What’s all this, now?

XULRunner is the framework on which we built the Evergreen staff client.
"XULRunner is a Mozilla runtime package that can be used to bootstrap XUL+XPCOM applications that are as rich as Firefox and Thunderbird." — XULRunner Project Home Page
https://developer.mozilla.org/en-US/docs/XULRunner_Hall_of_Fame
Version 14 of XULRunner, required by Evergreen, was released July 2012.
As of February, the latest version of XULRunner is version 28.
14 releases of security fixes, bug fixes, speed improvements, and features we can’t use.

Why Can’t We Update XULRunner?

$Used The Documented API$

* Consarn ye, XULRunner!

Why Can’t We Update XULRunner?

We’ve been using XULRunner like a development platform with a stable API and set of rules.
"XULRunner is a delivery vehicle for the XUL toolkit, which is not a frozen API. It is an API that has historically evolved over time, and it will likely continue to evolve for some time to come. While people agree that we need to stablize that API, it will not happen overnight." — XULRunner Development Plan Docs

The Big Lost Features of XULRunner

Remote XUL
- Gives XULRunner the power to read UI templates from the server
- Changes to server-hosted template files are applied to the client without the need for desktop application updates.
- "Support for remote XUL has long been a potential security concern; support for it was disabled in Gecko 2.0." — Remote XUL Docs
E4X (ECMAScript for XML)
- Used by MARC Editor
- "E4X, an ancient JavaScript extension, has been removed. Implemented only in Gecko, it never got significant traction (bug 788293)." — Firefox 21 Site Compatibility
multipart/x-mixed-replace messages
- Streaming responses
- "Support for the multipart property and multipart/x-mixed-replace responses has been removed from XMLHttpRequest. This was a Firefox-only feature that was never standardized." — Firefox 22 Site Compatibility

What do we do about it?

We have a significant amount of work to do, regardless of how we proceed.
Why not take this opportunity to reconsider how the client should operate?
After some lively debate among the community, we have decided now is the time to move toward a web browser-based staff client.

What’s So Great Web Browsers?

Remote updates
The browser is the de facto client development environment.
Aggressive competition between browsers
Your average developer is more likely to have experience with HTML than XUL.
Most of our problems have already been solved.
Browser interfaces can work on mobile devices.
- Inventory on a Nexus?
- Real-time holds pull list on an iPad?
- Running reports in the browser built into your refrigerator?
Browser Features are designed, documented, and implemented by a diverse groups of individuals, organizations, and standards bodies (w3c, etc.)
Browser support for a given feature is a good litmus test for long-term viability.
Good support for assistive technologies, like screen readers, etc.
Existing, proven tools for local template customization and translations.

What’s So Great Web Browsers?

Ease of moving between different Evergreen servers (production servers, test servers, migration servers, etc.)
It’s easy to create deep links to specific resources (e.g. patrons)
Supports multi-tab interfaces
Bonus: Much of the staff client is already developed as individual web pages.

What Challenges Come with Using a Browser?

Seemlessly printing to multiple printers
Secure file storage
- offline transactions
- workstation registrations
Interacting with 3rd-party services running on the desktop.
- RFID pad

What do we do about this?

Buid a small, standalone service ("shim"), which runs on the desktop.
- Talking to printers
- Reading/Writing files
- Potentially interact with 3rd-party applications
The goal is have a small, stable API that requires infrequent updates.
Only required by clients that need these features.
HACKFEST UPDATE: could also be run as a shared service, accessible over the local network to workstations and mobile devices, so each can print (and maybe more) to a single instance.
If built correctly, it could used by other systems, like Koha.

Staff Client Prototype Project

Build a sample application so the community could test the look and feel.
Interfaces
- Patron Search
- Checkout
- Items Out
- Items on Hold
- Checkin
- Record Buckets
Prototype Dev Log
Prototype After-Action Report
Browser Client Development Manifesto

Staff Client Prototype Project

Patron Search

Development Components

AngularJS
- JavaScript development framework project from Google.
- 2013 Stack Overflow User Survey Results
- 113 Neat Things Built With AngularJS
Bootstrap CSS
- Mobile-friendly CSS with a rich feature set.
- Beautiful and inspiring uses of Bootstrap

Development Components

Java / Jetty for the Print and Storage service
- Java is portable and has flexible printer support.
- Jetty is a small "Servlet Engine and HTTP Server".
- Browser can communicate directly with Jetty over HTTP / WebSockets.
WebSockets
- Bi-directional, streaming, long-lived connections
- Replacement (and then some) for multipart/x-mixed-replace
- Blog Series

WebSockets Streaming Example

Patron Search

XMLHttpRequest requires 102 OpenSRF messages; WebSockets requires 51.

Let’s Build This Thing

http://www.flickr.com/photos/evergreen-ils/3182703496/in/photostream/

ACQ Scribbles

Guiding Principles for the Project

¡Muy Rapido!

Reduce the amount of time supporting two systems
Avoiding feature drift and feature locks

Guiding Principles for the Project

Port existing features from XUL to HTML, as directly as possible, without adding new features along the way
Only XUL interfaces will be wholly rebuilt. Existing HTML interfaces (conify, acq, vandelay, etc.) will be integrated as-is.
As each sprint begins, the community will be placing restrictions on features added to the analogous module within the XUL client.
- Avoid duplication of effort
- Encourage development and use of the new interface.

Proposed Timeline

Sprint	Modules	Estimated Time
1	Base Components (WebSockets, Grids, etc.) and Circulation	18 weeks
2	Cataloging, z39.50 , and Authorities	12 weeks
3	Acquisitions and Serials	6 weeks
4	Reporting and Admin	7 weeks
5	Booking, Offline, Odds and Ends	8 weeks
6	Bug Fixing / Integration	6 weeks

Sprint #1 Progress

Dev Notes
WebSockets code complete and call for testing [LP#1268619]
- Using WebSockets by default in the staff UI
Proof of concept Print/Store service ("Hatch")
Display Grids

Sprint #1 Pending Code, Research, and Questions

JS integration of print/store server
JS components for keyboard shortcuts and navigation
More Grid work
Integrating existing HTML UIs with browser client
Integrating the TPAC with the browser client
Possibility of Integrating web UIs into XUL to ease integration

Development Partners

Sprint #1 - fully funded!
- BC SITKA
- Bibliomation
- C/W Mars
- GPLS PINES
- Howe Library
- MassLNC
- PaILS
- Pioneer
- SC Lends
Sprint #2
- Grand Rapids Public Library
- NC Cardinal

Comments and Questions

Bill Erickson <berick@esilibrary.com>

A Browser-Based Evergreen Staff Client

What’s all this, now?

Why Can’t We Update XULRunner?

Why Can’t We Update XULRunner?

The Big Lost Features of XULRunner

What do we do about it?

What’s So Great Web Browsers?

What’s So Great Web Browsers?

What Challenges Come with Using a Browser?

What do we do about this?

Staff Client Prototype Project

Staff Client Prototype Project

Development Components

Development Components

WebSockets Streaming Example

Let’s Build This Thing

Guiding Principles for the Project

Guiding Principles for the Project

Proposed Timeline

Sprint #1 Progress

Sprint #1 Pending Code, Research, and Questions

Development Partners

Comments and Questions