Parsons and Mozilla Labs collaboration

amilewski

This Spring, Mozilla Labs and MFA Design and Technology students from Parsons The New School for Design collaborated on a set of prototypes exploring engaging, multi-device Firefox UX for the future that aligns within Mozilla’s mission and goals. Led by Aaron Druck and David Ascher (Mozilla Labs) and Ryan Raffa (MFA DT), students addressed current issues with an eye to what comes next, from location-based experiences and augmented reality to social TV viewing and DIY maker communities.

The students detailed their entire process, from sketch to final prototype, on the class blog, Interactive Prototyping. Below are a final set of presentations and videos from each of the groups.

We at Mozilla are always interested in exploring ways to collaborate with other design schools. If you’re faculty at a design school and you’re interested in this kind of project, please get in touch with us at [email protected].

Congratulations to the students on a successful set of prototypes!

—————————————————————————————-

Cinemate
A social streaming cross platform application that allows friends to watch TV shows and movies together, incorporating video and text chat.

Class Blog Post:
http://www.ryanraffa.com/classes/ip2013/presenting-cinemate/

Video:

CINEMATE from Jean Zhao on Vimeo.

Presentation:
http://www.orleviteh.com/projects/cinemate/Cinemate.pres.pdf

Team:

TV TEAM
Jean Zhao – [email protected]
Lola Ye – [email protected]
Norma Chan – [email protected]
Or Leviteh – [email protected]

—————————————————————————————-

Honeycomb
A better way to see news that is contextually aware, and allows you to stay up to date with information that matters to you.

Class Blog Post:
http://www.ryanraffa.com/classes/ip2013/mozilla-honeycomb/

Video:

Honeycomb from Salome Asega on Vimeo.

Presentation:
http://www.ryanraffa.com/classes/ip2013/mozilla-honeycomb/#more-661

Team:
Samuel Lee Kwon – [email protected]
Salome Asega – [email protected]
Haijing Liu – [email protected]

—————————————————————————————-

Treehouse
Create personal HUBs on the web to share and save media and thoughts with those who matter most.

Presentation:
http://www.ryanraffa.com/classes/ip2013/wp-content/uploads/2013/04/Treehouse-presentation-flow-4.pdf
Google Doc Presentation

Video:

TreeHouse Multi-Device Real-Time Media Sharing from kasia witek on Vimeo.

Team:
Kasia Witek – [email protected]
Aneta Genova – [email protected]
Efrat Weidberg – [email protected]
Jackie Simon – [email protected]

—————————————————————————————-

How Do I
A multi platform app that provides fast and valid answers to specific questions by taking advantage of a community.

Class Blog Post:
http://www.ryanraffa.com/classes/ip2013/mozilla-how-do-i-app/

Video:

Mozilla How Do I? App concept from Susse Sønderby Jensen on Vimeo.

Presentation:
http://www.ryanraffa.com/classes/ip2013/wp-content/uploads/2013/04/presentation_howdoi1.pdf

Team:
Liz Tolson – [email protected]
Susse Jensen – [email protected]
Galina Rybatsky – [email protected]

—————————————————————————————-

CART
A conceptual augmented reality tool that allows for assistance and collaboration on a whole new scale.

Class Blog Post:
http://www.ryanraffa.com/classes/ip2013/cart-scenario-video/

Video:

CART – Collaborative Augmented Reality Tool from Mirte on Vimeo.

Team:
by Lightning […] Thunder
Nate Rudolph – [email protected]
Anthony Marefat – [email protected]
Mirte Becker – [email protected]

TowTruck Alpha usability testing

amilewski

TowTruck user testing

Hello TowTruckers!

We recently conducted a one week in-house usability test with Mozilla staff to gather feedback and problems with the current product so we could improve the experience.

We received great feedback and we wanted to share that information with you TowTruckers out there! Our users uncovered many problems (listed below) and we are working hard to fix these issues.

Problems discovered
Here is a list (but not all) of the problems our users encountered during TowTruck Alpha user-testing.

  • Users kept pressing / following the other person’s cursor to follow them around the page and to the next page, and wanted to chat with them that way. #500
  • Users thought they needed to email to invite people to the session. #479
  • Users kept trying to close the browser/tab to end the session. #442
  • Users wanted to go the current position of the user their were following when they went to a new page. #489
  • Users didn’t understand who the participants were in the dock (they thought that was their avatar). #475 and #312
  • Users didn’t understand when a user was down the page (they thought the cursor was just sitting at the bottom of the chrome). #47
  • Users accidentally ended a session, then created a new session, and then tried to send the old link. #456
  • Users kept pressing the participant avatar in the dock because they thought that was their profile and wanted to change their name there. #453

We are currently working to fix these issues and they’re documented here and here.

The Methodology
We gathered ten participants (thank you user-testers!), who had various backgrounds, skill levels and prior knowledge of TowTruck. We then ran one-on-one sessions for approximately twenty minutes each. The last session we ran included two participants to test a real-time multi-user experience.

Some basic guidelines to follow as the moderator:

  • Create a script with a natural flow, and come up with a scenario.
  • Be neutral.
  • Find mistakes in the flow.
  • Do not ask leading questions.
  • Give the participants clear tasks that are realistic to your product, e.g. “You’re having trouble finding a link on the page, so invite a friend to help you find it.”
  • Try not to influence or direct.
  • Record the sessions using video or a screen recorder.
  • We gave each user two scenarios to walk through, that would emulate how they might use TowTruck in a real-world scenario. For example, we tried to model situations similar to coding collaboratively, working on a complicated math problem, or trying to decipher a big document like The Odyssey.
  • Try not to the be a participant.

We went through a few scenario iterations, ranging from trying to use the Firefox Add-on, to cloning existing sites like kayak.com and adding TowTruck to it, to making fake-sites like these:
Odyssey site
Math problem

We ended up using the TowTruck Examples pages. This worked okay because there were fewer bugs, but there was some user confusion. For example, users had to imagine being in an actual scenario like “working on coding a website,” when they were on this sample Code Editor page which didn’t match interactions and context completely.

Here is the example for Scenario #1 instructions:

Scenario 1:
“I need help filling out this complicated form…” -> User experiences the Participant scenario.

Site:
https://towtruck.mozillalabs.com/example/form

Tasks:

  • Join the session.
  • Let me know who you are (change your name).
  • Ask me what you want to do on the page (send a chat).
  • End the session.

As the participant went through the tasks and scenario, they were asked to narrate their thought-process. We found specific pain-points and problems in the flow, from what they said aloud to just observing where they clicked on the screen. Some interactions were cumbersome and awkward, like “creating your profile name” and some UI elements were confusing like the “hangup button.”

During one of the sessions, we “declined to join a session.” This was never tested before and we found all sorts of bugs and problems with that flow.

Normally, it’s best to cluster the feedback with post-it notes and add them to something like Evernote, but wanting to move fast, we threw the notes in Evernote, then went back and watched through the videos to double-check them. The notes were then converted into Github Issues with the Issue tag “user-feedback-Alpha” here.

Conclusion
It’s always great to have some fresh eyes look at the product, use it and break it. Often, when heads-down creating the product, the product-creators get used to certain flows, UI elements, and interactions that they don’t feel strange/awkward anymore, and subconscious work-arounds are created to complete those tasks.

Other user-testing insights:

  • We started to get the same issues and problems popping up when we hit the 6-8 participant threshold, which is a known issue.
  • TowTruck was handy for usability testing because it shows mouse-clicks.
  • We ended up using the TowTruck Examples page, which was okay this time, but it would be better to place TowTruck on sites where users would actually find TowTruck useful.

If you’d like to review the feedback, you can see Github Issues with the Issue tag “user-feedback-Alpha” here or you can check out what we’re working on for Milestone Alpha 4.

We love feedback, so feel free to add TowTruck to your site or app and let us know what you think here!

Thanks!
– Team TowTruck

Announcing Mozilla Hatchery

mozilla

We’re happy to share a new offering from Mozilla Labs called Hatchery, a program and assemblage of resources and people to help Mozillians with early-stage product growth and success.

What Is Hatchery?

We offer coaching, resources and curriculum across various disciplines – user research, testing, design, product development, marketing and more – with a goal to help build Mozilla’s future products and services.

Why Are We Doing This?

Innovation is central to Mozilla’s mission to keep the web open. Without competition and diversity of offerings, the web risks being controlled by one entity and stagnating in development. Hatchery is one way we hope to foster and support continuing innovation at Mozilla. We’ve already started helping a Mozilla project, TowTruck  with pitching and design and look forward to seeing what projects you have as well!

How Can You Be Involved?

  • Submit your product idea! Check out our website, which has more details on what types of projects are a fit and how to apply, and apply!
  • Be a Coach. Currently Hatchery coaches are designers, user researchers, strategists and technologists who give their time and knowledge to participating teams. This happens through meetings in person or remotely (Skype, vidyo, telephone – whatever works). Lots of time it’s reacting to something the team is doing; sometimes it’s providing specific tools and advice. If you think you can help our teams in any of these fields – or others – to turn their ideas into products, please let us know by emailing us at labscoaches <at> mozilla <dot> com.
  • Give us feedback. This is a new initiative and in the spirit of early-stage ventures, we will be iterating early and often. Send questions, comments and constructive feedback to labscoaches <at> mozilla <dot> com

We’re looking forward to building Mozilla’s future with you!

The Hatchery Team

David, Diane, Didem, Paula, Aaron, Jinghua & Simon.

Introducing TowTruck: A Collaboration Service For Every Website

Ian Bicking

1 response

tl;dr
We’re building an experimental service for websites called TowTruck that makes it easy for your users to collaborate in real-time. TowTruck easily gives your website text and/or audio chat, presence, co-authoring, co-browsing, and is built to be extended by your website. Watch the screencast and see it in action.

TowTruck Logo

Do you love using Etherpad and Google Drive (previously Docs) to collaborate? We do too. The potential for that kind of collaboration is one of the great things about the web – except that only a handful of web applications take advantage of that potential. We think that every site should offer simple, easy-to-use, instant collaboration embedded directly on their site.

What makes TowTruck different.

As a web developer, you simply drop TowTruck into your site and it just works. It provides the full out-of-the-box experience users need to get things done collaboratively. It will also give you the opportunity to extend TowTruck to enrich the authoring experience.

Unlike screensharing and related tools, with TowTruck there is no need for your users to jump around to use different applications to collaborate. Your users can collaborate directly and see changes in real-time on your site, no matter the context. Users could be co-authoring a page together, or helping each other out if they can’t find something on your site.

Several libraries have existed to help make your pages collaborative, but they’ve never caught on. (Google have recently announced another.) These libraries tend to emphasize editor synchronization but leave out all the other details. Those details are important: tools to show where each person’s attention is, to chat, to see each other’s movements around a site, to start and maintain sessions.

We want TowTruck to complement the web as it exists, not requiring applications to be replaced or revamped. And we’ve found the web works really well for this – we have tremendous power to apply introspection to web pages. For example, a simple query like $("textarea") can give us the text fields on a page, we don’t need to hook deep into an application’s code to apply these tools. Developing TowTruck has been exciting because it feels like the web was built for this kind of tool.

Why did we want to build this?

The original prototype was built to help budding webmakers. It was trying to be a code editor with the collaboration features you’d expect to see in a Google Drive app.

The technology has changed a lot since that first prototype, and the scope has widened: We want everyone to be able to work together on the web. Not just sharing links, and not just in siloed applications with collaboration features built in. Everywhere we look we see reasons to collaborate on the web: mentoring, making travel plans, triaging bugs, navigating large sites or complicated interfaces. Anytime we find ourselves talking about a page, we have wished we were also working on that page together.

We want to bring the experience of looking over someone’s shoulder to the web. And we want it to be just as casual as that: something you can use to ask a quick question or show something off, with no more barrier to starting than sharing and opening a link.

Learn more.

If you want to learn more, check out the site or check out the screencast. If you want to try it out, use the example. If you want to look at the code check the Github project. If you want to offer an idea, leave feedback here, on Twitter at @moztowtruck, or email the team at [email protected].

The TowTruck team consists of @adruck, @ianbicking, and @simonwex.

We hope you enjoy TowTruck, now let’s collaborate!

Designs for User Controlled Shared Data

Ed Lee

(Cross-posted on the UX blog)

The Prospector team has been looking at analyzing data in Firefox, sharing a summarized form, and protecting privacy with Mozilla principles. We’ve been designing some prototypes of how to present these concepts to the user, so we would like to share a view of our very experimental mockups to get some of your feedback.

Experimental dashboard for users controlling shared data

The high level concepts of this dashboard fall into 3 parts:

  1. Informing users that they’re in control of their data
  2. Letting users see and control what they share
  3. Helping users understand the effects of sharing

In later posts, Aaron Druck, a designer helping out with these prototypes, will be going into the details of each of these parts with descriptions of the intended goals of each control, display, etc. Right now, we’ll focus on the overall composition of parts of the dashboard and not get too detailed as the specific text or shapes are preliminary content that will most likely change as we continue.

For the first part at the top, we want to give users a sense of empowerment by providing a description of control over their data. It should be brief yet informative enough so users understand what they’re able to control and sets some expectations of how the data is analyzed from Firefox. We also want to give users a quick peek into how Mozilla protects their data, which gives more control to the user. For each of these pieces, users who do want to learn more should be able to do so.

The second part is on the left side where users see a representation of their analyzed browsing behavior as well as controls to adjust their shared data. We want users to be able to easily understand what amount of data and what type of data is being shared or potentially can be shared. The interface should be simple enough in the common case for the users who want basic changes but potentially also allow for more detailed controls for advanced users.

The last part on the right side is a feedback module to give users a sense of how the web changes as they control their data. We want to help users make an informed decision that they are comfortable with, so this area should lead users to change their settings if they are uncomfortable or want more. For the feedback to be useful, users will need to be able to quickly understand and “consume” what is shown to get an immediate reaction and make a decision.

We would like to get your feedback on these high level parts, so don’t get caught up too much on any particular detail or visualization of this experimental prototype. Below are some initial questions to get you thinking, but feel free to provide other comments:

  • Are the three main parts the right combination? Anything missing or unnecessary?
  • Do the conceptual parts need to be distinct parts? Can they be combined visually?
  • Will users understand the connection/flow from the left control and right feedback?
  • How should the parts be organized? One view for each? Composition/arrangement?
  • What should be the relative importance? What comes first? Which is larger?

– Ed Lee on behalf of the Prospector team

New Tab Site Suggestions

Ed Lee

4 responses

Over the past weeks, we’ve talked about ways to analyze data in Firefox and to share that data out of the browser while keeping users in control. Today we’re putting those pieces together with a proof-of-concept: Site Suggest. This simple add-on locally analyzes your browsing history to pick an ODP category that you seem to have interest in then makes a secure and privacy-protected remote request for a site suggestion to then display on your new tab page.

A site suggestion with why it was suggested

Conceptually, the flow is much like the add-on update mechanism in Firefox. Users install add-ons, then Firefox makes a request to see if any of those add-ons have updates, and then updated add-ons can change the behavior of Firefox. From a high level, here are the similarities of Site Suggest and add-on updates:

  1. The user creates activity in Firefox (browsing pages vs installing add-ons)
  2. Firefox analyzes that behavior (finding ODP categories vs listing add-ons)
  3. Firefox securely sends the data (sent to Site Suggest vs add-ons servers)
  4. Firefox updates with the response (new tab content vs add-on functionality)

One thing we want to be explicitly clear is that the ODP category sent to the server is not tracked with the user. The site suggestion server does not use cookies or any way to identify the request to then use previous requests to personalize future requests. This simulates the terms of use on the user’s data where the server is only allowed to use the information in the request for that one response. This also means that if your interests change, the server is always using the freshest data to personalize the site suggestion.

For this proof-of-concept, we didn’t bother creating a large number of suggestions, so we don’t expect people to get high quality recommendations. In fact, we probably could have put all the suggestions in the add-on, and the site suggestion on new tab experience would be exactly the same. For many users, there isn’t a distinction between local suggestions and remote suggestions, and these users trust Firefox to do the right thing.

But by having this secure and privacy-protected remote request, the quality of suggestions can improve without requiring a Firefox or add-on update. And this is especially important as the number of potential suggestions increase, so instead of having millions of unused suggestions built into Firefox that can become outdated, Firefox can focus on just the newest suggestions the user cares about.

We would like your input on what you think about this privacy-protected flow of data that improves users’ Firefox experience. So install Site Suggest then open a new tab, and see if that triggers any ideas for you. As always, you can check the source on Github, provide feedback, and submit issues or suggestions!

– Ed Lee on behalf of the Prospector team

Ideas on Terms for Shared Firefox Data

Ed Lee

We’ve gotten good responses about how to protect shared Firefox data, so we’re following up by highlighting some interesting ideas and clarifying some points. The initial concept of setting some terms of use on the data shared from Firefox seems to be easily understood, but there are many aspects with their own set of details. The four topics in the rest of the post cover a wide range: rewarding good behavior, using data non-transactionally, increasing transparency, and creating contracts.

Rewarding good behavior

The about:trackers experiment tries to simulate what would happen if a web site had access to a user’s locally analyzed Firefox data and if the site could have used cookies to get more information about the user. It would block cookies to prevent mixing the user’s Firefox data with other data as well as to only allow the Firefox data to be used for the current request. More importantly, this would mean a web site that followed the terms of use on the user’s data would work normally without any blocking.

Firefox could warn of breached contracts like it does for malware

This tool of blocking can be seen as taking away from web sites, but Firefox can also reward good behavior without directly negatively impacting the web sites that do not comply with the user’s data requirements. For example, Firefox can detect if a web site is known to break the user’s terms and then suggest a similar web site with a better privacy policy that respects the user’s data. It’s then up to the user to decide if they want to keep using the current web site or to try something better. This rewarding good behavior helps web sites not only by directly increasing visitors but also by indirectly reminding users that their data is safer, and these users might be willing to spend more money than usual for that safety.

Using data non-transactionally

One concern about the original proposal was the requirement of temporary or transactional access to the Firefox data. This means web sites can use the data only for the current request to personalize the content, and future visits could not be personalized if the user turned off the sharing of their data. There could be contexts where the user’s data isn’t readily available for the web site such as the user visiting from a different device, computer, or browser; so it might make sense to allow the data to be saved on servers for short periods.

Just like how the terms of use on the data could require transactional use, the term could allow a site to borrow the user’s data — almost like leasing some private property from the browser. Again, the terms could put requirements on the remote storage of data: for how much data, in what fashion, to whom has access, and until when. The most direct approach for specifying time could be a number of hours or days, but another interesting approach could be to put a price per unit time where the monetary value could be directly exchanged or indirectly given through discounts.

Increasing transparency

While all the terms are for the user’s benefit, an interesting idea is to have some primarily to help users learn more. An example term would require the web site to report back to the user what parts of the user’s data have been used. Depending on how much the user has allowed to be shared, there could be many attributes, so for example, a technology related page might only use the fact the user is interested in smartphones and ignore the user’s interest in sports.

This reporting back to the user could be formalized through the browser, so Firefox would understand what’s being used as opposed just having the page display some text. This means Firefox could provide a standard interface for users to check what data is used on each of their tabs without needing to search around on the page. Firefox could then also provide a view showing each individual piece of shared data with the sites that is making use of it.

Creating contracts

Some responses to the original terms of use idea raised concerns about the effectiveness of contracts because individual users are less likely or able to make sure the contract is not broken. However, a web site that is breaking the contract with one user is likely to be breaking contracts for many users especially if there is a standard set of terms across all those contracts. These users could simply stop using the web site that blatantly fails to fulfill the contractual obligations, or if the problem is widespread, concerned users can get together and raise awareness to notify the offending party’s breach of contract.

Another approach would be to have a separate entity take on this role of making sure contracts are not broken. A non-profit that cares about the Internet and users’ privacy would seem to fit the part quite well. 🙂 This group could also directly create contracts with web sites instead of creating them at the per-user level. Contracts are mutually beneficial and agreed upon by both sides, so the non-profit that puts users first can set some standard terms to protect users’ data and privacy. None of this would have to be limited to just Firefox users either, so potentially all Internet users can benefit from the non-profit’s contracts with web sites.

We believe there will be many more ideas in this area given that we made this extra post to cover four topics from the one initial idea last time. So please continue to provide feedback on how Mozilla can help protect users’ data. We’ll continue next week with the originally scheduled experiment that puts some of these pieces of user data together.

– Ed Lee on behalf of the Prospector team

about:trackers – Protecting Shared Firefox Data

Ed Lee

5 responses

Last time we explored improving the Firefox experience with locally analyzed data and sharing summarized data to web sites. The Prospector team understands the importance of giving users control of what Firefox data is analyzed and what summarized data is shared. Even with Mozilla evaluating sensible defaults that support privacy by design, some users might want to share more or less, and this gets even trickier when data is shared to web sites out of Firefox’s direct control.

We’re looking into ways for how Mozilla can help protect users’ data that gets shared to improve the web experience. We’ve gotten some useful feedback already on how to analyze data in Firefox and what to do with the data, so we would like to hear more from you about this topic of protecting shared data.

One idea we have is related to the “terms of service” that users often need to agree to before using certain web sites. Except here, we want to flip that around and require web sites to agree to terms before accessing the summarized Firefox data.

Using that as a starting point, there are many ideas of what could be included in the terms, such as requiring the web site to only use the shared data for the current request and not associating the data with the user for future requests. This would ensure that web sites are using the freshest Firefox data that might have recently changed, and this gives users control to grant access to more or less data.

To help users make sure web sites comply with the terms, Firefox can provide tools such as targeted cookie blocking or connection blocking. These are useful because without cookies, the web site would have a harder time to associate any shared data with the current user. If this safeguard at the individual user level isn’t enough, Mozilla could reveal the bad acting web site and even put up warnings for all Firefox users similar to the existing built-in phishing and malware protection.

Different policies based on web site behaviors

We’ve put together a proof-of-concept add-on, about:trackers, that explores this idea of policies that allow for cookie blocking and connection blocking. While this add-on shares no data to the web sites with accompanying terms, this experiment gives users some settings to adjust and see if their browsing experience would be positively or negatively affected.

Just like the about:profile proof-of-concept, the main purpose is to get people thinking about what could be done in Firefox. So the exact details of the concept policy aren’t too relevant, but at a high level, about:trackers will gradually block sites that would have been able to see you across too many other web sites. It somewhat simulates a term that allows access to a user’s shared data as long as the web site isn’t trying to get other data by using cookies when on other web sites. This also means that web sites that don’t rely on cookies will have their connections working normally.

With the idea of Firefox helping enforce terms for the user on a per-web-site basis, this could help shift more control of data to the users — a better web experience on the user’s terms. So please try out about:trackers without restarting Firefox and think about ideas of how Mozilla can help protect users’ data. Next week, we’ll put some of these pieces together in yet another experiment. And as always, you can check the source on Github, provide feedback, and submit issues or suggestions!

– Ed Lee on behalf of the Prospector team

Update on Firefox Marketplace

mozilla

4 responses

Modern browsers based on open standards (like Firefox) enable developers to create amazing Web applications and websites. Mozilla is rapidly increasing the capabilities of the browser platform, which means developers can build more and more of their applications using Web technologies and we’ve been working hard to add more capabilities to the Web as a platform.

We first started working on building these capabilities into the Web and developing our own Firefox Marketplace last year. And, we have seen on the Web and particularly in mobile – Apps, those focused experiences are gaining massive adoption by consumers.

The future is mobile and we’ve made amazing progress with exposing Web APIs across platforms. We’re working to unlock the power of the Web on mobile, just as we did on desktop.

To this end, and based on what we have learned through our efforts to date, we’re now focusing our Marketplace offering. While we previously believed that desktop was the right initial first step to building out an HTML5 app ecosystem, we now believe that we need to pivot further and lead the way with mobile.

We’re not in any way changing our commitment to add features to Desktop as we still feel that Apps are as relevant on desktop as any other environment, but we do need to focus on mobile for the next few releases and as such you won’t see any changes in Desktop for a short period. As soon as mobile has caught up to desktop in features related to Apps we will refocus.

This means:

1) Mobile platforms will be the first target for our HTML5 apps, with desktop to follow providing the means for users to discover and manage their experience;

2) Initial platform targets are Firefox OS and Firefox for Android, with others to follow from our successes there.

We’re happy with the progress we’ve made and excited to share more soon about the next steps for the Web apps ecosystem and Firefox Marketplace. Stay tuned!

Improving Firefox with Locally Analyzed Data

Ed Lee

2 responses

Just as there are many ways to analyze data in Firefox, there are many different ways to use that data to improve the Firefox experience. For example, many people love using the AwesomeBar in Firefox because it helps them navigate to pages with just a single keystroke. This is possible because Firefox locally keeps track of the pages visited and previous selections.

The Prospector team would like to have a conversation about how data can improve the Firefox experience while supporting Mozilla’s principles such as protecting user privacy. Below are some initial ideas for people to ponder for changes to the Firefox interface and websites.

Using the ODP categories shown in about:profile, Firefox could understand what types of sites interest you. Keeping in the context of navigating the web, Firefox could help you focus on some of the many links on a page by highlighting those that you will find interesting. For example, social streams and search result pages often have many links to different sites, but you might only have time to click on the ones that are of interest.

Firefox helps you scan by highlighting interests

On a similar idea of highlighting links to interesting domains, Firefox could analyze the page titles in your history to figure out what topics you look at often. With that data, Firefox could highlight those topics or keywords on pages that have a lot of text such as a list of news or a long article. This saves you time when scanning while letting you see other topics or read the rest of the article for more context.

There are many interesting uses of data outside of navigation such as data organization, behavior matching, content (re)discovery, and more. Some brief ideas include auto-tagging of history, context-awareness of time/location/users of Firefox, and reminders of potentially-unfinished or one-time previous browsing experiences.

Automatically generated list of interests to present

A different kind of benefit of analyzing the data in Firefox is that the results can be processed to a summarized form such as “interested in Video Games,” using the example from about:profile. Potentially Firefox could facilitate the process of sharing this summarized data to websites by helping the user make an informed decision about what is shared to which sites.

Assuming users could easily share summarized interest data, some barriers of users trying out a new website are removed. For example, a content website could easily personalize itself to a user that presents a list of interested topics after a single click. This is contrasted with current patterns of asking new users a series of questions that might even include log-in credentials to import data from other sources.

There could also be benefits for the regular users of the website because now users are in control of how they present themselves to a website. Firefox could keep the interest data up-to-date, so the website can show users the most relevant content. This also means users might not even need to go through an account creation process nor be bothered to log in when returning to the website.

This is just one simple example of how Firefox could improve the web experience by facilitating users to share data. Next week we’ll focus on ways of protecting users and helping them feel safe about potentially sharing data to websites. If you have ideas for other ways to use data in Firefox while supporting Mozilla principles, please send us feedback.

– Ed Lee on behalf of the Prospector team