LGS Functional Specs and Wireframes

From wiki.gpii
Jump to: navigation, search

This page contains an evolving set of specifications and wireframes describing what is being built at a more fine grained level than the user stories.

This page is an evolving set of functional specifications and wireframes for the LGS. Over time they are expected to evolve from a state of more ambiguity to a state of detailed concreteness.

Iteration 0

The focus of this first development year iteration is a stable system that can be installed on the box and clients.  This includes:

  • GPII package that can be easily installed on the box, library workstations, and personal users laptops.
  • GPII Administration that can manage which preferences server is in use (local on the box, or GPII sponsorered cloud server)
  • Ability to tap in to anonymous library workstations.
  • Ability to automatically obtain settings when using an authenticated log in.
  • Ability for end users to initially set up configuration and settings when prompted at the start of the pilot.
  • Support for basic configuration/stop/starting of AT already installed on the particular workstation in use.
  • Compelling prototype of accessibly media on demand using Robobraille as a backend.

With the exception of the media on demand we consider everything above core functionality that must be stabile and production ready in order to deploy in pilots. It's also critical that it works very well so that we can build more advanced functionality on top of it.

We will now go through these steps and breakdown the user interaction, starting from installation and setup as administrator to usage as a library patron.

Comments from Jim: This is Windows, right? If so, which versions? Note that different workstations are used for different purposes -- catalog and other library functions vs. Internet access. Both should be considered core functions. If users are going to set up their profiles in the library, they will need assistance, which will come from us or the library staff; this needs to be factored into the pilot planning.

Administrator installation and configuration

We will have a short wizard that installs/configures the GPII Server components on the library box. The initial items we need to setup are on the list below, but going forward this will be the springboard we build off of for more advanced settings. For example, in our simplest iteration here we allow the input of which Preferences server to use. One that is on the internal box and automatically provisioned, and one that is hosted externally, such as the official GPII hosted server. In future iterations, this type of configuration will expand to allow for the various connectivity scenarios, such as syncing on semi-regular basis with the outside world etc etc.

  • Configuration of which preferences server to use. Local box or URL and information for external box.
  • Selection of authentication plugin to use and it's configuration. (ie. LDAP, local box)
  • Ability to generate the configuration for this server box to use with client provisioning.

TODO: Insert pictures for these screens.

Comments from Jim: Who is doing the installing? Given the small number of pilot installations, shouldn't it be us? Or are we assuming that it's the library ICT staff? I guess using the latter would give us feedback on the design, but this is another job responsibility for them and may affect how the host institution views the pilot. Are we looking at remote administration as a project goal, not just for the pilot? Whatever the answers, this needs to be part of the pilot plan. 

Administration Status

We will have at least a rudimentary status page for the system status that can added to in the future.

TODO: Insert screens

Patron Client Install

For library patrons that will be running the GPII locally on their machine, they will have a similar install wizard, without some of the admin like options. This could be provided to them by their host library system preconfigured, or it could be a similar experience to connecting an Exchange account to a laptop or mobile device where you provide the server and credentials, and the server is interrogated for options which are then pulled down.

Comments from Jim: 'their machine' is the laptop or tablet they bring to the library? What about using it when they're not at the library -- they will have access to GPII at home or wherever else we set them up? I'm not sure we want to be testing the installation process in a pilot, which is bound to be rough around the edges and undergoing frequent change. The alternative is to assist them with initial installs and do remote admin later. Just brainstorming on this....

User Facing Pilot Setup

At some point during rollout of an implementation or pilot, users need to be walked through the setup and snapshotting tools. Ideally, much of this functionality will come from the existing PCP/PMT projects and we will tailor/customize them for use in the LGS.

Comments from Jim: Yes, I see this as a local accessibility event of some sort -- all recruited users come to the library, we help them with installing, configuring, their settings, etc., and probably work with library staff too. 

User Facing Anonymous Usage

This is our classic case of tapping in at an anonymous kiosk and the fonts, settings, etc changing. As of now this doesn't have any screens per se, however, I think it would be good to design some level of accessible indicator for each platform to let you know you've tapped in. An audible ding or "Hello", a little notification pop up in the system tray etc.

We need to determine an appropriate way to automatically reset system settings in the event a user walks away without tapping out. Perhaps have a certain idle time. The UW anonymous library kiosks are the current test target for this.

Comments from Jim: Yes, this would work best if we can piggyback on what happens now. Are anonymous sessions really 'sessions'? There's no identifying info. But this may operate differently for Internet access and catalog use. For example, some libraries automatically may clear the browser history to end a session, even an anonymous one. Can our reset be triggered by that?

User Facing Authenticated Usage

In this scenario the user is automatically logged in to GPII as part of the operating system login. Because the user is authenticated in this environment we may want to allow more services (that would be bad to leave on in the anonymous workstation scenario where you might not log out at all). Similarly we might want some indication that various services are present.

In this scenario, a lot of interesting things can be done for the media on demand. Such as operating system hooks (i.e. drop something in a folder to have it made accessible).

Currently the UW Infolabs are the test target for this.

Comment from Jim: Here again, we may be looking at different current behaviors for Internet access and reserving or checking out a book. We should piggyback on whatever they do, right? Active logout = GPII logout; system session timeout = GPII logout. But what about the case when the user has left but there's been no timeout? Maybe a special screensaver after a brief timeout that says log in again (looking for the same method of authentication from the current GPII user) or press any key to begin (looking for a non-GPII login or a new GPII user login).

Patron Client / Home Usage

For usage on home laptops, it would seem a lot of the value will be from using media on demand and related services as their home machines are typically set up as need be.

Comments from Jim: What about the laptop they brought to the library? Can we set it up so that they have access to LGS at home, via wifi? This would be attractive to libraries, as it's another way to stay close to their users.

Media on Demand / Robobraille Prototype

TODO: Insert screens

Back to the LGS Dashboard