Wed 16 Mar
2005
Jason Fried made some waves at this year’s South by Southwest Interactive conference with a talk he gave entitled “How to Make Big Things Happen with Small Teams.” It’s a little uncomfortable for me to talk about a competitor in a weblog post, even (or especially) one I respect as much as Fried, a principal at the justly lauded 37signals — but he raised some excellent and also controversial points that bear further discussion. Equal parts advertisement for his company’s hit Basecamp product and a proposal for a new way to look at Web development, his presentation might be grossly summed up thusly: set aside almost all of the time-consuming, preparatory measures of user-centered design and start designing the final customer experience — the interface — as soon as possible. You might call it something like “iterative design.” Fried published some initial thoughts on this approach in this weblog post, and if/when I can find a copy of his slide deck, I’ll link to it here.
In my first quick report from South by Southwest, I very briefly made some reactionary remarks on this talk. Mostly, my complaints were about the mixed message that some of Fried’s talking points sent, how he somewhat freely alternated between, on the one hand, a design methodology for teams focused on building a product and, on the other hand, a process for teams providing consultative design services to clients. For the former, I had no issue with what he described, but for the latter, I found it an unrealistic proposal.
That distinction between a product team and a services team makes all the difference, in my view. In many instances, process is key to overcoming the obstacles of an intransigent corporate culture when a design studio is faced with helping a large client create a Web product with enterprise-wide ramifications.
Take feature specifications, for instance, those exhaustive and admittedly abstract documents that define what will be built for a site. Fried suggests that teams might forgo those altogether, dismissing them as “political.” He’s absolutely right to label them so, but that doesn’t necessarily render them inherently obstructionist. For any designer working in an enterprise environment, politics is a huge portion of the challenge for which clients engage us. The ability to navigate between multiple operating constituencies, and to achieve buy-in across groups often accustomed to working at odds with one another, is a crucial part of seeing a successful design realized. Given two equally capable design studios, I can guarantee that the one that has the greater capacity to balance a client’s internal politics will win the day in any design effort.
To be fair, I would doubt that Fried would advocate this approach for every instance — in a very brief discussion with him about the issue, he said clearly that different approaches apply for different circumstances. As another tool in the belt of Web developers, it’s a viable alternative to the comparatively monolithic approach of user-centered design. The line between gospel and dogma is as thin and impermanent as chalk, and it’s reasonable to say that the trappings of user-centered design methodology — extensive research, personae, user scenarios, branding exercises, mood boards, etc. — have attained some dogmatic qualities over the course of the past several years.
In fact, I must admit that I was being a curmudgeon when I was listening to Fried’s talk, stubbornly resisting my first, jarring exposure to a new methodology. I do that from time to time, especially when I have as much invested in a way of doing things as I have in user-centered design. It helped me open up a bit when the ideas that Fried discussed were echoed by several other speakers I heard at the conference — it was, you could say, definitely one of the show’s stronger memes.
What really converted me, though, was the realization that there was at least one thing about this approach that I like a lot. That is, this is a method that returns designers to that core notion of visceral creativity. For many of us — for me — what got me really excited about working in this medium was that I could have an idea and execute it immediately, that I could translate my ideas into code and experience it in very little time, without first clearing a series of procedural obstacles. As designers, what we should really be busying ourselves with at the earliest possible juncture is designing. The shorter the time span between conceiving the initial idea for a solution and the execution of that solution, the less risk of smothering creativity.
Of course, there’s a caveat to this: to get to a position where a designer can begin almost immediate work on the final design — and to be successful at it — it helps to have deep experience doing things the long way. It takes someone who has been through the process of political deliverables, who has watched the pain of user testing, and who has accumulated a history of design successes and failures to be able to make instinctive decisions in short order — someone like Fried, not coincidentally. In a sense, iterative design is strongly predicated on user-centered design. You need to walk before you can run.
I bet there is a way to pass the URL on to Spurl using an AppleScript. Tell Brent from Ranchero about it and I bet he’ll figure it out for you. Something like that needn’t be a “show-stopper”!
Yeah, it’s not a show-stopper, I agree. I was just being cavalier with that remark. I’ve had a few people suggest AppleScript as a replacement for those bookmarklets, which is a fine solution, I guess, but it somehow feels a bit like a cheat.
Khoi, I tend to agree with you re embedded browsers, especially on bookmarklets—whenever I’ve used an app with an embedded broswer, I’ve quickly wanted access to my most used ones.
In the short term it’s somewhat mitigated by System Services that can interact with form elements in WebKit views (as opposed to Gecko, which, at least for the moment, can’t.)
In the longer term, apps (with web views) that don’t include bookmarklets are undermining the value of the embedded browser—perhaps only with so-called ‘power-users’, but that’s not really the point, bookmarklets aren’t that difficult to drag to a toolbar, and a developer could deliver bookmarklets to extend their app in specific ways.
Ideally apps wouldn’t limit bookmarklets to publisher-provided ones only, but allow all comers, allowing custom workflows—the smart developer would do both, perhaps elevating their own bookmarklets within the UI, via special toolbars, buttons/icons, and dialogue/sheets (witness the ‘native-chic’ of Javascript dialogues in Camino.)
Imagine a browser view that is customised around bookmarklets and interacting with forms (mapping and showing keyboard shortcuts, tab order etc.) Multiple inputs for bookmarklets could be parsed and displayed in sheets, and associated with keyboard shortcuts, in a very simple facsimile of a Sherlock-like interface.
Having a browser embedded within an application like NetNewsWire is interesting; at what point is the application a news reader with mini-browser, or a browser, with a very studly bookmark sidebar? Esp. when combined with Smart Groups, scripted feeds, etc.
Are we inching toward the Microcontent browser?
Marc, you bring up a good point. When, in my post, I kind of disparaged the general idea of embedding browsers, I didn’t mean that there was no merit to the concept… such browsers can be very useful if treated with a bit of ingenuity. Some of what you describe above in terms of embedded browsers would make the NetNewsWire 2.0 browser much more useful, for instance. And of course, that does lead us down the road of micro-content browsers, which I think can be very powerful.
In fact, one of the best micro-content browsers ever made is probably running on your Mac right now in the form of the iTunes Music Store. That’s an example of an embedded browser that’s not just an instance of Safari—it’s been tailored to meet the specific needs of the content it’s meant for.
Khoi, you’re exactly right, the ITMS is an easily overlooked example of a tightly integrated desktop/web hybrid, especially as it’s not a WebKit view, but a purpose-built XML-described UI parsed within iTunes.
...in terms of the more general-purpose browser angle, I’d been thinking of the Mozilla Amazon Browser as a pretty good example (as opposed to the app-specific, locked-down ITMS model.)
The power of XUL plugins for FireFox is compelling, but like Hicks, I’m holding judgement until the ‘Acquafication’ release, to see if I can make it a home (preferring Camino for work, and Safari/Saft, OmniWeb elsewhere… Shiira’s nice, but it too lacks bookmarklets at the moment!)
As an aside, I’m a bit conflicted about wanting the Camino guys to merge their Mac-specific changes into the main Mozilla trunk—I really like the Mac-feel of Camino, but also value the network effect of using FireFox, and the configurability (elegance v flexibility… I want both!)
It is interesting to look at the flux in UI techniques that’s gaining steam… we’ve long had Sherlock as an XML declarative interface shell, I’m sure many have thought about Safari+Sherlock as Kottke opined, and of course Mozilla’s XUL ambitions, the high-profile ITMS, and Dashboard, Avalon etc. etc.
...interesting times!
Re NNW2, if you look at Shiira, you see the relatively limited effort required to produce a usable browser via the WebKit (if you’re not trying to be as ambitious as OmniWeb), mainly re accessing Safari bookmarks/history… it wouldn’t take much for Ranchero to add basic access to these items, along with a custom toolbar for bookmarklets and favourites… but of course embedded browsers are a bit controversial, whereas obfuscating things a bit more a la the ITMS, can help assuage the doubters.
If NNW2 were to go the way I’ve described, it could become extremely useful as an information hub. Paired with a blog, and blog editor it could be a useful information/knowledge/collaboration app, but in this regard, something like Flow (http://www.near-time.com) is more appopriate (purpose-built)… I’ve been bugging them since beta testing to add bookmarklet support as a first basic move in this direction.
Dunno if you’ve seen it or not, but another nifty news reader that’s up and coming for the Mac is NewsFire ( http://newsfirerss.com ) from the creator of the fabulous Acquisition ( http://acquisitionx.com ) P2P client. It’s got a simple and elegant interface that I find very appealing and easy to use.
NewsFire is quite elegant. But I think it’s a case of beauty at the expense of substance. I couldn’t see myself using NewsFire for a particularly long time because it doesn’t allow enough flexibility. Still, I applaud the authors—they’re also responsible for Acquisition, which is incredibly slick.