I'd like to second Heikki's concern about breaking the Back button &
browser history, and about the appropriate use of Ajax.
Ajax is very seductive, and does increase perceived responsiveness of a
web application. That's a Good Thing.
Ajax breaks the user's model of navigation, taking away basic tools
she's used to having. That's a Bad Thing.
Jakob Nielsen, the reigning Guru of Web Usability, has some very
common-sense things to say (backed up by formal usability research)
about Ajax and the Back button (these are short pages, easy reads):
Web 2.0 Can Be Dangerous
Within-Page Links for AJAX
Top Ten Web Design Mistakes of 1999 (still applicable)
Nielsen's recommendation and my own preference is to use Ajax only when
really helpful: maps/graphs, mode switching or commands (e.g.
Simple/Advanced Search), and improving on the lousy, primitive GUI
widgets HTML gives us (e.g. overlong Select boxes, unsortable tables,
fixed size TEXTAREAs).
For everything else, especially navigation, avoid Ajax, and use KISS
technology (Keep It Simple Stupid)!
Users will be happier that way.
Just my $0.02,
Simon Pigot said the following on 10/10/2008 06:51 AM:
> Hi Heikki,
> I'm not an expert on the various browser history frameworks but I think
> using tabs, modal dialogs and some other gimmicks can reduce the amount
> of work required to fix the broken back button. The approach we've used
> (you can see it in the BlueNet MEST sandbox of GN) is:
> - layout the page using tabs - simple, advanced, remote search and
> mapviewer are the tabs on the main page
> - shift the viewer/editor into its own window (without the navigation
> - do almost everything else (eg. privileges, categories, delete, about,
> administration etc) via an Ajax drop-down modal box dialog that appears
> over the top of the current page, thus it doesn't affect the content and
> doesn't look like a page change
> Yes - none of the above fix the back button in that clicking the back
> button probably does something that you wouldn't expect :-) - but there
> isn't really much need/inclination to use it either as the tab page
> content is always visible so the user doesn't really feel like the page
> content has changed.
> Fixing the back button in this layout isn't unfeasible either as looking
> at dsHistory (http://code.google.com/p/dshistory/) where you can
> directly attach js functions to the history, I think I can see how the
> back button could be made to do something reasonable eg. clicking the
> back button after having closed a modal dialog would make it reopen or
> clicking the back button after changing a tab would take you back to the
> tab you were at. I can also sense that without care this type of history
> manipulation could get ugly to code and/or maintain though....
> As I say I've only just glanced at this briefly....so this is opinion at
> best and quite likely ill-informed opinion at worst :-)
> heikki wrote:
>> Hello lists,
>> I'd like your opinion / advice on the following :
>> the browser history is fundamentally broken in GeoNetwork, on 2
>> different counts.
>> (1) Public site
>> In the public part of GeoNetwork, just about every request is an Ajax
>> request. This means that they are not put in the browser's history,
>> and therefore the browser's back (and forward) buttons are broken for
>> these requests.
>> Now there are some examples where it is perfectly fine to have Ajax,
>> such as the loading of the mapviewer, displaying small parts of a page
>> like "recent changes", "news" and "rating". But in my opinion those
>> requests that look like page changes to the user, should not break the
>> back button. These include "searchform to search results"; "search
>> results to metadata view", to name but a few. In cases where the
>> layout of GeoNetwork is very different from the standard layout, such
>> as is being developed for the Dutch "national" georegister, this
>> becomes even more apparent and annoying.
>> A possible solution is a hack to the browser's history; to this end we
>> this a quick try but somehow it did not work immediately in IE, and
>> since that is by far the important browser, the fix was useless.
>> However according to the RSH docs it _should_ work in IE ; so maybe
>> with a bit more effort we can get that to work.
>> The other obvious solution is to replace the Ajax requests with good
>> old synchronous HTTP requests.
>> What do you think ?
>> (2) Logged-in site
>> In the logged-in part of the site there are various instances of
>> requests that post form data; this breaks the back button in the most
>> important browsers, as they will show a "Page Has Expired" when you
>> try to go back after such a request. Also some of the back buttons on
>> the pages do nothing but call the browser's history, and they are
>> likewise broken. Example include viewing the categories or privileges
>> from a metadata, validating metadata and more.
>> The solution to this might be to use a pattern known as "PRG" or
>> "Redirect After Post". In my opinion this is good practice in every
>> case where we POST things because it not only solves the browser
>> navigation, it also makes it very easy to prevent double submits.
>> However it may be quite a lot of work. Does anyone know of, or has
>> already made, a solution like this using our Jeeves framework ?
>> thank you in advance for your replies
>> Heikki Doeleman
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> GeoNetwork-devel mailing list
> GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork