Archive for February, 2009

Why Praise is like a Wheel In Gravel

Friday, February 27th, 2009

Positive reinforcement is far more effective than negative reinforcement. It’s as true for people as it is for animals. But, why?

Information theory has the answer.

Is it easier to pull or push a shopping cart through a gravel parking lot? If you’ve tried, you know it’s significantly easier to pull than push the wheels through the gravel. That’s because when you push a wheel, it has many ways to turn aside. Pushing doesn’t provide a corrective force, so when it goes off path it stays that way. When you pull, there are far fewer ways for the wheel to stray because you’re always providing a corrective force — it always bounces back towards the center.

From information theory we know that the more options there are to choose from, the more work is required to choose one. You have to put in work to fight the entropy of choice.

It’s exactly the same with negative versus positive reinforcement. With negative reinforcement, there are many ways for the recipient to react: You are pushing them through gravel, they can turn the wrong way because you aren’t giving them a guiding, corrective force. With positive reinforcement, there is only one way for the person to go. The right way.

So the next time you are about to whack someone for a mistake, think about whether you’d rather be pulling or pushing a wheel thought gravel.

Good interfaces create good habits

Monday, February 23rd, 2009

When you’re first learning how to use even the best of interfaces, preserving your train of thought can be hard because so much of your mind is focused on how to use it, rather than on what you’re trying to do. As you become more proficient at using a good interface, it eventually becomes second nature — it becomes a habit, like walking or talking. You don’t need to think about what sequence of motions you need to perform an action because it’s like your hands have memorized them as a single continuous gesture, saving you the trouble of having to think about them.

Have you ever felt trepidation sitting down to drive someone else’s car, and spent the first couple of minutes “getting a feel” for the controls? That’s the acclimation period where you are concentrated on the “how” instead of the “what” of what you are trying to do. After the controls — the interface — becomes internalized, you don’t need to think about the “how” any more. They’ve become invisible.

Bad interfaces, on the other hand, prevent bad habits from forming — or, worse, they can cause you to form actively bad habits. Have you ever closed a window and hit “Do Not Save”, only to realize a split second too late that it was exactly what you didn’t want to do? That’s a bad habit developed trained into you by a bad interface.

Good interfaces make forming good habits really easy, and they make forming bad habits nearly impossible.

Question: What are some of your favorite examples of interfaces they train you wrong and set you up for failure?

A New Way of Writing Ubiquity Commands: Feedback Needed

Saturday, February 21st, 2009

In Mozilla Labs, one of our mantras when creating news was to write browser functionality is the “five minute rule”. If we can’t write a “hello world” example in five minutes — to get to that gratification of seeing the results of your work — then we’re probably on the wrong path.

Ubiquity passes with flying colors. Writing a hello world command can be done in under a minute. But only for a certain types of commands — as soon as they start requiring a lot of presentation, they become a bit unwieldy. In fact, we haven’t really updated the “map” command because its complexity sort of scares us.

We’ve been working on a new way of writing Ubiquity features which has three major advantages:

(1) It’s much more “webby”.
(2) It’s much easier to debug.
(3) It’s secure.

The goal of this blog post isn’t to announce what we’ve got, but rather to get feedback. We need your feedback before we make it a standard part of Ubiquity.

How it looks

By the end of this “tutorial” we’ll recreate most of the map command. The hard work for the map command is in creating the preview, so we’ll leave that for last.

Here’s the code the defines the command “new-map”. It looks remarkably like the old way of defining a command, but now it’s done inside a something that looks like a webpage. This lets you include complex HTML without the gross anti-pattern of building HTML with Javascript string concatenation.

<html>
<script src="ubiquity.js"></script>
<script>
Ubiquity.defineVerb({
  name: "new-map",
  takes: "address",
  previewUrl: "map-preview.html",
  execute: function(address) {
    window.open("http://maps.google.com/?q=" + address.text);
  }
});
</script>
</html>

There are two fancy things going on here.
(more…)

(Re)gaining Focus

Thursday, February 19th, 2009

I’m borderline ADD. The world is too interesting — there are concepts to learn, projects to dabble with, hypothesis to falsify. That’s means I’m never bored, even when waiting in line at the DMV (hard to imagine, I know). It also means that I when I need to buckle down and focus, I’ll often get distracted. The internet plus my brain is a pretty big place. There are times when I can focus for an entire day. I’ll forget to eat and when I look up from work, I discover that it is 6 in the morning. There are other times, though, that some errant thought hooks my interest like a burr to my socks.

There are a couple things I try to do when I need to focus. I take a shower. I take a “thinking” nap. I clean my desk. I listen to an all-absorbing symphony, like Prokofiev’s 5th symphony (and there I go again, I’m now on the Wikiepdia page, reading about Prokofiev).

I’m curious. What do people do to help themselves focus. And once that focus is lost, how do people reset?

Ubiquity In the Firefox: Round 2

Thursday, February 19th, 2009

We’ve been iterating hard on ideas to bring the power of Ubiquity to Firefox main. The two places it makes sense to surface Ubiquity-like power are (a) in situ with content when we are trying to manipulate, and (b) in the location bar, where we already type to perform navigation tasks. This post focuses on the second use case.

The three design goals, in shorten form, from round 1 were:

(1) Don’t force new work flows.
(2) It must be localizable.
(3) It should feel like Firefox.

We’ve added a new design goal, as a subset of not forcing new work flows: discoverability. The interfaces we design should be self-learnable. In this case, that doesn’t mean ever piece of functionality is immediately obvious, but that over time the system can teach you — step by step — how to use more and more of itself.

Note that all of these mockups are sketches. They don’t imply anything about the final visual style. From an interaction standpoint, they focus on tight feedback loops, as well as putting contextual autocomplete as close to the text being entered as possible.

Mockup 1

The Ubiquity-esque actions appear in the Awesome Bar results, and are subject to the same ranking algorithms as everything else.

The inset image on the right is an alternative way of accessing verbs: instead of having them appear in the awesome bar results, they appear as autocorrect-style text above what you’ve typed. The benefit is that you can always hit tab to quickly get to the action you want (as opposed to using the arrow keys for navigating the awesome bar results). It can also be unified with methods of structured modifiers (see later mockups). The detriment is that it is yet another mechanism and is visually noisy.

Other thoughts: The background of the url bar can change colors to add a visual key that an action is taking place. We can also unify the keyword mechanism, so that if you type “g ” it automatically gets expanded to a “Google” action.

Mockup 2

(more…)

Scaling Ubiquity to 60+ Languages: We Need Your Help

Tuesday, February 17th, 2009

The year is 1953. Robert Floyd, the man most cited in Donald Knuth’s The Art of Computer Programing, takes the stage. His topic is on using English as a programming language:

“Each word must be implemented by a procedure which somehow contains its meaning and consistently interlocks with other procedures for other words. I can’t think of any task, intellectual or not, which has ever been carried out which approaches this magnitude.”

Over half a century later, those words ring prophetically true. Instructing a computer to do what you want with natural language is astronomically hard. That’s why Ubiquity cheats left and right to do it. It embraces ambiguity, uses tight feedback loops, and a restricted vocabulary plus grammar to give the appearance of something human. And it can do a lot better.

As we think about Ubiquity uplift into Firefox, we aren’t just bound to English. We need to have an interface that can potentially work in the 60+ languages that Firefox has been localized too. For that we need your help.

I’m pleased to announce that Mitcho Erlewine, a linguist-coder, will be leading the charge in helping us understand how to bring conversational computing to the Firefox scale. His first blog post is on How natural should Ubiquity really be? Although he speaks four languages fluently (English, Japanese, French, Chinese) and is a gifted linguist, he can’t do it alone. Especially if your native tongue is not English we need you to get involved in blogging, thinking, and mocking up ideas for how Ubiquity in Firefox’s Awesome Bar can work in your language. Put your mockups on Flickr and tag them with ubiquity and mozconcept.

Question: What are the greatest difficulties in bringing Ubiquity to your language?

Exploring a Web Phone: Getting Physical

Wednesday, February 11th, 2009

As part of the Concept Series, we’ve been playing with what a phone that is optimized for the Web. That is the web.

We’ve been working with Billy May, just like we’ve been working dozens of other talented designers as part of the Concept Series, to envision what such a beast looks like from a physical perspective. He’s got some initial sketches of what an phone with a change-on-the-fly OLED keyboard would look like. It’s a throw-away first concept and I know that we’ll see additional concepts from Billy May and other Concept Series participants soon.

I’m not normally a fan of changeable/contextual keys — you end up with a buttons that change in the night, but if executed very carefully with strong guidelines they can provide a platform for physical innovation. They can provide the benefits of a touch screen with actual tactile feedback.

I’m also happy to say that Billy’s work on envisioning an open Web phone was picked up by NPR. Mozilla Lab’s is its community, and it’s exciting that main-stream press is starting to pick up on that by highlighted the virtual members of our team.

Here’s the interview from Future Tense:

[MP3]

One of the strengths of the iPhone as a platform for user experience innovation is the wealth of physical inputs: a microphone, a camera, an accelerometer, a GPS, and a touch screen. That gives the freedom to make our interfaces more human, by allowing us to interact in physical, personal ways.

Question: What are the physical aspects of a phone that you think are missing? What would your “Mozilla Phone” look like?

Solving the “It” Problem

Tuesday, February 10th, 2009

One of the neater features of Ubiquity is it’s ability to understand pronouns in a natural and contextual way. For example you can write the command

email That's brilliant! to him

and if you’ve got the name “Jono” selected, Ubiquity understand that “him” means Jono, and thus to look up his email address. Thus we get “email That’s brilliant! to jono@mozilla.com”. Although this makes for a great bit of magic, and is wonderfully useful, Ubiquity isn’t perfect in guessing what to interpolate. Say you’ve got “Lolz” selected and then use the command:

twitter I've seen links to this a lot

The question is do you mean to twitter “I’ve seen links to this a lot” or “I’ve seen links to Lolz a lot?”. Both make sense, and which one is better is unclear. The method that Jono DiCarlo pioneered was to embrace the ambiguity: we can make a smart guess about what the user means, but always give them the final choice in disambiguation.

The problem we’ve seen is that as we add more pronouns, the number of possibilities for interpolation goes up exponentially. For two pronouns, there are 4 disambiguation choices; for three pronouns, there are 8 disambiguation choices; etc. And for every extra command that matches, you double the number of disambiguation choices. It’s not a scalable solution.

Also bad is that often what Ubiquity thinks it should be interpolating is not your locus of attention, so as we use Ubiquity we often make mode errors. And we see this happening fairly often in the wild, where tweets have a random words from an errant selection where the word “it” should have been.

Bring the Fight To Them

There are a couple of potential solutions to the pronoun substation problem, but many of them don’t fly. For instance, we don’t want any special markup or computery quotation marks for indicating the to-be-interpolated pronouns. It should feel natural.

The solution I like best so far flattens the decision tree by having you choose as you type. It takes inspiration from cell-phone autocomplete/auto-correcter interfaces.

As you type a magic word, you can click or up-arrow to select the substitution. If you ignore it and keep typing, you get the plain text you typed. Think of it as on-the-fly text augmentation and structuring: we can greatly reduce the complexity of natural language processing by stealing a cycle from the user in a humane way. This scales nicely to other magic words. For instance, “url” can be replaced with the current pages url.

As focus in on Ubiquity uplift into Firefox, smart pronoun substitution may be largely important.

Question: What other solutions are there? We’re interested in radically different ideas to explore the solutions-space before we commit to one.

Intuitive Innovation Means Marketing

Monday, February 9th, 2009

Want to create a product that’s “intuitive”? Want it to be innovative in interaction — buck the trend for a significantly better user experience? You might have to do what Apple does and spend millions of dollars to make that happen.


Apple UI marketing

Weekly Ubiquity Focus: Email Command

Thursday, February 5th, 2009

It’s time to start improving the built-in Ubiquity commands! Since the launch of Ubiquity last August, huge improvements have been made. But most of these new changes haven’t improved the commands in any way. Aside from a few bug fixes, the “wikipedia” command, the “twitter” command and others are still the same as they were back in August.

We are starting a weekly focuses so that everyone can concentrate their efforts on a single piece of funcationality for a week or two to make it really sing. The first one is email.

For details of how to participate, head over to Abi’s blog, who is leading the charge.