Experiment with more browser-based staff interfaces
Bug #1117658 reported by
Jeff Godin
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.
Changed in evergreen: | |
status: | New → Triaged |
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.
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 peter.sh/ examples/ ?/html/ meter-progress. html davidwalsh. name/demo/ html5-context- menu.php www.webdesigner depot.com/ 2012/10/ creating- a-modal- window- with-html5- and-css3/
http://
http://
http://
There are many more...