MozillaWiki - User contributions [en]

MozPDX

2012-04-30T17:25:09Z

Jasongrlicky: /* People */

= Mozilla Community in Portland, Oregon =

* Mailing list: Join the [http://www.red-bean.com/mailman/listinfo/mozilla-pdx mailing list] notifications for get-togethers, etc.
* IRC: We hang out in [irc://irc.mozilla.org/#mozpdx #mozpdx on irc.mozilla.org].
* Co-working: Mozilla has a collection of accounts at [http://collectiveagency.co/ Collective Agency]. Contact the mailing list or chat room above to ask about meeting up with other Mozillians there and using the space.

== People ==

* Dietrich Ayala ([http://autonome.wordpress.com blog], [http://twitter.com/dietrich twitter]) - works on: Firefox front-end, Jetpack, perf
* Jim Blandy ([http://www.red-bean.com/jimb www]) - works on: ActionMonkey
* Dave Camp - works on: Firefox Developer Tools
* Crystal Beasley
* Allen Wirfs-Brock
* Ben Kero
* Taras Glek
* Wil Clouser
* Jeremy Orem
* Christie Koehler ([http://twitter.com/christiekoehler twitter], [http://subfictional.com blog]) - works on moving various webdev projects through the queue
* Tim Abraldes - works on: Windows Platform Integration
* Benjamin Sternthal [http://twitter.com/bensternthal twitter] - works on WebDev (Project Manager)
* Justin Dow (jabba) - IT/Infrastructure manager

== Lunch ==

We meet up occasionally for lunch, coworking, etc. Join the list to get notified.

Apps/ShowAndTells

2012-04-13T17:04:30Z

Jasongrlicky: /* Developer Ecosystem - everything else that leads to more Apps in our marketplace */

= 2012-04-13 =

== WebRT on desktop (including webapp mode and native app experience) ==

== WebRT on Android (including webapp mode and native app experience) ==
== AppSync (for WebRTs and HTML5) ==

== Marketplace - developer interfaces on desktop; consumer interfaces on mobile & desktop ==

== Developer Ecosystem - everything else that leads to more Apps in our marketplace ==
* [Daniel & Jason] - Marketplace App Developers mocks:
** [http://people.mozilla.com/~jgrlicky/drop/apps/Ecosystem/Landing%20Page/Ecosystem_Landing_Page.png Landing Page]
** [http://people.mozilla.com/~jgrlicky/drop/apps/Ecosystem/Landing%20Page/Ecosystem_Tutorial_Page.png Tutorial Page]

== Other ==

Older show and tells - https://wiki.mozilla.org/Apps/ShowAndTells/Older

2011-09-15T23:55:24Z

Jasongrlicky: /* How work with your existing authentication system */

= BrowserID Field Guide =

== What BrowserID looks like on your site ==

[UI Mockups]

== How work with your existing authentication system ==

When signing in, there are different paths that users can take. These paths vary based on which authentication system the user used when registering for the site, and which method they are attempting to use to sign-in now:

[[File:BrowserID_Field_Guide_Migration_Chart.png|500px|Migration Chart]]

It's up to you to implement a way to stitch accounts together when merging accounts. Note that this requires that the authentication backend provide a way to look up a single account given a unique email. If a user has multiple accounts linked to a single email, you need to resolve that with your users by some means.

== How to move your users to BrowserID ==

One idea is a one-time notification that the site is exclusively moving to BrowserID as an authentication system in several months. Users can continue to login with passwords until then.

== How to promote BrowserID To your users ==

If you're not sure what to tell your users about BrowserID, here is a brief description you can give your users:

MORE LIKE PAST-WORDS, AM I RIGHT?
* It's great
* No passwords

2011-07-26T18:19:36Z

Jasongrlicky: /* Design Plan */

This project is about getting a responsive design on Mozilla.com.

== Team ==
*Chrissie Brodigan (Product Owner/TPM)
*Sean Martell (Design Director)
*Jason Grlicky (Design Lead)
*Anthony Ricaud (Dev Lead)
*Raymond (QA)
*IT TBD
*Security TBD

== Meeting Notes ==

*Meeting Notes - [http://etherpad.mozilla.org:9000/mobile-in-mind-072111 07-21-2011]
*Meeting (Jason (Lead), Chrissie (TPM), Raymond (QA), Jeremy (IT/Security), Sean (Design), Anthony (Moz.com), Mike Alexis), July 27, Wednesday @11AM
*Meeting Notes - [http://etherpad.mozilla.org:9000/mobile-in-mind-072011 07-20-2011]

<br>

== Project Management & Bugs ==

'''Tracking Bug:''' [https://bugzilla.mozilla.org/show_bug.cgi?id=673202 673202]

'''Initial Experiments:'''

*[https://bugzilla.mozilla.org/show_bug.cgi?id=672903 672903] - Design mockup for Simple Responsive Page Experiment
*[https://bugzilla.mozilla.org/show_bug.cgi?id=672905 672905] - Design mockup for Complex Responsive Page Experiment
*[https://bugzilla.mozilla.org/show_bug.cgi?id=672906 672906] - Implement Simple Responsive Page Experiment
*[https://bugzilla.mozilla.org/show_bug.cgi?id=672910 672910] - Implement Complex Responsive Page Experiment

<br>

== Design Plan ==
=== Expectations ===

Giving mozilla.com a responsive design will be a difficult design exercise, but worth it for our mobile users, for site maintenance, and for future web design projects.
* Ideally, desktop users would not know anything has changed, since we're trying to change as little as possible with the site design. If anything, we will be subtly streamlining the site content and navigation, and making the user interface elements more consistent. Most of our design effort will go towards finding unique solutions that don't degrade our existing experience.
* On many design challenges, we should be able to provide seamless fallbacks that will not be shown to users on wide screens.
* A focus of this project will be moving away from a pixel-perfect design mentality to one that embraces the flexibility of the web. Potch's comment on [http://etherpad.mozilla.org:9000/responsive-design-mozilla the etherpad] sums it up wll:

''"For this to work, we need to move away from PSD == website mentality, and into a 'design vocabulary' style of UX mockup. I don't expect a designer to tell me what the page should look like at every width, but to define a series of "checkpoints" at various resolutions. We also need to ensure each page has a primary focus, so when push comes to shove, the most stripped down view is agreed upon. Look and feel is important, but it isn't sustainable or acceptible to be doing compass/caliper measurements on a static image to construct a responsive website. For example, defining a HIG-style set of guidelines for how forms should look/behave (spacings, errors, etc), at what resolution levels sites should transition between various layout states. Full listings of colors (accents, links, etc). I do not think it is appropriate to do this on a Mozilla-wide level, but these things should be defined per-project, with known fall-backs."''

* We will document our findings about the process along the way to make sure that knowledge gained here is reusable on future projects.

=== Timeline ===
The Design Team is Sean, Jason, John, and Chrissie!
* The Design Team will meet to review the [[Mozilla.com/Mobile in Mind/Challenges|list of mobile challenges]] on a high level, and agree on a list of pages we will not need to pay attention to (first run, etc).
* Sean & Jason will set up a series of meetings to discuss each challenge in depth and come up with a list of fallbacks and workarounds to be included on the [[Mozilla.com/Mobile in Mind/Challenges|challenges list]].
* Sean & Jason will produce wireframes of key & exceptional pages. From here they can create a document that details a design vocabulary that can be extended to the whole site. This vocabulary will reference existing visual elements, and will define scaling, spacing, and positioning rules for smaller-screen versions (as Potch suggested above).
* From wireframes, Sean & Jason will produce hi-fi mockups of a few example pages at each target resolution, highlighting the changes on desktop pages for clarity in implementation. They will also flesh out the design guidelines document with hi-fi representations of UI elements. This can then be used by devs along with wireframes to style the site at various resolutions.

== Other Pages ==

*[[Mozilla.com/Mobile in Mind/Challenges|List of design challenges in making Mozilla.com mobile-friendly]]
*[http://etherpad.mozilla.org:9000/responsive-design-mozilla Notes on Responsive Design for Mozilla Websites]

Mozilla.com/Mobile in Mind

2011-07-26T17:09:18Z

Jasongrlicky: /* Design Plan */

Mozilla.com/Mobile in Mind

2011-07-26T16:13:06Z

Jasongrlicky:

Mozilla.com/Mobile in Mind

2011-07-26T16:12:35Z

Jasongrlicky:

Jasongrlicky:

For the 2011 Q3 "Mobile in Mind" project, the first step is to identify a list of aspects of the site which will not translate directly to mobile. This can serve as an outline for the design process, where we address each of these challenges one by one to develop reusable design patterns. We should then be able to apply these patterns to mozilla.com to get a site design that can be more easily made mobile-friendly.

=Mobile in Mind Challenge List=

==There is no Hover on Mobile==

===Challenge===
Hover, as it exists on the desktop, doesn't exist on mobile. Firstly, the user's cursor is not present on the screen aside from their touch. This means that a user effectively can only scroll and click, not hover. Furthermore, since users are touching the screen in order to interact with it, their hand obscures elements as they click them.

===Potential Solutions===
Even if we'd like to provide this method of interaction on desktop, we need to find reliable fallbacks for mobile. One obvious answer is to trigger feedback on clicks as well.

===Examples===
'''Site-Wide:'''
* Main menu drop-downs operate on hover
'''Specific Pages:'''
* http://mozilla.com/firefox/features, http://mozilla.com/mobile/features - Top Features box rollover
* http://mozilla.com/firefox/customize - Personas hover-on-preview interaction
* http://mozilla.com/firefox/technology - Example rollovers
* http://mozilla.com/firefox/central - Tour page features rollovers

==Large Amounts of Content Won't Fit==

Having too much content can bury important information, especially on a small screen.

===Examples===
'''Site-Wide:'''
* Main menu drop-downs have too many subsections to fit, even when arranged horizontally
'''Specific Pages:'''
* http://mozilla.com/firefox/fx - Possibly too much copy on headlines
* http://mozilla.com/firefox/features, http://mozilla.com/mobile/features - Too much content per section, even if we were to create an expandable UI
* http://mozilla.com/firefox/technology - Really a lot of content, especially including examples.
* http://mozilla.com/en-US/firefox/central/ - 8 Steps is a lot of content for a small screen
* http://mozilla.com/mobile/home/ - Too many screenshots for small screens.
* http://www.mozilla.com/en-US/mobile/faq/ - Large amount of content under each section.

==Content Must be Linearizable==

Since the small amount of screen real estate on phones necessitates a linear browsing experience, the information hierarchy must be clear enough that making the content on a page linearized does will not confuse the user.

===Examples===
'''Site-Wide:'''
* Download button at the top of every page may need to be moved to the bottom or removed on small screens to allow page-specific information to rise to the top.
'''Specific Pages:'''
* http://mozilla.com/mobile - We could show one or two download buttons here to users, depending on their user agent. Making them choose between two is tough when space is at a premium.
* http://mozilla.com/plugincheck/more_info.html - What is the most important info on the page?
* Sidebar is of ambiguous importance:
** http://mozilla.com/firefox/technology
** http://mozilla.com/mobile/home/
** http://mozilla.com/mobile/sync/
** http://mozilla.com/mobile/getinvolved
** http://mozilla.com/plugincheck
** http://mozilla.com/press

==Horizontal Space is Limited==

The desktop convention of scrolling downwards on webpages is even more prominent on mobile, due to the limited horizontal space available on phones when held in portrait mode. Thus, interactions that require a lot of horizontal space to function will be frustrating to use on mobile.

===Examples===
'''Specific Pages:'''
* http://mozilla.com/firefox/fx - The content of the spinning wheel popup is horizontally oriented, and the panda graphic takes up a lot of horizontal space.
* http://mozilla.com/firefox/customize - The Add-ons gallery categories employ a tab metaphor that requires a lot of horizontal space.
* http://mozilla.com/firefox/video/ - Horizontal navigation for videos may be awkward.
* http://mozilla.com/firefox/central/
** We won't be able to fit the large image on small screens and keep the same level of detail.
** Absolute positioning of tooltips will be tricky at small screen widths.
* http://mozilla.com/about/contact
** Google Map may need to be modified or omitted for small screens.
** Horizontal list of options will wrap.
* http://mozilla.com/legal/fraud-report/index.html - ReCaptcha is fixed-width. Not sure how this would work on mobile, should be prototyped.

==Popups Should be Used Sparingly==

Popups can be great for letting a user interact with a specific object at a deep level while maintaining context in the page. On mobile, though, because the small screen size does not allow much content in popups and it is not something that users expect in mobile websites, many times other interaction paradigms may be appropriate.

===Examples===
'''Specific Pages:'''
* http://mozilla.com/firefox/central/ - with too much content in a popup, the user may lose context.
* http://mozilla.com/mobile/home/ - Launching a standalone video player directly may be appropriate here (Similar to what was done on Web O'Wonder)

==Tabular Data is Difficult to Fit on Small Screens==

Due to the horizontally-oriented nature of tables, they often won't fit on small screens. Luckily, in many cases the data can be represented in other methods.

===Examples===
'''Specific Pages:'''
* http://mozilla.com/plugincheck - Plugin details table
* http://mozilla.com/plugincheck/more_info.html - Fully Supported Browsers table

==Complex JavaScript Animations Will Not Perform Well==

Smooth animations on desktop cam evoke a sense of fluidity and technical marvel. On the diminuitive processors of many mobile devices, however, animations look choppy, make the page feel slow, and can even confuse the user about the state of the page.

===Examples===
'''Specific Pages:'''
* http://mozilla.com/firefox/fx - After being clicked (on a slow phone), the wheel takes longer than expected to react.

=Other Considerations=
* Videos will probably need to be reencoded to play on Android and iOS devices. We ran into this with Web O' Wonder.
* There are times where content should probably be altered based on the user's UA string. A I'll single out for consideration:
** http://mozilla.com/mobile - Download button should reflect user's phone, like on the main mozilla.com
** http://mozilla.com/firefox/channel - Need to see mobile nightly & beta
* We need to decide what happens when a user of a given device visits mozilla.com. Are they redirected to /mobile? /new? /fx? /mobile/home?