Skip to content

Decision: Content authoring workflow

Britta edited this page May 24, 2024 · 9 revisions
Thing Info
Relevant features Content view
Date started 2021-05-06
Date finished 2021-05-07
Decision status Good enough for now
Summary of outcome See details below

Background/context

In order to get a decent amount of policy content and other custom content into eRegs and maintain it, we need a reasonable workflow for content authoring even during the pilot stage. We believe it is very important to get at least some supplemental content into the sidebar on the live site soon.

eRegs contains multiple kinds of custom content; our focus here is on right-sidebar supplemental content for reg pages.

Figma prototype we used for testing the right sidebar content.

Folder with supplemental content sheets.

During pilot CMCS stage: Probably no formal review process. So we can focus on authoring for now. (When public, this is going to need content governance.)

The "Sub-Regulatory Guidance" category is likely the most important custom content category for our users, especially the SMDLs, SHOs, and CIBs.

Core questions

What should we design/build for authoring content during our pilot stage?

What we know

User needs

Our archetype user is Rebecca and fellow policy subject matter experts. Right now, our actual users would be Rebecca and any potential policy content contractor, as well as eRegs team members supporting them.

  • Policy subject matter experts are generally familiar with spreadsheets and spreadsheet-style interfaces.
  • Busy with policy work, little time/energy for learning complex technical stuff.

What do people need to do?

We're going to hardcode a specific model of what the data contains.

How do people create a category for subreg content?

How do people create a piece of subreg content (a link to a specific document) for: a section? For a range of sections? (May apply to sections within multiple parts.)

Content gathering process: look for content that applies to a part, and paste in the relevant content document by document. (Also find some content that applies to both that part and other parts, take some notes on that.)

Authoring flow is part-based while filling in the backlog. When in maintenance mode, the workflow will be more document-by-document, but still working within a part-based view.

We can also have an upload script for current spreadsheets now to help fill in the backlog. In the future, we can have a bulk upload method for very strictly formatted spreadsheets.

Things we need to decide + options for them

What does this look like?

What we need to make content show up (especially SMDs, SHOs, CIBs):

  • We need the data model to be represented in the interface, so people can enter data according to it.
    • Always a link
    • Name - the thing in bold that you would tell a person to look for to find it
    • A subtitle or description (sometimes the "title" of the document within the document)
    • A published date
  • Build in an "approved" flag (even though we're not doing a content governance flow).
  • Need to be able to create, update, delete categories and subcategories. (A piece of content can belong to either one.)
  • A category (or subcategory) is made of a title and an optional description.
    • The system should know that there are different presentation formats/templates for different kinds of content.
    • You can select from a list of what type(s) of content the category or subcategory includes.
  • Need to be able to create, update, delete content. Basic double check before deleting content (to prevent accidental clicks).
  • Could be either a static single user or an authed system.

Things you can do as a user:

  • You can choose the part you want to work in - you have a list of parts you can choose from to work in
  • Once you're in a part, show the existing subreg content for that part (so you can edit it, avoid adding redundant content)
  • If you enter a URL that has already been entered as relating to sections in that part, tell the user it already exists in that part (to help prevent duplicates) and suggest editing that existing piece of content

Later:

  • Categories have a link

Later, solving a different problem (not just making content show up):

  • Enable more knowledgeable users to review work of less knowledgeable users - able to print a log of changes for review (when things changed, who changed them, what changed) with a link. For example, "review what I did yesterday - where did I leave off?" (Also a place where you can edit things - a secondary place to edit things.)

Consequences

Next step is wireframing. We'll see what's missing or needs to change.

Overview

Data

Features

Decisions

User research

Usability studies

Design

Development

Clone this wiki locally