785813 - [Kitsune/SUMO] Firefox OS / mobile site design

Status: RESOLVED FIXED

(support.mozilla.org :: General, defect)

Description

[Bram Pitoyo [:bram]]

This is where I’ll post visual designs of the mobile site design for SUMO that’s optimized for the Firefox OS Gaia interface (primarily) and Firefox for Android (secondarily), killing two birds with one stone.

This bug will cover the design of:
* Product landing page for Firefox OS/Firefox for Android
* Topic landing pages
* Search Result Page (SRP)
* Support forum
* Ask A Question (AAQ) flow

This cover may cover the design of:
* Android tablet interface

This bug will not cover the design of:
* Top home page
* Product picker
This is because, if we just focus on designing the experience for just one product (B2G or Firefox for Android), it will be a much better experience than trying to make the whole Firefox Desktop corpus accessible on the phone. Plus, we will significantly reduce the complexity and scope of the project.

Comment 1

[Bram Pitoyo [:bram]]

Attachment: product landing page - design exploration

Comment 2

[Bram Pitoyo [:bram]]

Attachment: menu - design exploration

Comment 3

[Bram Pitoyo [:bram]]

Attachment: topic landing page - learn the basics - design exploration

Comment 4

[Bram Pitoyo [:bram]]

Attachment: article page - design exploration

Comment 5

[Bram Pitoyo [:bram]]

Attachment: product landing page - 01

Using the latest version of Gaia on the product landing page.

Comment 6

[Michelle Luna]

Awesome! I like how this is coming along, thanks for doing this.

Comment 7

[Bram Pitoyo [:bram]]

Attachment: menu - 01

Unlike many other B2G apps, the menu on Firefox OS Support is located on the right-hand side of the screen. This is because we frequently need to use the back button, which needs to be located on the left-hand side so it makes sense.

Since there are a lot of items on the menu, I use darker colors to highlight areas that are related to each other. For example, the search bar and AAQ are related, sign in and register are also related.

If possible, I’d like to only display a subset of menu items that would make sense in the context of browsing for Firefox OS help, and then do away with the rest.

For example: Hot topics is a must have, but do we want Mozilla news?

Another example: Suggestion box is an awesome way to get Firefox OS user feedbacks, but do we want Help other users? Do we want to get contributors who are helping solely via their Firefox OS phone, knowing that contributing means posting a lot in the forum, and the phone interface is not ideal for writing long posts?

There are probably more things to think about that I don’t cover here. These items are starters.

Comment 8

[Bram Pitoyo [:bram]]

Attachment: topic landing page - learn the basics - 01

Several notable things here:
* Because any of our page title certainly will not fit the orange box, I elect to display the full page title below it, and then give it a gray highlight
* I kept the partial page title on the orange box even if I have to repeat it immediately below, to give context to the page when user scrolls down
* The articles are displayed with snippets of texts below it, kind of like a search result
* This is expressly designed for a bandwidth-limited experience, because user can decide beforehand whether the article is worth opening or not

Comment 9

[Bram Pitoyo [:bram]]

Attachment: article page - 01

This is a sample article page that includes pictures, warning box, TOC box and numeral items. It should give you an idea of how other page will look.

Note how I kept the gray box to indicate the title. This isn’t final. I’m only including it in this version for continuity with the topic landing page.

Comment 10

[Verdi [:verdi] Best to slack me]

The latest mockups look really nice Bram!

(In reply to Bram Pitoyo [:bram] from comment #0)
> This bug will not cover the design of:
> * Top home page
> * Product picker
> This is because, if we just focus on designing the experience for just one
> product (B2G or Firefox for Android), it will be a much better experience
> than trying to make the whole Firefox Desktop corpus accessible on the
> phone. Plus, we will significantly reduce the complexity and scope of the
> project.

Although, I believe making the experience great for Firefox OS and Android is something that we definitely want to do, I don't think it has to (and shouldn't) come at the expense of the experience of navigating the mobile desktop help site. iOS (for which we don't make a browser) accounts for 42% of our mobile visits. I think we can assume that most of those visits are desktop related. In addition we have to assume that at least some of the Android visits (33% of mobile visits) are desktop related. That would mean that desktop mobile visits account for close to half of our mobile traffic (at the moment). 

So I think both the desktop product and the iOS device should be taken into account. And so we should design the:
*Top page
*Product picker
*OS and Fx version picker
*Topic refine/ability to list more topics

(In reply to Bram Pitoyo [:bram] from comment #7)
> Unlike many other B2G apps, the menu on Firefox OS Support is located on the
> right-hand side of the screen. This is because we frequently need to use the
> back button, which needs to be located on the left-hand side so it makes
> sense.

It seems to me that the B2G apps are all over the place on this. Mail and Calendar have menus on the left but Firefox and Marketplace have menus on the right. FWIW, menu on the right, back on the left looks good to me.

(In reply to Bram Pitoyo [:bram] from comment #9)
> Created attachment 656354 [details]
> article page - 01
> 
> This is a sample article page that includes pictures, warning box, TOC box
> and numeral items. It should give you an idea of how other page will look.

I would love it if we could keep the collapsible TOC that we have now.

Comment 11

[Bram Pitoyo [:bram]]

(In reply to Verdi from comment #10)

Verdi, thanks for the feedback!

> So I think both the desktop product and the iOS device should be taken into
> account. And so we should design the:
> *Top page
> *Product picker
> *OS and Fx version picker
> *Topic refine/ability to list more topics

Let me explain my decision. When the early versions of the mobile experience was designed, I, too, had the assumption that navigating to the Firefox desktop part via mobile is an important use case. So the earlier mockups were designed to showcase the full experience on the phone. Full experience means all products, all sidebars, and all tools.

Over months of conversations, I began to get the idea that navigating Firefox desktop via mobile device is an edge case. Optimizing SUMO for B2G, which has also been talked about for some time, further cemented that idea.

So I thought, okay, optimizing for one product is going to make design significantly easier for me. This is because fitting a lot of auxiliary information, sidebars and filtering mechanisms on a phone was done, and we’ve tested it, and it worked. But it feels more like a webpage that’s scaled down, more than a phone interface that’s built from the ground up.

Now, this is okay, and I don’t mind sort of returning to a more webpage-like direction. But I think we have to decide on what sort of direction we want, each with its own sets of positives and negatives.

Design it like a webpage that’s scaled down, and we’ll get the sidebars, pickers and refine+focus feature, but the interface cannot be simple.

Design it like an app, and it will behave like a good phone citizen, but some of the sidebars, pickers and refine+focus have to go.

Now, the final solution would probably be a compromise between the two, but I have very limited time to work on the visual design side – just until the end of the week at the moment – because there are other projects that are also important (translation tools), and other B2G works outside SUMO (Marketplace Developer).

It would help if we know what we want, and if I can get an idea as to what sort of experience we want on these devices:
* Firefox OS phones
* Android phones and tablets
* iPhones and iPads

One possible solution is to make the experience different on each device.

For example:
* On Firefox OS phone, we make it show the B2G product landing page by default, and make it feel like an app. Switching to Firefox Desktop is possible, but not going to be presented on the first screen
* On Android and iOS, we make it show the home page by default, not the product landing page, and make it feel like a mobile website. Switching to Firefox Desktop is obvious, because it is presented on the first screen

Or we can just decide on one experience across all mobile device:
* Either make everything feel like an app (land on product landing page, switch product with the sidebar)
* Or make everything feel like a mobile site (land on home page, product picker is displayed on the first page)

Or, we can decide to design the app experience now, and the mobile site later. Or, design the mobile site now, and the app experience later. Then we deploy whatever is done earlier on B2G.

If we want the mobile site design to be done soon, our SUMO experience on B2G will not feel native to the phone. If we want the app experience to be done soon, then the mobile site might not get the sidebars and refine+focus.

For now, I think it helps for me to know what exactly we want. It’s all a compromise, but generally, rather than trying to design something that’s part-app and part-mobile-site, which will take a long time if we want the experience to be great, I would much rather do one thing, and do it very well.

Let me know what you all think of this, and how I should move forward!

> *Top page
> *Product picker
> *OS and Fx version picker
> *Topic refine/ability to list more topics

I think the product and OS/version picker could be designed because they’re fairly small pieces. The top page and refine+focus tools are more complex, and I am not confident that I can tackle them given what little time I have to work on it.

When deciding, let’s keep in mind how small the corpus for Firefox Android is, and Firefox OS will be, and whether we want to make Firefox Desktop available on mobile or not.

If we have 20–40 articles total for Firefox Android and B2G, we don’t need KB search, an OS/version picker, and the refine+focus tools.

But if we want to make Firefox Desktop available, all of these pages will have to be visually designed. They have been wireframed in low-res, with the exception of the refine+focus tool.


> FWIW, menu on the right, back on the left looks good to me.
> I would love it if we could keep the collapsible TOC that we have now.

Definitely yes on both of these. Thanks again for the feedbacks!

Comment 12

[Bram Pitoyo [:bram]]

Attachment: topic landing page - sort and filter - 01

This is the start of a made for mobile article sort+filter system.

The sort+filter UI on the desktop has a lot of form controls and possibilities, all of which are operable via the mouse. In this design, I am starting to think about which controls make the most sense given the phone’s limited screen real estate.

I am also thinking about ways to access the sort+filter interface that’s not via the sidebar. Putting sort+filter in the sidebar is the most obvious solution, but there are already a lot of menu items there, and trying to fit a set of selectors will result in a cluttered interface.

You’ll note here how user will be able to filter by pulling up from the article listing page

User can filter using one tag and either click “Done” or just drag his finger to scroll down the filtered article list directly.

The tradeoff: user won’t have the ability to set more than one filter at a time.

What do you think of:
* The access point for sort+filter
* The fact that user can only set one filter at a time

Problems I haven’t solved, but might not need to given that it’s a mobile interface:
* Where should we put the entry point for Article Editing / Discussion / Translation Tools? Do we need it?
* Topic selector can only be accessed by clicking the “Back” arrow. It is not presented at all times on the sidebar, because we have no sidebar to begin with. Is this an okay thing to do?

Comment 13

[Bram Pitoyo [:bram]]

Attachment: search result page - 01

Note how I try to use another mobile-specific UI convention here, which is the switcher below the search bar, to allow user to search either the KB or the Support Forum.

When I talked to Kadir yesterday, he mentioned the fact that, although the corpus for mobile is fairly small, there are a lot of solutions in the support forum that we can expose in order to make SUMO more useful. But right now the only way for an end user to access this is via search.

So I made the search facets very clear here.

Comment 14

[Bram Pitoyo [:bram]]

Verdi and I had a really good meeting several hours ago.

Here are some summary as to how it will impact the design:

1. Home page / Top page
* We won’t need the top page. By “top page”, I mean the Desktop home page that has a list of topics, products, mozilla news, hot topics, get involved, etc.
* Instead of the scaled-down version of the Desktop home page, what might be good is, if a mobile user is not using Android or B2G, and they type in s.m.o/ into their browser address bar, then the first thing they will see is a product selector. Once they select a product, they will be presented with a list of topics
* That way, we can prevent the complexity of trying to present a lot of items all at once on a small screen. Just one thing at a time. User will either get a list of product, a list of topics, or a list of articles
* The links to Products & Services, Hot Topics, Mozilla News, Get Involved, Register, Sign In, etc. will still be available by clicking the menu (“three-line”) icon

2. OS and Version pickers
* It is important to have them, but we don’t expect people to use them most of the time
* So, while on it is logical to place OS and Version switchers next to the product name on the Desktop version, it might not make sense on Mobile
* Currently, SUMO’s mobile interface puts OS and Version pickers on the very bottom of the page
* I will investigate better ways to switch OS and Version. If I can’t come up with something better, we might have to just put them on the bottom of the page

3. Sort+Filter interface
* The Mobile interface will allow user to filter a list of articles using one topic, rather than multiple
* However, we can enhance the one-filter constraint by using the find-within-the-page functionality
* For a demo, open the Address Book on your phone. Put a series of letter on the search bar. Notice how the list of people go down from many to few? This might be how we can help people narrow a list of 20+ articles down to a manageable few
* However, adding a search box that would perform a find-within-the-page functionality would add confusion with the main search box that actually queries the server and search SUMO. This is a problem that I will need to solve.
* Either way, this feature might not be a P1
* Or is it? Kadir can help confirm as to how important it is to launch the Mobile interface with a Sort+Filter interface

4. The Orange Bar, a.k.a. do we make it behave like an app or a website?
* If user access SUMO via an icon on their phone—this means, if we end up having a SUMO app on B2G—then we will use the Orange Bar and the back button
* If user access SUMO via the help menu of an Android product, or by directly typing the URL in the browser, then we will most certainly not use the back button. I don’t know the Orange Bar is necessary or not. The answer could be either.
* Start page on B2G and Android: product landing page
* Start page on iPhone and other mobile platforms: product picker
* More investigation is needed on whether user who access via the iPhone is looking for Firefox Desktop help

Comment 15

[Bram Pitoyo [:bram]]

Attachment: product picker - 01

Note that the product picker may show up as the startup page for iPhone.

Comment 16

[Bram Pitoyo [:bram]]

Attachment: product picker (with description) - 01

If we are going to have a big list of product, we might want to give each a description. Plus, it adapts to the existing Desktop design responsively.

Comment 17

[Bram Pitoyo [:bram]]

Attachment: topic landing page - sort and filter - 02

Here’s an evolution of the sort and filter UI. You can visually compare it to attachment 656777 [details].

Changelog:
* The filter UI no longer has a done button, because the article below it would auto update
* The search-within-the-page box appears below the filter UI
* The page title is gone from the content area, replaced by the full title on the orange box followed by the topic icon

I had a lot of conflict over whether the page title should be repeated below or not, but the next attachment should show some alternatives as to what may or may not work.

Comment 18

[Bram Pitoyo [:bram]]

Attachment: title and sort+filter ui layout variations

Here are three variations of the layout for you to evaluate.

I think that layout #2 works and looks the best. At the same time, I am worried that, if we put the search box *above* the title, the search result cannot be displayed directly below the search box, but below the dark-gray page title area instead. This might confuse the user.

Comment 19

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #16)
> Created attachment 657138 [details]
> product picker (with description) - 01
> 
> If we are going to have a big list of product, we might want to give each a
> description. Plus, it adapts to the existing Desktop design responsively.

Nice! Looks great with the descriptions.

(In reply to Bram Pitoyo [:bram] from comment #18)
> Created attachment 657186 [details]
> title and sort+filter ui layout variations
> 
> Here are three variations of the layout for you to evaluate.
> 
> I think that layout #2 works and looks the best. At the same time, I am
> worried that, if we put the search box *above* the title, the search result
> cannot be displayed directly below the search box, but below the dark-gray
> page title area instead. This might confuse the user.

I like that you were able to fit the topic into the orange bar in the first version. It's nice that there isn't duplication there. Doing this may make this design work for both an app or a website.

Looking at these it occurs to me that the refine by one topic thing will probably be plenty and the search within the page may be overkill. If you were going to search you may have already done it to begin with.

In all the versions, it's not clear to me how you would expand the refine controls. My guess is tapping on the orange bar but I worry that's not discoverable. Maybe some kind of hint (the OS notification bar has a grabber for instance) is needed?

Comment 20

[Bram Pitoyo [:bram]]

Attachment: support forum - thread list view

This is the thread list view of the support forum. You might remember that visually designing the support forum on the desktop interface took me the longest to do and revise, compared to other parts of SUMO. The mobile support forum is no different. This is because the forum needs to convey a lot of information to our heaviest users (contributors) and soon-to-be heavy users (new contributors who use B2G devices), in a relatively small space.

Notable things:

* Number of comments are represented by chat bubble icons

* The color of these chat bubbles mean different things:
** Dark grey: normal thread
** Yellow: this thread has zero reply, or last replied to by the OP, or only replied to by the OP. Either way, it needs your attention
** Green: this thread has been solved

* The colored bubbles were implemented fitting the “green checkbox” and “blue plus” icons in the mobile interface translates to a lot of clutter. Plus, those two icons are meaningless without the captions that indicate “solved/not solved”, “contributed/not contributed”

* The font size of the thread title is smaller than other pages (e.g. attachment 656352 [details]), because questions tend to be longer in size

* Both thread title and its excerpt are truncated to 2 lines. Do you think contributors would benefit from seeing the entire title and excerpt? This would obviously make the height of each thread much longer.

* The dark gray / dark blue handle below the orange bar contains forum tools. I will post these in the next few attachments

Comment 21

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - sort/show/filter

This is the first level of the forum tools. Keep in mind that I tried to include every tool we have in the arsenal, so I had to split these tools into many parts.

The first level, which is directly above the article, contains sort, show and filter interfaces. All three are presented inside buttons. These buttons will expand when user taps on them.

Comment 22

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - sort

This mockup shows what happens when user clicks on the “Sort” button.

Note how the button has the appearance of being pressed (ie. it recedes), and a menu pops up directly under it.

The menu will have this behavior:
* It will appear on top of the forum thread texts. It doesn’t “push off” forum texts under it
* Currently selected item is bolded
* Items that the user can select is on regular font weight
* When user taps on a menu item, the page will reload, and the position of the handle will reset to attachment 658790 [details]. That is, the forum tools will be minimized
* When user taps anywhere outside of the box *other than* the Sort, Show and Filter buttons, that tap will not do anything other than closing the box.

Let me elaborate on this behavior:
1. I open the thread list view (attachment 658790 [details])
2. I pull down the handle to display the Sort, Show and Filter button (attachment 658792 [details])
3. I tap on “Sort” to pop up a box that contains “Most Recent” and “Most Requested” (this attachment)
4a. If I tap on “Show”, the box that contains selections under “Show” will pop up
4b. If I tap on “Filter”, the Filter interface will fill the screen
4c. If I tap on any thread below, it will close the pop-up box
4d. If I tap on the orange box, it will close the pop-up box
4e. If I tap on the Menu button (“three line” icon), it will close the pop-up box

Comment 23

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - show

This mockup shows what happens when user clicks on the “Show” button.

The popup menu that this button invoke will behave as explained in comment 22.

Comment 24

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - filter

This mockup shows what happens when user clicks on the “Filter” button.

Filter is a lot different from Sort and Show, in that user is asked to enter keywords into the search box, rather than select from a list of facets.

With an interface this complex, the search box and explanation of its use is moved to a modal overlay dialog.

After entering keywords, user can tap “Filter Tag” to perform a tag search. We can change the button label to something else, of course. Maybe a simple “Search” will do.

If user taps “Cancel”, the whole modal dialog recedes, and the “Filter” button returns to its unclicked state.

Comment 25

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - progress bar

This is the second level of the forum tools. The first level being the Sort/Show/Filter buttons.

This level shows the progress bar.

Notable things:

* The text on the top of the progress bar has been truncated. It says “xyz questions have no reply”, rather than “xyz questions in the last 3 days have no reply. Help solve them!”

* The question number is now a link. It does the same thing that the “Help solve them!” text currently does.

Comment 26

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - top contributors

This is the third level of the forum tools. The second level being the progress bar, and the first level being the Sort/Show/Filter buttons.

This level shows the top contributors.

There is always going to be 10 people in our Top Contributors list. However, displaying 10 items in a vertical list will make the forum tools area very long.

So this list is displayed horizontally, but with a twist. User can horizontally swipe to horizontally scroll through the list.

Comment 27

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - top contributors - swipe area

This mockup visualizes the area that user’s finger can swipe to the left and to the right in order to scroll the list of top contributors.

Comment 28

[Verdi [:verdi] Best to slack me]

Wow Bram! These are looking great. You've packed a lot of functionality into a tiny area without making it look cramped.

Bugzilla seems to be having a problem displaying a few attachments - 658796 & 658799 - but we can make them out from others.

Comment 29

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view

This mockup visualizes what happens when user clicks on a thread.

Notable things:

* The structure is exactly the same as the desktop forum interface. That is, chosen solution is displayed in full, and helpful replies displayed in excerpts immediately below the question.

* Doing this caused the layout to be vertically challenging. Generally, expect a lot of scrolling on the user’s part. To save vertical space, we can take out the chosen solution and helpful replies display below the question. The decision is up to us on this one.

* I had to condense the button label “I have this problem, too” into “I have this problem”.

* Above every thread is a bar that contains the username, post date, and helpfulness rating. Keep in mind that, if helpfulness score is zero, the rating will not display.

* Labels like “Administrator”, “Moderator” and “Top 10 contributor” are displayed immediately below the bar, and has a jagged bottom edge. To find it in this mockup, look below the “I have this problem” and “Post a reply” buttons. The jagged, ribbon-like edge is consistent with the desktop forum design.

* Because these pages will certainly run long, these bars are color coded to make it easy for user to skim and get the information he needs.

* The color coding scheme is the same as the desktop forum design:
** Helpful replies are orange
** Chosen solution is green
** Question owner is blue

* The tools associated with each post (ie. helpful/not helpful, solves the problem, edit, delete, report as spam) is going to be addressed in the next mockup

Comment 30

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - expanded from the left

You could probably guess from this mockup how each post in the thread will display its tools.

User can either swipe from the left or the right-side of the screen to display these tools.

This mockup shows the partially opened tools.

Comment 31

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - expanded from the right

This mockup shows the partially opened tools. This time, it shows what happens when user swipes from the right-side of the screen.

Comment 32

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - expanded

This mockup shows what happens when attachment 659167 [details] and attachment 659168 [details] have fully moved to the center of the screen.

Notable things:

* Rather than asking the question “Was this helpful to you?”, only the button is displayed. But rather than simply saying an undescriptive “Yes” and “No”, it goes back to “Helpful” and “Not helpful”.

* Note how the two buttons are also labeled +♥ and -♥. This shows the user what clicking each button will do. Clicking on +♥ Helpful will add a number to the helpfulness counter (the current score is 879). Clicking on -♥ will subtract that number. Simple math.

* Immediately below is the button to mark that the answer has solved the problem. Again, with this one, I did not include the title “Does this reply solve the problem” in favor of a longer button label.

* Below that is Edit post, Delete post and Report as spam. A couple things to note here. “Edit this post” is shortened to “Edit post”. “Delete this post” becomes “Delete post”. And “Report as spam” is a typo that I had not corrected, as the wording should’ve been “Report abuse”.

Comment 33

[Bram Pitoyo [:bram]]

(In reply to Verdi from comment #28)
> Wow Bram! These are looking great. You've packed a lot of functionality into
> a tiny area without making it look cramped.
> 
> Bugzilla seems to be having a problem displaying a few attachments - 658796
> & 658799 - but we can make them out from others.

Thank you! Rethinking the interface so the mobile experience doesn’t become a second-class citizen or a subset to the desktop UX was why the forum design took a while compared to the rest of the templates. I think it’s time well spent, though!

I don’t have a problem opening the files you mentioned. Could you try opening attachment 658796 [details] and attachment 658799 [details] again?

I’ll send you these files over email, too.

Comment 34

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - expanded from the left

The last version has an incorrectly colored part on the bottom, so it has been cut off.

Comment 35

[Bram Pitoyo [:bram]]

(In reply to Verdi from comment #19)
> I like that you were able to fit the topic into the orange bar in the first
> version. It's nice that there isn't duplication there. Doing this may make
> this design work for both an app or a website.

You were referring to the fact that I was able to fit the whole title of the page inside the orange bar on attachment 657186 [details].

I will have to think about this one carefully. I had thought of extending this to the support forum - individual thread view (attachment 659166 [details]), but obviously, a lot of people ask very long questions, and it might be a problem trying to fit all of it inside the orange bar.

As I design more pages and encounter both longer and shorter page/article/thread titles, I think we’ll know what the best solution will be.

I have a feeling like sometimes we will display the whole title on the orange bar, sometimes we can fit the whole title if we make the text size smaller, and other times, the title will simply have to be repeated below because it’s much too long. I worry about consistency, too, if the way we set titles are not consistent. We’ll see.


> In all the versions, it's not clear to me how you would expand the refine
> controls. My guess is tapping on the orange bar but I worry that's not
> discoverable. Maybe some kind of hint (the OS notification bar has a grabber
> for instance) is needed?

Yes. The grabber/handle will be the way to access the refine+focus controls.

Initially, I wasn’t sure as to the right access method to use, and had several solutions. But through designing the support forum (attachment 658790 [details] and onwards), I now know that the same handle will be perfect for accessing the refine+focus controls on topic landing pages.

I will integrate the handle into the design later. Thank you for pointing this out! It’s important that I don’t miss small stuff like this, so things are made clear to implement.

Comment 36

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #29)
> Created attachment 659166 [details]
> support forum - individual thread view
> 
> This mockup visualizes what happens when user clicks on a thread.
> 
> Notable things:
> 
> * The structure is exactly the same as the desktop forum interface. That is,
> chosen solution is displayed in full, and helpful replies displayed in
> excerpts immediately below the question.
> 

My initial reaction is that it's really difficult to understand what is happening in this thread. There is a partial title that repeated in the question below. Then it's followed up with another post that's very similar to the original question - not sure why that is there. The solution is highlighted after than but cor-el's helpful solution stands out more. Of course if you keep scrolling down you see the solution again, this time highlighted in a way that makes it more important than cor-el's but because you can't see everything at once you loose the context. Also it's not clear that blue is for the owner because they aren't identified as the owner anywhere.

Maybe the problem is that like you said this is exactly the same as the desktop which, I think, can be confusing to begin with and that gets amplified when trying to make it fit on the small screen. So that makes me think the way to fix it may be to figure out what works here and then take that design back to the desktop view.

Comment 37

[Bram Pitoyo [:bram]]

(In reply to Verdi from comment #36)

Thanks for your feedback! I’ll get back to it after I’m finished working with the l10n tools, which is a priority for this week and possibly the next week, too.

Comment 38

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 1 - pick a product

The next few mockups are my early attempt at the AAQ flow.

In this first attempt, I’m trying to recreate the full desktop AAQ experience. Some things are not going to feel ideal.

By recreating things verbatim, I will know which elements needs to be taken out, redesigned, and kept.

If you’re looking for a place to start your feedbacks, here are some questions I’m thinking about as I design, that you can help me answer:

* Do we need to show the product selection page? Can we assume that the product will match User Agent? Or should we not assume anything and allow user to ask a question on any product?

* Do we need to show the topic selection, possible solutions and search results pages?

* Let’s say that, when user taps “Ask A Question”, we present him with a question form right away. Is this an option that we even want to explore? Are we worried that we’ll get a lot of low-quality questions if we make it too easy?

Comment 39

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 2 - pick a topic

The problem I am starting to have with this layout is: what text should I put inside the orange bar?

If I keep the orange bar text consistently say “Ask A Question” on every page, user won’t get the hint as to where exactly he stands in the process. Or is the text immediately below, is that enough information to indicate where you are?

If I make the orange bar text change with the page, as I do in this mockup, then it would violate the information hierarchy.

The information hierarchy should go from widest to narrowest:
* Dark blue bar: Where I’m at in the context of the process
* Orange bar: The heading of that process
* White: The content of that process

Note how the design of the page dictates that the orange bar should always be on top. But the information hierarchy says that the the dark blue bar should be on top.

This is pretty confusing, and will get even more confusing as we go along.

But please be reminded that this is only my first attempt at the user experience for Mobile AAQ.

Comment 40

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 3 - try some solutions

This layout will probably change later. Right now, I’m just matching whatever information we have on the Desktop AAQ.

Comment 41

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 4 - search results

Note how the top area has multiple areas and colors that does multiple things. Not ideal. This will be worked on as we go along.

Comment 42

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 1 - pick a product - 02

I spent the day trying to work on a solution that will solve our information hierarchy problem, and it turns out that simply removing the progress bar does the trick.

Progress bar pros:
* User can swipe horizontally to get an idea of where he is in the process
* It remains persistent on every page, just like the orange bar

Progress bar cons:
* I had to design it to look like a navigational tool because of space constraint, but it’s useless as a navigational tool. This means that user will almost certainly try to click on the indicator, but it will do nothing
* It makes the information hierarchy confusing

At the moment, I feel that taking out the progress bar is a good enough tradeoff in order to keep the navigation very streamlined and clear (ie. not confusing).

But feedbacks on this would be great. I’d like to hear more pros and cons on the progress bar on Mobile.

Comment 43

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 2 - pick a topic - 02

Comment 44

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 3 - try some solutions - 02

Comment 45

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 4 - search results - 02

Comment 46

[Michelle Luna]

Hi Bram,

Thanks for working on this! I can't see the progress bar mockup actually (wrong file type in attachment?), but I think a swipe-left/right interaction could work as you have designed it, need to think about this more. If you could put the screenshots together, that would help me out, rather than all separate files.

For your questions:
* Do we need to show the product selection page? Can we assume that the product will match User Agent? Or should we not assume anything and allow user to ask a question on any product?

[ml]I would prefer to us the UA for Android and Firefox OS, to make this as lean a process as possible.

* Do we need to show the topic selection, possible solutions and search results pages?
[ml]I'm undecided about this, thanks for mocking it up, certainly helps! When we include the registration steps, I think this is a long process to complete on mobile. Can you add those?

* Let’s say that, when user taps “Ask A Question”, we present him with a question form right away. Is this an option that we even want to explore? Are we worried that we’ll get a lot of low-quality questions if we make it too easy?
[ml]There are a few things we worry about: untagged questions, too many questions and duplicate questions. But, I definitely want to explore this simplification, because the user has already gone through several steps to get to this screen and will have a couple of steps afterward to register.

Comment 47

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - explanation of progress bar

(In reply to Michelle Luna from comment #46)
> I can't see the progress bar mockup actually
> […] but I think a swipe-left/right interaction
> could work […] If you
> could put the screenshots together

Attached is a set of mockups that explains some of my design and issues when designing the progress bar.

You’ll also be able to see the very first iteration of the progress bar that’s earlier then attachment 661723 [details] but never got posted, because I deemed it unsuitable for the mobile experience. So I moved along and designed the v2 progress bar style, which was what you might have seen on attachment 661723 [details].

If the v1 progress bar ends up being better with some tweaks, I am open to revisiting it. I just thought that v2 works better, but introduces its own set of problems.

The fact that the page title always has to show up inside the orange bar causes some information hierarchy problem. You’ll see how I thought of some potential solutions in this diagram, too.

Comment 48

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 5 - register / sign in

(In reply to Michelle Luna from comment #46)
> When we include the registration steps, I think this is a long process to
> complete on mobile. Can you add those?

I was planning on mocking up the complete process, so the registration is up next on my list.

Notable things:
* There exist only one form on this page, which is the Registration form
* How do we put two types of forms in one page? Putting the Sign in form immediately below Registration is the most obvious solution. To access this form, user can scroll down past the Registration form, or click on a link that acts like an anchor tag
* Furthermore, seeing a lot of form elements on the page stacked from top to bottom is also confusing to the user
* The solution I found today is to put the Sign in form on a modal window. That way, we can keep each page as simple as possible. I will attach this next

Comment 49

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 5 - register / sign in - sign in modal dialog

When user taps on the “Already have an account? Sign in” button, a modal dialog would appear with the Sign in form.

There might be better methods that I find later, but the idea here is to have only one kind of form in every page. That is, give Sign in and Registration its own page. They share many of the same form elements, so putting everything in one page might potentially confuse user.

Comment 50

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 6 - fill in details

Notable thing:
The “Troubleshooting Information” field has been taken out, because it’s irrelevant to this product.

An interesting idea we might consider:
We might want to give user the ability to upload a screenshot of their problem.

For example, if a site looks wrong in Firefox OS, we might ask the user to take a screenshot of his phone screen, then upload it to SUMO to help identify his/her problem.

When we do this, let’s make sure that we give an option to “Use last picture taken”.

Comment 51

[Verdi [:verdi] Best to slack me]

The AAQ flow feels like the forum thread view in that it's fairly confusing on desktop and that gets magnified in the mobile design. Maybe it would be better to simply the process as part of designing the mobile flow?

Comment 52

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

(In reply to Bram Pitoyo [:bram] from comment #38)
> Created attachment 661723 [details]
> Ask A Question - 1 - pick a product
Hi Bram:

Could we add Thunderbird to the mobile AAQ flow please?

and have that icon link to support.mozillamessaging.com ?

Comment 53

[Bram Pitoyo [:bram]]

Attachment: AAQ flow - low-res wireframes

(In reply to Verdi from comment #51)
> The AAQ flow feels like the forum thread view in that it's fairly confusing
> on desktop and that gets magnified in the mobile design. Maybe it would be
> better to simply the process as part of designing the mobile flow?

I agree to how confusing the AAQ flow can be. Having no progress indicator may make the page simpler, but it doesn’t solve the real underlying problem, which is the fact that AAQ takes a really long time to complete on mobile, and it will cause a lot of users to become frustrated.

Attached is the last AAQ flow that I’ve revised in late August, based on our last user testing. I believe it has been making limited runs on the mailing list, but it hadn’t been uploaded to any bug.

This flow is not significantly different from our current flow. Where by “not significantly different” I mean “developers don’t need to write new features”. So implementation will be easier.

The most significant difference between this flow and our current model is that, this flow omits the search process entirely in favor of letting users ask a question directly if the solution is not listed. Plus, there are a lot of wording tweaks that help make the experience feel more positive, and combining things on one page to make the process feel shorter.

These wireframes were designed for the desktop version, so maybe I should design a Mobile AAQ flow based on this? What do you and everyone think about this?


(In reply to Roland Tanglao :rolandtanglao from comment #52)
> Could we add Thunderbird to the mobile AAQ flow please?

Sure. These mockups may visually represents the final product, but the contents will change. We should definitely add Thunderbird here, like we should in the Desktop SUMO product picker.

Comment 54

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 1 - pick a topic

Here’s a redesigned AAQ flow that’s based on the low-res wireframes I’ve posted yesterday (attachment 662849 [details]).

With this one, the “try some solutions” and “search results” steps are eliminated, in favor of a more robust topic system.

The first step is to pick a topic. You’ll notice immediately that the number of topics has been increased. User are more likely to browse than search for solutions, so we should aim to answer as many questions as possible by increasing the number of topics and articles inside each.

About the product selection: we will auto-detect the product, and user can change it by pulling down the handle.

Comment 55

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 1 - pick a topic (expanded product picker)

We will auto-detect the product that user wants to ask a question about, but the product switcher can be made available up top.

Comment 56

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 2 - article list

Putting a search box in the AAQ interface lengthens the flow, so instead, we forego search in favor of putting more topics into the first step.

Tapping on any topic would bring user to this page: the article listing page.

Below this page are two buttons:
* “Try another topic” is the equivalent of hitting the “Back” button above
* “Post a question” will lead user directly to the question form

Comment 57

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 3 - post a question

This mockup visualizes the question form.

Why have I decided to put the question form before registration/sign in?

My line of thought:

* At launch and afterwards, we will probably get a lot of people who are asking questions — more than our usual share
* Not everyone who taps on the “Ask A Question” link will follow through to the end
* We have reduced the barrier to the question form by eliminating search in AAQ
* So, even more people are going to submit a question

We need a better way to:
* Prevent people from dropping out of the AAQ process
* Reduce the number of new accounts that never get used for posting

How to prevent people from dropping out of the AAQ process:
* People might drop out because they are wary of registration (what will they do with my information? Where will my question be posted? Is it public?)
* If we show the registration page before the form, we have to explain why people will need to register. They may drop out if they don’t read the information on the registration page
* But if we show the registration page after the form, we don’t need to explain why people will need to register. The form already demonstrates why user needs to register

How to reduce the number of new accounts that never get used for posting:
* Make it so that an account will only be created when a question form has been submitted

These are the reasons why I think that the question form should go before registration/sign in.

Comment 58

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - 4 - register / sign in

After user submits a question, he is asked to register.

If for some reason user fails to register, we can still capture what his question was. The data we captured might be bad, but it might be interesting.

After registration / sign in, the question is posted in the support forum

Comment 59

[:ibai]

Great work Bram! There's so much great stuff in this bug.

Regarding the AAQ flow, one of the big challenges that users face with Smartphones is text input so the idea of removing the search step is fantastic! We want to invite them to consume some content but not necessarily ask them their question twice. If it's frustrating to type your question once...imagine to do it twice.

What I'm thinking is, would it be possible to design a flow that allow users to minimize the amount of text they need to include in the box because we assist them in the process? Some ideas: 
* Provide more contextual information than on desktop in the actual box
* Offer a template where users input their problem in a form (phone, OS  as a drop down, type of issue as a drop down, one liner of the actual issue, etc). Then we add the grammar so contributors see a real question.
* Simple way of taking and uploading an screencast/screenshot of the issue.
* Record your question with voice? (This an the screencast may not be optimal for the initial Firefox OS markets).
* Some type of "safe for later" or "complete later from your computer" type of mechanism.

Keep the great designs coming!

Comment 60

[Bram Pitoyo [:bram]]

Attachment: topic landing page - sort and filter - 03

(In reply to Verdi [:verdi] from comment #19)
> (In reply to Bram Pitoyo [:bram] from comment #18)
> > Created attachment 657186 [details]
> > title and sort+filter ui layout variations
> 
> I like that you were able to fit the topic into the orange bar in the first
> version. It's nice that there isn't duplication there. Doing this may make
> this design work for both an app or a website.
> 
> Looking at these it occurs to me that the refine by one topic thing will
> probably be plenty and the search within the page may be overkill. If you
> were going to search you may have already done it to begin with.
> 
> In all the versions, it's not clear to me how you would expand the refine
> controls. My guess is tapping on the orange bar but I worry that's not
> discoverable. Maybe some kind of hint (the OS notification bar has a grabber
> for instance) is needed?

It took me quite a while to find the best solution for this, but Verdi’s feedback helped me narrow down to something workable.


> I like that you were able to fit the topic into the orange bar in the first
> version. It's nice that there isn't duplication there. Doing this may make
> this design work for both an app or a website.

The title of the topic is now fitted inside the orange bar. This will almost certainly introduce problems with locales that has long texts, like Portuguese or German.

The only way to solve this problem that I can think of is to truncate the topic title at the second line. That way, we’d be able to get most of the texts.


> Looking at these it occurs to me that the refine by one topic thing will
> probably be plenty and the search within the page may be overkill. If you
> were going to search you may have already done it to begin with.
>
> In all the versions, it's not clear to me how you would expand the refine
> controls. My guess is tapping on the orange bar but I worry that's not
> discoverable. Maybe some kind of hint (the OS notification bar has a grabber
> for instance) is needed?


Since we are taking out search, this problem is now simpler to solve. The refine interface can now be displayed on the top of the article listing right away, without the need to have a handle/pulldown menu to access it.

Attached are three different alternatives to approach the filter interfaces.

Option 1 uses the text “Showing all articles (48)”, where “Showing” is normal text, and “All articles (48)” is a tappable drop-down list. When user tap, the list is expanded top show all the topics.

Option 2 lets user switch between topics by swiping horizontally. You’ve seen this before on the support forum’s top contributors list (attachment 658801 [details]).

Option 3 has a search bar, but there is a button with a down-and-up arrow to its side. This button functions similarly to the drop-down list of Option 1. When user tap on it, the list of topics expand. While it’s not clear what topic the user is selecting at the moment, this option does allow the user to use the search bar to search within the page.

I think Option 3 is the weakest solution. Plus, it has a search interface, which we thought is not necessary in this context. But I’ve included it to show the many UI possibilities for the filter interfaces.

So, to summarize, we need decide whether Option 1 or 2 will work the best. At this point, we don’t know because no testing has been performed on this mockup.

However, I feel like Option 1 is the simpler amongst the two; and usually, simpler works better.

Comment 61

[Bram Pitoyo [:bram]]

Attachment: language picker

Comment 62

[Bram Pitoyo [:bram]]

(In reply to :ibai from comment #59)

There are some great ideas in your comment. I love it!

Voice record your question and screencast, for example, is an awesome way to get support. It may not work for a market with very limited bandwidth, but it’s a great way of describing very specific problems (and seeing user’s mental model – it’s like getting qualitative research data for free).

Upload a screenshot is a no brainer, and I need to implement that, but there has to be a good method that’s not clunky. Maybe we give user instruction? (“To take a screenshot, go to the page where you encounter problem at, and then press a combination of these buttons”).

Offering a template where user input their problem in a series of forms, and then we formulate a question based on that (like Mad Libs), is also interesting. It is a feature that will encompass more than just the UX, so it’s good to plan it out beforehand.

I’ll have to think about each idea carefully and determine the most natural way through iterations. More likely than not, we’ll launch in January with a minimum set of shippable features, then develop these awesome ideas for the next few updates.

But it would be great if, at launch time, our mobile web app can have just one feature—on top of everything else—that will make the Firefox OS support experience really stand out from the rest of the pack.

Comment 63

[:ibai]

Regarding the options my opinion is to go for 1. In option 2 the orange bar feels like a waste of space and a source of confusion, by presenting something that is incomplete and it's replicated just some pixels below seems to add more confusion than clarity.

Also the fact that we can present almost one more article seems to be a net win.

Comment 64

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - option 1

(In reply to Verdi [:verdi] from comment #36)
> the way to fix it may be to figure out what works here and then take
> that design back to the desktop view.

I had a time to go back and work on the individual thread view of the support forum this week.

I came up with a lot of solutions. Generally, they boil down to two principles.

We can either:
* Adapt the desktop interface, or
* Design something from scratch for the phone

The mockup that’s attached here is my attempt at designing using the first principle. It takes the original concept, and evolve it in several ways to address some of your concerns.

Notable things:

* The question title is shown in full, but question body is hidden below an ellipsis button. When user tap on this button, the question is shown in full.

* Doing the above will help eliminate clutter and confusion that happens when user asks a question with similar wordings in the title and body.

* The color bar for “Helpful Reply” and “Chosen Solution” remains orange and green, but they have been made smaller, so now they’re less distracting.

* More importantly, these colored bars have small strips on the left-side of the screen, that extend through the length of the post.

* Doing the above helps the user when he’s reading and scrolling through a very long page — something that’s bound to happen with forum pages like this. The color bar remains on the left at all time, constantly orienting the user about the status of the answer he is reading at the moment.

* It also helps when user leaves (let’s say, putting his phone to sleep) and then gets back into the mobile interface. When user is left with no context other than the texts on the page, the color bar will help.

Comment 65

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - option 2

The mockup that’s attached here is my attempt at designing an interface from scratch that’s unique to the phone.

The main problem that this design sets to solve is this:

* Forum answers are rarely very short. The right and helpful answers are not always located on the top positions.

* Color coding helps user distinguish the good answers, but scrolling rapidly and precisely to get to the good answers is a lot of work.

* It seems that our biggest problem isn’t color-coding, but vertical scrolling without clear, marked areas.


So, to solve it, this design instituted two principles:

1. Only display one answer at a time. This will allow user to focus, simplify the UI, keep vertical scrolling to a minimum, and greatly reduce reading confusion.

2. Allow users and contributors to pick, skim and switch between answers easily. Give them at-a-glance overview of the thread’s history, so they know what to do next. Has it been solved? Has the owner replied yet? Is there any helpful reply? Give them tools to manage difficult threads.


The solution involves condensing the entire thread (which can be very long) into a horizontal-scrolling navigation bar that will only display one answer at a time.

Using this navigation bar, a user can quickly skim through the thread’s many answers by swiping horizontally.
* Chosen solution is indicated by a large, green checkmark
* Helpful answer is marked with a yellow/orange heart
* A regular post is displayed with a chat bubble

The navigation bar will show all posts by default (it will also give him the number of posts in the thread). If this is overwhelming, user can easily filter for only the good information by tapping the link called “helpfuls and solutions”.

Immediately to the bottom, there is a line with colored dots that gives user an overview of the thread history. The display is chronological: the oldest post is on the left, and the newest one is on the right.

This area helps users and contributors do tasks like:
* Want to know if the thread owner has responded? Look for the blue dot to the right
* Want to know if the question has been solved? Look for a green dot, swipe to it, and tap it to display the chosen solution
* Want to know how many helpful replies the question have? Count the number of orange/yellow dots. To display helpful reply, swipe and tap.
* Want to get a sense of how active the discussion is? More dots on the line means more posts on the thread.

For reference and context, the question title and body is always included at the top.

To rate or reply to an individual post, navigate to that post and then tap the “Reply” button.


Displaying one answer at a time makes our interface very simple to navigate. The horizontal navigation helps users to skim, pick and choose good answers. Lastly, the colored dots on the line visualizes the history and activity of the thread, allowing users and contributors to get a bird’s eye view into each thread.

I hope these tools work together to help our users tame long, difficult threads, and get to the answers they want quickly.

Comment 66

[:ibai]

I really like the new "native" version and I bet it works wonders. It has one challenge though, and it's to understand how the navigation works. Can we do something to make it more explicit? i.e. you need to use this black bar navigation to see more content.

Great work!!

Comment 67

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - option 2

(In reply to :ibai from comment #66)
> […] It has
> one challenge though, and it's to understand how the navigation works. Can
> we do something to make it more explicit?

Thanks Ibai for the feedback!

I spent the day figuring out how to make the navigation more explicit, and came up with an updated mockup that can hopefully solve the problem.

You can compare it to the mockup I posted yesterday:
Attachment 664854 [details]

What’s new in this version:


1. First of all, the information scope of the navigation bar is reordered from the biggest to the smallest.

On the previous version, it was ordered like:
* Show all / Show helpfuls and solutions
* A list of five posts
* The overview bar with dots

On this version, the order is:
* Show all / Show helpfuls and solutions
* When user tap on any of the option above, the change is immediately reflected in the overview bar below it
* When user swipe left/right, or tap the left/right arrow on the overview bar, the change is immediately reflected in the list of five posts below it

What we did for the user is:
* First, show me how can I sort the thread
* Then, show me what each sorting method will do to the thread as a whole
* Finally, show me an area of the whole thread that I can drill down into

By ordering information from the biggest scope to the smallest, we help minimize confusion.



2. Second, the black overview bar has a left and right arrow to its side.

There are two ways to move the highlighted area around:
* Tap directly on an arrow
* Tap the white highlight box, hold, then drag in either direction

These arrows are contextual. When the leftmost part of the bar is in focus, the left arrow disappears to indicate that user cannot move further to that direction. Ditto for the right-side of the bar.

By contextually visualizing the direction of movement that’s possible to accomplish, we help reinforce the idea that these black bars can be used to navigate.



3. Third, the black bar has an upward-pointing triangle. This triangle points to the currently selected item, and is immediately reflected below.

When we load an individual thread page, we will automatically load the first answer.

With two ‘you are here’ indicators loaded by default — one a triangle on the bar, the other a black box around the selected post — we help user make the connection between the two areas.



4. The texts “Helpful answer”, “Chosen solution” and “Question owner” above the post have been removed in favor of putting the same information immediately below the navigation bar icon.

The captions have also been shortened to “post”, “solution”, “helpful” and “owner”.

Captioning the icon helps prevent mystery meat navigation, where questions like “What does a blue head mean? And why is the heart yellow?” will pop up.



5. Last but not least, on the list of five posts area, user can always swipe left or right to scroll within all posts. The highlight box on the black bar above it will move to reflect the current area of focus.


I think this helps make the navigation bar easier to use and discover!

Tomorrow, I will continue to design P2 pages and hopefully finish the remaining pages soon. I think the hard stuff had been worked out, but I’ll let you know if there are more hard design problems ahead.

Comment 68

[Verdi [:verdi] Best to slack me]

Wow this is much clearer. I wonder if you even need that part with the row of dots. A sideways scrolling list of posts, solutions, etc. looks like it may work all by itself.

Comment 69

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - reply

Attached is a set of mockups that visualize the steps to reply to a question or an answer.

In order to write a good response to the original question, or to be able to ascertain whether s/he has the same problem as the OP, a user or contributor need to read the question in full first.

To do that, s/he would first tap on the ellipsis icon. The area that previously only contains the question title will expand to include the body text, as well as the owner information.

On the bottom of this expanded area, the user will see two buttons: one for “I have this problem, too”, and the other for “Reply”.

When user tap on “Reply”, an area that contains the textarea will slide down. To make editing easier, the textbox will automatically be highlighted (ie. an onscreen keyboard will show up).

The two buttons are now gone, replaced with a “Cancel” button.

When user hits “Cancel”, the aforementioned two buttons will return, and the expanded textarea would slide back up, returning to the previous state.

After the user finishes inputting a response, s/he will tap on the blue button labeled “Post reply”.

Finally, the page will refresh on tapping the “Post” button. To give a visual feedback of what the user just did, the navigation bar will automatically go to and show the very last item on the list. Obviously, this item is the same one that the user had just posted.



You may notice on attachment 665303 [details] that every post has “Helpful”, “Not Helpful” and “Reply” buttons.

To reply to a specific post (rather than to the OP’s original question), a user would tap on that reply button. The behavior here is exactly the same as what I had outlined up top: the “Reply” button is replaced with a “Cancel”, etc.

Comment 70

[Bram Pitoyo [:bram]]

(In reply to Verdi [:verdi] from comment #68)
> Wow this is much clearer. I wonder if you even need that part with the row
> of dots. A sideways scrolling list of posts, solutions, etc. looks like it
> may work all by itself.

Yeah. I think that this interface may work all by itself without the row of dots. Displaying only one answer at a time, plus being able to filter and show any type of answer on demand, is the real killer feature of this page.

I thought that seeing the dots will be important for contributors who answer a lot of threads and want to be able to decide whether he should respond to a question, ask for clarification, or pass it up.

For regular users, my aim is to get them to the answers they’re looking for as quickly as possible. So I thought of setting the navigation bar to show “Helpfuls and Solutions” by default. And then they can view “All” when they want to. To them, having the row of dots don’t matter as much as having a good display option selected by default.

Plus, the row is potentially hard to develop. So maybe we should set out to launch without the row of dots in order to make it as simple as possible to implement, and then we could either design the row later, or save it for logged in contributors only?

Comment 71

[Bram Pitoyo [:bram]]

Comment on attachment 656352 [details]
topic landing page - learn the basics - 01

See attachment 663957 [details] for the latest version.

Comment 72

[Ricky Rosario [:rrosario, :r1cky]]

This bug has become pretty epic with so many comments and mockups. Would be great to summarize what is finalized so far and remove mockups that are not to be used.

Is there no home page?

Comment 73

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #72)
> Is there no home page?

Ah, the home page is Products & Services. Are all the mockups here still valid except the first few that are in greyscale?

Comment 74

[Ricky Rosario [:rrosario, :r1cky]]

Can we get the styles for pagination? We need these on the question thread list and search results pages, at least.

Comment 75

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #74)
> Can we get the styles for pagination? We need these on the question thread
> list and search results pages, at least.

And by styles, I just mean a mockup of what the mobile paginator looks like :).

Comment 76

[Bram Pitoyo [:bram]]

Attachment: topic landing page - sort and filter - 04

We’re going with Option 1 of attachment 663957 [details]. That option is uploaded here.

Comment 77

[Bram Pitoyo [:bram]]

Attachment: topic landing page - sort and filter (expanded list of topics) - 01

This is what happens when user taps on the “Showing all articles (48)” dropdown menu (attachment 666892 [details])

Comment 78

[Bram Pitoyo [:bram]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #73)
> Ah, the home page is Products & Services. Are all the mockups here still
> valid except the first few that are in greyscale?

I just cleaned up the attachment list (sorry for not doing this much earlier in the process) and everything you see there should be the final version of things.

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #74)
> Can we get the styles for pagination?

I was thinking about this since the start of the process, and could find any good pattern that will work for mobile pagination.

The thing I was thinking of is to load a certain number of results at start (say, 10), and then load the next set of results when the user reaches the end of the list.

Contents will still be served one pageful at a time, in order to keep bandwidth light.

Do you think that this would be something that’s possible to do?

My source was Google, who wrote that, in user testing, “users generally prefer the view-all option in search results”. You can read it here:

http://googlewebmastercentral.blogspot.co.nz/2011/09/view-all-in-search-results.html

Comment 79

[Ricky Rosario [:rrosario, :r1cky]]

(In reply to Bram Pitoyo [:bram] from comment #78)
> The thing I was thinking of is to load a certain number of results at start
> (say, 10), and then load the next set of results when the user reaches the
> end of the list.
> 
> Contents will still be served one pageful at a time, in order to keep
> bandwidth light.
> 
> Do you think that this would be something that’s possible to do?

Is it like an infinite scroll or will it have a link that says "View more >>"? Either way seems doable.

Comment 80

[Bram Pitoyo [:bram]]

Attachment: product landing page - 02

Updated with new font style and sizes.

Comment 81

[Bram Pitoyo [:bram]]

Attachment: product landing page - menu - 02

Updated with new font style and sizes.

Comment 82

[Bram Pitoyo [:bram]]

Attachment: topic landing page - sort and filter - 05

Updated with new font style and sizes.

Comment 83

[Bram Pitoyo [:bram]]

Attachment: topic landing page - sort and filter (expanded list of topics) - 02

Updated with new font style and sizes.

Comment 84

[Bram Pitoyo [:bram]]

Attachment: article page - 02

Updated with new font style and sizes.

Comment 85

[Bram Pitoyo [:bram]]

Attachment: language picker - 02

Updated with new font style and sizes.

Comment 86

[Bram Pitoyo [:bram]]

Attachment: support forum - thread list view - 02

Updated with new font style and sizes.

Comment 87

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - sort/show/filter - 02

Updated with new font style and sizes.

Comment 88

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - sort - 02

Updated with new font style and sizes, and a new popover menu style.

Comment 89

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - show - 02

Updated with new font style and sizes, and a new popover menu style.

Comment 90

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - filter - 02

Updated with new font style and sizes.

Comment 91

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - progress bar

Updated with new font style and sizes.

Comment 92

[Bram Pitoyo [:bram]]

Attachment: support forum - expanded - top contributors - 02

Updated with new font style and sizes.

Comment 93

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread

Updated with new font style and sizes.

Comment 94

[Bram Pitoyo [:bram]]

I managed to convert 2/3 of the mockups to the new font and sizes. The job ended up taking much longer than I thought, because the new font flows differently, so almost all text bodies had to be refit.

What’s not done yet:
* Support forum - individual thread - explanation of reply
* Ask A Question (all steps)
* Product picker
* Search result page

Comment 95

[Bram Pitoyo [:bram]]

(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #79)
> Is it like an infinite scroll or will it have a link that says "View more
> >>"? Either way seems doable.

It would be like an infinite scroll, where the set set of items will load once user scrolls to the last item on the list.

An infinite scroll will have a progress circle / spinner, as well. Stay tuned for the design of that!

Comment 96

[Bram Pitoyo [:bram]]

Attachment: search result page - 02

Along with font style and size updates, this version brings three new things:


1. Perhaps the biggest change is the fact that the header now contains an input field. This will make it even easier for our user to perform a search.

Source: https://www.dropbox.com/sh/pygek1oa9a5pspu/Fld1D9DQbW/Building%20Blocks/02%20Widgets/03%20Headers#f:OWD_03_Headers.png


2. Search facets now uses the top filters style. White item is selected, and gray item is not selected.

Source: https://www.dropbox.com/sh/pygek1oa9a5pspu/wwXwFfWNpN/Building%20Blocks/02%20Widgets/02%20Filters#f:OWD_01_Filters.png


3. The spinner appears at the bottom of the page when user has scrolled down to the end of the list, but the next set of content has not been loaded yet.

Source: https://www.dropbox.com/sh/pygek1oa9a5pspu/IUqzNGxmZ4/Building%20Blocks/02%20Widgets/05%20Progress%2BActivity#f:OWD_00_Progress%2BActivity.png

Comment 97

[Bram Pitoyo [:bram]]

Attachment: product landing page - menu - 02

The sidebar menu has been updated with two things:

1. The search bar is now the same size as the one found on the header of the search result page (attachment 668334 [details])


2. The navigation items how has subheaders, making it easy for users to sort out a long list.

Source: https://www.dropbox.com/sh/pygek1oa9a5pspu/G40wjH0Rbi/Building%20Blocks/02%20Widgets/11%20Drawer#f:OWD_00_Drawer.png

Comment 98

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - reply - 02

Along with new font style and sizes, these update contains one major change:

When user taps on “Reply”, the input box looks and behaves like it would in the styleguide.

Source: https://dl.dropbox.com/sh/pygek1oa9a5pspu/uPMigpaq8W/Building%20Blocks/03%20Common%20Controls/CommonControls_121003.jpg

(Scroll down 3/4 of the way to the bottom, look for an area labeled “Input areas”, and then look for the subheading “Input field - bottom [max size]”)

Comment 99

[Bram Pitoyo [:bram]]

Attachment: product picker (with description) - 02

Updated with new font style and sizes.

Comment 100

[Bram Pitoyo [:bram]]

Attachment: Ask A Question - explanation

This mockup integrates all the steps involved in the mobile Ask A Question experience in one sheet, and replaces all previous scattered mockups.

Reminder: thanks to all your feedbacks, the mobile AAQ flow does not mirror the desktop AAQ exactly. It’s faster to complete, and optimized for small screens.

There’s no significant design change between this version and the last, except:
* The font style and sizes are new
* This flow has the new style of search facet, in use on Step 2

Comment 101

[Bram Pitoyo [:bram]]

Attachment: menu - logged in - 01

This mockup visualizes what happens when user is logged in.

Compared to attachment 668349 [details], the sidebar menu now displays the username, inbox, settings, dashboard and sign out items.

Comment 102

[Bram Pitoyo [:bram]]

Attachment: profile - view - 01

When user taps on the menu item on attachment 669051 [details] that has a photo and a username, s/he is taken to the profile view page.

On this page, items that lead to another page (for example, my Twitter username would lead me to twitter.com/username) is put inside a box, to make the hit area large enough for the finger.

Menu items that don’t lead to another page (for example, name, city, country, bio) are not enclosed within a box.

Comment 103

[Bram Pitoyo [:bram]]

Attachment: profile - edit - 01

On attachment 669055 [details], when user taps on the Edit icon on the top-right corner of the orange bar, s/he is taken to the edit profile view.

This view is pretty self explanatory. On the Twitter and Facebook fields, user would only need to enter her @ username and her Facebook URL username, not the whole ‘http://www…’ text.

My design source and inspiration was the Firefox OS’ Contacts app.

Comment 104

[Michelle Luna]

Hi Bram,

This is looking good, and I'm glad to see the attachment 668369 [details] that brings it all together and I'd like for us all to meet to talk about it if possible, just to be sure we know what the result will be and set expectations, clear up any questions before implementation. Please join my Wednesday meeting at 3pm PT in my vidyo room to talk us through these designs.

On this final mockup for the profile, I'm concerned that this is so close to the Contacts app look/feel that it could be confusing for the user. Could we identify it in the heading somehow, to make it clearly distinct?

Thanks!
Michelle

Comment 105

[Michelle Luna]

I guess my other high-level question is about army of awesome. Have you looked at it and how we could optimize it for mobile? I feel like twitter is the easier/more common way people chat about stuff from their phone, so I was hoping it would be optimized for mobile in this redesign and be included in all the menus. But, maybe I missed it somewhere in this thread?

Thanks!
Michelle

Comment 106

[Bram Pitoyo [:bram]]

(In reply to Michelle Luna from comment #104)
> On this final mockup for the profile, I'm concerned that this is so close to
> the Contacts app look/feel that it could be confusing for the user. Could we
> identify it in the heading somehow, to make it clearly distinct?

Good point. My design was a first iteration, so it will evolve further. Thanks for bringing this up as a concern.


(In reply to Michelle Luna from comment #105)
> I guess my other high-level question is about army of awesome. Have you
> looked at it and how we could optimize it for mobile?

I haven’t looked at AoA for mobile at all, because my first priority was to get all the user-facing part ready for launch. Secondly, Twitter’s timeline display guideline got both stricter and more vague for mobile. Thirdly, I’d much rather have the mobile experience to have a very limited set of user-facing features that are crafted really well, rather than trying to do everything half-heartedly.

Contributor tools, translation tools, article editing and reviewing tools, dashboards and AoA belong in the bucket of “things that I can design, but are hard to fit into the existing SUMO mobile experience because the sidebar is getting full”

This is to say that, I can design the Army of Awesome interface, but I have no idea about a good, discoverable place to put it in the interface. To me, the AoA almost feels like it should stand on its own as a separate webapp that does one thing very well, and then the interaction could be awesome and intuitive.

But I agree that it’s an important feature to have for mobile, so I think I will work on it next.

Keep in mind that I am decreasing my time to work on SUMO projects to work on our Marketplace Developers site, which needs a lot of love before Firefox OS launches.

Comment 107

[:ibai]

> This is to say that, I can design the Army of Awesome interface, but I have
> no idea about a good, discoverable place to put it in the interface. To me,
> the AoA almost feels like it should stand on its own as a separate webapp
> that does one thing very well, and then the interaction could be awesome and
> intuitive.
> 
> But I agree that it’s an important feature to have for mobile, so I think I
> will work on it next.

I agree that the majority of Contributors facing interface makes relatively little sense except the "answering pieces": answering casual forum questions and twitter interactions. 

Your idea of isolating the AoA interface to a separated app is a brilliant idea and it could be the first exploration for the team to work on a SUMO app for the Firefox Marketplace.

If you could dedicate some cycles to this project before cutting more time to SUMO we will really appreciate it.

Comment 108

[Bram Pitoyo [:bram]]

Attachment: ask a question - explanation

The Ask A Question flow has been updated.

Notable changes:
* Step 1 and Step 2 now accurately reflects the content of the desktop AAQ
* Search facet is taken out of Step 2
* Added Step 5: a page in the support forum that is shown after the question is submitted. Please note the captions below the screenshot.

Comment 109

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread view - reply - 03

This is the revised explanation of support forum’s reply feature.

Notable changes:
* All mockups now have “Show more” or “Show less” links that expands and contracts  question text
* Added keyboard layouts that will show up when user taps on any reply text box

Comment 110

[Verdi [:verdi] Best to slack me]

w00t! That looks great Bram. I think that addresses the things we talked about in the meeting yesterday.

Comment 111

[Bram Pitoyo [:bram]]

Attachment: article page - table of contents explanation

This mockup visualizes two possible options for table of contents.

The first option is a refinement of our existing TOC. It not only expands and contracts, but also has line separator and plenty of space between list items for optimum tap targets.

The second option is something different. It does away with the table in favor of listing every heading on the page, but minimizing every section under it. When user taps on any heading, the section will expand, and on the bottom of the section is a shortcut to go back a section.

The second solution mimics what Wikipedia has done for their mobile interface, and is effective because users don’t have to scroll all the way up the page, all the way up to the TOC, to be able to jump to a different section in a non-linear way.

But my concern is that our contents have enough layers of heading hierarchies, so that listing them all becomes not only technically tricky (ie. which heading can we group together under one condensed section?), but also potentially confusing to navigate.

Comment 112

[Bram Pitoyo [:bram]]

Attachment: article survey explanation

The mockup visualizes the article survey widget that exists at the bottom of every article.

The widget’s behavior is as follows:

1. On the bottom of every article, a text labeled “Was this article helpful?” appears. Underneath this title text are two buttons: Yes and No.

2. When user taps on “Yes”, both the Yes and the No buttons will fade out to reveal a text labeled “Thanks!”

3. When user taps on “No”, both the Yes and the No buttons will fade out to reveal a text labeled “Sorry to hear that.” Underneath this text, a menu will appear noting several reasons why the article might not be helpful to the user.

4. When user taps on any list item in this menu, a feedback form will appear underneath, allowing user to type a more detailed response, or tap “Submit” to submit the feedback.

Comment 113

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread - 02

Replaced the gray ellipsis (...) button with a link that says “Show more”.

Comment 114

[Bram Pitoyo [:bram]]

Attachment: inbox - view

This mockup visualizes the inbox.

Notable things:

1) Perhaps the biggest change is the move of the “Menu” (three-line) button from the top right of the screen to the top left. This is solely done to make room for the “Edit” and the “New Message” buttons, which are now located on the top right. I realize that this makes the inbox look inconsistent to the rest of SUMO, but future version might change this, and this is the best solution I have at the moment to fitting three buttons on top of the screen

2) Unread messages have a teal-colored dot to the right of it. The time signature is also colored teal. Read messages have a gray-colored time signature.

3) Messages are written in a short format. This means writing “13 Mar” rather than “13/4/2012 8:43 PM”.

4) User’s avatar is displayed to the right side of the message. On Firefox OS, we’d normally fit the picture to the height of each message. But since SUMO’s avatar has a maximum size of 48x48 px, we won’t be able to use the full space—that is, unless we enlarge the avatars and pixelate it.

Comment 115

[Bram Pitoyo [:bram]]

Attachment: inbox - edit

This mockup visualizes the Inbox’s edit mode.

On attachment 670696 [details], the edit mode is invoked by tapping the pencil-and-paper icon on the top-right side of the screen, to the left of the plus symbol.

(“Plus” stands for “add a new message” and pencil-and-paper stands for “edit”).

The editing header is colored black with a little transparency, and will go over the orange header.

The interface is composed of circles with red outlines that indicate items that can be selected. Items in a selected state have a red fill with a checkmark.

After selecting items, user can use the black bar below the screen to either delete the messages, or mark them as read.

Comment 116

[Kadir Topal [:atopal]]

Thanks Bram, the survey looks great. However displaying the second level after the no vote, seemed a bit confusing to me. Maybe we should display something like "sorry to hear that, could you tell us why?"

Comment 117

[Bram Pitoyo [:bram]]

Attachment: messages

This set of mockups replaces the previous attachments labeled “inbox - view” and “inbox edit”, because it turned out that the messages situations needed a lot more mockups to explain properly.

This set contains seven different views:
* Inbox
* Inbox - edit mode
* Sent Messages
* Sent Messages - edit mode
* Read Message
* Reply
* New Message

Notable things:

* On virtually all email applications out there, Inbox and Sent Messages are located on the sidebar. But at SUMO, messages is only one small part of the whole site, and the sidebar menu contains items that are used site-wide. To prevent nasty navigation inconsistencies, Inbox and Sent Messages are made into facets. To compensate, the page title inside the orange bar must not be written as “Inbox” or “Sent Messages”, but simply “Messages”.

* Icon explanations: Pencil-on-paper means “Edit”. Plus means “New Message”. Paper with an arrow that goes briefly right and then back to the left means “Reply”. Paper with a right-facing arrow means “Send”. Trash can means “Delete”. Opened letter means “Mark as read”. Closed letter means “Mark as unread”. These are standard iconographies used across Firefox OS and the mail app.

* The Reply and New Message interfaces are shown with a keyboard to visualize how it works.

* The black bar on the bottom of the Edit and Read Message interfaces: I am not sure if it is supposed to be transparent or opaque. That’s something I will look around and confirm.

Comment 118

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #111)
> Created attachment 670668 [details]
> article page - table of contents explanation
> 
> This mockup visualizes two possible options for table of contents.
> 
> The first option is a refinement of our existing TOC. It not only expands
> and contracts, but also has line separator and plenty of space between list
> items for optimum tap targets.
> 
> The second option is something different. It does away with the table in
> favor of listing every heading on the page, but minimizing every section
> under it. When user taps on any heading, the section will expand, and on the
> bottom of the section is a shortcut to go back a section.
> 
> The second solution mimics what Wikipedia has done for their mobile
> interface, and is effective because users don’t have to scroll all the way
> up the page, all the way up to the TOC, to be able to jump to a different
> section in a non-linear way.
> 
> But my concern is that our contents have enough layers of heading
> hierarchies, so that listing them all becomes not only technically tricky
> (ie. which heading can we group together under one condensed section?), but
> also potentially confusing to navigate.

I like the wikipedia style - especially the one with the smaller type. My concern is that because we generally have long section headings unlike Wikipedia, the links seem less like links and more like just text. I wonder if there is a way to combine the styes of the two TOC or in some other way make the heading links in option 2 look more clickable.

Comment 119

[Bram Pitoyo [:bram]]

Attachment: article page - table of contents explanation - 02

(In reply to Verdi [:verdi] from comment #118)

This set of mockups is a continuation of attachment 670668 [details], and contains three options for table of contents.

They are responses from verdi’s feedback: “because we generally have long section headings unlike Wikipedia, the links seem less like links and more like just text”.


Option 3:
The first thing we can do is truncate the wording of items inside the Table of Contents when minimized, and only display them in full-length when expanded.



Option 4:
The second thing we can do is give each section inside the Table of Contents its own proverbial ‘page’.

This method reduces a lot of vertical scrolling and breaks down a daunting article into little bits of manageable chapters.

To go back to the Table of Contents, user can either tap the Back arrow on the orange bar or tap on “Index” on the bottom of the page.

To go to the previous or next section in the article, user will tap on the “<- Previous” or “Next ->” link on the bottom of each section.



Option 5:
This option works exactly like Option 4, but with a two enhancements:
* “<- Previous” and “Next ->” navigation is also available at the top of every chapter, not just on the bottom
* Table of Contents appear on the bottom of every page. This makes it it easy to jump to a page that’s not immediately next to the current chapter

The problem with Option 5 are twofold:
* We have back buttons that do two different things. One gets you to the previous page, and the other gets you to the previous chapter. This is a really bad behavior.
* Every chapter needs a title, but at SUMO, not everything has a heading, or needs to have a heading

With these options, too, I was able to make each table of content item look more clickable. The problem is, more clickability means more space consumed, and more space consumed almost always means that list items start looking less like list items and more like a bunch of texts. With more space consumed, user also has to scroll down more.

As you might have realized by now, option 4 and 5 takes methods and metaphors from ereaders and tries to adapt them into our articles. I might’ve gone too far in my adaptation, but these are iterations.

What do you all think of all five options?

Comment 120

[Bram Pitoyo [:bram]]

Attachment: article page - table of contents explanation - 03

This attachment contains another iteration of the table of contents.

To keep things organized, let’s call this one Option 6.

It’s a bit hard to explain the behavior, so I made a video out of it (which took a long time but I think was well worth it).

In this version, the Table of Content reveals the content in-page (ie. it does not direct user to another page) when user taps on a chapter title.

Note how each individual chapter is given its own box. This box ‘sticks’ on top of the page as long as user is viewing the content under it.

When user has finished the content and scrolls down to view the content under the next subheading, this new subheading box ‘pushes over’ the old box.

The nearest parallel I can find is the Contacts app on the iPhone, and the menu on the new YouTube app for iOS 6.

Link courtesy of Kadir:
https://www.youtube.com/watch?v=xuARzuVMKE8#t=181s

Comment 121

[Kadir Topal [:atopal]]

Thanks, Bram! Love this implementation.

I'm wondering about the overall heading. Since we can't show the full title anyway, and it's basically useless in this form, would it make sense to use the heading space for a TOC button, so people could jump between sections? Just an idea.

Comment 122

[Bram Pitoyo [:bram]]

Attachment: profile - view - 02

This mockup is a response to Michelle’s feedback on comment 104 about the fact the the profile view looked too close like the phone’s default contact app.

The profile view has been updated to make it look distinct.

Notable things:
* User avatar is displayed in its native size (48x48) inside a box
* The page is now organized into sections, which makes it easy to scan:
** Photo, name and country
** List of contributions
** Bio
** Contact information (email, website, Twitter, Facebook, IRC)
** Groups
* Note that the Edit button on the top right side of the screen will only appear when user looks at his own profile page

Comment 123

[Bram Pitoyo [:bram]]

Attachment: profile - edit - 02

The profile edit view is also updated in response to comment 104.

Notable things:
* Display name now stands alone to the right of the avatar picture
* Avatar is displayed full-size (48x48), with the link to edit underneath it
* Email and password cannot be changed by tapping directly on the field. Instead, user must tap on “Change email” or “Change password” below and to the side of the field. This behavior is similar to the desktop version.
* Added timezone and email correspondence language fields
* When a field points to a drop-down menu (e.g. timezone, country), the arrow now points diagonally towards the bottom-right

Comment 124

[Bram Pitoyo [:bram]]

Attachment: article page - table of contents explanation - 04

(In reply to Kadir Topal [:atopal] from comment #121)
> I'm wondering about the overall heading. Since we can't show the full title
> anyway, and it's basically useless in this form, would it make sense to use
> the heading space for a TOC button, so people could jump between sections?
> Just an idea.

Kadir, I think that this is a very smart idea!

Attached is a slideshow video that visualizes what the page navigation looks like if we put a TOC button on the orange bar.

What this option needs, though, is a good way to represent the “Table of Contents” concept in an icon. Right now, I use an unordered list icon and put it to the left of the menu icon, but as you can see, putting two things that look like a bunch of lines next to each other is very confusing to user! So that will be revised.

The concept of putting TOC in the orange bar is what’s important to see here.

To keep things organized, let’s call this one Option 7.

Out of all the solutions we came up with, I personally think that this one (Option 7) and attachment 670668 [details] (Option 2) represents the simplest, least circuitous way of integrating a TOC into a long article to be read on a narrow screen.

Comment 125

[Bram Pitoyo [:bram]]

Attachment: searching through the sidebar menu - explanation

This video visualizes the behavior that happens when user searches SUMO through the menu.

* The keyboard slides up
* User types in his search term
* User taps on “Search”, or the loupe icon to the right of the search box
* The keyboard slides down
* At the same time, the menu sidebar slides to close
* At the same time, the content on the main area, below the orange bar, fades out
* At the same time, the page title, on the orange bar, fades out
* After done fading out, the search result page gradually fades in
* The search result page interface is composed of:
** A search box on the orange bar
** Two search facets immediately below the orange bar, for KB and the forum
** The search result listing, each with a title and two-line snippet
** Search keyword highlights on relevant terms

Comment 126

[Kadir Topal [:atopal]]

Bram, could you please include a view of the log-in/registration process? We'd like to include that in the current sprint. I think we can mostly re purpose the one in the AAQ process for that.

Comment 127

[Bram Pitoyo [:bram]]

Attachment: profile view and edit - explanation 01

This is a series of mockup that combines profile view and profile edit into one interface.

It should help answer ricky’s implementation question on bug 804155.

Notes:

* Profile view is grouped into 4 areas: contributions, bio, contact info, groups

* Profile edit has links to change profile picture, email and password that are separate from the form text box. The text box themselves are not editable. That is, user will not be able to edit them by tapping.

* Change profile picture is an overlay menu that allows user to either take a new photo using a camera, or select an existing image from the media gallery app

* Change email and change password pages have a “Cancel” button that will return user back to the profile edit interface

Comment 128

[Bram Pitoyo [:bram]]

Attachment: register and sign in - explanation 01

(In reply to Kadir Topal [:atopal] from comment #126)
> Bram, could you please include a view of the log-in/registration process?
> We'd like to include that in the current sprint. I think we can mostly re
> purpose the one in the AAQ process for that.

Attached is a collection of mockups that describes the registration and sign in experience.

Briefly:

* The sign in page is now a full page, rather than an overlay. This means that, on AAQ, it will also be a full page.

* The registration page have been designed, but if we want to put a “Register” link on the sidebar menu, we have to give user a good enough reason to register other than to ask a question. Otherwise, it’s just filling up space.

Comment 129

[Bram Pitoyo [:bram]]

Attachment: ask a question - explanation

The Ask A Question explanation has been updated to show the new sign in page. Sign in is given its own page, rather than an overlay. This means that we won’t have to implement two different versions of the sign in page.

Comment 130

[Bram Pitoyo [:bram]]

Attachment: article page - showfor explanation

Rehan pointed out that the mockups so far has lacked showfor selectors for OS and version. They are important in case our users want to view Firefox desktop articles on their mobile devices.

Attached is a mockup of the showfor selectors in the article pages.

The design of the selector is similar to the one present on the support forum. See attachment 667360 [details] and attachment 667361 [details].

Comment 131

[Bram Pitoyo [:bram]]

Attachment: article page - table of contents explanation - 03

This attachment updates the table of contents explanation that was found on comment 120.

What would be my ideal scenario is to merge this behavior with attachment 672203 [details].

So, there will be two possible ways of navigating:


The first way is via the TOC menu:
* When user taps the TOC button on the orange bar, that section appears
* When user taps on any section, that section is automatically expanded
* And, the screen would scroll down to that section, like an anchor tag


The second way is by using the TOC listing on the page itself:
* When user taps on any section title, that section is automatically expanded
* However, the screen would *not* scroll down to that section automatically
* When viewing a section, its title remains on top of the content
* Title remains on top of the content, superseded only by the section next to it
* This is how the iOS address book listing works

Comment 132

[Bram Pitoyo [:bram]]

Attachment: support forum - individual thread - 03

The thread navigator has been made easier to navigate by having a clear facet indicator.

Compared to the last version, which is attachment 670689 [details], the thread navigator is now separated into two facets. It has a larger hit box, a clear indicator of what facet is currently selected, and is set in larger type size.

Because there is actually less space for the facet text now that the type size has been made larger. I had to remove the number of thread in a conversation that was previously put inside a bracket (for example: “Show all (15)”). I also had to shorten the phrase “helpfuls and solutions” down to “Helpful solutions”.

But I think that this a worthy price to pay for the fact that each facet now clearly looks and feels like it can be tapped, which aids affordance and discoverability (and help make our interface more obvious).

Comment 133

[Bram Pitoyo [:bram]]

Attachment: support forum - thread list view explanation - 01

This mockups combined the previously separate parts of the support forum’s thread list view.

Aside from the integration, the notable changes in these mockups integrated the feedbacks that you all had given at the Mobile Support meeting:

* Number of replies is now put directly below the thread title

* Thread status (“solved”, “contributed” or “needs attention”) is put on its side

* Sort by, Show and Filter buttons are now styled like proper Firefox OS buttons

* Sort, Show and Filter all has a consistent behavior. No more tiny popup menus.

Comment 134

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #131)
> Created attachment 677283 [details]
> What would be my ideal scenario is to merge this behavior with attachment
> 672203 [details].
> 
> So, there will be two possible ways of navigating: 
> 
> The first way is via the TOC menu:

> The second way is by using the TOC listing on the page itself:

I like the second way best but both ways work and having both options could be good. My concern with the first option is the layout of the orange bar. The more I look at it the more the truncated article title makes little sense there. Also the TOC icon is similar to the menu icon and placed right next to it. Maybe we can remove the partial title and have some other way of accessing the TOC in the orange bar (click the words "table of contents" or another icon or the same icon with more space between it and the menu button).

Comment 135

[Bram Pitoyo [:bram]]

Attachment: article page - table of contents explanation - 04

(In reply to Verdi [:verdi] from comment #134)
> My concern with the first option is the layout of the orange bar.
> The more I look at it the more the truncated article title makes little
> sense there. Also the TOC icon is similar to the menu icon and placed right
> next to it. Maybe we can remove the partial title and have some other way of
> accessing the TOC in the orange bar (click the words "table of contents" or
> another icon or the same icon with more space between it and the menu
> button).

Verdi, you’ve made some great points!

I had tried several solutions today:

1. As user scrolls down, the chapter title replaces the text inside the orange bar
Problem:
- Sometimes the title runs way longer than the space inside the orange bar
- To make the chapter title text smaller than it is today would decrease readability
- Figuring out a scalable orange bar is developmentally expensive, and not very elegant


2. As user scrolls down, the chapter title (with a light gray background) pushes the orange bar up and occupies the heading area. Plus, anytime the orange bar is replaced, the menu button is replaced with a Table of Contents button
Problem:
- User can no longer see the menu or the back button unless he scrolls all the way up the page
- Replacing the menu button with a TOC one creates more confusion, because it only gets replaced during a very specific condition, and then disappear, only to be replaced by a similar looking button


3. eBook-style navigation, where when user tap to make the orange bar and the black status bar disappear, and then, we will show the Table of Contents button underneath the orange bar area
Problem:
- I actually like the fact that the whole navigation goes away, allowing the user to focus on reading. But this is a technical article that is not read in a consequential mode, from start to finish, for fun and pleasure
– Making the Table of Contents only show up during a specific condition is confusing


Knowing that the fancy ideas wouldn’t work, I returned to the simplest possible solution: design a unique, custom icon to represent Table of Contents, and then put it besides the menu button. User taps the icon, and the TOC menu pops up.

In addition to this, user can also expand and contract each section individually. So we’ll end up with two methods of navigating.

I then went researching for the best icon to represent the concept of Table of Contents, and found that either one of these two objects could work:
* A book (open, closed, partly open)
* A bookmark

Then I found that an open book has a shape that’s more recognizable (ie. user has less chance to mistake it for something else). And, even though a book does not automatically scream “Table of Contents”, it is a kind of related concepts (since every book has a TOC), and it definitely won’t get mistaken for the menu button.

Finally, I designed an open book icon, and then inserted it on the page to replace the previous TOC icon.

And the last thing that I did is to change the title of the orange bar to “Article”. So the article title, which will be a text immediately under the orange bar, can be written as long as possible.

Comment 136

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #135)
> Created attachment 678209 [details]
> 672203: article page - table of contents explanation - 04
> 
> Finally, I designed an open book icon, and then inserted it on the page to
> replace the previous TOC icon.
> 
> And the last thing that I did is to change the title of the orange bar to
> “Article”. So the article title, which will be a text immediately under the
> orange bar, can be written as long as possible.

This looks fantastic Bram!

Comment 137

[Kadir Topal [:atopal]]

I second that. Absolutely awesome! Sorry, adding bugspam, but had to say it ;)

Comment 138

[Bram Pitoyo [:bram]]

Attachment: support forum - thread list view explanation - 02

The support forum’s thread list view has been revised to include navigational buttons at the bottom of each page.

Thanks Rehan for the feedback!

These buttons are pretty self explanatory: Newer and Older means just what it says on the tin. And “Page x” can be tapped to reveal a drop-down menu of page number, so user can jump between pages non-sequentially

Comment 139

[Bram Pitoyo [:bram]]

Attachment: article page - edit - 01

This is a mockup of the article edit interface.

Although a user will be able to make big-sweeping changes to the article or start writing a new article from scratch, this interface is optimized for making small edits.

This means that it will give user the ability to:
* Skim quickly through all editable content
* Find a particular paragraph or item in the content that contains error
* Write fixes without having to scroll up or down the text box (the on-screen keyboard obscures half of the content area, so scrolling is usually unavoidable)
* Saving changes easily, without having to scroll all the way up or down the page (remember that the entire interface is very long)

To do this:
* Every paragraph has its own text box
* Every title (“=”, “==”, “===”, etc.) also has its own text box
* Every paragraph under a title is minimized by default

Every paragraph has its own text box, so that each box will occupy a relatively small vertical space. If a box occupies a large space, it definitely won’t be as large as if we simply condense the whole content into one big text box. This makes editing with on-screen keyboard easy, because user will no longer need to scroll up or down inside the text box: a painful thing to do in Firefox OS.

Every title has its own text box. This makes it easy to find a particular section that the user want to edit.

Finally, every paragraph under a title is minimized by default, so there won’t need to be too much scrolling. The more user scroll, the more likely he is to lose his sense of position on the page. By allowing every title to be expanded and minimized, we help eliminate some of this issue.

But most of the scrolling issue is going to be eliminated by having a page header that follows user wherever he scroll. This way, user can easily cancel at any point in the page, or save right after he’s done editing, without scrolling all the way down. When user saves, the article is always submitted for a review, so we don’t have to worry about rogue changes being made.


The question that will pop up here is: if finding a particular sentence in the editor is hard, why don’t we simply put an “Edit” link besides each section, a la Wikipedia?

This is because, on a skinny mobile screen, it will result in having too many “Edit” links cluttering up the interface and reducing readability for logged in contributors. On desktop, though, it’s a good practice.

Comment 140

[Verdi [:verdi] Best to slack me]

Hi Bram. This is looking good. What does the save button in the title bar do? How is that different from the save button on the description section and the submit for review button on the content section?

Comment 141

[Bram Pitoyo [:bram]]

(In reply to Verdi [:verdi] from comment #140)
> What does the save button in the title bar do?

Hi Verdi,

The save button on the title bar functions exactly the same way as the save description and submit for review buttons. In the desktop interface today, I think they also do the same thing, but labeled differently?

I think it’s best if we stick a more accurate labels for these buttons. Maybe “submit for review” works for all three? I think that “save” is too short and general of a label.

Comment 142

[Verdi [:verdi] Best to slack me]

(In reply to Bram Pitoyo [:bram] from comment #141)
> (In reply to Verdi [:verdi] from comment #140)
> > What does the save button in the title bar do?
> 
> Hi Verdi,
> 
> The save button on the title bar functions exactly the same way as the save
> description and submit for review buttons. In the desktop interface today, I
> think they also do the same thing, but labeled differently?
> 
> I think it’s best if we stick a more accurate labels for these buttons.
> Maybe “submit for review” works for all three? I think that “save” is too
> short and general of a label.

Hey Bram - sorry my point was that the "save" button under the description section and the "submit for review" button at the end of the content perform two very different functions. So the save button in the title bar can't do both. 

The description section is only visible to editors when creating an article. Once the article is created, that section is only visible to reviewers and admins. When a reviewer or admin clicks it, sumo will save changes to the description section without review. 

The submit for review button is visible for all registered users and always saves a new revision of the content section.

Comment 143

[Bram Pitoyo [:bram]]

(In reply to Verdi [:verdi] from comment #142) 
> The description section is only visible to editors when creating an article.
> Once the article is created, that section is only visible to reviewers and
> admins. When a reviewer or admin clicks it, sumo will save changes to the
> description section without review. 
> 
> The submit for review button is visible for all registered users and always
> saves a new revision of the content section.

Given:
* How long the “Edit Content” section is compared to “Edit Description”
* How “Edit Content” is going to be made available to pretty much everyone who are registered
* How “Edit Description” is going to be hidden from anyone else but reviewers and admins

Most people who are logged in and editing an article will not see the “Edit Description” section at all. So, they will only see two save buttons: the one on the toolbar, and the “Submit for Review” button down below.

This makes the design decision much less complicated. I think we should make the “Save” button in the toolbar perform the same function as “Submit for Review”.

In the case of a reviewer or an admin, and s/he sees three buttons rather than two, we can build a logic where the “Save” button on the toolbar is smart enough to detect what section is changed, and what section should be saved.

For example, if I expand the “Edit Description” section, there is a good chance that I will be editing that section. The “Save” button on the toolbar should know that, when I tap on it, I mean to save this section, not the “Edit Content” section.

The second alternative to this logic is to provide an overlay menu when clicking the “Save” button on the toolbar will present user with an option — Would you like to save: [Description] or [Content]?

There might be more elegant solutions that emerge, so I’ll continue thinking about it!

Comment 144

[Swarnava Sengupta (:Swarnava)]

We need an ''Edit This Post'' button badly in mobile support forum, something like
http://www.psdgraphics.com/wp-content/uploads/2010/09/pencil-icon.jpg

i need to go desktop version everytime to edit post :(

Comment 145

[Bram Pitoyo [:bram]]

(In reply to Swarnava Sengupta (:Swarnava) from comment #144)
> We need an ''Edit This Post'' button badly in mobile support forum […]

While we’re on that subject, do we all think that we need to include the full sidebar in the support forum?

I am referring to not only the “Edit this post” functionality, but also delete, lock, product, topic, system details and tags.

It could make the support forum complex (therefore, defeating the mobile interface), but with enough time, I might be able to design an elegant solution to include all of these features.

Comment 146

[Bram Pitoyo [:bram]]

Attachment: profile view - design variations 01

Per satdav’s request and noah’s idea, here are some design variations on the profile view page (attachment 674113 [details]). Feel free to chime in with feedbacks here as to which designs are more comprehensible to users, but keep in mind that the biggest user segment we have will probably be contributors, not casual visitors.

Comment 147

[David Weir (satdav)]

Thanks bran for this it looks brilliant

Comment 148

[Kadir Topal [:atopal]]

I'd like to take a moment to thank everyone involved in the mobile redesign. It is pure awesomeness :)

I think this bug has run its course, so I'm marking it as fixed. Please file follow up bugs for individual issues. Thanks!

Comment 149

[Bram Pitoyo [:bram]]

For the mobile version of get involved, please see attachment 728058 [details] (bug 781175 comment 18).