Mobile/firefoxhome/08-08-2011 - Revision history

Mcoates: /* Security */

2011-08-08T20:53:26Z

Security

← Older revision		Revision as of 20:53, 8 August 2011
Line 59:		Line 59:
	*'''HTTPS vs HTTP Sites'''		*'''HTTPS vs HTTP Sites'''
	** Should we encourage HTTPS by highlighting it in someway? Is it in the user's best interest to know the icon goes to https://bank.com vs http://bank.com		** Should we encourage HTTPS by highlighting it in someway? Is it in the user's best interest to know the icon goes to https://bank.com vs http://bank.com
			*''' 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.

	== Other ==		== Other ==

Mcoates: /* Security */

2011-08-08T20:50:29Z

Security

← Older revision		Revision as of 20:50, 8 August 2011
Line 57:		Line 57:
	*'''Safe Browsing List'''		*'''Safe Browsing List'''
	** Security feature idea: Don't display sites that are flagged by safe browsing list		** Security feature idea: Don't display sites that are flagged by safe browsing list
			*'''HTTPS vs HTTP Sites'''
			** Should we encourage HTTPS by highlighting it in someway? Is it in the user's best interest to know the icon goes to https://bank.com vs http://bank.com

	== Other ==		== Other ==

Mcoates: /* Security */

2011-08-08T20:49:14Z

Security

← Older revision		Revision as of 20:49, 8 August 2011
Line 53:		Line 53:
	**If this model is selected appropriate staffing, budgeting and processes will need to be in place to handle these requests		**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.		**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

	== Other ==		== Other ==

Dloviglio: /* Research */

2011-08-08T20:45:10Z

Research

← Older revision		Revision as of 20:45, 8 August 2011
Line 36:		Line 36:

	* think alouds from 3 homepage views, 2 search result views and pop-up larger views		* think alouds from 3 homepage views, 2 search result views and pop-up larger views
	** [http://fs2.mv.mozilla.com/research/pancake/user5-pancake-prototypes.MP4 user 2]		** [http://fs2.mv.mozilla.com/research/pancake/user5-pancake-prototypes.MP4 user 5]
	** [http://fs2.mv.mozilla.com/research/pancake/user4-pancake-prototypes.MP4 user 3]		** [http://fs2.mv.mozilla.com/research/pancake/user4-pancake-prototypes.MP4 user 4]

	== QA ==		== QA ==

Dloviglio: /* Research */

2011-08-08T20:44:40Z

Research

← Older revision		Revision as of 20:44, 8 August 2011
Line 34:		Line 34:

	=== Research ===		=== Research ===

			* think alouds from 3 homepage views, 2 search result views and pop-up larger views
			** [http://fs2.mv.mozilla.com/research/pancake/user5-pancake-prototypes.MP4 user 2]
			** [http://fs2.mv.mozilla.com/research/pancake/user4-pancake-prototypes.MP4 user 3]

	== QA ==		== QA ==

Nhirata: /* Other */

2011-08-08T20:38:03Z

Other

← Older revision		Revision as of 20:38, 8 August 2011
Line 51:		Line 51:

	== Other ==		== Other ==
			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

Mcoates: /* Other */

2011-08-08T20:36:15Z

Other

← Older revision		Revision as of 20:36, 8 August 2011
Line 40:		Line 40:
	* [http://developer.apple.com/ue/ User Experience]		* [http://developer.apple.com/ue/ User Experience]
	* [http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html Human Interface Guideline]		* [http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html Human Interface Guideline]

			== Security ==

			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.

	== Other ==		== Other ==

Nhirata: /* QA */

2011-08-08T20:27:00Z

← Older revision		Revision as of 20:27, 8 August 2011
Line 37:		Line 37:
	== QA ==		== QA ==
	* Going to start testing again soon		* Going to start testing again soon
			* [http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html#//apple_ref/doc/uid/TP40006556-CH1-SW1 iOS Human Interface Guideline ]
			* [http://developer.apple.com/ue/ User Experience]
			* [http://developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html Human Interface Guideline]

	== Other ==		== Other ==

Nhirata: /* Other */

2011-08-08T20:03:55Z

Other

← Older revision		Revision as of 20:03, 8 August 2011
Line 34:		Line 34:

	=== Research ===		=== Research ===

			== QA ==
			* Going to start testing again soon

	== Other ==		== Other ==

Pavlov at 19:51, 8 August 2011

2011-08-08T19:51:52Z

← Older revision		Revision as of 19:51, 8 August 2011
Line 23:		Line 23:

	=== Add-on ===		=== Add-on ===

			=== iOS App ===
			* What is missing?

	== UX and User Research ==		== UX and User Research ==