Designing for Mobile
The workshop I attended was excellent, and I'm going to do a separate post writing about it. In the meantime, here's the notes on all the other little panels I attended.
Tagging in the Real Web World
Thomas Vander Wal, who coined the term "folksonomy" gave this largely uninteresting lecture. He explained the history of tagging (archeologists putting a literal tag on an arrowhead which contains data about the object), and the purpose (to provide an identifier and description that can be used for sorting). He also talked briefly about how tags are being used online today on sites like Flickr and Delicious.
After that, he defined Folksonomy and got into some overly complicated theories about how and why it works. It was pretty confusing because on one hand he was saying that tagging is a purely personal thing, and that you should never use other people's tags, only your own personal ones, or the meaning would be diluted. But then he went on to talk about the community aspect, which seemed contradictory.
I was most interested in this lecture because I'm planning on switching to tagging instead of categories on my blog, but he specifically said that he doesn't apply Folksonomy to blogs, because when the tags are applied by the content creator, they're just adding ad hoc categories and keywords (well, yeah).
Scaling for Your First 100k Users
Matt Mullenweg, the guy who created Wordpress, Ping-o-matic, and Akismet, gave a fascinating talk about how to prepare for your first 100,000 users. After giving a bit of background into the projects he's worked on, and revealing that he's only been programming for four years(!), he explained that your first 100,000 users will be your core group of unique and passionate users. Getting them is a challenge, and once you have them, you'll have enough inertia to keep growing and face a new set of challenges. To get and keep them, he gave his 12 rules:
- You have to be your most passionate user. Use your product as much as you can, and more than everyone else.
- Get off the computer. The medium you're working in can shape the message and the product. Try using paper instead, and carry a notebook.
- Obsess about the details. There is no single killer feature - there are thousands, because it's different for each user. Pay attention to every little detail, and be anal.
- Do your own support. If you're not feeling the pain of your users, you're not going to be able to address it. To this end, make it as easy as possible for your users to contact you by email, IM, and even phone.
- Blog every step of the way. This lets your users feel involved, and people will be rooting for you because they can see how hard you're working.
- Have a great tagline. Be able to describe what you're doing in five words or less.
- Speak in the context of the people you're talking to. Don't say "we're the best," say "we make it easy for you."
- Get the first version out as fast as possible. You will be most successful in something other than you started with, so you have to be flexible and roll with the feedback as early as possible.
- Measure your success. You've got to have metrics, to say "If I get to X, I succeed." Identify your core metric and track is religiously.
- Know what to do if you're successful. Goals are no good if you hit them all the time. Have a plan for success.
- Start strong and end strong. Show them something great to bring them in, and then remember that their last impression of you might be the email you're sending now, so check your spelling, links, etc.
- Most Important Be a painkiller, not a vitamin. Tylenol does $800 Million in business, while vitamins only do $300-400 Million. Look for the real need.
- Start with fewer features than you think you need. Adding features is easy, but removing a feature is like pulling teeth.
- Try to get to the core of what people are asking for. They can't ask for what they don't know they need.
- Do you really want 100,000 users? The answer is not always yes.
As you can see, he tacked a few extra points onto the end, but he was so enthusiastic that no one minded. Matt is a young guy, and despite his incredible experience, it's fascinating to see that he's only been at this for a few years, and is learning every day.
Bulletproof Web Design
Dan Cederholm of Simplebits presented this, and I'm afraid to say I didn't take many notes, because almost all the content was straight out of the book. It was no less fascinating for that, but it seemed silly to take notes when I have the book on my desk. If you haven't read the book, you absolutely should. It's all about writing your CSS to allow for oddball situations and circumstances (hence, bulletproof).
Improving Front-End Architecture
Garrett Dimon, who writes for Digital Web Magazine gave this talk, and while the first half was interesting, I was totally falling asleep during the second half. The problem is that at first he was discussing what FEA is, and why we should do it, and the second half was really specific into techniques and details that I just wasn't very interested in. Ryan was at this with me, though, and he seemed to be completely captivated, so maybe it was just me. In fact, after the event, Ryan chatted with the guy about their shared frustration with developing for standards in .NET, which later showed up as a post on his site!
The core argument he made during the talk was that FEA is an investment in the future. It takes more time and money up-front to do thing correctly, but it pays off in the long run. He discussed the idea of Software Entropy, which is the myth that once you build a site, it's done -- but the reality is that you'll be spending money on it forever, so it's smart to invest money up-front. He encouraged us to be "Proactive instead of Reactive" by anticipating the impact of our actions. "If I write this code, will it hurt us later on?"
I was most interested when he discussed "The Myth of Separation," where he explained that the loose coupling of content and style is a target, not a goal. You're never going to acheive it 100%, so just do the best you can and don't stress about it. This led into the idea that what you support affects how you build your site, and he remarked "The sooner we stop supporting IE6, the happier we'll all be."
Design Patterns for the Web
James Reffell from eBay and Bill Scott from Yahoo gave a joint discussion about design patterns. The guy from eBay discussed all the false starts they had, ranging from putting out a book (which was obsolete the day it was printed, and actively dangerous within six months) to setting up a wiki-style site. The guy from Yahoo echoed these difficulties and they agreed on several points, including that design patterns only work when people understand why they exist. They can't be too specific (pixel measurements) or too abstract (use a clear path). They have to be fast and easy to update, and once it goes open-source it will start getting more use. Finally, early on you may need to bribe people to use and contribute to the patterns.
Design Panel
I was really looking forward to this, because it featured some big names. Bryan Veloso of Avalonstar was moderator for Dan Cederholm, D. Keith Robinson from Blue Flavor, and Mike Davidson from Newsvine. Unfortunately, a large portion of the discussion they had was based on the idea that web designers are too interested in tools and techniques and not interested enough in design. However, as I've discussed before, I think this is an artifact of the way web design has evolved as a field. As CSS and web production becomes its own niche, rather than being something the designers themselves do, this won't be such a big deal. This has already happened in print - the designers aren't the guys running the printing presses, they just need to know how to talk to those guys.
The New Community
Derek Powazek, the creator of Fray and JPG Magazine, gave a talk titled "The New Community - How Decentralized Conversation Empowers Individuals while Creating Community." He thanked us for coming to the last panel of the day, with the longest name. His presentation was an update to a book he wrote in 2001 called "Design for Communities."
To start with, he defined Community as "When people can use their voice in a public and immediate way, forming intimate relationships over time." He said that if Web 1.0 communities were Company Towns where you could use your voice, but only in the format and rules of the boss, then Web 2.0 communities have moved into the suburbs. Everyone has their own house, and the blogs, trackbacks, links, etc. are the roads connecting the houses.
As an example, he discussed BoingBoing getting rid of comments entirely, and linking to the Technorati page showing who's discussing their post. When they got tired of the crazy angry comments on everything they posted, they did this as a way of discouraging trolls. It raises the bar for people willing to post because only people in the community (with their own blogs) can participate, and they're less likely to post garbage because no one wants to graffiti their own house! This has the effect of improving the conversation. He was quick to point out, though, that modern Company Towns aren't going anywhere - and pointed to Flickr, YouTube, MySpace and TypePad as examples.
When you post on your own site, you're (in theory) talking to everyone, but he argued that this doesn't mirror communities in real life. We say things to our family, for instance, that we wouldn't say to our church group or coworkers. Moving forward, he thinks we're building towards a more community-based means of posting, where talking to everyone will be the anomaly, because small communities reward this kind of intimate participation. He also remarked that "There is less of a benefit to being a dickhead in a decentralized community."
What this all means is that you need to treat your community well, or they'll leave. Also, you can't create a community, you need to go where your community is, and if you're lucky, they will let you "visit." As an example, he pointed out that JPG magazine didn't try to create a new community, they went where the community already existed on Flickr and managed to co-opt that into something new. Similarly, Tivo found a thriving community on a public board and are now supporting the public forum, rather than forcing everyone to play by their rules in their company town. If you create tools people like to use, your users will start to feel community.
In the long run, we want the best parts of both the decentralized community (which is more free, but requires more work) and the company town, and we want it with less of the mess and work.
Speaking of Derek Powazek, see the entry over on my personal site titled "I was Accosted by Derek Powazek!"