Re: [IUG] buttons vs. check boxes to mark records

[Bob Duncan <duncanr at lafayette dot edu>]

At 12:49 PM 02/13/2007 -0800, Sue wrote:
> Our redesign team has come up against a problem we are hoping someone
> has a solution for. The Pro example set has buttons to mark records for
> export in browse display. We've noticed that when you click the "save
> record" button you are sent back to the top of the browse list rather
> than back to where you were when you clicked the button. This does not
> happen in our live system which uses check boxes. We've explored other
> Pro libraries' catalogs and observed the same behavior. Is there any way
> to fix this? I'm sure it has to do with the onClick=return
> replace_or_redraw" but I don't know enough about onClick options to
> figure out how to make it change the gif with the "clear item" button
> and return to the same spot.


I think it's the old "there's no there there" problem.  When you mark an 
individual record by clicking the button, you're saving the record and 
generating a new URL, hence a new page, and it's standard browser behavior 
to start at the top of a page.  (Essentially, the "same spot" does not 
exist on the new page.)  To land the user somewhere other than the top of 
the new page would require targets in the code and the ability to re-write 
on the fly the URL that results from marking a record.  Someone who's 
really clever with Javascript might be able to figure out a workaround, but 
since the button is generated via a token in conjunction with a wwwoption, 
if it's possible to do so I think it would take some fancy footwork.

The difference with the checkboxes is that nothing actually happens when 
you check a box---the records aren't saved until you click the "Save marked 
records" button.   If you click the button at the top of the screen you 
will remain at the top of the display (albeit the top of a different 
display), but if you click the version of the "save marked" button that 
appears at the bottom of the screen, you will indeed be placed back at the 
top of the (new) display.

It would be nice if the new "marked" class that's added to the browseEntry 
row in index browses had been incorporated into briefcit marking so users 
could be given visual clue for where they left off in browsing the list, 
but that didn't happen.  (I'm guessing the "clear" button that replaces the 
"save" button is supposed to provide that clue.)  What would be nice is a 
built-in mechanism that places users at the same place in the list of 
entries that they were when they clicked the save record button, especially 
in light of the R2006 ability to provide users a list of 50 instead of 12 
entries.  (Might be a good reason to stick with 12?)

Bob Duncan


~!~!~!~!~!~!~!~!~!~!~!~!~
Robert E. Duncan
Systems Librarian
Editor of IT Communications
Lafayette College
Easton, PA  18042
duncanr at lafayette dot edu
http://www.library.lafayette.edu/