ContextFree.js & Algorithm Ink: Making Art with Javascript

In honor of the the release of Firefox 3, I’m releasing ContextFree.js today, along with the demo site Algorithm Ink. ContextFree.js is about drawing striking images—and making art—with minimal amounts of code.


An introduction to ContextFree.js & Algorithm Ink

Computers programs lost something important when displaying a splash of color stopped being one line of code. As a kid, I remember being able to type “plot x,y” on the Apple II to throw up a phosphorescent splotch. When the simplicity of the one-line plotter went away, so did the delight at being so effortlessly generative—in a visual way—on the computer. ContextFree.js is a stab at making it easy again. It’s like a grown up version of Logo (or at least the Turtle Graphics part of Logo).

Go ahead and play with it on Algorithm Ink. It has goodies like a gallery to see other people’s art, the ability to view the source-code of any piece of art, and the ability to save the art to your desktop with a single right-click (that comes along for free, more on this in a second). It works best in Firefox 3, but should also work in Opera and Safari.

The inspiration and kick-in-the-pants motivation for this project came from the always-excellent John Resig (also of Mozilla) finally releasing Processing.js.

It’s All About the Javascripts

ContextFree.js is a port of Context Free Art by Chris Coyne. Algorithm Ink uses open-web, standards-based tools: no plugins required. It uses Canvas to to the drawing, and Javascript to compile and interpret the Context Free grammar. The code that does the compiling and render is open-source and available here. Handling thumbnails and other manipulations of images is just a couple lines of Javascript. No need to muck around with server-side black magic. With the addition of arbitrary transforms to Safari 3.1, all modern browsers, except IE, support Canvas fully enough to run ContextFree.js.

One of the great things about using open-web standards is that it plays nicely with user expectations. If you like a particular piece of art, you can just right click to save it as an image. It would also be possible to use an image as the background for a blog—imagine a unique piece of art adorning your site, one that’s different for every visitor. The bleeding edge versions of Webkit have, in fact, implemented the ability to use Canvas with CSS. Open-web technology helps to break down the silos of inaccessibility: backgrounds images done with Flash have never been adopted because of the heavy-weight feel, as well as the lack of interoperability with the rest of the DOM. As Canvas takes becomes more wide spread, I’m looking forward to an explosion of infographics and other data visualizations that weren’t possible before without a heavy server-side setup, or without a compile step that breaks the ability to view-source-and-learn cycle of the web (Flash, Java, &c, I’m looking at you).

A Peak at the Syntax

The grammar is pretty simple. Let’s start by making a circle:

startshape shape

rule shape{
 CIRCLE{}
}

This says start by drawing the rule named “shape”. The rule shape says to draw a circle.

Now let’s make things more interesting:

startshape shape

rule shape{
 CIRCLE{}
 shape{ s .5 b .2 x -.25 }
}

We’ve added a single line which says that part of the rule for “shape” is to draw itself, scaled down by half, with a slightly increased brightness, drawn on the left side of its parent circle. This makes an off-centered bulls-eye pattern.

Now let’s go to the right, as well as the left:

startshape shape

rule shape{
 CIRCLE{}
 shape{ s .5 b .2 x -.25 }
 shape{ s .5 b .2 x .25 }
}

For comparison, this is what the equivalent code in Processing.js looks like:

// Processing.js code to make the same circle pattern.
void setup()
{
  size(200, 200);
  noStroke();
  smooth();
  noLoop();
}

void draw()
{
  drawCircle(126, 170, 6);
}

void drawCircle(int x, int radius, int level)
{
  float tt = 126 * level/4.0;
  fill(tt);
  ellipse(x, 100, radius*2, radius*2);
  if(level > 1) {
    level = level - 1;
    drawCircle(x - radius/2, radius/2, level);
    drawCircle(x + radius/2, radius/2, level);
  }
}

It’s much longer, involves more setup, and more fiddly calculations. In fact, the entire ContextFree.js source is as long as the setup function. Of course, by simplifying so much in ContextFree.js, we’ve also removed the flexibility Processing.js affords.

Adding one more line of code gives an unexpected result: The Sierpinski Triangle. I’ll leave it as an exercise for the reader to figure out what that line of code is, but I doubt that it will be much of a puzzle.

Follow the mouse

The equivalent of “Hello, World!” for a graphical environment is a dot that follows the cursor, replete with a fading trail. This is what it looks like in ContextFree.js:

startshape DOT

rule DOT{
  SQUARE{ s 4 b 1 a -.9 }
  SQUARE{ s .3 }
}

rule MOUSEMOVE{
  DOT{ }
}

We start by defining the rule “DOT” which draws two things: A large square (scaled up 4x), which is white (brightness of 1), and mostly transparent (alpha of -.9), and then a smaller black square. The large transparent white square acts to fade out more and more of the previous DOTs that have been drawn (it’s a standard trick for doing motion blur effects). The rule MOUSEMOVE simply draws a dot at the current mouse position, whenever the mouse moves.

Here’s the result.

There’s one more example that demonstrates the rest of the features that makes ContextFree.js powerful at the end of this post.

The Big Picture

Besides being pretty, why is ContextFree.js interesting? Because it shows the power of Open web technologies for making graphically-enabled, compelling interaction. The true power of the web revolves around anyone being able to dive in, see what someone else has done, and expand upon it. Canvas lowers the cost of entry to creating graphical mashups and other dynamic, graphical content. It also shows the progress the web has made: a year ago, this demo would not have been possible. Canvas wasn’t ready, and Javascript interpreters weren’t fast enough. Looking at the qualitative difference in speed from Firefox 2 to Firefox 3 indicates the amazing and substantial progress made towards speeding up Javascript since the last major browser release cycle.

Implementation

There are three major components to ContextFree.js: a tokenizer, a compiler, and a renderer. Each can be instantiated and used separately. The compiler returns a JSON object of the parsed code, which makes it easy to write a new front-end. I’d be interested to see if a Flash implementation of ContextFree.js would be faster than the pure Javascript, and if so, how much faster. As a side note, I’d also like to see an implementation of the Canvas API done in Flash, as a better replacement for excanvas for IE.

Because the computation and drawing of fractals can be intensive, the rendering occurs in it’s own threaded queue. How quickly it iterates over the shapes is dependent on how long the last drawing operation happened. This helps to keep ContextFree.js from freezing the browser.

There were a couple problems with browser inconsistencies and Canvas deficiencies that make the renderer interesting.

The first problem I ran into was that whilst the Canvas specification does support setting the transformation matrix, it does not support getting the transformation matrix. This means that if you want to know how large a shape will be when you draw it (for instance, to know when an element in a fractal is too small to be seen and is therefore safe to not draw), or want to draw in a threaded environment where you can’t guarantee a global transformation state, you need to re-implement the entire transformation infrastructure. This is a bad breakage of DRY, and slow from a development standpoint. According to Ian Hickson, the reason for the lack of a getter seems to stem from a possible implementation detail, although I don’t understand the argument. In personal communications with irrepressible Mozillian Vlad Vukićević, it appears that there is an possibility of adding the getter to the Firefox Canvas API.

The second problem I ran into was that versions of Safari older than 3.1 do not support setting the transformation matrix. The work around isn’t pretty. It involves taking the desired transformation matrix, de-convolving it into an equivalent set of rotations, scales, and translations, and then applying those base transforms to the Canvas. That’s a lot of math and eigen values. Luckily, Dojo already did the heavy lifting and I was able to stand on their shoulders for ContextFree.js.

The last problem I ran into is that even the latest editions of Safari do not support .setTransformation, which means that there is no call to return to reset the current transformation matrix to the identity. I used lead Webkit-developer Maciej Stachowiak’s solution, which is to save the pristine transformation state (using .save), perform the desired transformation and draw step, and then restore the pristine transformation state (using .restore).

The end result is that while there are inconsistencies, JS libraries can tide us over until us user-agents get fully in sync. That said, I recommend the addition of .getTransformation to the Canvas specification: it will save a lot of unnecessary code rewriting, most of which is matrix multiplication best done in a low-level language.

Improvments

There are a number of improvements to be made to both ContextFree.js and Algorithm Ink. With the former, it isn’t a full port (it’s missing things like comments, z-index, and loop notation). With the later, there is still a strong disconnect between a text-based input and a graphical output. I would love the ability for authors to indicate which variables are interesting in their code, and have the UI expose that variability through sliders and other graphical means. I’d also like to graphically teach the system rules: for example draw a couple shapes, group them, copy and scale them, and have Algorithm Ink generalize that as a rule, translate that rule to code, and draw the full fractal.

The ever-inspiring Bret Victor had some excellent suggestions that I hope someone takes up:

* Highlight a section of code (or “mark” a rule somehow), and the parts of the picture that were generated by by that code/rule are marked somehow—by applying a tint or a glow, perhaps. Because things are so recursive, you should be able to tell when a part of the picture has been marked multiple times—darker tint, eg. The idea is to be able to quickly explore a program and see what’s doing what.

* The opposite: put the mouse over a pixel, and see what code is responsible for that pixel. Ideally, you could see the entire call stack. Perhaps with annotated pictures so you can see what was drawn at each level of the call stack. Let the artist answer the question, “Why did this [part of the picture] happen?”

* Scrub through the construction of the pic. At each timestep, both the picture being added and the code responsible for it are highlighed. The current transform matrix is shown. I can step through time and understand what is happening and why.

Given that ContextFree.js’s “bytecode” is simply a JSON object, as I mentioned above, it wouldn’t be hard to write a new front-end. For example, here’s the “bytecode” for the “follow the mouse” example:

{
  startshape:"DOT",
  DOT:[
  {
   weight:1,
   draw:[
    {shape:"CIRCLE", s:4, b:1, a:-0.9},
    {shape:"CIRCLE", s:0.33, b:1, a:-0.5},
    {shape:"CIRCLE", s:0.3, b:0.5, sat:0}
   ]
  }],
  MOUSEMOVE:[{ weight:1, draw:[{shape:"DOT"}] }]
}

Get Involved

ContextFree.js is open source and hosted on Google Code. Feel free to jump in. Feel free to email me at my first name at mozilla.com.

Appendix A: Full Example

The last example adds demonstrates a couple more features that make ContextFree.js powerful:

startshape scale

rule scale{
  spiral{s .1 y -.5 x 1}
}

rule spiral{
 SQUARE{ a -.5 }
 spiral{ y 1.5 r 10 s .99}
}

rule spiral .01 {
 TRIANGLE{ }
 spiral{ y 1.5 r 10 s .95}
 spiral{ y 1.5 r 10 s .95 flip 90}
}

Let’s step through the code. The “scale” rule simply makes everything smaller and translates it down and to the right. Let’s look at the first rule “spiral”. It creates a half-transparent square, then makes a slightly smaller square that’s transposed and rotated ten degrees to the left. Repeating this gets a stepping-stone spiral. There are, however, two rules for “spiral”. This is where randomness comes into the design: whenever the rule “spiral” is encountered, ContextFree.js randomly chooses one definition among all definitions of that rule. The number after the rule name indicates the weight of the choice, where the default weight is 1. Thus, this rule draws something like this:

Modify the code slightly we can get an almost hand-drawn look that makes for a compelling background image.

startshape scale

rule scale{
  shape{s .1 y -.5 x 1}
}

rule shape{
 SQUARE{ b 1 s 1.1 }
 SQUARE{ a -.5 }
 shape{ y 1.5 r 10 s .99}
}

rule shape{
 SQUARE{ b 1 s 1.1 }
 SQUARE{ }
 shape{ y 1.5 r 5 s .99}
}

rule shape .03 {
 TRIANGLE{ }
 shape{ y 1.5 r 10 s .95 b .1}
 shape{ y 1.5 r 10 s .95 flip 90 b .1}
}

A large version of this image is also available. You can also play with this pattern live on Algorithm Ink. And for those who missed it, here’s the ContextFree.js code. Email me, or comment below to get involved.

Posted at 3am on 6/30/08 | 21 comments

Cross Browser Canvas Support & Speed

It used to be that if you wanted to draw—curves, shapes, and polyhedra—with Javascript, you would have been out of luck. However, almost all modern browsers now supportcanvas, which is a nifty technology that finally lets Javascript out of its DOMy prison.

For the most part it works well. To see it in action, take a look at the always-excellent John Resig’s Processing.js, Ilmari Heikkinen’s CAKE, and my own Algorithm Ink (which I’ll write more about soon).

Standards Compliance

In the grand tradition of browser technologies, Canvas isn’t fully supported by everyone, yet.

Firefox 3 and Opera 9.5 both get good marks. Ironically, it’s Apple—who originated the technology—that hasn’t gotten around to implementing some of the basics. In particular, Safari isn’t yet standards compliant and doesn’t implement the fundamental setTransform and transform. Transform is, however, supported in the the nightly build of Webkit.

IE is the only browser that doesn’t support Canvas at all (although, with Google’s excanvas you can pretend that it does).

To see exactly how well your favorite browser does, head over to the test report generator. Do note some of the tests are fairly pedantic and don’t have much real-world meaning. To see how your browser stacks up against other browsers, go here. The same caveat still applies here as well, so take them with a grain of a salt.

Speed Tests

In general, Safari is always the fastest, followed closely by Firefox (in most cases), with Opera lagging in far third. Excanvas-enabled IE wasn’t really aware that the race had started. In general, it looks like what slows Firefox down is stroked arcs, while for Opera it’s filled arcs.

You can find the code for the tests here. I averaged the render times over 10,000 draws

Excanvas-enabled IE uses VML under the hood, so every object you draw remains as a live, unrasterized object that eats memory and potentially CPU time. This means that I wasn’t able to test IE in the same way I tested the other browsers: making 10,000 smiley faces causes IE to collapse into an unresponsive mess and die (IE can’t handle all the happiness?).

You can also see how the time increases as more and more objects are added in IE: Drawing 100 circles took only 1.1ms per circle, drawing 10000 circles took 2.14ms per circle, and drawing 50000 took a whopping 21.77ms per circle.

Posted at 4pm on 6/19/08 | 23 comments

Firefox Mobile Concept Video

Firefox is coming to mobile. The innovation, usability, and extensibility that has propelled Firefox to 200 million users is set to do the same for Firefox in a mobile setting.

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.

Standard Mockup/Experimental UI Disclaimer
All of the images and videos are only conceptual mockups of an experimental UI for Firefox Mobile, any particular feature may end up looking entirely different, or may not even make it into the final release.

Screencast

Design Principles

Touch. This concept prototype for Firefox mobile (code name Fennec) is being designed for a touch screen. Why not multitouch? Because Firefox should be able to run on the least common denominator of touch devices. Especially for touch-enabled interfaces direct manipulation is key. Along that line of thought, the interface should be operable with a finger. Switching between input methods is time-consuming and annoying, so the user shouldn’t have to switch to a stylus or other secondary form of input. Firefox will work on non-touchscreen devices, but that’s out of scope for this demo.

Large targets are good. The same fingertip that controls the interface takes up between 1/5th to 1/10th of the vertical/horizontal height/width of the mobile touch-screen. In other words, fingers are fat: hitting small targets is like trying to touch-type with your elbow. All actions should be represented by targets that are large enough to be fast, easy, and (at the very least) not aggravating to hit.

Visual Momentum and Physics are compelling. Nothing shouts “sexy!” like pretty animations and a physics engine. Beyond marketing appeal, there is a strong argument that such physicality helps the user build a mental model of the interface, and that interface physics yields consistency. We are wired to track the movement of things and to be able to remember where they’ve gone, as long as they don’t appear and disappear, which doesn’t happen in the real world. Of course, copying every physical metaphors blindly gets you interfaces like the multi-million dollar blunder that was Microsoft Bob, so we need to select our metaphors carefully.

Typing is difficult. This means we want to minimize the amount of keystrokes required to get anywhere or do anything.

Content is king. With restricted screen size, every pixel counts. As much of the screen as possible should always be dedicated to content, not controls or cruft.

Opening Screen

Let’s start with the basics. When you first open the browser, you’ll see two things. Your bookmarks (right), and a big plus button (left) which opens a new tab/page.

Clicking on bookmarks zooms the browser to the page. You can scroll the page by dragging as well as flicking. Scrolling has momentum (like the iPhone), so it’s easy to go long distances.

You zoom out again by dragging the page past its border in any direction. One of the cool things about this is that the gesture for zooming out to the home screen is simply throwing the page in any direction. It’s singularly therapeutic! It’s also discoverable: in the panning process you discover the visual clues that there is more past the edge of the page. In informal user tests every user figured out the interaction without instructions or help.

New Tabs

Creating a new tab is easy. You click on the big plus, and the browser finds an open spot, puts the tab there, and zooms in on it. If you have a homepage, the new tab opens there. Even as the page zooms further out, the new tab buttons remains in the same logical spot.

Placing the cursor in the URL immediately gives a set of results (a la the awesome bar) that is generate from your history sorted by both frequency and recency. To do an immediate search on what you’ve typed, you can just tap a search provider at the bottom of the results.

Controls

The standard controls (like back and forward) are located to the left of the page. You get there by gently dragging the page in the appropriate direction. When the controls are visible, the URL bar fades in as well. This makes for a discoverable way to access the chrome, with a huge Fitts’s-law-abiding target. To get rid of the chrome, you just drag the page back to the center, and the controls slide away.

Because the controls are accessed by panning, for the most part every single pixel of the screen is filled with what you care about most: the content.

By using horizontal panning to access the controls, we avoid the iPhone’s problem of needing to go to the very top of the page to enter URLs. (Yes, I know about tapping on the top of the screen to auto-scroll, but few iPhone users even here at Mozilla knew the trick). Horizontal panning does introduce the problem of accessing the controls when the page requires a lot of horizontal scrolling, but this is a rare case, and with kinetic scrolling moving a long distance is fast. Even long left-right pages will require only one flick to get to the edge, and then one push to open the controls.

To increase the discoverability of the controls even further, it might make sense to show the controls in the zoom-out view as well (appropriately scaled with the page).

Spatial View

In the zoomed-out view, you can drag the pages around to group them in a way that makes sense to you. If you have a couple pages open to your email, and a couple pages open to some vacation planning material, you can place the similarly-themed sites physically together. This makes excellent use of our spatial memory and muscle memory: finding where you put a page on two-dimensional plane is remarkably swift and requires little cognitive load. With the addition of semantic placement, it’s even better. Spatial view uses space in a near optimal fashion—all pages are displayed at once in near maximum size so that extraneous interaction is not required to browse through your open pages.

This is in contrast with the standard list-based, pop-up method of choosing pages, which is fast for a small number of items but becomes increasingly cumbersome as you have to peck-hunt-and-scroll for the page you want. Such interfaces retain no sense of physicality or visual momentum, and thus lose the benefits they confer.

One of the big benefits of the Spatial view is that it is easily extensible. The bookmarks page is a good example, but think bigger. Imagine if I wanted to transfer info from one cellphone to another: I’d bring the the new phone close to mine, and it would appear as an area in the spatial view. I could zoom into it (assuming I had the appropriate permissions) and see what the other phone is looking at, collaborate, and drag tabs/files/contacts back to my phone. I’m sure there are other ways of using the metaphor, too.

There are a couple ways of augmenting this view. For example, the pages can be sized based on the frequency/recency with which you view a site. That way, sites you visit more often will be larger targets. It also helps to combat the all-page-thumbnails-look-like-white-squares problem. The spatial view has some potential scaling problems on the desktop where you can have upwards of 100 tabs open, but on mobile you’ll never have more than 10ish tabs open. Even so, I think there are solutions to the desktop problem, but that will have to wait until another post.

Spatial view has some passing similarities to Apple’s Expose. Both mechanisms are examples of zooming user interfaces (ZUIs), which have been around for almost as long as multitouch. The biggest different is that with Expose, the spatial relationship between windows is broken every time the windows reshuffle. With the spatial view I know that the tab I want is down and to the left, whereas that mapping doesn’t exist using Expose. It’s an important distinction that helps the user to feel comfortable in the space and not get lost.

Get Involved

The code for the demo is open-source and available here. You can even play with it, but be warned that it is a hack-up-prototype and there are lots of edge-cases that aren’t handled. Labs is interested in turning this concept into a working Firefox extension, so if you are interested in helping to spearhead that effort, drop me a line (my first name at mozilla.com). If you’d like to get involved with Mozilla Labs more generally, check out our forums.

If you’d like to get involved on a broader level with the Mozilla mobile effort, you can join us on IRC (either #labs or #mobile on irc.mozilla.org), join the mailing list, or take a look at the Mobile wiki page.

Thanks

Creativity thrives best when not in a vacuum. There are a lot of folks I’ve bounced ideas off of, but I wanted to call out special thanks to crazy-in-the-best-way-possible Mark Finkle, drier-wit-than-thou Madhava Enros, unsung-hero Alex Faaborg, and I’ll-get-you-next-time Jenny Boriss for their invaluable input.

Posted at 3pm on 6/11/08 | 207 comments

Vote! How to Detect the Social Sites Your Visitors Use

One of the great things about the web is the relative ease with which one can set up a new service. In social bookmarking alone with have Del.icio.us, Digg, Facebook, Fark, Mister-Wong, Newsvine, Reddit, Technorati, Slashdot, and StumbleUpon, to name a few. That’s great for competition, and that’s great for users, but it’s not so good for bloggers and content creators.

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.

On the other hand, if you take the bird-shot approach, it overloads your reader with branded badge after branded badge. It turns your page into the village bicycle. Not pretty.

So many social bookmarking sites!

Nobody seems to have solved the problem yet. Lifehacker, for instance, uses a single Digg badge on their long articles, but they also list a couple of the top social bookmarking sites on every post. Wired takes the total shotgun approach, and they own Reddit.

There has to be a better way.

If you could detect which social bookmarking sites your reader uses, on a per-reader basis, you could display only the badges they care about. But you can’t know that because the browser secures the user’s history, right?

Wrong.

I know that you visit: . It’s a bit scary, I know. I’ll come back to how I know in a second. We can use this information to only display one or two badges that we know the reader uses. It solves the which-badges-to-display problem.

SocialHistory.js

Today I’m releasing SocialHistory.js, code which enables you to detect which social bookmarking sites your visitors use. Here’s an example of how to use it:

<script src="http://aza.googlecode.com/svn/trunk/SocialHistory/SocialHistory.js"></script>
<script>
  user = SocialHistory();
  var visitsDigg = user.doesVisit("Digg");
  var visitsSlashdot = user.doesVisit("Slashdot");
  var listOfVisitedSites = user.visitedSites();
</script>

SocialHistory.js cannot enable you to see all of the user’s history. It has to ask, 20-questions style, if the user has been to a particular URL: It’s hit or miss. SocialHistory.js has a big list of the most popular social bookmarking sites which it checks against. To see the list of sites, you can do:

user.checkedSites()

SocialHistory.js can also check other sites. For instance, if you want to see if your reader has visited any of the blogs I write, you’d do the following:

moreSites =
  {
    "Aza": ["http://humanized.com/weblog", "http://azarask.in/blog"]
  };
user = SocialHistory( moreSites );
alert( user.doesVisit("Aza") );

How Does It Work?

How does SocialHistory.js know? By using a cute information leak introduced by CSS. The browser colors visited links differently than non-visited links. All you have to do is load up a whole bunch of URLs for the most popular social bookmarking sites in an iframe and see which of those links are purple and which are blue. It’s not perfect (which, from a privacy perspective, is at least a little comforting) but it does get you 80% of the way there. The best/worst part is that this information leak probably won’t be plugged because it’s a fundamental feature of the browser.

Vote For Me, Where You Care

Enjoy cleaner, more aware pages. Gone are the medieval days of badge spamming!

P.S. Yes, I do feel a bit dirty for using this information leak. At least I’m using it for a modicum of good. My cleaner half raises the cup to hoping that Dave Baron can stop the leak in Firefox by vanquishing bug 147777.

Posted at 2am on 5/28/08 | 119 comments

What If… It Was Easy To Write Firefox Extensions

Writing extensions is labor intensive. Even as a veteran web developer, I feel trepidation at the thought of diving into the boiler-plate code, wading through the XUL world, and restarting Firefox uncountable times. There are tools out there to mitigate some of these problems—like Ted Mielczarek’s Extension Wizard, and Mark Finkle’s FUEL—but they feel like fresh frosting on a stale, left-out-since-last-Thursday birthday cake.

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: What incredible places could the web go, as an open platform, if extending the web was as easy as writing for the web? What if my knowledge as a web developer was all I needed to extend Firefox? What if writing a Gmail notifier was as easy as:

function gmailNotifier() {
  var url = "http://mail.google.com/mail/feed/atom";

  ajaxGet(url, function(rss) {
    var firstEntry = $(rss).find("entry").get(0);

    var newEmailId = $(firstEntry).find("id").text();
    var subject    = $(firstEntry).find("title").text();
    var author     = $(firstEntry).find("author name").text();
    var summary    = $(firstEntry).find("summary").text();

    if( newEmailId != globals.lastEmailId ) {
      var title = author + ' says "' + subject + '"';
      displayMessage(summary, title);
    }

    globals.lastEmailId = newEmailId;
  });
}

function onStartup() {
  globals.lastEmailId = null;
  setInterval( gmailNotifier, 15*1000 );
}

Well, it isn’t that easy. Yet. *wink*

Posted at 6pm on 5/23/08 | 16 comments

Intuition, and the Monty Hall Problem

Statistics is hard. It’s one of those fields, where your intuition seems to take you gently and seductively towards safety, and then you wake up in a bathtub full of ice, missing a kidney. Interface design is often the same way (but, for once, that’s not what I’m writing about). When we say that we find something “intuitive” it means that we have seen something like it before—we are saying that it is familiar. The thing with statistics is that similar looking situations can behave very differently.

The first time I had this point driven home was when I was presented the Monty Hall problem. Posit: You are on a game show and three doors stand before you. Behind two of the doors lies nothing, behind one door is a pile of cash. The game begins by you picking one of the doors. The host (Monty Hall) then opens one of the two remaining doors, revealing one that is empty. Then it’s your choice: Do you stick with the door you originally picked, or do you switch to the other door? Does it matter?

Intuition says is that it doesn’t matter. It’s 50%-50%. It’s the same as throwing a coin—the money is in either one door or the other. This kind of thinking will lose you a kidney. You’ve been tricked by “intuition” to not got suckered by the gamblers fallacy, only to get suckered by something new.

It’s best to switch doors. In fact, switching doors will make you win twice as often as staying. While I’ve been able to prove that for a long time—by enumerating all possible outcomes and counting&mash;it never really clicked in my head why it’s true. It never became familiar. It never became intuitive. Until a couple days ago. Here’s the explanation the occurred to me (in the shower, as always) that made it all make sense:

The chance that you pick the right door on the first choice is 1/3: there are empties and one prize. Conversely, that means that there is a 2/3 probability that prize is in one of the other two doors.

3 closed doors.

If you could open the other two doors, see which ones contains the money, and take it, you would have clearly do that. That’s twice as good as getting to open only one door! Well, when Monty opens one of those doors that doesn’t contain the prize, he’s effectively giving you that ability: there is still a 2/3 probability that the prize is behind the set of doors you didn’t pick.

It’s obvious, now, that switching will give you a 2/3 chance of winning. By opening a door that doesn’t contain a prize, Monty has effectively concentrated that 2/3rds probability into the one remaining door.

This way of looking at it makes it really easy to calculate similar problems. For example, take the 5 door case: you pick a door, Monty opens 3 empty doors, and you have to choose if you should switch. Your first pick has a 1/5 chance of getting the prize, which means that there is a 4/5 chance that it is in the set of doors you didn’t pick. Monty opens 3 of those 4 doors, which means that 4th unopened door takes that full 4/5 probability. Thus, switching is 4 times more likely to win than is staying.

What happens if Monty only opens two doors, instead of three? Should you switch? It’s easy to figure out. You still have 1/5 chance of getting the door on your first pick. The other doors still have a 4/5 chance of having the prize. He opens two, which means that 4/5 probability is spread equally over the remaining two doors. Thus switching will give you a probability of half of 4/5ths, which is a 4/10ths probability of winning. That’s better than 1/5 chance of winning, so switching is better.

What’s the moral of the story? That intuition is malleable and that statistics is hard, until you find the right way of framing the problem. And that’s a general rule.

Posted at 8pm on 5/22/08 | 20 comments

Geolocation Redux and a JS Library

After the excellent feedback I got on my last geolocation blog post, I’ve updated the proposed geolocation API. More importantly, I’ve also created a pure Javascript library which you can use to start playing around with geolocation before we actually get it into the browser. This library provides exactly the same API as would be provided by the browser. Although it can’t offer GPS-quality data, it does provide a decent city-level geolocation based on your IP. You can get the library here, and there’s also a no-frills demo.

For quick hacking you can just include the following in your head tag.

<script src="http://azarask.in/projects/geolocation/MockGeolocation.js"><script>

The best way to get a feel for the API is to see some examples:

var g = new navigator.GeolocationRequest();
g.request( function(geolocation){
  alert( geolocation.longitude + ", " + geolocation.latitude );
})

This is the same example as we saw last time; it alerts the user’s current location. What’s new is that I’ve spec’ed out the object passed to the callback (I’ve borrowed some of the great work done for the GoogleGears Location API):

interface Geolocation {
  readonly double latitude;         // in degrees
  readonly double longitude;        // in degrees
  readonly double altitude;         // in meters, or null if no data.
  readonly double accuracy;         // in meters
  readonly double altitudeAccuracy; // in meters, or null if no data
  int timestamp;                    // time of the location read, in seconds since
                                    // the epoch
}

Everything here should be self-explanatory. As a commenter mentioned last time, it’s important to know when the last location reading occurred. Without it, for example, it would be impossible to reliably calculate the current speed of the browsing device. (Knowing such data gives developers all sorts of fun—we could have an onDrunkDriving DOM event for when the browser detects your moving at 60MPH and weaving!).

Let’s move on to something a bit more complicated.

var g = new navigator.GeolocationRequest();
g.request({
  error: function(e){ alert( e.message ); },
  success: function(location){
    alert( location.altitude + "+/-" + location.altitudeAccuracy );
  },
  desiredAccuracy: g.defaultAccuracy
})

Here’s the new stuff:
error takes a callback whose argument is an object. The only attribute the object must have is message, a human readable explanation of the error. The error object may have other attributes, as dictated by the particulars of the location-giving device.

desiredAccuracy is a string which can take one of three values: “exact”, “neighbourhood”, and “city”. In order, “exact” means to return a geolocation as precisely as possible, “neighbourhood” means to return a geolocation good to 1km, and “city” means to return a geolocation good to 10km. It’s unnecessary to include a “country” option because there are more accurate ways of knowing what country a user is browsing from than with a highly fuzzed lat/long (e.g., IP-based geolocation).

defaultAccuracy is a read only property of the GeolocationRequest object that contains the user’s globally-set preference for yielding location to content providers. If the user has opted to give all websites city-level access to their location, then a website requesting city-level information won’t cause the browser to prompt for permission. In the above example, the request is asking for the highest accuracy location that won’t prompt the user for permission. defaultAccuracy is null if the user has opted out of providing geolocation information.

That about wraps it up for the API. Full interface documentation is available.


Why not on window.navigator?

It’s tempting to attach the GeolocationRequest object to window, but it makes more semantic sense to place it on the navigator object (and, unfortunately, not just for the pun). The navigator object contains meta information about the browsing agent—browser version, os, language, etc—and geolocation information is just that. Looking at it from the other side, the window object should contain information that is tied to the current tab/window. Geolocation is independent of what tab/window you are looking at (unless, of course, you have an extremely large screen), and so should not be attached directly to window.


Geocoding API

I’m somewhat on the fence about whether to include geocoding as part of the fundamental GeolocationRequest API. The information is useful to web developers, and it is a boon to not require an extra Ajax call to perform geocoding. However, it’s going beyond the scope of the fundamental language of geolocation. To quote Arun Ranganathan, our standards hero here at Mozilla:

When coining new browser primitives exposed at the same level as DOM stuff, we essentially go with the simplest thing that developers can do that won’t break the web and that are possibly exposed on the given device. You’ll notice that there’s plenty of scope for more nuanced APIs on top of our primitive stack, and this has contributed for much of the boom on the web for third party encapsulations around basic browser primitives (Dojo, Prototype, jQuery, etc.)… latitude/longitude is the basic thing we should expose. These can be used with other services and providers (example: Google Maps) to obtain address information or proximity information based on latitude and longitude.

That aside, we don’t really have to choose. By designing the API right, we can upgrade to include geocoding at a later date, without breaking any code. Let’s see it in action:

var g = new navigator.GeolocationRequest();
g.request({
  error: function(e){ /* Handle error. */ ); },
  success: function(location){ alert( location.address.city ); },
  desiredAccuracy: "neighborhood",
  requestAddress: true,
  addressLanguage: "en-US"
})

You can get the library for the address-enabled API here. The address object interface is:

interface Address {
  // Any of the below can be null, if not known.

  readonly string streetNumber; // street number
  readonly string street;       // street address
  readonly string premises;     // premises, e.g. building name
  readonly string city;         // city name
  readonly string county;       // county name
  readonly string region;       // region, e.g. a state in the US
  readonly string country;      // country
  readonly string countryCode;  // country code (ISO 3166-1)
  readonly string postalCode;   // postal code
}

The full specification is available, if you are interested in such sundry documentation.


Interface

Based on a number of good suggestions from the last post, this is how I’m thinking the security UI should look:
Geolocation Security Mockup

Posted at 1am on 5/22/08 | 15 comments

Geolocation in Firefox and Beyond

In preparation for her keynote on the at the Web 2.0 Expo, Mitchell and I recently chatted about the “mobile web” misnomer. The misnomer is that there is going to be, long term, such a thing as a separate mobile web. There should only the one web (to rule them all), with different views into it, depending on the particular limitations or abilities of the device you are using.

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 all of my devices.

One of the symptoms of the the mobile-only location information is that to make something location aware, you have to deal with the large overhead of compiling an old-style application and porting it to all desired platforms. Then you have to figure out how to import the bits of the web you want into that application. It’s a pain.

What’s the solution? Adding geolocation to the browser, irrespective of whether it is on mobile or the desktop. That way writing a location-aware app is just writing a web-app with a little bit of new javascript magic.

I’ve been thinking about an API/spec, basing it on the work already done by Doug Turner and Ryan Sarver at locationaware.org. Here’s how it’s looking.

Simple call:

var geolocator = new navigator.GeolocationRequest();
geolocator.request(function(location) {
  alert( location.latitude + ', '+ location.longitude + ", " + location.accuracy );
});

That should be pretty obvious. The only bit that needs explanation is accuracy, which is a measure of how accurately the system is determining your location. Accuracy can be an enum with the these meanings: “exact”, “neighborhood”, “city”, “state”, “country”. I’ll come back to the reasoning behind doing it this way. However, it is worth thinking about also having an attribute location.errorInMeters (If you have thoughts on this, comment away!).

Complex call:

var geolocator = new navigator.GeolocationRequest();
geolocator.request({
  success: function(location) { /* We've got the location! */ },
  error: function(err){ /* There was an error getting location. */ },
  accuracy: "neighborhood"
});

Accuracy is the desired accuracy for the request. It’s there to make it easy for users and developers to see eye-to-eye on privacy and reliability. By putting accuracy into understandable, semantic, and quantized levels, we make it fast to understand what a web-app is trying to request. This way, if the user has globally allowed web sites access to their location at the neighborhood level, then any location request at the neighborhood or less-accurate level won’t cause the security/privilege UI to be invoked. And when the the request invokes the security/privilege UI, it can let the user know, in human-terms, what level of location information is being requested.

Here’s a quick mockup of the security UI. I haven’t put to much thought into ways of making this nicer yet, although I’d love something that gave a more visually compelling message of how much information you are giving out to websites.

Geolocation Security Mockup

I should be releasing a mock library for starting to play with this API soon. After that comes the real thing.

Posted at 8pm on 5/7/08 | 21 comments

Blogging and Hiring

I’ve been very quiet since joining Mozilla. Too quiet. I’ve been catching my breath and getting up to speed. It’s time, however, to start blogging again. I’ll be blogging here, but I’ll be mirroring the posts on the Humanized blog for a while. Be warned that the new blog has a temporary look, meant to be replaced soon by the awesome work of Naz Hamid. I should also point out that Atul has already begun talking about his experiences at Mozilla on his blog. You can also follow the sundry happenings of Jono and Andrew on their respective blogs.

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 azzcsa@mozilla.com.

Posted at 2am on 5/6/08 | 4 comments

Bloxes

Today, we are proud to announce the launch of Bloxes.

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.

Posted at 5pm on 3/7/08 | 7 comments

Enso 2.0 Prototype

Get ready. Flex your pinkie finger. It’s time to try out the Enso 2.0 Launcher prototype. It runs on top of the free Enso Launcher, so all you have to do is download the prototype, install, and try it out. You’ll get some new features, several improved commands, and (of course) all of your old commands will still work. If you haven’t been following our weblog, you might want to read about the motivation behind this design, and our explanation of the design .

(more…)

Posted at 8pm on 2/5/08 | 50 comments

Enso 2.0 Design Thoughts

As part of the our move to Mozilla and thinking about a free-as-in-speech Enso, I want to be more transparent with our design directions and goals. Our designs can only benefit by incorporating the criticism and suggestions of the community we have here. Open-source design is a balancing act between making final decisions and finding consensus. We hope to take the lessons that Jono spelled out in his excellent article on successfully humane open-source projects and use them in our own projects.

This post is about the new directions we are taking Enso. If you haven’t done so yet, start by reading about some of the motivations for doing some Enso redesign. In short:

  • Enso shouldn’t make you type all of “open” every time
  • Enso should be able to open paths and urls
  • Enso should support international character input
  • Enso should gracefully handle the case where there’s no convenient place to enter text
  • Enso shouldn’t require you to type out text, select it, and then run a command when you’d rather run the command and then enter the text (think calculate)
  • Enso shouldn’t make you hold down a key while typing lots of characters

We think we’ve solved these problems with our Enso 2.0 redesign. In this post, and possible follow on posts, I’ll walk through the new stuff. I should note that our upcoming prototype will not yet have have all of the features mentioned here. (more…)

Posted at 1pm on 1/31/08 | 47 comments

Songza and a Little Thing

Songza Logo

Last month we added an “about songza” page to Songza. It’s a simple page — just a couple headers, some text, and a return-to-Songza link. I thought I’d a walk through my thought process in through-designing this tiny feature. It’s not quite as simple as it first appears.

The first question is whether to have the about content be on a separate page, or as lightbox/hidden-div content on the main page. I was tempted by the second option; there is a seduction to having Songza exists on only one page. On the other hand, that solution isn’t particularly scalable — Songza has already added other pages similar to the about page, how would they all interact? And how do you keep the load-time reasonable as more and more content is added? — More importantly, the content is not linkable or search-able. Using clever Ajaxy tricks means that the visibility of the content is dependent on application state.

It’s clear that the about page should be, in fact, a separate page. That leaves us with a glaring usability problem. Do you see it? It’s bad enough that I would be wary of clicking links while listing to songs if I ever got bitten by the problem.

(more…)

Posted at 10pm on 1/25/08 | 17 comments

Joining Mozilla

Software is too frustrating. There are a lot of choices in today’s computing world — what’s worse, most of them are too complicated. Hundreds of features, dozens of user preferences, unresponsive programs, inscrutable error messages, crowded toolbars, merciless disrespect for the safety of your data; all of these are problems that plague most of today’s software. We, as Humanized, are dedicated to tackling these problems and to making software effortless.

Mozilla is about making the web (which isn’t just the browser!) useful for, and usable by, everyone. Mozilla is in a unique position — not being beholden to any particular technology or the bottom-line — to push the web forward, past the boundaries of the browser, focusing foremost on people. Which is why I am excited and proud to say that we are joining forces with Mozilla to head up the user experience side of Mozilla Labs. We will be working inside the browser, on the browser, outside the browser, and mixing all three. Enso’s coming too.
(more…)

Posted at 11pm on 1/16/08 | 24 comments

The Case of the Mysterious Vanishing Amazon Kindle

I broke down and ordered a Amazon Kindle a couple days ago. It is definitely a first generation device: not only does it look state-of-the art 1980’s, but it’s main mode of interaction is through a marginally clever hack to get around eInks slow refresh rate. However, the idea of being able to have all five books I’m always invariable a third of the way through, plus an always-on calendar (via it’s browser function and mobile Google calendar), always-on email, always-on maps, always-on Wikipedia, makes it (possibly) worth the price.

So late the other night, when my rationality had been worn down by a days debugging, my “buy” impulse beat out my fiscally responsible genes. I took out my credit card and purchased. Because I’m a previous Amazon customer I entered my email (which I haven’t bothered to update to my new address) and my password, clicked the buy button. It was done.

The next day, I checked up on the order. When was my new toy going to arrive? I logged in and… the order wasn’t there! I frantically clicked on every button I could find to no avail. Had I only imagined ordering the Kindle? I hadn’t been that tired. I checked my bank account and indeed the money had been deducted from my account. So where had my order gone?

(more…)

Posted at 8pm on 12/17/07 | 12 comments

Songza Launch

I am proud to announce the release of Songza, a music search engine and Internet jukebox. Songza solves the related problems of “I want to hear a song” and “I want to share a song with a friend.” Released on November 8, its popularity is growing rapidly: We’re poised to reach one million songs played within just a week of launching Songza.

Songza is also an interface showcase. I’ve used the interface principles discussed here on the Humanized blog to design Songza to be humane, slick, and viral. Play with the interface for a bit, and you’ll find habituatable pie-menus instead of slow linear menus; an inviting design that uses only two icons, both of which act as illustrations for words; an incredibly high density of content and a correspondingly low amount of interaction; undo instead of warnings; and transparent messages that don’t break your train of thought.

Ironically, there’s a lot that went into making Songza so simply. Achieving such a high level of simplification required a lot of code, in part because we couldn’t just use standard widgets. It was worth it, though.

You can’t be better without being different — I think Songza is both.

Posted at 5pm on 11/13/07 | 90 comments

Enso Developer Prototype

Ever since we launched Enso, we’ve been getting feedback like this:

— When are you going to come out with the Python API for commands?
— I’m looking for a way to extend Enso.
— Is it is possible to enrich Enso with custom commands?
— I heard there will be support to create your own commands. How far off is this?
— An SDK would be wonderful!
— Being a Python developer, I am very interested in the ability to expand Enso.
— Would you have any available API’s?

The entire Humanized team is extremely proud to announce that the answer to whether is “Yes“, and the answer to when is “Now“! Today marks the release of Enso Developer Prototype, which lets anyone develop commands for Enso. It’s free and it’s available for download. (more…)

Posted at 12pm on 10/24/07 | 9 comments

Undo Made Easy with Ajax (Part 2): Time-Sensitive Actions

This is the second part of the Undo Made Easy with Ajax series. If you are jumping in late, make sure to check out part 1.

Last time we covered the event queue method, an entirely client-side way of implementing a light-weight, multi-level undo. I mentioned a couple of caveats, including that it does not work in multi-user collaborations, and that it doesn’t work for time-sensitive actions like sending emails. I missed a significant caveat that one of my readers, Alexander Botero-Lowry, pointed out: That two tabs, pointed to the same page, could get out of sync. I wrote about how to solve that issue with cookies.

This time, let’s take a look at solving Undo for time-sensitive actions. In the event queue method, we could wait until the “onunload” event to sync the user’s actions from client-side to server-side. For time-sensitive actions like sending emails, we don’t have that luxury. Worse, email is a push technology. Once an email has been released into the wild tubes of the Internet, it cannot be unsent.* For the unfortunate who hits “send” only to realize that they’ve CC’ed their boss on a steamy love letter, the only things left to hope for are power outages and spam filters. Given how often spam slips past my filters, the outlook is not so good. (more…)

Posted at 2pm on 10/22/07 | 13 comments

Introducing Enso Map Anywhere

Imagine this. You are writing an email to a friend and you mention that you want to meet at your favorite breakfast place in Chicago: Tre Kronor. Wouldn’t it be nice to be able to send them Tre Kronor’s address along with a map? Currently, the only way to do this is to open your browser, load up a site that provides maps, do a search for the restaurant, wait for the map to appear, copy the URL of the map to your email, copy the address to your email (and reformat it), and finally close your browser. Gross—and you’re not even sending a map, just a link to one!

Enter Enso Map Anywhere.

Enso Map Anywhere lets you select an address or a business name and add a map in place. For instance, if you don’t know where a business is, you can just highlight its name and you’ll get a beautiful map from Google with the location marked, along with the business’s full address and phone number. Alternatively, you can use the map command on a partial address like “4611 N Ravenswood” to get a map and the full address. It’s a great way to look up a forgotten ZIP code.

So download it now, it’s free forever and works with (but doesn’t require) other Enso products. Go map happy. It maps in lots of places, from Word to Gmail. You can even use it while blogging in Word Press. Check it out:

Bongo Room, Chicago
Map
Bongo Room: 1470 N Milwaukee Ave, Chicago, IL - (773) 489-0690
Did you mean the Bongo Room at 1152 S Wabash Ave, Chicago, IL - (312) 291-0100?
Mapped by Enso Map Anywhere

Posted at 6pm on 9/24/07 | 9 comments

Undo Made Easy with Ajax (Part 1.5)

This is the second half of the first part of the Undo Made Easy with Ajax series. If you are jumping in late, make sure to check out Part 1.

One of my readers, Alex Botero-Lowry, pointed out a big caveat to the entirely client-side event queue method of implementing Undo: If a user opens a second tab to a page they were viewing, those pages might be out of sync. In the to-do list example, if you delete three to-do items and then open a new tab/window to the same page, those to-do items would still be there. Why? Because the first page knows about the deletes (even though they are uncommitted) and the second does not.

Let’s take the client-side only approach and run with it. There is something nice about not having to mess with the back-end. We can fix the multiple-tab problem by syncing the event queue across all open pages with a cookie. (more…)

Posted at 4pm on 9/21/07 | 8 comments

Avast ye Win-lubbers: Here be Pirate Translation

In honor of International Talk Like a Pirate Day we’ve added the pirate-talk ability to Enso Translate Anywhere! To chat like a sea dog, all you’ve got to do is to select your text and use the “translate to pirate” command. To make your Photoshop captions more swashbuckling, just select them and use the “translate to pirate” command. Even your file names can be made less land lubbin’. Seriously, what could be better?

Want the penultimate laugh? Select an email to your boss, translate, and shiver his timbers.

Arrrr you wanting to know more about this horn swogglin’ Enso and its commands? Sail o’er to this link. And, a round of rum to Jeffrey Souza for being the source of all our buccaneer-talk knowledge!

So take out your hornpipe and grog, and download Enso Translate Anywhere, the pirate edition. Where does it run? I’ll give ye a hint: XP marks the spot (Vista and 2K too, arr).

Now, t’ return t’ findin’ me some golden interface booty.

Posted at 2pm on 9/19/07 | 4 comments

More Enso Commands. For free.

We are proud to announce four new Enso products. This time they’re all free.
Enso Media Remote Control
A remote-control for your music: play, pause, and skip tracks in you favorite music player without moving from your current application.

Enso Translate Anywhere
The power to translate English to and from eight other languages, in any application.

Enso Web Search Anywhere
Provides commands for performing web searches using a variety of web services, from Amazon to Youtube to your Gmail account.

Enso TeX Anywhere
Effortlessly render TeX markup into beautifully type-set equations (and convert them back again) anywhere from Powerpoint to your email.

Can’t decide which one you want to try first? Then download them all with the One Installer.

(more…)

Posted at 7pm on 9/17/07 | 15 comments

Undo Made Easy with Ajax (Part 1)

As users, we make mistakes. As designers, we need to design with mistakes in mind, as I argued in my recent article, Never Use a Warning When You Mean Undo. Undo is the ultimate safety net, lending an incredible sense of solidity to an interface. That’s why every desktop application from Word to Photoshop provides multiple-level Undo.

So, then, why are Web apps that provide any sort of Undo so few and far between? The answer I often get is that Undo is hard to implement. I’m here to tell you that it is not.

In this series of blog posts, my goal is to explain just how easy it is to provide Undo functionality. Recently, I gave a preliminary version of this post in a workshop. After giving the front-facing demo of how Undo could work, the audience moved slightly towards the edge of their seats (it’s all you can hope for in the post-lunch session). When I opened the source code and started showing how I implemented undo, the universal response was, “Why are you bothering to explain this implementation? It’s barely anything at all. We’re software engineers. This is easy.”

That’s my point!

Adding Undo to your interfaces profoundly and positively affects the usability of your site. It reduces user frustration, and increases user trust. Both of those outcomes mean that more users continue coming back, which helps your bottom line. Remember: To the user, the interface is the product. (more…)

Posted at 12pm on 9/14/07 | 50 comments

“Wikipedia” + “Expert” = “Wikspert”

I’d like to propose a new portmanteau for inclusion in the English language: “Wikspert“.

A wikspert is someone who is an expert on a topic purely on the basis of having read the Wikipedia article on that topic. In short, “Wikipedia” + “Expert” = “Wikspert”.

Once confined to an exclusive class of in-the-know computeristas, the last couple of years have seen proliferation of “wiksperts” in every level of our society. They’re everywhere. From business-school professors to burger-flippers, everyone now has a quasi-authoritative opinion on, for instance, how much corn is produced in Iowa. These trivia, once the sole purview of academic cocktail parties, have now been liberated for the masses. In fact, every one of us either knows a wikspert or is one ourselves. Personally, some of my best friends are wiksperts, and I know a suspicious amount about liopleurodons, pumas, and the ethnic make-up of Romania in the early 1800’s.

(more…)

Posted at 5pm on 9/5/07 | 10 comments

Redesigning the iPhone’s Buttons

In my recent article about the first generation woes of the iPhone, I complained that the volume buttons are difficult to use in landscape mode; that the natural mapping that works so well in portrait mode (up means louder, down means softer) fails after the rotation (left means louder, right means softer). I suggested that the iPhone could detect its orientation and correct the mapping accordingly. In other words, the iPhone should swap the meaning of the buttons based on the phone’s orientation. The result? Widespread criticism. Even the venerable Apple pundit John Gruber weighed in with “I strongly disagree with [Aza’s] idea about the volume buttons.”

It’s clear I need to make my case stronger, or else banish the idea to the halls of interface shame (a fate normally reserved for Clippy and Adaptive Menus).
(more…)

Posted at 2pm on 7/30/07 | 34 comments

iPhone and the First Generation Woes

The iPhoneFor everybody who was hiding under a Godzilla-sized rock, Apple released the iPhone last weekend. It represents a big step forward in pure humane-ness of mobile devices. Despite the slow network, the poor customer service provided by AT&T, and the lack of an open development environment, I am still on the verge of getting one. Using its interface is a like drinking refreshingly cool water after a crawl over a barren desert made of discarded cell phones.

Instead of singing the praises of the iPhone (which it deserves), I want to describe some of the unpolished corners that escaped Apple’s quality assurance.
(more…)

Posted at 12pm on 7/5/07 | 48 comments

The End of an Icon

Finding the right graphic for an icon is hard — and even if you do find a decently descriptive graphic, it might not be descriptive for long.

For the majority of cases, trying to represent an abstract idea like “bibliography” in a 32-by-32 pixel array is futile, even if you do have millions of colors and an alpha channel. Sure, you might choose a book with a magnifying glass as your icon, but that graphic could mean many things: “library”, “help”, “research”, “index”, “vision impaired”, etc. Any interface that uses the icon would still have to add a tooltip to explain what it means. There is a reason why we have words — it’s so that we can specify one thing in particular no matter how complex or abstract the thought.

Why make the user go spelunking for the information they need? Just give it to them.

It came to my attention recently just how fragile the connections are between the iconal representation of a concept and the actual concept. Here is the Microsoft Word icon for “to save”.

Word's icon for save, which is a floppy disk.
It’s a floppy disk. There is only a tenuous connection between saving and a floppy disk even for those of us who know what a floppy is (and at the moment most of us remember them), but floppy disks are on their way to becoming as unknown as Charles Yerkes. Don’t know who I’m talking about? That’s my point.
(more…)

Posted at 5pm on 6/25/07 | 31 comments

Humanized Puzzler #2: Firefox Tabs

Recently I wrote an article called Firefox 2.0: Tabs Gone Wrong. In it, I argue that Firefox introduced a new feature that represented a big step backwards in terms of tab usability:

In Firefox 2.0 a “feature” was introduced that dealt with the edge-case where there were many tabs in a new way. It takes a giant step backward by actively concealing information.

Previously, as the number of tabs grew, each one’s size would shrink. Eventually, there would be so many tabs that you couldn’t even read their titles. But, while this clearly wasn’t ideal and led to a certain amount of hunting for tabs, you at least always knew roughly where it was: “an inch or so from the right side of the window”. Now, however, the tabs remain mostly readable but can scroll off-screen.

Firefox 2.0 style tabsTo access off-screen tabs you need to click on the little arrows on the left or right of the tab bar. For allowing a only a subset of the tabs to be readable at a time, a lot has been sacrificed:

  1. Scanning your eyes across the tab-bar no longer guarantees you’ll see all of the tabs — this has tripped me up a number of times: I’ve ended up with 3 or 4 identical because I didn’t realize that I already had the tab open;
  2. You can no longer associate a tab-bar location with a certain tab because they shift around every time you scroll — the interface doesn’t feel stable anymore;
  3. Scrolling through tabs is quite slow — I find that it is often the case that opening a new tab is faster then finding the old one.

Well, here’s the thing. Mozilla is listening. They want a better solution and are willing to put it into Firefox if it’s good.
(more…)

Posted at 6pm on 6/19/07 | 120 comments

Iterative Design: Towards the Perfect Paper Plane

Paper Airplane (Beta)Iterative design isn’t design by trial and error. Iterative design is a process of continually improving not just the design, but also the problem your design is trying to solve.

Coming up with a solution is often the most straightforward part of the design process. That isn’t to say that creating the solution is easy, or doesn’t require a deep knowledge and honed skill set. It’s just to say that when you have a set of requirements and a well defined problem, you know where you stand and where you have to get to. It’s mostly straightforward. Much harder is the implicit problem of figuring out exactly what the problem is in the first place. If the problem is vague or ill-defined, the design solution will be too.
(more…)

Posted at 6pm on 6/5/07 | 13 comments

Firefox 2.0: Tabs Gone Wrong

Firefox introduced tabbed-browsing to the masses. And it was good. It took Microsoft years to catch-up.

Why are tabs good? Frankly, because the standard windowing model is bad. It’s much easier to scan through a horizontal list of tab names then it is to wade through alt-tab’s textless, iconic grid. One of the benefits of tabs is that they are always linearly arranged in a fixed order. To find your tab, you simply have to run your eyes from left to right; once you get to the end, you’re done. With windows, however, your eyes have to rove around the screen looking for the one you want and you might never find it because windows can hide behind other windows. And unlike tabs, unless you’re very careful, windows will not stay in a consistent place because they are constantly being shuffled to accommodate limited screen real-estate. The net result is that finding a particular window is like playing whack-a-mole blind-folded, whilst finding a particular tab is like fishing for fish in a barrel with dynamite.

In short, tabs are better than windows because they don’t conceal as much information.*

In Firefox 2.0 a “feature” was introduced that dealt with the edge-case where there were many tabs in a new way. It takes a giant step backward by actively concealing information.
(more…)

Posted at 4pm on 4/5/07 | 68 comments

What Makes a Good Autocomplete?

We’ve been working on a problem for the past couple of weeks: an optimal autocomplete algorithm.

Many of our users have said that while Enso is great, it requires a bit too much typing. We’re inclined to agree. Yet, figuring out the best solution is tricky: there are more autocomplete algorithms than bones in a school of lionfish. There are straightforward algorithms, too-clever-for-their-own-good algorithms, standard command-line-style autocomplete algorithms, and the list goes on. A lot of the algorithms seem to go down fairly easily when you first start playing with them, but they end up getting stuck in your throat due to some unforeseen edge-case. This post explains our thought process in evaluating the algorithms given the (g)astronomical number of possibilities.
(more…)

Posted at 4pm on 3/30/07 | 32 comments

Command Line for the Common Man: The Command Line Comeback

Web 2.0 Style Command Prompt
Command line interfaces are bell-bottom out-of-fashion in the current Web 2.0 boom: I have yet to see an Ajax-enabled glass-reflected command prompt. Let’s face it, command line interfaces are extinct to the masses. The GUI dealt the first blow, and now the Web has nailed to coffin on the old style text interface, and it seems to have been a boon for the user. I don’t know if I can set up a printer on the command line, but I do know that I don’t want to try.

But maybe that isn’t the fault of command line interfaces in general. Maybe it’s just the command lines we’re used to. The hard part of learning Unix is memorizing command names as unfathomable as Stonehenge’s origin. And even if I do remember the command name, remembering its options is like bobbing for apples in a cement mixer. I still have to ask my co-workers what flags are needed for untaring a gzipped file. “tar -xfvz”. How could I forget?

If commands were memorable and their syntax forgiving, perhaps the command line wouldn’t be going the way of the punch card. And perhaps they aren’t. Perhaps, command lines are staged for a comeback.
(more…)

Posted at 1pm on 2/24/07 | 34 comments

Interface Puzzler #1 Answer

puzzler.gifThanks to everyone who wrote in and gave solutions to the first Humanized Puzzler. There have been many more responses that we anticipated! I loved the discussion of the problem. Although I had meant for people to email the solutions privately instead of discussing publicly, in retrospect, the discussion was more valuable than the secrecy. The next puzzler will all be discussion.

I’d also like to apologize for taking so long in posting the solution. With the release of Enso, we’ve been very busy.

In short, the puzzler asked, “Can you design a car that isn’t forward/reverse modal?” For those who didn’t read the original post, check out the full question.

Few people were fooled by my implication that a solution was impossible. With modern automatic cars, almost any conceivable behavior is possible for shifting because the gear selector is simply an electronic switch physically decoupled from the transmission. The trick is choosing a good behavior.
(more…)

Posted at 4pm on 2/13/07 | 16 comments

Enso Update and Price Drop

Thanks to everyone who downloaded Enso and tried it out, and a special thanks to those who have already bought Enso. In the last week, we’ve gotten an enormous amount of feedback, and we’re working as hard as we can to respond to all the requests, complaints, compliments, and feature requests. Happily, we’ve fixed the first round of bugs. And, already on its way, is the next round of changes: adding the oft-requested features (like the ability to change Enso’s entry key and whether Enso is “sticky” or not).

In this update we’ve made two important changes.

First, we’ve heard a lot of feedback that Enso was just too expensive. We hear you. We are dropping the price of both Enso Launcher and Enso Words today. They are now $19.95 each. What’s more, we’ve added a discount for buying both products: people who purchase a second product will be charged $14.95. Personally, we hate it when we go buy a new product and then its price drops the next day and we can’t get that money back. So, we will be refunding the full difference to those who already purchased the software. Our goal is to make usable software that is also affordable.

Second, for those of you who have downloaded and installed Enso Launcher or Enso Words (or both), we issued an update to the software earlier this week. We hope that most of you didn’t even notice it go by. In that update, we fixed a number of bugs, most of which only occurred on a small number of computers. Among the things we fixed were:
(more…)

Posted at 1pm on 2/1/07 | 20 comments

What’s That Music?

We’ve had a number of people ask us what that awesome music is in the background of our demonstration movies. It’s a song called “Chick A Boom” by Mocean Worker. Mocean Worker has long been a favorite at the Humanized office and Chick A Boom has been at the top of Andrew’s list for as long as I’ve known him.

It was with considerable surprise that Mocean Worker gave us permission to use his song. In exchange, we will be working in collaboration with Mocean Worker on a little project for his upcoming album. Stay tuned.

While I’m on the subject of thanking people, there are a couple people and projects that have been extraordinary in helping us get Enso to launch.
(more…)

Posted at 5pm on 1/27/07 | 6 comments

Enso Released: In Memory of Jef Raskin

It all started with one man’s dream for a computer that worked the way people did; a dream for a computer that he could compose music on. That man was Jef Raskin. And the dream became the Macintosh.

Jef never could accept the status quo. When something didn’t make sense to him—whether it was in mathematics, aerodynamics, nursing, or musicology—he pressed until he either understood it, or discovered that it actually didn’t make sense. This is how he was able to formulate the philosophy underlying the orginal Macintosh design: That computers should make tasks easy for people, not the other way around. Jef’s talent was in realizing when something was flawed, challenging it, and inventing something significantly better.

Jef did not dwell in the past; he focused his energy on moving forward. He felt that, while inventing the Macintosh was laudable, there was much work left to be done and many ways to make computers more humane.
(more…)

Posted at 11pm on 1/24/07 | 30 comments

Enso Launch in the Wall Street Journal

Today is a great day for us. We released Enso and ate great Indian food. And, for dessert, the Wall Street Journal’s Walt Mossberg covered it (Enso, not the food). Walt’s video review is below and you can read the full article here.




Please note: Since January 15, 2008, all Enso products have been free. To get the latest version of Enso, free of charge, see the main Enso page.

Posted at 11pm on 1/24/07 | 6 comments

Enso Trailer

Watch the Enso TrailerWe’ve been quiet, at Humanized. Too quiet. That’s about to change.

For the last year-and-a-half we’ve been working on a piece of software we think will change the way we use computers. Now we are weeks away from its debut. We call it Enso.

Enso is a new idea in computing that brings true universality to interfaces. It makes Windows, and everything in it, more humane. It breaks down the walls of applications. What does that mean? See for yourself. First, read this link then watch the trailer for a sneak preview of Enso.

Are you good at finding bugs? Then there’s barely enough time to sign up for the Enso beta.


Please note: Since January 15, 2008, all Enso products have been free. To get the latest version of Enso, free of charge, see the main Enso page.

Posted at 11am on 1/15/07 | 22 comments

Humanized Interface Puzzler #1

Welcome to the first installment of the Humanized Interface Puzzler. For your fun, bafflement, and desire for free stuff, we’ll pose an interface design puzzler on a semi-regular basis. To enter, simply send your answer to puzzler@humanized.com by the deadline. We’ll select the best answer and post it on our blog. Then, we’ll send the winner a limited-edition* Humanized shirt and entrance to our beta program.

The first puzzler is about modes and cars.

An interface has modes if one gesture can mean different things, depending system state. Modes are at fault when you miss a call because your phones in silent mode. And there’s little worse than having the final bars of Appalachian Spring – with harmonies as delicate as frozen cobwebs – thrashed by a cellphone who’s owner has forgot to put it into silent mode. Perhaps there is something worse: having it be your cellphone. You can read all about modes, modes errors, catastrophic mistakes, and some solutions in our article Visual Feedback: Why Modes Kill.
(more…)

Posted at 3pm on 12/15/06 | 57 comments

Visual Feedback: Why Modes Kill

Let me set the scene. It’s the comedy film “Airplane“. The flight crew is violently ill and Striker, a shell-shocked, former pilot, is forced to land a jet full of passengers in dire need of medical attention. The air is heavy with fog, rain pounds on the cockpit windows. Over the static-filled radio comes the voice of ground control desperately talking Striker through the landing.

Ground Control: The radio is off. Our one hope is to build this man up, I’ve got to give him all the confidence I can. Turns radio on. Striker… Have you ever flown a multi-engine plane before?

Striker: No, never.

Ground Control: Thinking the radio is off. #@&*#! This is a waste of time… there’s no way he can land that plane. Striker starts to tremble.

How did Ground Control make this mistake? The answer is simple. Mode error.

Don Norman defines mode errors as occurring when a user misclassifies a situation resulting in actions which are appropriate for the conception of the situation but inappropriate for the true situation. In Airplane, the action could not have been more inappropriate for the situation.
(more…)

Posted at 7pm on 12/7/06 | 27 comments

Web 2.0: Is Converging Towards the Desktop Good?

I recently had the pleasure of talking at the Ajax Experience in Boston. You can view my power-point-free slides here.

This conference was particularly exciting for Humanized because it was the first time we’ve let Enso outside the office. I think it’s fair to say that the floor required some jaw-scraping after I demonstrated Enso.

But while I met some amazing people at the Ajax Experience and had a exhilarating time, I also discovered a worrying trend: interface design on the web is slowly migrating back towards inhumane desktop paradigms. More and more, people are reimplementing windows, dialog boxes, and tree-list controls instead of brainstorming more humane solutions.

I’m going to make an odd claim: interface toolkits on the web are starting to discourage innovation. In harnessing underlying web technologies in (admittedly) ingenious ways, these toolkits make it too convenient for us to fall back onto the desktop paradigms we know, simply because we aren’t prompted by technical constraints to think of something different.
(more…)

Posted at 1pm on 11/6/06 | 28 comments

Enso Beta: Hints

beta.gif

Applications are like isolated cities, each with its own customs and infrastructure.

Both applications and isolated cities have a lot of needless redundancy. Cities have an excuse: they’re in physically different places and are forced to duplicate a lot of things. Applications don’t have such an excuse—they all share the same hard drive, processor, memory, and operating system. Yet despite such proximity, for the end-user, applications don’t actually have that much in common with one another.

For example, both Microsoft Word and Macromedia Fireworks have spell check, but they work in different ways and include separate dictionaries. On my computer, I counted 7 separate implementations of spell check—all of which work slightly differently—with 7 different lists of every word in English. No wonder I have to upgrade my computer as often as I take out the trash*.
(more…)

Posted at 5pm on 10/2/06 | 21 comments

Monolog Boxes and Transparent Messages

SpellCheckComplete.png

We’ve all seen dialog boxes that look like the picture on the right.

Dialog boxes are bad enough: they pop-up at inconvenient times, they derail our train of thought, and normally we don’t even read them. But this type of dialog box is worse. It’s not even a dialog box. It’s monolog box. There’s nothing one can do with this messages but click “OK”. Or wait and click “OK”. They have, as I’ve explained before, 0% efficiency. Beyond that, monolog boxes can have frightening consequences: because I often use two monitors, I’ve spent panicked seconds thinking I’d lost my work due to a crash… only to discover later that a monolog box had appeared on the other screen and stopped Word from operating normally. Even with a single monitor, you can miss the dialog box, and you’ll have a similar scare.

In the article The Spelling Check is Complete by Jensen Harris (of the Microsoft Office User Experience team) defends the “Word has finished spell check” monolog box shown above, along with the “Word has finished searching your document” box. The Office team had tried removing those documents but discovered that “people who were spell checking their document manually had no idea when the process was complete.” Thus, the monolog boxes were reinstated.

This is classic inside-the-box thinking. The problem is valid: people have trouble knowing the process is complete. But the solution isn’t to use monolog boxes. I can think of two different—and better—solutions. You can probably think of more.

Solution 1: Bypass the problem

Implied in the justification for reinstating the monolog boxes is the false idea that spell check is a fundamentally modal operation. In Jensen’s words:

“Spell check is one of those great features that have a beginning, a middle, and an end. The beginning is you clicking the spell check button. The middle is the computer conversing with you about potential misspelled words and giving you an opportunity to fix them. And the end is the computer telling you that the process is complete.”

But Spell check isn’t necessarily a modal interaction at all. Word’s own spell-check-as-you-type feature is a great example of a non-modal spell check. The text is underlined with a red squiggle: you only need to “converse” with the computer if you decide to fix it. The Gmail spell check, although ever-so-slightly modal, is another example of a spell check that does not require a “conversation”: spell check is done when you are done. Besides obviating monolog boxes, non-modal spell check has another benefit: it isn’t mutually exclusive with writing. If you are correcting a misspelling and you see something else you’d like to change, you can do it without exiting spell check. Your train of thought is never endangered—let’s see the standard Word spell checker and it’s monolog box do that!

Solution 2: Think outside the (dialog) box

If you keep Word’s somewhat antiquated spell check mechanism, then it’s true that the user needs to be informed when Word has finished spell checking. As I’ve explained, a modal monolog boxes are dangerous and inhumane. Luckily, there are many other methods of presenting information that are not modal. In particular there is one we are using in Enso, our upcoming product: transparent messages.

Transparent messages are the brainchild of Jef Raskin. It’s simply a large and translucent message that’s displayed over the contents of your screen. They fade away when the user takes any action (like typing or moving the mouse). In practice, the message is both noticeable yet unobtrusive. And because the message is transparent, you can see what’s beneath it. It’s just humane. Take a look:

Message Log

Transparent messages, however, introduce a problem: messages disappear easily. What happens if the user wants to see what it said? The solution is message log—simply a list of past messages. This way if the user doesn’t have time to read a message, they can go to the message log to view it only if they think it is important enough. And think about it: a message log would be a great thing to have anyway. How many times have you wanted to reference the contents of a dialog box and couldn’t because you had already dismissed it? And how many times have you had to transcribe the contents of a dialog box because the text wasn’t selectable? The lives of users and the lives of tech support staff would be greatly simplified by the addition of a system-wide message log.

On the web

The transparent message also has a place on the web. Web designers have a constant struggle to come up with non-obtrusive means of conveying fleeting feedback to users. For example, validating user input and checking login credentials. It is in instances like this that the transparent message really shines. Give it a try below.

The correct email is trans@parent.com and the correct password is pass. Make sure to play with incorrect login information.

Email

Password


Feel free to nab the source code.

Conclusion

Transparent messages are a simple and elegant solution to a problem that is normally either over-looked or over-engineered. They’re not right for everything, but for messages that need no user interaction, transparent messages are hard to beat: they have an efficiency of 100%.

Plus, they look pretty.

Posted at 2pm on 9/11/06 | 70 comments

Know When to Stop Designing, Quantitatively

Last time, we were talking about convincing the world that interface design is more than hand waving and color preferences by using Math (with a capital “M”). If you haven’t already read that, you should go back and read it now. It’ll give this article some context. And now, we dive in.

Which of the following two sentences contains more information?

1) Cogito ergo sum.
2) Shoes smell bad.

The first represents a foundational building block of Western rationalism, the second is a rather banal (albeit true) thought. The first sentence clearly has more meaning, yet they both contain the same amount of information. Why’s that? Because they both have the same number of letters and use the same alphabet (see note). To get ahead of myself slightly, they both contain they same number of bits of information.

The lesson here is that “meaning” and “information” are distinct concepts. Meaning is something which can’t be quantified, whereas information can. Meaning is subjective, information is objective. So how do you quantify information? In bits.
(more…)

Posted at 4pm on 7/22/06 | 26 comments

Collaboration Made Simple with Bracket Notation

I just had the dubious honor of writing my first patent. It was a laborious and arduous process that I would only force on my best enemies. Luckily I had help from my coworkers. But help meant collaboration, and collaboration meant too many hands in the cookie jar. Edits flew like popcorn kernels on the griddle. It was the stuff project manager nightmares are made of and we needed a robust method of keeping track of comments and edits to combat it.

When writing, I like to keep things simple. And while I don’t go to the extremes of Khoi Vinh’s Blockwriter, I use an editor that can’t even make text bold. When I write, it’s just the raw text and me, mano a mano. By using a bare-bones editor, the text can’t fight dirty by throwing frivolous fonts and formats in my eyes.

Everyone at Humanized writes the same way, so how did we collaboratively write and revise the patent? We couldn’t just edit, because in a patent every change is crucial and must be reviewed. We couldn’t just use standard revision control, because we needed to shoot things back-and-forth across myriad different file formats (we all use different editors). We needed another solution. We needed an elegant solution.
(more…)

Posted at 12pm on 6/30/06 | 55 comments

One Thing at a Time and the Multitasking Myth

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.
(more…)

Posted at 2pm on 6/8/06 | 9 comments

Interface Math

Interface design isn’t about choosing a particularly pleasing color of blue. Nor is it something that can be slapped-on at the end of the product design cycle. For the user, the interface is the product. The technology behind a product is useless if no one can actually use it.

Google has really taken this to heart. Why do people use Google Maps? Because it’s just so nice to use. Microsoft’s Terraserver gave users access to high resolution satellite images many years before Google Maps did the same. (In fact, while attempting to be clever, I inadvertently terrified my to-be roommate: I used the service to view an aerial photograph of his home and asked him some leading questions about the stuff in his backyard. It took until the second quarter of college before he even talked to me, and then only warily.) But, it wasn’t until Google rethought online maps that the security and privacy issues of such a service came into the national conscience. Why? Because whereas Mircorsoft had given access to satellite imagery, Google made them accessible.

“Okay,” you say, “Sounds good. But, how do I convince my clients that there’s more to interface design than just aesthetics and fluffy feelings?” The answer: By using math.
(more…)

Posted at 3pm on 5/12/06 | 6 comments

No More More Pages? Part 2

I recently posted an article called “No More More Pages?“. It argued that the “more” pages used everywhere from Google to Slashdot are a possibly aging technology that might be given a face lift with the new tools available to Web 2.0. In short, it argued, “Don’t force the user to ask for more content: just give it to them“. A number of people wrote some thought provoking comments. This is a response.
(more…)

Posted at 2pm on 5/4/06 | 19 comments

No More More Pages?

Google’s good. But it could be better. Chances are that you’ve done a search where you haven’t found what you’re looking for on the first page. If so, then you’ve had to click on the unhelpfully numbered more-result pages:

google_more.gif
Google's aging links to get more search results.
There’s no semantic meaning in these numbers; there’s no telling what’s lurking behind a representing numeral’s bland exterior. If I find something good on the fourth page, I’ll be unlikely to find it again without aimlessly clicking on random number after random number. Normally, if I don’t find what I want on the first page, I’ll usually just give up.
(more…)

Posted at 1pm on 4/25/06 | 27 comments

MoonEdit to the Rescue

Last summer, before Humanized got started, Andrew, Atul, and I did some consulting work. Andrew and I were in balmy California, while Atul was back in humid Chicago. We were all working on the same project, and we had a big problem: we needed to talk. A lot. About everything: documents that needed commenting and editing, new ideas one of us had brainstormed, what we were going to do the next day, and the weather. Unfortunately, our tools (phones, AIM, email, and a wiki) were inadequate.

Enter MoonEdit.
(more…)

Posted at 3pm on 4/19/06 | 14 comments

Humanized Launches its Website

CHICAGO, IL., 10 Apr, 2006

Monday, April 10, 2006 marked the debut of Humanized’s public website, www.humanized.com, which provides computer users and interface designers alike a resource for finding and understanding humane interfaces.

A key component of this website is the Humanized Weblog, where individuals concerned with making the computer experience better can read and respond to articles covering topics ranging from stoves to voice mail, computer preferences, software development, and more. “The goal of the weblog,” said Vice President Atul Varma, “is threefold: to serve as a place where consumers can come to find usability-oriented product reviews and advice; to serve as a repository where aspiring user interface designers can find educational material on design fundamentals; and lastly, to serve as a forum where user interface professionals can find and contribute to thought-provoking commentary on the state of the field today.”

About Humanized, Inc.

Humanized, Inc. is a small software company based in Chicago, Illinois, dedicated to the promulgation of good human-computer interfaces. Humanized differs from many software companies by focusing on software usability, rather than software features. While the designers at Humanized believe that it is important for products to support the features that users need, they feel that many companies have sacrificed usability in a rush for additional product functionality. As a result, even though a user may know that their computer can do something, actually doing it has become difficult, time-consuming, and error-prone. Accordingly, Humanized believes that good interfaces make computers more pleasant and productive for the people who use them.

Posted at 4pm on 4/10/06 | Comments Off

A Pretty Neat Digital Watch

Douglas Adams’ novel The Hitchhicker’s Guide to the Galaxy starts, “Far out in the uncharted backwaters of the unfashionable end of the Western Spiral arm of the Galaxy lies a small unregarded yellow sun. Orbiting this at a distance of roughly ninety-eight million miles is an utterly insignificant little blue-green planet whose ape-descended life forms are so amazingly primitive that they still think digital watches are a pretty neat idea.”
(more…)

Posted at 12pm on 4/10/06 | 19 comments

The “Over The Phone” Test

Here at Humanized, we use the “Over the Phone” test as a good rule of thumb for interface design.
(more…)

Posted at 1pm on 4/9/06 | 18 comments

Redesigning Stoves

The kitchen is a great place to go bad interface diving. Who can resist taking potshots at undecipherable microwave controls? Do you know how to set its clock? Its power level? I don’t. And I’m not about to dig out the manual with buttered fingers. But today’s dive isn’t about the technological gizmos that we all know complicate our cooking lives. Instead, its about re-evaluating an interface that we all take for granted; an interface that is so ingrained in us that we don’t realize that it’s possible to even think about making it better. Today’s bad interface is The Stove.
(more…)

Posted at 9am on 4/7/06 | 19 comments

Redesigning Volume Buttons, Old Style

I thought it couldn’t get any worse than volume buttons. You know the kind: You get in your car, start it up, and get blasted by a wall of sound. And you continue to be blasted as you frantically search and then mash that tiny button again and again until the radio is once again at a reasonable level.
(more…)

Posted at 12pm on 4/4/06 | 4 comments

Down With Audio Interfaces

voicemail_bad.jpg

I often get asked about the future of interfaces: “Wouldn’t it be great”, people say, “if we could just talk to our computers like in Star Trek? Aren’t voice recognition and talking computers the interface of the future?” A lot of people seem to think that all interface problems can be solved via voice. But I have a one word answer: Voicemail.
(more…)

Posted at 12pm on 4/2/06 | 12 comments

About me...

Aza gave his first talk on user interface at age 10 and got hooked. At 17, he was talking and consulting internationally; at 19, he coauthored a physics textbook because he was too young to buy alcohol; at 21, he started drinking alcohol and co-founded Humanized. Two years later, Aza founded Songza.com, a minimalist music search engine that had over a million song plays during it's first week of operation. After Humanized was sucked into Mozilla, Aza became Head of User Experience for Mozilla Labs. In another life, Aza has done Dark Matter research at both Tokyo University and the University of Chicago, from where he graduated with honors in math and physics. When not working (ha!) Aza enjoys playing music and punning.