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

[Bill Erickson]

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

> Hi Bill (and group),
>
> I apologize for being too late to add my input.
>
> In general, I'd prefer users to be able to interact with the grid as close
> to 'normal' web behavior as possible. With that in mind, I agree that
> double-clicking should select text rather than opening a page. Either
> having the data in one of the first columns display as links or having a
> simple edit button on each row would be very obvious to the users (and
> either would only require one click instead of two).
>

We discussed this at the conference a good bit.  I believe everyone
generally agrees that having a visible action, like you describe, for
"activating" a row (spawning an edit dialog, opening a new page, etc.) is a
good idea.  I tend to agree.  We don't want core behavior to be mysterious
to new users.


>
> For selecting multiple rows at once, checkboxes at the left of each row
> would be very obvious to users. CTRL-Click is nice too, but it's not as
> intuitive to most non-computer-savvy people. Also, I'm guessing checkboxes
> would be easier to use when using a touch-screen device or mobile device.
>

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.


>
> I second that simple, standard copy and paste would be wonderful to be
> able to do. Not being able to copy and paste from a grid row in the current
> client is a continual source of frustration. And doing so without building
> a pop-up to manage it would be ideal. I noticed on the example of the 3rd
> party angular UI that you posted a link to, I could not select any of the
> text.
>

We probably won't be using the Angular UI grid tool, but FWIW it does
support copy/paste, it's just not enabled by default.


>
> Paging versus Scrolling - I prefer paging, but with the ability to control
> how many rows display per page. Most pages on most library monitors are
> going to require scrolling of the entire page, and I find having to scroll
> within a box while I'm also scrolling a page is really annoying, especially
> when using touch screen devices. I've typically found that sites with
> paging also tend to resize better on different monitors and tend to print
> better (although these two things can probably be tweaked with diligent
> testing of the CSS).
>

All good points.

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).  On pages with multiple grids (admittedly, a rare
occurrence), then there will be multiple scrolls to contend with.

Having said that, though, whether scrolling grids are a better design
choice for the interface I can't say.  What is your average library staffer
going to better understand (today and several years from now) and be able
to use efficiently?

Following the mantra of What Would Google Do?, I note that GMail on my PC
is paged, while GMail on my phone is scrolled.  My (uninformed) guess is
that they're thinking paging is easier for the average user to grasp, but
that the paging controls are not worth the extra screen space on mobile
devices, where scrolling is generally more common, anyway.

The code for paged grids is simpler (slimmer, easier to maintain) and there
are fewer memory consumption concerns.  However, some people may find
scrolling grids easier to read, since you tend to focus on one part of the
screen as opposed to tracking from top to bottom.

Other pros and cons?

After recent experiments, I can say that either approach is feasible and I
have not (yet) discovered any features that can only be implemented in one
vs. the other.   Which is best?  (Whoever says, "let's do both!" is
electing him/herself as maintainer for that code, BTW).  Anyone else have
opinions on scroll vs. page?

-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-general/attachments/20140331/4ce7b0a8/attachment.htm>