From MozillaWiki
Jump to: navigation, search

« previous week | index | next week


  • 650-903-0800 or 650-215-1282 x92 Conf# 265 (US/INTL)
  • 1-800-707-2533 (pin 369) Conf# 265 (US)
  • IRC channel #fxhome
  • Room: MTV 3Z - Zombocom
  • Vidyo: tbd


  • What is remaining for next milestone
    • BrowserID update
    • iOS App update

Engineering Update

Front end

  • New grid layout



iOS App

  • What is missing?

UX and User Research


  • App icon design
  • Visual design for add-on UI


  • think alouds from 3 homepage views, 2 search result views and pop-up larger views



Points for consideration

  • User History Data
    • Storing this data for users will likely result in Mozilla eventually receiving official inquiries on particular user data for criminal investigations.
    • If this model is selected appropriate staffing, budgeting and processes will need to be in place to handle these requests
    • Alternatives: There aren't obvious alternatives at the moment since the intended use of the application is to provide quality information to the user based upon search history. Therefore, the server side needs access to the plain text data.
  • Site "Title" Displayed
    • Need to be cautious about phishing attacks if the Title is used instead of the domain name
  • Safe Browsing List
    • Security feature idea: Don't display sites that are flagged by safe browsing list
  • HTTPS vs HTTP Sites
  • Iframe Approach
    • Many sites will use x-frame-options: deny so this may be an issue if you head down the iframe route
  • Authentication w/ other services
    • Not currently a priority. But, please work closely with security for brainstorming on this if it becomes a focus area. The goal is to avoid Mozilla storing authentication credentials or powerful tokens for users.


nhirata's raw meeting notes: 8/8/2011 Home

- front-end: Jason: most of ian's new mockups done wrapping up the grid Stephan: - server side, pretty good shape, changes to make more server ready - should be done today - backend changes for browserid (should be managable)

- bug: sometimes we don't produce search: client or server side? something to do with JS Fabrice - addon: plan for - need some mock testing - browser id support, need to create an account for our site - using from iPhone app

Stephan - Browser ID test - integration is not difficult - initialize with top ten site for new accounts?

addon - is not perfect - keeps track of new stuff - add browser id and it would be good for first beta -> add-on is used to get data from firefox into pancake -- without using sync

- iOS App basic app that wraps, and we have experiments - we have a few more experiments that we have but haven't been implemented (ian spec'ed out) - need direction; flip to the side? - Option 4 => just loading the page is good enough for now -> tune it a bit and it would be ok?

need the app to send history updates to the server -> do we want people to bookmark? no -> don't add more, just history updates (so that results improve over time)

Firefox integration is secondary, addon implementation is primary (as if it was in the browser)

- overview: => short version: build a product that runs across various devices - built on the web - iphone, ipad - secondarily in a browser - trying to make it stand alone as possible - not tied to anything - the goal is to focus on exposing the site and things you go most often - to be able to get to the quickly - things you been to not necessarily what you want to go to - web search + history/your own data - recording history becomes important due to this -> helping to get you where you want to get to - visually experiment on how people use the web - more of a dashboard/portal to your world. don't like dahsboard/portal wording -> slice that different data into what you want to look at. -> kinda like a newspaper --> stand alone is the focus given the resources, figuring out where to tackle next

-> next milestone -> ios app more... know exactly what we're building -> account creation simplified w/ BrowserID needed -> all sync based currently -> hopefully by end of this week it wont be. -> log into site w/ browserid -> need some way to restrict it -> account creation need to be approved? -> don't want to leave it wide open -> close the default account -> browserid is a bit of a risk, not sure how it works w/ iOS -> need to do some work to make it work in the native App already doing some work to integrate it into Firefox. Think it means they are making some APIs. -> need to do make their pages more mobile compatible. -> Weekly meeting at 2 pm for iOS team -> doesn't need to be perfect, but mostly working is ok

don't need to store but login -> Browser ID + storing password is antibrowserid -> 2 authentications temporarily (don't love that idea ) Madhava - App icon - styling the login and addon UI - Addon screen is going to change after BrowserID - swiping idea going on

- Research: -video recordings, screenshots together - diane not here for the month of september -> teaching Diane, don't lead users -> ian had fun last week

QA going to start testing to -> question iOS Guideline needed to be checked? ---> not anytime soon

mcoates: - new person intro : Mark Goodwin

  • History

-> permanently for longer decisions, don't know yet. Do things to build data for shorter term building. may need to split later on -> need to cut history at some point. need to have at least 3 to 6 months history => point of information on users --> may get asked for criminal information/investigation -> people and process to accomidate that -> people where they want to go who they need to go after -> decrypt it like sync we can't do anything -> crypto research is still several years out - next goal is to try to model out some of the future stuff more. - look at data model better, which may give us a better sense -> more worried about the rest of the data not the history at this moment in time - what are the other things we are talking about: suggestions = index sites, inferences, by groups, - need to figure out social interactions : what are we doing w/ that stuff; don't quite know yet - can store a lot of different stuff -> figure out how to bring in arbitrary data to display (may not necesssarily need to store the data) -> application level, with views. Filtering by some sort of context -> build with other stuff to be able to be added on to -> google account, google docs... filter up versus just google/doc -> application aware -> how do we get beyond specific URLS ->

initial internal results is what is needed: - limited on how many people can use app - roll out to active people. - can use the same account; 1 account per company , can reset once per year? - need to look into that.

-> 400 people here, not everyone is going to do that... going to URL version, app would be the primary focus when it comes out