User-Interface Proposal for Weave on Fennec

Mozilla Labs is working on porting Weave
(our data-syncing extension) to Fennec (our version of Firefox for cell-phones and other handheld gadgets). Weave is still experimental, Fennec is still experimental, so as you can imagine, Weave-in-Fennec is still in the early planning stages. But here’s why it’s going to be cool:

An hour later, you’re standing on the sidewalk in an unfamiliar city, and you need to double-check those directions. Oh no! You forgot to print out a copy! You’re lost! What do you do?

Lucky for you, you have a cell phone with Fennec and Weave on it. You open up Fennec and your map is already there, waiting for you, because Weave automatically synced your open tabs between your desktop Firefox and your Fennec. There’s no need to put your phone in an awkward cradle-thing connected to your computer to sync it up manually, nor do you have to fiddle with BlueTooth settings,
because syncing happens through a server, and it happens automatically whenever you’re online.

Besides tabs, you’ll have access to any other type of browser data that you choose to sync, too — like bookmarks, history, cookies, stored passwords, etc. Syncing goes both ways, so all the names and phone numbers from your cell-phone contact list can be synced back to your desktop computer, too.

I’ve been working on a user-interface design proposal for Weave on Fennec. Weave mostly works invisibly, without user input, but there are a few places where interaction is needed. Since I know that typing in text can be painful on a mobile phone, I’ve tried to keep the amount of text-input required down to the absolute minimum. In the places where I’ve had to introduce new screens and new interactions, I’ve tried to make them a logical extension of Fennec’s existing touch-screen, finger-gesture-based UI.

By the way, if you want to try out Fennec, you can download it here. It’s an alpha version, so no guarantees of anything, OK? But there are versions for Mac/Windows/Linux as well as for mobile devices, so you can run it in a window on your desktop computer and pretend you’re squinting at a tiny cell-phone screen.

The UI Proposal itself is here. It’s a very detailed document aimed mainly at the audience of developers and contributors to Weave and Fennec, so if you have only a casual interest, you might want to just skim it.

Please obscure passwords. On my iphone I zoom in close to data entry fields – and I’m aware of the person sat behind me on the train reading my credentials. I dont mind if you plaintext the last character as long as the last character is in plaintext even after several character deletions. I’m even more aware when I enter my screen unlock pin – the number entry boxes are very large and can easily be read from the seating row behind.

Why am I worried? – because I’ve seen spreadsheets of national significance – highly confidential – being edited by someone on the seat row in front.

One area that might want to think some more about is the bookmarks list area — listing everthing could be overwhelming, and I wonder if there’s a simpler way to support the “I want to get to a site that’s important to me without typing” use-case, given that, if the user’s willing to type, they can get to anything bookmarked through the awesomebar.

Oh, also — one thing to consider for the tab list is that titles may be as (or more) useful a cue as thumbnails. Thumbnails on a mobile device are recent in the users memory, but thumbnails from the desktop system may be less so. It would also mean that we could list tabs (of which there may be a _lot_ more densely.

Great points about Startup / Shutdown and Auto-Sync Behavior. That makes a lot of sense. It’s not just the device getting turned off, either — mobile devices go in and out of signal all the time. We can’t count on reliable connectivity.

richb: Passwords are not now, and will never be, stored on the Weave server in plaintext. That means that we can’t actually send someone their password, which means that my mockup actually promised an impossible feature. Thanks for pointing this out. Where the design document refers to recovering a password, it should instead refer to *resetting* a password. I’ll go fix this.

As for obscuring passwords: remember that under the normal use scenario, the user will have enter the password on the mobile device exactly once, ever. I’m not sure whether that’s an argument for or against, however.

[…] to get it down to the absolute minimum possible user interaction — even more minimal than the earlier mockup I posted. I took the advice of some commenters on my earlier post and added a button to hide/show the […]