From MozillaWiki
Jump to: navigation, search

Meeting Details


  • 09:00 PDT
  • 11:00 CDT
  • 12:00 EDT
  • 16:00 UTC
  • 18:00 CET

Phone call details:

  • California: 650-903-0800 then extension 92
  • Toronto: 416-848-3114 then extension 92
  • Toll-free: 800-707-2533 then password 369
  • Skype (free): +18007072533 then password 369

Then, enter the conference number: 9435#

Video details:

  • Guest video link
  • You will need to download and install the Vidyo desktop software. #sumo <== Click the link to use web-based chat

Link to meeting video

Design & Development work

The paper prototype testing will be complete by this time. We should talk about the results and what needs to be done, discussed and decided before implementation begins.

Michael: I spoke with Bram this week to clarify what the current understanding of the IA recommendations are and what questions will need to be answered in order to implement them. These are my notes:

Bram will present the findings of the paper prototypes to everyone next week to allow some time for thought and feedback. Michael and Bram talked about presenting different workflows instead of one giant collection of wireframes. For example, the workflow for searching for an article, the workflow for browsing a topic, etc.

Topics will be flat (subtopics didn't work well in testing) and listed in the left sidebar of articles (no breadcrumbs). In the wireframes it may look like one topic is a subtopic of the one above. That's not intended - it's meant to be highlighted as the one chosen in the users' path to the article. When arriving from search we can just not highlight a topic or we can pick a topic but we'd have to come up with a way to determine what topic to highlight.

Topic page creation - this is big open issue. We discussed this a few weeks back. Some things have changed since then. Ibai and Michelle came up with some ideas (linked below).

  • Images on topic pages - the prototypes have images associated with articles. Bram indicated that this not necessarily the recommendation. If it is, we'll need a way to define and source these images as images in articles are not created with this display in mind.
  • 3 possibilities to implement the new IA:
    • Complete Manual- No development time required. English version completed. Hard to maintain and challenging for L10n.
    • Automatic article population- Home page and Topic pages done manually. Landing Page populated automatically based on "Topics" and "Relevant to". Easy to maintain. L10n will need to maintain strings around 50 navigation pages.
    • Automatic index- Development feasibility required. All the pages generated based on 2 wiki articles that contain the index and the strings. Easiest to maintain and for L10n.
    • Matt has a proposal for automating the navigation that can use the idea of the topic templates that we discussed previously to customize pages when needed. We'll talk about this more next week.
    • Locales - there will be issues with us exposing lots of unlocalized material through better browsing. We discussed using machine translation to get a first pass done of the unlocalized material. We also talked about possibly needing a way to phase in the new IA on a locale by locale basis.

Clarification about how topic nav on works - The top home page that this navigation defines has a list of 6 main topics. In the new IA, choosing one of those 6 main topics from will take you to a page where you will have to pick a product. From there you will go the that product's version of that topic page. For example, I start on and choose "Download and Install" and then I'm asked, what product I want help with and let's say I choose "Firefox for mobile", I'll get the download and install topic for mobile.

  • This brings up a concern. We have defined a set of topics that we are using for all products but in actuallity they are based on desktop Firefox. Some topics may not apply to all products and some products may require topics not yet defined. For example, Thunderbird probably doesn't need "Bookmarks" but it may need something else like (total guess) "IMAP." What should we do here?

There are two basic ways to ask a question. A link on each page (at the top next to the search bar) and in search results (when you've searched more than once) that takes you directly to the AAQ flow. We'll also have a topic page that explains what to expect by posting a question in our forum (including that it's public, that's it's community driven, etc.) before linking you to the AAQ flow.

  • Bram said the idea is to implement some of the easy things that they tested and then later to do more extensive testing to come up with an even better AAQ flow.

The Product & Services sidebar below the topics sidebar may not be included.

Contributor links and editing tools could be displayed above the topic sidebar for logged in users. This is something we have to figure out.

The related articles block isn't shown in the wireframes but they will still be included. They just weren't testing these.

News/Blog - we need to figure out how this information is sourced. In the wireframes it's litterally the SUMO blog. The problem with that is that the vast majority of the time this is not aimed at Firefox users. We might want something with more control. For example we might want to list a nice add-ons blog post like this and another time something from user engagement Of course a good sumo article should always be a possibility. And having more control like this will allow locales to customize this section for their language.