Write a pattern for Right Rail Standardization / Content

[cohnjesse]

Feature Request

• [x] I’ve searched for any related issues and avoided creating a duplicate issue.

Do you have a suggestion for a new component or utility?

There is a 'Right Rail" component that is used in both the VA Disability Rating page as well as the Check your claim or appeal status page. Ther right rail is the content area on the right side of the page that houses a list of three blocks of information with a heading, a horizontal rule, then some content. The pages using the right rails are both listed here ( from staging ) -

The right rail in the above screenshots is being used to house additional information that is supplemental to the main content on the page. I would think part of our design process needs to be determining -

1. What are the cases in which we use this right rail as well as what are the cases in which we DO NOT use this right rail?
2. In order to make this a reusable component we need to come up with a few pre-defined layouts that the content blocks inside the right rail can take, what are those pre-defined layouts?
3. What specific types of content can and should be housed inside the right hand rail. What we have on these pages above may serve as a model but don't necessarily need to be the main examples?
4. How many individual content blocks should be allowed in the right rail component?

[jaredcunha-usds]

Not sure if this is what you mean by pre-defined layouts, but we do have some layout templates for a page grid: https://design.va.gov/layout/page-templates#two-columns-content-on-left

These are not all-encompassing, but there are some basic snippets for page layout grids.

Just a minor terminology nitpick, the right rail isn't necessarily a component, but a place in the design grid where some content, links, or other components may live.

[cohnjesse]

@jaredcunha-usds I totally understand that we may be getting into a grey area with making this a component or calling it a component, however I would say this is being used now on two pages and in both of those pages it had to be created as a React component and had to be hard coded from scratch. Since it is being used on these two pages it stands to reason we will use it on more so it makes sense to nip it in the bud early. Making this a component inside the design system allows us to not have to build from scratch each time as well as allows us a uniformed experience across the different places this is used.

It also allows designers to understand when this is a good solution to use as well a not a good solution to use. When we went through the process of designing the disability rating page there was a lot of back and forth between designers because there are no clear delineations of when to use a right side rail and when not to. Making this a component in the design system would allow us to alleviate that to some extent.

As far as the layouts, I was thinking more along the lines of templates for the content inside the right rail You can see in this picture -

We have three distinct blocks of content, the first has the header, then a horizontal rule, then a paragraph with a link after the paragraph. The second block of content has a header, a horizontal rule, then a paragraph. The third block of content has a header, a horizontal rule, then a paragraph with a link inside the paragraph. If we want to make this a reusable component it makes sense for us to define the layouts of these content blocks so that this can be much easier to configure from both a design and a development standpoint. @ncksllvn

[jaredcunha-usds]

I might have misunderstood what you meant by right rail component then. When I think of a right rail, I think of the entire containing element that creates the layout for the right rail. You're asking about the 3 items in the red boxes above, right? And each of those being separate instances of the suggested component?

[cohnjesse]

@jaredcunha-usds Really I mean both, the right rail is the entire containing element that creates the layout but if we want to make that container reusable we also need to think about the content that will go inside it and make those content blocks reusable as well. If we only make the containing element reusable that means we still have to hardcode the blocks inside the container from scratch each time and sort of defeats the purpose.

[jaredcunha-usds]

I wasn't talking about making the containing element reusable as a component. I don't think that the div that creates the layout should be a component or part of a component. It adjusts to different breakpoints and would have some dependencies that are not contained within it, and it could be a bit narrower on pages that have 3 columns of content.

I just want to clarify that the component you are requesting includes the heading, the rule, and the content; and that it does not include the layout div.

I would defer to @KevinMHoffmanUSDS or @rtwell on how to handle this question. I'm trying to make sure I understand the scope so I can assist them with any decision-making if they needed.

[cohnjesse]

@jaredcunha-usds I would disagree that the div that contains the blocks should not be part of the component. Like our current sidenav component, the component includes everything you need to create a sidebar nav, not only the containing div but also defines the look and behavior of the menu items inside the container. It also includes when it is a good idea to use a sidebar nav as well as when not to use a sidebar nav.

Granted the sidenav is a layout, not a component per se, but if we treat the sidebar nav as a component ( as it is inside the components for the design system ) I think it may serve as a good example of what we are aiming to achieve.

As far as the content block layouts for the right rail I am thinking we need to come up with those as well. In the sidebar nav component it would be analogous to the guidelines we have for keeping sidebar nav titles short as well as not having too many list items nested too deeply inside a hierarchy. This type of guidance defines a suggested layout for the sidebar nav itself and the links inside it, or maybe "best practices", that allow the designer and developer to get the best end result out of the sidebar nav. The content in the blocks for the right rail is decidedly more complicated than the links in a sidebar nav so with the content blocks for the right rail I feel we need to go further than coming up with best practices and actually create pre-defined layouts for those content blocks. This will make it much easier to have the best result possible from the right rail. It also allows us a developers to create these blocks as reusable so nothing needs to be hardcoded when using the right rail component. Does that make sense?

[cohnjesse]

Maybe it would be helpful for me to create a prototype of what I am thinking and submit that as well?

[rtwell]

@cohnjesse i love this thinking regarding the right rail! I would split one hair though and suggest that this approach fits the design system as a pattern more than it is a component. It would be great to provide guidance that designers can use to identify whether or not they need to utilize this particular pattern.

A great example we could pick apart is the "Get help" snippet. Sometimes, it's appropriate in the right rail, but sometimes it works better at the bottom of the page (I believe we see this most commonly at the bottom of form pages, so users always have that info as they fill out the form).

[cohnjesse]

@rtwell I totally agree, calling it a pattern is most likely a better name for it. We will build it as a reusable thing but I think calling it a pattern is better terminology. Is there anything I can do to help shepard this along?

[rtwell]

first thing i would do @cohnjesse is audit how it is currently used throughout VA.gov, including within applications/tools. I used Mural.ly for the audit i did on all of our cards, and it seemed to work well. once we have that, we can talk about how it's used, what the components/patterns are, and then start to form some design guardrails and statutes.

[jaredcunha-usds]

@cohnjesse The sidenav component is a standalone component, as it is in the U.S Web Design System. I designed and developed design.va.gov, as well as wrote much of its content. I wanted to present the sidenav in a context because on its own, it expands to its container, which is not a great depiction. The container is not part of the component. The container is in the snippet because I haven't quite figured out a way to handle the includes and responsive examples in Jekyll without creating duplicate HTML: a separate file for both UI example and the snippet. Most of the UI examples and HTML snippets pull from the same file, so if I make an update to the display, the snippet is uploaded. The snippet has comments that show where the component HTML begins and ends. I broke down and created separate files to isolate the HTML snippet on most of the pages, but I must have missed the sidenav page. I think I'll go ahead and make that update because I think it is misleading the way it is.

Sorry for that long, exhaustive explanation.

I agree with @rtwell also that this can be documented as a pattern, and that we can provide HTML snippets in that section to ensure other developers can build similar features while maintaining consistency across the VA.gov platform. As he also pointed, and part of where I was trying to get at, was that by not including layout containers as part of the scope allows for wider usage of what you are trying to present.

If you want to display things within a context, or in multiple contexts using the responsive previews to show how things are presented at different screen sizes, I think that goes a long way and I strongly encourage it.

[KevinMHoffmanUSDS]

@cohnjesse Here's an example of the MURAL which @rtwell was referring to.

https://app.mural.co/t/departmentofveteransaffairs9999/m/departmentofveteransaffairs9999/1574086026453/e8ba87ed25507f73b7c0b5c40267a3ae95a20b09

Also, I think right rail standardization as a goal is going to vary greatly between applications and content pages, and then by content page type, as a pattern (e.g. a "hub landing" right rail has a very specific use, as does eligibility pages, etc.).

Once we have a good audit of what's out there, we can start to see if there's opportunity for more standardization and reuse. Thanks!

[cohnjesse]

@KevinMHoffmanUSDS @jaredcunha-usds @rtwell Sounds good, let me know if there is anything I can do to help.

@jaredcunha-usds Thank you for the explanation, that helps tremendously.

[KevinMHoffmanUSDS]

@cohnjesse Good morning, and thank for doing a wonderful job of keeping this one moving over the last several (crazy!) months!

We spent the entirety of a recent Design System Council (August 14, 2020) meeting on this topic, and we came to a few conclusions:

As per your original post,

What are the cases in which we use this right rail as well as what are the cases in which we DO NOT use this right rail?

What specific types of content can and should be housed inside the right hand rail. What we have on these pages above may serve as a model but don't necessarily need to be the main examples?

How many individual content blocks should be allowed in the right rail component?

@sshein and @rtwell are going to be working together to develop set of specific use cases based on tool types, developing content guidelines (content types and content length) for the following unique patterns of right rail usage:

• listing tools (e.g. disability ratings)
• forms
• search tools (e.g. GI Bill Comparison Tool)
• calculators

We want to focus this effort on reducing the amount of variation in the way we use the right rail, because based on mobile testing that we've conducted over this month, we've found that users are successful in finding right rail content on mobile when it sits at the bottom of the page, and are considering deprecating the right rail from the design entirely (in the long term.)

Per your other suggestion:

In order to make this a reusable component we need to come up with a few pre-defined layouts

For the reasons above, VA's decision is that we are not going to create a reusable REACT component for the right rail. However, as we assess the current right rail usage and seek to simplify and provide better guidelines, we may provide new HTML/CSS code and content guidelines for the short term.

[caw310]

DST needs to create a pattern for Right Rail standardization. After we get template in, we will work on this.

[sshein]

I thought we had completely deprecated the right rail? Or are you referring to the authenticated info list pattern?

[humancompanion-usds]

@sshein - The last update we have is that you and Ryan were going to go off and develop some specific use cases: https://github.com/department-of-veterans-affairs/vets-design-system-documentation/issues/160#issuecomment-679126217 If you say that right rail is no longer a thing then we can close this.

It seems like it is in use in certain templates like Hub, for example: https://design.va.gov/patterns/templates/hub My thought would be to cover right rail usage in future templates that we would add.

[sshein]

ah, interesting. So yeah I think this ticket veered from its original intent. The right rail has been deprecated so we don't have to worry about that. Based on this ticket I did create the authenticated info list pattern which is in experimental. There were a couple other patterns suggested (like tool pattern and search pattern). I think there are some search pattern work in progress tickets that I could dig up. But yeah we can close this one.

[bkjohnson]

Edit: I see now that Matt pointed out something similar in his comment above :upside_down_face:

---

The right rail has been deprecated

Does that mean that this will be going away?

I realize that it isn't the same as the earlier disability rating examples, but it has names such as "right rail" and "hub rail" associated with it.

[sshein]

ooh great question - no, that's not what I was referring to when I said we should no longer have people use the "right rail" I was referring specifically to the examples where people have questions and answers on the right, as in the disability rating example. In that example the questions and answers are important and become kind of "invisible" especially on mobile.

That "hub rail" I think is a fairly new design that Ryan worked on with Jenn Lee and maybe Beth/Danielle. Those things are more "footer type" content so maybe more ok in a right rail / at the bottom on mobile? So yes this is a bit nuanced and interesting.

[KevinMHoffmanUSDS]

DSC recommendation: confirm that the right rail pattern has been deprecated. If so, close this ticket.

[humancompanion-usds]

@sshein says this was deprecated so I'm closing.