A More Readable (Pythonic) Javascript Syntax?

While I’ve come to love Javascript, I miss the syntactic beauty of Python. The stark modern minimalism of the language causes the meaning of code to float on the syntax like a feather on water. There are no extra braces, brackets, or parenthesis to saturate your visual bandwidth. In comparison, Javascript’s syntax is like the cluttered boudoir of a Victorian house: elaborate, ornate, and unnecessary. You can be left with half a dozen trailing braces and parenthesis, with no clear owner; their balance in an unstable equilibrium.

Note that I am not arguing that Javascript isn’t a beautiful or powerful language, just that its syntax is a vestigial meme left over from a time when we didn’t know better.

I’ve often wanted to bring Javascript and modern minimalism together: to strip the language of parens, braces, and semicolons. So that’s what I’ve done. I wrote a little parser for a slight modification of Javascript. I call it Pyscript. (more…)

Is A Creative Commons for Privacy Possible?

There was a lot of great feedback for my post Making Privacy Policies Not Suck. We are now in conversation with a whole slew of industry leaders and deep thinkers in the area of privacy (Lorrie Cranor, Jonathan Zittrain, Lauren Gelman, Ryan Calo to name a few).

With all of the work that’s been done before us, I wanted to touch on some of the way our thinking and position breaks from the mold.

Bolt On Approach

Privacy policies and Terms of Services are complex documents that encapsulate a lot of situation-specific detail. The Creative Commons approach is to reduce the complexity of sharing to a small number of licenses from which you choose. That simply doesn’t work here: there are too many edge-cases and specifics that each company has to put into their privacy policy. There can be no catch-all boiler-plate. We seem to have lost before we begun. There’s another approach.

Here’s where we stand: Companies need to write their own privacy policies/terms of service, replete with company-specific detail. Why? Because a small number of licenses can’t capture the required complexity. The problem is that for everyday people, reading and understanding those necessarily custom privacy policies is time consuming and nigh impossible.

Here’s the solution: Create a set of easily-understood Privacy Icons that “bolt on to” a privacy policy. When you add a Privacy Icon to your privacy policy it says the equivalent of “No matter what the rest of this privacy policy says, the following is true and preempts anything else in this document…”. The Privacy Icon makes an iron-clad guarantee about some portion of how a company treats your data. For example, if a privacy policy includes the icon for “None of your data is sold or shared with 3rd parties”, then no matter what the privacy policy says in the small print, it gets preempted by the icon and the company is legally bound to never sharing or selling your data. Of course, the set of icons still needs to be decided (we’ll be having a workshop on the 27th of January to help figure it out).

This method means that without ever having to delve into the details, everyday people can glance at the simple icons atop a privacy to know if and how their data is being used. At the same time, it gives companies the flexibility required to create comprehensive and meaningful policies. We’ve found a way past the deadlock.

Nobody Will Use the Bad Icons?

Some of the Privacy Icons will have potentially a bad normative value, like the icon that indicates your data may be sold to third parties. The icon might even look scary. The question becomes, why would any company display such an icon in their privacy policy? Wouldn’t they instead opt to not use the Privacy Icons at all? This is the largest problem facing the Privacy Icons idea. Aren’t we are creating an incentive system whereby good companies/services will display Privacy Icons and bad companies/services will not?

If Privacy Icons become widely adopted (and I think Mozilla is in a unique position to help make that happen) then the correlation of good companies using the icons and bad companies not using the icons becomes rather strong. If a privacy policy doesn’t include any icons it’s synonymous with that policy making no guarantees for not using your data for evil. The absence of Privacy Icons becomes stigmatic.

Asking people to notice the absence of something is asking the implausible. People don’t generally don’t notice an absence; just a presence. The solution hinges on Privacy Icons being machine readable and Firefox being used by 350 million people world-wide. If Firefox encounters a privacy policy that doesn’t have Privacy Icons, we’ll automatically display the icons with the poorest guarantees: you’re data may be sold to 3rd parties, your data may be stored indefinitely, and your data may be turned over to law enforcement without a warrant, etc. This way, companies are incentivized to use Privacy Icons and thereby be bound to protecting your privacy appropriately. With Firefox growing past 25% market share, we are in a position to affect critical-mass adoption.

There are other options as well; like crowdsourcing tentative Privacy Icons for a website whose privacy policy does have icons yet (and deferring to the company’s as soon as they put them up).

(Note that Mozilla has not yet decided to integrate this into product yet.)

Lawyer Selected, Reader Approved

Since it’s release, Creative Commons has continually pared down the number of licenses it provides and is now down to just two icons, one with two states and one with three. It has to be so simple because everyday people choose their own license. Privacy Icons don’t have that constraint. A qualified lawyer chooses what icons to bind to their privacy policy, and so there can be substantially more icons to choose from allowing the creation of a rich privacy story. As long as the icons are understandable by an everyday person, we are golden.

Next Steps

This blog post lays out the groundwork for how we are thinking about crafting Privacy Icons. We still need to figure out what the icons and their states will actually be (as well as if this approach makes sense). Ahead of the Federal Trade Commision Privacy Roundtable, we will be hosting a workshop to discuss and creating solutions (or at least next steps) toward a more meaningful privacy framework over the web. We hope you can join us. Please rsvp to liz@mozilla.com no later than January 18th.

The Details:

What: A Privacy Forum Co-Hosted by Lauren Gelman and Mozilla
Who: You and Any Others at Your Organization Interested in Privacy Issues
When: January 27th from 10am - 3pm
Where: Mozilla (http://www.mozilla.com/en-US/about/contact.html)

Identity in the Browser (Firefox)

Identity will be one of the defining themes in the next five years of the Web. Nearly every site has a concept of a user account, registration, and identity. Searching for “sign in” on Google yields over 1.8 billion hits. And yet, the browser does nothing to make this experience better save for some basic auto form filling. The browser leaves websites to re-implement identity management, and forces users to learn a new scheme for every site.

Most current solutions involve lots of redirects or iframes, which leads to a confusing and phishable experience.

Besides the poor user experience, we are seeing market-moving effects of the identity/log in problem. Facebook Connect and Google’s Friend Connect both let you use your pre-existing identity and social graph to super-power other websites. The problem?

Your identity is too important to be owned by any one company.
Your friends are too important to be owned by any one company.

A Solution

The browser is your personal and trusted agent to the web. It’s the only actor on the Internet stage which both knows everything you do on the web, and never has to let that data leave the privacy of your desktop. Your browser knows you (or, at least, should).

At Mozilla Labs, we’ve been working on some potential integrations of identity directly into the browser. Note, this is an extremely rough draft.

Some key points:

• * Identity is part of where you are, and what you are looking at (Amazon looks different depending on if you are signed in or not). That’s why we put it in the URL Bar.
• * For most sites, you’ll probably only have one identity, so login will be a single click or automatic.
• * Putting verbs into the navigation bar isn’t new. See Taskfox.
• * To increase visibility, webpages should be able to make a Javascript call that opens the login/signup bubble.
• * For webpages that want to own the login-process, the account creation simply acts as the ultimate form-fill.

For those interested in the evolution of the idea, you can see an early mockup with comments as well as Alex Faaborg’s similiar mockups.

Next steps

Chris Messina and others has been advocating for a model which follows the Facebook Connect lead: a single verb, to connect. Once connected, you decide exactly what information to share in an asynchronous manner. Unfortunately this bleeds information — your name is known to all websites which which you connect. We’d like to explore what a connect metaphor in combination with the ability to remain anonymous but connected means.

Get involved here.

What are your thoughts? How would you expose identity in the browser?

Firefox Image Editor: 14 Lines of Code

Jetpack makes it super-fast for any web developer to make Firefox extensions. 14 lines of code is all it takes to write an extensions that let’s you edit any image you find on the web.

Try it out!

Drew Willcoxon has some great examples of Jetpack, context menus, and Twitter working together. To find out more about creating menus in Jetpack, you can read the pretty pretty documentation.

Here’s a quick challenge: What can you make using Jetpack in 14 lines of code?

Making Privacy Policies not Suck

Privacy policies are long legalese documents that obfuscate meaning. Nobody reads them because they are indecipherable and obtuse. Yet, these are the documents that tell you what’s going on with your data — how, when, and by whom your information will used. To put it another way, the privacy policy lets you know if some company can make money from information (like selling you email to a spammer).

Creative Commons did an amazing thing for copyright law. It made it understandable.

Creative commons reduced the complexity of letting others use your work with a set of combinable, modular icons.

In order for privacy policies to have meaning for actual people, we need to follow in Creative Commons footsteps. We need to reduce the complexity of privacy policies to an indicator scannable in seconds. At the same time, we need a visual language for delving deeper into how our data is used—a set of icons may not be enough to paint the rich picture of where you data is going.

Understanding Data Flows

With the rise of web services, your information can end up in unexpected places. To get a better understanding of some of the complexities of data flow, we sketch out how Anti-phishing works in Firefox (with help from Oliver Reichenstein).

Here’s what that looks like as a wall of text, which is the typical privacy policy mode.

The difference in understandability is huge between the text and the schematic. In fact, while we were working on creating this infographic we found a hole in our legalese and updated it accordingly.

The idea here is that by creating a visual schematic language, it is relatively painless way for a company to convert their wall-of-text into something a bit more approachable. And that the more visualization actually shines a light into the dense tangle of words, possibly highlighting flaws or trouble spots that would have otherwise remained hidden.

The simple form

The visual schematic language is a descriptive way of explaining a privacy policy and helps us to understand what’s going on underneath the hood. It doesn’t solve the problem of being able to quickly figure out the guarantees a privacy policy is making on your data.

For that, we want to move from the descriptive to the proscriptive, to a set of legally-bindings icons like Creative Commons.

As an experiment, we tried a schematic form of icons:

The feedback that we’ve got so far is that the schematic is over-kill and that a set of icons more similar to Creative Commons’s would be easier to scan and understand. The next step is for us to come up with a set of orthogonal decisions about what compromises the most important aspects of a privacy policy. In the end, we probably shouldn’t have more than 5 icons in the interest of simplicity.

You can help us brainstorm them.

For now here are a set of axis we’ve come up with that need to be whittled down:

Is your information…

Shared with a 3rd Party? Shared internally within the company?
Anonymized/Aggregated before being stored or used?
Personally Identifiable?
Stored for more than x number of days?
Encrypted on the server?
Monetized (sold) in some way?
Usable to contact you?

You-Centric: A Sketch of The Future of Browsers

We’ve been thinking at Mozilla Labs about what it means for the web to be more personal, more social, and more about you. It breaks down into four area:

• Identity
• Social
• Deep Integration
• Task-Centric

What does that mean? The video of my keynote from FOWA London below presents a sketch of what this might look like, and what it means for the future of browsing. This is all still in embryonic form, so now is the time for feedback to provide the greatest change. So let’s here it! Are the API’s and directions proposed here useful or compelling?

You Can’t Multitask

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.

Making Long Scrolls on the iPhone Not Suck

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?

The Over-the-Phone Test

One of the design heuristics we use at Mozilla Labs, especially as we work to create a more invisible browser, is the “Over-the-Phone test”.

If your friends have ever got it into their heads that you might be good at technology, I’m sure you’ve found yourself trying to explain some aspect of computing over the phone. Probably something trivial and difficult to explain. I give you my condolences. Trying to troubleshoot a GUI over the phone is like giving driving directions to train conductor.

For instance, it’s difficult to tell Grandma how to spellcheck in a web mail application that doesn’t have spellcheck:

• “Ok, Grandma, select everything by clicking anywhere in the text and typing Control-A.”
• “Now copy the text by typing Control-C.”
• “Open Word by going to the Start Menu, clicking ‘All Programs’, clicking ‘Microsoft Office’, and finally by clicking ‘Word’.”
• “Paste your text into Word by typing Control-V… No, Grandma, I don’t know why it’s ‘V’–maybe because ‘P’ is already used for printing?”
• “Click the little icon on the top of the bar that has a checkmark and some letters. You don’t see it? Okay, describe what you see. You see something that looks like a coffee cup? I have no idea what that is. Actually, forget it. Just select ‘Spell Check’ from the ‘Edit’ menu.”
• “Click ‘Start Checking’. Grandma, I know you just told it you want to spell check; I don’t know why you have to tell it again.”
• (Time passes as Grandma spell checks her document.)
• “Click the ‘Done’ button. Or maybe it’s called ‘Finish’. Uh, just click either the ‘Done’ or the ‘Finish’ button.”
• “Select everything by typing Control-A.”
• “Copy the text by typing Control-C.”
• “Switch back to the email you were writing. What’s that? You can’t see the email you were writing? Well, um… Move some windows around and try finding it.”
• “Is the text of the email still selected? No? Okay, click anywhere in the text.”
• “Select everything by typing Control-A.”
• “Paste in your spell checked text by typing Control-P. Wait, no, Control-V…”
• “You’re done! wasn’t that easy?”

At every step something can go wrong, your mental model can get out of sync with the state of the computer, or you might remember a button name incorrectly.

Thus our test: We ask ourselves, “Would I be willing to teach my Grandma how to use this over the phone?”. If the answer is “Definitely”, we know we’re doing well; if the answer is “Maybe”, we know we can do better; and if the answer is “No”, then it’s often time to rethink the whole thing.

This is one of the heuristics that informed Ubiquity.

How to Make the Road Speak. With Design.

Run your finger across the top of your keyboard, starting at the “q” and finishing at the “\”. Run your finger the other way. Listen to the sound it makes. Run your finger over the tops of the keys faster and the pitch goes up. Run your finger more slowly and the pitch goes down.

You are witnessing an amazing process of synthesis in your brain. There is no pitch out in the real world, just a series of short and sequential air-molecule vibrations. Your brain takes these little clicks and, depending on how fast their coming in, translates them into a melodious sound. Your brain wants to hear pitch.

It’s a coping mechanism. There’s too much sound out there in the wold, so you brain translates it from lots of little discontinuous noises, into a few recognizable pitches. The same thing happens when you put a playing card in the spokes of a bicycle. As the wheel turns, those little slapping noises blur together into a continuos sound, the pitch going up and down with the speed of the rider. (more…)

The conondrum of releasing Ubiquity 0.5

Ubiquity 0.5 has a number of awesome features, all made possible by a large group of dedicated people like Mitcho, Cers, Satyr, Brandon, Jono, just to name a few. We’ve revamped the natural language parser to be much more robust: gone are the days of ugly hyphenated commands, as well as awkward commands like “add-to-calendar 3pm lunch with Mitcho”. Instead, you can say “add 3pm lunch with Mitcho to calendar”. We’ve also added the ability to use Ubiquity in many languages other than English. Like Japanese, Catalan, Portuguese, and Danish. We’re excited to see more soon.

And all these changes break compatibility with 3rd party Ubiquity 0.1.x commands. By pushing an upgrade to Ubiquity 0.5, we’ll break a lot of currently working functionality: people will just wake up and things that worked yesterday won’t work today.

We’re left in an interesting position.

Ubiquity is a Mozilla labs project that has around 400 thousand active users. As as leading-edge experiment we need to be agile and iterate quickly, and yet we don’t have the right to break the daily habits and work flow of so many people.

It’s a conundrum. This video describes our solution.

How We’re Releasing Ubiquity 0.5.

Syllabuzz: Tactile Design Made Real

Last week, I wrote about an idea that let you know who was calling without having to look at your phone. It centered around having the phone “speak” the callers name through vibrations. The idea provoked a lot of interesting discussion: everything from how it might work in monosyllabic languages to guiding visually impaired people through urban environments.

As any silicon valley investor can tell you, ideas are cheap. Anyone can have an idea. It’s actualization which is valuable: that takes time, initiative, and know-how. Fellow Mozillian Dietrich Ayala has all of those.

Over the fourth of July weekend, when he should have been basking in the glow of falling phosphorescing chemicals, he spent some time turning the speak-through-vibration idea into a tangible thing.

Syllabuzz is an implementation of the tactile design that works on Android phones by Dietrich. You can get the source code on Github, or you can get it from the Android Market if you have an Android-based phone.

A huge thanks to Dietrich for making it all happen.

Know Who’s Calling: Tactile Design

I keep my phone in my pocket. This has the (un)fortunate side effect of putting the entire internet in my pants. When I get a call, I have to do a little dance to slip the phone out of my pocket and in to my hand.

I’m one of those people who thinks its rude to answer the phone in the middle of a conversation. It’s worse when it’s during dinner. It’s even border-line rude to just check the phone to see whose calling before slipping it away. I want to know whose calling before I go pocket diving.

Having my phone read out the caller’s name isn’t a tenable solution: I’d don’t want to broadcast that information to everyone near me. Imagine the embarrassment of being on a date and having your ex’s name announced by your phone to the room at large. Or worse, “Mom” being blared in the middle of your slam poetry reading. We’re going to need a more local solution.

I generally keep my phone on vibrate; it’s less intrusive that way. Given a name, it’s not difficult to deduce its basic constituent phonemes (every text-to-speech program does it). Here’s the thought, have the vibrator buzz out the phonemes of the caller’s name. The name Alexis, would be “br br brrr” and Jenny would be “Brr brr”, and Dan would be “bRrr. Imagine it as the sound of trying to say someone’s name without opening your mouth, complete with pitch and loudness modulation (which can be controlled with vibration speed and strength).

Playing around with a toy implementation, the mapping seems to be fairly natural. Learning the feel for a name is close to instant.

I know what your thinking, though: With my hundreds of contacts, how can I possibly differentiate them all from the buzz patterns?

The answer is that you don’t need to.

Most of us get calls regularly from less than 10 people. On Facebook, where the cost of communication is significantly lower than placing a call, an average man has two-way communication regularly with only 4 people. For women, that number is 6. (Data from Primates on Facebook). Learning to differentiate even 10 buzz patterns that feel like the way a name sounds is easy. That covers 90% of your use cases. And keeping you from needing to take your phone out of your pocket 9 out of 10 times is a big win.

Just a thought. It doesn’t bother you when it doesn’t work, doesn’t require you to go through a setup process to choose a ring/vibrate for each person, and is quick to learn. Plus, it gives the phone a bit of emotional impact (think Pixar).

Any other solutions?

Update: Dietrich Ayala has created a working version of this idea for Andriod phones.

We Nod While Talking on the Phone. Design For It.

Admit it. Even though you know the other person can’t see you, you still nod in agreement while talking on the phone. You gesture. You gesticulate. You communicate in a medium destined never to be communicated. That extra set of meanings dies a local, meaningless death.

We gesture because it’s part of our lexicon. It’s involuntary. And those gestures matter; they really do convey information. Using them wisely in the classroom, for instance, increases the rate of learning and learned material retention. On the phone, though, we do without and use carbon-heavy transit to bridge the physical gap.

Yet with technology, perhaps we can return this funny quirk-of-behavior to it’s rightful place as a communicator.

As I sat recently, nodding along to a friend’s story, I realized that my iPhone knew fully well what I was doing. It just sat in beautiful-but-ineffectual silence. Given the accelerometer and proper programming, it could be conveying my nod tactiley across the ether: If I nod, the other phone vibrates a pattern conveying the vigorousness of the nod and on screen, it shows an animated representation of me nodding; If I shake my head, a different set of vibrations goes over the line, and my representation shakes it’s head sadly (or curtly, or slowly in disbelief, or…).

Ideally, there would be a natural mapping between my head’s actions and the feeling on the receiving phone—a nod should feel like a nod, a shake should feel like a shake. I’m not sure if that’s possible with the current iPhone, but given three shake-and-shimmy locations creating a facsimile becomes feasible.

Even if we can’t create a natural mapping, the brain’s plasticity comes to the rescue. When you use a tool, you’re brain actually represents that tool as an extension of your body. Similarly, when you’re brain gets consistent input from a real-world sensor, it quickly learns to map that into a sort-of six sense. As long as there was a different feeling for the different types of nods and head shakes, and a way to learn which means what (say by looking at the screen), your brain would soon process the vibrations into their gestural meaning subconsciously.

You’d just know that the other person was nodding agreement.

A nod-aware phone would make my daily communications that much more humane, and technology that much more human.

Of course, I’d still feel silly gesturing with my hands.

Jetpack FAQ

In the less-than-week since launch, we’ve seen more than 25,000 downloads of Jetpack and nearly 100,000 watches of the tutorial movie. There seems to be a particularly interested in Jetpack from the Web developer world. In the few days since launch, we’ve had over 20 Jetpacks written by people who previously had only written web sites.

This release of Jetpack is a 0.1 prototype, meant mainly for developers and testers. That there has been this much response speaks to a deep-set and unmet need to allow creators on the web to be able to participate in making the browser better for everyone, regardless of their depth of technical ability.

These are questions and answers from an interview. (more…)