Know any decent web designers? In the Seattle area? Who are looking for a part-time gig? I'm looking for one. Check out the job description. We're located on the Ave in the U District, making this a great position for a UW student, either advanced undergraduate or graduate student (or even a recent graduate looking for a part-time position). We're doing some pretty cool things here, and it'd be a chance to work on a site that is used by tons of teachers and students around the state. Plus, you'd have a good boss. :)
Go read Jeff Veen's wonderful rant about "interactive design." In many ways, he says, designers haven't moved very far from the early attempts at web design.
Most of what I saw was a strange blend of fast-paced television commercials and the "Choose Your Own Adventure" books I liked so much a kid. Everything was designed as over-produced "click here for the next Flash movie" interaction. Which is to say, it wasn't interactive at all. What I quickly realized was that the work I was seeing reflected designers refusing to let go of their perceived control.
A funny little thing I just noticed: well-known blogger Dave Winer pointed to an article on the Seattle Times website. He attributed the story to the Seattle Times, but a quick look at the actual story says they're just re-publishing a syndicated story from, in this case, "Knight Ridder Newspapers and Newsday." Nothing unusual about that. But, I'm willing to bet that the reason Dave linked to the Seattle Times site (and gave it credit) was because the Times offers RSS feeds, and Dave probably saw the item in one of the feeds. If my little theory is right, then this is yet another good reason for content providers of all stripes to offer RSS feeds...the more ways you offer access to your content, the higher the likelihood someone will notice and tell others. It is not exactly groundbreaking, but a point worth noting.
A long time ago, I threw together a simple technique for created expanding nested lists. So, when I saw this item flow past in my RSS reader, I thought I'd check it out. The gazingus.org version takes a different approach, but it looks to be a pretty good one. Check it out...
...they just fade away.
Sorry.
Anyway, I ran across a couple of nice-looking implementations of the storied Yellow Fade Technique, complete with code:
I've been waiting for this little utility for quite some time now: a Firefox extension that validates every page you view. Doing HTML validitation can often be something of a pain if the documents in question live behind some sort of protection (firewall, authentication, etc.). The method I had been using, especially if the page was dynamically generated, was to load the page, do a "save as," then upload the file to the validator. Needless to say, this wasn't a smooth process. This little extension takes that away. If you can see the page in your browser, you can see the validation (in the form of a nice little icon in the bottom right hand corner). Sweet.
The only other browser I've seen with this built in was iCab, a mac-only browser that would display a smiley face or a frown face depending on the validation state. Unfortunately, it wasn't at the same level as the major browsers in terms of CSS support (and a few others things) when I last tried it a couple of years ago.
[Updated with other links to Basecamp-related articles at the end.]
I attended the Building of Basecamp workshop in Seattle (just up the street from my house) a couple of months ago, and I’m finally getting around to commenting on it.
I found the workshop to be valuable experience. All of what they said was thought-provoking, and some of the methods and techniques discussed I put into use immediately. But, anyone going to workshops like this needs to know that no method or system is a magic bullet. You’re not going to be able to do a “copy ‘n paste” from what you’ve heard into your organization. Most of the folks at the workshop, I’d guess, weren’t coming from a similar situation as the 37Signals team (building a product in a small firm), so not everything will fit cleanly. Indeed, I’ll point out some of the ill-fitting pieces later. But, you should be able to apply some of the methods you’ve learned in specific situations.
By way of background, the 37Signals team spent the day talking about the principles and practices they used in developing and running the Basecamp project management web application. In short, a small team (3 people) created a very nice web application that has turned out to be very popular, and quite useful, too.
I’ll start with the principles. They discussed their “mantras” – I think I prefer the term “shared values” (even though that makes me sound like a management dweeb). These were phrases or concepts that the team used to guide their decision-making throughout development. The two most important ones were “Less Software” and “Say No By Default.” The team made a conscious effort to write only as much code as was needed to get the job done. They—wisely, I might add—realize that every line every feature has a cascading string of implications. While writing the code for a feature might be easy, it needs to be tested, maintained, and integrated into the rest of the system (does the feature require other supporting features?). They get to the point of writing less software by saying “no” to feature requests. They really worked to make each feature prove it’s worth. They would slow down, and not take action on an idea for a week, and make sure it was truly a good idea before implementing it.
Next, they explained their development process. In my mind, this process looks like a simplified and quite functional iteration of the “extreme programming” or “agile programming” concepts. The main idea, as they put it, is to get to “real” as quickly as possible. This means not spending time writing long functional specifications, but rather focusing on creating paper prototypes, then HTML mockups. This idea I like a great deal, and have been using it more and more at work. It really gives everyone, from designers to programmers to clients or other stakeholders, a common ground to work from. Words in specs can (and are) misunderstood. HTML mockups are much more concrete. Then they move to prototyping, where they program in just the functionality needed to make the mockups come alive, and finally launch and maintenance.
I’m really just scratching the surface of what they said. I really do encourage you to go to the workshop, as they have a lot of good ideas about each of the things I’ve mentioned and more. But, I’d like to spend a little time critiquing the methodology. Most of my critiques apply to attempting to take their system and apply it a dissimilar situation. You might find these more or less of an issue than I did.
A team’s shared values (“mantras”) must truly be shared amongst all the team members. I didn’t really hear much about how 37Signals developed their mantras, but I’d imagine that they just arose out of many conversations and time spent working together. Concepts like these won’t work if applied to a team in a top-down manner; at least, they wouldn’t be nearly as effective in that situation. And heaven forbid if not all the team members buy into the values. Disagreements about indentation or some other minutia of code style are bad enough, but if not everyone bought into, say, the concept of saying “no” by default…well, I imagine the results wouldn’t be pretty. So, how do you get a team to coalesce around some set of values? Well…that’s what a good manager is for, I guess. Still, I’d caution anyone against trying to unilaterally apply 37Signals’ mantras in their team.
You may have noticed in my high-level fly-by of their process, I didn’t mention anything about testing. I’ve been schooled in the church of user-centered designed and methodologies that rely heavily on user testing. These guys, by their own admission, didn’t really test at all. But, they got away with it, in fairly spectacular fashion. How? Clearly, much of credit goes to the team that built the product. They all had a great deal of skill and tons of experience. They were focused on created a usable product, even if they didn’t employ traditional usability practices. Skill and experience can, I think, make up for testing to a degree. At some point, you know what the UI trouble spots are, and you can create designs that avoid the common traps. Plus, they were willing to iterate the design aggressively to address problems as they arose. But, for teams without incredible designers on hand, I think the tried and true UCD processes can be very effective.
The 37Signals guys had a couple of other natural advantages. Because they were, in effect, their own clients on this project, they didn’t have to deal with many of the issues that can arrive when working with either internal or external clients. For example, in a client situation, you’d want to be sure the client understood your team’s shared values and was willing to work with them. If your team fully bought into the “less software” mantra, and you were working with a client that wanted lots of extra bells and whistles, then, well, you’ve got problems. Not everyone has the luxury of choosing to work only with people who “get it,” so I see this as a potentially problematic area.
Finally, they were able to put a fairly tight scope on their problem domain (communication and project management). They were able to focus on three aspects (messages, to-dos, and milestones), and abstract the concepts so they could apply to many different situations. Many people face problem domains that, for any number of reasons, are quite specific and are imposed upon the development team. Sometimes, the complexity and messiness of the real world can’t be easily abstracted or simplified. And the “say no by default” mantra isn’t going to help you here, either (but the other parts of their process quite likely could help).
So, if you go, take good notes (I wish I had taken better notes, and I never got the promised slides in the email) and put some thought into how their learnings can be put into use in your situation.
Interesting conversation about clearing floated elements. I'm all for anything that makes designing simple, clean layouts easier. Update: more to the story.