Closed Bug 867701 Opened 11 years ago Closed 11 years ago

Need visual and ux design for topic landing page

Categories

(support.mozilla.org :: Knowledge Base Software, task, P2)

Product:
support.mozilla.org
Component:
Knowledge Base Software
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
2013Q2

People

(Reporter: atopal, Assigned: rehandalal+mozilla)

References

Details

(Whiteboard: u=user c=wiki p=2 s=2013.12)

Attachments

(3 files, 3 obsolete files)

sumo - topic landing page - 01
557.21 KB, image/png
Details
Use animation to connect navigation items
740.13 KB, image/gif
Details
Back from Suptopic or Topic
130.91 KB, image/jpeg
Details 
We need the visual and ux design for the topic landing page that fits the topic/subtopic iA we plan to roll out this quarter.
There are at least 3 separate elements we can tweak within the topic landing page:
* Article summary
* Sidebar navigation
* The display of subtopics vs. articles 

Attached are various mockups for article summary.

Page 1, 2 & 3:
16px title, 14px summary text. Light, regular and bold font weights.

Page 4, 5 & 6:
18px title, 14px summary text. Light, regular and bold font weights.

Page 7, 8 & 9:
20px title, 14px summary text. Light, regular and bold font weights.

Page 10:
20px title, 16px summary text. Bigger summary text size makes each summary more readable, but also makes the page more lengthy. Big tradeoff here.

Page 11:
16px title, 16px summary text. To compromise for the space that the bigger summary text size will consume, I made the title size smaller here, but also bolder.


Notes:
* Page 2 is the article title size we use today (16px), coupled with the summary text size of the Search Result Page (14px)
* Page 7 is has text sizes that are exactly the same as our Search Result Page


Recommendations:
* Page 1 & 2 don’t have enough contrast
* Page 9 has too much contrast, and the difference looks jarring to the eye
* Page 7 is a copy of the style we use on the Search Result Page. It will be the easiest one to implement
* Page 6 is a nice compromise: each article title is set in bold, so they’re absolutely clear and readable yet not too large. But in order to be consistent, we have to make the Search Result Page conform to this style
Attached are mockups for the sidebar navigation that exists on each topic landing page.

Page 1, 2 & 3:
I investigated different ways of displaying topic and subtopic on the sidebar. Should both topic and subtopic be set in lowercase? Both in uppercase? Topic in uppercase and subtopic in lowercase?

Page 4 & 5:
We will display subtopics on the sidebar. When subtopics get selected, how should we display it so that two things are clear: a) What is the parent topic and how do user get back up to it? b) How does a subtopic differ from a topic? In these two mockups, the entire topic and subtopic area is colored slightly darker than the rest of the sidebar, to let user know that “you’re in this zone”. When subtopic is selected, it’s highlighted using the same color we use today. The capitalization creates a hierarchy. The capitalized text means topic, and sentence case text means subtopic.

Page 6 & 7:
Dark grey highlight color, the rest of the sidebar is colored white.

Page 8 & 9:
Blue highlight color, the rest of the sidebar is colored white.

Page 10 & 11:
Orange highlight color, the rest of the sidebar is colored white.

Recommendation:
* Stick to displaying topic in uppercase, because it’s already emphasized enough. When we add subtopics, use regular sentence case. Capitalization makes the hierarchy.
* Having a white background color for the sidebar might be too much contrast. We don’t want to draw attention away from the article content box. Use the existing color we already use today: off white.
* Which highlight color is the best one to use? It depends. If people are already using the sidebar to navigate, then the existing highlight color (low-contrast as it is) is good enough. If not enough people use the sidebar, consider changing it to a color with higher contrast.
* Basically, this means using page 4 & 5
Attached are various mockups for displaying subtopics, and making subtopic distinct from regular articles.

Page 1:
No change here. Subtopics are displayed alongside articles, and user can’t tell which one is which.

Page 2:
Subtopics and articles are separated with a thin, dotted grey line.

Page 3:
Subtopics and articles each get their own boxes, separated by a vertical space.

Page 4:
Subtopics get a box that looks like hot topics. Articles remain inside a white box. My concern is that subtopics /will/ look too similar to hot topics.

Page 5:
Subtopics are displayed underneath topic, so it’s clear that user is situated on the parent category, and what the child categories are. While this design may be clear, note how the sidebar mirrors the structure exactly, making it somewhat redundant.


Recommendation:
* If we choose to display summary for each article, then every subtopic will naturally look different from the articles. There’s no need to separate the two.
* Plus, subtopics are already listed on the sidebar, and we assumed that the sidebar is already getting used as a navigation tool. So if subtopics are displayed, they will get used.
(In reply to Bram Pitoyo [:bram] from comment #1)
> Created attachment 744456 [details]
> sumo - topic landing page - article summary variations - 01

I think we should try to make the style of these pages (the listing of articles at least) consistent or the same as the search results page. Would that make sense? It would be great if at the end of this process they shared the same styles. Any reason not to?
(In reply to Bram Pitoyo [:bram] from comment #3)
> Created attachment 744473 [details]
> sumo - topic landing page - subtopic variations - 01

I think we need more than just the sidebar to expose subtopics.

Just for reference, our current super simple quick solution is:

http://cl.ly/image/1U0O322g3v0G
https://support.mozilla.org/en-US/products/firefox/get-started

It would be great to measure and later compare the effectiveness.
This designs are a great inspiration!!

Agree with Comment 4. 

I would like to see consistency with the Search result listing: Icon, text weight, etc.

For the Subtopics: It would be nice to do 2 explorations:
- To show them on top of the articles as a different type of item of the same list (page 4 of sumo - topic landing page - subtopic variations - 01)
- Mix them with the results. We will need to evaluate how they get ordered (the total of visits to the articles in that group? the total of visits to the subtopic? the total for the most visited article of that subtopic?) This is the whole document 1.

Traditionally Subtopics are presented separately, but I see the value of having mixed and promote articles that are more important, this is also aligned with the notion that users don't really care if it's an article or a list of articles as long as they feel they are making progress. I think that separating subtopics and articles is more of an artifact of how KBs are organized with traditional Online Help software (rigid trees) and we don't really have that architecture.

Apart from this, the orange highlight on the sidebar looks like a call to action more than an indicator of the position. We should try a different type of highlight.
Just to clarify, we needed a place to store things and refer to them. The current attachments do not represent the current state of discussion, and parts of the mockups were not even considered from the start, just fillers to set things in context. We'll share the current mockups shortly, and feedback will be very welcome at that point.

That said, the order of items and how to fit in the sub topics is indeed a concern. Maybe one way to go would be to use viewcounts of the subtopic landing pages. More feedback on that is very welcome.
(In reply to Kadir Topal [:atopal] from comment #7)
> Maybe one way to go would be to use viewcounts of the subtopic
> landing pages. More feedback on that is very welcome.

Just a reminder that currently we use number of votes to sort and not view counts.

If we want to mix subtopics with articles, then I'm not sure what would be the best way to sort those in. I'm not sure what would be a "fair" comparison to weigh subtopics vs articles in the sort.
Votes as a proxy of reads. Thanks for the reminder Ricky.

I spent some good time thinking about it and I'm starting to believe that the total of votes of the articles grouped within the subtopic is a good start:
- If there's a bunch of articles in the subtopic that are important, we want to promote that subtopic.
- If there's an article that is really popular, it can outweigh the subtopics.
- Normally subtopics will show up on top and will have priority because they have more info than the articles.
If subtopics are getting the sum of all the votes/reads/views in it's children, then I think they will almost always appear at the top. It's an unfair comparison. But if that's going to happen, I'd rather just have them at the top and sort them by the topic sort order. At least as a v1.

Otherwise we have to figure out a way to implement this. Right now the document listings are straight out of our Elastic Search index. We'd don't have subtopics in there because they aren't articles. So, mixing them increases the complexity of this as we'd have to figure out a way to do that.
Ricky, if mixing is hard, as mentioned above, I would recommend going with the separated solution. The majority of navigations work like that: separating the elements based on what they represent: either the next level of topics or a piece of content (and this expands from help centers to ecommerce to anything in between).

In other words, the simple solution is the standard solution...and there may be a reason for it.
This is the mockup that incorporates all improvements made on the topic landing page, but previously scattered over many mockups (attachment 744456 [details], attachment 744472 [details] & attachment 74473 [details]):

* Topic name on the sidebar is bigger, even though the highlight color is the same. It’s also set in sentence case, making it more readable.

* Sidebar highlight color stays the same as today. The color of the subtopic area is different, and is described on bug 867702 comment 6.

* When user clicks on a topic, the page transitions and the subtopic box is maximized.

* Every subtopic under a topic has a gray box (with a slight gradient). This is a visual signal telling user that everything under the gray-colored box belongs under the same topic.

* The page comes with article summary. Attachment 744456 [details] has all the design variations. I’ve selected the design with optimal contrast between the title and the summary: not too large or small, and most importantly, not too thin. This will help alleviate the reading problems our users have.
Attachment #744456 - Attachment is obsolete: true
Attachment #744472 - Attachment is obsolete: true
Attachment #744473 - Attachment is obsolete: true
(In reply to Bram Pitoyo [:bram] from comment #12)
> Created attachment 746795 [details]
> sumo - topic landing page - 01

I am worried that we people won't ever see the subtopics because:
* They are only shown in the sidebar
* Your example has them on the very top item so it's kind of visible. But what happens when they are on one of the topics lower in the sidebar? The subtopics will be beneath the fold down in the noise area that I wouldn't pay much attention to.
Ricky, the subtopics are also displayed in the main content area, they are just not differentiated from articles. The assumption is that people don't care about the difference between articles/subtopics, as long the title sounds like something they are looking for and it gets them closer to the content.
(In reply to Kadir Topal [:atopal] from comment #14)
> Ricky, the subtopics are also displayed in the main content area, they are
> just not differentiated from articles. The assumption is that people don't
> care about the difference between articles/subtopics, as long the title
> sounds like something they are looking for and it gets them closer to the
> content.

OK, I guess that wasn't clear in the mockup. Comment 11 still needs to be figured out.
The UI is great, the assumption in comment 14 is something that we need to test.

For comment 11, can we use the platform meeting tomorrow.
I share Ricky's concerns. If people were using the sidebar to get to this page it would be one thing but they aren't. The navigation changes from buttons in the middle of the page to an expanding and collapsing sidebar. I'm afraid we will loose people.

Here's a super rough idea using one of Brams older explorations for the product page. We can use animation to help people make the connection. Here's what I'm thinking in this gif:
1. The product page features basically a sidebar that is expanded across most of the page.
2. As you hover over each topic, the subtopics expand, pushing the lower topics down.
3. When you select a topic, the giant sidebar shrinks to a normal sidebar keeping the indication of what you just selected visible the whole time. While that is happening we move hot topics off the page and bring in the list of articles.
It seems to me that the sidebar is creating a constrain.

Is the sidebar necessary? More specifically, do we need to offer access to the rest of categories from any specific category and subtopic? 

The outcome of removing the sidebar is that users will need to go back in their navigation (through the breadcrumb) instead of jump horizontally in the navigation.

Is that a bad thing? How many users are actually using the side bar to navigate horizontally?

If we agree that it's not necessary, we can use the sidebar to only show the next level of subtopics and it may be more clear for the users that they can keep digging it through that sidebar.

Or we can reclaim that space for something else (i.e. hot topics, etc).

Just an idea to explore.
Whiteboard: u=user c=wiki p= s=2013.11
Based on what we know, Rehan thinks this is 2pts.
Whiteboard: u=user c=wiki p= s=2013.11 → u=user c=wiki p=2 s=2013.11
This should go after a waffle flag to make sure that we can test it before it rolls out to everyone.

Moving forward for all these changes that affect the overall experience of the site (multiple pages/products) we should do it in 2 steps: 

First after a flag so the team can perform a user acceptance test for a couple of days and once that's cleared we can remove the flag.
Depends on: 878453
I didn't comment on the sidebar issues raised here, because they were made before we showed the product landing page. I think it should be clear now that there is consistency between the product landing page and subsequent pages and that the sidebar holds that flow together. 

Yes, this should definitely go beyond a waffle flag, and we should roll it out in a controlled way.

One thing to resolve still is the issue of how to order subtopics amongst the articles. As that is a significant issues I filed bug 878453 and made it a blocker for this one.
Assignee: nobody → rdalal
No longer depends on: 878453
We haven't finished this yet, dropping to next sprint.
Whiteboard: u=user c=wiki p=2 s=2013.11 → u=user c=wiki p=2 s=2013.12
Landed:
https://github.com/mozilla/kitsune/commit/959530460368960255abadee70f5c5b468320cc6

Pushed to prod by me, right now.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Great stuff! It looks quite good, although for now, I noticed that we missed to add the Subtopics to the list of articles as bug: https://bugzilla.mozilla.org/show_bug.cgi?id=878453

For now, let's show Subtopics on top followed by Articles.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Oops! One detail, do we want to show Topic descriptions below the titles? It would make the links more consistent with the article links, but I don't think we have Topic descriptions filled in with anything meaningful right now?
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #25)
> Oops! One detail, do we want to show Topic descriptions below the titles? It
> would make the links more consistent with the article links, but I don't
> think we have Topic descriptions filled in with anything meaningful right
> now?

Looking at the descriptions for Topics in the admin, let's not show the descriptions for now. But it's an interesting option we could add if the descriptions are clear.
Right...we don't have that...so for now let's not do it. It also adds localization overhead...and adding a good snippet for a whole subtopic could be challenging.

To be honest, my dream was to have icons similar to Search Results. With the File to represent an Article and a Folder (or similar) to represent a Subtopic.
(In reply to Ibai Garcia [:ibai] from comment #24)
> For now, let's show Subtopics on top followed by Articles.

Landed on master:
https://github.com/mozilla/kitsune/compare/959530460368...b033fcde6e44

And deployed to prod now.
What is the mobile site supposed to do for navigating from topic to subtopic and back?

We should probably list subtopics along with the article links like we are doing on the desktop site. But there is no obvious way to allow the user to navigate back up to the parent topic from a subtopic? Thoughts?
Yes to listing subtopics in the same list as articles.

To navigate back, we have the back button in the chrome and we can add a visual element on top of the list of articles (Maybe the name of the Topic and Subtopic) so you click on it to go back...or just an arrow (this shouldn't represent the same challenge as showing the arrow in the articles).
Some pretty pixels to illustrate what I meant.

Can we make sure that this lands early next week?
Yes I am working on this now!
Landed:
https://github.com/mozilla/kitsune/commit/2258f00c6152e75e634dafdb04eb61739ece0364

Has not been pushed due to "NO PUSHES ON FRIDAY" rule.
Deployed now.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: