Tabs Design Manual page

Dnpizarro commented 9 years ago

Working from @keelerr outline for the Tabs design manual page, I'll start mocking up the visuals and laying out the content.

Stay posted on page designs....

Dnpizarro commented 9 years ago

@keelerr here is the most recent mock-up I showed during our Working Session. I'll keep working on the design, while you try to shorten some of the bullet points. Also, for the link under the image, should we show the full url or just the label (i.e. Form explainer)? I believe our standard is to show the url so that the user knows where they are going. Also on that note, if we decide to show the url I'm not sure if we need to add the external link minicon...

ui-toolkit_tabs_dm_page_r1_tabs-01_tabs-01

Dnpizarro commented 9 years ago

@keelerr the designs below include all of the content provided in outline document. I made some suggestions to simplify a couple of the headers ( "Tab usage" = "Usage", "1. To show alternate..." = "Use case 1: Show alternate..."). There are still some areas that could use some cutting back on content, but I wanted to show this full view as you edit it down. Also, one thing that I just realized is that I should include some illustrated measurements for how the tabs should be styled (i.e. height of tab, padding, etc)

ui-toolkit_tabs_dm_page_tabs-01

kurzn commented 9 years ago

I just ran across this implementation of tabs on Paying for College: expandables as tabbed interaction. Can we add a comment in the tabs rules about NOT doing this, please?

http://www.consumerfinance.gov/paying-for-college/choose-a-student-loan/#o1

benguhin commented 9 years ago

@kurzn I totally agree. That said, we could have very long pages if we try to detail everything that people should not do :)

I think the rules for the expandable sections pattern will help make sure that that interaction doesn't happen again

benguhin commented 9 years ago

Similar to @Scotchester's comment about tooltips, I don't think we should standardize the use of minicons instead of text for the name of each tab. Iconography and hover states are not clear enough indicators of what's underneath the tab.

Dnpizarro commented 9 years ago

Latest update for Friday Presentation

ui-toolkit_tabs_dm_page_r2_tabs

nataliafitzgerald commented 9 years ago

@Dnpizarro @keelerr - I don't think that I agree with including the minicon tabs as a standard. Also, the OaH tabs are taller than the standard you have set forth. So, for the image I would rather see tabs that are following the guidelines you are proposing. If you'd like to chat through this I'm available.

Dnpizarro commented 9 years ago

Update 9/14

@nataliafitzgerald sorry for not updating this issue sooner, but we are definitely not including the minicon tab as a standard. In the mockup below, under the section "Use" I plan on showing live versions of the tabs. I included some lorem ipsum to fill in the example. Also, I included some questions in the mockup, particularly the one about whether we should consider numbering the tabs in the "Navigate a process" example.

ui-toolkit_tabs_dm_page_r3_tabs

nataliafitzgerald commented 9 years ago

It looks like we are repeating the content between the introduction and the paragraph under "Use." The text seems to be more applicable to the "Use" section.
Also, you mention that we would "rarely" use tabs to navigate a process. The explanation is pretty complicated. Is there really an essential need for this tab usage?
Wording edit: If we are thinking of the word "Use" as the first word in the sentence, then the titles for the two use cases would be: "1. To show alternate views of the same information" and "2. To navigate through a process" OR you can remove the word "To" from both.
It would be useful to include examples of use cases for each of the tab types. These don't have to be visualized they could just be mentioned in the text.
The black minicon numbers feel too heavy (and distracts from the tab header). And I wonder whether including them would preclude a designer from instead doing something like "Step 1" "Step 2"
It looks like there is a typo in the first bullet under "Technical considerations"
For the layout, make sure to follow the current standard for the Design Manual pages. The text under "Use" should be Georgia and the intro text should be larger.

keelerr commented 9 years ago

@nataliafitzgerald and @Dnpizarro, I've tried to respond to your points:

I think the introductory sentence should stay in the introduction. I don't think we need any more preamble before jumping into the use case. (And this is what's included in my current draft of the content.)
I think using tabs to step users through a process is a valid use case. This is why I've included it. To help me clarify and improve this section, can you tell me what seems complicated about it?
Thanks for the wording suggestion. I like including "to" in each use case. So, it would be "To show alternate views of the same information" and "To navigate through a process."
I think it would be more helpful to include examples rather than the generic "tab 1" and "tab 2." Is there a reason we've moved away from the CFPB examples? I think it provides helpful context. And, the example link you're showing under "To show alternate views..." is really to illustrate "To navigate through a process". This might help clarify @nataliafitzgerald's concern about the 2nd use case. If they didn't look identical, it might be easier to distinguish why there are 2 use cases.
I agree the black is heavy, but I think including "Step 1" and "Step 2" may also become problematic. With tight character counts, this may not leave enough space to include a descriptive word/phrase explaining what the step is! @Dnpizarro, I think it's helpful to include numbering. I don't think we have to mandate it be included, but I'd love the example to show some numbering...
Do we just want to eliminate this section all together? (It should read: Use name anchors. Consider...)

nataliafitzgerald commented 9 years ago

@Dnpizarro - If you include numbers you can look at a different coloring for the minicon circle or use numbers without circles.

Dnpizarro commented 8 years ago

I started coding the DM page, see below. I will post screenshots of the examples tomorrow. @keelerr not sure were we landed on the "Technical considerations," did we still want to include that? Also, the links connecting to the code still need to be corrected. @Scotchester would you be able to provide those links for me?

http://dnpizarro.github.io/design-manual/ui-toolkit/tabs.html

Dnpizarro commented 8 years ago

@keelerr and @nataliafitzgerald what are your thoughts on having the example go full width in the main content area after the use case explanation. The bullet points would go after the example. Additionally, @keelerr and I discussed the possibility of defining the bottom of the tab with a rule line. For clarity, the rule just above the bullets is the tab's bottom rule line. An alternate option would be to just switch the example with the bullets. Let me know your thoughts.

FYI, I cropped it intentionally to highlight the use case examples.

ui-toolkit_tabs_dm_page_r4_tabs

keelerr commented 8 years ago

@Dnpizarro, in answer to your questions:

I like the examples going the width of the content area. The only problem is that right now the 2 use cases look identical—other than the use of numbers. Since the second use case is meant to be used for navigation, would a "screenshot" of tabs spanning the width of the page be more helpful? I don't think this example really captures the use case. And, could we pair it with a link to the OAH journey to show people a live example?
I think it might be helpful to switch the bullets with the example. This way, all the text would be together. If this creates weird white spaces before the example and looks weird, than I leave it up to you and @nataliafitzgerald.
As for technical considerations, I think the one that's most helpful/ worth keeping is the one about named anchors.

nataliafitzgerald commented 8 years ago

In terms of "Alternate views of the same information" I can think of a lot of examples of tabs used to show multiple views in tables or charts. Would tables or charts be a good use case for this DM issue or are you looking for a more text based example.

Here are two examples from Fitbit:

Weight over time	Steps over time

KimberlyMunoz commented 8 years ago

Something I just discovered this week is that WAI-ARIA outlines the intended interactions for things like tabs. It's worth reading and perhaps linking to under the technical considerations.

https://www.w3.org/TR/wai-aria-practices-1.1/#tabpanel

We should be programming keyboard interactions to have screenreader users navigate according to the spec.

caheberer commented 7 years ago

The recommendation from this is to not use tabs...EVER. So should we even include tabs in the Design Manual?

caheberer commented 7 years ago

@keelerr will take a look at the language to reaffirm that we shouldn't use tabs except in extreme cases.

cfpb / design-manual

Tabs Design Manual page #352

Latest update for Friday Presentation

Update 9/14