webclient: Some interfaces would benefit from a progress bar

[Kathy Lussier]

There are some webclient interfaces that would benefit from a progress bar indicating that data is still loading.

For example, when loading "view holds" for a bib record, the "No Items to Display" message appears for a while before the titles display, leading the user to believe there are no holds on the record.

I'll try to take some time to identify other interfaces that could use a progress bar.

[Victoria Lewis (sykeslewis)]

I'm working to add a progress bar while loading "view holds" for a bib record.
Is there an example of a good use of a progress bar already in the client, one that people like?
I've been using the one from search patrons as a model.

[Kathy Lussier (klussier)]

The search patrons bar was the one I was going to recommend. Thanks Victoria!

[Bill Erickson (berick)]

How about a progress bar that presents as a floating / modal window (via shared directive)? With this, we don't have to find space in the page for the progress bar or risk having a progress meter the causes the page to shuffle as it appears and disappears. This is especially useful when adding a progress bar to an existing crowded page.

Alternatively, we could have a section of every page reserved for progress bar space (like in the navbar) similar to the XUL client progress bars along the bottom of the UI.

Or maybe embedded in an ngToast?

My thinking is the easier it is to put a progress meter in the page, the more likely people are to use them.

[Victoria Lewis (sykeslewis)]

commit 1ab407621a78c4aa38279e8694176e3de30ffedb

committed http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=1ab407621a78c4aa38279e8694176e3de30ffedb

LP#1522638 webclient: Some interfaces would benefit from a progress bar

When loading "View Holds" for a bib record, progress bar modal appears while user waits
for the titles to display.

Test Plan
[1] Locate a media item with holds
[2] Click on View Holds
      Note progress bar appears until titles are loaded.
[3] Locate a media item with no holds
[4] Click on View Holds
       Note that progress bar doesn't appear

[Bill Erickson (berick)]

Thanks for knocking this out, Victoria! I think there's just a bit of cleanup left.

The last posted commit makes changes to a file (t_progress_bar.tt2) that does not exist in master. Just to confirm, both commits from user/vlewis/LP1522638-add-progress-bar-view-holds are required?

If so, can we get these 2 partial commits squashed? Also there are a number of commented out debug alerts, etc. that we don't need going into master. Those should be removed.

Lastly, and this is more of a wishlist thing, but we would eventually want a progress bar to respond to current and max value updates from the application, so that the progress bar can progress as data is loaded, providing useful feedback to the user. Something along the lines of: egProgressModal.open(); egProgressModal.update({max : 100, value : 23}); ...; egProgressModal.update({value: 35}); ...

[Victoria Lewis (sykeslewis)]

Squashed the commits.
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/vlewis/LP1522638-add-progress-bar-view-holds

[Bill Erickson (berick)]

Thanks, Victoria. Temporarily removing the pullrequest and grabbing this one. Going to take a stab at the real-time progress updates.

[Bill Erickson (berick)]

Sign-off for Victoria's code plus additional commits pushed here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1522638-progress-bar-holds-etc

1. This adds support for both determinate (value / max) and indeterminate progress bars.

From the inline docs:

+ * Open an indeterminate (100%) progress bar.
+ * egProgressModal.open();
+ *
+ * Open a determinate progress bar.
+ * 'max' can be set in open(), update(), or both.
+ * egProgressModal.open({value : 0});
+ *
+ * Update a determinate progress bar.
+ * egProgressModal.update({max : 45, value : 25});
+ * egProgressModal.update({value : 26});
+ * egProgressModal.update({value : 27});
+ * ...
+ *
+ * Close it.
+ * egProgressModal.close();

2. Progress bar implemented as an HTML5 <progress/> element. The HTML5 element renders much more accurately than the Bootstrap pseudo-progress component.

3. For determinate progress meters, the percent complete is also shown in the dialog.

4. Tip commit replaces the inline patron search progress meter with an indeterminate egProgressDialog.

[Bill Erickson (berick)]

By the way, anyone with CSS skills and a good eye could probably style the <progress/> element a lot better than what I've done, which was just to fill the space. Rounded corners, colors more consistent w/ Bootstrap, etc.

[Terran McCanna (tmccanna)]

I tested this in 2.12 on the View Holds screen and the Patron Search screen. Thanks Victoria and Bill!

I have tested this code and consent to signing off on it with my name, Terran McCanna, and my email address, <email address hidden>.

[Bill Erickson (berick)]

Thanks, Terran!

I'm planning to merge this code tomorrow, unless someone beats me to it, since other pending bugs are waiting to leverage the progress dialog code.

[Bill Erickson (berick)]

Rebased branch, complete with Terran's sign-off's pushed back to:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1522638-progress-bar-holds-etc

[Bill Erickson (berick)]

After further use and testing (integrating with other branches), I have added another feature to the progress dialog: a semi-determinate mode. With this, the <progress/> bar appears as an indeterminate bar (showing no specific indication of progress), but the dialog also shows the current value (assuming it's set).

This is useful when we know how many of something we have retrieved from the server, but we have no way to know how many we will ultimately retrieve. (This is a surprisingly common scenario, because it's faster to simply fetch stuff than to first ask how many stuff's I'll be getting). This allows us to show that actual progress is being made, without creating an imaginary end-point for the progress.

Will push the new commit shortly for another set of eyes.

[Bill Erickson (berick)]

New progress dialog features and docs pushed back to main branch:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1522638-progress-bar-holds-etc

Since the behavior of the progress bars in this branch is unchanged from what Terran tested, I retained the sign-offs. The new features are mainly intended for other UI's (holds pull list, patrons w/ negative fines, etc.). They are documented inline, which can be seen here:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=blob;f=Open-ILS/web/js/ui/default/staff/services/ui.js;h=ad4c104abcc2fc45311d232919643414ec8ca282;hb=refs/heads/user/berick/lp1522638-progress-bar-holds-etc#l81

I think is finally done. Will leave unmerged for other eyes.

[Mike Rylander (mrylander)]

Should we have a service.setValue() in addition to increment()? Some APIs report progress in chunks, and that would save the caller from having to remember the previous progress value so it can be subtracted from the new one for use with increment().

[Bill Erickson (berick)]

Mike, there are 2 functions available for setting the value.

.update({value : 123})
.update({value : 123, max :456}); // e.g. set/change the max some time after open()

.increment(); // increment 1
.increment(5); // increment 5

Do these cover your use case?

[Mike Rylander (mrylander)]

Doh! They sure do. Not sure how I missed that... NOTHING TO SEE HERE, MOVE ALONG.

[Kathy Lussier (klussier)]

I noticed there is still an old-style progress bar that appears when saving the patron record. Should that be replaced with the new progress bar?

[Bill Erickson (berick)]

Kathy, it looks like there are a number of progress indicators scattered about that will need replacing. Would you be amenable to me opening a new bug to address the remaining UI's so that we can get the code from this bug merged sooner than later? I'd like give it a chance in the wild, verify it's what we want, and shake out any remaining bugs before migrating the other interfaces.

At a glance the remaining UI's include:

patron edit
age to lost
bucket record searching
z39.50 searching
holds shelf
circ backdate dialog.

[Kathy Lussier (klussier)]

Sure, that's fine. I can merge this code as is when I have a moment (hopefully today) unless someone else beats me to it.

[Bill Erickson (berick)]

Thanks, Kathy. I have opened bug #1670427 for the remaining UI's.

[Kathy Lussier (klussier)]

Thank you Victoria, Bill and Terran! Merged to master for inclusion in 2.12RC