[OPEN-ILS-DEV] Browser client dev log update / feedback request on grids

Bill Erickson berick at esilibrary.com
Tue Apr 1 09:34:19 EDT 2014


On Mon, Mar 31, 2014 at 6:24 PM, McCanna, Terran <
tmccanna at georgialibraries.org> wrote:

> Bill,
>
> >>The approach I'm testing now is a combination of checkbox (single select
> / multi-select), row click (single select), row ctrl-click (single select /
> multi-select), and row shift-click (batch select). The different styles
> seem to complement each other well and in each case the state of the
> checkbox (and CSS) indicate which rows are selected. <<
>
> Nice! That sounds like it would cover everything a user will try (and they
> WILL try everything...)
>
> >>Regarding scrolling, when we build pages that only have a single grid,
> we have the option of allowing the grid to fill the page. That is, there
> will only be one scroll bar on the page (the main scroll) and as you scroll
> down the page, you are scrolling through the content as well (and new
> content is fetched as needed). <<
>
> When printing this type of page, would it by nature default to printing
> all records unless the staff told it to only print selected pages? I'm
> thinking of the times when there might be hundreds or even thousands of
> results and staff members that will click print without limiting the pages.
> With paging instead of scrolling, there'd be an automatic limit on how many
> pages would print at once based on how many records the user chose to view
> at once.
>

Indeed, we would have to create some type of artificial / configurable
barrier, like only printing the visible or selected rows.  Printing
thousands of rows would be a bad thing.


>
> Your mention of scrolling requiring more memory raises red flags - I don't
> think PINES is alone in having a lot of libraries running very old/slow
> machines on slow connections. Granted, we're saving memory in a lot of
> other places with the web client, so it might be okay to use a little more
> memory here if it offers significantly better usability, but I'm not so
> sure that it would... I'd like to hear opposing viewpoints though.
>

As would I.  I'm confident we can build it to be memory efficient, it will
just take a little more poking and prodding to be sure.


>
> Thanks for putting so much thought into these details and giving the rest
> of us insight into your findings!
>

Thanks for the feedback.

-b

-- 
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: berick at esilibrary.com
| web: http://esilibrary.com
| Equinox Software, Inc. / The Open Source Experts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20140401/bdc2feb5/attachment.htm>


More information about the Open-ils-dev mailing list