-
Notifications
You must be signed in to change notification settings - Fork 10
Decision: Default content view
Thing | Info |
---|---|
Relevant features | Content |
Date started | 2020-10-21 |
Date finished (original) | 2021-03-25 |
Date updated | 2021-07-07 |
Decision status | Done, unless further research makes us change our mind |
Summary of outcome | Subpart default, include option to view whole part |
For the pilot project year: Having even a not-entirely-ideal implementation of part view and the associated resources on the right sidebar is better than not having it at all. To that end, design and dev will be scoped to create the best option that is also relatively easy within our current setup.
For the future: We want to eventually support three views: Part, subpart, and section. However, this is going to require rethinking navigation throughout the site, as changing views should change the right sidebar resources displayed and navigation should always be consistent (i.e. whether you click 433.10 in the Part TOC, header, or left sidebar, you should always get the same view). We also want to bring in other titles eventually, which also requires rethinking the site's structure. It makes sense to think about all of this comprehensively at once, as there are wide-ranging design considerations.
July 26, 2021: further discussion is at Decision: Multiple content views.
What should be the default level of content when reading regs? (Part, subpart, or section)
Other tools:
- Section view is the only choice within classic eRegs (like ATF eRegs) and Cornell LII.
- The most popular view on classic eCFR seems to be part, but you can also find yourself in subpart view or section view - people seem to be a little confused and puzzled when they end up there though.
- Beta eCFR also offers a somewhat dizzying range of options for viewing (part, subpart, section) and ways of navigating around them.
Content:
- Some of the parts in Title 42 are a single topic (like 435 and 438), while others have different subject areas among the subparts (like 433).
Research so far:
- Our domain SME prefers part view for single-topic parts and subpart view for multi-subject parts.
- Only one or two people in our research seemed to prefer section view (and those that preferred it didn't have access to subpart or part view)
- A couple of domain SMEs preferred part view (subpart seemed too short!)
- Many people in our research so far liked the idea of subpart view
Technical details:
- We are able to offer all three or any subset of the three.
- Some supplemental content (subreg guidance) is pretty specific to one section, but often it's general for a subpart (it applies to all sections in the subpart).
- Offering all view options may be confusing.
- Section view is probably good for search engine optimization (SEO) - people often search Google for a citation that includes both part and section, so if a page focuses on a specific section, it may be more likely to rank highly on a search results page.
Options: Part, subpart, or section
Result: We want to do subpart because it seems to meet the needs of most people (and at least tolerable for domain SMEs who preferred the whole part). It also enables more sensible display of supplemental content than either section view (often too specific) or part view (too broad).
Options:
- Yes, both subpart and part
- Yes, all three (section, subpart, part)
Result: Probably for now we'll try displaying all the options.
We need to display supplemental content in a way that makes sense for subparts. This can be a large amount of supplemental content!
We may need to eventually figure out how to better display supplemental content that is very specific to a section.
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