mozilla-labs-concept-series Google Group

iPhone App - 20/20 Vision

bdgmndz...@gmail.com (Twenty Twenty Vision) — Mon, 31 Dec 2012 13:43:13 UT

iPhone App - 20/20 Vision - [link]

Re: Ubiquitous Firefox Revisited

david.re...@gmail.com (David Regev) — Thu, 20 Dec 2012 13:37:33 UT

*Afterword*: Making It Work

Thanks to a fruitful and insightful discussion, I’d like to revisit the
concept with some answers to the questions I asked at the end of my
proposal, along with some new ideas to modify and compliment the design. I
will also discuss how we might implement this system, and what needs to

Re: Ubiquitous Firefox Revisited

david.re...@gmail.com (David Regev) — Sun, 11 Nov 2012 16:33:07 UT

This “touchpad” component is exactly what the Palm Prē (the first webOS
device) had: a gesture area
<[link]>below the display. When
the HP TouchPad came out, the gesture area was
gone, probably due to the difficulty and expense of putting a gesture area
on all four sides of the display. That version of webOS did, however,

Re: Ubiquitous Firefox Revisited

kithpendra...@gmail.com (Kith) — Sun, 11 Nov 2012 14:57:20 UT

Good thinking with page-up/down; I was actually thinking of the top and
bottom edges being neutral -- that all commands would be issued from the
right/left edges -- but I do like the screen-sized scroll thing better.
If the user is meant to touch outside the display, perhaps a hardware
change would be in order: a simple touchpad component (probably just a

Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

david.re...@gmail.com (David Regev) — Sun, 11 Nov 2012 14:32:40 UT

Oi, Pedro! You should read my follow-up
proposal<[link]>.
In my new design, the URL is still attached to the page and goes away
during normal usage, but it is not inline with the page, so there could not
be any confusion. Also, I address how commands/Ubiquity should work there

Re: Ubiquitous Firefox Revisited

david.re...@gmail.com (David Regev) — Sun, 11 Nov 2012 14:21:28 UT

Oh! That’s an interesting observation. I wonder how common that is. Yes, it
could lead to accidental edge swipes in my system. Perhaps accelerated
scrolling would fix that. Also, making the physical edges of the screen
actually touchable and exposed to the operating system should also make
accidental edge swipes less common, since we could require you to touch

Re: Ubiquitous Firefox Revisited

david.re...@gmail.com (David Regev) — Sun, 11 Nov 2012 13:25:51 UT

I love pie menus, so I would love to be able to include one, if it works
well in testing. In my design, a swipe from the top is already used to
invoke the menu, so this could work with a top-swipe. It would also work
equally for devices with a hardware button. Alternatively, we could reserve
corner swipes for this. One could swipe from the top/corner of the device

Re: Ubiquitous Firefox Revisited

kithpendra...@gmail.com (Kith) — Sun, 11 Nov 2012 13:18:59 UT

Ah... I think I see what you thought I meant there. I'm sorry, that's my
bad for being unclear. The problem I'm having is that the scroll mechanism
on iOS doesn't handle long scrolling well and I was swiping up from below
the bottom edge of the screen just to get more room for my gesture so I

Re: Ubiquitous Firefox Revisited

david.re...@gmail.com (David Regev) — Sun, 11 Nov 2012 12:36:04 UT

I had no idea iOS did that. That sounds unnecessary (and not too
discoverable) to me. For rapid scrolling, I prefer what some mouse drivers
already do: the first scroll gesture (using the scroll wheel on a mouse or
flicking a page with your finger) initiates scrolling with inertia, the
next gesture while the page is still moving multiplies the speed. When

Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

pedrolrbe...@gmail.com (Pedro Bessa) — Fri, 09 Nov 2012 15:23:57 UT

We are redesigning them from scratch for iPad. I wish I could see what
Firefox will look like in iPad.

Re: Community Concepts: Ubiquitous Firefox, Part 1: How Do You Design a Debris-Less Browser?

pedrolrbe...@gmail.com (Pedro Bessa) — Fri, 09 Nov 2012 15:22:40 UT

Somebody asked me elsewhere what I thought about the url being scrolled
along with the page. I think it would look like the url belongs to the page
content when in fact they're separate things. The url bar can show the url
and be used to write commands. There's no need to show the url elsewhere.

Re: Ubiquitous Firefox Revisited

kithpendra...@gmail.com (Kith) — Thu, 08 Nov 2012 19:55:02 UT

I gave this some more thought, including some thoughts about rapidly
scrolling back up the page. Why don't we reserve the top and bottom edges
for scrolling and use 2-step gestures from the sides.
Quick mockup<[link]>
Dragging from the edge (the arrow in the mockup) to the center would show a

Re: Ubiquitous Firefox Revisited

kithpendra...@gmail.com (Kith) — Wed, 07 Nov 2012 19:31:31 UT

I was browsing on my iPod Touch the other day and found myself swiping up
from the bottom to scroll quickly. Do you think that behavior will be an
issue with the Delete/Archive gesture? Maybe it's appropriate to make D/A
a 2-gesture command? Or do you have some other method in mind for rapid
scrolling?

Re: Ubiquitous Firefox Revisited

david.re...@gmail.com (David Regev) — Thu, 01 Nov 2012 13:16:06 UT

As I mentioned, there may need to be some sort of hierarchical command

I imagined the animation to be something like zooming out from the current

You’re right, in that it may be disruptive. If it does become necessary to
separate the command interface from the canvas, I would preserve the zoom

Re: Ubiquitous Firefox Revisited

kithpendra...@gmail.com (Kith) — Thu, 01 Nov 2012 00:45:16 UT

this before, but didn't include it in the mockup because I couldn't think
of a good place for it to come from (spatially).

structure. The cloud was mostly something I threw in to have a structure
present without actually having the real command set available. I agree
with your observation about Ubiquity previewing various likely commands