Hi Maria,

> Thanks Shawn for the recommendations! I'll have to
> tell my husband about Filezilla.

My pleasure. :)


> ...we have people submitting tournament information
> using our form.

Looks like it's using FormMail in one variation or another. Depending on
which one he's using (which I won't "test" without permission) it may
have some rather nasty security holes providing the ability for anyone
in the world to either send spam from your server or execute commands on
your server. Neither of which are good.


> [form to] calendar format we have.

How is the calendar generated? Is it using a database to compose the
actual layout already? If it is then I would recommend having the form
accept the data and post it to the database and alert you via email that
a new record has been entered, requiring your approval (via a link that
toggles an "approved" field in the table) to enable the record. This way
you can minimize the work on your end for each new entry.

However, if it is not already using a database to display the calendar
then you may have quite a bit of work to do to generate it
automatically. Seriously consider switching to using a database-driven
calendar. Here's an example:
http://www.motherlodek9.com/therapy/visits.asp
This calendar is generated directly by data within a database, and it
uses patterns to generate the results so it isn't tied to creating a new
record for each specific event. For example, "Avalon" occurs the first
Saturday and the second Wednesday of every month, while "WATCH" only
occurs on the fifth Friday - when a month has five Fridays (yes, I
thought that was absurd, too). Other patterns you can use are stuff like
"every x days", "every x weeks", "the next to last Tuesday", "the 23rd
of each month". It was a lot of fun putting that together. ;)

I need to setup an example/test db sometime so I can show people the
data-entry interface, too. If you think the output is cool - you'll LOVE
the data entry form. Anyway...


> In addition, we have people e-mail their flyers to us so
> we can add that to our calendar. Can you recommend an
> easier way to do this?

These could be upoaded directly to your site, as well, and if it were
all bound to the same database table you could store the PDF in such a
way as to index them for content (free searchable content for your site)
and link directly from the calendar cell. Since this is what you're
after anyway, I think that would be the best way to go.

> Are there any security type problems with receiving their
> files off the website?

Oh yeah. Depending on the server architecture (you happen to be using
Linux) you might have major issues with double-file-extension parsing (a
common problem for default installs of the Apache web server), or just
stuff like uploading too much content for your site to support. Also,
file uploads are often prevented in "secure" systems where the page
being uploaded to is in a child frame from a non-originating server -
like when you frame wrestling.brookings.net with sdyw.com, and frame
sdyw with ncyw.com (which can also severely affect your adsense revenue,
btw).

For the "too much data" issue you could minimize the effects by using
users/passwords, but you would not prevent the double-file-extension
issue in Apache. This is something you'd have to write a wrapping
routine to validate the form and structure of the content for validity
(and it's best to rename their file to prevent executeable extension
mapping).


> Any other comments/suggestions you may have on our
> website would be great, too.

Get rid of the frames. If you absolutely cannot include the content
directly on the site (without duplicating another domain!) then use a
301 redirect from your ncyw site to the site you really have the content
on. Otherwise some search engines, spiders and users will not be able to
see the content. The default installation of IE on locked down Windows
prevents frames from other domains so they'd never see it. And probably
the worst part, is that people visiting your site for specific content
cannot bookmark it. They end up bookmarking the home page, effectively
forcing them to dig through your entire site again to find what they
wanted last time.

Minimize the use of tables. I know it's hard, the first time especially,
to create a site without tables, but over 80% of your home page is
tables, and that's going to make it load slower than it could on most
browsers (the entire table has to be downloaded before anything within
it will display), and you're duplicating the functionality of basic html
with the "lists" you've created as table cells in each side column.
Using an unordered list (UL) with a style-based list-marker would get
the same effect and save you a few kb right off the top.

Where you've provided click-maps for regions of an image, place
text-based equivalents close to the image. Not everyone uses a mouse, or
has the ability to use it effectively to select a specific visual
region.

Add index files to each folder on your site. It's really easy to find
out more about a server by stripping off the file name and digging
through directories that become exposed by the Apache automatic index
(directory browsing) feature.

Lastly, try to avoid forcing the page to a specific width. Your home
page is 1290 pixels wide, which is wider than the two most common screen
resolutions, effectively forcing a horizontal scrollbar on more than 95%
of your visitors. And the people that do use larger resolutions (like
me) often have their browsers set to an area approximately 800x600, in
order to get the best look from the other 9 million sites designed only
to work with 800x600. If you still want to push the width to what would
fill the screen on a 1280x1024 screen you should reduce the width to at
a maximum of 1240px, since that accounts for the scrollbar and the
window edges in most computers (also called "chrome"). I wouldn't
recommend creating any fixed-width sites, though, especially if it can
be avoided easily (where tables really shine).

Regards,

Shawn K. Hall
http://12PointDesign.com/