dev:browser_staff:dev_notes
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
dev:browser_staff:dev_notes [2014/04/04 09:58] – integration erickson | dev:browser_staff:dev_notes [2014/05/19 16:59] – [2014-05-19] erickson | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ==== Browser Staff Client Development Notes ==== | + | ===== Browser Staff Client Development Notes ===== |
Explorations and milestones for the browser staff client development project. | Explorations and milestones for the browser staff client development project. | ||
- | === 2014-04-04 === | + | ==== 2014-05-19 ==== |
+ | Author: Bill Erickson | ||
+ | |||
+ | === More UI Work and Planning === | ||
+ | |||
+ | I've started working through some actual functional interfaces. | ||
+ | * See [[http:// | ||
+ | * I'm focusing on simpler interfaces for now, since each interface creates opportunities to solidify solutions to common problems. | ||
+ | |||
+ | I've started fleshing out the dev targets for the other dev sprints | ||
+ | * See http:// | ||
+ | * Review appreciated. | ||
+ | |||
+ | === Horizontal vs. Vertical Patron Display === | ||
+ | |||
+ | Is there any chance we can pick one patron interface layout instead of supporting both the vertical and horizontal displays? | ||
+ | |||
+ | What I have now in the prototype is kind of a hybrid. | ||
+ | |||
+ | For example: | ||
+ | |||
+ | |||
+ | Are there other aspects of either layout that we need to address? | ||
+ | |||
+ | === Link Behavior === | ||
+ | |||
+ | There have been some sporadic discussion about how links (< | ||
+ | |||
+ | To do this, we code the interface to present all links as standard replace-the-current-page links. | ||
+ | |||
+ | These are the commands for controlling link behavior in Chrome. | ||
+ | |||
+ | * Click : Open link in current tab, replacing current content. | ||
+ | * Shift+Click : Open a link in a new window. | ||
+ | * Ctrl+Click : Open a link in a new tab, while retaining focus on the current tab. | ||
+ | * Same as MiddleClick (mouse wheel button) | ||
+ | * Shift+Ctrl+Click : Open a link in a new tab and give focus to the new tab. | ||
+ | * Same as Shift+MiddleClick (mouse wheel button) | ||
+ | |||
+ | (Note that these controls also work on the navigation bar entries, which are also standard links). | ||
+ | |||
+ | Coding all the links the same creates consistent behavior and gives the user the power to decide for themselves when they want to open new tabs/ | ||
+ | |||
+ | Concerns / Comments / Questions? | ||
+ | |||
+ | ==== 2014-05-09 ==== | ||
+ | Author: Bill Erickson | ||
+ | |||
+ | === Project " | ||
+ | |||
+ | I've created some " | ||
+ | |||
+ | * http:// | ||
+ | * http:// | ||
+ | |||
+ | As code is completed on development targets and the time comes for additional eyes and user testing, they will be stricken through (w/ a date). | ||
+ | |||
+ | === Dependency Retrieval, Building, Testing, Minification === | ||
+ | |||
+ | In the early days of the prototype, I [[http:// | ||
+ | |||
+ | I also briefly discussed JavaScript [[http:// | ||
+ | |||
+ | Recently, I started experimenting with [[http:// | ||
+ | |||
+ | These three general areas of work are common to all modern JavaScript projects and the Internet has lots of tools for helping accomplish them. After some research, including discussions with over developers at the Code4Lib conference (go figure!), I've honed in on a nice workable solution. | ||
+ | |||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | * [[http:// | ||
+ | |||
+ | These are all Node.js plugins, which means once Node.js is installed as a dependency, the rest are managed via the Node package manager. | ||
+ | |||
+ | (To use the minified files from the browser, it currently requires a variable be set in the staff web template, but this will likely evolve into something more configurable / dynamic, like an environment variable, etc. It might be cool to support user-toggleable use of minified vs. non-minified files for standard production vs. debugging use). | ||
+ | |||
+ | These are certainly overkill for fetching some files and putting them into the correct places, but we need an external solution for headless unit test running and minification. | ||
+ | |||
+ | **NOTE**: This only affects packaging and installation, | ||
+ | |||
+ | As part of this work, I also pushed some new unit tests for our Angular services. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ==== 2014-05-01 ==== | ||
+ | Author: Bill Erickson | ||
+ | |||
+ | === Workstation Registration UI === | ||
+ | |||
+ | It's pretty much what you expect, with some additional features. | ||
+ | |||
+ | {{: | ||
+ | |||
+ | The login page now limits workstations to those registered on the current machine. | ||
+ | |||
+ | == Stored Preferences UI == | ||
+ | |||
+ | This one is particularly useful for debugging. | ||
+ | |||
+ | Note: We may eventually have data we don't want to display here for security reasons. | ||
+ | |||
+ | === Grid Update === | ||
+ | |||
+ | All of the existing prototype UIs which presented tabular data now use the grid. I did this, even though a few UIs are out of scope for " | ||
+ | |||
+ | Related, I discovered [[https:// | ||
+ | |||
+ | === Firefox Update === | ||
+ | |||
+ | Firefox version 29 was released this week. This release officially brings support for SharedWorkers, | ||
+ | |||
+ | When this is resolved, then FF and Chrome will both be good for global WebSocket connections in PC browsers. | ||
+ | |||
+ | === Catalog Integration : Feedback Requested === | ||
+ | |||
+ | The last big decision we have to make before we begin in earnest with porting interfaces regards the integration of the catalog into the browser client. | ||
+ | |||
+ | How will this work? | ||
+ | |||
+ | The catalog already knows when it's being accessed from a staff context by detecting a workstation. | ||
+ | |||
+ | Do we foresee any problems with this approach? | ||
+ | |||
+ | Of course, we still have to decide how to build it, e.g. do we integrate Angular/ | ||
+ | |||
+ | When viewing the catalog, do staff need access to the main staff menu bar along the top of interface? | ||
+ | |||
+ | To be clear, none of this should affect the regular patron view/ | ||
+ | |||
+ | Thoughts? | ||
+ | |||
+ | |||
+ | |||
+ | ==== 2014-04-23 ==== | ||
+ | Author: Bill Erickson | ||
+ | |||
+ | |||
+ | === HTML Printing === | ||
+ | |||
+ | For printing HTML, we are using the brand new JDK version 8, which includes as part of the standard edition classes for displaying and printing web pages. | ||
+ | |||
+ | http:// | ||
+ | |||
+ | The way we use them is pretty basic: pass in some HTML and tell it to print itself. | ||
+ | |||
+ | To use these classes, we have to construct a javafx Application and allow it run in its own thread, launched from the main thread. | ||
+ | |||
+ | Because of the overhaul, I started a new branch for Hatch at http:// | ||
+ | |||
+ | === Configuring Printers === | ||
+ | |||
+ | To print javafx Nodes, I had to move over to using the javafx.print library: | ||
+ | |||
+ | http:// | ||
+ | |||
+ | To test all of this, I've added an initial printer configuration interface to the browser client, under a new Administration menu. In here, users configure printers for different print contexts (just like the XUL client), currently one of default, receipt, label, mail, and offline. | ||
+ | |||
+ | This structure seems to work fairly well, but to protect you from yourself, Java will sometimes silently modify settings if the selected settings are invalid. | ||
+ | |||
+ | We're currently storing the following preferences for each print context: | ||
+ | |||
+ | * printer | ||
+ | * color vs monochrome | ||
+ | * paper source (e.g. automatic, tray 1, tray 2, etc.) | ||
+ | * paper type (Letter, etc.) | ||
+ | * orientation (landscape / portrait) | ||
+ | * left/ | ||
+ | * page ranges | ||
+ | * number of copies | ||
+ | * collation | ||
+ | * print quality | ||
+ | * print sides | ||
+ | |||
+ | What else do we need? | ||
+ | |||
+ | After some more testing, I'd like to put together a bundle that brave testers can download and run on their local machines so that we can start testing in different environments. | ||
+ | |||
+ | ==== 2014-04-11 ==== | ||
+ | |||
+ | I have a mixed bag of updates this week: | ||
+ | |||
+ | === Grid Design === | ||
+ | |||
+ | I put together a functioning infinite scroll grid using the [[http:// | ||
+ | |||
+ | === Grid Features === | ||
+ | |||
+ | * row selection | ||
+ | * multi-select via checkboxes and control-click | ||
+ | * ranged selection via shift-click | ||
+ | * select all / none | ||
+ | * Sorting | ||
+ | * quick sort by clicking on column headers | ||
+ | * primary, secondary, tertiary, etc. and ascending/ | ||
+ | * Pagination | ||
+ | * home, next, prev navigation | ||
+ | * go to page | ||
+ | * page size selection | ||
+ | * CSV download and printing | ||
+ | * Column reordering via drag-n-drop | ||
+ | * Column resize via drag-n-drop and via the grid configuration row. | ||
+ | * The drag-n-drop controls are buggy in FF at the moment | ||
+ | * Column resize only operates in one direction per drag action. | ||
+ | * I can expand on that for those interested. | ||
+ | * There is a lot of room for improvement with the drag-n-drop UI bits in particular | ||
+ | |||
+ | === Printing === | ||
+ | |||
+ | I reached a milestone recently while printing CSV output from a grid through Hatch (the print/ | ||
+ | |||
+ | The Hatch-connecting code is designed to fail gracefully and use the browser printer if no connection can be made. Browser printing is done (for now, anyway) via print CSS media and standard $window.print() on the current page .. no window.open() (and the various browser oddities that ensue) required. | ||
+ | |||
+ | |||
+ | === Status Bar === | ||
+ | |||
+ | Based on discussions at the #egils14, I put together a small status bar which lives at the bottom of the page. For now, it shows connectivity information for the server websockets connection and the Hatch websockets connection. | ||
+ | |||
+ | |||
+ | === SSL Hurdles === | ||
+ | |||
+ | I've encountered a number of challenges migrating to SSL WebSockets with untrusted certificates. | ||
+ | |||
+ | * Talking to the Evergreen server, Firefox provides no mechanism for allowing a connection to an untrusted certificate. | ||
+ | * https:// | ||
+ | * Related, Chrome will allow temporary connections to untrusted certificates for WebSockets within the current page, but not if the WebSocket connection is executed from within a shared web worker. | ||
+ | * Firefox (and probably Chrome, eventually) prevent security downgrades for WebSockets connections. | ||
+ | * https:// | ||
+ | * This means all WebSockets connections coming from the staff UI must use SSL, since the staff UI uses SSL. | ||
+ | * Of particular note here is the connection to the local print/ | ||
+ | |||
+ | The solution to all of these is to use trusted certificates. | ||
+ | |||
+ | The bigger challenge here will be providing trusted certificates to the local print storage service. | ||
+ | |||
+ | ==== 2014-04-04 | ||
- | == Integration Path == | + | === Integration Path === |
There are two ways we can integrate the new browser interfaces into staff work flow. Staff using a certain module can either use the browser directly as their primary work environment or we can (theoretically) integrate browser-based interfaces piecemeal into the existing XUL app. The purpose of the mixed (browser + XUL) approach is the ease staff into the new interfaces, to encourage earlier adoption by replacing functionality directly in the client, and to avoid the case where staff may have to switch back and forth between two different environments. | There are two ways we can integrate the new browser interfaces into staff work flow. Staff using a certain module can either use the browser directly as their primary work environment or we can (theoretically) integrate browser-based interfaces piecemeal into the existing XUL app. The purpose of the mixed (browser + XUL) approach is the ease staff into the new interfaces, to encourage earlier adoption by replacing functionality directly in the client, and to avoid the case where staff may have to switch back and forth between two different environments. | ||
Line 29: | Line 268: | ||
What are the other aspects of this decision? | What are the other aspects of this decision? | ||
- | === 2014-03-18 === | + | ==== 2014-03-18 |
I found some code which demonstrates printing of web pages in Java: | I found some code which demonstrates printing of web pages in Java: | ||
Line 37: | Line 276: | ||
It's using features not available until Java 8, due out this week. This will, in theory, allow us to print CSS-driven HTML, graphics, etc. | It's using features not available until Java 8, due out this week. This will, in theory, allow us to print CSS-driven HTML, graphics, etc. | ||
- | === 2014-03-14 === | + | ==== 2014-03-14 |
Found [[http:// | Found [[http:// | ||
Line 50: | Line 289: | ||
This doesn' | This doesn' | ||
- | === 2014-03-13 === | + | ==== 2014-03-13 |
- | == User Interface Grids / Tables == | + | === User Interface Grids / Tables |
The final (known) big item which requires resolution before coding can begin in earnest is the display grid. This will be the workhorse UI component, used in any interface that provides a list of data (list of checkouts, list of holds, list of holdings, list of records, every conify interface, etc.), which is many if not most UIs. | The final (known) big item which requires resolution before coding can begin in earnest is the display grid. This will be the workhorse UI component, used in any interface that provides a list of data (list of checkouts, list of holds, list of holdings, list of records, every conify interface, etc.), which is many if not most UIs. | ||
Line 100: | Line 339: | ||
The great thing about my experiments so far is that the back-end code is markup-agnostic, | The great thing about my experiments so far is that the back-end code is markup-agnostic, | ||
- | == Print/ | + | === Print/ |
It occurred to me that the print server will need to operate over WebSockets instead of XMLHttpRequest, | It occurred to me that the print server will need to operate over WebSockets instead of XMLHttpRequest, | ||
- | == WebSockets == | + | === WebSockets |
Thanks to Warren A. Layton for testing the WebSockets install / code! | Thanks to Warren A. Layton for testing the WebSockets install / code! | ||
Line 111: | Line 350: | ||
- | === 2014-03-07 === | + | ==== 2014-03-07 |
Author: Bill Erickson | Author: Bill Erickson | ||
Line 118: | Line 357: | ||
- | === 2014-03-05 === | + | ==== 2014-03-05 |
Author: Bill Erickson | Author: Bill Erickson | ||
Line 127: | Line 366: | ||
I'm pretty sure it's the item listed under APR 1.4.2. | I'm pretty sure it's the item listed under APR 1.4.2. | ||
- | === 2014-03-04 === | + | ==== 2014-03-04 |
Author: Bill Erickson | Author: Bill Erickson | ||
Some of the stuff I've been working on lately... | Some of the stuff I've been working on lately... | ||
- | == Print / Storage Server == | + | === Print / Storage Server |
Mentioned in IRC, I posted a proof-of-concept Java print/ | Mentioned in IRC, I posted a proof-of-concept Java print/ | ||
Line 148: | Line 387: | ||
So far, I have high hopes. | So far, I have high hopes. | ||
- | == WebSockets == | + | === WebSockets |
Testing, bug fixes, documentation, | Testing, bug fixes, documentation, | ||
Line 159: | Line 398: | ||
In this specific example, patron results render about twice as fast. With properly built APIs, we should see comparable speedups on similarly shaped data sets (e.g. long lists of results). | In this specific example, patron results render about twice as fast. With properly built APIs, we should see comparable speedups on similarly shaped data sets (e.g. long lists of results). | ||
- | |||
- | |||
- |
dev/browser_staff/dev_notes.txt · Last modified: 2022/02/10 13:34 by 127.0.0.1