Of course I needed a text editor, so I figured I’d give TextMate a try since it’s highly recommended by many Mac hackers. My first impression has been good. It’s a got a nice, simple, no-frills interface, some slick built-in themes (Espresso Libre ftw!), and the bundles come in pretty handy.

I’ve found a few small things that have thrown off my rhythm though. The regular find command (⌘-F) doesn’t do an incremental search, and hitting Enter again doesn’t bring up the next match. Yes, I know about Ctrl-S, but geez, I gave up Emacs like eons ago, and I’m just so used to typing Ctrl-F (on Windows) or ⌘-F (on the Mac) to search. And I want it to work that way in every application.

Another thing that I miss is the way the Home and End keys work on Windows: they move the cursor to the beginning and end of the line. On the Mac, they take you to the beginning and end of the file, which you can also do on Windows by hitting Ctrl-Home and Ctrl-End. I really miss the Windows behaviour, because it’s my favourite way to nuke a line or a whole section of code: whack Home, then hold down Shift and use the arrow keys to select the lines you want to kill.

Anyways, the point of this post is not to complain about TextMate, because it is a fine piece of software, and I’m sure it won’t take long for me to adapt. But this experience got me thinking about the whole experience of programming in a text editor, and made me realize that this hasn’t really changed much in 30 years.

Where’s the innovation?

In 2008, on almost every operating system, your choices for a text editor are roughly the same:

• vi, the modal editor for UNIX-loving, bearded hackers
• Emacs, the non-modal editor for LISP-loving, bearded hackers
• Some kind of WIMP-y editor, for everyone else. Sure, there are plenty of “choices” in this category, but it’s like the choice between Coke, Dr. Pepper, and root beer: they’re still all sugary, caramel-coloured beverages. TextMate, Eclipse, Visual Studio, Notepad, etc. — the actual act of editing text is almost exactly the same in all of them. These guys basically work like your standard WYSIWYG word processor, with a few extra features for coding.

Now let’s go back 30 years, to 1978. I wasn’t breathing 30 years ago, let alone coding, so I had to go to Google for a little history lesson. But as I understand it, here were your choices in 1978:

• a line editor like ed, which I’ve been told was roughly like trying to write with a pen tied to the end of a metre stick
• vi, the modal editor for UNIX-loving, bearded hackers
• Emacs, the non-modal editor for LISP-loving, bearded hackers
• Some kind of WIMP-y editor, if you were lucky enough to be working at Xerox PARC

So where’s the innovation?

At this point, you might be thinking, who cares? Emacs/vi/TextMate is good enough. The thing is, the text editor is still the primary user interface for coding. That’s why some people get so religious about their preference. It just seems weird to me that there have been so few attempts to try something truly new. And I find it hard to believe we reached the pinnacle of programming UIs in 1978.

A few ideas

Most editors are just as good for writing a blog post or screenplay as they are for writing code. But the structure of code is completely different. You rarely open up a source file and read it from beginning to end. But most programming environments seemed to be designed for that kind of workflow.

In the end, I think that’s the real kicker: most programming languages are file-based. For some reason, we seem to be so attached to coding in plain text with 80-character lines. If you drop this assumption, things start to get a bit more interesting. But that only takes us to where Smalltalk IDEs were at in the 80s.

Anyways, most of the dynamic languages aren’t inherently file-based. By that I mean that it’s not too difficult to interface with the interpreter without using text files. So that’s not a good excuse.

Here are a few things I’d love to experiment with in a programming environment:

• Better support for random access. The structure of code is more like hypertext than it is like a book.

• Richer annotations. Comments take up valuable screen space. It would be nice to be able to have more unobtrusive comments in the code. This would also allow you to do things like have a discussion thread about a section of code, link to other relevant methods, etc. Even something as simple as comments that auto-wrap to the width of the window would be a nice touch.

• Better support for looking at several sections of code at the same time. Some editors (including Emacs) allow you to split the window into several viewports. That’s a start, but it could be improved upon I think. That reminds me, I’ve been meaning to try Acme for a while.

• Tighter integration between the editor and the runtime. One example is having your editor be able to tell you “every time you’ve run this method, this variable has been of type X”. Another example is if your editor visualized code paths — maybe you could overlay a heat map on top of the source code for profiling purposes

• Explicit support for exploratory programming. When I code in Python, I like to keep an interactive console open, where I can try out little snippets of code. With a bit of tweaking (e.g., not tossing out my entire method when I make a syntax error on the last line), I could see this becoming a primary way to write code.

What do you guys think? What are your favourite programming editors/environments, and why? Any other ideas about how programming UIs could be shaken up?

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.

• AJAX Libraries API - Google Code

  I was wondering when this was going to happen. Google announces that they are now providing hosting and distributing of popular JavaScript libraries. No longer do you have to include the kitchen sink in your application. Well, as long as you are willing to put your eggs in Google’s basket.

• Proposal for a new ticketing system for DrProject

  An interesting idea for bug tracking. Your bug database starts as a simple to-do list, and then you add fields as you need them. Only one working on a project? Don’t need the “owner” field. Just starting to write the code? Don’t need the “release” field.

• Grape desktop

  Really cool concept for a desktop interface based on zooming and spatial organization.

• Long Methods are Natural - Beautiful Code

  Michael Feathers explains how method length seems to have a power law distribution.

• Stanford Human-Computer Interaction Seminar - Free on videos iTunes

  via UsabilityBlog

• When location is everywhere | FactoryCity

  How will your web app change when (and not if) your users can easily share their location data?

(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.

It’s been an interesting 24 hours for anyone who follows the One Laptop per Child project. Yesterday, OLPC announced that they have teamed up with Microsoft to make Windows XP available on the XO. Then it was announced that Walter Bender, OLPC’s former president of software and content, is forming a new organization called Sugar Labs to spearhead development of the Sugar user interface.

This is an interesting development. I started working on OLPC-related projects a few months ago, doing some work on the user interface for the built-in graphics tablet. Back in January, I wrote about how cool I think the Sugar UI is. I really hope that Sugar can gain some momentum on its own, instead of constantly being overshadowed by the political and ethical issues of the One Laptop per Child project as a whole.

I’ve been thinking about buying myself some kind of ultra-portable laptop, and since I find it almost impossible to type on the XO keyboard, I’m currently eying the Asus Eee PC. I don’t think it makes sense to use a conventional desktop environment on that kind of machine, and I think that the current Sugar UI is a really promising alternative. Now that Sugar is being developed separately from the OLPC project, it will be interesting to see if it can develop into a useful general-purpose desktop shell.

Since all my other plans fell through, I decided to show up to the Twitter party (fashionably late, of course). You can get your Dubroy fix in bite-sized chunks at http://twitter.com/dubroy. Hope to see you there!

And from time to time, I bookmark things that strike my fancy at http://del.icio.us/pdubroy. Most of the links are relevant to this blog, so I try to post a link roundup here every now and then.

“Object Calisthenics” is supposedly an exercise to get you to write better object-oriented code. Reading through the suggestions, I couldn’t decide if the article was serious or not. From Andrew’s summary:

1. Use only one level of indentation per method. If you need more than one level, you need to create a second method and call it from the first. This is one of the most important constraints in the exercise.

2. Don’t use the ‘else’ keyword. Test for a condition with an if-statement and exit the routine if it’s not met. This prevents if-else chaining; and every routine does just one thing. You’re getting the idea.

3. Wrap all primitives and strings. This directly addresses “primitive obsession.” If you want to use an integer, you first have to create a class (even an inner class) to identify it’s true role. So zip codes are an object not an integer, for example. This makes for far clearer and more testable code.

From what I can tell, this really is serious. These are supposed to be the object-oriented equivalent of chin-ups, designed to whip you into shape to write better OO code.

This strikes me as so bogus, I can’t even begin to describe it.

I’m not against OO: I’m a huge fan of Smalltalk, and I cut my programming teeth at one of the oldest object-oriented development shops. In fact, I keep thinking of something that Steve Northover used to say to me when I was on my first work term at OTI:

“That which obscures my code is bad.”

If you’ve ever seen a large body of code that adheres to The One True OO Style^TM — like say, Smalltalk class libraries — you’ll understand that almost every step you take towards “true OO” is just another way of obscuring the meaning of your code. If you break your code up into 10 different methods, then that’s 10 different places I have to look to figure out what is going on. You’re just writing spaghetti code by a different name. If you’re building a very large library, then maybe, just maybe, the additional flexibility is worth it.

I think Paul Graham sums it up best in his essay Why Arc Isn’t Especially Object-Oriented:

My own feeling is that object-oriented programming is a useful technique in some cases, but it isn’t something that has to pervade every program you write. You should be able to define new types, but you shouldn’t have to express every program as the definition of new types.

One of the cooler features of Firefox 3 (which is currently in beta) is the awesomebar, which is the nickname for the URL bar and its new autocomplete features. Madhava, one of Mozilla’s talented interacticians, noticed something neat: this means that the URL bar can be used as a shortcut to perform commands in web apps like Google Docs.

Here’s how it works: instead of navigating to Google Docs and clicking the “new document” button, you can just type the words “new document” into your awesomebar. These search terms will match part of the query string of a Google Docs URL, and visiting that URL will pop you right into a new document.

This reason this works in Firefox 3 is because the awesomebar autocompletes anywhere in the URL or page title, not just at the beginning of the URL like older versions of Firefox. For more information about the awesomebar, check out Deb Richardson’s post, or see some of my older posts: Firefox 3 Awesomeness and Firefox 3 Beta 1: Usability impressions.

I just tried something similar when I went to write this post: instead of navigating to my blog’s admin page and then clicking “New post”, I just typed “new post” into the URL bar. The first hit was on the title of the Wordpress “Create New Post” page. Sweet!

I think this is pretty cool. It means that Firefox’s URL bar is now a command-line for web apps. Of course, this is just more evidence of the command-line comeback and the URL as a user interface.

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.

• the One Laptop per Child wiki
• the DrProject wiki for a class I’m taking with Greg Wilson
• random notes that I keep on a Jottit page

I’ve become pretty finely attuned to the difference between their markup languages. The OLPC wiki runs on MediaWiki, the same as Wikipedia. The version of DrProject that we’re using seems to use a variant of the MediaWiki syntax. Jottit uses Markdown format. In this wiki-markup-language-cage-match, here’s my decision:

Markdown rules.

Markdown wins, hands down. In fact, ever since I learned about Markdown a few years ago, I’ve been wishing for a wiki that would support it. Luckily, more and more are. In fact, even the new version of DrProject supports Markdown.

I won’t even begin to go into the reasons why Markdown is so superior. If you haven’t tried it out yet, give it a go.