We discovered as soon as we (and our users) got their hands on Internet Explorer 7 that freehand drawing in Thinkature was misbehaving. In particular, we learned that it was only possible to start a drawing in IE7 if the cursor were positioned on top of some other object in the workspace. After the drawing got started (that is, after the initial mousedown event had been handled), everything worked great.

This, naturally enough, caused some wailing and gnashing of teeth. It turns out that the problem stems stemmed from a bug in how IE7 handles JavaScript mouse events (click, mousedown, mouseup, etc.) on transparent/invisible objects. On a blank page, objects with a CSS ‘background-color’ property set to ‘transparent’ or not set at all will not be able to receive mouse events. If that were the entirety of the issue, though, this wouldn’t be a very interesting problem (at least as far as IE bugs go).

Needless to say, there’s a twist. If there’s a non-transparent object below the transparent object, the transparent object becomes clickable within the bounding box of the object below it. Here’s a diagram to illustrate the idea:

In the diagram above the transparent object will respond to mouse events, but only if those events occur over the red box underneath the transparent image. But wait! There’s another catch! Suppose the non-transparent object underneath the transparent object is actually an image (i.e. an img tag). Will the transparent object respond to mouse events over the image? Nope! This only works if the non-transparent object is an opaque (or at least not totally transparent) DOM object that is not an image.

And there’s one more exciting twist to cover. Suppose you assigned a background color to the formerly transparent object, but set its opacity to zero. In IE7, a colored-but-zero-opacity object will receive mouse events just fine. If my memory serves me correctly (and it may not), mouse events won’t reach a zero-opacity object in basically any other browser on the planet. The fix for IE7, then, breaks all other browsers. And so the saga continues.

The moral of today’s story? If you need to handle JavaScript mouse events directed at a transparent object under IE7, you’ll need to make it transparent by (a) assigning it a solid background color and then (b) setting its opacity to zero. Setting ‘background-color: transparent;’ will not work, but the zero-opacity solution may break mouse events in other browsers, so you’ll need to implement some degree of browser detection to make things happy.

The video is available on the YUI blog, and there’s also a high-res version available courtesy of Yahoo!; we hope you enjoy it!

If you’re interested in the Hot New AJAX Web 2.0 Ethernet Cyber Monorail Page Technology, you’ve probably heard of using long-lived HTTP connections for server-to-client communication in web applications. The technique (sometimes called “Comet” or “server-push”) is based on the idea that browsers will execute complete chunks of JavaScript as they’re received rather than waiting for the connection to close. The process begins when a client requests a resource (we’ll call it /stream). The server begins to respond to the request, sending along all of the appropriate headers, but then keeps the connection open (as opposed to notifying the client that it’s done sending content). As things happen during the application session, the server writes fully-formed script tags to the open connection in order to send notifications to the client.

The advantages to this approach have been discussed in detail elsewhere, but the biggest one (particularly for Thinkature) is that it’s a very low-latency way to communicate. Were it not for the server-to-client stream, the client would have to poll the server at regular intervals to find out if anything new had happened. The process of polling introduces some inherent latency, and it also adds to overhead through opening and closing connections and complicates synchronization (there’s no guarantee that messages will arrive in the order you expect them to).

One of the big problems with this approach is that it’s not yet well-understood. Strange problems pop up that nobody’s run into before, and there’s nowhere to turn for help. In adding voice chat to Thinkature, we ran into one of those problems. Our voice chat client is a small Flash movie that’s embedded in the Thinkature workspace. It notifies the workspace of events (user joins voice chat, begins speaking, stops speaking, etc.) via an ActionScript-to-JavaScript call. We discovered that whenever the voice chat client sent a message to the workspace server, Internet Explorer (and only IE — all other browsers were fine) would drop its streaming connection to the server. This was, obviously, unacceptable.

Flash-to-JavaScript communication works most reliably by calling the ActionScript getURL method with a javascript: link. After a lot of unsuccessful experiments, I hypothesized that IE treats javascript: URLs the same way as links to other pages: by preparing to leave the current page and closing any open connections. I’m not sure that’s strictly true, but I get the feeling that it’s something along those lines. In any event, I wondered if sending the JavaScript “impulse” to a frame inside the main document would prevent IE from “navigating away” from the workspace and dropping the streaming connection.

I created an invisible frame inside of the workspace and began sending ActionScript-to-JavaScript messages to that frame instead of to the main frame. Instead of calling “handleEvent(...)“, for example, I would call “parent.handleEvent(...).” To my pleasant surprise, it worked. A diagram of the “bad” approach and the “good” approach is included below.

So, in short, the message here is that sending Flash-to-JavaScript messages directly to the main frame of a streaming application under Internet Explorer causes a loss of stream connectivity. The workaround we use for Thinkature is to embed a “dummy” frame in the main document that routes the messages safely to the main frame.

Again: whew.

When you log into a workspace, you’ll notice a speaker button to the right of the user list. Click on that button to get at the voice chat controls (join/leave voice chat, adjust microphone settings, etc.). You’ll always be able to see who’s talking, but you won’t be able to hear them (and they won’t be able to hear you) until you join the voice chat.

We’re really proud of voice chat, and think it’s a really great way to collaborate. Unlike other voice chat systems, this one doesn’t require a ton of bandwidth, it doesn’t need any special software, and it most certainly doesn’t require making a long-distance phone call. Everything runs seamlessly in your web browser. We’d love to hear how it’s working out for you; please don’t hesitate to leave feedback or ask questions.

Thanks very much!

Generally, this has demystified the process of production. I’m always amused to hear Ron Moore of Battlestar Galactica and his wife talking more or less directly to fans on the forums on his podcast. I’ve learned more about the process of creating a TV show from those podcasts than from any other source. The same is true for web applications - part of what got Jon and I started was a prevailing belief (fueled by reading about other people doing it) that there isn’t any particular magic to creating a web application. Certainly, there’s a lot of hard work and inspiration required, but it’s something that smart/competent people can do without being blessed by, I don’t know, the King Arthur of web applications. Hopefully we’ve done our very small part in making web application development appear a little less daunting, too.

The creator/consumer connection has also had a profound effect on how design is practiced. This is a well trodden topic, but one that came to mind over the past few days because of an excellent conversation with a journalist on the topic, an article in The Escapist, and being heavily involved in the question of new features with Jon.

As a starting point, I want to talk about The Escapist article and get off my chest what’s so ridiculous about Massey’s position. She argues that the hardcore game players that beta test games provide feedback from a position biased by their extensive experience with other games, lack of patience, and desire to create games for themselves. I certainly won’t contest that - early adopters in any media are a particular subset of an entire market that are not (necessarily) representative of the whole market. I would also agree that slavishly following feedback as it comes in is a bad idea. But Massey takes this one step further, claiming that “developers must learn to stick to their guns and see their visions through. Half-finished products are always going to inspire hate, and no mater how much it stings, making drastic changes in response to community complaints invites disaster.”

… What?

Jon and I will be the first to admit that Thinkature is not a “finished” project. There’s plenty left to do, and it may in fact be only half the application we envision, but that’s not a reason to “stick to [our] guns and see [our] visions through.” Massey is trying to conflate listening to users with “reactionary design”. I agree that good design isn’t about taking a poll among your users and blindly following the results. But I strongly disagree that involving users in the design process any earlier than in the polishing phase is a bad idea.

Good designers have the perspective and maturity to critically consider and integrate feedback. Formal design courses like to talk about this as abstracting tasks to goals and goals to values. For instance, I worked on a mailing list project a few years ago and it quickly became clear after talking to people that subscribing to mailing lists helped satisfy a few desires like “feeling connected to the community” and “showing off what I know”. A mailing list is just one way that they could fulfill those desires. This level of discussion is independent from conversations about where to put the “subscribe to list” button in the interface, but critically important to providing context to design decisions. Most generally, the question designers (should) ask themselves is “what does this person really want?” If you follow through on that thought, you might find that they want exactly what they’re asking for. Sometimes, though, it’s something else entirely. Maybe what they want is at odds with what your vision is. If that’s the case, listening to users doesn’t mean you have to do what they say all the time. Speaking for myself, when I’m in the consumer role instead of the creator role, I’m usually just grateful to have a voice.

That’s not how Massey feels, though.

She recommends lying to users, more or less. I wanted to cut this quote down, but it’s just so juicy and ridiculous I had to include this section in full.

The nefarious trick for videogame developers is to ignore their community without telling them. It’s evil, it’s underhanded, but if you can still fool the hardcore into buying into your brand, so much the better. In order to get them, they need to think they were only this far away from getting their names in the credits.It can be done. The trick is to have smart community relations people. These are people who can rationally use a message board to talk to players. There, they post, they discuss and they explain. They let the community know they’re reading and that they’re not wasting their time.

In reality, though, the community better be wasting their time. Community management is public relations when it’s at its best and cause for reactionary development when it’s at its worst.

Part of a close creator/consumer relationship is about treating the people who appreciate what you’re creating with the utmost respect. Massey’s attitude is a relic of another era of software design - one mired in the belief that listening to users means giving up on effective, vision driven design. It has no place in modern ideas about web design, and I sincerely hope that no one takes her seriously on this particular topic. We at Thinkature certainly don’t.

This was kind of a long and critical post. I originally wanted to talk more about how Jon and I think about design and feedback, but my distaste for Massey’s article was such that I couldn’t keep it short. Alas. But fear not! I will have a more positive article soon.

Quite so.

Apple has been an incredibly strong force in popularizing design in consumer electronics and beyond, starting with the original iMac in 1998. Because good design practices (both in a technical, aesthetic, and business sense) became obvious to the general public coincidentally with Apple becoming successful again, outsiders who didn’t understand the deeper reasons for Apple’s success decided that ‘design’ was what was going to set them apart too. The problem is, a lot of them didn’t really get it.

So instead of real design, we got a bizarre imitation of design of which the Zune is just the most recent and spectacular example. Just like islanders famously cleared landing strips and built bamboo radio towers to attract American cargo planes, companies like Microsoft are now imitating the branding (”Hello from Seattle?” Cute.), building an online store, and adding “social” features, expecting that commercial success will follow. I’m sure someone inside Microsoft said at some point during the design process “What would Apple do?” with a straight face. Maybe it even got used as an argument - “This is the right thing to do because Apple does it.”

But, of course, this isn’t how Apple does it (although the prospect of an Apple designer asking “what would we do?” is pretty amusing). Apple’s design process is, as far as I’ve read, a pretty idiosyncratic thing, but I’m pretty sure it doesn’t involve copying single parts of past designs and assuming that they can mish-mash them together to make another successful product. Products and services are holistic beasts that succeed or fail for lots of reasons, not because they look like past successful products. It’s easy to mistakenly assume that technical details have shallow roots and can be tweaked without major consequences. The Zune is evidence of precisely that phenomenon to the extent that it’s crashing while the iPod isn’t.

We’re trying to avoid this cargo cult design process in Thinkature. It can be surprisingly hard at times. A lot of interface design is rooted in copying best practices and taking advantage of interface metaphors that people are already familiar with. Still, it’s critically important to understand why existing interfaces are good, so you get the details right. Otherwise, you’re just another islander hoping that drinking afternoon tea and chatting politely about the weather is what made Western Civilization successful.

…but what you’d find is that the output <div> always lags behind the textarea by one keystroke. This is actually by design, and not a bug. The idea is that event handlers should have veto power over the event. By fiddling with the stopPropagation and preventDefault properties/functions, it’s possible to prevent the keystroke from being handled by the browser. It’s only after all of the handlers for an event have fired — and none of them have stopped the event — that the event actually takes effect.

The downside of the give-event-handlers-the-power-to-stop-events design is that it’s difficult to have a handler take effect after the event has already finished and been “accepted.” In the textarea-to-div mirroring example this isn’t a huge problem. There are plenty of workarounds. It’s possible, for example, to pull the character code out of the event, append that to the string from the textarea’s value property, and work from there. There are cases, though, where that’s not possible or not practical.

The situation, in a nutshell, is this: because the event doesn’t take effect until the event-handling call stack opens and closes completely, there’s no way to work in a post-event environment via conventional event handlers. Whew. It’s not possible (as near as I can tell) to circumvent the closing call stack requirement, so instead we have to work with it — or around it.

The trick I usually use it to call setTimeout with a delay of 0. For example, I’ll do something like this:

What that does is wait for the current call stack to close, then opens a new one in which the “real” event handler (outputDiv.innerHTML = textarea.value;) executes. Because the handler runs after the event-initiated call stack closes, the event has already taken place and textarea.value will be in a post-event state. Everything will work as originally intended, and the outputDiv will mirror whatever is currently in the textarea, rather than lagging one step behind.

This works because JavaScript is (at least in every implementation I’ve been able to get my hands on) not implemented as a multi-threaded language. If the JavaScript engine is busy when it’s time for something to happen (be it an event handler or a timer), it starts to queue up backlogged tasks rather than executing them in parallel. Once the current task (defined as the opening and closure of a single call stack) finishes, a new call stack is opened and the next task begins. (Side note: my test code for this is a mess, but I’d be happy to clean it up and publish it if there’s interest).

What happens when we call something using setTimeout with a delay of 0 is that the JavaScript engine notices that it’s busy (with whatever task called setTimeout) and queues the setTimeout code for execution immediately after the current call stack closes. In other words, it calls it as soon as possible in its own call stack.

I’ve found this technique to be useful in a few cases, and I’m sure there are more. Here are a handful of the things I use it for:

1. As mentioned above, I’ll often use setTimeout(..., 0) to set up post-event handlers.
2. Most browsers are smart enough not to apply DOM changes until a call stack closes. For example, if a function changed an object’s color from red to green and then back to red, the browser would be smart enough to realize that there wasn’t any net change and that it shouldn’t really do anything. I’ve found a few browser bugs, though, where it’s necessary to “poke” the DOM to make things appear correctly (particularly when scrolling with fixed-position elements). My poking functions change the style one way with one call stack, and then immediately revert the change in another call stack, thereby forcing the browser to redraw the problem element.
3. Along the same lines, there are some things that can’t be done in a single call stack. I’ve heard arguments that that’s the case for security reasons, but I don’t buy it. As an example, I’ve had trouble programmatically spawning form fields with content and then focusing/selecting those fields in the same call stack. Using the setTimeout trick, everything works just fine.

There’s something of a black art to knowing when to use the setTimeout trick. If you’ve ever found yourself in a situation where you can make something happen in response to user actions, but can’t make it happen in code, chances are that you need to escape the call stack somewhere. As a rule, though, it doesn’t (shouldn’t) happen often. I only use it in three or four places in Thinkature, which is a very substantial piece of JavaScript.

As far as we’re concerned, Web 2.0 defines an era. When people try to put together functional descriptions of what a Web 2.0 application is, the end result is that they don’t exclude a whole lot of applications developed in the past 3 years. Web 2.0 encompasses too many ideas ranging from usability to social software to business models to specific technologies to really be meaningful. It turns out that most modern web applications include some of these ideas.

This is not to say that the term Web 2.0 is useless. History is frequently divided into temporal segments. In culture and fashion, we commonly talk about 90’s bands, 80’s hairstyles, or Victorian literature. Web 2.0 is just another way of separating the history of web applications. That’s great - we need those terms to understand the field in which we work.

The other bit of evidence that points towards Web 2.0 being an era term not a genre term is the inevitability of its death. Last week, the NY Times reported on the future of Web 3.0 (which we disagree with, but that’s beside the point) and various articles use the term Web 1.0 disparagingly to imply “old”. It would be crazy to claim that genres have this inevitable march of progress in the way people talk about Web 3.0 coming after Web 2.0. You couldn’t (seriously) claim that rock deterministically lead to grunge which deterministically lead to rap-rock. You can trace inspirations, sure, but that’s not linear “this is better than what came before” progress. Even the name “Web 2.0″ implies monotonic positive progress by using software versioning as its basic metaphor, which is also an era term.

Somewhat orthogonal to era, we also describe ideas/art/scholarship/music by genre; for instance classical as a genre spans eras. It represents a somewhat different style now (eg Philip Glass) than it did two hundred years ago (eg Beethoven) but still shares some important thematic elements. So what’s always annoyed us is that Web 2.0 is often used as a genre term when it’s really an era term. It would be silly to ask Smashing Pumpkins if they’re a 90’s band in just the same way it’s silly to ask if Flickr is a Web 2.0 application. Of course they’re both members (and in some ways quintessential members) of their respective eras.

So yes, we are a Web 2.0 application. But not in the way we think most people understand Web 2.0.

We think this is a critically important question when designing an interface. Thinkature is intentionally a really simply application. We offer fewer features than some of our competitors. Strategy, MBAs like to quip, is the art of deciding what not to do. Here’s what Thinkature doesn’t do: control line thickness, change fonts, draw hexagons, run filters on images, edit drawings, and draw straight lines. These are just a few of the features we’ve talked about adding and decided not to do so far. Certainly, there are a handful of people who’ve asked for each of those features. If we assume they’re representative we could make some small (but not non-zero) number of people happy by adding them. So why don’t we?

There are lots of reasons why not, but I’d like to focus on the cost of losing simplicity. It’s my basic belief that every feature we add to Thinkature comes with some cost to overall usability. Every added feature makes Thinkature slightly more overwhelming and confusing.

Now, it’s possible to make this cost approach zero. For instance, adding keyboard shortcuts is a nearly zero cost feature add. Adding another menu item to the “workspaces” menu (like export, which has always been destined to end up there eventually) would also be another nearly free feature add because the menu is still really short. But there are plenty of other feature additions that come with some clear cost to overall usability. For instance, if we added another button halo item (say, a copy button) that’s another icon users need to decode. Similarly, if we add a workspace feature like “manage invited users’ permissions,” that interface would need to get more complicated, and people who didn’t need that particular feature might get confused.

Now, I think both of those features are really useful, and both will probably happen, but we always ask ourselves what the incremental cost to the clarity and simplicity of our application will be, and whether the feature is good enough to be worth paying that cost. If you approach new features as not being “free,” you can avoid ending up with an application that looks like Word.

This attitude also changes the way we think about features. When we design new features, we have two jobs: make the feature effective, and make the incremental cost to overall usability as low as possible. Often, doing a good job on one of those questions means you’ve done a good job on the other, but we always try to think about both.

• Do web design. (the usuals - HTML/CSS)
• Hack on the client-side (we use Javascript in ways rarely seen on the web)
• Enhance server-side functionality (our custom HTTP server is written in Python)
• Test like a fiend on a variety of browser platforms (our current release supports all the major browsers)
• Engage in high level design discussions about the direction of the product
• Engage in low level design discussions about details of specific features
• Develop relationships with potential future user groups
• Run pilot deployments with specific user groups
• Maintain community relations (writing on our blog, reading/commenting on others, plus staying involved in our forum and on our wiki)
• Help us manage money and other administrative tasks

We’re not expecting candidates to demonstrate experience in all of these areas, but the more of them you can demonstrate experience in, or reasons why you might be good at them, the better. More than anything else, though, we want to hire a smart, passionate, and flexible person.

If you’re interested, please get in touch with me and we can start a dialogue. Feel free to include whatever supporting materials you think are appropriate for convincing us that you’d be a good fit.