If you’re interested in web browser user experience, take a look at Browser Bits, my little tumblelog/mini-blog thingy all about browser UX.

Of course, the iPad browser is Safari. And from what I’ve seen and heard, it’s more like the iPhone than the desktop version. John Gruber reported that “even though the screen offers the same pixel count as what was once the standard size for a laptop display, iPad Safari renders pages like iPhone Safari. The web surfing experience is all about zooming and panning.”

I’ve had an iPhone for a while now, and done my fair share of browsing in Safari. Since I’m interested in web browser user interfaces (c.f. Browser Bits, my blog on web browser UX), I thought it would be interesting to take a closer look at the little details that make for such a great browsing experience on the iPhone. By examining the most widely-used (and arguably best) mobile web browser, we can better understand what it takes to make a great mobile web browsing experience, and how we might do even better. But also, looking at the design choices made under the iPhone’s contraints can help us break free from our assumptions of what a browser interfaces should be.

Browser Controls

The first thing I noticed is that despite the restricted screen resolution of the iPhone (320×480) they’ve still managed to fit in most of the browser controls that we’re used to seeing.

Along the top, we’ve got the page title, the URL bar, and the search bar. It’s interesting that they chose to keep the two bars separate, rather than combine them into one as Google Chrome does. They probably made this choice in order to stay consistent with the desktop version of Safari.

In fact, almost everything about iPhone Safari is strongly consistent with the desktop version. Page loading progress is shown in the URL bar, and the refresh and stop buttons appear at the far right of it. The controls along the bottom — the back and forward buttons, the bookmark button, and the “+” button — all work almost exactly the same. One small difference is that the “+” button, instead than just being used to add a bookmark, serves three purposes: “Add Bookmark”, “Add to Home Screen”, and (somewhat oddly) “Mail Link to this Page”. The last function seems a bit out of place on this menu, but without adding a button, I’m not sure where it would make more sense.

One of the clever design choices Apple made is that top control bar is actually positioned inside the scrollable content area, so that when you scroll down, it disappears off the screen. The initial content area is 356px high, and the control bar takes up another 60px, so the result is 17% more vertical pixels for the page contents.

The bottom control bar, on the other hand, is static. I’m curious to know if the choice to put those controls on the bottom was based on any empirical usage data, because it’s not obvious that they would be used more often than the controls on the top [1].

Another thing to note is how small the URL bar actually is. In most desktop browsers, the URL bar is massive, taking up most of the window width. The iPhone browser proves that’s mostly unnecessary — I’ve rarely needed to see more than the ~20 characters it shows by default. However, the URL bar and the search bar are only that size when they don’t have focus. When you tap on one of them, it expands to fill the full width of the screen.

One weakness of the smaller URL bar is that it makes it much harder for the user to detect a phishing attempt: on many sites, the entire domain isn’t visible. Tapping on the URL bar is useless because it shows the end of the URL, and scrolling it to the beginning is complex and slow.

The extra width afforded when typing into the URL and search bars is nice, but I’ve found that it can lead to mode errors. When I want to go to a new page, sometimes I tap on the wrong box, and quickly hit the “X” to clear its contents. Once the box fills the screen, there is little indication which box you are typing in. The differences are very subtle: the search bar has fully semi-circular ends, whereas the URL bar is a rectangle with rounded corners. But what usually happens to me is that I type the first word of a search query, and then freeze when I realize that there’s no space bar on the keyboard.

If you’ve never used on iPhone, that probably requires a bit of explanation. On the iPhone, the on-screen keyboard changes depending on what kind of text field you are typing in. I’ll explain more in the next section.

Typing

Text entry on an iPhone is done using a soft keyboard that takes up the lower half of the screen. In most apps, the keyboard is in the configuration shown below left (notice the space bar). Symbols (like the ones you’d need when typing a URL) can be accessed by tapping the button in the bottom left corner. This is the same configuration used when you’re typing in the search bar. But when you’re typing in the URL bar, the keyboard is different, as shown on the right. The space bar is replaced with keys you’re more likely to need when typing a URL.

An additional hidden feature is that you can hold down the “.com” key to access “.net”, “.edu”, and “.org”. Very handy indeed.

One of the coolest things about this feature is that it doesn’t just work this way in the URL bar and the search bar. The keyboard will also reconfigure on any web page that uses one of the new HTML5 input types (like “url” or “email”). In “email” configuration, for example, the space bar is extra small, and buttons are added for “@” and “.com”. (For more information on this, see Mark Pilgrim’s very informative article on forms in HTML5.)

Ok, so most people probably don’t spend that much time thinking about the keyboard. The actual browsing experience in iPhone Safari consists of three main things: tapping on links, scrolling around the page, and zooming in to content.

Zooming

Before the iPhone, it was hard to use a mobile browser to view a site that wasn’t specially designed for a smaller screen. iPhone Safari made things much better by providing two ways of easily zooming in to view the page contents.

One way of zooming is to use the multi-touch pinch/anti-pinch gestures. Contrary to popular belief, this was not invented by Apple. In fact, Myron Krueger demonstrated this technique around the time that the original Macintosh was first released. That said, the mere existence of pinch zoom is not enough; the devil is in the details, and that’s exactly where Apple excels.

When you put two fingers on the screen and spread them apart, the view zooms in on a point located between your fingers. This is important, because it helps maintain the real-world “stretching” metaphor. An alternative implementation would have been to just zoom in on the middle of the screen. I’ve used interfaces like that — it’s very frustrating.

Another detail that Apple got right is the speed of the zoom. To be absolutely true to the real-world metaphor, the content underneath each finger should remain static relative to the finger. That is, if you put one finger down on the top right corner of an image, and the other on the bottom left corner, and then spread your fingers apart, they would still be over the corners of the image. In iPhone Safari, the zoom is actually slightly slower than this, meaning that you have to move your fingers a little bit further apart to achieve the same level of zoom — but it feels just right.

The second method of zooming in iPhone Safari is to double-tap on any content to make it fill the width of the screen. This is straightforward with an image, but not so much with text. The most common use case is to double-tap on a column of text, and the browser will zoom so that the column fills the width of the screen. In general, this works exceedingly well, but in some cases, it will zoom to the width of a particular element that is smaller that the column. I’ve seen this problem on sites that have threaded comments, such as Hacker News.

On the subject of zooming: many web sites have an iPhone-specific version that uses the the meta “viewport” tag to ensure that the width of the page matches the width of the device. This tag (introduced by Apple for iPhone Safari) has an option named “user-scalable” which allows the developer to control whether the user can zoom in to the page or not. The default is “yes”, but unfortunately many web sites set it to “no”. This can be frustrating on sites like Flickr and DeviantART, where you often do want to zoom in to get a better look at a picture.

Scrolling

The more you zoom in, the more you’ll have to scroll. On the iPhone, you do this using direct manipulation — just swipe in any direction to pull the page in that direction. Note that this is the opposite of how scrolling works on a trackpad. On a MacBook, swiping down with two fingers will move the viewport down, whereas on the iPhone, swiping down moves the viewport up.

When zoomed in, Safari makes it easy to scroll in one direction only. That is, a swipe that is not quite vertical will result in a perfectly vertical scroll with no horizontal movement. This way, when you’re scrolling down a column of text, you don’t have to re-adjust the horizontal position every time you scroll. In my opinion, it’s still a bit too easy to go “off the rails” when attempting to scroll vertically. However, it’s a delicate tradeoff, because you want horizontal scrolling to remain responsive.

When you are in the midst of scrolling, you see bars along on the side of the screen that look very much like a scroll bar in a desktop application. This goes for the entire iPhone, not just Safari. These “scroll bars”, however, are completely read-only. They are just there to help you get a sense of where you are on the page. When you stop scrolling, they disappear. It’s good that they don’t take up any screen real estate, but frustrating when you are on a really long web page and want to scroll all the way down to the bottom. This would be even more of a problem for scrolling back to the top of the page, except that there is hidden feature on the iPhone for this purpose. Tapping the status bar at the top of the screen scrolls the main viewport back to the top. Very useful, but very hard to discover. Well, unless you read the documentation.

When reading said documentation, I actually discovered another hidden feature. To scroll within a frame or a textarea on a web page, you can swipe with two fingers. However, on my iPhone 3GS running OS 3.1.2, this doesn’t actually seem to work with either textareas or iframes.

Just like other iPhone apps, Safari has “kinetic scrolling” — swiping with your finger gives the page momentum, and it will continue to scroll after you’ve lifted your finger off the screen. And when you hit the bottom or the top, it will scroll a bit past it before snapping back. It’s a nice, natural, and cute way of indicating that you’ve hit the end of the page.

For some reason though, web pages just don’t scroll the same as other controls on the iPhone. They seem to have less momentum, or more friction. John Gruber has written about this before, going as far as to say that it’s one of the main ways that iPhone web apps fall short of native apps.

Tapping Links

Besides scrolling, clicking on links is the most common thing people do in a web browser [2]. In iPhone Safari, following a link is as simple as tapping on it. It seems pretty straightforward and uninteresting, but given the size of a human fingertip and the small size of web content on the iPhone’s screen, it’s not as easy as it might seem. Given that most web sites are designed for use with a pixel-perfect input device (the mouse), it’s actually pretty amazing that about 95% of the time, I can manage to follow the correct link in iPhone Safari. I’d guess that the hardware is the major factor here, but it still feels like there is some kind of software heuristic at work. It’s easy to take this for granted, but given my experience with various multi-touch interfaces, it’s actually a remarkable achievement that tapping links on an iPhone is as precise as it is.

Another thing to notice is that scrolling and zooming are very rarely mistaken for a link tap. This comes at a cost of responsiveness — there is a slight delay after you tap a link, as it waits to see if another tap is coming. But the delay is subtle enough that it’s hardly noticeable.

Multiple Pages

iPhone Safari does not support tabs. This isn’t surprising, due to the screen and resource limitations of the iPhone. Instead, it has the concept of “pages”, which are somewhat like multiple windows. When you click a link that would open in a new tab or window (such as in GMail), or open a URL from another iPhone app, it will launch in a new page. When you click on the “pages” button in the lower right, you can flip through all the pages that you have open. From this view, you can close pages, or create a new page.

When a link is opening in a new page, there is a nice little animation that makes it clear that you are going to a new page that is to the right of the current one. Without it, you might become confused and wonder why the back button doesn’t work anymore. This actually happens to me sometimes when using desktop browsers, and I’ve heard other people report having the same problem.

There is a limit of 8 pages that can be open at any time. I suppose this is to conserve resources, and to prevent the list from getting unwieldy. If you have 8 pages open and a link needs to be opened in a new page, you will lose the first one in the list. However, this has never actually happened to me.

Although they are called pages, they behave very much like tabs. They have a close button on the top left, and just like with tabs, when you close a page, the one to its right takes the focus. This is another example of how strongly Apple cares about keeping consistent with the desktop user experience.

The key feature of tabs that is not supported by iPhone Safari’s “pages” is the ability to open a link in the background. You can open a link in a new page by touching and holding the link then selecting “Open in New Page”, but this will immediately switch focus to the new page, rather than loading it in the background.

What’s Missing

Well, when you’re trying to put a fully-functional web browser on a mobile device, you can’t do everything. Here are some of the key things iPhone Safari is missing:

Flash

One of most discussed (and hotly debated) things about iPhone Safari is its lack of Flash support. It was never entirely clear whether this was a technical decision or a political one; that is, until Wednesday when we learned that the iPad won’t support Flash either. From a user experience point of view, this has its pros and its cons, but I think it’s a good thing for the web.

Find-in-page

A small annoyance that bites me from time to time is the lack of find-in-page support. However, there’s a plethora of bookmarklets out there that can add the functionality. (Actually installing bookmarklets is pretty painful, but I digress.)

Security and Phishing Protection

I mentioned the fact that small size of the URL bar makes it difficult to visually detect a phishing attempt. There’s also no way to see details about the SSL certificate. The only security-related thing I see is the lock icon that appears before the title when you’re using an SSL connection, but what good is that if you can’t even see what site you’re connected to?

Update: In the comments, PCheese points out that iPhone Safari has phishing protection just like the desktop version.

File uploading

Any file input widgets in HTML forms are just shown as being disabled. Since there’s no user-visible file system on the iPhone, this isn’t too surprising. Still, it would have been nice to provide a simple way of choosing a photo or video to upload.

Opening links in the background

In the study on tabbed browsing I ran in 2009, I found that many power users habitually open links in new tabs, especially on search result pages and on sites like Digg and Hacker News. I find that the inability to do this on the iPhone seriously changes my browsing habits. And I’m quite surprised that the iPad doesn’t appear to support tabs, though this may of change before it’s released.

Conclusion

The iPhone was a revolutionary computing device, in no small part due to how great iPhone Safari is. In its user experience, Apple did what they do best — put a great amount of energy and effort into perfecting the smallest details of the design. I hope this article has helped you notice more of those details.

The version of Safari on the iPad looks to be highly influenced by iPhone Safari. This is interesting, because its screen resolution is bigger than most web users had in 2005 [3]. If it really is “the best web browsing experience ever”, aspects of its design will no doubt trickle up into desktop browsers.

1. Mobile Firefox (aka Fennec) takes an interesting approach: the back, forward, and bookmark buttons are in a control strip that lives to the right hand side of the page content. It is hidden by default, by can be revealed by dragging all the way to the right.
2. See Weinreich et al.’s Not quite the average: An empirical study of Web use

What I find cool about Ubuity is not that it’s “a command line for the web”, but that it provides a much simpler way to extend Firefox. To reach its full potential, I think it needs to move beyond the command line — which is why I was glad to see Aza Raskin (one of Ubiquity’s creators) blogging about making Ubiquity more mouse-oriented (see here and here).

The Concept

In Aza’s proposal, the main way Ubiquity would be accessed by the mouse is through a “badge” that appears beside the selected text, as in the photo below:

When the badge is clicked on, the page slides to the left to reveal the Ubiquity pane. Take a look at Aza’s video to see what I mean:

Mouse-Based Ubiquity from Aza Raskin on Vimeo.

Thoughts

The badge-with-selected-text behaviour can be incredibly annoying (e.g. Snap previews), but it can also be done well (e.g., nytimes.com). As implemented in Aza’s prototype, it’s very subtle, so I think it could work.

But there also needs to be a way to bring up Ubiquity without selecting some text. And whatever that is — a toolbar button, a context menu item, etc. — it’s going to be something completely different from this badge. It’s already a problem that Ubiquity doesn’t integrate into your regular workflow, and having two separate ways of accessing Ubiquity would only make things worse, in my opinion.

As for the slide-over effect, I’m not sure I understand the advantage over a translucent overlay like Ubiquity currently uses. And I think that if Ubiquity is invoked with the mouse, it should look as similar as possible to when it’s invoked with the keyboard, providing a smooth transition from mouse-based use to keyboard-based use.

Alternative Ideas

One possibility is for Ubiquity to have a dedicated toolbar button, like many extensions do. When the user clicks the button, the Ubiquity pane pops up or slides out. If we want to call attention to Ubiquity when text is selected, the button could change it’s icon in a subtle way, getting more colourful, or even glowing or pulsing.

There are other ways Ubiquity could be hooked into the Firefox UI. A Ubiquity bar could replace the search bar (since Ubiquity can do search anyways). Or maybe Ubiquity deserves its own pseudo-tab? See the sketches below:

Panel Layout

The real hard part about a mouse-based Ubiquity is figuring out how commands would be accessed using the mouse. Since Ubiquity is essentially a command-line interface, it can easily scale to handle dozens or hundreds of commands. It’s harder to imagine how that can be done with a mouse-based interface.

To complicate things, there’s no obvious way of grouping Ubiquity commands. Do you group them by verb? e.g. search, post, convert, translate? Or do you group them by site? Or…? And how do new commands fit into that picture? Overall, I think trying to fit commands into a static hierarchy is a losing proposition.

A Ubiquity user needs to be able to access all of their commands, but it doesn’t need to be especially quick to access any arbitrary command. Most people probably have 5 – 10 commands that they use most frequently (it would be nice to have some real numbers on this — Test Pilot anyone?). Those commands should be quick to access. For other commands, I think it’s okay if it’s not as quick.

I don’t have a complete design in mind, but I’ve sketched up a few ideas:

Any thoughts?

The thing about software is that it’s remarkably easy to write a program that mostly works. And it’s difficult to tell the difference between a quick hack and a stable, reliable, and robust system, because the software development process produces almost no visible artifacts.

When you look at a building, it’s easy to get a quick sense of how well-built it is. Which of the two buildings below would you rather be in during a heavy storm?

Besides the program itself, the only visible artifact of the software development process is the source code. And that is only viewed by the programmers, through the tiny lens of the text editor. What if we could make the entire process more visible?

I’m thinking of visualizations along the lines of the comparison of system calls in Linux/Apache and Windows/IIS that I posted a while back. But this is just one idea. What other ways could we visualize Code Smells? (Maybe we could actually smell them!)

Aside from visualizing various aspects of the source code itself, could we show how well tested a piece of software is? We could show how many tests were run recently, what their results were, how good the code coverage is, the number of crashes encountered in the field, etc. With projectors and LCD displays being so cheap these days, there’s no reason a development team couldn’t have a few displays dedicated to these kinds of visualizations.

What do you think? Could this help improve the quality of software? What if companies openly published these kinds of things?

It’s definitely a handy feature. I often use tabs like lightweight bookmarks, leaving tabs open to a page that I am planning to come back to. (And in my field study I’ve learned that lots of other people do this too.) If your browser crashes, or the Firefox process sustains collateral damage in a kill(1)ing spree, it’s a relief not to lose all the tabs your were saving.

The Problem

But the interface for session restore has always bugged me a bit. First, it uses modal dialog boxes, which are generally a bad idea. One of great things about Firefox 3 is that it eliminated a lot of the modal dialog boxes (e.g. “Do you want to remember this password?”) in favour of non-modal messages in the notification bar (see Alex Faaborg’s post about this from last year).

Not only does it use modal dialog boxes, but it’s asking me a question that’s usually unrelated to what I’m trying to do. “Do you want Firefox to save your tabs for next time?” I’m probably closing my browser for a reason, but I have no idea whether or not I’ll need these tabs next time. And asking me when I start up might not be the right time either…I’m starting my browser because I have something to do, and I can’t remember what I had open before, so how should I know whether to restore or not?

Either you’re part of the problem, or…

So I’m thinking — what if we got rid of these questions altogether? What if Firefox always remembered what windows and tabs you had open? But you might not want 15 tabs loading every time you start Firefox up.

A while back, Aza proposed making the new tab screen more useful. His proposal included a separate screen for restoring recently-closed tabs and windows, but it’s kind of hidden in his design. Most of the space in his design is taken up by contextual actions, but when you’re just starting the browser, these aren’t as relevant. Here’s a quick mockup of what a similar screen might look like on startup (mouse over to see the notes):

There are a few things to mention here. First of all, recently-closed windows are accessed from within a history list. Lately, I’ve been thinking that so much of what we do in the browser is revisiting pages that we’ve been to before, so a time-based view makes a lot of sense. Unfortunately, the history is pretty much hidden in most browsers. So you can see some inspiration here from Google Chrome, which presents the history like a regular web page. I think this makes a lot of sense, because it lets you use the same behaviours that you use on the web, whereas a separate history window forces you to learn a new UI.

Recently-closed windows are presented in a way that looks somewhat like they actually appeared in the window, maintaining the tab ordering. It probably needs to be made a bit more obvious than in this mockup, but you get the picture. Of course you could go a step further here, and make it look almost exactly like a screenshot of the tab bar. This mockup only shows one recently-closed window, but you can imagine having more than one, and they would appear in the history at the time that they were closed. I’ve also incorporated recently-closed tabs into this page. That’s currently available as a menu item under History->Recently Close Tabs, but to me, it’s always seemed kind of tacked-on there. You could also imagine using some of the space here for bookmarks.

What do you think? If you have any thoughts, please leave a comment.

Fennec

Fennec is the name of the upcoming mobile Mozilla browser — think Firefox for your phone. I’ve been keeping an eye on the development for a while, especially the UI design discussions that Aza and Madhava have been having. Things are really coming along…last week Madhava posted a walkthrough of the first alpha version:

Fennec Alpha Walkthrough from Madhava Enros on Vimeo.

One of the coolest things about Fennec is that it dedicates the entire screen to web content. Pixels are precious on small screens, so you don’t want to waste them on controls that you aren’t using. On the iPhone version of Safari, the title and URL bar are fixed to the top of the page, so that as you scroll down, they disappear. But the navigation bar — with the back, forward, and bookmark buttons — remains fixed at the bottom of the screen. In Fennec, the title and URL bar also disappear when you scroll down the page, but the other controls aren’t at the bottom — they’re accessible by dragging the page to the left or right. Check out the video to see what I mean.

Edward Tufte would be proud: “the content is the interface, the information is the interface — not computer administrative debris.”

Computer Administrative Debris

In his critique of the iPhone interface, Tufte praises the iPhone interfface for minimizing “computer administrative debris”: the buttons, menus, labels, etc. that steal content space away from the users. This is becoming a serious problem as we continue to shoehorn our desktop interfaces into smaller and smaller screens. For example, take a look at an Asus EeePC running Excel:

Barely half of the available screen space is actually taken up by the content.

On larger screens, losing a little content space is not a problem. But then, I find it causes another problem: it’s distracting. My monitor is too big to run apps at full screen, so I have no choice but to work with clutter all around the window I’m focusing on.

Debris on the web

Inspired by Tufte’s coinage, Ryan Tomayko [redesigned his web site to remove all of the "computer administrative debris"](http://tomayko.com/writings/administrative-debris ) earlier this year. When I saw it back then, it caught my attention. I thought it was definitely an interesting experiment, but I thought it went a bit too far, although I couldn’t quite pinpoint what I didn’t like about it.

Earlier this afternoon, I was procrastinating on my thesis work, looking for inspiration for the long-promised redesign of this blog. I want to stick with something minimal, and I remembered Ryan’s site, so I swung by to check it out again. This time, I was able to put my finger on what I don’t like — it’s the missing title and navigation bar.

The thing is, without a title and navigation bar, the user is missing a lot of important context. When I visit a web site, I’m happy to see a small banner across the top with a few navigation links, because it quickly gives me some important context about the content I’m looking at, and about the site itself. It’s not strictly necessary, but that’s fine as long as it doesn’t get in my way, and lets my focus on the content. And the way most sites implement a navigation bar, it disappears as soon as you scroll the page, like the URL bar in Fennec. So it’s not persistently in your face, or wasting important screen space.

The other thing a navigation bar does is give you some idea about where the links lead. When I follow a link labeled “about” from someone’s blog, I have a pretty good idea where it’s going to take me. But if I just click on the person’s name, I’m not sure — maybe it’s a mailto link (note: I’m guilty of this one too).

So, by all means, let’s eliminate useless administrative debris. But be careful; you aren’t just moving functionality, you’re also removing important contextual information.

In my research, there are two main questions that I’d like to answer. First, what are the problems that people encounter with tabbed browsing? And second, how exactly do people use tabbed browsing? What strategies do they use, and why? The answers to these questions could guide the future design of web browsers.

Great minds think alike

It just so happens that I’m not the only person interested in this. Mike Beltzner put me in touch with a bunch of people at Mozilla who have been thinking along similar lines, and I thought I’d point you guys to some of the interesting things they’ve been posting.

The closest thing to the work I’m doing is Bryan Clark’s post about how and why people use tabs. Bryan is working on the UI for Thunderbird, the Mozilla mail client. They’re interested in understanding the use cases for tabs, in order to support similar use cases in Thunderbird. He’s collecting his data informally; I’m hoping to get similar data, but in a more formal way.

Big changes…

On the Humanized blog more than a year ago, Aza Raskin wrote about the problem with tab scrolling, and challenged his readers to come up with a better solution. Lots of interesting thoughts in the comments, especially the idea of implimenting “tabs” as a single, infinitely long document (perhaps inspired by Aza’s father Jef’s ideas).

That was last summer; more recently, since he’s joined Mozilla, Aza’s been looking at interfaces for mobile browsers. To check out some of the ideas he’s playing with, check out his post on Firefox mobile concepts. I really like the idea of implementing tabs in a zooming UI — it’s something I’ve been thinking about for a while.

…and smaller changes

Since he’s currently focusing on mobile, Aza’s prototypes are a bit more radical than we’ll probably ever see in the desktop version of Firefox. But Jenny Boriss and Madhava Enros are looking at both big and small ways to improve the tabbed browsing experience on the desktop. Boriss starts by listing some of the problems with tabs, and suggests some possible ways to fix the problem: check out her post here.

Inspired by Boriss’ post, Madhava comes at the problem from a different angle, “crushing it, finally, in something we like to call the pincing crab-claw of good design”: see here. Boriss follows up with a great post, incorporating some of Madhava’s ideas, which discusses ways that future versions of Firefox might better support visual navigation. These ideas are a bit more down-to-earth, maybe; it’s easier to see them being added to a future version of Firefox.

Coming Soon?

If you’re interested in how this will all play out in the next version of Firefox, check out this wiki page. Mozilla has assembled a critical mass of talented UI people, and I’m really interested to see what they come up with in future versions of my favourite browser. If you have any thoughts, I know they’d love to get your opinion.

As for me, I’ll be posting some of my own ideas soon, and will hopefully have some empirical data in the next couple of months to back some of these ideas up. Until then, I’ll keep you posted.

(As an aside, I see that I’ve been added to Patrick Mueller’s Planet OTI aggregator. OTIers, read on! Today’s post contains at least two OTI connections.)

Avi Bryant: Turning the Tables: Moving Beyond Relational Storage

The first talk I attended was by Avi Bryant of Dabble DB fame. Avi talked about why how not to use a RDBMS. There’s been a lot of interest lately in alternatives to the relational database — CouchDB, Amazon SimpleDB, and Google BigTable being the most famous examples.

Avi mentioned that there are two main cases where it’s advantageous to have something other than a relational database. First, if your dataset is massive, as with Google. In this case, it’s just not feasible to use a RDMS. The second case is if your dataset is really just many small, independent datasets, in which case it might be simpler and more scalable to use an alternative technique.

At the end of the talk, Avi demoed MagLev, which is a Ruby interpreter built on top of a Smalltalk VM (OTI connection #1). This was really cool, not just because it’s Ruby running on top of Smalltalk. It was cool because MagLev can transparently persist heap objects to disk, and distribute them to other VMs, either locally or running on other machines. For example, you can define a function in one VM, and then call it from another VM. Wow. As far as I know this was the first time MagLev has been shown in public, but there’s going to be a talk at RailsConf 2008.

Daniel Burka: Iterative Design Strategies

The second talk I attended was by Daniel Burka (OTIers probably know Daniel’s brother Peter). Daniel is the lead designer for Digg and a co-founder of Pownce. Daniel gave a great talk on iterative design strategies. You can check out the slides here.

It was really interesting to hear some of Daniel’s stories from Digg. He said that one of the times that they redesigned the comments, they were getting a lot of negative feedback from users. But they also noticed that under the new system, stories were getting more comments than ever before. So although there was a vocal minority who weren’t happy with the design, it was an overall success. The moral of the story is that you need to look at the implicit feedback as much as the explicit feedback.

Another thing I took away from Daniel’s talk was that I should read How Buildings Learn by Stewart Brand. I’ve had this recommended to me enough times that I’ve finally decided to buy it.

John Resig: Building Interactive Prototypes with jQuery

John Resig is the creator of jQuery, “the write less, do more Javascript library”. This talk was pretty timely for me. I just started using jQuery a few weeks ago for a Firefox extension that I’m writing, and I’m pretty much in love with it. So it was practically guaranteed that I would like this talk, since it was further demonstration of all that is awesome about jQuery. I did learn one new thing from the talk — I’d never heard of the jQuery Form Plugin before, and it is really cool as well.

I’m not sure what more I can say about this one. If you’re a web developer, or a designer who codes a little, you should seriously check jQuery out.

So that was my day. $30 well spent at meshU. Thanks to the organizers: Mark, Mathew, Rob, and Stuart.

So, you’ve probably all heard of One Laptop per Child. They recently started shipping their first laptop, which is called the XO. One of the unique things about the XO is that it comes with a built-in graphics tablet. Unfortunately, the system software doesn’t come with tablet support built-in. My project for the semester was to work on improving the tablet support — specifically, the API for activity developers, and the user interface for drawing.

The user interface ended up being the most challenging part of the problem, because the XO tablet is not quite like a standard graphics tablet. It has no hover mode, and it has an aspect ratio that’s completely different from the XO’s screen. In this video, where I explain some of the ways I’ve come up with to deal with these problems.

For more information about the project, check out the Pen Tablet Support and Pen Tablet UI pages on the OLPC wiki.

I’m planning on continuing with this work this summer, so if you’ve got a comment or any other ideas, I’d love to hear them. Leave ‘em here, or send me an email.

I was taking a look at the phones they offer for prepaid, and got a laugh out of the description for the Motorola W370:

The features for the Nokia 6080: “Great value!”, “Pocket sized”, “Sleek design”, and “Embedded camera.” For the Motorola W370: “Flip phone”, “Affordable”, and then a blank bullet. Like the sales guy just gave up: “Meh…I got nothing.”

If that doesn’t convince you to grab one of these babies while you still can, I don’t know what will.