If I could chime in with another few issues: My laptop has quite a small screen, and even on my desktop I tend to keep my browser window quite small. Although the default size of your content does fit nicely within my normal size of the browser window, it is not centered when I initially view your site, and so a bit of horizontal scrolling is required. Then also, once I click a link on the menu, the page scrolls back to the left.
Another thing, if I increase the text size, the header becomes filled with a very large area of black (so lots of vertical scrolling is required). Another minor point is that with a large font size some of the menu items jump up into the black area, and looks a bit strange (although admittedly it is difficult to keep a design looking nice with the user increasing font size). I agree with the posters above that using a history manager is a good idea. Another issue with not having one is that if a user lands on a page deep within your site, all other pages (including the home page) appears to have the address of the deep page. Also, you write > Indecently, why doesn't JS allow a site to change the URL but it does! window.location.replace(newLocation); can be used to forward to "newLocation" without adding anything to the browser history (and so not breaking the back button). I do the following for a portion of one of my sites (it is for a gallery, but each photo does have a unique non-numbered page name): I have this sort of arrangement: gallery/photoTitle/ gallery/anotherPhotoTitle/ On each page, I have some JS that extracts the last part of the URL, and uses window.location.replace to forward to, say, gallery/#photoTitle/ gallery/#anotherPhotoTitle/ And then HistoryManager (for MooTools 1.2) to keep the correct hash in the address bar when changing photos using Ajax. I imagine you could do something similar for your whole site...? Also: I do like the torn paper look! Michal. CroNiX wrote: > I would suggest preloading the mouseover images in your menu system so > they don't pop up a second or two after you mouseover them for the > first time. > > On Dec 19, 9:52�am, nwhite <[email protected]> wrote: > > I hear yeah. The naming scheme for hashes could get tricky for a whole site > > like yours. > > > > If you ever did resolve it you could have a hook in your back end that looks > > at the url and takes the anchor and redirects it to the correct page. Using > > a method like this on the back end would allow the hash based bookmarks to > > work for javascript and non javascript browsers. > > > > Again nice job. > > > > On Fri, Dec 19, 2008 at 11:41 AM, Xeoncross <[email protected]> wrote: > > > > > Thanks for the comment! > > > > > Yes, I have been fighting with the whole "to use URI hashes, or not to > > > use URI hashes.. That is the question!" I worked with Harald's script > > > but I decided that trying to figure out a hash system for a site with > > > lots of pages might be to hard to manage. It's fine for photogalleries > > > or AJAX tabs - but not a full site with lots of pages and stuff. > > > > > Google would have one URL to the page - and the users would have > > > another url (with a hash) to another page. I don't think that would > > > work. > > > > > I was actually thinking of placing a "location/address" bar up at the > > > top that told the REAL page URL. > > > > > Indecently, why doesn't JS allow a site to change the URL? I > > > understand that phishing could take rise - but just limit the change > > > to the current site (the same way we handle cookies) That would keep > > > badsite.com from changing the URL to chase.com. > > > > > This is the biggest thing I see for JS right now - here we want to > > > break out of the old fashion HTTP requests - but the browsers won't > > > let us! We would save so much bandwidth just sending partial pages > > > (most on my site are 2-5kb).
