Evergreen

Bug #1117658
Comment #1

Comment 1 for bug 1117658

Revision history for this message

Bill Erickson (berick) wrote on 2013-02-08:

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...

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?