Digital Door Sign Specifications

This web-based door sign should have two visual parts. Both should work from desktop web-browser and from phone.

  • staff input: to rapidly update your status.
  • public display: to rapidly view a CSCF person's status.

Public Display

  • the URL for a user's page should be very easy to determine; such as https://hostname/door/userid
  • the user's page should include whatever information the user has supplied; centered on the page.
    • the status should be in the middle of the page; there will be optional "header" and "footer" information above and below.
  • the app's root URL https://hostname/door/ should prompt for a user name or userid in a fill-in field, look up the userid from user name if necessary, and translate that to the above user's page URL
    • the root page should offer a link to "log in"
      • for development, we can use an Apache Basic Auth file with a .htpasswd for valid users.
      • for production, we can switch to ADFS, which would allow us to know who are valid users without keeping our own table for it.

Staff Input

  • if a logged in user goes to someone else's page, it will be the same as Public Display. If they go to their own page, they see the input page, which loads various information from the database for this user and allows them to submit the page.
  • All of the below functions should be available as buttons on the input page; and also as unique URLs that can be bookmarked so they can send an update with a single click.
    • The format should be https://hostname/door/USERID/LOCATION/TIMING where USERID and LOCATION are mandatory for updates, and TIMING is optional.
    • (eg., https://hostname/door/userid/Here, or https://hostname/door/userid/Away:Home or to add 30 minutes to the timing, https://hostname/door/userid/Away:Meeting/30 )

Status

  • Status will appear on both the public display and the input page.
  • A status has three portions: Location, Timing, and Last Updated.
    • Location is mandatory; Timing is optional; and Last Updated is supplied by the app.
    • Default status is "Away" with "Last Updated" appearing on a smaller second line of text in the format "Last updated yyyy-mm-dd hh:mm"

Input Page

  • The input page shows the status (as with the public display) and then has three sections for updates; Location, Timing, and Defaults.
  • Where the below refers to "buttons," implementation is up to the developer. If the user-interface works better with scrolling drop-down lists instead of a list of buttons, please do that!

Location:

  • The first button should be "Away". Pressing it will update the Location, clear the Timing, and update the "Last updated" line to now.
  • The second button available will change the sign to "Here," clear the Timing, and update the "Last updated" line.
  • Users can add new options which are available in the future, and are visible as buttons - listed as an alphabetically sorted list (eg., "Away: back soon", "Away: DC2564", "Away: home", "Here: please knock", "Here: in meeting; knock if emergency")
    • in all cases, changing the Location will clear the Timing and update the "Last updated" line.

Timing:

  • Timing will display as "Back at ..." and an optional formatted time (eg., "yyyy-mm-dd hh:mm AM/PM")
  • There will be a date-and-time picker to choose an exact time.
  • There will also be buttons for common defaults, both relative and absolute times.
    • Common "Back" defaults include: "+5 minutes" "+15 minutes" "1pm" "After lunch" "Tomorrow morning"
    • If they click "+5 minutes" the time will be calculated and stored as a time, not stored as "in 5 minutes"
    • If they click "+5 minutes" twice, it should update quickly to have a total of 10 minutes added.

Defaults:

  • There will be text fields on the input page to store this user's "start of day" and "back from lunch" times (via date and time picker).
  • There will be text fields for optional "Header" and "Footer" information, such as "If you require assistance when I am away, please contact the CSCF Help Desk ..."

QR Code:

  • There should be a link from the input page to output the public URL for this user as a QR Code, so we can print it for our door. it appears there is a React component to generate these, which might make this easy.

Database

(draft schema; there may be more tables and fields necessary).

There should be at least three tables; for:

  • user_current_status (one row per userid)
    • .userid = text field
    • .current_status_text = text field
    • .due_back = date and time, optionally supplied by the user.
    • .timestamp = date and time last updated
  • user_preferences (one row per userid)
    • .userid = text field
    • .user_header = text field that appears at the top of their page
    • .user_footer = text field that appears at the bottom of their page
  • user_status_options (many per userid)
    • .userid = text field
    • status_text = text field

-- DanielAllen - 2019-08-30

Topic revision: r3 - 2019-09-04 - DanielAllen
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback