You Can’t Multitask

Aza Raskin

August 31, 2009

9:49 am

I can only think about one thing at a time.

Any girl reading this just going to roll her eyes and think, “Of course. You’re a guy!”. But it’s not just true for me, it’s true for everyone. It’s true for you.

And not in that way.

At first, this claim can sound fantastic. We can talk on a cell phone while driving to work, and we can compose complex sentences while typing. But, if you stop to reflect on it, you can only do those things at the same time because at least one of them is automatic. In the first case driving is automatic, and in the second case typing is automatic. You’ve done them so often that you’ve habituated to them: doing them doesn’t require any thinking. Can you still talk on your cell phone while driving through a rainstorm on unfamiliar roads? Would you still be able to concentrate on writing if you had just switched to a Dvorak keyboard? I didn’t think so.

In both cases the extreme situation frustrates your habits and forces you to actively think about what you are doing at the expense of your other task. When you are thinking about driving safely in adverse conditions, you can’t also hold a conversation. And while you’re searching for the “e” key, you can’t also compose the next line of your sonnet.

Still not convinced? Then try this experiment: Think about the taste of chocolate (that glorious silky rush of sweet earthy flavor) at the exact same time as you add 47 and 56. Really try. At the same time. If it makes your brain fuzzy in the way your mouth feels after you’ve had an unripe banana, you’re in good company: it’s impossible. You can switch back and forth really quickly, but you can’t actually think about both things at the same time.

Want another experiment? Try saying “I cannot do two things at once very well” out-loud while reading the next paragraph. If you are like most people (i.e., not a practiced speed reader), you’ll end up reading the paragraph very slowly, one word at a time in between your spoken words.

Software often requires us to actively think about two things at once: like needing to know if the current content of the clipboard is important (when you should be thinking about the edit you want to make), or whether the “predictive” text entry on cell phones has incorrectly guessed the word you want (when you really just want to be writing your message). Unfortunately, this is like asking us to simultaneously press two buttons that are 10 feet apart. It’s impossible, and it’s not humane, so we’ll make mistakes. But, it’s not our fault.

Not being able to think about two things at once means that we can’t truly “multitask” things that we need to think about. Instead, we cycle through tasks in quick succession. But be warned, there are costs. At each switch we risk losing our train of thought and even if we remain on track, it takes time to re-situate ourselves with where we were before the switch. The net effect is that it takes more time to multitask a set of actions than it does to do them sequentially.

Time for another experiment. Time yourself doing the following two actions:

  1. Spell aloud, letter by letter, “Jewelry is shiny” at the same time as you write your full name.
  2. Spell aloud, letter by letter, “Jewelry is shiny” and then, after you are done with that, write your name.

It took me 18 seconds to do the tasks concurrently, and 8 seconds to the tasks sequentially. However, if you practice spelling “Jewelry is shiny” aloud for a couple minutes, it’ll become automatic. You’ll no longer have to think to do it, and you’ll be able to complete the two tasks at the same time without incurring the switching cost.

What’s the lesson to be learned? If you want a boost in productivity, try rethinking how you multitask so that you only ever need to think about one thing at a time.

Even if it is about that.


Bespin 0.4.2, a Short Roadmap, and a Test Swarm

Ben Galbraith

August 28, 2009

9:51 am

A couple of items to report this week from the Developer Tool’s group here in the labs: First, we released Bespin 0.4.2 code-named “H. E. Pennypacker” over at http://bespin.mozilla.com. H. E. Pennypacker is a bug-fix release focused on patching issues in our still-fairly-new collaboration engine. More details on the release are available on my blog.

Short-term Bespin Roadmap

We’re busily working away on firming up longer-term plans for Bespin, but for those of you curious about our shorter-term plans, we recently published a roadmap through the end of September. Please take a look and let us know what you think.

Test Swarm!

Test Swarm

On Wednesday, John Resig on our team pushed out an alpha release of his most recent labor of love, Test Swarm. The project allows developers all over the world to contribute their browser to a swarm that continuously tests code. This allows projects like jQuery to run tests on a large variety of browser / operating system combinations without having to setup test labs and servers, etc.–an effort beyond the reach of most open-source projects.

We’re all very excited about the potential of Test Swarm to increase the quality of JavaScript code in projects world-wide. Read more over at John’s blog.

- Ben Galbraith, on behalf of the Bespin and Test Swarm teams


Weave 0.6 Released

thunder

August 27, 2009

12:35 pm

Weave Sync is a prototype that encrypts and securely synchronizes the Firefox experience across multiple browsers, so that your desktop, laptop and mobile phone can all work together. It is part of the Weave project, which aims to integrate services more closely with the browser.

Major Features

What is Weave Sync all about? In short, Weave Sync lets you securely take your Firefox experience with you to all your Firefox browsers — including our mobile browser, codenamed Fennec. It currently supports continuous synchronization of your bookmarks, browsing history, saved passwords and tabs, as well as form-field history and preferences. For example:

  • Get the same results on the Smart Location Bar on each of your Firefox browsers, so you can get to your favorite sites with just a few keystrokes
  • Continue what you were doing: have the ability to open any tab you have open on any of your Firefox browsers
  • Keep the same list of bookmarks on all of your Firefox browsers
  • If you use Personas, your currently selected Persona can be synchronized across your Firefox browsers
  • Easily sign in to all your favorite sites using your saved passwords (this is especially handy on mobile phones, where it’s hard to type in complex passwords)
  • Do it all securely: Weave Sync encrypts user data before uploading it to Mozilla’s servers, so that only you can access your data

What’s new in 0.6?

If you have not looked at Weave recently, now is a great time to jump in and try it out! In this release we did a major overhaul of the user experience, as well as major improvements in terms of reliability and performance. A few of the major changes are:

  • Brand-new UI, allowing for most set-up, configuration, and status to be done from a single streamlined interface
  • Major performance improvements during upload and download
  • Better error handling and reporting

Getting Involved with Testing and Development

– Dan Mills, on behalf of the Weave development team


[ANNOUNCEMENT] Apache Wink 0.1 Released (JAX-RS Implementation)

Davanum Srinivas

2:55 am

The Apache Wink team is proud to announce the availability of Apache Wink 0.1
Apache Wink is a framework for building RESTful Web services.
It is comprised of a Server module and a Client module for developing
and consuming RESTful Web services.
Disclaimer: Apache Wink is an effort undergoing incubation at The
Apache Software Foundation (ASF), sponsored by the [...]


Developerworks space for Websphere webservices team

Davanum Srinivas

August 25, 2009

5:35 am

We just got this going…with links to redbooks, technotes, articles etc here:
http://www.ibm.com/developerworks/spaces/ws


Making Long Scrolls on the iPhone Not Suck

Aza Raskin

August 24, 2009

2:58 pm

The designers of the iPhone had an immense amount of courage. They finally removed the scrollbar, a persistent and harmful UI anachronism. Given the amount of time spent scrolling on computers, requiring the move from your locus of attention to the small target that scrollbars represents has wasted immense amounts of time. If you calculate it out conservatively, the scrollbar widget wastes almost one complete day a year. And that’s only if you scroll once every 6 minutes. Multiply that by number of the 300 million Firefox users and you’d find that the scrollbar wastes over three-fourths of a million man-years of web browser’s time. Every year.

No wonder we have scroll wheels and two-finger scrolling. They remove the 4 seconds of back-and-forth targeting the scrollbar. They save the world millions of man-years of wasted time.

Fennec (Firefox Mobile) and the iPhone go the next step and get rid of the scrollbar all together. There just isn’t enough room on those little screens. They both use pan-to-scroll, which solves the problem with the exception that getting around on pages so over-flowing with length that they stretch for half an infinity (like the Line of succession to the British throne) takes half of forever. The problem is so horrific that mobile Safari had to implement a band-aid UI patch for jumping back to the top of a page.

There has to be a better way of solving the problem, one where you get the immediacy of touch-and-drag to pan but where you also don’t get stuck scrolling the scenic route.

Here are two thoughts on how to solve the problem.

Sticky Scroll Indicator

The obvious solution. When you start to scroll, the scroll indicator fades in. After you stop scrolling, the scroll indicator remains and can be interacted with for some amount of time. Time based solutions are always a tricky — the timeout is never the right length for everyone — but this one seems pretty pit-fall free. The scrollbar is there when you need it and gone when you don’t.

Scroll-to-zoom

The more visually impressive solution, although I’m not convinced it is better than the obvious solution. During long scrolls, the page automatically zooms out. Optionally, the longer the scroll, the further the zoom. The zoomed out page can be panned, and the now-present scrollbar can be used for quickly jumping around. A single tap zooms you back in. This gives you a wonderful visual table-of-contents map of the page you are moving about, but at the potential cost of simplicity.

Other solutions

Are there other solutions?


Mozilla Labs Meetup – Thursday, August 27th

Ragavan Srinivasan

11:11 am

After a brief hiatus, we are back again for another edition of Labs Night, our monthly meetup to discuss Labs projects, your projects and the Open Web. Our August session will be this Thursday, 8/27 6-9 pm at the (still) new Mozilla HQ – 650 Castro Street, Suite 300 in downtown Mountain View. The event is open to everyone, so if you are in the area feel free to stop by.

Our featured speaker this week is Li Gong, Chairman and CEO of Mozilla Online, the Beijing based subsidiary of the Mozilla Corporation. Li will be talking about a wide variety of topics related to firefox, the mozilla community and the open web in China.

We will also hear what a lot of the Mozilla Labs projects have been working on, in 5 minute lightning talk style presentations. We’ll have a few slots open for other lightning talks as well, so if you are working on a cool project, this is a great opportunity to show and tell.

And if that’s not enough, we’ll also be providing pizza.  Please RSVP by commenting on this blog if you plan to attend. Hope to see you there!

PS: We may have another super exciting speaker this week. We will post an update once we hear confirmation.


Exploring Command Chaining in Ubiquity: Part 2

mitcho

August 23, 2009

3:14 pm

Introduction

I recently have begun giving serious thought to what command chaining might look like in Ubiquity and the various considerations which must be made to make it happen. The “command chaining,” or “piping,” described here always involves (at least) two verbs acting sequentially on a passed target—that is, the first command performs some action or lookup and the second command acts on the first command’s output.

A few days ago I penned some initial technical considerations regarding command chaining. In this post I’ll be point out some linguistic considerations involved in supporting a natural syntax for chaining.

Simple syntaxes: sequential vs embedding strategies

When it comes to creating a natural language interface, there’s always a decision to make between requiring a certain kind of input, or working a little harder to understand the user’s natural input. From an implementation point of view, adopting certain programmatic conventions is of course simpler and to this end, there have been a couple different “unnatural” command chaining syntaxes suggested. While these both go against Ubiquity’s basic tenet of natural syntax — that is, to not introduce rules which contradict the user’s natural language — which gives Ubiquity its strengths of usability and memorability, I’ll entertain them here as they illustrate two different structural relationships that we will want to consider.

not-pipe.gif

The first suggestion is to adopt the shell pipe (|), which would lead to input such as

1
translate hello to Spanish | email to Jono

While this itself is pretty unnatural unless you speak shell, note that this syntax is similar to the more natural “, and” syntax, yielding translate hello to Spanish, and email to Jono, which we will consider below. I’ll refer to this strategy as the sequential strategy.

Another very interesting proposal by Alex Fritze is to embed each subordinate computation into an argument position, marked by parentheses. This could also be parsed relatively straightforwardly by writing a noun type which first checks for parentheses and then runs the content of the argument through another ParseQuery.

2
email (translate hello to Spanish) to Jono

I’ll refer to this pattern as the embedding strategy.

Sequential and embedding strategies in natural language

What’s interesting about the two proposals above is that both strategies are seen in natural language. The sequential strategy could correspond to the following linguistic phenomena:

  1. coordination: a non-hierarchical joining of two or more clauses, often marked by a conjunction. Here’s an example from English:
    • “[I made a sandwich] and [you will eat it]” where [] represent clause boundaries. Here, “and” is the conjunction.
  2. serial verb and converb constructions: a joining of multiple verbs or verb phrases within a single clause, with shared subject and tense/aspect values, with no particular conjugation or delimiter between them. Such constructions are common in many African and east Asian languages. Here are two examples:1
  • A converbal construction in Japanese:

    3
    4
    5
    
    僕は     サンドイッチを 作って     食べる
    boku-wa sandiʔchi-o  tsuku-ʔte tabe-ru
    I-TOP   sandwich-ACC make-CON  eat


    “I (will) make a sandwich and eat [it].” (Here, `TOP` = topic, `ACC` = accusative, `CON` = converbal ending)[^3]

  • A serial verb construction in Mandarin Chinese:
    6
    7
    8
    
    我 作   三明治      吃
    wǒ zùo  sānmíngzhì chī
    I  make sandwich   eat


    “I (will) make a sandwich and eat [it]” or “I (will) make a sandwich [in order to] eat [it].”


Note that in both the converb and serial verb construction, the second verb (eat) takes shares its object (sandwich) with the first verb and there is no need for a pronoun such as “it” to introduce that argument as it is with coordination, above.2

The embedding strategy is observed in natural language as well, in the form of the following phenomena:

  1. embedded clauses: a sentence is itself the argument of another verb. Example:
  • “John says [he likes sandwiches].”


Embedded clauses, however, clearly have no relation to command chaining and does not require our attention.
2. relative clauses: a partial sentence3 is attached to a noun in order to describe it or distinguish it from other possible referents. Example:

  • “You ate the sandwich that I made” where “sandwich” is called the “head” of the relative clause, and “I made” is what I here call the “partial sentence” (see footnote). The “relative clause” is used here to distinguish “the sandwich that I made” from other sandwiches.

The natural syntax of chaining

So which strategy is used in complex natural language commands: the sequential strategy or the embedding strategy? Both the sequential strategy and embedding strategy can be involved with commands:

9
10
[Make a sandwich] and [eat it]!
Eat (the sandwich that I made)!

These two commands do not mean the same thing, though, and only (9) is the kind of command we would want to give Ubiquity. The problem with relative clauses, as in (10), is that it presupposes the existence of the sandwich in the context. If we both know you just made a sandwich, saying (10) is perfectly appropriate, but out of the blue it doesn’t make sense. For this reason, only the sequential strategy is used in the natural syntax of chaining.

Parsing the sequential strategy

In natural language, unlike the initial simple proposals laid out above, there is often no clear delimiter marking the boundary between the two parts in a sequential relation (e.g. examples (3) and (6) above, particularly given that neither Japanese and Chinese normally break words with spaces). How would we parse a sequential string of commands?

Let’s assume for our purposes here that we can identify find all verbs within the input string.4 Parsing a sequential strategy string is not particularly difficult if we can also assume that the verb in any particular language is either always verb-initial or always verb-final. Let’s look at both cases:

  • Always verb-initial: Mandarin Chinese:
11
12
13
翻譯       hello 到  西班牙語   送    給  Juanito
fānyì     hello dào xībānyáyǔ sòng gěi Juanito
translate hello to  Spanish   send to  Juanito



“Translate hello to Spanish [and] send [it] to Juanito”
1. find every possible verb:
翻譯hello到西班牙語給Juanito
2. as every verb marks the beginning of a sentence, we now have our two commands: “翻譯hello到西班牙語” (translate hello to Spanish) and “給Juanito” (send to Juanito).
* Always verb-final: Japanese

14
15
16
helloを スペイン語に 訳して Juanitoに 送って
hello-o supeingo-ni yakus-ite Juanito-ni oku-ʔte
hello-ACC Spanish-DAT translate-CON Juanito-DAT send-CON



“Translate hello to Spanish [and] send [it] to Juanito”
1. find every possible verb:
helloをスペイン語に訳してJuanitoに送って
2. as every verb marks the end of a sentence, we now have our two commands: “helloをスペイン語に訳して” (translate hello to Spanish) and “Juanitoに送って” (send to Juanito).

For languages where there is a clear conjunction between the two commands, such as English “and”, we can also use that conjunction as a delimiter as well. We then simply execute the first command and then execute the second with the first command’s output in its interpolation context. This way the output of the first command will be picked up both by an overt pronoun such as “it” in the second command and without it, such as in the Chinese and Japanese examples above.5

The only potential problem with this approach is in the case of languages where some commands are verb-initial while others are verb-final. I note that such languages do exist in a previous blog post, Where’s The Verb. In these languages, commands can be expressed by more than one verb form (such as infinitive, imperative, subjunctive, etc.) and some of those verb forms are sentence-initial while others are sentence-final. Here’s one such example from German:

“search hello with google” (German)
1. Infinitive: hello mit google suchen
2. Imperative: suche hello mit google

Here the verb for “search” is “suchen” (infinitive) or “suche” (imperative). I know that this same type of phenomena occurs in other Germanic languages such as Dutch with infinitive and imperative and also other languages such as Modern Greek with infinitive and subjunctive forms. If you are a speaker of one of these lanuages (German, Dutch, Greek, etc.) I would love to know whether you can chain verb-final and verb-initial commands together.

Conclusion

In this blog post I examined command chaining in natural language, focusing on data from English, Mandarin Chinese, and Japanese, which exhibit three linguistically different approaches to chaining. What we found is that the sequential strategy—that of listing the commands one by one, in order of execution—is what is used in natural languages, rather than any sort of embedding. This fact, combined with the fact that our parser can recognize every available verb, offers a simple approach to doing a naive parse of natural command chains in most languages, even without explicit delimiters.

In a final installation of this series on “exploring command chaining,” I hope to consider how the Ubiquity interface itself could present command chains and aid in its input.


  1. The distinction between serial verb and converb constructions (as well as other forms of complex predication) hinge on structural distinctions which are not of importance for our purposes. 

  2. Some people (Baker 1989 and others), in fact, list this object sharing as a necessary part of the notion of a “serial verb construction.” 

  3. “Partial sentence” is used in a descriptive sense here to reflect that the relative clause, such as “I made” in the example given cannot stand as its own sentence, as the verb’s argument is clearly missing. This type of pattern is also seen in questions (“What did [you make]?”) and topicalization (“That sandwich, [I made].”) and is a great focus of theoretical linguistics research. See wh-movement on wikipedia for more examples and information on theoretical approaches to such constructions. 

  4. We don’t do this right now as there hasn’t been a use for it—right now Parser 2 simply looks for known verbs at the beginning and end of the input. The parser does build a nice regular expression to find known verbs, however, so finding verbs input-medially would also be easy to do, though. 

  5. Note that even though the linguistic relation between the two commands is non-hierarchical, we interpret the sentences to mean “translate hello to Spanish and then email it to Juanito”, rather than “translate hello to Spanish and email it (hello) to Juanito at the same time.” This observed universal property that, ceteris paribus, the linear speech order of verbs reflects the conceptual order of events is known as the Temporal Iconicity Condition (Li 1993 and others). 

Related Posts

  1. Exploring Command Chaining in Ubiquity: Part 1
  2. Command Chaining with Oni?
  3. Ubiquity in Italian

Related posts brought to you by Yet Another Related Posts Plugin.


Put it all out there

Ubiquity Feed

August 22, 2009

5:19 pm

Getting the user to do something is like asking for a phone number: it has to be done at the right time and after they are excited about it.

After I updated Ubiq I started getting these reminders notifications:

Ubiquity Command Notification Screenshot

This is a common UI design pattern, one that is well intentioned but awkward. About as well intentioned and awkward as the first time I asked a girl out- via “secret admirer” in fifth grade. Just asking someone on a date is the quickest way to a fake phone number. The girl only knows your interested, not if your worth it. Hell, she may even know your worth it, but is to distracted with other things.

Just throw it all out there, show the user what is valuable about the command and they will follow along:

Search faster: google search keywords

Secondly stick to seducible moments. Try a reminder in to Google search-bar autosuggest, or some extra highlighting of unused commands within ubiquity when opened on related sites. This is something I touched on earlier in error pages.


Announcing the Jetpack Contest and a Pre Release

Aza Raskin

August 20, 2009

2:19 pm

Jetpack is an experiment in using open Web technologies to enhance the browser, with the goal of allowing anyone who can build a Web site to participate in making the Web a better place to work, communicate and play.

We are currently hard at work on Jetpack 0.5 which will have a number of great new features, from the ability to handle streaming audio, to being able to play the music already on your computer, to a much improved Twitter library. This is in addition to a whole slew of bug fixes. You can see exactly what’s changed here.

If you’re impatient, you can download the beta of Jetpack 0.5.

The Contest

In preparation for the release we are launching a Jetpack contest. For making the coolest or most interesting Jetpack, we are offering a brand new netbook (the ASUS Eee PC 1000HE). For the runner-up, we’ll send you a big package of Mozilla swag. Special kudos for Jetpacks that use the latest features in Jetpack 0.5.

Get Involved

Mozilla Labs is a virtual lab where people come together online to create, experiment and play with Web innovations for the public benefit. The Jetpack experiment is still in its infancy and just getting started. There are many ways to join the team and get involved:

We’re also looking for a full-time product manager and software engineers to join Labs and work on Jetpack! What title is better than Jetpack PM? Check out the career opportunities available.

— Aza Raskin, on behalf of the Jetpack team


Older Posts »