Experiment with more browser-based staff interfaces

Bug #1117658 reported by Jeff Godin
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Fix Released
Wishlist
Unassigned

Bug Description

There is community interest in experimenting with more browser-based staff interfaces.

This interest has been demonstrated by several individuals in discussion on the open-ils-dev list and in #evergreen -- both before and after the "future of the staff client" development meeting of Feb 6, 2013.

Such interfaces would enable functions which are traditionally seen as "xulrunner-based staff client only" to be performed by staff from most modern web browsers. There will be benefits and trade-offs, and with some experimentation these can be more clearly identified.

Working branches and progress should be tracked here, until such time as it no longer makes sense to do so.

Tags: fixedinwebby
Changed in evergreen:
status: New → Triaged
Revision history for this message
Bill Erickson (berick) wrote :

In IRC, we discussed the idea of picking a development path, implementing some proof of concept code (a common staff feature, like checkout), evaluating the results, then moving on to other paths as needed for experimentation. The first path we decided to experiment with was the path of least resistance: using the latest version of Dojo and OpenSRF javascript (http translator, JSON.js, etc), build a checkout interface. (Note, we need to verify/make the IDL parsing code work w/ modern Dojo and/or ask Thomas about is non-Dojo IDL code...).

I hope to do some coding soon as time allows....

While we're musing the idea of a web-based staff client, it might also be a good idea to collect examples from the t00bz of sites the we like and/or leverage good technical/visual design.

I'll start with https://play.google.com/music/listen?u=0#start

(It helps if you have a google account).

It's not gorgeous, but it's clean, functional, and snappy.

In particular, I like how it uses page anchors for navigation, which means pages are book-markable, but do not require loading from the server for basic navigation. For example, clicking on Artists takes you to ...#artists, which just causes the main body of the page to change (via JS) without having to reload all of the surrounding components.

This is similar to how I imagine a staff client functioning. Each top-level page is a collection of all of the activities
 a staff member performs when engaged in a given role. For example, if staff perform the same 20 things at the circ desk,
 those 20 things should be accessible within the main Circ page (e.g. via anchors) without requiring any page loads. Each
 activity can be accessed quickly with one click.

I also find the layout as a whole to be very usable, with the command bar along the top and the page-specific actions along the left.

Considerations for later:

1. Approaches for making sites faster.

E.g. https://developers.google.com/speed/docs/best-practices/rules_intro

2. Creating some sort of general design manifesto to ensure visual consistency and usability across interfaces and to avoid the introduction of unneeded stuff.

3. What HTML5 and CSS3 features can we leverage? Do we need Dojo Dijits or can we get most of what we need using native code?

http://davidwalsh.name/datalist
http://peter.sh/examples/?/html/meter-progress.html
http://davidwalsh.name/demo/html5-context-menu.php
http://www.webdesignerdepot.com/2012/10/creating-a-modal-window-with-html5-and-css3/
There are many more...

Revision history for this message
Alex Lazar (alex-lazar) wrote :

I would support the idea of using a responsive and/(or) adaptive CSS layout that works for all devices. Perhaps something like http://twitter.github.com/bootstrap/ could be of use.

As far as HTML/CSS, I would hope to get all of what we need with native code, if possible. Wikipedia actually has good feature comparison tables for CSS and HTML:

1. http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28Cascading_Style_Sheets%29
2. http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29

Revision history for this message
Job Diógenes Ribeiro Borges (jobdrb-gmail) wrote :

"I would support the idea of using a responsive and/(or) adaptive CSS layout that works for all devices."
Yes, we are more fast moving to iPad, Tablet, mobile Internet.
Solutions, that could work in WebBased are becoming mandatory.
What about use of HTML5 ? Ajax, JS and HTML5 are really good trends IMHO.

What the people think?

Revision history for this message
Remington Steed (rjs7) wrote :
Revision history for this message
Remington Steed (rjs7) wrote :
Revision history for this message
Andrea Neiman (aneiman) wrote :

Tagged "fixedinwebby" with tongue firmly in cheek. Seriously though, not sure about the best practice for closing something like this. I'll leave that to a Bug Maintenance person.

tags: added: fixedinwebby
Revision history for this message
Terran McCanna (tmccanna) wrote :

Ha! I believe we can change the status to "Fix Released"? I'll try it and someone will correct me if I'm wrong!

Changed in evergreen:
status: Triaged → Fix Released
Changed in evergreen:
milestone: none → 3.0-alpha
status: Fix Released → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.