Closed Bug 867700 Opened 8 years ago Closed 7 years ago
Need visual and ux design for product landing page
572.15 KB, application/download
80.67 KB, application/pdf
539.60 KB, image/png
412.90 KB, image/png
We need the visual and ux design for the product landing page that fits the topic/subtopic iA we plan to roll out this quarter.
Attached are various visual design mockup for the redesigned product landing page. Ideas: * Make better use of horizontal space * Provide preview of subtopics under each topic * Possibly allow user to bypass topic and click directly on subtopic Page 1: Topics are displayed in two columns. “Hot topics” is changed to “Top support issues” and displayed on the third column. Page 2: Same idea as page 1, but the ‘small’ or ‘non-main’ topics are made into normal links instead of white boxes. This mockup is obsolete, because we will no longer have ‘small’ topics. Page 3: Each topic occupies two columns instead of one. The result is a better use of the space and more locale-friendly topic areas (ie. you can write longer topics without worrying about lacking horizontal space). The negative is that topics are no longer seen side-by-side (implying equal importance), but rather, top-to-bottom (implying hierarchy). Page 4: Each topic gets a caption text explaining what it contains. Three-column layout. Page 5: Each topic gets a caption text, and is 3-column wide. Hot topics sits above. Page 6: Each topic gets a caption text, and is 2-column wide. Hot topics sits on the side. Page 7: Each subtopic is displayed under the topic, so user can click on them to go directly to the subtopic. Page 8: Same as page 7, but each subtopic doesn’t have an arrow. This makes it less clickable, and consequently makes the topic more attractive than the subtopic. Page 9: Same as page 7, but each subtopic is colored blue like a link. This makes it more clickable. The danger here is that the interface becomes distracting. Page 10, 11 & 12: Same as page 7, 8 & 9, but with smaller font. Smaller font means that each subtopic looks less important, making each topic more attractive to click. Page 13 & 14: Each topic has a caption text, and one is smaller than the other. Otherwise, this is exactly the same idea as Page 4, 5 & 6: give user a glimpse of what’s under each topic, but don’t give direct link to subtopic so user get to discover more potential solutions on the way. Recommendation: Page 4. Keep the existing three-column layout, but augment each topic with a caption that describes what it’s about. If we run into space issue during localization where text doesn’t fit inside the box, then we can implement something along the lines of page 6 or 5.
An interesting idea here is to make subtopic slide out from under each topic box when user hover over each topic. It might be fancy with no true usability benefit, though (other than reducing clutter, which is legitimate).
(In reply to Bram Pitoyo [:bram] from comment #1) > Recommendation: > > Page 4. Keep the existing three-column layout, but augment each topic with a > caption that describes what it’s about. That one looks pretty good in English but I wonder how it will look in German, for example. https://support.mozilla.org/de/products/firefox I kind of like the concept of exposing subtopics directly from this page.
Just to clarify, we needed a place to store things and refer to them. The current attachments do not represent the current state of discussion.
http://people.mozilla.com/~bpitoyo/sumo/product-topic-sub-flow-animation-2.mov The attached video contains three variations of the product landing page. The video helps make the interaction (ie. what happens when you mouseover or click) clearer, and helps demonstrate the continuity between product, topic and subtopic landing pages that these designs achieved. Note how the sidebar remains at pretty much the same position throughout the flow. The variations are located at :00, :22 and :48. They’re extensions of the same ideas that were present in attachment 744457 [details] and attachment 744452 [details] page 5 & 6. The ideas ========= * Keep the sidebar navigation appear and function as consistently as possible across all pages: product, topic and subtopic * Give user a peek to the content of each topic, but don’t give them the ability to click directly on subtopic or article The first two mockups (:00 and :22) are design variations of the same layout. One has the icons in the middle, and the other has it on the side). The third layout (:48) features a megamenu that expands when hovered. Why you’ll love the third layout ================================ In my opinion, the third layout does a somewhat better job of handling different locales because it provides a lot of space to describe topics, and gives us the flexibility to describe our topics as detailed as we like (or not; it’s up to us). Furthermore, each topic box can be vertically lengthened (or shortened) to adapt to locales with shorter/longer written scripts. Some problems with megamenus ============================ There are numerous problems common to all megamenu. I’d like to go over some of them, and how this design solves them: 1. The diagonal problem Expanded sections would always close when the mouse moves diagonally. This problem is highly reduced in this design, because each topic occupy a large hoverable box. 2. Occlusion Expanded sections often cover contents that user wants. In this design, there’s no content underneath. Hot Topics is located on the far right side 3. Hover What happens when user is on a device with no hover action like a tablet? There’s a link called “View this topic” to the bottom-right hand corner of every expanded section. When the device is ‘hover-less’, each topic section will expand on tap (not on hover). User can either tap again anywhere on the expanded area to go to the topic landing page, or he can tap on the “View this topic” link. Having a link makes it obvious that user is supposed to tap on it. Hot Topics ========== Related to bug 867221, one nice benefit that these layouts have is that Hot Topics is now put on the side: 1) It’s not over-emphasized by being positioned on top, so it won’t ‘steal’ clicks 2) It’s not under-emphasized, either, because it has a different background color from the rest of the page (to achieve this, the topic section has to be colored more subtly, not white)
Attached are the mockups of the latest product landing page layouts. They’re static versions of what I’ve shown in the video posted on comment 5, so the same explanation also goes here.
This bug lacks a problem statement. My question is, what are we trying to solve here? The new designs are great but if we are not talking about what are we trying to resolve is unclear to me if they have the potential to do so. Back in the London meetup we identified that the product landing page had an unacceptable level of bounces and we need to fix that. I don't see that topic being discussed here. The hypothesis back then was that we are not surfacing the information that different users are looking for in the site when they land on it. Now we are focusing this redesign in the need of incorporating the sub-topics to the landing page. Question, is that necessary? What problem is that resolving? I'm adding the email that I sent back from London with more context and ideas on what's not working with the actual landing page: ------- One of the first things that we have been looking at is the landing page for the users clicking on the Help menu of their Firefox Browser. It seems that the majority of them is not finding what they expect, and one of the things that we want to test is the layout of it, to understand if we are targeting the right group of people. Yesterday, we came out with 5 different groups of users that may land in our site: - Users with an old version looking for any type of help. - People looking to learn something - People looking to answer a question about something that has changed or is broken on their site. - People looking to answer a question about something that has changed after they update Firefox. - People looking for help with something really specific/they know what they need (i.e. firefox crashes when I open Facebook, etc). The idea is to create new variations of the landing page targeting each of this groups, and measure the performance to understand what's the most popular group. For each group, we have some principles: - Old version: They need to understand how to update. It needs to be really easy to update. We offer them a button to download the latest version of the browser (this is basically our site today) - Learners: They want to see as much content as possible, straight away. - People with questions: The need to start digging into the categories to figure out what's their issues. - Updaters: They need to see what are the hot topics and ask questions that are not in the list. They probably have problems that are not documented. - People who know what they want: They know what they want and they will prefer to search for it. I put together some wireframes to represent this, but we would appreciate your input. Particularly, the one showing more content in the landing page (we are talking about showing a description of the category and a short list of articles). Can you look into this and give us some feedback? If you want, we can try to meet you tomorrow at night. The next step after trying the layout, is to try the copies. One of the things that we observe in our site, is that the copies surrounding and explaining the tasks are less clear than in other similar site: We say "Help Topics" instead of "Chosse the topic that better represents your question" or something like that. If you want to think about that, feedback would be greatly appreciated. -----------------
Hi Ibai, The diagram and what it explains -------------------------------- I have responded to the 5 user types with the attached diagram. These diagrams detailed the ways that the product landing page design could respond to different user types: 1. Users with an old version We should: upgrade them first, then solve their issues 2. Users with a version that’s just updated We should: display version-specific issues first, then the rest of the KB 3. Users looking to learn something We should: give a glimpse of the subtopics and articles inside each topic 4. Users with questions about something that has changed or is broken We should: help identify their problems so it’s more specific 5. Users with questions about something specific, they know what they need We should: emphasize search, because it gets them to the answer faster The mockups I’ve posted so far have mainly addressed the 5th user type: learners. I believe that they’re the hardest to design for. I think that the landing page mockups you posted (attachment 750520 [details]) already works for almost all the user types: everyone but the learners. The mockups need visual design, of course, but the idea makes a lot of sense: add a bigger AAQ button, emphasize the search bar, put Hot Topics on the bottom of the page, etc. In fact, my mockups (attachment 749713 [details]) took the idea on page 4 of the document and expanded it. My mockups is optimized for learners (user type 3), of course. Why identifying some user types is tricky ----------------------------------------- Identifying these user types seems to be easy: 1. Users with an old version 2. Users with a version that’s just updated But it’s only doable if Firefox passes version information to SUMO. The only way we could do this today is if user visited via the help menu. What if they land via Google? How can we detect that the user’s Firefox is old or has just been updated? Identifying these user types are trickier, because we can’t autodetect: 4. Users with questions about something that has changed or is broken 5. Users with questions about something specific, they know what they need A possible way to detect user types ----------------------------------- 1. Assume everyone is a learner (user type 3) 2. Everyone is a learner, unless his version of Firefox is old (user type 1), then offer a large download button 3. Everyone is a learner, unless his version of Firefox has just been upgraded (user type 2), then make Hot Topics very prominent and version-specific 4. When a learner is going to the ‘Fix Firefox’ topic, assume that he’s there with question about something that is broken (user type 4) and offer something to help diagnose his problem 5. When user type 4 has been browsing an x number of articles, or navigated back and forth between x number of sub/topics, reward browsing by showing a big search bar on top of the page 6. When user type 4 has been searching for a while, reward search by showing a big Ask A Question button that will allow user to directly ask a question 7. When user starts SUMO not with browsing but with search or AAQ, assume that they have a question about something specific (user type 5). We should reward multiple search attempts with showing a big AAQ button, and make an expedited AAQ process just for them. Why identifying them this way might not work -------------------------------------------- Firstly, item #4 to #7 above are assumptions. For example, There is no indication that a user who uses search first tends to belong in user type 5. Similarly, not every user who visits the ‘Fix Firefox’ topic belong under user type 4. Secondly, identifying item #1 and #2 would only work if user visits from the Help menu and if Firefox pass the version information to SUMO. It will not work if user visits from Google and we don’t get any version information. Given this fact, and given that we do want to offer to upgrade for users who has old versions, we need a way to detect version in a non-intrusive way. Conclusion ---------- The mockups I posted were designed with the learners (user type 3) in mind. I did not take the rest of the user types in mind because I thought that Ibai’s mockups involves fairly minimal visual design work, and I agree with most of its principles, and they should be easier to implement: big AAQ button, large search area, de-emphasize Hot Topics, etc. I thought that I could save them for later, after the hard work for designing for learners is done. I also thought that, while the visual design is easy, the process of autodetecting user is hard. So the big problem that we should talk about is how to autodetect reliably and at what point we think we should present a large search area or a big AAQ button.
Thanks for the detailed explanation Bram. I remember your context and previous presentation, that I think is brilliant! I just wanted to make sure that in this particular bug we were talking about the same problem statement. The designs seems to be really focused on how to present more content in the landing page and not the overall experience of the page to reduce the bounce rate that we detected. That's why I will like to see how are balancing the navigation, with search, AAQ and the rest of the elements. That said, while reviewing your notes, I think that your design starting in Page 6 (I think that not showing content as in Pag. 5 looks less engaging/clickable so the page could load at the stage of pg.6) could be the perfect baseline for a new overall organization (more obvious search, AAQ flow, etc...) What do you think?
(In reply to Ibai Garcia [:ibai] from comment #10) > Thanks for the detailed explanation Bram. I remember your context and > previous presentation, that I think is brilliant! > > I just wanted to make sure that in this particular bug we were talking about > the same problem statement. The designs seems to be really focused on how to > present more content in the landing page and not the overall experience of > the page to reduce the bounce rate that we detected. I think the goals are clear: Make sure that more people are reaching an article or forum thread that helps them solves their issue. One way is to reduce the bounce rate on the product landing page, another way is to reduce the friction for those who click on something to reach an article/forum post. We are trying to reduce the bounce rate by giving people a peek at the topics without overwhelming them. That's what the product landing page is about. The goal of making sure that those who stay reach an article/thread is what we are concerned about on the subtopic/article pages. However the subtopic/article pages are linked to the product landing page, so consistency is what we shot for (using the sidebar). > That's why I will like to see how are balancing the navigation, with search, > AAQ and the rest of the elements. > > That said, while reviewing your notes, I think that your design starting in > Page 6 (I think that not showing content as in Pag. 5 looks less > engaging/clickable so the page could load at the stage of pg.6) could be the > perfect baseline for a new overall organization (more obvious search, AAQ > flow, etc...) > > What do you think? The idea of leaving the area free was to not cover up an area people might actually click on. Amazon does the same thing with their mega menu. On the other hand, we could test all kinds of things in that area, and validate our assumptions. Maybe people don't have an issue with covering that area up, maybe hot topics would be ideal in that area. Maybe the search, or AAQ as you said.
> I think the goals are clear: Make sure that more people are reaching an > article or forum thread that helps them solves their issue. One way is to > reduce the bounce rate on the product landing page, another way is to reduce > the friction for those who click on something to reach an article/forum post. > > We are trying to reduce the bounce rate by giving people a peek at the > topics without overwhelming them. That's what the product landing page is > about. The goal of making sure that those who stay reach an article/thread > is what we are concerned about on the subtopic/article pages. However the > subtopic/article pages are linked to the product landing page, so > consistency is what we shot for (using the sidebar). > Kadir, we need to have a better list of what are the problems with the actual page before we can start designing something that solves those problems. If we know that users don't end up in an article/thread, why is that? Because they leave early. Why is that? We are not going to be able to have a better design to resolve that issue until we have answers to those questions. The only thing that we will do is a different design...not necessarily a better one. I hope this clarifies what I mean by saying that we don't have a problem statement in this particular bug. What I proposed is to test some rough options to get the answer to why people bounces so fast, but we also can ask our users.
http://cl.ly/3o1F2Y0q2o1Y/product-topic-srp-search-aaq-variations-1.pdf Hi Ibai, Attached are a few visual design mockups that addresses the idea you proposed and mocked up on attachment 750520 [details]. Thank you so much for that! Explanation exists on page 2 of the document, but the basic idea is to reward users who actively browse with a prominent search interface, and reward active searchers with a link to the ‘express lane’ of the AAQ. They also address the issues I outlined on the diagrams on attachment 750815 [details] with several user types. The ideas of these mockups are: 1. For users with questions, we should have an email-style browsing so checking out articles becomes easier. The mockups I’ve posted is a partial solution. Even though we don’t cache articles like I proposed in the diagram, the sidebar of the product, topic and subtopic landing page will look, function, and be positioned identically. This will make it easy to ‘make the connection’ between those pages. In our current design, there’s a visual disconnect between product and topic landing pages because the list of topics is not displayed in the same way. 2. A better browsing experience is not enough. For users with questions, we should also reward active browsing with a prominent search interface. 3. For users who know exactly what they’re looking for, we should give them a prominent search interface right away. 4. Lastly, we should reward active searches with an AAQ that takes the search query into account. * AAQ should pre-select the “tags” with the keywords user had typed * AAQ should be quick: bypass search and go straight to the questions form
Bram, these are great suggestions. I especially love the positioning of the search bar in slide 6. I just talked with Ibai, and this is what we came up with: The design is good as it is and we can use it to drive our experiments: * Test the search bar placement. * Add upgrade-specific articles to hot topics for 2 weeks after a release * Experiment with prominent AAQ button and a change of copy to "Ask the community" One thing that should still work on is the empty area in the middle. We should probably not fill it up with more data, but it also looks a bit awkward as an emtpy space in the middle of the page. Ibai had the idea of using a mascot that points towards the left menubar. That way we can have some color on the page, lighten it up and point people in the right direction. We had great success with the mascots on the "Get involved" pages, would be great to have something light hearted for our start page. After all, the demise of Nurse Cat has left a hole in our lives ;) I'll follow up with a testing plan for the various experiments we want to run to figure out why certain parts of the population are dropping off, and whether we can make them an offer they can't refuse.
(In reply to Kadir Topal [:atopal] from comment #14) > One thing that should still work on is the empty area in the middle. We > should probably not fill it up with more data, but it also looks a bit > awkward as an emtpy space in the middle of the page. Ibai had the idea of > using a mascot that points towards the left menubar. That way we can have > some color on the page, lighten it up and point people in the right > direction. This is a great idea! I do feel like the new SUMO design lacks a little warmth, and a little illustration could bring that back. For starters, can we appropriate the mascot we currently use on Get Involved for the product landing page? We should engage the brand/creative on this.
Bram, you mean the fox mascot here? https://support.mozilla.org/en-US/get-involved That would be great. I don't see this as a blocker for the launch, but it would be great if we could get this in from the beginning.
Whiteboard: u=user c=wiki p= s=2013.backlog → u=user c=wiki p= s=2013.12
(In reply to Kadir Topal [:atopal] from comment #16) > Bram, you mean the fox mascot here? > https://support.mozilla.org/en-US/get-involved > > That would be great. I don't see this as a blocker for the launch, but it > would be great if we could get this in from the beginning. Yes. I also think that this is not a blocker. The image should be of the fox pointing to the left-hand side area, or a variation of that which will visualize the fact that the area is hoverable. For that, we probably need to collaborate with the creative team to come up with one new illustration. Other than this -- and the illustration is not critical to the page -- we’re good to go.
Making this 2pts like the others.
Whiteboard: u=user c=wiki p= s=2013.12 → u=user c=wiki p=2 s=2013.12
This is the final set of mockups of the product landing page design, ready to implement.
Attachment #749713 - Attachment is obsolete: true
We are going to table this change until a later stage. The design that we are proposing has some problems: - The empty space looks bad. This should be fixed with the piece that creative is putting together. - If we land in the page with the empty space, is not really clear where to start from (hot topics have the same weight as Topics). - Once hovered, subtopics gain too much weight and articles that are part of the topic and not the subtopic (the highest level ones) maybe at risk of not being accessible. We need to resolve this issues before moving forward. The actual design, while not perfect, is less risky than this new one. If we implement a new one it needs to: - Offer access to Subtopics from the home page without over promoting subtopics over topics. - Focus on Topics while promote Hot Topics as a good source of information (but not the primary). Let's focus on the rest of the navigation pages and leave this for later. This is not a P0 for FxOS launch.
Moving to the backlog and unestimating.
Whiteboard: u=user c=wiki p=2 s=2013.12 → u=user c=wiki p= s=2013.backlog
Hi Ibai, PROBLEM 1: THE EMPTY SPACE IN THE MIDDLE ----------------------------- > - The empty space looks bad. This should be fixed with the piece that > creative is putting together > - If we land in the page with the empty space, is not really clear where to > start from […] I totally agree with this. The empty space lacks a visual indication as to what the starting point should be. PROBLEM 2: TOPICS AND HOT TOPICS: WHICH ONE SHOULD BE PROMOTED? ---------------------------------------------------- > […] (hot topics have the same weight as Topics) > - Once hovered, subtopics gain too much weight […] > - Focus on Topics while promote Hot Topics as a good source of information > (but not the primary). My design had tried to equalize the importance of topics and Hot Topics as much as possible by: 1. Positioning Hot Topics not on the top or bottom of the topics, but to the side 2. Not showing subtopics by default But at the end of the day, we have to make a decision: 1. Is it okay that one item on the page is made more important than the other? 2. If not, then are we okay with compromising and have less overall visual emphasis? If one is more important than the other, then emphasizing one will come at the cost of de-emphasizing the other. Emphasizing the topics will mean that Hot Topics will need to either be moved somewhere less prominent, or have less text contrast. On the other hand, if we decide that topics and Hot Topics are both equally important, we have to be okay with nothing looking as important as the other. Simply put, we can’t have our cake and eat it, too. PROBLEM 3: OFFERING ACCESS TO SUBTOPICS FROM THE PRODUCT LANDING PAGE ---------------------------------------------------------- > […] articles that are part of the topic and not the > subtopic (the highest level ones) maybe at risk of not > being accessible. > […] > - Offer access to Subtopics from the home page without over promoting > subtopics over topics. I designed the interface so that accessing subtopics is impossible from the product page. This is why the expanded topic list does contain subtopic texts and descriptions, but the subtopics are not colored blue. In other words, the subtopics are readable, but not clickable. Clicking anywhere on the expanded box will take user to the topic landing page. The idea here is twofold: * Having a big clickable area eliminates many problems associated with megamenus * User should go step-by-step from product–topic–subtopic-article, not skip steps When user can skip the topic and go directly to the subtopic, the user will be able to find the solution faster, but only if he knows the correct vocabulary to describe his problem. On the other hand, users who don’t know these vocabularies will be confused. S/he will benefit from going to a general topic page first, reading the content of this page, then narrow down to a more specific subtopic, before opening an article. The hypothesis here is that reading the content of the topic will give user contextual information (“this sounds like my problem”) without being too precise. This also allows the user to quickly go back up the information architecture and choose another path, another general-sounding topic, if the original selection was wrong. CONCLUSIONS ----------- 1. Let’s work with creative to put together a piece to fill the empty space and provide an indicator of “This is where you should go first”. 2a. If we decide that topics is more important than Hot Topics, we have to be okay when Hot Topics is understated. They can’t both be important. 2b. Alternatively, maybe they are both important. If so, we have to be okay with none of the two winning the visual battle. 3. I don’t think that we should offer access to subtopics from the product landing page. User should go through the product-topic-subtopic-article path
Nicely summarized Bram! Thanks for that. (In reply to Bram Pitoyo [:bram] from comment #22) > > > CONCLUSIONS > ----------- > > 1. Let’s work with creative to put together a piece to fill the empty space > and provide an indicator of “This is where you should go first”. I agree that we should try this though I'm not convinced that it's the only answer. A pre-expanded mega menu might work. My point is that maybe we should test a few things. > > 2a. If we decide that topics is more important than Hot Topics, we have to > be okay when Hot Topics is understated. They can’t both be important. > > 2b. Alternatively, maybe they are both important. If so, we have to be okay > with none of the two winning the visual battle. > I think topics and subtopics are more important plus the hot topic articles are still available though that path. If we've done our work right, users should be able to easily browse their way to these articles. I'm willing to be convinced otherwise though. > 3. I don’t think that we should offer access to subtopics from the product > landing page. User should go through the product-topic-subtopic-article path I agree. I think Bram makes an excellent point about this above.
1- It seems that we are all align that an empty space looks not shippable. Michael, we discussed yesterday with Rehan about the option to pre-expanded box and it has the problem that it seems that you have access to subtopics...but not really. Bram, thanks for the clarification. It also has another potential problem that we should test, and that is the emphasis on the Learn the Basics section. Suddenly that category is the most clickable topic by far. Not sure if any of this is bad and will hurt us...but i'm not sure if it's good either so I prefer not to spend time on doing and undoing in preparation of the FxOS launch. 2- I'm not sure if this was ever made explicit by Kadir. FWIW, I shared Michael's vision here. Topics are the most important thing of this page. In a more clear statement, the goal of the main pages at SUMO (IMHO) is as follows: /home: Pick a product /product/foobar: Pick a topic or Perform a Search /product/foobar/topic/: Pick a subtopic or an article. /kb/articlename: Read the article + (Vote OR Ask a Question) The rest of the functionality on each side is a nice to have add-on. 3- I'm good with either option. And the argument against making subtopics being selectable from the main product page are good. The concern then is the implementation. Having a list of subtopics, where it seems that I can click, to land in a page, where I see the same list again and I need to click in the same subtopic again...is suboptimal. If we don't want to make Subtopics accessible from the product page: What's wrong with the actual product page on the first place? The benefit of the new design is to see what subtopics you can find in the topic, at the cost of the confusion and annoyance of reading the same thing twice. I agree that we should do some experimentation around these concepts, unfortunately now is not the time. We need to focus on being 110% ready for FxOS.
There seem to be some pressure to ship a new design for the main page. From the different comments in this bug and the conversation today: 1- The new design needs to align with the visual refresh that we added to Topic and Subtopic pages. The actual proposal doesn't seem to be a significant improvement compared to what we have in production today. 2- Bram proposed that we should optimize the page for Learners. That may be a good starting point. If so, the design needs to: "Show as much content as possible, straight away (give a glimpse of the subtopics and articles inside each topic)" 3- And it needs to be flexible. How does this design work with Topics that have no subtopics? These new design covers #2...it shows more content...but it doesn't make it accessible and it's confusing. Also it doesn't address the requirement of aligning it to the rest of the pages and I'm not sure if it's really flexible. I'm sorry that I'm adding too many things now, but this page is our face and we can't ship anything that is not perfect.
This might be crazy and stupid. But what if we took the product landing page out and just take the user to the top topic landing page for that product? Show them hot topics there. For example, the landing page for Firefox would be: https://support.mozilla.org/en-US/products/firefox/get-started (plus some hot topics)
(In reply to Ibai Garcia [:ibai] from comment #25) Hi Ibai, First, I’d like to comment on the fact that the product landing page design fail to align to the visual refresh that was added to the Topic and Subtopic landing pages. These mockups were explicitly designed to minimize any overly abrupt change between the product and topic landing pages. To see it in action, have a look at the video: http://people.mozilla.com/~bpitoyo/sumo/product-topic-sub-flow-animation-2.mov And note the page transitions that happen at 3 different points: :05, :29 and 1:18. Note how the positioning of the topic title doesn’t change at all between pages. In fact, the topics occupy the same area, and uses the same text size. This will happen no matter which topic is chosen, and makes the transition between screens fairly seamless. Does this address the page alignment problem, or are you looking for alignment in a higher (maybe more conceptual) degree that the design had failed to account for? Second, I’d like to comment on the fact that the design needs to work with topics that have no subtopics. In the video, you’ll see 3 different design variations of the product landing page. In the third variation, every time a topic is hovered, the subtopic under it expands in a separate white area. However, have a look at the first two variations. In those, each topic has a bit of text to the right of it that gives user a hint of what’s under each. These text bits indicate “here are some things that you’ll find if you click on this topic”, without giving user the ability to click directly on a subtopic. There is no white box to expand, no hover area, and no overly descriptive text. In these two designs, we give people less glimpse of what’s under each topic. However, because we show less, we don’t imply that subtopic is directly clickable. Sometimes, we just show short descriptions of the topic and don’t even print the subtopics. Plus, we also utilize the middle area better. Do either of these designs satisfy the need to accommodate topics that don’t have subtopics? Do either these designs solve the problem of wanting to show people something, but not too much to make it confusing?
(In reply to Bram Pitoyo [:bram] from comment #27) > To see it in action, have a look at the video: > http://people.mozilla.com/~bpitoyo/sumo/product-topic-sub-flow-animation-2. > mov The problem with this video is that the data used doesn't match what we have in production. We could implement this, and it looks great in the video, but it will be totally different with the data in production. We don't have verbose descriptions for any of the topics, so we can't really display those at all right now. The flyouts (or whatever you call those) will be at most 3-4 links with no description. We don't have any description for the main parent topics either, so topics without children will have an empty flyout. The video has different variations of the start state, so I'm not sure which one we are going for. I can say that the one with the empty middle is pretty odd for a product landing page. The others are unrealistic because we don't have any descriptions like I mentioned above. TL;DR: we need to get fix our data to implement this or we need to adjust a design to fit our data.
This is based on earlier ideas. Ibai and I were talking about this yesterday. The idea is to have the topic buttons be similar to their current design but enlarged to show the topic description. The description is something we can write and localize for each topic for each product. They can include words related to the articles and subtopics the user will find when they click though.
Now I'm confused. The video posted by Bram shows another 2 designs, closer to what Verdi is sharing in Comment 29. Without flyouts. It seems that we all agree that's a small step forward, without limited to no risks compared to the actual design. I think that the general risk/issue that we all see is the implementation of the flyout. Any of the other solutions looks good to me. That said, while I agree that it improves the transition to the sidebar navigation, the way that we are reloading the page makes the consecutive pages "new pages" and I'm not sure if the intended continuity works. In other words, because of our way of loading the site completely... I'm not sure that this continuity is having the necessary effect and it's even needed. Examples of the opposite: - Amazon. We keep going to that one. You have a sidebar that completely changes when you go to the next level, you need to go to the "Shop by department" tab to go back. - Our "beloved" Apple: http://www.apple.com/support/ Boxes, boxes and more boxes that depending where you go turn into something or something else. In general...with more boxes. - Yahoo (After Marissa's redesign): This is a good example: Whenever you click something that loads content asynchronously, the navigation elements are still there. If you click in something that reloads the page, the navigation changes completely. - AirBnb (a design driven company): Same as Yahoo. The navbar on top is constant, the rest of the elements...change. - etc. My point is: Are we limiting ourselves in making a good landing page with a design element (the continuity of the navigation) that seems to be unnecessary? After all, the MAIN problem that we are trying to solve is that this page has 60% of bounce rate. We need those 6 out of 10 people clicking somewhere. We are trying to fix the continuity to 4 out of 10 when the real problem is the people who don't click on anything and they are not going to benefit from a, in theory, more cohesive navigation. So here goes another idea...can we do some user testing to understand why people may be bouncing? I want to focus on the 3 million people we lose, not the 2 million that decide to click on something.
I had a talk with Ibai about this, and we have agreed that maintaining consistency of navigation elements between pages is secondary to solving the 60% bounce rate problem. This means that we’ll need to rethink the info organization of the product landing page again to reduce bounce. We can worry less about visual consistency, if necessary, to achieve that goal.
Bram is going to add a mockup soon, that is a hybrid between the first version in the video and Michaels proposal. It has Icons on the left, the topic next to it and a description to the right. There is no silver bullet for the design of the product landing page. We have to start somewhere, and keep experimenting and iterating, based on the results. The guiding principle is moving the bounce rate down, and the goal completion rate up.
This is nice. I have a question: Why do we think that this design can reduce the bounce rate? And, do we know why do user bounce? I think that we should start by answering that question.
I'm going to call this done.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.