Hey Everyone,
I just finished up a site i've been working on for quite some time. If you wouldn't mind taking a look, and letting me know how it looks, and works. That would be great. Before i start getting yelled at for no netscape support, the menu doesn't work in netscape, but it will in about a month. The client doesn't really like netscape anyways and told me not to worry about it

Also, if you can't get to the website, thier router gets killed by all the students downloading porn, and they are waiting for a replacement. Kinda a pain, but o'well

All the content wasn't done by me, i just made the framework and admin tools for the site. Some pages look good, some don't

http://www.cazenovia.edu/

Oliver

I think it is a very professional-looking site. Pretty easy navigation and the pages load quickly. One important point you have well covered is the common "look and feel" throughout the site. I like it.

There seems to be a bit of a problem with the menu. The selection doesn't move smoothly when you hover over one item and them move down to hover over another one.

It takes too long for it to unhighlight the current item and then it feels like their is a pause before it highlights the new item. It also somethings highlights one of the intermediate items on the way. The result of this is you end up waiting for the UI to catch up with you so you can see the sub menu.

You could make the HTML quite a bit more compact if you made more use of CSS classes. There is lots of formatting data which should be using classes instead.

You should also move your inline Javascript into separate .js files, so that it can get cached sensibly on the client.

Both of these will significantly reduce the size of some of the pages, some of which are a little large. There are some "short" pages that are 135kb or so in size, which would take 30 seconds to download on the average modem.

Using Opera 6, and it appears like the opening photograph is a bit close to the cazenovia college logo.

Calvin

Just thought I would say a little more about the size of your pages as I was short of time to comment more fully last time. Take http://www.cazenovia.edu/viewSection.aspx?id=69&title=Need%20Based as an example (it seems fairly typical).

The total size of this page is around 131Kb, which breaks down into:

- 17kb Javascript
- 110kb of menu markup/code
- 2kb of markup for the actual content
- 2kb of actual content

So the actual data the page is displaying represents only 3% of the data that the browser has to download to display the page. If the browser only needed to download that 3% then the page would be loaded in under a second on the average modem, compared to 30 seconds for the pages as they are now.

The first easy thing to do is to move the Javascript out of the page itself and into a .js file. You can then include it on each page using a <script> tag (this assumes that the Javascript is common for every page in the site, which appears to be the case).

I bigger problem at this stage in the project is shifting the data for the menu out of every page. As I see it you have two options here; start using frames or build the menus on the fly from Javascript.

I know lots of people have a downer on frames, but they can serve useful purposes. In this case if you made the menu a separate frame the data for it would only need to be loaded once. You would unfortunately probably have to revisit your menu code however, because it pops out to the right and would probably therefore get cut off by the frame.

The alternative to frames is to define the menus in a set of arrays in a .js file and also add code to the .js file to build the menus on the fly using DHTML. Then include this .js file in every page with a <script> tag and call the Javascript to build the menus when the page has loaded. There are several downsides to doing this however:

- it might be slow on low spec machines
- it's extra code that you need to write
- you have to make the DHTML code work on more that one browser

If it was me doing the coding I would take the frames route. One of the things that people don't like about frames is that when people find your pages from search engines they tend to end up with the content page, without the menus. There are ways to solve this though, if you can assume your client has Javascript, by putting code on the pages to detect when they are loaded without the menu frame and then have them reload with the menu frame in place.

If you did all of this then imagine the effect of a user coming to the site and visiting just ten of your pages. With the current design they would download 1.3Mb of data. With the changed design they would download only 167Kb of data. That is nearly 8 times less data that they have to download.

I spotted that you are using the menu control from http://www.aspnetmenu.com/

So I downloaded it and took a look at it. It looks like you can save yourself the 17Kb of Javascript on each page by setting a single property on the control:

"Optimizing Menu Output:

You can substantially decrease the amount of content that gets sent to the browser by specifying the ClientScriptLocation property;
This property should point to the folder containing the core ASP.NET Menu JavaScript files; If this property is specified, the control will only render the JavaScript include tag, saving about 15Kb per request, since the JavaScript file will be cached by the browser after the initial request"

Unfortunately this won't solve the main problem with this control, the whole of the menu structure will still get downloaded on every page.

P.S. looking at that menu control is enough to make me seriously consider getting into the ASP.NET controls business myself, their design is lacking and they haven't even done the hard bit yet (make it work on Netscape <6). They do have pretty graphics though...

Wow, that is fantastic advice. What a great BBS we have here.

I work on an Intranet app that we sell to customers that has to support tens of thousands of concurrent users and costs thousands per seat, so I tend to get fairly obsessive about saving a few k here and a few k there...

...our app currently runs to about 200,000 lines of code across 1,000 .asp, .htm, .js, .vb and .xsl files. And that doesn't include the database neutral, data driven middle-tier it all runs on top of. All the data exchange between the IIS layer and the middle-tier is with XML, I've almost forgotten how to call the database direct...

Hi Andy,
Thanks for your in-depth input. I'm aware that this menu control sucks alot. I've been looking into other menus, but can't seem to find a good menu. The guy that wrote the aspnet menu control has been promising netscape <6 support from around july i think. He finally just gave me a copy of the program for free. So we decided to use it for a bit.

Anything on their website is extremely easy to change. Everything but the main page sits in a sql database. Everything is cached to keep sql queries to a minimum.

As soon as I find a better control that can cut down on html output, and support netscape I will put it into effect, thanks for the info on the caching script option, I knew about it, just haven’t turned it on yet.

FWIW, I built a website with this menu. I initially used version 3 which caused Netscape4 to crash. Version 4 works in Netscape4 (well enough) and works 100% in Netscape6.

CoolMenus is very nice. I actually opted for DHTML Quickmenus on my last project, which is also a great script. Quite customizable. I liked being able to use graphics both for the actual rollover buttons as well as in the menus.