Site Showcase - Mootools AJAXified System

[Xeoncross]

I just finished a remake of a site I could never have completed
without the use of the Mootools framework. I thought you guys might
like to see what I did with your system.

The beauty of this site is the indestructible AJAX interface that
downgrades to plain XHTML when a user doesn't support JS. Also, images
are not needed, source ordered layout for non-css users, etc. Try to
destroy it. ;)

http://xeoncross.com

I would would love your comments.

http://groups.google.com/group/mootools-users/browse_thread/thread/bac562fd1e09be18/925ed97fff9cf8a5?lnk=gst&q=new+dom+elements#925ed97fff9cf8a5

[nwhite]

The site looks great! Great job.

I did find one thing that is 'broken'. When in AJAX mode I have no easy way to bookmark a page or send a link to a current page. You might want to check Harald's History Manager (Ajax - Back Button). http://digitarald.de/project/history-manager/


Related to your other post I know understand why you were so concerned about memory consumption. Everything Aaron said is right. Javascript has builtin garbage collection. Closures with DOM elements was the biggest issue with memory leaks but using the Mootools framework properly negates that.

Again, I really like the site.


Nathan

[Xeoncross]

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).

[electronbender]

It's not that difficult.
I have a fully AJAX-ified site: http://www.f1almanah.com/ which uses
history, and can accept links too.
From what i've seen in your site, you can do that within 30 minutes...

[nwhite]

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.

[CroNiX]

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 <changereal...@gmail.com> 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.
>

[Michal]

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.

[Michal]

> Indecently, why doesn't JS allow a site to change the URL

Oops, it suddenly came to me that you mean just a "pretend" change of
URL: the URL that is shown in the browser's address bar, not an actual
redirect/forward.

Michal.

[Xeoncross]

Michal wrote:
> 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.

Yes, I wasn't able to figure out a way to setup the background images
(to be stationary) without forcing a 100px margin on the left side of
the screen. My next theme will hopefully be more compatible with
smaller screens. Anyway, the most important part of the design process
is to know your audience - and I knew that the only people that would
visit my blog where my friends and designers/programmers with larger
than 1024+ screens.

> 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

Yep, it works lovely on FF3 but chrome and IE can't handle it. Make a
note to self on that.

> 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.

Yep, until JS fixes that whole "you can't change a URL from JS" thing
it looks like I will have to break down and try one of those hash
managers again.

Tell me, why can't you change the URL dynamically? Why is it such a
danger? (aside from the aforementioned problem)

[Michal]

> > 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
>
> Yep, it works lovely on FF3 but chrome and IE can't handle it. Make a
> note to self on that.

I was actually on Safari on Mac... I think a similar thing happens on
FF3 if you zoom text only.

> Tell me, why can't you change the URL dynamically? Why is it such a
> danger? (aside from the aforementioned problem)

This I don't know... but maybe even keeping the location in-domain
could be a security hazard, as some sites could be controlled by
different people in different directories, some you trust and some you
wouldn't...?

[Claudio Moretti]

> Tell me, why can't you change the URL dynamically? Why is it such a
> danger? (aside from the aforementioned problem)

This I don't know... but maybe even keeping the location in-domain
could be a security hazard, as some sites could be controlled by
different people in different directories, some you trust and some you
wouldn't...?

I think I have an answer: imagine if you have a "My bank" link in a site you don't completely trust, you check in your statusbar if the URL is trustful (i.e. address = http://www.mybank.com) and you think it is. But when you click, there's a JS that changes the URL and redirects you on a phishing site; you trusted the link, why can't you trust the site? You can imagine the rest...

[Xeoncross]

> I think I have an answer: imagine if you have a "My bank" link in a site you
> don't completely trust, you check in your statusbar if the URL is trustful

> (i.e. address =http://www.mybank.com) and you think it is. But when you

> click, there's a JS that changes the URL and redirects you on a phishing
> site; you trusted the link, why can't you trust the site? You can imagine
> the rest...

That is a change of site link - we are talking about only allowing a
URL change
on the SAME site. Like,
mybank.com to mybank.com/page1.html

not
mybank.com to evilsite.com

[nwhite]

I understand you point. Historically Javascript has been crippled since it does run on the client. It has largely been accepted by the adoption committees that javascript should not be allow anywhere near anything that involves direct user interaction with the browser itself. This includes closing windows. Preventing a user from leaving a page, etc. It effects the usability of a browser if the user doesn't have complete control over the navigation bar.

While you proposal does have validity. Don't hold your breath. Even if the adoption committees considered adopting this fringe case I believe the potential exploits that it opens would prevent any kind of acceptance. Even if it did it would take years to become practical on the web. 

[Xeoncross]

On Dec 21, 4:10 pm, nwhite wrote:
> While you proposal does have validity. Don't hold your breath. Even if the
> adoption committees considered adopting this fringe case I believe the
> potential exploits that it opens would prevent any kind of acceptance. Even
> if it did it would take years to become practical on the web.

Yes, but what are those security holes is my question. So far I can't
think of any. ;)

Most of the time people don't want to try things (like allowing HTML)
in forms because they are afraid of "possible" holes that might come
up later - but most of the time, with the proper foresight and
implementation, it can be done easily with no side effects.

Thanks for the description of the purpose people see with the JS
language. However, I don't believe that allowing an alteration to the
address bar would be imposing on this. After all, when you go to a new
page the address bar already changes. This is just supporting a change
for the AJAX request instead of HTTP requests.