From: Markus F. <in...@fl...> - 2011-05-20 09:54:20
|
In openurl.tpl there is an onclick event on line two, which has an error option: error: "{translate text="An error has occurred"}" If I see this correctly, this error appears in the UI, if the user clicks e.g. on a facetted option _before_ the page has finished loading the onclick event. The message "An error has occurred" may be technically correct, but as usual, the user will read up to the word "error" and then will have a high probability to leave the site... ;-) So I'd suggest to change the error message into something more "understandable" in this context: error: "{translate text="Loading"}" I may be wrong though, if the "error" will appear in other situations too... Markus PS: you may see the new error message in action, if you stress test the site here, by clicking as fast as you can: http://bibnet.org |
From: Demian K. <dem...@vi...> - 2011-05-20 13:18:11
|
I think this is a little bit complicated... That message is used for the AJAX callback's generic "failure" method, which can be called in a lot of different circumstances -- the three most likely being network problems, malformed responses or user interruption. It's a bit annoying that these cases are lumped together, since you want to respond very differently when the network or software fails vs. when the user hits the Escape key or clicks to leave the page before AJAX processing is complete. That being said, the current error-handling behavior (an alert box containing a message) was written on the assumption that it would very rarely happen. The default trunk openURL code only triggers when a user clicks a button, and once they have done that, it is unlikely that they're going to leave the page again. Since you have customized this so that the openURLs load automatically, that greatly increases the likelihood that the user will interrupt the process and get unwanted error messages. Changing the text helps a little, but I really think that any kind of browser pop-up is going to annoy and confuse people. Perhaps a better solution for your situation is to change the getResolverLinks function in themes/your_theme/js/ajax_common.js so that the failure function does this instead: failure: function(http){ myTarget.innerHTML = strings.error; } This way, if something fails, the "loading..." gets replaced with an error message. In the case where the user interrupts the process, they won't notice this since they're going to another page anyway. In the case where an error really does occur, a message will show up where the openURL link belongs, but the user won't get bombarded with a series of 20 pop-up boxes. Does that make sense? - Demian > -----Original Message----- > From: Markus Fischer [mailto:in...@fl...] > Sent: Friday, May 20, 2011 5:54 AM > To: vuf...@li... > Subject: [VuFind-Tech] Change error message in openurl.tpl > > In openurl.tpl there is an onclick event on line two, which has an > error > option: > > error: "{translate text="An error has occurred"}" > > If I see this correctly, this error appears in the UI, if the user > clicks e.g. on a facetted option _before_ the page has finished loading > the onclick event. > > The message "An error has occurred" may be technically correct, but as > usual, the user will read up to the word "error" and then will have a > high probability to leave the site... ;-) > > So I'd suggest to change the error message into something more > "understandable" in this context: > > error: "{translate text="Loading"}" > > I may be wrong though, if the "error" will appear in other situations > too... > > Markus > > PS: you may see the new error message in action, if you stress test the > site here, by clicking as fast as you can: http://bibnet.org > > ----------------------------------------------------------------------- > ------- > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Vufind-tech mailing list > Vuf...@li... > https://lists.sourceforge.net/lists/listinfo/vufind-tech |
From: Markus F. <in...@fl...> - 2011-05-20 15:10:06
|
Demian, this is much better! Thanks a lot! Works smooth and perfect! Markus Am 20.05.2011 15:18, schrieb Demian Katz: > I think this is a little bit complicated... That message is used for the AJAX callback's generic "failure" method, which can be called in a lot of different circumstances -- the three most likely being network problems, malformed responses or user interruption. It's a bit annoying that these cases are lumped together, since you want to respond very differently when the network or software fails vs. when the user hits the Escape key or clicks to leave the page before AJAX processing is complete. > > That being said, the current error-handling behavior (an alert box containing a message) was written on the assumption that it would very rarely happen. The default trunk openURL code only triggers when a user clicks a button, and once they have done that, it is unlikely that they're going to leave the page again. Since you have customized this so that the openURLs load automatically, that greatly increases the likelihood that the user will interrupt the process and get unwanted error messages. Changing the text helps a little, but I really think that any kind of browser pop-up is going to annoy and confuse people. Perhaps a better solution for your situation is to change the getResolverLinks function in themes/your_theme/js/ajax_common.js so that the failure function does this instead: > > failure: function(http){ > myTarget.innerHTML = strings.error; > } > > This way, if something fails, the "loading..." gets replaced with an error message. In the case where the user interrupts the process, they won't notice this since they're going to another page anyway. In the case where an error really does occur, a message will show up where the openURL link belongs, but the user won't get bombarded with a series of 20 pop-up boxes. > > Does that make sense? > > - Demian > >> -----Original Message----- >> From: Markus Fischer [mailto:in...@fl...] >> Sent: Friday, May 20, 2011 5:54 AM >> To: vuf...@li... >> Subject: [VuFind-Tech] Change error message in openurl.tpl >> >> In openurl.tpl there is an onclick event on line two, which has an >> error >> option: >> >> error:"{translate text="An error has occurred"}" >> >> If I see this correctly, this error appears in the UI, if the user >> clicks e.g. on a facetted option _before_ the page has finished loading >> the onclick event. >> >> The message "An error has occurred" may be technically correct, but as >> usual, the user will read up to the word "error" and then will have a >> high probability to leave the site... ;-) >> >> So I'd suggest to change the error message into something more >> "understandable" in this context: >> >> error:"{translate text="Loading"}" >> >> I may be wrong though, if the "error" will appear in other situations >> too... >> >> Markus >> >> PS: you may see the new error message in action, if you stress test the >> site here, by clicking as fast as you can: http://bibnet.org >> >> ----------------------------------------------------------------------- >> ------- >> What Every C/C++ and Fortran developer Should Know! >> Read this article and learn how Intel has extended the reach of its >> next-generation tools to help Windows* and Linux* C/C++ and Fortran >> developers boost performance applications - including clusters. >> http://p.sf.net/sfu/intel-dev2devmay >> _______________________________________________ >> Vufind-tech mailing list >> Vuf...@li... >> https://lists.sourceforge.net/lists/listinfo/vufind-tech |