Here is the updated version of the search guidelines for Fennec:

5 standard search engines:

You should choose only 1 search engine in each of the following categories.

• Global general search
  • ‘Regular’ global general search, much like in desktop Firefox.
• Reference search
  • Almost all of the time, this will be Wikipedia.
• E-commerce search
  • Both to shop on-line and to consult product information.
  • Store preferred over auctions.
• Local search
  • I.e., “around me” search; e.g. “find the nearest ATM”.
  • Only if available in the region.
• Social search
  • I.e., microblogging platforms/feeds, social networks (no invite-only sites).
  • Only if relevant in the region.

1 extra search engine:

You can choose to use it if no e-commerce/local/social search is available.

• Specific interest search
  • Something specific to the region, reflecting the local way of using the Web.
  • Can be from different categories: e.g. reference (a dictionary or a word reference recommended), entertainment (imdb, youtube, music search), e-commerce (price comparison), general search provider very popular in the region, etc.

The maximum number of search engine plug-ins is 5. Each search engine should be chosen from a different category, as listed above. In rare and well justified cases, we might go for 6 plug-ins total—the sixth one would be then an engine from the additional specific interest category. You can add a specific interest search engine also if there is no e-commerce, local or social search that you would recommend for mobile Firefox for your locale. Or, you can choose to go with fewer plug-ins, which is totally fine, too.

For more context and rationale behind these choices, please take a look at my previous posts on Fennec’s productization.

As always, comments are more than welcome.

Litmus is a great tool used by our QA community for testing purposes. With a wide range of test cases grouped in test runs, it’s probably safe to say that it covers all aspects and features of Mozilla products. You can read all about Litmus over at QMO, in the Litmus tutorial.

If you want to test your localization of Firefox 3.5 using Litmus, the best place to start is the 3.5 l10n test run. It’s a great way of giving your testing a structure, which will help make sure you cover all localization. It’s also very helpful when testing periodically—by following the test run, you’re sure not to miss anything that you tested last time.

To do a Firefox 3.5 l10n test run for your locale, go to the Firefox 3.5 l10n localizer test run on Litmus and sign in. You can also created a new account if you haven’t already. Or, go to litmus.mozilla.org and choose Firefox 3.5 l10n localizer test run from the list of active test runs. (You may have to click View all available test runs at the bottom of the page first.)

Next, fill in your Build ID, Platform and Operating System, and, most importantly, your locale. Click Submit configuration. On the following page you’ll see testcases subgroups available in this test run. Right now there are no testcases in the RTL (right-to-left) subgroup, so just click Submit in order to proceed.

As of this writing, there are 23 testcases to go through, and for each of them you can indicate a result: not run, pass, fail or test unclear/broken.  Please leave a comment when a testcase fails or the instructions are unclear or outdated.

When you’re done (you don’t have to do all testcases at one time), just click Submit All Results. Congratulations, you’ve just contributed to the testing efforts to ensure best quality of your localization!

There are other test runs available on Litmus, many of them more detailed and more thorough than the l10n test run (e.g. the catch-all test runs). You’re encouraged to perform these tests to provide even more testing coverage for your locale, but generally they’re not required to move a locale out of beta.

You may also be interested in seeing how much testing has already been done for your locale. It’s simple. Just go to the Search Results page, choose your locale on the far right and hit Show Results. You may also want to specify the product, branch and platform, as well as the timespan (e.g. show only tests performed in the last 2 weeks).

If you’d like to have more information about how to use Litmus, be sure to check out the tutorial on QMO. If you have questions, don’t be shy and do ask us in #l10n or #qa.

This quarter, the l10n drivers team has set out on a mission to improve the current localization documentation experience. The ensemble of the l10n documentation consists of a rather formidable number of resources (wiki documents, articles, blog posts, graphics, etc.). With time, some of them have unfortunately become out-of-date, and one of our objectives is to update our documentation to reflect the changes that took place to our processes, practices, policies, guidelines, tools and infrastructure (like, remove references to CVS in documents about starting new localizations).

But that’s not our only objective. A big goal that I see here is to identify who’s using the l10n documentation (localizers, l10n-drivers, qa, bizdev, build, developers, webdev, marketing… and so on and so forth), and with these targets in mind, reorganize the documentation in a way that would best serve these groups in completing the task they come to the l10n documentation with.

A rough plan (still work in progress) is outlined on the wiki. The first step is to create an inventory of all documentation resources regarding l10n, across wikis, blogs and other documents. What we need is a flexible tool to create a collection of documents and describe them with tags. After some research I came to the conclusion that the best tool for this purpose is Delicious.com. It offers powerful tagging features (like bulk editing tags or creating tag bundles) and allows to export the collected bookmarks to a well-structured HTML file, which will, for example, make it easy (with some basic parsing) to create a graph of all resources that we know of (if we decide we need one). Delicious has also managed to create a thriving community of tools developers who take advantage of Delicious API to create stunning visualizations of relationships between bookmarks or tags (or both). I’m really looking forward to exploring some of the possibilities this will give us and see how we can use them in order to understand and improve our documentation.

And so I have created a Delicious account called “mozdocs“. I would like to use delicious’ tagging capabilities to create a list of documentation articles with tags describing the contents as well as the metadata, like the location of the article (I used the “at” syntax for this, i.e. @wikimo, @mdc, @blog, etc.). Just go to mozdocs’ bookmarks page on Delicious to see those tags in action. I’ll bookmark this very blog post, too, once it’s published, and tag it with “@blog, @stas, documentation.”

Delicous being a social network, it also offers a couple of neat networking features. You can add any account to your network and then post bookmarks for such defined contacts. In other words, you can add “mozdocs” to your network and then use the “for:mozdocs” tag to make the bookmark show up in mozdocs’s inbox!

If you feel like participating in this grand l10n documentation overhaul, I would like to ask you to bookmark any pages that in your opinion contain useful l10n documentation content and tag them with “for:mozdocs”. It doesn’t matter if you think that the page is so obvious that someone else must have already added it. Delicious is smart about detecting duplicates, and even if it wasn’t, I’d rather deal with duplicates than miss an important piece of documentation.

You don’t have to add any tags, but it will certainly help us if you do (and don’t hesitate to add a lot of them!) Also, if you see that an article is out-of-date, please use the “fixme” tag. I’ll be watching this tag and I’ll make sure the articles tagged with it are updated.

Thanks in advance for your help. I’m looking forward to discovering new l10n documentation pages that I haven’t seen yet :) I’m positive that using Delicious will help us tremendously to categorize the articles and identify those that need to be updated or rewritten.

As always, please share your thoughts in the comments.

We’d like to use the same approach for Fennec. For each locale, we’ll look at the region’s market and try to choose search engines that offer best user experience and bring a lot of added value to Fennec. To facilitate the process of suggesting search engines and choosing a few of them for including in localized Fennec builds, I’d like to suggest the following guidelines for choosing search engines in Fennec.

I propose the following 4 categories of search engines for localizers’ consideration:

• General search
  • 1 global
• Reference search
  • 1 Wikipedia
  • 1 e-commerce (store preferred over auctions)
  • 1 other (optional, a dictionary or a word reference recommended)
• Local search
  (i.e., “around me” search; e.g. “find the nearest ATM”)
  • 1 (only if available in the region)
• Specific interest
  (extra category, use if no local or 2nd/3rd reference search available)
  • 1 (can be from different categories: e.g. entertainment (imdb, youtube, music search), price comparison, general search provider very popular in the region, etc)

Not all categories are required for every locale, in fact, some should be ignored if there are no good search engines available in the region. This applies primarily to the local search (C). If no local search service provider is available in the locale’s region, then we should not include this category at all. Instead, we could look for other interesting search services from other categories and include them under category D. For example, if there’s no local search engine in Germany, then instead of shipping a US-based local search engine with the “de” version of Fennec, we could look for a different type of search engine that would offer good experience and be relevant for German users.

The maximum is 6 search engines. However, if you have good candidates for categories A, B and C, you probably should leave D out, and stay at 4-5 plug-ins. Also, all locales should start with a global general search provider and Wikipedia, and not the en-US defaults. This makes the minimum number of plug-ins equal 2. To sum up:

Minimum: 2 (general search & Wikipedia)
Recommended: 4-5 (subset of A, B, C, D)
Maximum: 6 (A+B+C+D)

To help decide which search engines to choose for each category, I propose to use the following list of criteria, similar to what we use for all productization components across all Mozilla projects, augmented by the compatibility criterion:

• User experience
  • Mobile compatibility
  • Search quality
  • Clean and easy-to-use interface
• Relevancy
  • Popularity in the region
  • Usefulness for locale’s users

To provide some background on the choice of categories: you may wonder for example why I listed e-commerce under “reference”. My assumption is that searching in Fennec is mainly about acquiring information, less so about performing actions on-line (like buying a product). We can then use this information to perform actions off-line, for example take out some cash in the nearest ATM as located by the search engine. A mobile browser brings together two worlds: the off-line world in which we operate and the on-line one in which we acquire information. Consequently, I see e-commerce sites as great sources of information, answering questions like ‘Who wrote that book? What year was this film released? What’s the 4th track on this album?’ etc.

Following this line of thinking, I see two main objectives for the search plug-ins from the user’s perspective:

1. acquire general information, knowledge, definitions, and
2. acquire location-specific information.

A third objective, this time from Mozilla’s point of view, is to demonstrate the feature called “adding search engine plug-ins to the chrome”. It could be argued that including more search engine plug-ins than Fennec’s search bar can fit would have an advantage of demonstrating the horizontal swipe-ability of the bar. On the other hand, offering less engines by default has two additional advantages:

1. There’s an empty space on the right of the bar (cleaner interface), possibly encouraging the user to fill it, by adding new plug-ins.
2. The first plug-in the user adds by herself will be visible right away on the search bar (it won’t be hidden) which, as I believe, will be more rewarding for the user and will make it easier to understand what has just happened (no questions like “Where is this search plug-in I just installed?”).

These reasons are convincing to me. I also believe that it is important to keep the interface clean. Contrary to Firefox, search plug-ins are a highly visible piece of UI in Fennec, somewhat similar to the bookmarks toolbar in a desktop browser. It is therefore crucial to find the right balance between offering more functionality with more search engines and keeping the interface clean and uncluttered. Let’s remember that the browser (together with the search bar) belongs to the user.

Please share your thoughts in the comments.

Clustory: reinventing the tabs in the browser (Mozilla Concept Series) from Staś Małolepszy on Vimeo.

In the video above (slightly too lengthy, I admit), I try to explore a different approach to managing visited pages. I suggest using the loads of data stored in the browsing history (mining for patterns!) and present it in a way that exposes two new dimensions: time and tasks.

The clustory screen (a portmanteau word from “cluster” and “history”) would present a timeline of the visited pages, organized by themes, topics, or actions. Each horizontal line represents a cluster, and the pages belonging to the clusters are portrayed using screenshot thumbnails or favicons. At the top, there’s a timeline indicating the time of visits, and giving some other contextual information like the weather or even (not illustrated in the mock-up) wi-fi hotspot names (SSIDs), which you could identify as your own, your company’s or your school’s.

The sidebar on the right gives you some details about each cluster, such as:

• a user-given name,
• most important keyword as identified by the clustering algorithm,
• last activity time,
• total time spent on the pages belonging to the cluster,
• action buttons: forget, bookmark, share (all pages in the cluster).

The page that you were viewing most recently is always the biggest thumbnail on the screen, to make it easy to click on it and leave the clustory screen. Moreover, it never disappears from the screen, even if you pan to see older visits or clusters that are below the page fold. Its meta-information is always visible, too. To get more information about other clusters, just hover over them, to expand them and show bigger thumbnails, as well some additional metadata.

You can drag and drop pages across clusters, for example when the algorithm isn’t accurate enough and made a mistake. Dropping a page into a new cluster would make the algorithm recalculate the probabilities of each word indicating that a new page belongs to it. Pages currently in the cluster would stay in it.

Which brings me to data mining. I believe that it would be sufficient to represent web documents as unordered collections of words that occur in them (the bag-of-words model). You could even go as far as checking only if a word is present in the document, without counting its occurrences. This would lead to a very simple binary representation that could then be used by a Naive Bayes classifier. The advantage of such approach is that we would be storing minimal amount of data per visited page and we wouldn’t need to recalculate the weights for each word and each document after opening a new page (as using an idf-based weight would require).

Please watch the video, download the Keynote presentation and share your thoughts in the comments. Thanks!

Today, let’s discuss the compatibility criterion, which I believe is the most important guideline for localizers to consider.

The compatibility criterion: Services included in Fennec must render correctly on mobile devices, assuring good readability and ease of interaction.

The compatibility criterion is important, because it allows us to base on Firefox’s guidelines and adapt them to the mobile context. In other words, Fennec’s productization should follow Firefox’s guidelines, making exceptions when the compatibilty criterion is not met.

As you probably remember, there are 5 productization components in Firefox, mapping to components in Fennec (in fact, the future of the live bookmark and the getting started page in Fennec is uncertain, but let’s just assume for now that they’re in):

1. Content handlers (a.k.a feed readers)
2. Protocol handlers (currently: webcal, mailto, irc)
3. Search engines
4. News feed (a.k.a. Live Bookmark)
5. The ‘Getting Started’ page

Fennec should ship only with services that meet the compatibility criterion. We should not promote websites that render badly on mobile devices, are impossible to read (e.g. because of the broken layout not adapted to the small screen), or impossible to interact with on mobile devices.

The good news is that I don’t expect there are many websites that don’t conform to this guideline. After all, Fennec’s developers have gone to great lengths to make sure the browsing experience is as good as on a desktop browser. You can pan and zoom easily, increasing the text size and focusing on chosen part of the website.

But I can imagine a couple of scenarios effectively breaking the mobile user experience, for example:

• a Flash-based ad covering a significant area of the website which is difficult to close/discard (due to very small close button),
• a non-standard input element with no accessibility fallback, which makes typing text into it difficult or impossible,
• websites detecting a small-screen device (which as a practice is not bad) and offering a broken layout.

I’m sure you can think of more example like these. Feel free to add them in the comments.

Mozilla’s mission ensures that the Internet, desktop and mobile alike, evolves in the  correct direction. In this context, that means open, participatory, and innovative. Good for the users. With Fennec, we’re becoming reponsible for building mobile Web the right way. We have the momentum and power to make an impact and make sure web designers and developers don’t ignore mobile in their projects. Because with no doubt, mobile will become one of the most important contexts of using Web, independently of region or demographics. Even more so, mobile is gaining a lot of traction in developing countries, which skip directly to the age of personal and portable computing. I like to think that we’re responsible for the direction in which the mobile Web evolves: open, participatory, and innovative.

Please add your thoughts. Is this criterion too strict? Too vague? Just right?

* * *

In the next post I’ll try to summarize my thinking about the search engines in particular and suggest a couple of categories of search engines that we might want to ship Fennec with.

I immediately liked the idea (in fact, I’ve been thinking about something like this since I first experimented with Exhibit, but never got around to learn more about the Quick Search syntax and buglist.cgi options) and created a very simple search command for Ubiquity to be able to access Andrew’s tool quickly and seamlessly.

I then started to experiment with different queries as I continued to work, so that I can test both the Quick Search and the Exhibit interface on real-life examples. This has been such a great help to me already, and it hasn’t been even a day since I started using it.

Up until now, to quickly get a status of a locale or a bug, I’d simply start typing the bug’s summary in the awesome bar and then go directly to the bug (if there was only one that I was looking for) or to the dependency tree of the locale’s release tracker. However, the dependency tree doesn’t give much information (only summary, number and status), which is not enough when you’re using keywords (e.g. “fixed1.9.1″) in open bugs to indicate that the bug was fixed on branch but not yet on trunk. (I wrote about it before.) Bugzilla’s Quick Search is great help in this situation, because it lets me be more precise about which bugs I want to see. However the default buglist.cgi view isn’t very useful to me in this scenario: it’s just a flat list of bugs, whereas I’m interested in grouping bugs by locale, at the very least. Enter BugXhibit, which allows you to slice and dice the search results to your liking.

One other thing that made this so helpful for me and that we introduced a couple of weeks ago, is the “productization” keyword in bugzilla.mozilla.org. We use this keyword for all bugs related to productization of Mozilla software, i.e. third-party services that extend its functionality (search engines, protocol and content handler, live bookmarks etc.). This allows me to see all open productization bugs with a query as simple as “!productization“, and Andrew’s BugXhibit lets me further manipulate this data by selecting bugs for a specific locale only (in “Components”), bugs that havn’t been yet fixed on branch (select only “productization”, not “fixed1.9.1, productization” in “Keywords”) or bugs that only regard protocol handlers (”protocol” in “Text Search”).

Since I wanted to tweak the interface a bit, I ended up cloning BugXhibit’s repository and making some small changes.  Namely, I set the ordering criteria of the Tile view to “Component” first, “Bug status” second and “Keywords” third. I chose component as the first criterion because in bugzilla.mozilla.org, under the “Mozilla Localizations” product, components translate to locales. I’m pretty sure I could use SimileAjax.parseURLParameters() to specify the ordering in the URL and somehow tell Exhibit to use it in the Tile view. I just don’t know yet how to do that :)

I uploaded the code to the l10n server, go ahead and try it if you wish: bugXhibit-st.

Yet again Exhibit turned out to be a very interesting project and a great tool for sketching prototypes quickly. It has a great potential for creating dashboard-like interfaces (e.g. we currently use it on the l10n dashboard) and I’d like to experiment with it more in the near future, while working on the new l10n dashboard that’s being developed.

I’m sure I’ll continue using BugXhibit, especially through the Ubiquity command. Thanks a million, Andrew!

For development, the process takes place simultaneously on several branches. For example right now, we work on trunk (mozilla-central, Firefox.next), 1.9.1 (releases/mozilla-1.9.1, Firfox 3.5) and 1.9.0 (CVS trunk, Firefox 3.0.x). When a bug receives a patch, it first lands on trunk, and the bug is marked as fixed. Then it lands on branch(es), after getting needed approvals, and the bug is given the fixed-* keywords, for instance, fixed1.9.1.

I have a feeling that this workflow doesn’t fit well into the localization process. The localization efforts often focus on only one branch. In the current case, that’s 1.9.1. Some localizers like to keep their 1.9.1 and central repos in sync, and that’s great, but we don’t require them too. If they prefer working on 1.9.1 only, that’s perfectly fine. After all, strings on trunk have higher probability of changing, so it’s understandable that someone prefers to wait until they stabilize. I.e. until they land on a more stable branch.

So translations land first on 1.9.1, and for many localization, they will only be pushed to central after the 3.5 release, at which point central will no longer be central, but will be given its own branch. The process will start over: the localization efforts will focus on this branch, because this is where the next major release of Firefox will come from.

As you can see, for localization the workflow is reverse: we first translate on the more stable branch, and then port over to the dev branch (trunk). And this is what made me start thinking whether we should change the rules of marking the bus as fixed.

Why is this a problem? Let’s take Assamese as an example (just because it illustrates my point quite well and I’ve been working on it recently). Bug 443139 is the Firefox 3.5 release tracker for Assamese and it’s blocked by a couple of bugs that will need to be resolved before we can release Assamese version of Firefox. In fact, most of them have been already resolved, so we’re really close to releasing Assamese. Congrats to the Assamese team :)

If you look for example on the “Firefox 3 RSS reader setup for Assamese” bug (bug 443145), you’ll notice that it was marked as fixed and has a fixed1.9.1 keyword. That’s because it was fixed on both trunk and branch. So the bug’s status is now “resolved fixed” (thanks to the landing on trunk), and it doesn’t block the release tracker anymore.

But now take a look at the “Search engine setup for Firefox 3 for Assamese” bug (bug 443142). The fix landed on 1.9.1 only, so the bug has the fixed1.9.1 keyword, sure. But since it hasn’t been yet fixed on central (for Firefox.next, mind you), the bug’s status is “new”, and it is still blocking the 3.5 release tracker. Why the lack of landing on central should block a 3.5 release?

That’s a problem for me, because it makes using and following the tracker bugs harder. Of course the right question to ask here is “if we mark this bug as resolved fixed right now, how do we make sure that the fix lands for Firefox.next, too?”. I don’t have a good answer to this yet. But even in the current workflow, if the fix lands for Firefox.next after mozilla-central gets branched again, will we mark the bug as fixed, or maybe just add a fixed1.9.2 keyword? (or a different one, depending on what the name of the branch will be).

I don’t have any concrete proposals right now to address the problems described above. I feel that we should just resolve bugs as fixed when the fix lands on current next-major-release branch (1.9.1 these days). We should still use keywords to make it easier when looking back at fixed bugs to figure out on which branches they were fixed. Lastly, next time we branch from trunk, we should somehow make sure all the fixes are included. I’m not yet sure how, though.

What do you think? I wanted to share my thoughts on this out in the public. I’d be grateful for your comments!

• Добре дошли, хора!
• Planvenguts umans !
• मनुष्यांचे स्वागत आहे!
• (Welcome Humans!)

Many thanks to Ognyan (Bulgarian), Sandeep and Priti (Marathi) and Yannig (Occitan) for their continuous work on the quality of the localization and awareness of it among local users. The 3.0.9 release is a culmination of weeks and months of the efforts by these guys, both on the localization front (translation, productization, web parts, testing) and the promotional one (advertising the beta builds, getting feedback from beta users, increasing awareness of the browser etc.). Good job!

Thanks for all the bugs we fixed together. Looking forward to working with you again soon on next updates and versions of Firefox.

This race is only about to start :)