--- /dev/null
+Browser-Based Staff Client After-Action Report
+==============================================
+
+References
+----------
+
+ * http://yeti.esilibrary.com/dev/pub/techspecs/web-staff-prototype.html[Prototype Tech Specs]
+ * http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/berick/web-staff-proto[Code in Evergreen Working Repository]
+ * http://yeti.esilibrary.com/dev/pub/web-staff-log.html[Development Log]
+ * http://angularjs.org/[AngularJS]
+ * http://getbootstrap.com/[Bootstrap CSS]
+ * http://angular-ui.github.io/bootstrap/[AngularJS for Bootstrap]
+
+Prototype Development Goals
+---------------------------
+
+In addition to basic functionality, a number of specific development goals
+were listed in the tech specs. Below is a breakdown of how each of these
+were met and what remains to do for each.
+
+Speed / Responsiveness to user actions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ * Applications are developed in functional groups. Within each group,
+ page reloads are not required. This allows navigation between
+ tightly-linked functional areas without page reloads, e.g. jumping
+ between the patron items out list and the patron holds list.
+
+ * All data-fetching server communication runs asynchronously, allowing
+ other browser processing to occur while waiting for responses. This
+ also prevents the possibility of browser lock-up on long-running
+ requests. (See: egNet and egPCRUD).
+
+ * When possible, batches of data requests are fired at the
+ same time, instead of serially, to maximally leverage browser
+ parallel XMLHttpRequest connections. (E.g. egEnv.load())
+
+ * Special care was taken to avoid fetching data from the server until
+ needed, reducing the cost of up-front data loading.
+
+ * In some cases, primarily in the Record Buckets UI, traditional Perl API
+ calls were replaced with PCRUD calls. PRCUD is much faster than Perl.
+
+ * The code was implemented to support Javascript minification and it has
+ been confirmed to function correctly. When configured, this reduces
+ page load times.
+
+ * Apache gzip compression and cache optimizations added to sample Apache
+ configs. These were added because the existing settings were not
+ sufficient to satisfy standard web optimization practices. (See Chrome
+ Audits). Apache configuration cleanup and consolidation should be
+ considered so that other parts of the site get the same benefits.
+
+
+TODO Items
+^^^^^^^^^^
+
+ * Improved support for streaming and paging need to be added to some API calls
+ * New API calls could be developed to better deliver targeted data sets to
+ reduce the overrall number of API calls.
+ * To leverage streaming responses (which can reduce the number of API calls,
+ in some cases by a wide margin, and allow long-running calls, like
+ Vandelay imports), support for WebSockets is still suggested.
+
+
+Standards Compliance
+~~~~~~~~~~~~~~~~~~~~
+
+ * Prototype developed for and tested with Chrome and Firefox.
+ ** Incidentally, also confirmed to work on Safari and Opera.
+
+Ease/Speed of Development
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+****
+This is just my opinion.
+****
+
+Learning AngularJS (and Bootstrap) is neither easy or terribly
+difficult, but it does take some getting used to, especially if you
+are accustomed to writing code for the existing Dojo-driven Evergreen
+interfaces. However, once you're used to it, building interfaces is
+considerably easier in Angular, basically because there is much less
+code to write.
+
+Probably the biggest hurdle for new developers will be resisting the urge to
+fall back on manual DOM manipulation and bypassing the Angular environment
+altogether, when it suits his/her needs. A mix of Angular and non-Angular
+code will be difficult to support in the long run. There are verying levels
+of Angular code purity and the more Angular-correct the code is, the easier
+unit testing, etc will be, but more important than Angular perfection is
+simply staying within the Angular universe.
+
+There are two basic ways to do this:
+
+ * Avoid global variables/functions
+ * Avoid referencing DOM elements (outside of Angular directives).
+
+With these rules in place, you're pretty much forced to ask, "what would
+Angular do?"
+
+Comprehensive Support for Internationalization / Localization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+Accessibility / Screen Reader support
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+Quality Assurance Testing
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+Mobile / Responsive Design Best Practices
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+TODO
+
+Ease of Local Customization
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Customization of the staff prototype works much like the TPAC. It
+uses overridable Template Toolkit templates and template-driven CSS.
+Additionally, with the use of AngularJS for template content, it is
+considerably easier to customize the templates, because the link
+between the script and the templates is less strict than with traditional
+dynamic HTML.
+
+For example, AngularJS does not rely on the existence of elements, it
+only responds to the content it encounters. If an HTML element is
+removed or fails to be added as part of an upgrade, the lack of the
+element will not break page rendering.
+
+[source,html]
+-----------------------------------------------------------------------------
+<!-- old school -->
+<div id='username'><div>
+<!-- this DIES if <div..> is not present -->
+<script>$('username').innerHTML = "peggysue"</script>
+
+<!-- angular -->
+<div>{{username}}</div>
+<!-- all is well -->
+<script>$scope.username = 'peggysue'</script>
+-----------------------------------------------------------------------------
+
+
+Consistent Look and Feel Across Interfaces
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Bootstrap CSS classes are used wherever possible. Very little local CSS
+was created. The local CSS we do have is template-driven, like the TPAC.
+
+////
+vim: ft=asciidoc
+////
projects / working / Evergreen.git / commitdiff