Deliver refined IA

[kathrynmcelroy]

• [x] through card sort and user interviews
• [x] and other methods

[kathrynmcelroy]

• [x] test IA sketches with different methods

[kathrynmcelroy]

Link to the IA research I've been doing and next steps for it: https://releaseblueprints.ibm.com/display/WDA/Updated+Information+Architecture

[Snugug]

Please move this into our public Wiki here from Release Blueprints. If it has confidential information, please anonymize it first. Thanks!

[kathrynmcelroy]

[Snugug]

Question: I see that things are color coded, but I don't see a key for the color coding. Can you provide one?

As for the different IAs, I prefer the Design/Code/Both and Scale and Scope approaches over the disciplines one, leaning most towards Nick. The one exception to his flow is that we won't be providing a specific grid, but rather guidelines on how to determine layout and layouts for specific types of content, following content out layouts. Generally speaking, some of what we're doing (or going to be doing, layouts for instance) is new when it comes to design languages and pattern libraries (focusing not only on how things look, but how they work, how they respond, how they enhance, which ones fit together to form UX flows, etc…) so we should keep in mind that some of what we're providing our users will have never seen/considered before. It is also on the roadmap (eventually) to provide more than HTML patterns, so we shouldn't tie ourselves too tightly to only HTML in the long run.

Additionally, I noticed that everyone talked about not using the word "patterns" because it's too vague. Let me codify the definitions we're using, just so there's no ambiguity amongst ourselves and when we discuss them.

• Pattern - A reusable piece that makes up an interface.
• Base Elements - Elements whose name is identical to the item used to create it. In HTML, this would be a tag name. For instance, a checkbox styled to look like a checkbox and referred to as a checkbox would be a base element, but a checkbox styled to look like an on/off toggle and referred to as a toggle would not be (it would be a component).
• Component - A way to view and/or interaction with content. Can be made up of one or more base elements (or multiple components). Base elements in components do not necessarily need to be visually identical to their out-of-context base elements, but should try and use their styling where possible. Components can and should control how they are laid out internally based on their own size. The Avatar would be a component, as would messaging, toggles, navigation bars, etc…
• Layout - A way to group components in relation to each other and in relation to the viewable area. Layouts should be based on the type of content being displayed and should respond and change based on the available viewable area. There may be more than one layout used to make up a full page. Layouts cannot be nested inside of each other.

Base elements, components, and layouts are all types of patterns. Color, typography, and animation, on the other hand, are not patterns but rather style choices that affect the display of patterns. Icons can be both patterns (components) and style choices.

[kathrynmcelroy]

Research posted here: https://github.com/IBM-Watson/design-library/wiki/Information-Architecture-for-the-final-site

[kathrynmcelroy]

The color coding was for my personal use, so I could more easily see how the organizations differed. Here is the original organization that I used for color-coding:

• Pink is high-level Values
• Blue is Design Principles
• Yellow are the really Watson-centric pieces
• Orange are the in-between Guidelines
• Green are the HTML elements that were in the original IA work done in RBP
• Red (seen in Nick's) are parts that he would like in addition

For the grid, I think the layout patterns will fulfill this desire. We also saw in Jessica's visual designer interviews that our designers don't currently have a unified way of developing a grid or layout, so we need to provide some sort of guidance for that (like you mentioned above).

As for the word "Patterns", I've added some of the specific quotes I heard about the term. It does not resonate with a couple of the devs I've talked to, and it has a broader meaning for our other target user, the visual designers. Although we can create our own definitions for these terms, if it doesn't intuitively connect with our user, then the definition will not work. So we need to either consider a different word choice or have specific "on-boarding" for that term for our users.

[kathrynmcelroy]

Images from the mini-workshop. I will be posting the full playback of the workshop to the Wiki later this afternoon.

[kathrynmcelroy]

[kathrynmcelroy]

Updated Wiki page with IA Workshop process and results. https://github.com/IBM-Watson/design-library/wiki/Information-Architecture-for-the-final-site

[kathrynmcelroy]

I made a clickable prototype of the initial IA hosted here: http://pages.design.ibm.com/kemcelroy/watson-design-library-wireframe/master/ui_patterns.html

I will be testing user flows through this in the next few hours and on Monday morning.

[kathrynmcelroy]

Initial idea for the responsive navigation - original navigation on the left, and how it will alter for smaller screens on the right

[Snugug]

A couple of things to keep in mind when designing responsive navigation, in case you hadn't already:

1. We should do our best not to hide or remove navigation at smaller screen sizes; consistent navigation reduces cognitive load on our users. If we have too many items in our navigation, maybe we re-consider if all of them are needed in general. In fact, it may be a good exercise to not think about the largest screen size navigation at all and only focus on small screen navigation, building the larger one up from the constraints built in the small version.
2. Having navigation update itself while we scroll (highlighting the section, for instance) is neat looking and may provide a visual aid to where they are in a site, but very resource intensive (meaning bad for on-page performance). Same goes for sticky-ing things to the top of the screen on scroll. Really, any change that is dependent upon scroll position is very resource intensive and we should try and avoid as much as we can. This holds true for parallax as well.
3. Some thing are easier to animate than others. Having things slide, for instance, is much easier than animating the height of something from 0 to X height.
4. The large screen section almost looks like a single page view. Single page views can suffer from infinite scroll syndrome on smaller screens where the is simply no end in sight for the bottom of the page. Because we are serving a single HTML request to everyone, we should consider what our content will look like on small screens first, then expand up to larger screens instead of the other way around.

[kathrynmcelroy]

@Snugug Re: 1 & 2, I would love if you could share some examples of websites with long navigation streams (API documentation, retail websites, etc) that handle this well. I have not found any ideal ones and very few good ones, so if we could share resources that would be really helpful.

And what is 3 referencing?

[Snugug]

Number 3 was a general statement when it comes to designing, say, a slide out menu.

As for 1 & 2, there aren't good examples, in fact I'd argue that long navigation streams is an outdated UX pattern (press spacebar to get through the splash screen and preloader). Basically, my recommendation from that presentation is Your Org Structure Is Not Your Information Architecture, or more specifically, not everything that is available on your site needs a top level navigation item if what it contains can be made obvious. What winds up happening with long nav items is people fall in to the Paradox of Choice. Instead, we should pair down our main nav to whatever our main concepts are and have (maybe) first level subnavigation once you get to that section.

Take North as an example. I've only got primary nav items for each section. When clicked, you are taken to that section and the second level nav items for that section become available. There are tertiary navigation items in there too, but they are not presented because we start to get too far into the "org structure" of North.

[kathrynmcelroy]

Testing completed with updated, coded prototype: http://pages.design.ibm.com/kemcelroy/menu-test/master/

Feedback written here: https://github.com/IBM-Watson/design-library/wiki/Information-Architecture-for-the-final-site

No major issues with user testing the IA, ready to move into wireframes, visual design, and coding.

[Snugug]

@kathrynmcelroy In the coded prototype you have, for the patterns, I see that you have text and forms, etc… under each header. What are these? Taxonomy that patterns will be grouped in to? We currently don't have any form of taxonomy for our patterns (we can have) but if we're going to introduce that, we're going to need a system in order to categorize them. What happens when we have more than 2 categories? What happens (as we've discussed) when we want to present components/layouts based on UX flows and not just categories?

[kathrynmcelroy]

I realized that I have not put the final IA map anywhere on here. This is the final IA:

@Snugug We will need a taxonomy for the patterns as they grow. As of right now, I do not have enough information about what patterns will be in "Elements", "Components", and "Layouts" to propose a taxonomy. I had enough of an idea of Elements to do a quick test for navigation purposes, but am not proposing any sub-sections at this point.

I think we should still have the meeting today to discuss and finalize as a group.

[Snugug]

Yes, let's talk more. Especially as some items in "elements" aren't actually elements as we have them defined, and we are going to run in to issues with displaying taxonomy under each heading for UI patterns, starting immediately and growing (specifically, items with the same taxonomy may exist under multiple items, like right now we have form items in both elements and components)

[kathrynmcelroy]

Updated Site Map to show how we're setting up the pages.

[bobbinrobyn]

@kathrynmcelroy I'm thinking through the header for these pages, and I'd love your thoughts. Here are my best options:

Principles

• Overview
  -- Getting Started
  -- Values
  -- Design Principles
  -- Personality (coming soon)

Vision

• Principles
  -- Getting Started
  -- Values
  -- Design Principles
  -- Personality (coming soon)

[kathrynmcelroy]

In the future, do we see any additional internal sections if we went with "Vision"?

My initial instinct is to go with Principles --> Overview, because Principles tested very well for understanding, and I fear that putting it within Vision might not be as intuitive.

Also, "Getting Started" has specific connotations to the developer community, involving installation and starter files. I think we should stick with "Introduction", but we can test both if we want.

[joshkimmell]

"Vision" is too broad and really should be internal only. I think "Getting Started" is fine if we specify "Getting Started with the Design Guide"

[ryanbrownhill]

This issue needs more work on the pattern side of the IA before close.

[joshkimmell]

Waiting on Content Model of UI Patterns

[Snugug]

Unblocking now that CMs are delivered

[Snugug]

URL structure part of IA defined in #152. Looking for page IA now.

[Snugug]

What's the progress on this?

[ryanbrownhill]

I believe the IA for the UI Patterns section still needs to be refined. @kathrynmcelroy (she is out the rest of the week FYI)

[Snugug]

If that's all that's missing, I'm going to close this and spin that out to #172. Is that all that's missing everyone?

[ryanbrownhill]

:+1: on my end

[britanyponvelle]

:+1:

[bobbinrobyn]

All right, y'all – this is the result of the convo that @joshkimmell and @Snugug and I just had.

1. The "Introduction" page will become a true homepage, and it will not live in the "Principles" section. It will be the page you see when you go to www.watsondesignguide.com or www.watsondesignguide.com/home (insert the appropriate domain name).
2. The main nav links remain the same – Principles, Guidelines, and UI Patterns.
3. The side nav for Principles will change. Each principle will get its own page. Like this:

Principles -Introduce Cognitive -Inform Interactions -Offer Control

[bobbinrobyn]

Can I get some :+1: from @IBM-Watson/design-acceleration? I think this mainly affects Eva and Sam (whoever is doing the architecting).

[bobbinrobyn]

Also, @ryanbrownhill, @britanyponvelle, and I decided on a rule for structuring content in the side nav.

If there is only one category of sub-pages under the main nav link, no headers are necessary in the side nav. For example:

Main nav link: Principles Side nav:

• Introduce Cognitive
• Inform Interactions
• Offer Control

If there is more than one category of sub-pages under the main nav link, headers are necessary in the side nav. For example:

Main nav link: Guidelines Side nav:

Style

• Accessibility
• Color
• Grids

Interaction

• Animation
• Signature Patterns

Branding

• Brand Attributes
• Wordmark

[bobbinrobyn]

As soon as we figure out what's happening with the brand attributes (#159 & #160), we can review and close this issue.

[bobbinrobyn]

:+1: Ready to close

[ryanbrownhill]

:+1: ready to close! resolved by the decision made via #152

[bobbinrobyn]

Final IA:

/Home

/Principles --> goes to /Principles/IntroduceCognitive /Principles/IntroduceCognitive /Principles/InformInteractions /Principles/OfferControl

/Guidelines --> goes to /Guidelines/Style/Accessibility

/Guidelines/Style/ --> goes to /Guidelines/Style/Accessibility /Guidelines/Style/Accessibility /Guidelines/Style/Color /Guidelines/Style/Grids /Guidelines/Style/Typography

/Guidelines/Interaction --> goes to /Guidelines/Interaction/Animation /Guidelines/Interaction/Animation /Guidelines/Interaction/SignaturePatterns /Guidelines/Interaction/SignaturePatterns/Avatar

/Guidelines/Branding --> goes to /Guidelines/Branding/Wordmark /Guidelines/Branding/Wordmark

/UIPatterns --> Goes to /UIPatterns/Documentation/GettingStarted

/UIPatterns/Documentation --> goes to /UIPatterns/Documentation/GettingStarted /UIPatterns/Documentation/GettingStarted /UIPatterns/Documentation/Settings /UIPatterns/Documentation/Animation /UIPatterns/Documentation/JavascriptStandards

/UIPatterns/Patterns --> goes to /UIPatterns/Patterns/Elements /UIPatterns/Patterns/Elements

/UIPatterns/Patterns/Elements/anchorlink /UIPatterns/Patterns/Elements/blockquote /UIPatterns/Patterns/Elements/body /UIPatterns/Patterns/Elements/button [...] /UIPatterns/Patterns/Components /UIPatterns/Patterns/Layouts

[britanyponvelle]

:+1: