I am happy to announce that Tab Candy is coming to Firefox 4. Starting today, Tab Candy will be called Firefox Panorama and be available as a feature in Firefox betas. Head to the Firefox 4 feature list, or watch the video below, to learn how to organize your tabs into groups and reclaim your browsing experience from clutter and information overload.

Like many innovations, the ideas behind Panorama are a mashup of previous work. You can see roots in the Firefox Mobile concept, zooming user interfaces, and virtual desktops.

While there are many directions still left to explore (some of which are covered in the Tab Candy announcement video), there is a strong set of design principle that have and will continue to guide development. We’ve already seen activity from extension authors to extend the capabilities of Panorama, which makes now a perfect time to discuss Panorama’s design principles.

History and Spec

It took 7 months to go from sketches to inclusion in Firefox. In a fast moving project, ideas need to be communicated fluidly. Instead of having specs broken into many smaller documents, we used one massive document to house concepts, specifications, and design decisions. Here it is. There’s a lot to explore in here so enjoy and feel free to ask questions in the comments.

If you want to delve deeper into the inspiration, go back to mid-2008. Below is a concept video for Firefox Mobile that shows a number of the key design principles and concepts that informed the creation of Tab Candy. The second video shows the in-progress design for Panorama from early April.

The Principles of Design

Within the concept of “organizing your online tasks” is a lot room for paradigms, metaphors, and features. We used a set of principles guided by cognitive psychology to create a unified interface we feel is humane and efficient.

Harness the power of spatial memory. Spatial memory is what allows you to navigate back to your house from a new resturant, remember how to get to your bed after you turning off the lights, and knowing exactly where something is on your messy desk. Probably stemming from our hunter-gatherer days, spatial memory is universally strong in everyone: we just remember where things are if they don’t move on us. That’s why in Panorama we are careful to never mess with your organization and layout — it is always the same even after you restart the browser.

The lack of consistent spatial layout is one of the main usability issues with interfaces like Apple’s Exposé. Their shifting layout means it confounds our ability to remember where things were. It messes with our heads and forces us to learn and relearn an ever-modifying map. Imagine how hard it would be to navigate if the city you lived in constantly rearranged itself.

Seeing is remembering. In the cognitive science community we talk about two modes of accessing long term memory (anything longer than a couple seconds): there is recognition and recall. Recall requires first conjuring up a memory, then checking that it is the right memory, and finally doing something with it, while recognition doesn’t require that first costly recall step as it is triggered by seeing something. Recognition-based interfaces are generally less taxing and are more preferable than recall-based interfaces.

This implies that an overview of everything is the right approach to letting you group and organize your online life. One click lets you see all of your tabs just the way there were before, letting your brain use recognition rather than recall. Many past proposed tab-grouping designs fail this principal.

Minimize required interactivity. In other words, don’t make me click. This goes hand-in-hand with recognition versus recall. Instead of using stacks or other occlusive group visualizations we invented a new way of grouping, where tabs in a group shrink to accommodate more tabs. This way, tabs stay in the order and rough location you remember whilst always remaining visible.

Remove distractions: out of sight, out of mind. This is the corollary to seeing is remembering. We, as humans, are bad at multitasking. As practitioners of GTD know, the secret to productivity is removing distractions and focusing. Piles let you visually hide the pages by which you don’t want to be visually distracted, which strategically requires recall-based memory. When you are in a group, you only see the tabs related to the task at hand, again allowing you to focus. Strategic hiding is key to a mind free of info-guilt.

Tangible. A good interface is behaviorally onomatopoeic. Web pages are now physical objects which you can interact with, leading to all sorts of new metaphors for using and sharing the web. For instance, you’ll soon be able to share a webpage directly, instead of sharing the text representation of the URL for the web page, by dragging it to a friend; and move a tab to your mobile device simply by dropping it onto a representation of your phone.

Also, nothing shouts “sexy!” like a gently stylized physics engine and visual momentum. 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.

Speed and Joy. All of the above is moot if the interface doesn’t feel snappy. Down to the distinctive bounce-styled animation, we’ve focused on making Panorama be and feel fast. Similarly, in all of our animations and interactions (like how a group runs away if another group is placed on it) we’ve tried to focus on creating a little bit of whimsy.

Related posts:

1. Tab Candy: Making Firefox Tabs Sweet
2. Firefox 3.1: Control-Tab Woes
3. Firefox Mobile Concept Video

As you can see, I’m linking to the real Google domain and the looks and acts legitimately. The URL looks normal. You can even change the search, say remove “massacre” and Google still doesn’t find anything. Try it with quotes. Remove square. Still no results. The “censorship” certainly feels fairly real, and the hoax would be even harder to detect if if I had said that they were only censoring links from some third party sites.

Now try copying and paste the search to a different search engine. Nothing again. It’s a conspiracy! And look, Digg censors searches for their rival Reddit!

Or how about the government forcing videos from Afghanistan to be removed from YouTube from within the US?

What’s going on?

I’m using a search query that looks like one thing but is, in fact, another. This particular search query uses unicode characters that look identical or similar to normal characters. In this case, I’ve replace one of the “a”s in Tiananmen with look-a-like character from the Cyrillic alphabet. Nobody uses such a tampered string when writing about Tiananmen Square so Google naturally doesn’t find any results. Hence, it looks like they are censoring. As long as you don’t delete the entire query and start again, modifying the query in place will continue returning results that appear “censored”.

In effect, this is taking the old phishing trick of homoglyph attacks—an attack consisting of using confusing look-a-like URLs like paypa1.com with the numeral one replacing the letter ell—and adding a dash of cross-site scripting but where you become the agent of infection: the supposed “censorship” may be shocking enough to cause you to forward the link. You can find a list of look-a-like characters here.

Using this technique you can create viral links showing that Bing censors BP oil spill images, or that Techcrunch has never used the word perfect. With a mischievous eye, these kinds of searches might well cause damage. Someone will figure it out eventually, but probably not before the PR damage is already done.

Being #1 In Google. The Easy Way

Another way to take advantage of this hack is to easily appear to be the first hit for any term in Google.

Step 1: Decide on the term you want to own. Say “Used Cars”. Now perform the homoglyph substitution. When you search for the tampered phrase, you should get no results.

Step 2: Use the tampered phrase on the site you want to appear as #1.

Step 3: Make a set of throw-away web sites that mirror your competitors sites that all use the tampered phrase and have them link to the site you want to be #1.

Step 4: To prove that you are the most reputable used car site on the web, just link people to the Google search for the tampered phrase. The page will list you at the top for the phrase “used cars” with all of your “competitors” ranked below you.

Step 5: Congrats. You can now control any search engine’s search page, as long as you provide the link.

Mirror Character

I stumbled on this technique through an exploration of the unicode “mirror” character, which reverses the direction of all text after it. Doing a search for “‮” seemingly breaks Google. Going a step further, you can write your queries backwards with the mirror character at its front, making it look normal and also yield no results. When I tried this particular technique on my Twitter following most of them figured that something strange was going on based on strange interaction experience and odd search results. The unicode homoglyph method does not suffer from these issues.

Search engines could nullify this attack vector by watching for such strange homoglyph characters in the middle of normal words and quietly swap them back.

No related posts.

The power of the browser has grown substantially in the last ten years. We now use the Web to multi-task the activities we juggle every day, like vacation plans, purchases, sharing pictures, listening to music, reading email, and writing a blog post.

It’s hard to keep everything straight with dozens of tabs all crammed into a little strip along the top of your browser. Your tab with a search to find a pizza parlor gets mixed up with your tabs on your favorite band. Often, it’s easier to open a new tab than to try to find the open tab you already have. Worse, how many of us keep tabs open as reminders of something we want to do or read later? We’re all suffering from infoguilt.

We need a way to organize browsing, to see all of our tabs at once, and focus on the task at hand. In short, we need a way to get back control of our online lives.

Enter: Tab Candy.

With one keystroke Tab Candy shows an overview of all tabs to allow you to quickly locate and switch between them. Tab Candy also lets you group tabs to organize your work flow. You can create a group for your vacation, work, recipes, games and social sites, however it makes sense to you to group tabs. When you switch to a grouped tab only the relevant tabs are shown in the tab bar, which helps you focus on what you want.

Link to the video here or download the video here.

One more thing. Tab Candy is made entirely with HTML, Javascript, and CSS. There is no native code—just the open Web. That is how powerful the web has become.

Tab Candy is in early development. We’re at the point where we’d like more people to try it out and let us know what they think. There’s work to be done on some existing bugs and performance issues, and we’re building a motivated group to attack those issues head-on.

This is not an extension. This is a super-early build of Firefox with Tab Candy enabled.

A Walkthrough of Tab Candy’s Features

Instant Overview—Never lose a tab again

Tap Option-Space on the Mac or Control-Space on Windows to zoom out and see thumbnails of all open tabs. Click on one to zoom back in. It’s a quick visual way to search for that one tab you need with work research or directions to the restaurant.

Lightweight Grouping

Drag two tabs together to create a group to keep related tabs together. You can even name groups for all your videos, research, social sites or whatever you need. If need a group from one tab just click and drag to create one. You can easily rearrange tabs and drag them anywhere inside a group or between groups.

Right now there is no automatic grouping, but it is a feature we are working to deliver.

Only the Tabs You Want

When you go to a tab in a group, you’ll only see the tabs from that group in the tab strip. That means you can focus on the task you are doing. Work tabs stay separate from play tabs. Clean tab bar, clean mind.

Organize Your Space

Tab Candy is not just the ability to move tabs around, you can move groups so that they fit your needs. Make the group with your calendar and email bigger so that you can see what’s new just by zooming out to Tab Candy. Hide the group with distractions in a corner. Keep things to read in a long vertical list. Because Tab Candy is in early development, there are lots of user experience changes and bugs to fix. We want your feedback. While Tab Candy is fairly stable, it might still lose your groupings or cause Firefox to operate more slowly.

Next Steps

Our current goals are focused on overall and start-up performance, unit tests, code documentation and refactoring. Next, we will focus on user feedback and polishing the user experience.

The Tab Candy team is working to get Tab Candy into nightly development builds of Firefox. You can follow along as we work to improve the code.

Get Involved

Start by reading the Tab Candy FAQ.

* Visit the project page or the project wiki
* Give us feedback
* Submit a bug report and see what bugs need to be fixed
* Grab the source code and get a walkthrough of the code
* Download a Tab Candy-enabled build

Related posts:

1. Firefox Panorama: Tab Candy Evolved
2. Firefox.next: Tabs on the side?
3. Firefox 3.1 Proposal: Tabs in the Awesome Bar

The Good

Using CSS to obfuscate HTML can be used to protect your email address in a quick-as-you-type way. No need for unwieldy inline images or arcane Javascript functions. For example, here’s my email address:

azSPAMa@moREMOVEzilla.com This email address cannot be copy and pasted. Try it.

Notice that it appears to be in normal, selectable text. Don’t be fooled by appearances. Copy and paste it. You’ll get the following: azSPAMa@moREMOVEzilla.com, which is easy for a human to fix but difficult for a bot. How does it work? Here’s the sample code:

<style>
.z{
  float:right;
  font-size:.001px;
  color:transparent;
  display:inline-block;
  width:0px;
  }
</style>

...

az<span class="z">SPAM</span>a@mo<span class="z">
REMOVETHIS</span>zill<span class="y">a.c</span>om

This takes anything marked with the class z and visually hides it, leaving only the email address rendered as if nothing was amiss. When you go to copy my email address, however, the browser doesn’t see the garbage text as hidden and so it gets selected along with my email address. This is the same way that your DNA protects itself, by hiding the real information in a huge amount of noise. It would be difficult for a scraper to even know that there was an email address there, let alone implement a program that understands CSS well enough to parse it out: there are a semi-infinite number of ways to use CSS to make text visually disappear. If you wanted to get really tricky, you can add multiple classes to each little span; because CSS cascades and inherits it becomes very hard to know, without just looking at the results, what the text will end up saying.

Foiling spammers with a bit of their own medicine brings a smile to my lips.

The Bad & Evil

Besides spammers using this trick to get around your Bayesian spam filters, there are other bad things for which this can be used. This first is for that misguided holy-grail of publishers: copy-protection for their words. A publisher could generate, on the server side, a new random mess of HTML and CSS that would render their text uncopyable. This also has the side-effect of making your pages impossible for search engines to index sensibly; it’s an easy way to keep your information human-readable but cloaked from Google’s all-seeing Sauronic eye.

Here’s a simplified example of how a publisher might use this:

mTheIismM trpexsmt aEiscy uexnc nopiNyanxblaie.vk KnAeiLAthev Roaup zerant dwMutnrde.oc‘mh eswaaIs svbo LrnsB inyn .MehMlbilou Crnnae wGineo 1gx93 z1.oC Advt vothlae pBtiavmefI, rGhi rs fkfaizthsherld, nGKetxitarh MMuourdlyoc rh,es wdkasle avE rryegdlioblna ml iFnelzwsTEpaaqpe ar eomaezgnrvathbe robaBfseasd cmou yt aIof P MizelrwbopIursOneih a vndhO ayNs rIa Hrel.suoPltun tiphegt ftnameGilrLy kvwaozs lMwedfalevthtMy. n Reeupeuerost fwa hs oAgrmdooomme Ed npbyul hisis F fhwattFhecHr uzfrdAombM a Jn eneaiqrleOy eMag ze,yp apwndlx w.venest msofrof sptoaL scatueudy b piGhinploaasovqphnFy,Ld peNolotit Micads dkant d etec‘LoneHomazicsas natsp Onyxf .orhrd ieUn civnPerwksieytygF i vn owEndnglvcanlcd.p

The other evil thing this could be used for is phishing attacks. Sometimes you run across a URL unlinked on a web page. To go there, you copy and paste it into your location bar. In fact, we are often told that the only way to really trust a website’s location is to put it there yourself. Try copy and pasting this URL into your location bar:

http://facebook.com.evil.comThis URL will phish you if copy-and-pasted into the location bar.

While you think you copied one url, it directs you to an entirely different, evil URL. While this particular example is easy to detect for pedagogical reasons, you can use all of the standard phishing methods of disguising a URL to make it look more legitimate.

Brainstorm

I’m sure there are other good and bad things you can do with this technique—these are the ones I came up with in a couple minutes. What are your ideas?

No related posts.

How Do CSS Transitions Work?

Normally, when you change the value of a CSS property, it changes instantly. With CSS Transitions, they automagically animate over time. Imagine you want to have a rollover indication for links where, on hover, the link changes its background color and jigs up a bit. With CSS Transitions instead of having the effect happen instantly, it can smoothly animated. Here’s how you’d do it.

a{
  transition-property: all;
  transition-duration: 350ms;
  transition-timing-function: ease-in-out;
  position: relative;
  background-color: white;
  color: black;
}

a:hover{
  top: -2px
  background-color: black;
  color: white;
}

You can even add an event listener to detect when the transition has finished:

aLink.addEventListener("transitionend", function(){
  console.log("Transition Done!");
}, true);

Timing functions are defined by the control points for a cubic bezier curve of the form cubic-bezier(x1,y1,x2,y2). You can see some of the named timing functions and their values below. You can also define your own timing functions:

/* A more pronounced ease-in-out timing function. */
transition-timing-function: cubic-bezier(0.6, 0, 0.4, 1.0);

/* A timing function which causes a little bounce.
   Note that values above 1 only work in Firefox. */
transition-timing-function: cubic-bezier(0, 0.35, .5, 1.3);

Using CSS Transitions with jQuery

To use CSS Transitions in practice, you’ll want some helper functions to handle setting and and unsetting the transition properties, handling completion callback, and stopping animations. Towards that end, I’ve written a quick jQuery plugin that allows you to do just that (as well as deals with an annoying Firefox bug.)

Using it is simple:

// Makes all paragraph elements grow a border and then atrophy away.
$("p").animateWithCSS(
  {border: "5px solid #555"}, // CSS properties to animate
  1000,                       // Duration in ms
  "cubic-bezier",             // The timing function
  function(){                 // Callback
    $("p").animateWithCSS({border: "0px"}, 350);
  }
);

Get the CSS Transitions jQuery Plugin.

Demo

Get the CSS Transitions jQuery Plugin.

Problems with CSS Transitions

Better timing functions. While using a cubic bezier curve is clever—it packs a lot of variation into just four numbers—it isn’t enough. While I was able to create a basic bounce animation, not only does the spec explicitly disallow it, but I can’t control even the basic parameters of the bounce (like how fast it returns). As John Resig mentioned in a blog post, it would be nice to supply a custom Javascript timing function (although this might break the ability to do hardware acceleration). A more CSS-like solution might be to allow authors to provide an arbitrary number of control points for a series of linked quadratic or cubic bezier curves (and to not restrict the y-axis points to the 0 to 1 range). That would enable fine-grained control of timing without requiring Javascript.

Ability to layer two animations on top of each other. If I’ve started an animation moving an element to the left, and half-way through want to start animating its opacity at a different rate, things get complicated very quickly. And by complicated, I mean impossible.

Ability to register an on step handler. We can currently register a “transitionend” event handler. I’d like to be able to do the same for “transitionstep”. This would make CSS Transitions potentially much more versatile—and allow frameworks to keep innovating on top of the transitions base instead of reverting to pure Javascript animation.

No related posts.

I was recently looking at some of my father’s, Jef Raskin, old documents and came across his February 16, 1981 memo detailing the genesis of the Macintosh. It was written in reaction to Steve Jobs taking over managing hardware development. Reading through it, I was struck by a number of the core principals Apple holds now that were set in play three years before the Macintosh was released. Much of this is particularly apropos in understanding Apple’s culture and why we have the walled-garden experience of the iPhone/iPad and the App Store.

Even better, I found some sometimes-snarky annotated comments Jef made to the memo as part of the Stanford Computer History project. The annotated memo follows my commentary.

Apple Learns to Own the Entire Experience

We see that Apple was struggling with an explosion of fragmentation with the Apple II: “it is impossible to write a program on the Apple II or III that will draw a high-resolution circle since the aspect ratio and linearity of the customer’s TV or monitor is unknown.” This is the exact problem that Google Android now faces. The revolutionary idea back in 1981, even to Apple, was to throw away the Apple II’s corner-stone expandability in exchange for owning the experience from top to bottom. “The secret of mass marketing of software is having a very large and extremely uniform hardware/software base.”

To combat fragmentation, for the Macintosh “[t]here were to be no peripheral slots so that customers never had to see the inside of the machine (although external ports would be provided); there was a fixed memory size so that all applications would run on all Macintoshes; the screen, keyboard, and mass storage device (and, we hoped, a printer) were to be built in so that the customer got a truly complete system, and so that we could control the appearance of characters and graphics.”

We also see Jef articulating and forming Apple’s nascent core principle of innovation being prioritized over backwards compatibility. “The Apple II/III system is already lost. We cannot go back and simplify, we can only go forward.” This became a key differentiator to Microsoft’s no-matter-what policty of maintaining backwards compatibility. Apple willingness to ditch the old for innovation as left it nimble and able to over come the innovator’s dilemma.

Interesting Sound-bytes

• “Another key concept is ‘think small’. We have not begun to reach the limits of what can be done with 64K bytes of memory and a single mass storage device. It is important to hold to these limitations in order to keep the project from burgeoning into a huge, expensive and time consuming effort.“
• “In my first conversations with Steve Jobs and Steve Wozniak, back in the garage that was the original location of Apple, I argued that the Apple I (and later, the II) needed upper- and lowercase on both keyboard and screen. At the time they disagreed rather strongly–a position they now somewhat regret having taken. “
• “It does not take much imagination to see that a portable computer will open up entire new application areas, and once again give Apple access to totally untapped, yet ripe, market.“
• “Having been associated with PARC, I repeatedly called Apple’s attention to the kind of thinking going on there, and it was gratifying that the company took note of and eventually based a lot of the LISA software on the published work done at PARC.“
• We see that the ideas behind universal-access computing, like Ubiquity or Enso or the Services Menu, are already in place: “The original concept gave the word processing program access to calculator ability without having to leave the word processing environment. Studies have shown that having a multiple level system is more confusing than a single level system.” The iPhone in particular suffers greatly from this problem.

The Original Document

The Genesis and History of the Macintosh Project

by Jef Raskin, 16 Feb 1981

Introduction

I joined Apple Computer as a consultant in 1976, to write the Integer BASIC manual, and then as a manager of the Publications department. Since then I started and managed the New Product Review and Applications Software departments. These departments are now scattered among our various divisions.

The Background of the Design

Writing manuals is a very special and privileged task in a computer company, for in the process of writing them you are forced to go over every detail of the hardware and software the company sells in an attempt to make it understandable and usable in our extremely broad customer base. In the process a consciencious writer will discover nearly every good and bad feature of the system, and can provide valuable feedback to the designers and implementers.

It became very clear to me that Apple’s products were, in many ways, difficult machines to explain to customers. For example to quote Brian Howard’s wonderful memo “Too many variations on a theme” (30 June 1980):

In writing [a manual] I have, once again, come across an exasperating problem: just what IS an “Apple Computer”? Apple now comes in a bewildering variety of flavors.

He then points out that an Apple II behaves differently depending on what peripherals are inserted, what ROMs are on the main board, what PROMs are on the disk controller, how much RAM is installed, which keyboard is supplied, and so on. After a carefully detailed and specific list of problems, he concluded with this remark:

The question is, for example what Apple, or which of the possible Apples, do we describe procedures in our manuals? Are we going to have twelve footnotes after every mention of the RESET key?… Will every writer be provided with not one, but seven or a dozen Apple systems to that descriptions of each procedure can be tested against the actual behavior every user may experience?…

In our present context the question is, how can a naive customer deal with such a system? The answer is that he or she cannot. Even the manuals for just one sub-system, the language card, themselves require a manual to act as a roadmap to the other manuals! From this viewpoint, the Apple II/III system is already lost. We cannot go back and simplify, we can only go forward.

Considerations such as these led me to conceive the basic architecture and guiding principles of the Macintosh project. There were to be no peripheral slots so that customers never had to see the inside of the machine (although external ports would be provided); there was a fixed memory size so that all applications would run on all Macintoshes; the screen, keyboard, and mass storage device (and, we hoped, a printer) were to be built in so that the customer got a truly complete system, and so that we could control the appearance of characters and graphics.

This item of controlling appearance is quite significant: for example it is impossible to write a program on the Apple II or III that will draw a high-resolution circle since the aspect ratio and linearity of the customer’s TV or monitor is unknown. You can probably promise a closed curve, but not much more. You cannot promise readable characters, either. Therefore, a predictable, documentable system must be entirely under Apple’s control. LISA is Apple’s first system to allow us to design in context, without depending on chance for the all-important visual aspects of the computer’s output.

At the time I was trying to start this project there was a growing feeling within the company that we needed a lower-cost product than the Apple II. I was originally requested to design a machine that would sell for under $500. Even hasty estimation of the cost of any practical (non-toy) system showed that goal to be unrealistic, and a new goal of $1000 was settled on. Such a goal was feasible, but the company’s insistence on a number of features, such as restricting the choice of mass storage to a floppy disk rather than some slightly riskier but potentially less expensive possibilities, led to a system that will probably be offered to our customers for around $1500. Note that this leaves room for a truly low-cost system design at some future date.

In my first conversations with Steve Jobs and Steve Wozniak, back in the garage that was the original location of Apple, I argued that the Apple I (and later, the II) needed upper- and lowercase on both keyboard and screen. At the time they disagreed rather strongly–a position they now somewhat regret having taken. Similarly, when I first proposed the Macintosh architecture to the company there was strong opposition, from many levels, to the hardware and software concepts behind the machine. It is to this company’s credit that they tolerated these disagreements from the beginning*, and that they had enough faith in me to give me some resources with which to pursue the design to the point where it had n opportunity to prove itself.

I am honored that the company should choose to put my concepts into practice as a product.

With its excellent character display (25 lines of 96 characters each) Macintosh is a natural for word processing. Given its low cost and small size it will carry word processing into areas that it was not possible to sell to with larger and more expensive equipment. If a truly portable version is produced, then an entire realm of new application areas opens up. As one small example, consider the difficulty of supplying a classroom with conventional personal computers–the problem of power cords alone is enough to be discouraging, since rooms must be specially prepared to put a computer on each desk. It does not take much imagination to see that a portable computer will open up entire new application areas, and once again give Apple access to totally untapped, yet ripe, market.

The original concept gave the word processing program access to calculator ability without having to leave the word processing environment. Studies have shown that having a multiple level system is more confusing than a single level system. IBM’s Displaywriter has a similar but more primitive facility. This opens the way to office computation applications, and a further enhancement was proposed (at the instigation of Steve Jobs*) to give the editor abilities similar to Personal Software’s Visicalc, except that the facilities would be embedded in the editor so that no file shifting would have to take place to use Visicalc results in a document or vice versa**.

A third application area is seen in the field of distributed data bases and personal communications. Access to a wide range of data bases could be implemented by providing a common interface and billing procedure to a number of separate commercial data services. Personal communications could be improved by a message forwarding system implemented on the user’s own computer (the “completely distributed network” concept) without having to have any central computers at all.

These applications alone could result in a very high level of sales.

The Evolution of the Hardware

From the first, considerations of cost and size restricted us to a black-and-white screen. Initial mock-ups showed that a complete system in a single package could be made small enough to fit under an airline seat, and since it was self-contained could be truly portable. Power consumption estimates showed that battery power was a possibility, although at a 2.5 kilo weight penalty. One interesting feature was the concept of a “bus diagnostic port” which would allow dealers to merely plug an Apple II (or perhaps another Macintosh) in to more thoroughly diagnose an ailing machine than would be possible with built-in diagnostics. Such a port would also allow attachment of high-speed peripherals such as a hard disk.

Another key concept is “think small”. We have not begun to reach the limits of what can be done with 64K bytes of memory and a single mass storage device. It is important to hold to these limitations in order to keep the project from burgeoning into a huge, expensive and time consuming effort.

The original processor was the 6809E, but when Burrell Smith showed how a single row of RAM could be used efficiently with the 6800 processor, the machine was redesigned so that we could share the processor and much development software with the LISA project. This increased the speed of Macintosh system development, and allows us to leverage our software expertise across a range of products, much as the common 6502 basis of the Apple II/III unifies that family of machines.

The screen resolution is 384 dots across by 256 dots vertically, which is close enough to the TV standard 4:3 aspect ratio so that little screen space is wasted if the monitor is adjusted so that dots are on a square grid. Human factors considerations shows that the ideal size of such a screen is very close to the viewing area of a standard 9″ television CRT. Bandwidth considerations limited the 6809-based system to 256 by 256 dots, which would have been optimally displayed on a 7″ tube.

With a special font developed for the project, an average of 2400 easily read characters can be placed on the screen, on 25 lines of typically 96 characters each (the font, except for numbers, is proportionally spaced). This makes it very suitable for word-processing. The entire screen can update in about .3 seconds.

The keyboard’s design is based on office typewriter layout, with the backspace moved to a much more convenient location since it is so often used in word processing. The company is considering making the keyboard design standard across a number of present and future products–which would, in the long run, prove effective from many points of view such as cost, user acceptance, ease of documentation and uniformity of software design*.

Software

The design of the software, like the design of the hardware, stems from the immense frustration inherent in trying to work with existing computer systems. The best of these is probably the Alto hardware and software available at Xerox’s Palo Alto Research Center (PARC). Having been associated with PARC, I repeatedly called Apple’s attention to the kind of thinking going on there, and it was gratifying that the company took note of and eventually based a lot of the LISA software on the published work done at PARC.

My concepts in designing the software were extreme ease of learning, rapid (and thus non-frustrating) response to user desires, and compact and quickly developable software. Key elements in designing such a system are freedom from modes, the elimination of “levels” (eg. system level, editor level, programming level), and repeated use of a few and consistent and easily learned concepts. Such software also leads to simple and brief manuals without having to sacrifice completeness and accuracy.

The editor is similar to the LISA editor (and thus is similar to PARC’s) but does not require the expensive mouse. A careful study shoed that it is probably faster to use than a mouse-driven editor–although it is probably not as flashy to see when demonstrated in a dealer’s showroom. A calculator-like facility is accessible from the editor, as is the ability to link quantities within a document which gives the user an ability similar to that of Visicalc.

The calculator is modeled somewhat on programmable calculators and thus allows some programming to be done by the user, without having to learn a programming language. It goes beyond the programmable calculator in that the user can work with a collection of numbers (such as a price list) as easily as with a single quantity. Fortunately, a long existing language, APL, as shown how this may be done so that little new work is required.

The editor can also receive and send text to external devices, including auto-answer/auto-dial modem or a printer. In conjunction with real-time clock it can do schedule reminding as well as automatic call-forwarding and receiving.

Summary and Future Directions

Macintosh is designed as a stable base for our low-end product line. By limiting expandability we will have a product that will be free to grow to new heights of mass-marketing–for which it is essential that all Macintoshs be identical (the secret of mass marketing of software is having a very large and extremely uniform hardware/software base).

While it seems that current production plans for Macintosh may violate some of the basic principles outlined here, Mike Scott and Steve Jobs have agreed (in the Apple sprit of leading technology instead of following it) that I will continue designing and implementing the software design to the point of being able to demonstrate some of the software concepts discussed here so that the company can evaluate them.

No related posts.

While the full-depth of understanding design cannot be covered in a short article, here are some guidelines to help you out.

To get you started, here is an example of a critique I recently did of the interface for the yet-to-be-released Add-On Builder* for Firefox. The Add-On Builder is part of the Jetpack project and is a web-app of medium complexity that allows you to easily build Firefox and Thunderbird extensions online and then publish them to the world. I took screenshots of each screen of the interface, put them into one large document, and commented ex vivo.

When are you critiquing?

The first factor in how you critique is determined by when you are giving it. If you are reviewing an interface just before a product or website launches, there won’t be enough time for your feedback to have a big effect and you’ll have to give smaller-scale suggestions. The earlier you can review the product, the more impact your words will have.

The User’s Train of Thought is Sacred

Look for things that break the users train of thought: any time they have to think about how to use your product and not what they are doing, your interface is frustrating them. Modal dialog boxes, confirmations, settings screens, anything that requires them to think about more than one thing simultaneously, and filling out unnecessary forms before being are allowed to enter the site, etc. All of these things get in the way of the user actually using your product.

Reduce Interaction

The goal of interface design is to get rid of the interface. While interfaces with lots of interaction can look snazzy, you’ll have fewer usability issues when you minimize the amount of work someone has to do to use your product. You know those news sites where the articles are paginated into tiny chunks so that you keep having to hit “next” just to wait for dozens of ads to load? If you are like most people, you hate them and often never finish reading the article. That’s interaction overload at work.

Think long and hard about every little step a person has to do to use your product. Write them out. If you get fatigued, you know you need to simplify.

Visual Placement Matters

Make sure that your buttons, links, and actions are logically grouped. Often you will see interfaces with “save” right next to “close”, meaning a little user mistake can cause dire repercussions.

Beware Too Many Icons

Icons can be difficult to understand, even while they look pretty. Users often have to hover over an icon each time they want to use it to discover what it means. Instead of using an esoteric hieroglyph, use text to say what you mean.

Give a Good Starting Point and Keep Consistent

The best interfaces are incrementally learnable: you shouldn’t have to tackle a fifteen-minute seminar before you can do a basic task—you should be able to just learn the one thing you need to do and be on your way. Does your product give a good indication of where and how to start? And is what you’ve learned should be applicable in helping you learn the next thing. Keep the mechanisms simple and the metaphors consistent.

Fewer choices mean fewer worries

Try to avoid burdening your users with choices on how to perform an action. Giving them lots of options may seem like a good idea but it isn’t. It ends up bloating an interface and burdening your users with decisions they shouldn’t have to make. If you see more than one way to do something, ask the designer to take the time to make one simple mechanism that the user can use for all their purposes. Don’t just dump an indecision into a preference. The less burdened a user’s mind is with irrelevant decisions, the more clear their mind is to accomplish what they need to get done.

Look is Important. Interaction is More Important

The look of a product often gets much more attention than the “how” of a product. Avoid the trap of spending the bulk of the time on look: it’s like rearranging the chairs in the Hindenburg. Look is much easier to change and polish, and it is much more apparent when something is broken. Interaction is the heart of your product—spend all of your time making it act right and at the end make it look right.

More

For more information continue reading this blog or the following books and blogs:

• The Humane Interface by Jef Raskin
• First Principles of Interaction Design by Bruce Tognazzini*
• 10 Heuristics by Jakob Nielsen*
• The Design of Everyday Things by Don Norman
• Understanding Comics by Scott McCloud
• The Resonant Interface by Steven Heim
• Don’t Make Me Think by Steve Krug

For the designers out there, what resources would you recommend? If you’ve got some I’ve undoubtedly missed, please leave your suggestions in a comment.

Related posts:

1. Interface Math

Most phishing attacks depend on an original deception. If you detect that you are at the wrong URL, or that something is amiss on a page, the chase is up. You’ve escaped the attackers. In fact, the time that wary people are most wary is exactly when they first navigate to a site.

What we don’t expect is that a page we’ve been looking at will change behind our backs, when we aren’t looking. That’ll catch us by surprise.

How The Attack Works

1. A user navigates to your normal looking site.
2. You detect when the page has lost its focus and hasn’t been interacted with for a while.
3. Replace the favicon with the Gmail favicon, the title with “Gmail: Email from Google”, and the page with a Gmail login look-a-like. This can all be done with just a little bit of Javascript that takes place instantly.
4. As the user scans their many open tabs, the favicon and title act as a strong visual cue—memory is malleable and moldable and the user will most likely simply think they left a Gmail tab open. When they click back to the fake Gmail tab, they’ll see the standard Gmail login page, assume they’ve been logged out, and provide their credentials to log in. The attack preys on the perceived immutability of tabs.
5. After the user has entered their login information and you’ve sent it back to your server, you redirect them to Gmail. Because they were never logged out in the first place, it will appear as if the login was successful.

I dub this new type of phishing attack “tabnabbing”.

Targeted Attacks

There are many ways to potentially improve the efficacy of this attack.

Using my CSS history miner you can detect which site a visitor uses and then attack that site (although this is no longer possible in Firefox betas). For example, you can detect if a visitor is a Facebook user, Citibank user, Twitter user, etc., and then switch the page to the appropriate login screen and favicon on demand.

Even more deviously, there are various methods to know whether a user is currently logged into a service. These methods range from timing attacks on image loads, to seeing where errors occur when you load an HTML webpage in a script tag*. Once you know what services a user is currently logged in to, the attack becomes even more effective.

You can make this attack even more effective by changing the copy: Instead of having just a login screen, you can mention that the session has timed out and the user needs to re-authenticate. This happens often on bank websites, which makes them even more susceptible to this kind of attack.

Attack Vector

Every time you include a third-party script on your page, or a Flash widget, you leave yourself wide open for an evil doer to use your website as a staging ground for this kind of attack. If you are the evil doer, you can have this behavior only occur once in a while, and only if the user uses a targeted service. In other words, it could be hard to detect.

You can also use a cross-site scripting vulnerabilities to force the attack to be performed by other websites. And for browsers that do not support changing the favicon, you can use a location.assign call to navigate the page to a controlled domain with the correct favicon. As long as the user wasn’t looking at the tab when the refresh occurred (which they won’t be), they’ll have no idea what hit them. Combine this with look-alike Unicode domain names and even the most savvy user will have trouble detecting anything is amiss.

Try it Out

You can try it out on this very website (it works in all major browsers). Click away to another tab for at least five seconds. Flip to another tab. Do whatever. Then come back to this tab.

It’s hard to find, isn’t it? It looks exactly like Gmail. I was lazy and took a screenshot of Gmail which loads slowly. It would be better to recreate the page in HTML.

Update: Many people have reported that the attack doesn’t change the favicon in Chrome. This was due to a bug in Chrome which has been fixed in the version 6.0.408.1. Chrome is fully susceptible to this attack.

You can get the source code here: bgattack.js.

The Fix

This kind of attack once again shows how important our work is on the Firefox Account Manager to keep our users safe. User names and passwords are not a secure method of doing authentication; it’s time for the browser to take a more active role in being your smart user agent; one that knows who you are and keeps your identity, information, and credentials safe.

No related posts.

Switching between applications, windows, and tabs is a fundamental action of modern computers. As people browse the web, we know that an average user will switch tabs more times in a day than they click on a link. Think about that. Much of your time using a modern browser (computer) is spent in the digital equivalent of shuffling papers.

Every major OS provides an “alt-tab” interface: a keyboard shortcut for quickly switching between windows and applications. To use it, you tap alt-tab and you are jumped back to the last focused window. Tap multiple times to cycle through all open applications. It seems simple enough, but there’s a interface gorilla in the room: What order should the applications be shown and cycled through?

What order should command-tab interfaces display for switching between applications?

Throughout this blog post, I’ll refer to the problem as switching between applications using alt-tab (PC) and command-tab (Mac), but the thinking applies just as well to tabs in Firefox—it is something we have been thinking a lot about recently. More on that later.

The standard method is to use MRU (Most Recently Used) order: the applications are arranged in the order in which they were last used. This works great for switching back-and-forth between two apps, which is a very common task. Unfortunately, that’s most of what it is good for. People have a strong spatial memory and the constant seethings of MRU confound it. If you need to switch between three windows (another common task), you are out of luck because MRU frustrates your natural tendency to form habits. Here’s a situation that comes up often in user testing:

You’ve been using alt-tab to bounce back-and-forth between your text editor and your web browser—you’ve formed a habit. You now click over to your Twitter client to see your friend’s latest updates, click back to your text editor, type a few sentences and hit alt-tab. What happens? Because of your habit, you expect it to go to your web browser, but because the last used application was your Twitter client, that’s where it switches. That’s most likely not what you wanted. What happens next? You generally pause to think, and then use double alt-tab to switch where you wanted to go, which is your web browser. Then you hit alt-tab to switch back to your editor (habit!) and instead it goes back to Twitter. The troubled cycle repeats until MRU’s ordered once again aligns with your habit.

The constantly shifting positions means that the pattern of tapping alt-tab to switch to the window you desire becomes unpredictable. Thinking about how to switch tabs rips your attention from completing your task and put it squarely on using the computer.

Instead of MRU ordering, we could use a static ordering dictated by when the applications were opened. This works well with spatial memory as applications are exactly where you left them, but it entirely ignores the need to quick-switch between two apps.

That’s where we’ve been stuck for the last twenty years, using the MRU ordering despite its flaws because switching back-and-forth between two applications is such a powerful need.

A Better Way

The biggest problem with MRU is that it breaks habituation. This solution is focused around keeping alt-tab from frustrating our habits: if you’ve been switching between two applications constantly, when you then switch to a third application, it shouldn’t change the behavior of alt-tab between those original two apps. The system should detect your habits and respect them. In the above case, the ordering would always keep the web browser and text editor next to each other, once the habit was formed.

This kind of interface is a habit respecting design and I dub it HRMRU order or Habit Respecting Most Recently Used order. With it, alt-tab would switch to an interface that seems to magically know what you want: hitting alt-tab almost always takes you were you want to go.

How do you detect habits?

The complexity in this design stems from knowing when a habit has been formed. The problem gets even more complex if there are two conflicting sets of habits (e.g., you switch between TextMate and Firefox a lot, and between Firefox and Tweetie a lot).

Detecting a habit is heuristic task and would take tweaking to get right. The heuristic metric I’d start with would depend on frecency (frequency + recency): the more often you make a particular switch the more likely it is you have a formed a habit, the less recent the particular switch the less likely it is to still be a habit. In other words, frequency would boost a “habit” score which would then decay over time.

In the case of overlapping habits, the interface should choose one (the more frecent diad) and stick with it. That promotes the habituation so your fingers can, over time, learn with for which app pairs to tap tab and for which to double-tap tab.

A Crazy Thought

Here’s a crazy thought. App switching can be be modeled with a Markov model. Why not crunch the numbers in real-time and use the output of the Markov model to determine to which app you are most likely to switch? It’s really just a generalization of the above idea. You could actually take it a step further further and use the Markov model to find the sets of apps you switch between often, thereby allowing the computer to automatically detect the workspaces you make ad-hoc simply by watching how you switch between apps.

While there are well-known issues with adaptive interfaces, if you followed the same guidelines above to make it a habit-respecting adaptive interface, we might get an interface that seems capable of mind reading. Of course, we might also get an interface that’s too clever for it’s own good. Only careful implementation with an eye towards respecting habits followed by intensive user testing can tell which one it will be.

Exercise for the reader

I’m sure there are other ways of coming up with a smarter ordering. If you think of anything please let me know in a comment. Style points for implementing it. If you come up with something awesome, I’ll send you some Firefox goodies.

Related posts:

1. Good interfaces create good habits
2. Firefox 3.1: Control-Tab Woes

Must of my collaborators are the same way. We are often editing each-others’ work, but many hands in the copy-editing cookie jar means edits fly like popcorn kernels on the griddle. How do we keep collaboration simple, especially now that Etherpad is about to reach the end of its life? We need a robust method of keeping track of comments and edits. Standard revision control is too heavy weight, and most diff programs operate on a too-course line-level granularity. We needed another solution. Text interface design to the rescue!

The solution is simply three sets of square brackets and some customs: the first set of brackets denotes deletion, the second set denotes addition, and the third set denotes a comment. Apparently, a similar model is used to keep track of edits in the United Nations. The system easiest to explain by example. Let’s start with a simple sentence plagued by two typical errors:

They called to say that their coming over in an quarter-hour.

An editor might revise the sentence to:

They called to say that the[ir][y're] coming over in a[n] quarter-hour. [][][Be careful with "their" and "they're".]

The edits are deciphered like so:

• the[ir][y're]: “their” was used when “they’re” was meant. To fix this problem the editor suggestions deleting “ir” and replacing it with “y’re”.
• a[n]: “An” should only used before a word that begins with a vowel-like sound. The editor suggests removing the “n” of “an”.
• [][][Be careful...]: The editor is reprimanding the author for forgetting the rules of English. Notice the two sets of empty brackets that prefix the comment. They are needed to make sure that comment cannot be confused for an addition or deletion.

After you use bracket notation for even a little bit, the order of the brackets will become second nature. But, if you need a mnemonic, just remember that a number line always goes from negative to positive. The same is true of the markup, it starts with subtraction and goes to addition. Now let’s try a sentence in drastic need of some complex editorial help,

The silver quick-browed fox jum over thier lazy dog.

This might be edited as so:

The [silver] quick[-][ ]brow[ed][n] fox jum[][ped] over th[ier][eir][Remember, I before E, unless after C. Unless the word is weird.] lazy dog. [][][Shouldn't "their" really be "the"?]

This looks a bit scary at the outset (the density of comments is pretty high), but it is easy to follow the edits:

• [silver]: Delete “silver”.
• [-][ ]: Delete the hyphen and add a space. Notice how easy it was to show changes dealing even with white space.
• brow[ed][n]: Delete the “ed” and add a “n”, resulting in “brown”.
• jum[][ped]: Don’t delete anything and add “ped”, resulting in “jumped”.
• [ier][eir][Remember ...]: Delete “ier” and add “eir”, resulting in “their”. The editor has included a somewhat ironic comment about the inconsistency of English spelling.
• [][][Shouldn't ...]: Like in the first example, this is simply a comment.

Thus, if all changes were accepted, the edited sentence would be:

The quick brown fox jumped over the lazy dog.

The bracket notation method is never ambiguous, easily readable, and can be used with reckless abandon in email. To find changes. you just search for an open square bracket, accepting and rejecting comments is as simple as selecting and deleting text. Having been recently forced to used Word’s revision system, it is a true joy to come back to this elegant markup.

I mentioned earlier that bracket notation can be used for collaborative editing among many editors. So how do you know who has made what comment? Adding an author tag is easily accomplished by putting meta data in the comment section. For instance, “If it’s not chocolate, it’s not dessert” might be edited to:

If it['][]["It's" does not equal "its"! -Jono 7/4/05]s not chocolate, it[']s not des[s][][-Aza]ert.

In this way, adding any meta data about the edit is easily written, searched for, and read.

The only thing lacking is some simple syntax highlighting. It would be great if color could make the comments jump out at me to give that slight edge in readability. It’s a simple thing to implement for your favorite text editor.

Give bracket notation a try the next time you need to edit something. You might be pleasantly surprised at just how seamlessly it works. I’ve been using it for a long time and still use it frequently. It’s a simple solution to a possibly complex problem. It shows that sometimes the solution to an interface problem doesn’t involve inventing something brand new, but reusing something old.

Related posts:

1. The Seduction of Simple: Hidden Complexity