762255 - [Kitsune/SUMO] site visual design

Status: RESOLVED FIXED

(Marketing :: Design, task)

Description

[Bryan Clark (DevTools PM) [:clarkbw]]

Hey, I emailed you guys a couple weeks ago just to give a heads up about this.  The SUMO/Kitsune site is moving through it's paper prototype phases toward implementation.

I think we're looking at a visual design that uses the One Mozilla layout, I'm not sure that there will be too much that differs from the existing One Mozilla work that we've already been working on.  However I'd like to have you look it over and give some guidance.

Bram or David can you to point to the latest wireframe mockups for the new site?

John/Sean, what do you think is a reasonable time frame for this kind of work?

Thanks!

Comment 1

[John Slater]

Hey Bryan. Thanks for getting in touch...I'd just been having some conversations about the possibility of moving SUMO towards the One Mozilla style, so that sounds great.

Re: timing, what kind of work do you have in mind for us? From comment #0 I can't quite tell if it's a matter of doing new work from scratch or reviewing mockups that have been created by someone else.

Either way, we're pretty solidly in all hands on deck mode for the next 3 weeks or so leading up to the Firefox for Android launch, so starting a big new project in that timeframe will be tough. Things should open up after that...this is definitely something we want to help with.

Comment 2

[Bram Pitoyo [:bram]]

The latest wireframe mockups is located at:
http://people.mozilla.com/~bpitoyo/sumo/sumo-wireframes.pdf

And, in your interest, the mobile wireframe mockups:
http://people.mozilla.com/~bpitoyo/sumo/sumo-wireframes-mobile.pdf

I  will keep making updates to the files, even though at this point we are mostly tweaking words and ordering of various page elements, not layouts.

One design note:
The “Hot Topics” area on the Top page is meant to be located more prominently. We put it on the bottom for testing, because we want people to go through our wireframes rather than selecting Hot Topics as a solution over and over again.

Comment 3

[John Slater]

Thanks Bram. 

Bryan, in your email I think you had mentioned working on this in July...is that correct?

Comment 4

[Bram Pitoyo [:bram]]

The desktop version of the wireframes have just been updated and can be seen at:
http://people.mozilla.com/~bpitoyo/sumo/sumo-wireframes.pdf

What’s new in this version:

* Moved the main navigation area to the right of the “Mozilla Support” header/logo. We don’t have to stack it this way. We can make it fit on one line rather than two. The point is to have the main site navigation be on the right of the “Mozilla Support” header/logo somewhere

* On the Top page, the search box is made much more prominent, but it’s moved down. On the rest of the pages, the search box remains on the header, where most people have learnt to expect to see it

* On the search result pages, the search box is not put on the header. It’s a bad idea to have two things that look like search boxes on each page, because people will never sort them out.

* Added breadcrumb on most pages. We know that there will be problems with breadcrumbs because SUMO is a wiki, and a wiki does not have a deep structure by design. I too am not convinced that breadcrumb is the best way to navigate a shallow-structured website, but I’m putting it there, just in case. Maybe we could use it someday.

Comment 5

[Bram Pitoyo [:bram]]

Design requirement
We can divide this project into several modular parts:
* Design icons for the task
* Design a visual look for SUMO that will unify it with Mozilla’s web experience

We found in the test that icons we had for tasks are attractive (I took them from The Noun Project), and people were able to remember the visual’s they’ve clicked on. We think that it’s important that we design a good representation for these tasks.

As for designing the SUMO visual look, we can divide the site into a few important templates. If the visual designer would be able to unify them, we can apply his/her design throughout the rest of the site.

The important templates (along with pages referred to on the latest wireframe PDF):
* Top, logged in contributor (p2)
* Product landing page - Firefox - logged in contributor (p7)
* Article page (p10)
* Search Result Page + Tailored Answer (p20)
* Product picker (p5)


Top, logged in contributor (p2)
I chose this page because it has the most unique layout that will need a custom design. For starters, it doesn’t look like a typical wiki page.


Product landing page - Firefox - logged in contributor (p7)
I chose this page because it’s a landing page that’s fairly complex, and other landing pages can be based off of this one. For example, Learn the Basics is a variation of this design that doesn’t have the 5 task boxes up top. In addition to that, it has the wiki tools and the “For Contributors” sidebar that we can take out when displaying the non logged-in version.

The “For Contributors” field is put on top of the “Help Topics”. It is only present when contributors are logged in. Regular users won’t see it.


Article page (p10)
This is important so we can get an idea of how various text elements (p, h1-5) and tables would render on the page. In addition to this, look on the sidebar and you’ll see a list of topics. The challenge with this is how to design it so that the text inside doesn’t reflow in too many lines (two max). The text inside the sidebar should probably not look so much smaller than the content area.


Search result page + tailored answer (p20)
This page is important because search looks different from the rest of the site. Look at p21-23 to get an example of how search facet/filter is implemented. We need to design this, too.


Product picker (p5)
This page appears when you click on any topic on the top page (p1).


Q&A

Q: Why does the language picker have a globe?
A: It’s a best practice, supported by research others have done (here’s a nice summary: http://uxmag.com/articles/select-country-select-language). Map and globe are actually the two dominating icons to indicate language/country/region selector on many sites. Globe renders better in small sizes.

Q: Why does the language picker say “Deutsch 日本 中文”?
A: If the user doesn’t speak English well but uses the Firefox English interface to get help, understanding the word “Select a language” or “Choose your country” is going to be harder than understanding a globe and a few language names, rendered in their native scripts.


Q: But then, why does the language picker say “in English” in p4?

A: In p4, the interface is rendered in Bahasa Indonesia. In this one, the word for the language picker is “in English” because we know that most people who uses the Indonesian version of Firefox, and thus get help in Bahasa Indonesia, prefer English as a secondary language. We also know that English is perceived as better in conveying technical-related informations in many other locales. So, when we don’t need the full picker, we don’t need to display it.


Q: Why use another page for the picker, rather than a dropdown menu?

A: A page handles more languages, locales and complexities better even though it invites less click (less affordance). It will allow us to differentiate between languages that have fairly complete translations in SUMO, and those with only partial translations. It will also scale better for the future. Other than that, picking through a long list of smaller texts tend to be harder for disadvantaged users.


Q: Why is the search bar located up top and not presented more prominently on the page?

A: People have learnt that search, sign in, register, language picker, settings, profile, and accessibility-related informations are found at the top. This is called Utility Navigation, and it’s present in the biggest sites in the world. Google, for example. We are using this knowledge to put things where people expect to see them, so they don’t have to relearn that when visiting SUMO.


Q: But the search bar is missing from the Top page (p1, p2, p4) and the Search Result Pages (p19-23). What explains it?

A: Our research found that users have a hard time sorting out two things that look like search boxes on the page.

On the Search Result Page, the reason is clear. We cannot keep the search box so small because search is the main operation, and a main operation should occupy a more prominent place on the page.

On the top page, the search bar is present on the bottom, but in a much larger size. Our earlier research found that some people are searchers: they prefer to search first rather than browse. Most people like to browse. For those people, we have a big search box. On the rest of the pages, though, the search box is present on the header.


Q: Some products have explanations, and some don’t. What gives?

A: We found that people may get Firefox’s name wrong (some called it “Mozilla” like the old browser), but they already understood what it is. Other products like Thunderbird and Home (Home is a big problem because people associate “Home” with the top page, and not the product) aren’t so clear. Services are even harder to grasp. How do you explain Sync, Persona and Marketplace in a few words?

So we tried our best to explain it using words that people uses (“single sign-on” was a tester’s suggestion, “iPhone is more well known than iOS”, etc.)

Comment 6

[John Slater]

Thanks guys. Lee Tom will be able to tackle the web design portion of this...he'll be able to start on Monday 6/25 at the latest, or potentially a little earlier if we get some existing mobile projects wrapped up quickly. I'm guessing it'll be about two weeks of work to get it complete.

My recommendation is to have the icons done by another designer so we can be more efficient in our use of time. Bram, can you list out the icons needed so I can scope that out?

Tenser, how does all this sound re: timing and your expectations?

Comment 7

[David Tenser [:djst]]

(In reply to John Slater from comment #6)
> Tenser, how does all this sound re: timing and your expectations?

The timing sounds great given the late notice -- I really appreciate it. Breaking the work down by web design and artwork makes sense if it speeds the overall implementation up. Bram should be able to provide more details on the artwork needs.

I'm also thrilled that we'll get the awesome Lee Tom to work on this. We should set up a meeting with him, Bram, and Verdi (at least) to discuss the specifics as soon as possible, as I imagine that will help us scope out the work. There are a lot of design considerations that were made and not all of them are reflected in the wireframes, so spending some time talking it through would likely be very helpful.

Thanks!

Comment 8

[Bram Pitoyo [:bram]]

(In reply to John Slater from comment #6)
> Bram, can you list out the icons needed
> so I can scope that out?

Yes. The icons we need to have will need to represent these concepts:
 
* Learn the basics and get started (We’re trying to represent the user’s language of “how to learn if I am new to the software”our version has a stairs with 1-2-3 on top of it to represent learning and progression.)


* Download, install and migration (We’re trying to represent: “how to put something into my computer?” Our version has a down arrow leading down to a computer screen.)

Alternatives we’ve considered:
** The down arrow by itself (it might not carry enough concrete meaning)
** Down arrow leading to a hard drive (to our audience, the monitor is the computer, so they might not have a concept of what a hard drive is)


* Privacy and Security settings (We’re trying to represent: “the articles inside here relates to my security on the web”. Our version consists of an opened padlock.)

Alternatives we’ve considered:
** A key
** A padlock with a keyhole opening


* Customize controls, options and add-ons (We’re trying to represent the concept of: “things I can customize, tweak and change to my liking go under here”. Our version consists of a gear because it might be the visual representation that will be used in Australis.)

Alternatives we’ve considered:
** A wrench
** A hammer and wrench


* Fix slowness, crashing, error messages and other problems (We’re trying to represent the concept of: “something is wrong”. Our version consists of a triangular road sign with an exclamation mark, like a warning message icon).

Alternatives we’ve considered:
** A broken monitor
** A stethoscope


* Join the discussion, ask a question and get community support (We’re trying to represent the concept of: “this is where I can be helped by real people, rather than help myself”. Our version consists three avatar silhouettes.

Alternatives we’ve considered:
** One talk bubble
** Two talk bubbles (it consistently conveyed “chat” or “get live help”, which the SUMO forum is not)


Lower in the priority list (ie. not needed right away):
* Help Articles (to be used in the search result pages to represent the KB articles. Our version consists of a document icon.)
* Bookmarks/favorites (a star icon)


In the prototype test, I took a bunch of icons from The Noun Project and either modified them a bit or just used them out of the box.

I am not sure about the role that the silhouette nature of the icons plays in their good recognition, or whether a more photo-realistic one would be better. The icons should fit into the new visual style, though.

Comment 9

[Bram Pitoyo [:bram]]

(In reply to David Tenser [:djst] from comment #7)
> There are a lot of design considerations that were made and not all of
> them are reflected in the wireframes, so spending some time talking it
> through would likely be very helpful.

Yes. Let’s do this next week, if possible. I imagine that it will be most helpful to first take Lee through our basic navigation system, and then run him through the visual limitations in the wireframes that the new design style will need to solve.

Comment 10

[John Slater]

Thanks guys. So we have Lee booked to do the site design and Matt Ternoway (an awesome freelancer who has done some great work for us on a variety of projects) lined up to tackle the icons.

FYI, a few other projects have crept onto Lee's calendar so this will likely take a bit longer than the 2 weeks I originally estimated (although not dramatically so). We can estimate better once we talk it through, but I'm thinking it'll be complete the week of July 9.

Can we have that kickoff meeting this week? If we can cover both the site design and the icons in an hour that would be ideal. Let me know who I should invite and I'll set it up.

Comment 11

[Verdi [:verdi] Best to slack me]

(In reply to John Slater from comment #10)
> Let me know who I
> should invite and I'll set it up.

Please include me. Thanks!

Comment 12

[Bram Pitoyo [:bram]]

(In reply to John Slater from comment #10)
> Thanks guys. So we have Lee booked to do the site design and Matt Ternoway
> (an awesome freelancer who has done some great work for us on a variety of
> projects) lined up to tackle the icons.

Thank you! Can we have that kickoff meeting tomorrow?

As far as scheduling goes, Verdi and I will have a meeting at 9–10am Pacific. I am free after that up until the end of my workday at 1p. Verdi can confirm his availability.

I have some notes compiled that explain the problems we had due to the wireframe’s low fidelity, that the visual design will need to solve. I will post that here.

Comment 13

[Bram Pitoyo [:bram]]

Prototype research findings that visual design will need to solve:

1. People are missing the sidebar in relevant scenarios
* We intentionally design the sidebar to serve as navigation aid (to help signal “you are here”, even though the main navigation bar already does that) as well as search facet
* In both cases, sidebar will need to contain topic texts. Some topic texts are 5–6 words long
* When we specifically ask people to explain what items on the sidebar means, they understand it
* We think that people didn’t notice the sidebar due to its relative text size and wrapping. On the test, the sidebar was not only set smaller than the rest of the page, but also thin so the text inside wrap to the next few lines


2. A strong indication of “You are here” is needed:
* In the wireframes, we did this by making the navigation item unclickable (no underline)
* We found that people click back as a way to navigate (the back button is not a taboo)

2a. Indicator on the navigation bar

2b. Indicator on the content area
* We think that simply having the product name & icon would signal people that they are viewing help for a particular product. This worked well, if the name & icon is sufficiently separated from the sidebar and the content area
* It is important to make people confident that they are viewing an article that pertains to their OS and Firefox version
* Version & OS appear on the bottom of the product name & icon. OS has icons to the left of its name. The pickers are drop down menus. We tested several different pickers before arriving at this solution
* We autodetect version and OS when user visits SUMO. It is important to let people know that we did the autodetection. We know this but were not able to test it, because highlighting autodetection requires color, animation, or some other indicator that will need to be visually designed

2c. Indicator on the sidebar
The selected item on the sidebar is indented and given arrows as indicator. This indentation does not indicate subtopic.

2d. Breadcrumbs
The breadcrumb was originally not tested or put into the wireframes, because SUMO is a wiki with a very flat structure. However, breadcrumb is a useful tool, and we want to investigate ways to incorporate it


3. Boxes attract too much attention and cause people to skip reading other things
* The wireframes are B&W, so when we put things inside of boxes to delineate types of information, people are fixated on it
* This is a good thing. In most cases, we want to draw the most attention to the task-based navigation.
* But in cases where page-wide attention is needed, we want people to be skimming everywhere, not just inside the boxes
* In some cases, people didn’t even read what’s on the heading, when the heading is put outside of these boxes
* We think that a color contrast that will subtly nudge people and direct their attention towards various blocks of information is going to be more effective than putting very clear and marked boundaries


4. Pertinent to icon design:
We found that if icons look too “visual” when compared to the rest of the site—SUMO is pretty text heavy—and if that icon is paired with a heading and put inside a box, user could view it as banner ads, and skip over it (banner blindness).

Comment 14

[Bram Pitoyo [:bram]]

Attachment: SUMO templates for visual design

List of templates to be designed:
* Top page, logged in as contributor
* Product landing page: Firefox, logged in as contributor
* Article page
* Search Result Page + Tailored Answer
* Product picker

Comment 15

[Bram Pitoyo [:bram]]

List of icons to be designed:
1. Learn the basics and get started
2. Download, install and migration
3. Privacy and Security settings
4. Customize controls, options and add-on
5. Fix slowness, crashing, error messages and other problems
6. Get community support, join the discussion, ask a question

Comment 16

[John Slater]

Thanks Bram. Looking fwd to talking further about this tomorrow.

Comment 17

[Bram Pitoyo [:bram]]

Attachment: SUMO templates for visual design

The third page has been updated with the addition of a thin “Hot Topics” area. This is a design oversight. Thanks Verdi for reminding.

Comment 18

[Lee Tom]

Posting this work-in-progress mockup for Matt who will be doing our icon set design. It's the current approach for the icons going into Marketplace:
http://people.mozilla.org/~smartell/marketplace/marketplace-icons.png
This not necessarily direction for the SUMO icons, just some visual reference. 

(In reply to Bram Pitoyo [:bram] from comment #15)
> List of icons to be designed:
> 1. Learn the basics and get started
> 2. Download, install and migration
> 3. Privacy and Security settings
> 4. Customize controls, options and add-on
> 5. Fix slowness, crashing, error messages and other problems
> 6. Get community support, join the discussion, ask a question

Comment 19

[John Slater]

Thanks Lee. Matt, I would definitely recommend following that general direction for these icons...the consistency will be really nice.

Ping me anytime you want to discuss.

Comment 20

[MT]

Hey guys,

Really liking the direction of these icons, very nice!
For my part it looks like I will be coming up with a way to interpret the list of 6 that Lee has posted?  

John - I'm available now if you are able to chat more about this.

Matt

Comment 21

[Lee Tom]

Attachment: SUMO - homepage - contributors -01

Hi all, attached is a mockup of SUMO Homepage (Contributor signed in.) The IA is a fairly literal interpretation of Bram's wireframes, but there might be some things we'd like to discuss once you see the page skinned. 

* Top Menu (next to Tabzilla)
 - will we need to accommodate links that might span across full page width? On subpages, I think it may be too tight to squeeze in a Search box here. 

* Search box
 - Should we make a dedicated Search module/strip that is easy to find on the page? In this mockup, it's pushed pretty far down the page. I don't however, think that it will be too noticeable in the menu nav (and might not fit)

* "mozilla support"
 - following our Mozilla wordmark convention, I created this for all page headers

* Firefox blue background
 - It is possible to change the background color for SUMO, but since the current site is based on the Firefox styles, I thought this was a good starting point for these mockups.

* Help Topic icons
 - I picked up on the icon pads and styles of our Marketplace site design.
 - FPO / where Matt T's new icons will go

Comment 22

[Lee Tom]

Attachment: SUMO - product picker -01

SUMO Product Picker

* Search
 - I placed the Search module at the top of the page content -close to breadcrumbs- for good visibility. Is this one of the main ways users navigate in Support? If so, it might be a good idea to include the Search bar at the top of every subpage

* Products
- I tried to keep the 6 product buttons high up on the page. FPO copy - in case we'd like to write a small description or blurb for each product.

Comment 23

[Bram Pitoyo [:bram]]

(In reply to Lee Tom from comment #21)
> * Top Menu (next to Tabzilla)
> On subpages, I think it may be too tight to squeeze in a Search box here. 
> * Search box
> - Should we make a dedicated Search module/strip that is easy to find on the page? In this mockup, it's pushed pretty far down the page. I don't however, think that it will be too noticeable in the menu nav (and might not fit)

The search box not fitting is a valid concern. I am not worried that they are small, but they do need to exist somewhere on every page.

I wonder if moving the search box to the right of Mozilla Support makes sense? That part is not going to change between pages, and then we can eliminate the “Find articles and answers” section entirely.

(In reply to Lee Tom from comment #21)
> * Top Menu (next to Tabzilla)
>  - will we need to accommodate links that might span across full page width?

I don’t think so. In fact, you can even remove the “Accessibility” link since that is something that we will only read aloud to user when they’re accessing SUMO via a screenreader.

Minus “Accessibility”, will we have enough space for a search bar up top?

We found that the (admittedly very long) button label “Search Mozilla Support” work well in setting user expectation, but a text label inside a search field doesn’t. I know that this is a very minor concern, but maybe it factors into your design decisions, so I’ve put that here.

What we definitely don’t want to happen is for search to serve as a primary mean to navigate. Research found that a majority of users browse rather than search. I worry that when the search module’s placement is so prominent on all pages, browse might get skipped.

(In reply to Lee Tom from comment #21)
> * "mozilla support"
>  - following our Mozilla wordmark convention, I created this for all page
> headers
> 
> * Firefox blue background
>  - It is possible to change the background color for SUMO, but since the
> current site is based on the Firefox styles, I thought this was a good
> starting point for these mockups.

These all look good to me!


> * Help Topic icons
>  - I picked up on the icon pads and styles of our Marketplace site design.
>  - FPO / where Matt T's new icons will go

This area also looks good visually. I like that the topics and products areas are colored differently!

One thing: the size of the text labels is worrying because they’re so small.

An idea: to enlarge the text labels, I wonder if you could treat the 6 topic boxes the same way as the list of products in the picker (attachment 637223 [details])? That is, you’d have 3 topics in a row, and then make 2 rows. I don’t think making the topics occupy 2 rows will confuse users in terms of visual hierarchy.

Comment 24

[Bram Pitoyo [:bram]]

(In reply to Lee Tom from comment #22)
> Created attachment 637223 [details]
> SUMO Product Picker
> * Products
> - I tried to keep the 6 product buttons high up on the page. FPO copy - in
> case we'd like to write a small description or blurb for each product.

We found that products other than Firefox need to be explained. Your copy space is perfect to do this. The three column layout is also something smart that could be reused elsewhere.

(In reply to Lee Tom from comment #22)
> * Search
>  - I placed the Search module at the top of the page content -close to
> breadcrumbs- for good visibility. Is this one of the main ways users
> navigate in Support? If so, it might be a good idea to include the Search
> bar at the top of every subpage

You’re right. It’s one of the ways to navigate. Our plan is to have the search interface be on every page, but located somewhere that doesn’t attract too much attention to itself. That was why I put it up top, not on the main navigation area.

Thanks, Lee. The two mockups look great!

Comment 25

[Lee Tom]

Attachment: SUMO -product landingpage - Firefox 01

Product Landing page - Firefox 01

Glad you like the progress so far! 

* Search
- still trying to figure out a good place to put this. If we can carve out more space in the menu (eliminating "Accessiblity" etc) we might get away with keeping this at the top of the page. It starts pushing everything else down slightly, but the payoff (a consistent, out-of-the-way-but-still-accessible spot) could be worth it. 

* For Contributors
- Is this header redundant? We have a list of links in side nav, but it also has it's own section in the main content area (with a different set of links)
- I'm not sure I understand the wireframe portion of this section in the content area of page - should this be an expand/collapse accordion (similar to FAQ pages? http://www.mozilla.org/en-US/firefox/mobile/faq/)

I know there are still many things to work out, but i think it's helpful to start seeing how all of these elements will (or won't) fit on the page. Let me know what you think...thanks!

Comment 26

[MT]

Attachment: Help Topic icon concepts

Hey guys, 

Here is an example of what I'm thinking for the remaining 6 help topic icons.  Keeping in the style of what was established for the Marketplace approach. 

1. Learn the basics and get started - chalkboard with a written 1,2,3 in a chalk-like font

2. Download, install and migration - similar to the existing one, but integrating the arrow into the monitor screen to tighten up spacing

3. Privacy and Security settings - sticking with the lock visual, thought it is pretty standard 

4. Customize controls, options and add-on - breaking away a bit from gear image, to play up more of the Add-Ons imagery with the puzzle piece

5. Fix slowness, crashing, error messages and other problems - sticking with the common alert imagery

6. Get community support, join the discussion, ask a question - thought that a simple speech bubble with a question mark could be a way to represent the discussion/question aspect


Please let me know what you think of this direction. 

Cheers,
Matt

Comment 27

[Bram Pitoyo [:bram]]

(In reply to Lee Tom from comment #25)
> Product Landing page - Firefox 01
> * Search
> - still trying to figure out a good place to put this. If we can carve out
> more space in the menu (eliminating "Accessiblity" etc) we might get away
> with keeping this at the top of the page. It starts pushing everything else
> down slightly, but the payoff (a consistent,
> out-of-the-way-but-still-accessible spot) could be worth it. 

I agree with you. Putting it somewhere on top, either:
1) On the utilities area (in line with sign in, register, etc.), or
2) On the right of the Mozilla support

Will be awesome. We deliberately designed search to exist on the header area on every page  _except_ for the top page. But you’re right, I’d prefer something consistent, accessible, but a little out of the way. We know that search users are in the minority.

We can remove Accessibility on the nav. Another two things we can combine to save space for search are “Sign in” and “Create an account”. Maybe change it to “Sign in/Register”, so the search box can be made longer?

We also found that the word “Search Mozilla Support” on the bottom works very well (this, versus “Search”) because it prevents people from thinking that the search box is Google’s (we had people searching for “Facebook”, “games” and even “sex”). We won’t need the arrow either. But making the button contain that long of a word might be visually problematic?


> * For Contributors
> - Is this header redundant? We have a list of links in side nav, but it also
> has it's own section in the main content area (with a different set of links)
> - I'm not sure I understand the wireframe portion of this section in the
> content area of page - should this be an expand/collapse accordion (similar
> to FAQ pages? http://www.mozilla.org/en-US/firefox/mobile/faq/)

The links in the main content area shouldn’t contain “For Contributors” (the sidebar is enough, and good looking!), but headings like tips and tricks, bookmarks and favorites, cookies, tabs, fix problems with websites and get community support. I believe these links are included in the PDF I sent you.

These headings don’t have to expand or collapse, so you don’t need to create separate styles for the heading and for the paragraph. Just headings.

Let me know if there are any other questions.

Comment 28

[Verdi [:verdi] Best to slack me]

Some additional feedback:
I like the new icons - https://bugzilla.mozilla.org/attachment.cgi?id=637696 - especially the chalkboard and puzzle piece (ties in with add-ons). The one I question is the chat bubble. Bram can say more but I thought the multiple person icon tested better than the chat bubble. Also the chat bubble could be misleading since community support isn't a live chat or a regular discussion forum.

My concern seeing the icons on the page is that they blend in with the other items and make the product icons and search the most prominent things https://bug762255.bugzilla.mozilla.org/attachment.cgi?id=637219 I believe in the user testing these help topics were the most attractive targets (they were certainly designed to be attractive). Maybe it's as simple as giving them white backgrounds like the other icons but it feels like they need to be the biggest call to action.

The "For Contributors" section on the front page seems to take up a lot of space. I certainly use those links a lot but I also browse and search the site quite a bit. I suspect that other contributors do that more than I do as I have every article in my awesome bar.

In general though I LOVE LOVE LOVE this. It's very exciting!

Comment 29

[Lee Tom]

Thanks for the feedback, Michael! I think Matt did a great job on the icons too - I'm sure we can make them stand out more by lightening up their backgrounds, as you suggested. I'm working on the 5th mockup today, with the idea of routing all five pages back through you all, so we can see them at once - in context with each other. I think we'll be able to define pain-points more easily that way, and look at the UX more holistically. Stay tuned!

Comment 30

[Bram Pitoyo [:bram]]

(In reply to MT from comment #26)
> Help Topic icon concepts
> 
> 1. Learn the basics and get started - chalkboard with a written 1,2,3 in a
> chalk-like font

The chalkboard iconography along with a handwritten styled numbers imply learning, which is a nice allusion to the concept we’re communicating. To make the icon more readily read as a “classroom”, maybe we could give the numbers a chalky texture (I worry about the legibility) and/or adding a chalk somewhere on the board (which may make the design too busy).

Searching for images of “chalkboard icon” demonstrates both points:
https://www.google.com/search?q=chalkboard+icon


> 2. Download, install and migration - similar to the existing one, but
> integrating the arrow into the monitor screen to tighten up spacing

Looks great. Currently, the icon refers to the general shape of an iMac. I am not worried that user will have trouble reading this icon as a monitor. The icon tested well, too.

My hypothesis: making it resemble an everyday, PC LCD monitor will aid comprehension further.

An iMac is different from a monitor in four general ways:
* The border around the monitor is even on all sides
* There’s no logo on the bottom side
* The monitor stand tends to be thinner and more rectangular
* The monitor base is separated to the stand, and wider

Reference images:
https://www.google.com/#q=lcd+monitor&tbm=shop

 
> 3. Privacy and Security settings - sticking with the lock visual, thought it
> is pretty standard

Awesome!


> 4. Customize controls, options and add-on - breaking away a bit from gear
> image, to play up more of the Add-Ons imagery with the puzzle piece

Originally, we matched the iconography with that which is going to be present in Australis (reference: http://people.mozilla.com/~shorlander/files/australis-designSpecs/australis-designSpecs-windows7-mainWindow.html) because user will be able to associate the icon on their Firefox UI with what they see on SUMO.

However:
* There is no icon that reads as “options, settings and preferences” in the UI today
* The representation of Add-ons as a puzzle piece is very well known, because we already use it
* I cannot confirm whether the gear is going to be included in the final Australis design (can someone help?)

I know that having both the gear and the puzzle piece on the icon isn’t ideal, though! My proposal: we should use the well-known and well-used puzzle piece as an icon today. But you may need to create the gear for when the Australis UI is deployed at a future date.


> 5. Fix slowness, crashing, error messages and other problems - sticking with
> the common alert imagery

Awesome!
 

> 6. Get community support, join the discussion, ask a question - thought that
> a simple speech bubble with a question mark could be a way to represent the
> discussion/question aspect

The question mark is something we haven’t tested, but it’s a very interesting idea, because it contrasts well with the exclamation mark. Using exclamation mark to mean “warning” and a question mark to mean “help” are universally accepted.

What we have tested is people’s confusion when we displayed the speech bubble. They associated it with live chat (over an IM-like interface), which is not what this topic covers. Susan, our IA consultant, had recommended trying the multiple-head icon to represent the community aspect of the discussion forum (ie. most of the support forum is led by volunteers rather than staff).

What might be interesting is to combine the two imageries: some sort of a question mark with a group-people icon. I am not sure if this will make the icon look busy and unreadable, though.


Let me know what you think of these ideas? I hope it helps give you some direction.

Comment 31

[MT]

Attachment: mozillaSupport_icon_layout.jpg

Hi guys,

I know most of you are probably out of the office for the day, hope you're all enjoying your July 4th!..but wanted to have this ready for when you return.  Thanks Bram for your suggestions, I have taken most into account, namely 'Learn the Basics, Download/Install and Community Support'.  

For 'Learn the Basics' I've worked in your suggestion to add a piece of chalk to give the black board an easier recognizable form....unfortunately I found it hard with that size to incorporate a distressed look to the 1,2,3 font to give it that chalk look.

For 'Download/Install' I've gone with more of a generic LCD monitor with an even rectangular shape.

Community Support, I've had some difficulties working with both the trio of people and the question mark as one icon, I was feeling that it was getting a little overwhelming to look at, so I've reverted back to the original icon that Lee displayed. 

Lee had also mentioned to me that there is a need for a page/file icon seen in the search results page, I've attached a possible look for that as well.

Please let me know how you feel about the latest version of these.

Cheers,
Matt

Comment 32

[MT]

Attachment: file_icon

Comment 33

[Lee Tom]

Attachment: SUMO - article 01

Hi everyone, Here's are all 5 of the latest mockups (Matt's icons are not integrated yet.)  Hopefully, seeing them all together will make it easier to identify any inconsistencies or issues we'd like to address. Here are some issues off the top of my head. (These may or may not be issues to everyone, but I thought I'd flag them as notables)

* Search
- Search field can fit in the top left of the page menu by consolidating the other links. I think it's too wordy to say "search mozilla support" in the button itself, but should fit fine as a prompt inside the search field. 
- Should the top menu Search field remain persistent in the menu on the Search Results page? I have removed it in the mockup, since we want to make the Search bar prominent on that specific page. 

* Breadcrumbs & Nav Bar
- Hierarchy: should breadcrumbs be above or below the list of links? 
- For most other new Mozilla sites we've been designing, we've typically been using the white navigation bar with anchor tags (jumping to relevant content further down the page). I'm assuming the links in this nav bar take the user off the page - should this list be stylized differently? I'm a bit concerned/confused by how many different lists of navigation and styles we're trying to cram into these pages. I'm also not comfortable placing these links to the right of the Mozilla Support wordmark either. 

*Help Topic (pads and graphics)
- Bram expressed concern that the copy on these buttons may be too small to read comfortably. I'm wondering if rescaling them to the same size as the Product/Services pads would be overkill...? Will this be problematic/require too much real estate on mobile versions?

Comment 34

[Lee Tom]

Attachment: SUMO - homepage - contributor - 02

Comment 35

[Lee Tom]

Attachment: SUMO -product landingpage - Firefox 02

Comment 36

[Lee Tom]

Attachment: SUMO - product picker -02

Comment 37

[Lee Tom]

Attachment: SUMO - search result -01

Comment 38

[Bram Pitoyo [:bram]]

Thanks, Lee, for the excellent mockups! Below are my feedbacks. First, I will give feedbacks to the points you’ve written. Then, I’ll give my own feedbacks on each mockup

(In reply to Lee Tom from comment #33)
> - Search field can fit in the top left of the page menu by consolidating the
> other links. I think it's too wordy to say "search mozilla support" in the
> button itself, but should fit fine as a prompt inside the search field. 

I think this decision is fine. Seeing search best practices, though, if we are to eliminate a very clear and clickable “Search” button from the interface, we need to make the search box even more obvious to see. Below are some ideas:

* Make the text box longer. This will make it obvious that you’re supposed to type into it
* Make the arrow say “Go”, and then put it on a button that looks clickable
* Highlight the search area so user can find it easily. For example, since the rest of the page is blue themed, we can give the search area a lighter blue or a white background box underneath

About the findability, placing search on the top left part of the site is consistent with the findings that users scan the page in an “F” shape. Search will be one of the first things they see on the page.

A proposal I’ve brought up in earlier comments but would like to bring up again is about placing search on the right of the “Mozilla Support” heading.

With this proposal, we can:
* Make the text box longer
* Make the button say “Search Mozilla Support”
* Not introduce a new color to highlight the search box
* Keep the search box consistent, on the same spot, on every page
* Not violate the “F” shape skimming pattern

The (admittedly big) problem with this proposal is, the space on the right of Mozilla Support will no longer be a whitespace, and empty spaces like what you’ve given in the design is important for the design to be successful.

Feel free to look at how the search box is implemented today (ie. on the bottom of the “Mozilla Support” wordmark). It’s not pretty, but its usage is very obvious. I’d like the new search box to be obvious in affordance (ie. the area looks searchable and clickable) even though the visual design may be subtle (which I like your color scheme very much).


> - Should the top menu Search field remain persistent in the menu on the
> Search Results page? I have removed it in the mockup, since we want to make
> the Search bar prominent on that specific page. 

No. In the search result page, it should be obvious that the search field is a main way to navigate. Your implementation in erasing search on the menu above and making a big search box below is perfect.


> * Breadcrumbs & Nav Bar
> - Hierarchy: should breadcrumbs be above or below the list of links?

It should be below the list of links (or the main navigation bar).

> - For most other new Mozilla sites we've been designing, we've typically
> been using the white navigation bar with anchor tags (jumping to relevant
> content further down the page). I'm assuming the links in this nav bar take
> the user off the page - should this list be stylized differently? I'm a bit
> concerned/confused by how many different lists of navigation and styles
> we're trying to cram into these pages. I'm also not comfortable placing
> these links to the right of the Mozilla Support wordmark either.

I share your hesitancy in placing these links to the right of the Mozilla Support wordmark. It should remain below it, like what you’ve implemented.

You are correct that most new Mozilla sites uses the navigation bar area to contain anchor tags, rather than real links. Perhaps it would help if the links in this area is styled like the links in the area above it (Ask a Question, Sign In/Register, Deutsch). That is, we erase the white box from around the navigation bar, we also erase the vertical ruler, but we keep the link color blue.

Our research found that things inside boxes attract a lot of attention, oftentimes too much for its own good. Maybe simply erasing the white box and the rulers, but keeping the blue, will help improve the navigation bar?

Your concern is correct. There are a lot of links in these pages. I’d venture a guess and think that you’re most concerned about all the links on the sidebar and how hard it is to digest that much information.

Everything under the 1) “Projects” and 2) “For Contributors” headings can only be seen and are only used by contributors who are logged in. Most people won’t see it.

If we take both items out from the sidebar, most people will only see two headings:
1. “Help Topics”
2. “Products and Services”

On the Search Result Page, though, I’ve made a mistake. I haveve included too many items on the search bar. You can erase everything under “Related Search” and “Show Everything”.

However, “All Topics” and “All Products” are not headings. They’re search facet links that should be as big as other items on the search bar.

How search facet works: When a user first search, the facet initially points to “All Topics” to indicate that the search result contains all topics, and “All products” to indicate product. A user can click on a specific topic or product to refine, and then the selected item becomes the topic or product name.

For example, if I want to display search results that are just about “Privacy and Security”, I click on that topic, and then that topic becomes the selected item.

Two more points about the sidebar:

The first one comes from our research finding. We found that we need a very clear signal that a particular link is being selected. We call it a “You are here” indicator. The point is so that user knows the item he had clicked on by just glancing at the sidebar.

In the low-res wireframes, I had used an arrow to indicate selected item. This is a very crude way. I think you can solve it more subtly. What should a selected sidebar item look like so it has a clear “you are here” signal? Using your design language, I imagine that the selected item would have a white box around it, and the text would be colored dark grey/black.

Fancier solutions are welcome!

Last point about the sidebar: there is no hierarchy. So, on attachment 639403 [details] (SUMO - article 01), the sidebar item called “Learn the basics: get started” is not indented. Rather, it’s being selected. That is, the article called “Navigation Toolbar Items” has a topic called “Learn the basics”.

This spot is the place to demonstrate the aforementioned “selected” state of the sidebar.


> *Help Topic (pads and graphics)
> - Bram expressed concern that the copy on these buttons may be too small to
> read comfortably. I'm wondering if rescaling them to the same size as the
> Product/Services pads would be overkill...? Will this be problematic/require
> too much real estate on mobile versions?

Maybe it would be overkill. The point is to make this area:
1) Very clickable (I think you did a really great job at this)
2) Very readable (the text size simply isn’t big enough)

I understand that increasing the text size too large may be overkill, and plus, it might cause the text to go multiline, which again is not great for readability.

Here are two possible solutions to increase text size while (I hope) keeping the harmony of your design at the same time:
1) Try combining the five or six boxes into one large box, and then put vertical ruler between each item. Kind of like what you did with the main navigation bar, but with icons on top of each item. You’ll get more space to put larger text this way. You can also remove the arrows.
2) Expand the topic box so they occupy twice the area. This way, we get 2 rows of 3 topics each. Basically, make the Help Topics area similar to Products & Services.



Here’s my comment on each mockup:


(In reply to Lee Tom from comment #33)
> Created attachment 639403 [details]
> SUMO - article 01

I love the fact that Table of Contents gets a receded look similar to our Hot Topics area! We use a bunch of boxes like this in SUMO to communicate warnings and important things, within and out of the article. This is excellent!

For example, on this article, you see blue and yellow-colored boxes to indicate Note and Important sections. Your receded design could be adapted or reused for these sections.

Currently on SUMO, we use a very boring font for our body text for a reason. Our users need technology help, and those who need help tends to be both older and younger than a technically-inclined internet user. So we try to make it as readable as possible using Helvetica Neue on Mac, Arial on Windows, Nimbus Sans on Linux, and so on.

Would it be possible to make the body text sans serif? Not necessarily the big headings, but the body text, captions and small texts.

Personally, I am hesitant to make the body text uses Open Sans Book, since it looks very anemic on my Windows XP machine, but it is a good start. If we are to change the body text to a sans serif, maybe making everything Open Sans would be great.

I know that this would break away from the standard Mozilla look, so maybe it’s something to be discussed.



(In reply to Lee Tom from comment #34)
> Created attachment 639404 [details]
> SUMO - homepage - contributor - 02

What’s your thought on making the Help Topics links not blue, since the box around each link already looks clickable? The less blue links on the page == the less clutter we have. It would be great if the Help Topics text could be bigger, too. This is just restating my previous point.

What’s your thought on making the “For Contributors” links look like the “Hot Topics” section? Only contributors and power users will ever see it. Maybe it will help lighten up the visual weight of the page.

Your design and hierarchy makes this page not need to have the “Get Involved” heading. “Help Other Users” and “Suggestion Box” are enough. You can either keep them in that size, or promote the heading size to be as big as “Get Involved”. One less thing on the page.



(In reply to Lee Tom from comment #35)
> Created attachment 639406 [details]
> SUMO -product landingpage - Firefox 02

Everything on this page is perfect. The list items “Tips & Tricks”, “Bookmarks & Favorites”, etc. looks like a list of headings rather than body text. This is exactly what we want, because these links will lead to topic landing pages.

The text on the help topic buttons could be bigger here, too.



(In reply to Lee Tom from comment #36)
> Created attachment 639407 [details]
> SUMO - product picker -02

No problem here. This page is great because we might have a lot of products very soon.



(In reply to Lee Tom from comment #37)
> Created attachment 639408 [details]
> SUMO - search result -01

To sum up what I’ve written above:
* Erase “Show Everything”
* Erase “Related Search”
* “All Topics” and “All Products” are search facets, so they should look like the link below it
* We need a strong indicator of selected item on the sidebar. For example, “All Topics” and “All Products” are both selected by default, so you could style that differently from the rest of the links under it (getting started, Firefox Home, etc.)

And one more point about the headings:
We’re going to have headings on the sidebar, so why not try to make the heading sof the tailored answer and the search result as big as the current sidebar headings?



Thanks, Lee! And sorry for being so lengthy. Please email me anytime to schedule a one-off call to ask questions and explain your points.

Comment 39

[Bram Pitoyo [:bram]]

(In reply to MT from comment #31)
> For 'Learn the Basics' I've worked in your suggestion to add a piece of
> chalk to give the black board an easier recognizable form....unfortunately I
> found it hard with that size to incorporate a distressed look to the 1,2,3
> font to give it that chalk look.

I think the chalk is readable enough as a writing implement, and the addition of that makes the shape read as a proper blackboard. My opinion: we’re good to go.


(In reply to MT from comment #31)
> For 'Download/Install' I've gone with more of a generic LCD monitor with an
> even rectangular shape.

Less Mac-like means a monitor that resembles most of our userbase’s. Just curious: what’s the small round dot below the screen? I think we’re good to go on this one.


> Community Support, I've had some difficulties working with both the trio of
> people and the question mark as one icon, I was feeling that it was getting
> a little overwhelming to look at, so I've reverted back to the original icon
> that Lee displayed. 

I took all of the initial design for those icons from the Noun Project, which Lee restyled. I am not opposed to using the shape as is (we need to credit the original designer, Rémy Médard), but think that an original concept would be nice.

I am thinking out loud here with some head silhouette ideas that could possibly turn out bad, all in the name of originality:
* A man, a woman and a fox (think cartoonized fox head with ears upright)
* Three men, to make it gender-neutral
* A man, a woman and superhero (think somebody in a superhero mask with definitive silhouette a la Batman)

Superhero is a theme that we have used to reach out to contributors, with messages like “Superheroes wanted” (https://support.mozilla.org/en-US/kb/superheroes-wanted). It would make a nice nod to SUMO’s vibrant community of volunteers, as well as an easter egg—all at the price of icon legibility, though we can make it subtle enough so that only those who know will know where to look.

My opinion: we’re good to go because the icon captures the concept, but we have to credit the original designer.


(In reply to MT from comment #31)
> Lee had also mentioned to me that there is a need for a page/file icon seen
> in the search results page, I've attached a possible look for that as well.

The file icon looks good! It might be presented in the search result page (attachment 639408 [details]) on the left side of the search result text, along with the community (three-head) icon. The document icon will indicate KB articles, and the community will indicate forum threads.

In our search result page test, the document and community (we tested the talk bubble) icons were readable, and testers understood what they meant. But they did not find them as useful as we think. That is, they care more that the top few search results answer their problem, no matter if the results originated from a KB article or a forum thread.



The last point I want to address is the settings/add-ons icon. I’ve given it some thought on the past few days. My criteria for the ideal icon is this:
* It has to imply something you can tweak, like tweaking the height of your car seat
* It also has to imply something you can add on top of something else, like adding a new coat of car paint

Currently, neither the gear icon nor the puzzle icon alone can communicate both concept. So I started thinking of hybrid shapes between the two.

For example, we can:

1) Make a gear-shaped negative space inside a puzzle shape.

2) Place many gears inside a puzzle-shaped frame. Think of Apple iOS Settings icon (http://www.thepropertyjungle.com/imgs/mail-clients/ios-settings-icon.jpg) that has a puzzle-shaped frame rather than a square one.

3) Make a puzzle-shaped negative space inside a gear shape. Alternatively, a gear often has a hole inside, so the puzzle need not be a negative shape. It can be a shape inside the gear’s whitespace.

4) Make the one gear be made out of 2–4 puzzle pieces. Think of the Microsoft Office 97 box (http://s.ecrater.com/stores/74726/493c75bb05519_74726n.jpg) where the outline is shaped like a gear.

5) One gear is made out of 2–4 puzzle pieces, but one piece comes apart slightly. This is to further indicate the “puzzleness” of the icon.

6) Make two gear interconnect (can be equal or differing in size), but the teeth that project radially is shaped to resemble the roundness of a puzzle piece, rather than simply straight-edged.

When designing the gear, it’s helpful to match it to what Firefox uses to its UI, so user can associate and match the shape right away.

For your reference, here are the various gear icons that the browser uses today: http://cl.ly/3X0b0r1F0J0Q321U1O23

Perhaps interestingly, all has some sort of a round hole in the middle. Could this hole be shaped like a jigsaw puzzle piece, for instance? Or would that destroy the icon’s readability?


Thanks, Matt! I hope these feedbacks are useful.

Comment 40

[Rehan Dalal (Inactive)]

Are these mockups final? If not does anyone have an ETA on final mockups?

Comment 41

[Lee Tom]

Rehan, I'll be posting the next round of mockups today.

Comment 42

[Lee Tom]

Attachment: SUMO - article 02

Hi everyone, I'm back from the drawing-board with 5 revised mockups (Matt's icons again, are not integrated yet.)

- David Tenser and John Slater, not sure if you'll need to retrace all issues covered (hope not) but now would be a great time to review these mockups.

- Bram, I'm hopeful that the revisions I made here have covered most of our collective concerns. If there are any outstanding issue - I think we should schedule a meeting with all parties involved, and discuss item by item in real-time. 

- Everyone, give a warm welcome to Holly Habstritt, joining us as an information architect/UX designer on our Web team. I'm CC'ing her here as she may have some valuable feedback, if there's time to integrate. Holly, we can also meet offline to discuss.

Some high-level issues you may see in the mockups:

* SUMO page-header
- creating a slightly darker blue background of our page headers helps delineate content global SUMO content/navigation (such as tabzilla, sign-in menu, logo, search, and site navigation bar) which appears on all pages, from more variable page content. I think this makes it easier for users to navigate through Support site.

* Search
- New treatment of search box makes it easy to find, but fits design of page without being distracting. Search bar is much more prevalent on Search Results page (see attached)

* Breadcrumbs & Side Navigation
- Breadcrumbs moved below site links
- Side navigation is based on some of Sean's latest mockups for the style-guide. Collapse/Expand arrows denote 2-level deep categories.
- Selected content (where you're at) is denoted by bold type and page colored background
- Hover state is denoted by highlighted background and link color text

Comment 43

[Lee Tom]

Attachment: SUMO - homepage - contributor - 03

Comment 44

[Lee Tom]

Attachment: SUMO -product landingpage - Firefox 04

Comment 45

[Lee Tom]

Attachment: SUMO - product picker -03

Comment 46

[Lee Tom]

Attachment: SUMO - search result -02

Comment 47

[Bram Pitoyo [:bram]]

Hi Lee,

I will review these mockups in more details tomorrow, but I don’t see any glaring issue with it, so I think that we’re generally good to go! Thanks for the excellent work.

Some things I like:
* With our kind of information density, the darker blue, separated header style works well
* The breadcrumb is placed in the right position. I’ll have to think of a way to make it even more obvious.
* The collapse/expand arrows is a good solution to reduce clutter – I’m thinking of applying this to the search facets
* The magnified glass icon communicates the idea of search better than the arrow. I’ll have to think whether a search button is still needed in this case, or if it can be integrated more elegantly. I like what you did here.
* Two-line topic listings will allow us to be more generous with our topic descriptions.
* Dotted-line separation between search results. I saw one on the mockup Not sure if you intended it, but it’s a good idea.

Other than reviewing, my next step is to apply your design into other pages that we have (e.g. the support forum). I will attach these mockups in the bug, so you all can see, review, and make sure that my adaptation fits with Lee’s visual style.

Could you send me or attach PSD files of these wireframes, so I can work from it?

Comment 48

[Rehan Dalal (Inactive)]

:bram can we assume that this is not going to change significantly at this point?

Comment 49

[Holly Habstritt Gaal [:Habber]]

Thanks for cc'ing me, Lee. I'll take a look just as another pair of eyes on this, but given Bram's involvement and background with this, I would guess what I have to add will be pretty minor. This is a great introduction for me to see what has been going on with SUMO! Looking forward to working with you on other projects as well.

Comment 50

[John Slater]

These look really good to me, thanks Lee. I like the changes you've made in this round...kudos to you & Bram for making this happen.

Are we done here?

Comment 51

[Verdi [:verdi] Best to slack me]

(In reply to Lee Tom from comment #46)
> Created attachment 645130 [details]
> SUMO - search result -02

The way I understand the sidebar on the search results page is that there should be multiple facets that you can narrow your search with. This mockup makes it look like one long sidebar of choices in a single group. In Bram's wireframe it's broken up into four sections:
* Type of document
* Topics
* Products
* Related searches

Comment 52

[Lee Tom]

Michael, it seems possible to keep the multiple facets organized in collapsible/expandable buckets as shown in the Product Landing page (comment #44). By default, these could be open, if you wanted everything exposed.

(In reply to Lee Tom from comment #44)
> Created attachment 645127 [details]
> SUMO -product landingpage - Firefox 04

Comment 53

[Verdi [:verdi] Best to slack me]

(In reply to Lee Tom from comment #52)
> Michael, it seems possible to keep the multiple facets organized in
> collapsible/expandable buckets as shown in the Product Landing page (comment
> #44). By default, these could be open, if you wanted everything exposed.
> 
> (In reply to Lee Tom from comment #44)
> > Created attachment 645127 [details]
> > SUMO -product landingpage - Firefox 04

Ah - so if you have multiple things expanded, would each one have a bold title and a dotted line separator?

Comment 54

[Lee Tom]

Attachment: SUMO - article 03 - San Serif font

Attached is a mockup showing our body copy in Open Sans regular VS. Georgia font. I think this font change could work well for the site. 

 
> Would it be possible to make the body text sans serif? Not necessarily the
> big headings, but the body text, captions and small texts.
> 
> Personally, I am hesitant to make the body text uses Open Sans Book, since
> it looks very anemic on my Windows XP machine, but it is a good start. If we
> are to change the body text to a sans serif, maybe making everything Open
> Sans would be great.
> 
> I know that this would break away from the standard Mozilla look, so maybe
> it’s something to be discussed.

Comment 55

[Verdi [:verdi] Best to slack me]

(In reply to Lee Tom from comment #29)
> Thanks for the feedback, Michael! I think Matt did a great job on the icons
> too - I'm sure we can make them stand out more by lightening up their
> backgrounds, as you suggested. 

The topic icons with white backgrounds look much better. I wonder if we can make the icons themselves darker though. The product icons still seem like much more attractive targets to me.

Comment 56

[Bram Pitoyo [:bram]]

(In reply to John Slater from comment #50)
> These look really good to me, thanks Lee. I like the changes you've made in
> this round...kudos to you & Bram for making this happen.
> 
> Are we done here?

I think Lee’s work is done here, but my work to adapt his design starts now.

Before adapting, though, there are a few things in the current design that I plan to change. I’m making these changes because some things got lost in translation between my lo-res wireframes and Lee’s mockups. And rather than asking Lee for another round of update, I figure I would do these myself.

Doing these changes will make for a good introduction on how Lee’s design files are structured. It will help me adapt his design shortly.

These changes:
* Will not. No new UI element will be introduced. They will just be repositioned, reordered or tweaked slightly.
* Will be attached to this bug, so you can review them.

I plan to do these changes. Please let me know if there are concerns or objections:
* Separate the breadcrumb bad from header and content, so that it looks obvious and gets used. At the same time, it can’t call too much attention to itself.
* Change most, if not all, fonts to Open Sans
* Populate product description field with real descriptions, and increase its text size
* Add a little globe icon to the left of “Deutsch”, to indicate language selection
* Organize the sidebars on the search result page so they work as intended (attachment 645130 [details], comment #53)
* Rename some of the sidebar headings. For example, the heading “Projects” should be called “Editing Tools”

I can start editing as soon as I have the PSD files.

Comment 57

[John Slater]

Got it, thanks Bram. Can you post your revisions here so we can take a last look as well? After all this back & forth I'd like to make sure that all parties are satisfied with the results (for example, I'm curious to see how the transition to Open Sans looks).

Comment 58

[Lee Tom]

I'm cleaning up my PSDs as we speak, and will link them here ASAP. Stay tuned.

Comment 59

[Rehan Dalal (Inactive)]

Lee: great! I'm starting to code up the header and footer so the sooner the better! thanks!!

Comment 60

[Lee Tom]

Rehan, here's the sumo_article PSD to start with. The others will trickle in behind it: 

http://cl.ly/432o3Q1n3o2K

Comment 61

[Lee Tom]

And here are the rest of the files...


sumo_home_contributor:
http://cl.ly/1A2c3V163N0r

sumo_productlanding_firefox:
http://cl.ly/0R0L1y0h0G3M

sumo_productpicker:
http://cl.ly/271F371z0t0G

sumo_search_result:
http://cl.ly/3J272K3c2R1W

Comment 62

[Rehan Dalal (Inactive)]

Awesome! Thanks Lee!

Comment 63

[Bram Pitoyo [:bram]]

(In reply to John Slater from comment #57)
> Got it, thanks Bram. Can you post your revisions here so we can take a last
> look as well? After all this back & forth I'd like to make sure that all
> parties are satisfied with the results (for example, I'm curious to see how
> the transition to Open Sans looks).

Yes. I will, and am going to start working on it now.

Comment 64

[Bram Pitoyo [:bram]]

What’s coming is all of Lee’s mockups that I’ve expanded and worked on. Feedbacks always welcome!

Changelog (applies to all files – I will attach per-file changelog later):
* The color of the header is muted: less blue compared to earlier mockups. I’m not sure if this is intended?
* The breadcrumb is now marked as a separated area from the content and the header. This will help it get used more.
* Lee did the majority of the work converting the font to Open Sans, but missed 1–2 instances. Everything’s Open Sans now.

Comment 65

[Bram Pitoyo [:bram]]

Attachment: SUMO - homepage - guest - 01

This is a new file: an adaptation of Lee’s design for the homepage that is seen by user who doesn’t sign in (ie. nearly everyone).

It doesn’t have a “for contributors” section, so the content moves up.

Comment 66

[Bram Pitoyo [:bram]]

Attachment: SUMO - homepage - contributor - 04

This is the homepage that logged in contributors will see.

What’s new in this version:
Added an up arrow to the right of the “for contributors” section. This indicates that this section can be minimized.

Comment 67

[Bram Pitoyo [:bram]]

Attachment: SUMO - homepage - contributor (minimized section) - 01

This is a new file: an adaptation of Lee’s design for the homepage that is seen by logged in contributors

Changelog:
* The “for contributors section” is minimized
* The down arrow on the right indicates that the box can be expanded

Comment 68

[Bram Pitoyo [:bram]]

Attachment: SUMO - product picker - 04

Comment 69

[Bram Pitoyo [:bram]]

Attachment: SUMO - product landing page - Firefox - 05

Changelog:
* The “Products and Services” section on the sidebar serves important navigational function. It is shown maximized and cannot be minimized
* This section is separated from the other sidebar sections by a space
* Selected sidebar item (“Firefox”) is now indicated by appearing lighter and sunken. I took Sean Martell’s sidebar idea and made an arrow shape to the left of the selected item.

Comment 70

[Bram Pitoyo [:bram]]

Attachment: SUMO - product landing page - Firefox (guest) - 01

See comment #69 for changelog.

Changelog addition:
Removed “Editing tools” and “For contributors” sections from the sidebar, because this page appears when user is not signed in

Comment 71

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - 04

Changelog:
* Added “Editing tools” and “For contributors” sections on the sidebar, because this page is shows to signed in contributors
* Added a state for selected sidebar item (lighter-colored, and sunken)
* Contributor sidebar and topic sidebar sections are separated by a space

Comment 72

[Bram Pitoyo [:bram]]

Attachment: SUMO - article (guest) - 01

See comment #71 for changelog.

Changelog addition:
Removed “Editing tools” and “For contributors” sections from the sidebar, because this page appears when user is not signed in.

Comment 73

[Bram Pitoyo [:bram]]

Attachment: SUMO - search result - 03

Changelog:
* The sidebar is split into three sections:
** Document type (everything, help articles, community discussions)
** Topic (all topics, getting started, privacy and security, etc.)
** Product (all products, Firefox, Firefox for Android, etc.)

* Added space to separate sections

* Added a state for selected sidebar item (lighter-colored and sunken)

Comment 74

[Bram Pitoyo [:bram]]

Coment #64 to #73 covered what I proposed to tweak and expand from Lee’s original design.

I’ll start working on adapting this design to the rest of SUMO next week. It will take longer than the time it takes for me to tweak, because I will have to create new elements and then style them accordingly.

Comment 75

[Lee Tom]

Hey Bram - Your adaptations are looking great so far! I just wanted to give you the new color values for the page header and backgrounds. Yes, I changed the colors to be consistent with the Firefox style guide. 

Here's a new PSD for the sumo_article page: http://cl.ly/0l3z0n1K1j3n
Please use the values I've set here for background color, and darker page header gradients. Also, the GRAIN texture should now overlay both page bg and page header. 

*note: changes, like your new recessed breadcrumb treatment are not reflected in this doc - just the color/gradient changes. 

Thanks, and let me know if you have any questions! Lee

Comment 76

[Lee Tom]

Also, let's use the standard Firefox link color convention:


Default Link - #0095DD

Hover Link - #00539F

Comment 77

[Bram Pitoyo [:bram]]

(In reply to Lee Tom from comment #75)
(In reply to Lee Tom from comment #76)

Thanks for the PSD and the link color convention. I’ll update the mockups appropriately. This week, I will focus on creating new pages outside of the five templates you’ve created.

Comment 78

[Bram Pitoyo [:bram]]

(In reply to Lee Tom from comment #75)
(In reply to Lee Tom from comment #76)

Thanks for the PSD and the link color convention. I’ll update the mockups appropriately. This week, I will focus on creating new pages outside of the five templates you’ve created.

Comment 79

[Bram Pitoyo [:bram]]

(In reply to MT from comment #31)
> Created attachment 639161 [details]
> mozillaSupport_icon_layout.jpg

Hi Matt,

What’s the status of the icon design, and if the deliverable will take some time, could you send over the latest icon that I can use on mockups?

Thank you!

Comment 80

[Bram Pitoyo [:bram]]

Attachment: SUMO - topic landing page - get started - 01

This is the landing page for Learn the Basics: Get Started.

A few notable things:

* I’ve changed the background and link color values based on Lee’s comments. I have also applied it to the rest of the mockups, but will only repost them here when they are truly finalized (I don’t want to spam).

* The icon that appears to the left of “Learn the basics” has a width of one column (60x60 pixels), and a style that’s similar to other white rounded corner boxes we have on the site.

* The text size is 16px: the same size that the six topic headings are set with, on attachment 646530 [details].

* Some headings on the bottom half of the page has either the ‘arrow’ or the ‘list’ icons. This is to indicate links that lead outside, and links that lead to another topic landing page, respectively. We might not need them or choose to use them, because all we care about is the user getting to the place that will solve her problem, but I did it here nonetheless.

Comment 81

[Kadir Topal [:atopal]]

Lee, Matt, Bram, this is great work! I can't wait to see this implemented on the site, it's a huge leap forward for us, thanks guys!

Slater, are you also okay with the direction of this? Rehan has already started adapting the footer and header last week, and we'll implement bigger chunks starting tomorrow, but I want to make sure we are on the same page before we move on.

Comment 82

[Kadir Topal [:atopal]]

Rehan: For the transition period we'll use the old iA for localized versions. As far as I can tell that should not be an issue, we just need to hide the main navigation bar (the one right above the breadcrumbs and belove the search, that goes "products and services, help articles, ...") because we don't have product and topic pickers in the old iA.

Comment 83

[MT]

Hi Bram, 

Here's a link to the PSD of my most recent help icons. Please let me know if you require anything else. http://cl.ly/1B1i3n34111u

Cheers,
Matt

Comment 84

[:ibai]

Great job! This looks really good!

Reading trough the bug I feel that the Search box in the main page has lost relevancy and while is still in a visible place it's somehow faded. Bram pointed to the research to explain that users prefer to browser than to search.

Our data in the other hand shows that around half of the people who interacts with the Home page (http://support.mozilla.org) performs a search. These are a lot of users (around 200K a day).

I'm worried that with this new design we have complicated the flow for this users. Initially (in the wireframes) we were giving this task a prominent place in the site but now it's gone.

Comment 85

[Verdi [:verdi] Best to slack me]

Attachment: Home page with darker topic icons

I think we need to experiment with darker topic icons. They look really washed out to me. I created this attached example.

Comment 86

[Verdi [:verdi] Best to slack me]

(In reply to :ibai from comment #84)
> Our data in the other hand shows that around half of the people who
> interacts with the Home page (http://support.mozilla.org) performs a search.
> These are a lot of users (around 200K a day).

We've never tested a less emphasized search box. Even today with our attempts to test this new design under the constraints of the current design we're still using the same, very prominent search box. I think that may account for the finding that about half our users search.

> 
> I'm worried that with this new design we have complicated the flow for this
> users. Initially (in the wireframes) we were giving this task a prominent
> place in the site but now it's gone.

The wireframes that Bram tested had the search bar very far down this main page. The later designs here have it up at the top in the commonly expected place so I think it's actually gotten more prominent on this particular page.

Comment 87

[:ibai]

With the actual layout of the page the Call to action for search is well balanced with the call to action to browse so I'm not convinced that we are influencing "browsers" to search or "searchers" to browse.

It's true that we never tried a different style but the important factor is to have an explicit and obvious way of going one or the other...or promote one versus the other because of a business reason (i.e. we know that users don't like one, or search is really bad, etc).

In this particular case, I'm inclined to think that an important amount of users who come to our site prefer to search for their issue (we have quantitative data to prove so) and we are investing good amount of development and SUMO time to improve search...changing the strategy now to promote "Browsing" is new to me. It may be the right strategy but I will like to get a little bit more background to understand it. Saying that "Research found that a majority of users browse rather than search." is not conclusive enough.

Comment 88

[Verdi [:verdi] Best to slack me]

Attachment: Article content with a white background

One thing we completely missed is the content background. On critical things like articles and search results (maybe even other pages) the content background should probably be white. We use that in places like http://www.mozilla.org/en-US/firefox/features/ and it's important on sumo for a couple of reasons:
* Users have complained about low contrast. We recently just changed the text and link colors to account for that.
* We include lots of screenshots and taking them against a colored background is not practical. We'll liable to end up with backgrounds that don't quite match the page backgrounds. 
* If visitors come to sumo from places like http://www.mozilla.org/en-US/firefox/features/ it's nice if the pages look more alike.

Comment 89

[Verdi [:verdi] Best to slack me]

A few questions/comments for Bram:
*The article used in the mockup is not typical. It would be great to see a more typical article mocked up. Maybe - https://support.mozilla.org/en-US/kb/private-browsing-browse-web-without-saving-info It has a video, screenshots, a warning and notes. 

*The article mockup doesn't include related articles. Those were removed from the wireframes for testing and never got put back in I think.

*We don't need editing tool on anything but wiki pages - so basically articles. Things like product landing pages will be part of the auto-nav and not editable.

*We may want to remove "Would you like to edit this page?" from the footer. If the footer is common to every page, that link will appear on many pages that are not editable.

*On the logged-out article the only indication that it's a wiki is the "Would you like to edit this page?" link in the footer. Maybe we should include the editing tools in the sidebar (collapsed) like we do today? Would also need it if we remove the link per my last comment.

Comment 90

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Verdi from comment #89)
> *We may want to remove "Would you like to edit this page?" from the footer.
> If the footer is common to every page, that link will appear on many pages
> that are not editable.

In mozilla.org, that link takes the user to https://www.mozilla.org/en-US/contribute/page/

In our case, we can send the user to a page about contributing to SUMO which could include information on contributing to the code too. What do you think?

Comment 91

[Verdi [:verdi] Best to slack me]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #90)
> 
> In our case, we can send the user to a page about contributing to SUMO which
> could include information on contributing to the code too. What do you think?

Ah - didn't know that. Makes sense - that works for me. 

Still need to address editing tools in the sidebar though.

Comment 92

[John Slater]

(In reply to Kadir Topal [:atopal] from comment #81)
> Lee, Matt, Bram, this is great work! I can't wait to see this implemented on
> the site, it's a huge leap forward for us, thanks guys!
> 
> Slater, are you also okay with the direction of this? Rehan has already
> started adapting the footer and header last week, and we'll implement bigger
> chunks starting tomorrow, but I want to make sure we are on the same page
> before we move on.

Yes, definitely. I do want to make sure the updated colors Lee supplied are implemented, but overall I love the work and am excited to see it go live.
(In reply to Verdi from comment #85)

> Created attachment 647305 [details]
> Home page with darker topic icons
> 
> I think we need to experiment with darker topic icons. They look really
> washed out to me. I created this attached example.

Lee, what do you think?

Comment 93

[Lee Tom]

I think it's fine to go a bit darker on the Help Topic icons. Thanks for making the reference mockup, Michael - it helps gauge how much darker you think would be effective. That said, I'd like to use values for the icon gradients from our style guide. They would only be a slight bit lighter then what Michael mocked up. 

Gradient Overlay:
#424F5A  to  #6A7B86 (Angle 90, Opacity 70%)

With regard to the white backgrounds for article content (comment 88), Let's please use the same filter/values seen in the white, raised, Search module from the Search Results page (this is also a standard treatment we're trying to lock down in our style guide)

Comment 94

[Lee Tom]

Attachment: Help Topics - darker icons

Here's a look at the darkness of the icons I was referring to, in contrast to Michael's mockup

Comment 95

[John Slater]

Thanks Lee.

Final thought from me here: there's been a lot of discussion and revision after we handed over what we thought were the final files...for the sake of an orderly process, that's really not the ideal way to handle it. Lee has a bunch of other projects piling up and we really need to redirect his attention to those.

That said, I would also ask you to please implement the pages the way they were designed (not including the various post-handoff tweaks that Lee & Bram have been discussing). I'm a bit concerned that what will appear on the live site won't really resemble what Lee did, which would be unfortunate...not to mention a pretty big waste of his time if so.

So, my understanding here is that Lee is finished with this project and that it will be moving to implementation soon. If you have any other design requests, please file a new bug and we'll address there.

Thanks!

Comment 96

[Bram Pitoyo [:bram]]

Thanks! I saw all your feedbacks, will incorporate them today, then post an update here.

My to-do list:
* Change background color value to one seen in the search box of the Search Results Page
* Change icon gradient to what Lee had suggested in comment #93
* Remove “would you like to edit this page” from the bottom of the page. Change it to contribute?
* Mock up the Private Browsing article and figure out how the “warning”, “notes” and “related articles” sections work


(In reply to Verdi from comment #89)
> *On the logged-out article the only indication that it's a wiki is the
> "Would you like to edit this page?" link in the footer. Maybe we should
> include the editing tools in the sidebar (collapsed) like we do today?

I will include the editing tools in the article logged out mockup, and take it out on the topic/product landing pages.

What I think: if user is logged out, the editing tools will appear on the bottom of the topic and product selections. If user is logged in, the editing tools will appear on top of the sidebar. Either way, it will be minimized by default. What do you think?

Comment 97

[David Tenser [:djst]]

(In reply to John Slater from comment #95)
> So, my understanding here is that Lee is finished with this project and that
> it will be moving to implementation soon. If you have any other design
> requests, please file a new bug and we'll address there.

I'd love to hear from Lee about comment 88 before we lock this one down. It makes product feature pages differ from support pages more than seemingly necessary.

For an example of a truly seamless transition from product to support pages, see the Chrome firstrun page: http://tools.google.com/chrome/intl/en/welcome.html. If you click on one of the blue plus signs, you're transitioned from product to support pages, but they feel similar enough in terms of colors and weight that you hardly notice it. 

The background color is probably an important factor that influences the "weight" of that transition. It would be great to hear from Lee if that darker article background color used on these mockups is intentional or if it would be better in plain white like we use on http://www.mozilla.org/en-US/firefox/features/. See also comment 88 for the other benefits.

Thanks, and sorry that this feedback feels late. I thought I was supposed to hold off on comments until Lee submitted the latest mockups, but I might have misunderstood that. Overall, I think the mockups are kicking some serious butt!

Comment 98

[David Tenser [:djst]]

Related to my above comment: Ibai's attachment 647322 [details].

Comment 99

[Bram Pitoyo [:bram]]

I spent most of today trying to address comment #88 (white background color on articles), and it proved to be trickier than I thought.

There are three main reasons why:
1. For starters, the sidebar is designed to go over a colored background.
2. Then there’s the header area (utility navigation, Tabzilla, main navigation, search box), a very prominent space that doesn’t look very appealing on white.
3. Go to http://mozilla.org or any page under it, and notice that white is used as a highlight color, not as a main background.

I try to be as faithful as possible to Lee’s visual design proportion, and came up with three different potential solutions with varying degree of white color coverage:
1. White covers article, but not sidebar or product name
2. White covers article & sidebar, but not product name
3. White covers article, sidebar & product name

Solution #1 looks very much like attachment 647322 [details] and Wikipedia.

I think it’s prudent that I wait for consensus before I continue my work, as the white coverage is a potentially major change to the design. The timing also works nicely, because it’s the end of my workday.

Comment 100

[Bram Pitoyo [:bram]]

Attachment: White covering article

The white box fits the grid, so it’s both harmonious to the rhythm of the design, and doesn’t require change to the width of the text box.

The style of the white box was sent by Lee in a PSD earlier in the day.

Comment 101

[Bram Pitoyo [:bram]]

Attachment: White covering article and sidebar

Comment 102

[Bram Pitoyo [:bram]]

Attachment: White covering article, sidebar and product area

Comment 103

[Kadir Topal [:atopal]]

I'd say no. 1, "White covers article, but not sidebar or product name", makes the most sense here. In this case we'd use white as intended on the other Mozilla sites, as a highlight, the article is exactly what we do want to highlight. That said, visually I find Michael's mockup the most balanced: attachment 647322 [details]

Comment 104

[David Tenser [:djst]]

Thanks for those proof-of-concepts, Bram. Personally I like all three of them and could go with either of them as they all serve the purpose of 1) highlighting the content we want the user to focus the most on, 2) adding more contrast/readability to that content, and 3) making a more seamless integration between Support and Product pages on mozilla.com

Let's hear from Lee though; I'm sensitive to Slater's comment 95 about us sticking to the output from Lee and want to make sure this concern with the background colors are properly addressed before we lock anything down.

Thanks again!

Comment 105

[Verdi [:verdi] Best to slack me]

(In reply to Lee Tom from comment #94)
> Created attachment 647345 [details]
> Help Topics - darker icons
> 
> Here's a look at the darkness of the icons I was referring to, in contrast
> to Michael's mockup

Thank you Lee!

(In reply to Bram Pitoyo [:bram] from comment #96)
> 
> What I think: if user is logged out, the editing tools will appear on the
> bottom of the topic and product selections. If user is logged in, the
> editing tools will appear on top of the sidebar. Either way, it will be
> minimized by default. What do you think?

Yes, I agree.

(In reply to Bram Pitoyo [:bram] from comment #99) 
> Solution #1 looks very much like attachment 647322 [details] and Wikipedia.
> 
> I think it’s prudent that I wait for consensus before I continue my work, as
> the white coverage is a potentially major change to the design.

I like solution #1 and agree we should hear from Lee. It's a big change.

(In reply to John Slater from comment #95)
> Final thought from me here: there's been a lot of discussion and revision
> after we handed over what we thought were the final files...

I'm really sorry about that. Honestly I totally missed the white background and when David mentioned it to me yesterday I felt terrible. I should noticed and said something about it a long time ago.

Comment 106

[Rehan Dalal (Inactive)]

The main nav (above the breadcrumbs and below the search box) is not localization-friendly the way it's been designed. I think it should have six equally sized buttons rather than six fluid sized buttons.

Comment 107

[Matt Grimes [:Matt_G]]

The latest mockups look amazing Bram. One question about the Topic Landing Page. Are those groupings done using our "custom" template or are the groupings going to be done based on tags? I think it could easily be done using tags, but just want to be sure.

Comment 108

[Lee Tom]

Attachment: SUMO - article 06

Hi everyone. Thanks so much for the quick feedback and considering the visual design while solving this article issue. I think we're all in agreement that Solution #1 ("White covers article, but not sidebar or product name") attachment 647322 [details] seems like the best solution; highlighting the content and making it easier to post screenshots without mismatched background colors. 

The main challenge I found with this revision is losing a bit of horizontal real-estate on the white background. Because the sidebar and main content are laid out according to our grid, we'll lose about 60px in width to give the content adequate padding - Not too big of deal, since we're scrolling really long anyway. Please see the attached mockup, and let me know what you think.

Comment 109

[Verdi [:verdi] Best to slack me]

(In reply to Lee Tom from comment #108)
> Created attachment 647585 [details]
> SUMO - article 06

This looks great to me. the column appears to be just over 640px wide which is big enough for a video and about as wide as the widest images we ever try to use.

Comment 110

[Bram Pitoyo [:bram]]

Attachment: SUMO - language picker - 01

In addition to the language picker, this mockup also has the menus translated in German, to demonstrate how the language would set and fit to existing measurement.

Comment 111

[Bram Pitoyo [:bram]]

Attachment: SUMO - language picker, small text - 01

This language picker is set in smaller text.

Comment 112

[Bram Pitoyo [:bram]]

(In reply to Lee Tom from comment #108)
> Created attachment 647585 [details]
> SUMO - article 06

I like this solution because the text column measures at 640px. We plan on making more tutorial contents with more pictures and videos, so having a measure that will exactly fit a 360p video works well.

Let’s clarify here. The white background will be used only on:
* Article page
* Search result page

It will not be used on:
* Top page
* Product landing page
* Topic landing page
* Product picker & language picker

Comment 113

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - 07

I took Lee’s treatment of the article and applied the breadcrumb and selected sidebar item styles.

Comment 114

[Bram Pitoyo [:bram]]

Attachment: SUMO - homepage - guest - 02

Updated with new icons from Matt (thank you so much, Matt!) and new header and background colors (Lee provided).

Comment 115

[Bram Pitoyo [:bram]]

Attachment: SUMO - homepage - contributor (minimized section) - 02

New icons, header and background color.

Comment 116

[Bram Pitoyo [:bram]]

Attachment: SUMO - homepage - contributor - 05

New icons, header and background color.

Comment 117

[Bram Pitoyo [:bram]]

Attachment: SUMO - product landing page - Firefox (guest) - 02

New icons, header and background color.

Comment 118

[Bram Pitoyo [:bram]]

Attachment: SUMO - product landing page - Firefox - 06

New icons, header and background color.

Comment 119

[Bram Pitoyo [:bram]]

Attachment: SUMO - topic landing page - get started - 02

Updated with Matt’s new icon (blackboard, chalk, 1-2-3).

Comment 120

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - private browsing - 01

Comment 121

[Bram Pitoyo [:bram]]

Comment 120 is a mockup of the Private Browsing article, which would represent a more typical SUMO article content.

Note the use of a simple yellow, sans stripes, to indicate warnings. This is done because everything else on the page is so subtly colored, and so blue, that adding a splash of yellow is enough to create contrast.

Also note the use of the same color as the background for the Note boxes.

Comment 122

[Kadir Topal [:atopal]]

This is really great work, and I love what I'm seeing here :)

One issue that might still need clarification is Ibai's concern in comment 84 about the deemphasizing of search. Would it make sense to add more weight to it by making it bigger than it currently is?

Also, Bram could you mockup an article page that has the editing tools and the contributor section expanded?

Comment 123

[Will Kahn-Greene [:willkg] ET needinfo? me]

I checked out https://bugzilla.mozilla.org/attachment.cgi?id=647856 and the nav bar ("Products & Services, ...") looks pretty low contrast. I'm having difficulty reading it.

Does that nav bar meet the WCAG guidelines? Specifically the contrast one: http://www.w3.org/TR/WCAG20/#visual-audio-contrast

Comment 124

[Will Kahn-Greene [:willkg] ET needinfo? me]

I'm concerned that it doesn't appear that we're doing an l10n or a11y pass on these mockups before we spend the time implementing them.

Particularly:

1. localized strings fit in the spaces allotted and if not, we should have some direction in regards to how the layout should flow

2. we meet accessibility guidelines from the WCAG. in particular, text sizes and contrast against the background


Are we expecting to do this inspection pass during development? If not, who's making sure this is getting done?

Comment 125

[Verdi [:verdi] Best to slack me]

(In reply to Kadir Topal [:atopal] from comment #122)
> This is really great work, and I love what I'm seeing here :)
> 
> One issue that might still need clarification is Ibai's concern in comment
> 84 about the deemphasizing of search. Would it make sense to add more weight
> to it by making it bigger than it currently is?

Like I said in Comment 86 my opinion is that I think it's been emphasized more in this design compared to the wireframes that Bram tested. When you blur the home page it's one of the only things still distinguishable http://people.mozilla.org/~mverdi/screenshots/front-page-weight-20120801-151123.jpg

Comment 126

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #118)
> Created attachment 647858 [details]
> SUMO - product landing page - Firefox - 06
> 
> New icons, header and background color.

Hey Bram - we don't need editing tools on this page.

Comment 127

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - private browsing - 02

Updated the private browsing article with a “related articles” sidebar.

Comment 128

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - private browsing (guest) - 01

This is the view that a non-logged in user (ie. almost everyone) will see on an article.

Note how the related sidebar is the only other white element on the page. It’s chosen for two reasons:

1) Related articles contain names that are long (ie. a sentence). In order to be usable in a small size, they need to be readable.

2) The white background signals that user needs to pay attention to this area equally as they pay attention to the main content.

In this page, you see 4 navigational tools that will go both vertically (up the level) and horizontally (between articles):
* Main navigation menu
* Breadcrumbs
* Sidebar navigation
* Related topics

There are plenty of choice here, and all of them work together to instill the fact that there are many ways to reach the one article that will solve the user’s problem, somewhere in the KB, and that he shouldn’t give up just yet.

Comment 129

[Bram Pitoyo [:bram]]

(In reply to Verdi from comment #125)
> (In reply to Kadir Topal [:atopal] from comment #122)
> > One issue that might still need clarification is Ibai's concern in comment
> > 84 about the deemphasizing of search. Would it make sense to add more weight
> > to it by making it bigger than it currently is?

In the low-res prototypes we have user-tested, the search box was as small as we have it in these wireframes. Furthermore, the position of it was in the top-left corner.

Lee thought that the utility navigation on top could be obscured, so we proposed the idea of moving the search box down, to the right of the logo.

This actually gives the search box a more prominent location than the first design, because there is no other element to the side of it. Just the search box. And it’s still located on the utilities area, where people usually go look for login, register, account information, languages, and search.

Comment 130

[David Tenser [:djst]]

Just wanted to say two things here:

* The mockups look absolutely stunning. I can't wait to see these implemented. Kudos.
* This is the first bug that I've seen that has >100 comments without going completely bananas. Kudos.

Comment 131

[Bram Pitoyo [:bram]]

(In reply to MT from comment #83)
> Hi Bram, 
> 
> Here's a link to the PSD of my most recent help icons. Please let me know if
> you require anything else. http://cl.ly/1B1i3n34111u
> 
> Cheers,
> Matt

Hi Matt, I think we’re just missing one icon, which is the document icon that you’ve thoughtfully provided on comment 32 as attachment 639162 [details].

I am going to use it to complete the look of the search result page (attachment 646541 [details]).

Could you send this file over?

By the way, you can see your icons integrated into the mockups on comment 115 to comment 119. Thank you!

Comment 132

[Kadir Topal [:atopal]]

Attachment: SUMO start page, grayscale

(In reply to Will Kahn-Greene [:willkg] from comment #124)
> I'm concerned that it doesn't appear that we're doing an l10n or a11y pass
> on these mockups before we spend the time implementing them.
>
> 2. we meet accessibility guidelines from the WCAG. in particular, text sizes
> and contrast against the background


Lee, I think Will has a point here, I'm attaching a gray scale version of the start page. As you can see most items on the page actually do have a high contrast, but the main navigation bar in particular becomes almost gray on gray. Since that's such an important part of the new design, we should make sure it is as readable as possible. What do you think, can we use different colors or some other solution to ensure higher contrast?

Comment 133

[John Slater]

We have gotten a TON of design requirements after the fact on this project...it would make things so much easier to know this type of information before the design work starts rather than during or after it.

Who can pronounce this bug done? We are now at 133 comments...way too much. 

My take: these designs have been reviewed and discussed and reviewed and discussed almost to the point of absurdity. Let's implement them and then make additional tweaks (as needed) after they've gone live and we see how users really react. Otherwise we could keep this process going for weeks and weeks and weeks without much progress.

Comment 134

[David Tenser [:djst]]

John is right -- let's close this one out and open new bugs for implementing this. 

I think part of the problem here has been confusion about when the review/discussion phase were supposed to begin and end -- it was unclear even for me when we were supposed to stop providing feedback. But now we're at a point where we should feel confident with implementing it and make any necessary minor adjustments as we do that. 

Bram, if you agree, please close this one and open up a new one for the implementation of the latest design. Thanks everyone!

Comment 135

[John Slater]

(sorry, I just saw the "Bram, please close" part as I was resolving...didn't mean to jump the gun. Bram, if you disagree please reopen...otherwise let's proceed as David suggested.)

Comment 136

[Bram Pitoyo [:bram]]

Reopened because, even though these mockups are ready to implement (in fact, Rehan had started implementing already).

We know that we had a limited time with Lee, so I only sent five page templates that will need to be designed. However, these pages don’t cover the whole of SUMO.

I will be responsible for the design of these pages, and refining Lee’s design so it fits our requirement.

As I wrote in comment 56, Lee’s design will not change. I’m doing an adaptation of his work: designing new elements where necessary, but mostly filling holes in the design: this sidebar is missing, what does a minimized state for a sidebar looks, and so on.

We have 3 remaining important pages that need to be designed, that this bug will cover:
* Support forum, individual thread view
* Support forum, list view
* Ask A Question process

We also have a few pages that are of lower priority to the ones above (SUMO has a lot of views). I will adapt Lee’s design to those, but this bug will not cover them.

Comment 137

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - thread list (alternative 1)

This is the mockup for SUMO’s support forum, where you view all of the threads.

Notable things:
* The wordmark for “Support Forum” isn’t final (looks too thick at the moment)
* The “Sort by” and “Show” sidebar can be collapsed
* I’m only listing 5 threads. Normally, we’ll show 20 in a page

Comment 138

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - thread list (alternative 2)

This is the second alternative to the last mockup, where every thread is visually separated by a box.

I like this one better because each thread on this page has the same appearance as a reply on the individual thread view page, which I’ll post soon

Comment 139

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - individual thread view

This view is what would appear when you click on a question. It’s a pretty complex page, as you might’ve noticed.

Notable things:
* I’m building this page to represent a relatively complex state that no one but our logged-in contributors will see. For example, most users won’t see “Edit this post” and “Delete this post” sidebar, and other page elements. To most users, this page won’t look as complex as it looks at the moment
* The “Solution chosen” and “Helpful reply” sections contain replies that are attributed to specific usernames. These usernames appear on the top right corner of the white box.
* There are a lot of green buttons here. Our design convention for green button is to use it only to indicate download-related concepts. I will change most of them to blue
* “Was this reply helpful” contains the same two white buttons that appear on the bottom of attachment 647853 [details] [diff] [review], for consistency. I thought that coloring these two buttons blue/greem would give the page too much color

Comment 140

[Bram Pitoyo [:bram]]

(In reply to Bram Pitoyo [:bram] from comment #139)
> * “Was this reply helpful” contains the same two white buttons that appear
> on the bottom of attachment 647853 [details] [diff] [review], for
> consistency. I thought that coloring these two buttons blue/greem would give
> the page too much color

This point should have referred to attachment 648250 [details]. Sorry.

Comment 141

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - thread list

Changelog:
* Changed the navigation to be on the right side of the screen. This is similar to how the forum look and works today, but it’s quite a big design change
* Changed all buttons to blue, eliminating arrows where it’s not necessary
* Added progress bar, just like how the forum is today

When implementing the progress bar, we have to make two changes:
* Update font-family to Open Sans
* Update the font sizes

There’s no need for any color change.

I basically kept the forum tools intact, on the right-side of the screen, to account for the fact that our forum’s heaviest users will be contributors, not users. Contributors are used to the existing interface, so we should implement the new skin first before changing the forum layout significantly.

Comment 142

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - individual thread view

Changelog:
* The green buttons are changed to blue
* Forum and thread tools are moved to the right-hand column
* Reduced text sizes for questions, “Solution Chosen” and “Helpful Replies” sections. This makes the layout very consistent with attachment 649559 [details] (thread list)
* Give each section a heading that’s separate from the white box, so it’s visually delineated
* The “Helpful Replies” section can handle multiple answers, not just one. This is how it works today

Comment 143

[:ibai]

Thanks for taking care of this. A couple of things:
- There are 2 options for the support forum view: To make it really usable for contributors or make it really friendly for users who are looking for answers. Traditionally we wanted to address the first. This designs, while really pretty, don't seem to be really actionable from the contributor point of view. There's a lot of plain text and scanning the page for the right information (what tags, does it have follow ups, etc) is more time consuming than the actual version.
- In the thread view we have changed where the menus and the names are located: from right to left and left to right. Is there a reason for it? 
- The solutions and helpful answers are promoted but don't stand out much or give any visual cue explaining that they are out of context in the conversation (i.e. you may need to read below to understand them fully).
- The labels "contributed" seem to be missing from your design. And the label "Solved" doesn't stand out as much as it used to be. This is related to the first point.
- The "Top Contributor" list should be a little bit more promoted. We want to let users and contributors know who are the people that help the most.
- The general view is elegant, yet it could be better representing what they are: conversations. The way they look today it could be anything. The actual design, while not perfect, shows a little arrow resembling a "word bubble", meaning: this person says..
- It's hard to follow the question owner follow ups. The tag should be more visible.
- Also, the amount of content per pixel seems to be pretty low compared to other forums where much more information is presents in one screenshot. Maybe we can use a smaller font for this side of the site?

They are a lot of implications of applying this design almost 1:1 to the forum and it's probably worth giving it a shot and rethink the whole forum as the next step. (This is out of scope of this bug).

Comment 144

[Lee Tom]

Hey Bram, 
Overall, I think these new mockups are looking great! I just wanted to quickly flag a couple things I noticed and suggest a couple things that might help: 

* Page title ("Support Forum") 
- We're no longer using the Meta font on our webpages - only for our tiered branding/wordmark system ie: mozilla support. 
http://mozilla.seanmartell.com/guide/index.php?directory=.&currentPic=23
- I would recommend using Open Sans here. I'm sure you could find a point-size that feels hierarchically appropriate to the page; ideally no heavier than Open Sans Regular. 

* Buttons
- I realize there are many avenues to access/navigate desired information through this site. When and if possible, could we reduce the amount of primary CTAs that we show (blue) and use more secondary/tertiary button styles (white/grey and hyperlinks) to navigate? I'm also not sure we want to use the "go" arrows on every button, as well. 
- For instance, the "Newer" and "Older" paginating buttons might resemble something more similar to Sean's User Flow buttons in the Sandstone Toolkit 
http://mozilla.seanmartell.com/guide/index.php?directory=.&currentPic=32

Please feel free to poke around the Sandstone toolkit that I've linked to above. Although it's not Final-Final, there are many elements we're hoping to standardize, and give some consistency across our web ecosystem.

Comment 145

[John Slater]

+1 for comment #144 - that stuff is important. Thanks all!

Comment 146

[Bram Pitoyo [:bram]]

Attachment: SUMO - search result - 04

Updated the search result page with the final document-type icons from Matt.

I am going to start cleaning up the attachment section of this bug by making old screenshots obsolete

Comment 147

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - thread list

Changelog:
* Set the “Support Forum” heading in Open Sans light
* Added Seans’s User Flow button as a replacement for “Older” and “Newer”
* Changed the “Add Tag” button style to white

The changes are made to respond to Lee in comment 144. Thanks, Lee, for the ideas!

Comment 148

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - individual thread view

Changelog:
* Set the “Support Forum” heading in Open Sans light
* Changed the “Add Tag” button style to white

Comment 149

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - thread list (alternative)

(In reply to :ibai from comment #143)
> This designs, while
> really pretty, don't seem to be really actionable from the contributor point
> of view. There's a lot of plain text and scanning the page for the right
> information (what tags, does it have follow ups, etc) is more time consuming
> than the actual version.

Ibai,

Thanks for the design feedbacks.

I spent the day going through several different iterations of a forum interface that’s markedly better for contributors, compared to the last design. The mockup I uploaded is the idea I’ve refined. Warning: it’s quite a departure from the last design.

It’s not final yet, and everything can change, so your comment will be important here.



Notable things:
* Contributors can quickly see whether a question has been solved, contributed to, or locked, by scanning the icons on the left-hand side of each thread, and whether each icon is colored or grayed out
* The icons might be confusing to new contributors, but they’re designed to not have captions by default so that contributors can scan and take actions quickly
* To help explain what each icon means, a caption will pop up when contributor mouses over the surrounding area
* The icons are still displayed even though they’re grayed out state, because they’re incentives. By seeing grayed out icons, contributors are encouraged respond to a question, which will increase solve rate. This is similar to how the progress bar operates: by exposing metrics, we help increase the forum’s respond rate
* To make scanning for unanswered questions and questions that a lot of people have trouble with easy, the number ‘0’ is highlighted in yellow and rendered in large size
* Tags are given its own space, which gives each tag a bigger click area
* The amount of content per pixel (information density) is increased, without reducing the font size



(In reply to :ibai from comment #143)
> - The solutions and helpful answers are promoted but don't stand out much or
> give any visual cue explaining that they are out of context in the
> conversation
> - The solutions and helpful answers are promoted but don't stand out much
> - The general view is elegant, yet it could be better representing what they
> are: conversations. The way they look today it could be anything.
> - It's hard to follow the question owner follow ups.

I have not addressed the problem with the individual thread list view. Specifically, these 4 points.

Several design elements can be used to help indicate chosen answer, helpful answers and thread owners, because I’ve used them in this design. The icons, maybe? I have thought of using colors (e.g. put a background color on chosen answer), but harmonizing them will be harder because our color scheme is so subtle.

But it’s a good idea to color-code things, or at least to give them some sort of a mark to indicate helpfulness and ownership.

I will also try to make the thread more ‘conversationish’. I am not sure what this could look like, but your point is a good one. At the moment, the design doesn’t look like a back-and-forth conversation.

This will be my job tomorrow. And if you can believe it, the forum is the last big item to be designed for SUMO (the rest, like AAQ, is not hard to adapt). Stay tuned, and thank you!

Comment 150

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - individual thread view (alternative)

In respond to Ibai on comment 143, I have also redesigned the individual thread view of the forum to make it more usable.

I spent the day looking at how other forum operates, and took some learning from that to this design.

Notable things:
* Question title is visually separated from the body text
* Question metadata is presented directly below the title. This parallels the information on the list view: # of replies, # of people who have the problem, and who replies the last
* Chosen solution has a checkmark icon and is colored green, similar to how it works in the thread list
* Helpful replies has a heart icon and is colored yellow
* Chosen solution and helpful replies are integrated into the question box
* By not treating the two as separate entities, it will help explain that they are related to the question at hand, but must be read fully in context (ie. below) in order to understand
* Question owner has a head icon (I took it from Matt’s community icon) and is colored orange
* By color coding and associating things with icons, contributors can follow the question owner follow ups by scrolling down and scanning
* I can’t put a “word bubble” in the exact shape. Instead, I have triangles that are pointing to the avatar’s picture. This makes the thread look more like a conversation
* Information density is increased throughout, without decreasing the text size. I was able to save quite a bit of space in the new design

Comment 151

[Kadir Topal [:atopal]]

Bram, I like the alternate style for the thread list, it's doing a much better job of using the existing space to convey information upfront. There are some issues though, and maybe we can address them here:

* In the alternate style there is no indication of time or date.
** I'd suggest displaying time and date for both the last reply and the original question. Fortunately that should be relatively easy as there is lot's of room below the question

* One of the most important parts when deciding whether to open a thread or not is the actual question content, but we only show a small part of it on the thread list
** It would be great if we could use this redesign to address this issue. Maybe we could show more of the question on hover, or we could reduce the space for other elements and reuse that for showing more of the question.

Comment 152

[Kadir Topal [:atopal]]

(In reply to Bram Pitoyo [:bram] from comment #150)
> Created attachment 650468 [details]
> SUMO - forum - individual thread view (alternative)
> 
> In respond to Ibai on comment 143, I have also redesigned the individual
> thread view of the forum to make it more usable.
> 
> I spent the day looking at how other forum operates, and took some learning
> from that to this design.
> 
> Notable things:
> * Chosen solution and helpful replies are integrated into the question box
> * By not treating the two as separate entities, it will help explain that
> they are related to the question at hand, but must be read fully in context
> (ie. below) in order to understand

I like the design otherwise, but this is step backwards from your original proposal. Showing the solution in full right below the question was a very helpful change. As far as I can tell Ibai just meant that there should be some indicator that it belongs to a discussion below. With that I agree. The same goes for the helpful posts.

Comment 153

[:ibai]

Comment 152 clarifies what I meant. Although, this alternative is something worth exploring. Apple new Discussion groups use our old solution (show the whole answer): https://discussions.apple.com/message/19214525#19214525 plus a pointer to the reply in context.

Lithium (a large community software provider) does the opposite: Just tells you that a solution exits and provides a link to it: https://www.en.adwords-community.com/t5/Improve-results-optimize-ROI-CTR/Charged-for-2-clicks-within-a-minute-for-same-keyword-and-user/m-p/46518#U46518

Both solutions have their pros and cons. An intermediate solution probably gives more context to the link and increases the chances of people clicking on it.

That said, the new design seems to demote the "Helpful" and "Solves" questions/buttons. For a one time visitors they are not really obvious and it's going to force us to rely on the email communication to get the solution votes. I'm ok with the "Solution" action being only e-mail if we revamp the template but for the helpful votes it will be good to allow random visitors to find the action. If we can't/want to make it more visible, maybe we can remove it completely and rely only on Solutions.

Comment 154

[Matt Grimes [:Matt_G]]

This all looks great! Do you have an image of what the alternate thread list view would look like with the filters expanded? I think I like that view since it makes the interface very focused on the end user. Most people looking for help probably aren't going to use the sorting options that we all use. We do want it to still be easy for our contributors though, so I'd like to see what those filters look like when expanded.

I also think the alternate individual thread view is my pick. I think the additional color and icons have much better eye tracking. It's much easier to pick out solutions and helpful votes. I think I agree with Ibai and Kadir that showing the solution in full below the question was a great idea. I'd like to see that layout, but with the colors and icons currently used in the alternate view.

Comment 155

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 1

On step 1 of the Ask A Question (AAQ) process, the user selects a product that s/he needs help with.

Comment 156

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 2

In step 2, user selects a category that best describes his problem.

Comment 157

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 3

In step 3, user is presented with some solutions to try. If none of them work, user is invited to type in his question into a search box.

Comment 158

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 4

In step 4, user is presented with search results from the query the entered into the box.

Comment 159

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 5

When user clicks “None of these solved my problem”, he either registers or signs in.

Comment 160

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 6

In step 6, user types in his question into the form fields. The query he entered into the search box in step 3 (attachment 651287 [details]) is used to populate the “Question” field. Several other fields, like Firefox version, OS and plugins, are auto-detected.

After this, what’s left are two screens:
1. A confirmation window telling the user to check his email and confirm
2. The individual forum thread view (attachment 650468 [details]) populated with his question

Item #1, being a confirmation screen, is a very simple interface comprising of just a couple lines of text. We can easily adapt the design there, so I don’t plan on mocking it up.

Comment 161

[:ibai]

Bram, I created a document with my feedback and added to https://bugzilla.mozilla.org/show_bug.cgi?id=758731

Some of the comments are UI related but some other are not. That's the reason to add it there. Feel free to incorporate the UI suggestions here.

Comment 162

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 2

Changelog:
* Made the selected product section and “change product” smaller
* Kept the heading, but removed the description. It now looks like “Product: Firefox (change product)”

Comment 163

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 3

Changelog:
* The selected “Category” section is made smaller
* The “Try Some” Solutions section is put within a white background, to clarify the fact that it’s the most important part of the page
* I forgot to mention on comment #162 that the “Which category describes your problem?” section is also put within a white background, for the same reason

Comment 164

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 4

Changelog:
* Removed the hardcoded list of articles, to focus only on the search box and the search results

Comment 165

[Bram Pitoyo [:bram]]

Attachment: SUMO - ask a question - step 6

Changelog:
Selected product and selected category sections are made smaller

Comment 166

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - edit - 01

This is the mockup for the article editing interface.

Notable things:
* There is no product, version or platform indicator in this view
* The text for “Editing” uses the Semibold weight of Open Sans
* The checkboxes are divided into three columns, but it doesn’t have to be. Two columns would also work

Comment 167

[Bram Pitoyo [:bram]]

Attachment: SUMO - army of awesome - 01

This mockup shows the new skin of Army of Awesome.

It’s been drastically simplified from the existing interface:
https://support.mozilla.org/en-US/army-of-awesome

And it now adheres to Twitter’s timeline display guideline. Our old interface actually violates some of the rules:
https://dev.twitter.com/terms/display-guidelines

Notable things:
* The same 1-2-3 steps seen in the Get Involved page (attachment 652004 [details]) is used
* The “Sign Into Twitter” button is moved up the page to a more prominent position
* Reply is located directly below the individual user tweet, consistent with how Twitter’s web interface behaves
* Real name is displayed alongside username, to conform to Twitter’s guideline

Comment 168

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - expansion behavior

(In reply to Matt G, Mozilla SUMO (irc: Matt_G) from comment #154)
> Do you have an image of what the alternate thread list
> view would look like with the filters expanded? […]
> We do want it to still be easy for our contributors though, so I'd
> like to see what those filters look like when expanded.

The expanded view is attached here.

* The “Top Contributors” section expands on hover
* The “Sort and Filter section expands on click. “Top Contributors” also expands to fill the vertical space that would otherwise be left empty


> I think I agree with Ibai and Kadir
> that showing the solution in full below the question was a great idea. I'd
> like to see that layout, but with the colors and icons currently used in the
> alternate view.

I’ll work on this soon. Thanks for the very specific feedbacks, Matt! It helps me a lot.

Comment 169

[Bram Pitoyo [:bram]]

Attachment: SUMO - profile - view - 01

Mockup for the View Profile interface.

See a sample of the existing page here:
https://support.mozilla.org/en-US/user/634444

Comment 170

[Bram Pitoyo [:bram]]

Attachment: SUMO - help articles - 01

This mockup visualizes what happens when user clicks on “Help Articles” on the navigation bar. The Help Articles page lists every topic that every SUMO article has.

Think of the Help Articles page as an extension of the 6-topics interface that we have on the main page (attachment 647854 [details]). It displays a lot more than those six.

Comment 171

[Bram Pitoyo [:bram]]

Attachment: SUMO - profile - edit - 01

Mockup for the Edit Profile view.

Comment 172

[Bram Pitoyo [:bram]]

Attachment: SUMO - contributor forums dashboard - 01

If you have a SUMO account, you can view the interface at:
https://support.mozilla.org/en-US/dashboard/forums

Notable thing:
I decided to label the thing “My Forum Contributions” because it describes clearly what the interface does, which is to list the articles that one has commented or created on the Contributor Forums. However, this heading might be confusing, because user might confuse it for the Support Forum. I’m open to name change or even coming up with a better, more descriptive name to call this section.

Comment 173

[Bram Pitoyo [:bram]]

Attachment: SUMO - inbox

This mockup visualizes the interface that shows up when user clicks the “Inbox” link on the top right-hand corner.

Notable thing:
* Currently, the link is called “Inbox” but the page itself is called “Messages”. I thought. I decided to call both “Inbox” for consistency’s sake. People are also used to the word “Inbox” to represent the concept
* The checkbox is put at the left side of the email listing, to make it easier to target with a mouse. This is also a behavior we see in many webmail clients
* The reply symbol is now shaped like a proper “Reply” arrow

Comment 174

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - private browsing - discussion - 01

This interface appears when contributor clicks on the “Discussion” link on the sidebar of the Article View (attachment 648248 [details]).

You can view the current design in this URL:
https://support.mozilla.org/en-US/kb/private-browsing-browse-web-without-saving-info/discuss

Comment 175

[Bram Pitoyo [:bram]]

Attachment: SUMO - article - private browsing - discussion - 01

Attachment 652683 [details] does not have a “Post a New Thread” button. This button has been added here.

Comment 176

[Bram Pitoyo [:bram]]

Attachment: SUMO - contributor forums - thread list - 01

See the current Contributor Forums interface:
https://support.mozilla.org/en-US/forums

Notable thing:
Today, we label the link “Contributor Forums”, but call the URL and the page title simply “Forum”. I have corrected this inconsistency. The page is titled “Contributor Forums”.

Comment 177

[Bram Pitoyo [:bram]]

Attachment: SUMO - contributor forums - individual forum - 01

This mockup is a continuation of attachment 652693 [details]. When user clicks on any forum on the list, he will be presented with this page.

Please note that every page will have 20 threads listed, rather than the five I mocked up here

Comment 178

[Bram Pitoyo [:bram]]

Attachment: SUMO - contributor forums - individual thread - 01

This mockup visualizes what happens when user clicks on a thread inside the contributor forums (attachment 652697 [details]).

It’s designed to look consistent to, but not completely the same as, the Support Forum (attachment 649988 [details]). The Support Forum is where users can ask questions and get help.

This attachment completes the 3 page templates inside the contributor forums:
* Forum list (attachment 652693 [details])
* Individual forum (attachment 652697 [details])
* Individual thread

Comment 179

[Bram Pitoyo [:bram]]

Attachment: SUMO - knowledge base dashboard - 01

This is a visual mockup of the first three sections of the Knowledge Base Dashboard, as seen on https://support.mozilla.org/en-US/contributors

These three sections will cover the styling of the rest of the page if applied in the CSS. Mocking up all five sections in this page will take a long time.

Comment 180

[Bram Pitoyo [:bram]]

Attachment: SUMO - karma dashboard - 01

Mockup of the karma dashboard (https://support.mozilla.org/en-US/karma/questions).

Note how I have left the existing chart size and positioning alone. We can change the chart font and coloring to match the new style later, but right now, the focus is to style the page.

The first 10 entries of the table are included. I didn’t render all ~50 entries to save time.

Comment 181

[Bram Pitoyo [:bram]]

Attachment: SUMO - advanced search - knowledge base - 01

SUMO’s Advanced Search interface (https://support.mozilla.org/en-US/search?a=2) has three separate tabs for different kinds of search scope.

This mockup covers the Knowledge Base advanced search interface.

Comment 182

[Bram Pitoyo [:bram]]

Attachment: SUMO - advanced search - support questions - 01

This mockup covers the Support Questions tab of the advanced search interface.

Comment 183

[Bram Pitoyo [:bram]]

Attachment: SUMO - advanced search - discussion forums - 01

This mockup covers the Discussion Forums tab of the advanced search interface.

Notable thing:
The “search in forum” field uses a series of checkboxes rather than a selectable text box.

The checkboxes do the same thing, communicates the idea of the search scope better, is more familiar to use than a text box (ie. no need to Shift–click to select multiple items) and is consistent with the rest of the advanced search interface.

Comment 184

[Bram Pitoyo [:bram]]

Attachment: SUMO - media gallery - 01

This is the mockup for the SUMO media gallery, as seen on https://support.mozilla.org/en-US/gallery/images

Notable thing:
The search box, sort/filter interface and the upload button has been reordered and made more logical.

The search interface is combined with the sort and filter UI, because one can think about the three as a related set of operations.

Upload is visually separated. It is set to the right of the page title.

Comment 185

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - thread list

The latest design for SUMO support forum, thread list view. Please follow bug 784614 for discussions related to this page.

Comment 186

[Bram Pitoyo [:bram]]

Attachment: SUMO - army of awesome - 02

Updated the Army of Awesome page design to conform to Twitter’s Display Requirements: https://dev.twitter.com/terms/display-guidelines

Specifically, referring to this section:
“Reply, Retweet, and Favorite action icons must always be visible for the user to interact with the Tweet.”

Please note that, although Retweet and Favorite is not relevant to Army of Awesome, the guideline has recently been promoted to a sort of absolute requirement, so we need to follow that (https://dev.twitter.com/blog/changes-coming-to-twitter-api)

Comment 187

[Bram Pitoyo [:bram]]

Attachment: SUMO - forum - individual thread view

The latest design for SUMO support forum, individual thread view. Please follow bug 784614 for discussions related to this page.

As we have designed every page that SUMO has (to my best knowledge), this will be the last design I’m doing for this bug.

A few modal/non-modal dialogues in the old style might exist, and will be tackled in a separate bug with a small CC list, so as to not overwhelm people.

Comment 188

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #178)
> Created attachment 653253 [details]
> SUMO - contributor forums - individual thread - 01
> 
> This mockup visualizes what happens when user clicks on a thread inside the
> contributor forums (attachment 652697 [details]).
> 
> It’s designed to look consistent to, but not completely the same as, the
> Support Forum (attachment 649988 [details]). The Support Forum is where
> users can ask questions and get help.
> 
> This attachment completes the 3 page templates inside the contributor forums:
> * Forum list (attachment 652693 [details])
> * Individual forum (attachment 652697 [details])
> * Individual thread

Looks like I missed this (along with others). This just landed and I have to say I don't like that the sidebar switches sides here. It's totally disorienting to me. I don't mind the options on the right hand side for the support forum because they are not navigation items (though they could easily be on the left hand side). But having navigation swap sides when you go from thread list view to individual thread doesn't seem right to me.

Comment 189

[Bram Pitoyo [:bram]]

(In reply to Verdi from comment #188)
> But having navigation swap sides when you
> go from thread list view to individual thread doesn't seem right to me.

I agree. Originally, I switched the sidebar around to match the individual thread view appearance as much as possible to match the Support Forum.

To wit, compare:
* Attachment 653253 [details] <-- contributor forums
* Attachment 655884 [details] <-- support forum

But now I’ve realized that the two forums don’t necessarily need to look the same, because they are optimized for different activities. In fact, the thread list view of the two already looks different:

* Attachment 652697 [details] <-- contributor forums
* Attachment 655510 [details] <-- support forum

So I agree with you in that we should swap the sidebar to the left side. This oversight happened because I was designing pages after pages and didn’t have much opportunity to look back and compare everything. Sorry.

I hope swapping the sidebar of the contributor forum’s individual thread view won’t be very hard to do.

Comment 190

[David Weir (satdav)]

Bram can we get the following edited

http://mozilla.disabledpeople.org/images/replybox.png

a line under the images so we know were to start typing

Comment 191

[Kadir Topal [:atopal]]

Hey satdav, that was fixed some time ago: http://www.evernote.com/shard/s4/sh/5661f099-62b2-4810-9086-5333a3660578/b092090c627ccfb6a359085bf6612cef

Closing this bug, as everything in here has been implemented. Follow up bugs are being created for further changes.

Thanks a lot, everyone for your contributions to the new SUMO visual design.