Pitch
The raw idea, a use case, or something we’ve seen that motivates us to work on this
The larger problem this addresses is that of the barriers to prototyping in the browser for people without a development background. I believe that rapid web prototyping accelerates learning and reduces risk by making ideas more tangible more quickly in the medium of the web.
The Rapid Response Team has already started to address this through projects like USWDS Boilerplate, Page Templates, and the Screener Prototyping Tool. These are a great start, but as we've started to use them and share them, I've noticed a couple things:
- While no-code content is pretty straightforward using Markdown, editing layout still requires creating and editing HTML templates, which could be a barrier for some.
- They don't follow the designer's mental model that is present in UI design tools of having a symbol or component that you define in one place and use instances of throughout the project while tweaking some of the content or presentation parameters.
These issues increase the learning curve for using a tool like this for rapid prototyping.
The core elements we came up with, presented in a form that’s easy for people to immediately understand
The solution I'm going to explore in this project is building on what we've started by separating out the components into reusable code snippets that you can pull into the content page you're working on (as opposed to building a template that the content feeds into).
These are the goals of this approach:
- Keep components in the content pages. It's easier to understand what's happening on a page when you can see everything right there instead of having to understand the related layout template.
- Keep HTML out of the content pages. By using generic includes to do the heavy lifting, we can hide the code while still making it clear what everything is doing.
Here's an example of what a content page could look like:
# Create your account
<!-- Include a text input component for name. -->
{% include text-input.html label="Name" id="name" type="text" %}
<!-- Include a text input component for email. -->
{% include text-input.html label="Email" id="email" type="email" %}
[Use phone instead of email](#){: .usa-link}
After creating your account, you'll receive a message with a link to set up your username and password.
<!-- Include a button component as a call-to-action for completing the form. -->
{% include button.html label="Create" link="../index.html" %}
This is a combination of markdown and simple include statements that pull in particular components and assign some settings (overrides) that are specific to that use of the component on the page.
This is how that page is rendered:
The idea is that with a few lines of very readable text, anyone can make interactive pages, link them together, and test them in the browser.
How much time we want to spend and how that constrains the solution
I started playing around with this right at the beginning of the year, so I'm going to give myself a six-week cycle to get a usable version I can try out on some projects. I have a talk coming up this summer on the topic, so I want to determine pretty quickly if this is something I can build a half-day workshop around.
Details about the solution worth calling out to avoid problems
While styling is not hugely important for prototyping, the utility classes available with the Design System can be useful for getting what you want on a particular page. The challenge is that adding these settings to the includes can start to muddy them up and make it difficult to scan the content. I've already started experimenting with moving some of the styling to page front matter so it's still on the content page but not mixed in with the include statement. Overall we want to find a balance of keeping the content simple and readable while allowing for some useful customization of components.
Some components like Card or Side navigation that are intended to be used with X number of content items could get tricky and require a different approach than some of the more basic components like Button or Text input. I haven't dug into these yet, but the intent is to stay focused on the principles of "more content, less code" on the page.
I've tried some proofs-of-concept with doing custom layout on a page without HTML, but it does get a bit complex with using Liquid template variables. Still more to experiment with here, but avoid getting too caught up in providing all the possible layout functionality. It may be fine to just offer a few preset options as templates.
Well, "maybe-go." One challenge we still face with this approach is interactivity. While you can do a lot with prototyping by just hiding and showing elements in response to some user input, that is going to require some JavaScript. For this version, I think it's important to explore some basic, generic functions that make the tool versatile enough. So that might include hiding/showing elements and storing/retrieving components using the browser's localstorage functionality. But anything beyond that is going to get too complex for what most of the target audience would be comfortable with (and my comfort level with coding).
The intent with this version is not to recreate the entire Design System, but to make some key components available with this approach to see how well it works for prototyping. Before including a new component, consider the level of use it might get across multiple projects. Try using the toolkit with some projects (or recreating old ones as you go) to see what's needed in a real-world context.