Mozilla Labs is starting to experiment with linguistic interfaces. That is, we’re playing around with interfaces where you type commands and stuff happens — in much the same way that you can type a location into the address bar in order to go somewhere.
I think this is cool because, for one thing, I think language-based interfaces are seriously under-explored compared to pointing-based interfaces. For another thing, I used to work on a project called Enso. Enso’s a language-based interface, where you type commands in and stuff happens. I think we got certain things right and certain things wrong in Enso’s UI design, so I want to take another crack at doing it better.
Here’s my current theory.
Those are the three “E”s. Let’s unpack ‘em a little.
“Easy to learn” should be self-explanatory. Even if a tool is super-efficient and incredibly powerful, if it’s too hard to learn, it’ll be relegated to the “experts only” ghetto. Yeah, that’s right, I’m talking about you, Unix shell. (ahem, Unix/Linux/Posix/BSD/etc.) The original language-based UI, the oldest UI still in common use, and the one which has given the whole concept of “type what you want to do” a bad name for the last thirty years, serves as an excellent counter-example. For a linguistic UI to be easy to learn, it should strive to avoid all of the following misfeatures of the shell: (more…)
]]>It’s these principals that inform the design of new features long after the original design as been coded, released, and iterated on. In discussions with the perspicacious Mike Beltzner, another design principal emerged.
6. Use modal overlays sparingly, if at all.
To be sure we are on the same page—I’m may be partaking in the dangerous hobby of coining new terminology—an overlay is simply a content area that sits in front of the content beneath it. The aspect that makes a modal overlay modal is that when it is up, the content “beneath” the overlay cannot be acted upon until the overlay is dismissed. Although a modal overlay may be visually transparent, it is never interaction transparent: you must always take action, like clicking “okay”, before continuing with your workflow. While I’m living dangerously, I’ll toss one more phrase into the mix: a state-forgetting modal overlay is an overlay whose state is reset every time it is summoned. That is, any work you do in the overlay is lost when you dismiss it. (more…)
]]>Ubiquity is heavily informed by Enso, a software product developed by me and my colleagues at Humanized from 2005-07. Aside from the benefits outlined in Alex Faaborg’s blog post entitled The Graphical Keyboard User Interface, this experiment is intended to solve few other problems, one of which I’ll address in this post.
Web applications, much the same as desktop applications, are a bit like isolated cities: it’s difficult for an end-user to arbitrarily share data and functionality between them. This is alleviated to some extent by creations like Firefox Add-ons that add toolbars or sidebars to Firefox’s UI, Bookmarklets, and Greasemonkey, but while all of these solutions are powerful, each comes with its own set of problems. The buttons and bars of many Firefox add-ons don’t scale well because of the valuable screen real-estate they consume; Bookmarklets are restricted in scope because they only have the access privileges of the website they’re running on; and Greasemonkey doesn’t prescribe any kind of interaction model, which makes it difficult to reuse the functionality of a script in a context other than the ones it was expressly designed for.
]]>User experience is the most important aspect of having a compelling mobile product. Every bit of interaction and pixel of presentation counts when typing is laborious and screen sizes are minuscule. Many of the standard interaction models, like menus, always-present chrome, and having a cursor, don’t necessarily make sense on mobile. It’s a wickedly exciting opportunity but there are myriad challenges to getting it right.
One avenue for exploring this opportunity is through Mozilla Labs, which is about pushing the envelope towards better and brighter interaction horizons, as well as incorporating a winder community into the innovation process. This concept video explains one direction we are thinking in, and we’d love to inspire participation in thinking about other directions.
See the demo video and read the post on Aza’s blog.
]]>What are you to do if you want readers to promote your content? Kevin Rose, of Digg, put it succinctly: “Encourage your visitors to submit their favorite stories directly to Digg [with a Digg badge].” Not everyone uses Digg. You have to decide on which bookmarking site, if any, to dedicate your precious screen real-estate. It’s a hard choice. If you choose poorly your reader won’t vote—it’s not a single click coupled and out-of-sight means out-of-mind—and your content losses its chance to make it big. You have to choose your horse wisely.
Read the rest of the post for a way to figure out which social bookmarking sites visitors use, on a per-visitor basis. JS library included.
]]>Developer extroadinare, Atul Varma, said it best: “I hereby classify restarting Firefox during development as a ‘barbaric measure’”. Of course, restarting Firefox to install extensions is like-wise barbaric.
As a simple learn-to-write-extensions project, I decided to make a Gmail notifier. All I want it to do is and notify me—in a humane way—when a new email came in. As I dug into the the extension world, I found myself day-dreaming.
Read the rest of the post for some awesome code, that may or may not work.
]]>One place I see the desire to separate the two webs is in geolocation. Location is often billed as the next killer-app of the mobile world, and people generally assume that it is a feature that will be bound to mobile devices. Yet, there are compelling reasons to have location information available to laptops as well: it is nice to have contextually relevant information available to me while working at a new coffee shop, traveling, or when farblonjet. At the core of the one-Web vision is the continuity of experience across…
Read the rest of the post for the proposed API and other good stuff.
]]>The open source world is the world’s largest and arguably, the world’s best engineering department. It lacks a comparable design department. One of my goals in coming to Mozilla was to work on bridging this gap between the engineering world and the design world. I’ve only begun to think about the problem, and I hope to begin some conversations about the topic soon. An exciting aspect of working for Mozilla is that almost all of your design work can happen out in the open. There are none of those we-take-your-ideas-and-lock-you-away-from-the-sun policies that many other companies shackle their employees with. I hope to start sharing those design processes as well.
Which brings me to: We are hiring! Mozilla is looking for some top-notch UI/UE/UX/IA/IxD/HCI/TLA people. There are few places in the world where the user-to-employee ratio is roughly 1.2 million to 1. Getting to help shape the future of the web is hard work, but it’s easily worth it. If you are interested, send me an email at aza@mozilla.com.
]]>
Bloxes are essentially 3D cardboard Legos that ship flat, and fold up in modular building blocks that are strong enough to stand on. While they aren’t tech per se, we use them for building tables, walls, cubicles, and desks at the Humanized office. Google and Mint.com have already ordered some, and Mozilla has expressed interest in using them in their offices too. This may well be the new thing in terms of agile office-space deployment. Don’t like where a wall is? Just move it! Don’t like the way it looks? Just rebuild it! They are cheaper than cubicles, and much more fun.
They are also eco-buzzword-friendly (meaning that they are made from recycled cardboard and are recyclable).
So head over to Bloxes and order yourself some re-factorable furniture and walls. Then come back here and tell us all about it.
We are now a Python and cardboard shop.
]]>