Meeting Date
December 9, 2025 @ 11:00 AM Central Time
Topics
Lance Campbell from Web Services is exploring a new prototype layout for the Webtools portal and would appreciate feedback on the overall structure. The design uses two side-by-side panels: the left panel lists all available applications, and the right panel displays the form fields and content for the selected application.
Within the right-hand panel, the layout is organized from top to bottom as follows:
- Application name / breadcrumb: When editing, this may include the specific item being modified.
- Tabs to navigate within the current tool.
- Action buttons (Save, Back/Cancel, View, etc.).
- Message space for informational, validation, or warning messages.
- Form fields and content for the selected application and tab.
- Footer, fixed across the bottom of the screen.
The prototype HTML page is a single-page snapshot, intended to begin a discussion about layout and usability. Please ignore the sample form fields beneath the action buttons—they’re present only to test scrolling and the sticky header. In the final implementation, the page will refresh whenever the user selects a navigation item, tab, or action button.
We welcome your feedback and thoughts on this proposed new interface!
Meeting Notes
- Focusing on framework/structure - minimal styling in demo
- Goals for layout: 2 main boxes/sections
- Left: listing all applications in Webtools
- Right: main content area
- Breadcrumbs
- Top-level tabs
- Sub-tabs
- Action buttons
- Content area
- Dena: considering different users’ views of content based on eyesight/screen size
- Lance’s screen shows entire content area w/10 labels + 10 inputs, with lots of extra whitespace at bottom and right
- Dena’s screen shows 3 labels + 2 inputs with content pretty scrunched together
- Dena: is it possible to reduce number of items in top-level nav?
- Dena: would be nice to be able to collapse tabs area, like Word ribbon & Google Docs toolbar
- Mark: also noticed that 400% zoom @ 2048x1280 renders the site totally unusable. The footer takes up all the lower space, the header/file menu takes up all the upper space, and I can’t get into the form fields themselves.
- Toolkit could help
- E.g. LLM & Graduate Admissions page demonstrates collapsible left-hand nav
- Bryan: that’s a WordPress-specific feature; could consider adding to main web component if broadly useful
- Web Toolkit Builder v3 has many pre-built components that might be useful
- Bryan: may consider using Section Nav component from Toolkit Builder v3
- SkipTo.js
- In use on Brand Guidelines website
- Mark McCarthy: one of very few “more accessibility in one line of code” tools that’s legit 🤣
- Dena: could main area scroll with rest of page?
- Lance: uses sticky header so buttons are always available/visible. Perhaps buttons could stick to top when scrolling but other elements scroll off screen?
- Dena: back to top link could help users get back to top (see Back to Top web component); and/or perhaps floating action buttons
- Beth Sheehan: usability rather than accessibility: lots of menus on page. May not be necessary to show links to all the other webtools on every page. Left-hand menu usually indicates links relevant to current page rather than whole site. Maybe consider a single link back to all the webtools rather than menu showing all of them?
- Bryan: too much info can also be an accessibility issue for users with ADHD
- Based on discussion, some users use a single tool at a time; others regularly bounce between 2-3; need to find a way to make it work for both user types
- Discussed including menu of all webtools hidden by default (e.g. hamburger menu). Maybe it could remember a user's choice so users can choose whether to have it visible or collapsed as they work.
- Lance: considering adding context-relevant links on homepage (e.g. link to Reports tab of recently sent Email+ email)
- Dena: when adding dynamic sections like that, it's important to keep the organizational structure consistent (e.g. have a specific section for those context-relevant links, but also keep static listing for ease of navigation via muscle memory)
- Bryan: perhaps the tool’s primary navigation menu could display along the left-hand side instead of the list of all Webtools tools. Perhaps the list of other tools could be a drop-down list
- Lance: perhaps action buttons could float at top to right of tool title + breadcrumbs
- Dena: might be helpful to run A/B tests
- Dan: navigating via forward/back browser buttons leads to 'Confirm Form Resubmission' warning. Perhaps 'Post/Redirect/Get' request pattern could help avoid that?
- Lance: jumping between tools uses GET w/warning about losing work; all other links are POST
- Bryan: Nielsen Norman Group (NNG) recommends to build forms where the back button is available
- Headings:
- Tool title is H1
- Top-level navigation menus tend to use a visually hidden <H2>
- Bryan: Tab pattern, Tab Control
- Mark McCarthy: the <tablist> itself might/could be aria-labelledby a preceding <h#> though, too. (which would help if people are jumping through interactive items only.)
- Bryan: WIGG starting to look at how applications are built too; application group getting folded into WIGG; looking at ways to update web components for web app style use