-
Notifications
You must be signed in to change notification settings - Fork 10
Decision: item design direction
Thing | Info |
---|---|
Relevant features | Policy repository item design; potentially other item designs as well |
Date started | 2023-09-22 |
Date finished | |
Decision status | first draft |
Summary of outcome |
We have several directions we could go with how the items are presented:
- Stick with the design we have and make minor changes to expand/extend it to cover new fields. Implement across the site.
- Determine that a more deeply modified design is better to accommodate new fields. Implement across the site.
- Something in between.
If we do decide that major changes are important across the site, we'd have to figure out how to prioritize implementing that against other work, and how to help our users get familiar with it; we'd need evidence to justify it as more important than something else.
- How much change do we make to the design for items?
- How do we apply any changes we do make to different parts of the site?
We have a significant amount of information about what types of items we store and the data we have about them. It's mostly consolidated in this structure and content document.
We have an existing design history of resources. Its most current iteration is used on the combined search page. The same design language is also used in resource sidebars, on the homepage, and on the Resources page. There are variations based on placement and use, but the overall structure is the same.
- Combined search version:
- Homepage version:
- Resource sidebar version:
- Resources page version:
We also have a proposal designed specifically for the fields associated with internal policy repository documents. This design was made with the assumption that it would only apply to internal documents, and that we'd learn through further research how to prioritize the possible fields for each document.
- Version that shows the most fields:
- Version that shows fewer fields, focusing on what we currently have data for:
Main differences the new version introduces:
- Font sizes used (uses different sizes for things, and a generally higher size, although all the sizes are used elsewhere on the site)
- Doesn't have all of the other design variants defined, which are likely important
- Which fields are currently displayed
- Emphasis/order of the fields
- View document button
- Designed with subjects
- Designed to support multiple dates for a document, if relevant
- Designed to connect dates with groups/owners/individuals
- Designed with possibility of states
- Designed without multiple levels of document type
- Designed without summary/teaser
- Designed to expand/collapse regulation and statute citations separately
- How does the usability on the two versions compare?
- What are the implications if both versions exist?
- Do both versions exist? If so, is the inconsistency worth it? Is there a small roadmap for reducing the inconsistency gradually?
- If only one version exists, which one?
- If only the existing version exists, how do we incorporate new fields?
- There's a rough version of that in the Figma:
- If only the new version exists, there are several things that might be on those documents that would need to be integrated
- If we don't decide to only use the existing version, we'd likely have a new design inconsistency for some amount of time.
- We do already have several similar inconsistencies
- We could define a small design consistency roadmap and set of stories. It might involve reducing the variation across the site on: spacing, font sizes, colors (basically our design system status document). The already-existing grid system would help dramatically with this.
- We'll likely have more of this kind of work anyway with needing design changes on the header and sidebar, and the main reading experience if it is affected by the grid.
- If we do decide to only use the existing version, we'll need to revise it a bit.
- Make sure the subject design works well
- If we like the separate "view document" link, we could add it
- We should investigate how much work it is to incorporate that component into the new page design (I'm guessing it's not much extra, but is that accurate?)
- If we decide to only use the new version, we'd have some significant work:
- Make a version of public documents that can go alongside the internal ones
- Make a version of the new design that can go in all the other places
I think in writing this that I've persuaded myself that it might be better to just use the existing design and revise it, if that is viable.
Please note that all pages on this GitHub wiki are draft working documents, not complete or polished.
Our software team puts non-sensitive technical documentation on this wiki to help us maintain a shared understanding of our work, including what we've done and why. As an open source project, this documentation is public in case anything in here is helpful to other teams, including anyone who may be interested in reusing our code for other projects.
For context, see the HHS Open Source Software plan (2016) and CMS Technical Reference Architecture section about Open Source Software, including Business Rule BR-OSS-13: "CMS-Released OSS Code Must Include Documentation Accessible to the Open Source Community".
For CMS staff and contractors: internal documentation on Enterprise Confluence (requires login).
- Federal policy structured data options
- Regulations
- Resources
- Statute
- Citation formats
- Export data
- Site homepage
- Content authoring
- Search
- Timeline
- Not built
- 2021
- Reg content sources
- Default content view
- System last updated behavior
- Paragraph indenting
- Content authoring workflow
- Browser support
- Focus in left nav submenu
- Multiple content views
- Content review workflow
- Wayfinding while reading content
- Display of rules and NPRMs in sidebar
- Empty states for supplemental content
- 2022
- 2023
- 2024
- Medicaid and CHIP regulations user experience
- Initial pilot research outline
- Comparative analysis
- Statute research
- Usability study SOP
- 2021
- 2022
- 2023-2024: 🔒 Dovetail (requires login)
- 🔒 Overview (requires login)
- Authentication and authorization
- Frontend caching
- Validation checklist
- Search
- Security tools
- Tests and linting
- Archive