BACK in GeoNetwork broken in 2 ways

[heikki doeleman]

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 might use a javascript thing called "Real Simple History". I once gave 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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@...
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

[Simon Pigot-6]

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
buttons)
- 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 :-)

Cheers,
Simon

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
> might use a javascript thing called "Real Simple History". I once gave
> 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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@...
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork

[Rich Fozzard]

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
       http://www.useit.com/alertbox/web-2.html

    Within-Page Links for AJAX
       http://www.useit.com/alertbox/within_page_links_comments.html

    Top Ten Web Design Mistakes of 1999 (still applicable)
       http://www.useit.com/alertbox/990530.html

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,
--Rich
   

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 
buttons)
- 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 :-)

Cheers,
Simon

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 
might use a javascript thing called "Real Simple History". I once gave 
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@...
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
  

-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@...
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork