[OPEN-ILS-DEV] prototype staff client, feedback/2

[Mike Rylander]

On Sat, Jan 25, 2014 at 3:14 PM,  <schan at vcn.bc.ca> wrote:
> I am giving more feedback on the prototype staff client that was recently
> released.
>
> I advocate for a fairly capable notification service at the outset so that
> end-users don't have to endure something cheap and nasty.  I think it
> matters
> to put more brain power into the notification service right away, because
> it's
> responsible for representing the staff client to users in times when they
> are
> learning or struggling with its use, for example, doing nonsensical
> sequences
> of operations, errors are showing up, network connections are broken, and so
> on.
>

Agreed.  And it's helpful in debugging if one can turn on a "verbose" mode.

> In the staff/services/ui.js file, two notification services, egAlertDialog
> and
> egConfirmDialog, are defined alongside some low-level functions.
>
> a. The differences between Alert and Confirm are slight. It seems more
> efficient to collapse the two into one, and to define the code in its own
> file,
> staff/services/notification.js or similar.  The calling scheme for the
> single
> service would be something like
>
> var confirm = egNotify({ title:'title', body:'body', yes:yes, no:no });
> var alert   = egNotify({ title:'title', body:'body', yes:yes        });
>
> b. If no yes/no callbacks are specified, for example,
>
> var progress1  = egNotify({ title:'title'              });
> var progress2  = egNotify({                body:'body' });
> var progress3  = egNotify({ title:'title', body:'body' });
> var no_op      = egNotify(                              );
>
> would show the message for a short time period, say 2 seconds.
>
> c. If egNotify() is quickly called multiple times, the service would queue
> up
> the inbound messages and show them in a first-in, first-out fashion.
>
> d. A call to egNotify() would not directly execute a function to show the
> message, but would broadcast the input object as a custom event. An event
> handler would be listening for the same type of events and would respond by
> showing the message according to the details in the object. This loose
> coupling
> of the service from the rest of the UI would allow controllers or other
> services to use egNotify and not be much affected by a refactoring of
> egNotify.
>

Overall I like the suggestion, but I wonder if we shouldn't just
subclass a generic event publisher with a "confirm" and "alert"
classes.  They would inherit a channel to publish to, and supply the
flags required to cause the confirm/yes/no behavior appropriate for
the class.  That would make the code more explicit at the call sites,
would keep us from using magical or idiomatic parameters, and allow us
to change/improve one or the other or both as needed down the road.

> The end result would be something akin to the notification service one finds
> on
> a desktop. Perhaps there is something like this already written in the
> angularjs world.
>

I'm  not certain if there's something shaped just like what we want,
but I bet there's something similar.  Dojo has a "toaster" UI
component that can require confirmation or just fade away, and I bet
Angular has something like that.

Thanks, Steven, for the feedback.  The code we're looking at here is
just a prototype, and meant more to explore user-level viability as
opposed to production-grade code-level engineering, but now that the
code is out and works (and is fast!) it's time to begin thinking about
that.

-- 
Mike Rylander
 | Director of Research and Development
 | Equinox Software, Inc. / Your Library's Guide to Open Source
 | phone:  1-877-OPEN-ILS (673-6457)
 | email:  miker at esilibrary.com
 | web:  http://www.esilibrary.com