FIDO UI Changes
FIDO UI Changes
WHY:
- These changes began development based on the rule at https://www.ada.gov/resources/2024-03-08-web-rule/ and guidance we were given from UW legal and the UW ADA coordination office. Updated guidance on the ADA office on 2025/11/03 brings into question whether a tool like FIDO is in scope or not and MUST change, none the less, here we are, and I plan to proceed.
- Based on specific evaluation of FIDO itself by the Center For User Experience [https://it.wisc.edu/about/division-of-information-technology/center-for-accessibility-user-experience/], for ns-apps and deficiencies highlighted by CFUE in a report, I embarked on remedying the UI, making some quality of life and performance improvements as I went along.
Key changes;
- alarms and logging no longer in combined view: two tabs required
- visual changes with CSS styling
- FIDO header has been re-arranged; some data is now at the footer, new features added
- Settings have been rearranged with some functionality changes
- Page reloading has been moved to javascript instead of using meta-refresh
- FIDO no longer refreshes unless your tab/screen is visible
- Significant performance improvement in the web view; up to 10x faster than before for large reports
Additional details far below, past the picture show/tell
Live demo: warning, this may be a WIP playground
next steps
- Gather more alpha feedback from specific users; [target completion 11/7/25]
- presentation to larger NS audience [target completion 11/21/25]
- tito tag and deploy on campus secondary fido [target completion 12/5/25]
An overview by picture[s]
existing: private browsing window
new: private browsing window
Details
- alarms and logging no longer in combined view: two tabs required.
- Previous frameset/iframe approach is deprecated in HTML so I am living on borrowed time
- Previous frameset/iframe approach is deprecated in HTML so I am living on borrowed time
- visual changes with CSS styling
- A shift to CSS styling has been made which will allow us to restyle rendering more easily if desired or required
- A basic/preliminary view for mobile exists, you can still render normally by setting your browser to "Desktop mode".
- FIDO header has been re-arranged; some data is now at the footer, new features added
- New header takes up less height, more room for content
- includes a dynamic counter for next refresh on the upper right
- Moved to footer; filtered count details, localhost name and client IP
- There is a dedicated link to the logging view
- The header should be "sticky" at the top of the screen, so if you scroll a large list of alarms, it will stay present. This works most reliably on desktop, mobile browser seem to ignore this if you pinch and zoom
- Settings have been rearranged with some functionality changes.
- You can expand the options pane like so
- the settings pane should be footer sticky in the same way that the header is sticky, with same caveats about behavior on mobile
- settings no longer use cookies; they use sessionStorage [clientside only, similar to cookies] and work like tab level incognito. You should [in theory] be able to open up a bunch of bookmarks in separate tabs [normal ones, not incognito] with different sessionStorage options.
- some settings are now rendered in javascript on the client.
- This has created new opportunities for customizing your behavior while simultaneously reducing server load. If you choose a non default client side rendered option, you can still use the server load optimized "static" view.
- Examples of things now handled client side
- 'Refresh': if you pick a different refresh cadence than default of 30
- the checkbox options under 'hide'.
- pageHeader and pageFooter: not demonstrated in above screenshots, but there has been a request to add an optional header/footer above/below the main FIDO render. These buttons toggle those features if enabled
- sound remains by popular demand, now rendered client side via javascript, although modernly this doesn't work at all on mobile. On desktop, you must bless the site to play background audio. An example for one browser => https://support.mozilla.org/en-US/kb/block-autoplay#w_site-settings
- "JSON", "tiny" have been removed
- json is still supported, just silently, by adding json=1 cgi parameter
- "tiny" is now supported by choosing a custom view under the 'hide' columns. Mess around with the checkboxes under the "hide" row; it should dynamically add/remove columns
- There are several new form buttons
- Reset: restores options to the most recently committed options
- Pause: stops the reload from occurring until Pause is pressed again. You can do this instead of putting an arbitrarily large value in the "Refresh" box. I'm not sure if this is truly useful, but here it is for now.
- Copy Settings; copy to clipboard a URL your current form settings to move settings between tabs/devices.
- Just a side note, not everything is in a form; if you click, for example, on an item or comment correlation, those settings will NOT be saved, as they are not in the form. If this ends up being highly desired, it could be added. My advice if you want to save
- Submit: commits the current options
- Clear Settings: commits default options
- You can expand the options pane like so
- Page reloading has been moved to javascript instead of using meta-refresh.
- The goal for deployment will be to use nonblocking AJAX to update page content, which avoids a full page refresh on update. You don't need to worry about the page refreshing, the screen losing focus of what you were looking at, or our options being overwritten while in progress.
- Hidden in the codebase [developed during alpha testing] is a blocking javascript page reload. These details left here for posterity and internal notes
- In the blocking/reload mode, if you change ANY options pane content, the reload is canceled/suspended until you either Reset, Submit, or Clear Settings. This avoids a downside of the form being inline which would be the form refreshing in the middle of a user making option changes. When the application is in this mode there are several visual indicators warning the user of the status.
- In the blocking/reload mode, if you change ANY options pane content, the reload is canceled/suspended until you either Reset, Submit, or Clear Settings. This avoids a downside of the form being inline which would be the form refreshing in the middle of a user making option changes. When the application is in this mode there are several visual indicators warning the user of the status.
- Hidden in the codebase [developed during alpha testing] is a blocking javascript page reload. These details left here for posterity and internal notes
- The goal for deployment will be to use nonblocking AJAX to update page content, which avoids a full page refresh on update. You don't need to worry about the page refreshing, the screen losing focus of what you were looking at, or our options being overwritten while in progress.
- FIDO no longer refreshes unless your tab/screen is visible
- visible here specifically means the javascript variable document.hidden. It does not [or should not] mean the entire browser window must be maximized, in full view, or even in the foreground. For example you can have a small sliver of the window visible, covered with other windows, and still qualify.
- This does save server load, but the main attraction was interaction with mobile clients that tend to do things like prevent background network or javascript use when asleep.
- If you choose to enable the "sound" feature, refresh will still occur in the background. This is to support a user who is not looking at the screen but is reliant on the sound to notice change of state. Remember, sound doesn't really work on most mobile browsers, so this feature is predominately aimed at the desktop.