:backend: slidy
:max-width: 45em
-== Why Are We Talking About This? ==
+== How did we get here? ==
[role="incremental"]
+ * "XULRunner is a Mozilla runtime package that can be used to bootstrap
+ XUL+XPCOM applications that are as rich as Firefox and Thunderbird."
+ * XULRunner is the framework on which we built the Evergreen staff client.
+ * 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
== Why Can't We Update XULRunner? ==
[role="incremental"]
- * We've been using XULRunner like a development platform.
-// with published features which are maintained
- * XULRunner is really a test bed for Firefox.
-// as browser features are discarded, they are removed from XULRunner
- * Too bad we are using some of those discarded features.
+ * We've been using XULRunner like a development platform with a stable API.
+ * "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."
+ -- https://wiki.mozilla.org/XULRunner[XULRunner Development Plan Docs]
== The Big Lost Features of XULRunner ==
[role="incremental"]
* Remote updates
- * The browser is the de facto client development environment
+ * The browser is the de facto client development environment.
* Aggressive competition between browsers
- * Developers as far as the eye can see
- * Most of our problems have already been solved
- * Browser interfaces work on mobile devices
+ * 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?
- * Much of the staff client is already developed as individual web pages.
* Browser Features are designed, documented, and implemented by a diverse
groups of people and standards bodies (w3c, etc.)
* Browser support for a given feature is a good litmus test for long-term
== What's So Great Web Browsers? ==
[role="incremental"]
- * We can keep our multi-tabbed interfaces
* It's easy to create deep links to specific resources (e.g. patrons)
+ * We can keep our multi-tabbed interfaces
+ * Much of the staff client is already developed as individual web pages.
== What Challenges Come with Using a Browser? ==
[role="incremental"]
- * Seemlessly printing to different printers
+ * Seemlessly printing to multiple printers
* Secure file storage
** offline transactions
** workstation registrations
// as the code stabilizes, the updates will be less frequent
* If built correctly, it could potentially be shared and used by other
systems, like Koha.
+ * HACKFEST UPDATE: this could also be built to 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 remote shim.
[NOTE]
======
image:images/browser-client-patrons.png[Patron Search]
-== Browser Developer Tools ==
+== Development Components ==
* http://angularjs.org/[AngularJS]
** JavaScript development framework project from Google.
[NOTE]
======
-The final product will be a mix of new Angular UIs and
-existing web-based UIs. Only the XUL interfaces being wholly rebuilt.
+The final product will be a mix of new Angular UIs and existing web-based
+UIs. Only the XUL interface will be wholly rebuilt.
======
== Sprint #1 Funded ==
* JS integration of print/store server
* JS components for keyboard shortcuts
+ * 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