Archive for September, 2006

Rojo relaunch

Thursday, September 21st, 2006

I’m not a UI guy nor have I ever relaunched a web app. But I noticed a few things about the recent Rojo relaunch that I find could have been done a whole lot better:

  • I’m missing some features I really liked (browse by most-read)
  • Some URLs (bookmarks) don’t seem to be working anymore
  • Navigation has changed significantly
  • Mark as read behaves differently now than it used to (items marked as read still show up)
  • Most of all, I wasn’t aware of any of these changes beforehand (presumably because nobody at Rojo had told me), and even now — a few days into the relaunch — I can find no information on the site whatsoever that would explain the whats and the hows and the whys (presumably because there simply is none or it’s too hard to find).

There’s still a slight chance that underneath all the surprise changes there lies this awesome web-based RSS reader.

Or maybe it’s just that time of year again to switch.

The comments of crowds

Sunday, September 17th, 2006

Jeremy Keith is experimenting with comments: The comments of crowds

… Traditionally, comments are visible, thereby influencing future comments. That’s good if you’re trying to stoke a conversation, but lousy for getting some honest feedback.

So here’s what Im going to do:

I will occasionally open up some posts for comments. You will be presented with the usual form: name, email, url, etc. I would greatly appreciate getting your opinion. However, your comment will not be published immediately.

Comments will remain open for a set period of time; sometimes a week, sometimes a month. At the end of this time, all the comments will be published at once. At this point, it will no longer be possible to add a comment.

Nice blog, see for example this post: Backlash 2.0

Wintertime — and the coding ain’t easy. Sharks are jumping and the bubble is high.

Web 2.0 isn’t a cluster of technologies, it’s a way of thinking about data, design and user experience.



Friday, September 15th, 2006

The Citizendium Project

The Citizendium (sit-ih-ZEN-dee-um), a “citizens’ compendium of everything,” will be an experimental new project. It will begin life as a “progressive fork” of Wikipedia. But we expect it to take on a life of its own and, perhaps, to become the flagship of a new set of responsibly-managed free knowledge projects. We will avoid calling it an “encyclopedia,” because there will probably always be articles in the resource that have not been vouched for in any sense.

We believe a fork is necessary, and justified, both to allow people a place to work under the direction of experts, and in which personal accountability–including the use of real names–is expected. In short, we want to create a responsible community and a good global citizen.

The Citizendium will be launched as soon as possible, meaning within a few weeks at most.

Read the essay, Toward a New Compendium of Knowledge (longer version), for a more in-depth introduction to the project.

Is it just me, or is the space of online deliberation, citizen participation etc. picking up speed?

Via Tim: Öffentliches Wissen (in German)

Carl Sjogreen — How we built Google Calendar

Friday, September 15th, 2006

Some quick take-aways:

  • The road to Google Calendar: In the beginning, a largely “classic” google product team (1 product manager and 3 engineers), origin from both customer feedback & internal interest, seemed like a space with little innovation, nothing out there was “right”. Vague idea: “Google should do something in the calendar space”
  • First things first — go talk to “real” customers: Sounds cliche, but it’s amazing how little it’s really done (btw, “real” customers, not your Silicon Valley geek buddies)
  • Spoke to many people, sometimes even in their homes: Students, families, schools, working couples, PTA organizers. Tried to find a whole spectrum of different technical backgrounds. Kept probing: busy is not the same as “needs a calendar” (e.g. students may be extremely busy but may stick to a pretty regular calendar. Maybe “busy + irregular calendar” is more of a sweet spot)
  • Key themes emerged quickly: Calendars are necessary but just a chore, calendars are really personal and emotional, calendar “collaboration” is just too hard
  • Vision — it’s important to have one: You have to have a vision, a larger idea (otherwise, you might be building a feature list, not a product). Vision for Google Calendar:
    1. Fast, visually appealing, and joyous to use
    2. Drop-dead simple to get information into the calendar
    3. More than boxes on a screen (reminders, invitations, etc.)
    4. Easy to share so you can see your whole life in one place
  • Development: Lots and lots of prototyping, focused on getting interactions and user model right before thinking about scale (scaling is a significant challenge for Google).
  • Keep in mind that your early users might not be your target users, make sure you talk to actual, real users!
  • Once they felt they had it mostly right, worked on making it real: Backend infrastructure designed for scale, frontend UI rewrite to pixel perfect mockups + static HTML, doing all the hard parts (recurrences, parsing iCals, API testing, interop, etc.).
  • Worked on UI design in stages as well: Get the interactions down and try them out, focus on the look & feel while engineers are making it real, save the pixel pushing for when you know you have it right.
  • Private betas are a good thing: Even with all the internal testing, learned a ton from testing with a small group of “real users”
  • 6 key insights that might be useful for your next product or company:
    1. Easy is the most important feature: Always have an eye on the minimum useful feature set that most people will use. Product usage tracks directly to how easy a feature is to find and use. Figure out what you absolutely have to get right and relentlessly refine it (keep redesigning if necessary). Don’t spend too much time on the less important areas (i.e. know where you’ll get the most bang for the buck).
    2. Know your real competition: Know what your competitors do well. Google spent a lot of time looking at the market (online and desktop), but the real competition may be paper (non-tech and low-tech mechanisms are the way that most people communicate and interact, and paper has a bunch of great advantages that you need to beat, e.g. easy to carry with you, doesn’t require boot time, doesn’t require a login etc.). Focus on removing the hurdles to adoption. Focus on what the web can do that paper can’t (e.g. collaboration, access from anywhere)
    3. Visual design matters: Usability is important, but visual joy is key (helps to creat personal connection).
    4. Build products for people who don’t want to use them: Not everyone who can benefit from your service actually wants to use it, changing behavior and workflows are very, very hard. You need to make it as easy as possible for people to use your product with as little work as possible. Get your product in front of the applications people use every day: Can you integrate with email in a meaningful way? Can your install something on the desktop (links count)? Can you integrate with Google’s applications (home page, toolbar, desktop)? And then make it painless for people to start using your product without fully switching into a new way of doing things.
    5. Timing launch properly: Launch early and often, but not too early (the first time around). Launch early and often is the mantra of web companies, it is a fundamental structural difference that sets web companies apart from packed software. However, the old adage of “you can only launch once” still applies. Leverage internal testing and private betas to get feedback early, but make sure that you have something worthwhile once you land on Digg, Techcrunch etc. Launching is hard to do (it’s never an easy call): Ask yourself if you could really see your target user using what you have at day 1, or switching from something else.
    6. Driving usage: Think about how your product can generate touchpoints that extend beyond your app (and make it easy to do so): “Add stuff from my site” (remind me with Google Calendar), “publish stuff” to my site (embeddable calendars), “tell a friend” (invitations & sharing). Social reinforcement is key for validation: My friend telling me to use a product is ten times more valuable than hearing it from the company. Make social reinforcements easy. Relentlessly remove account signups: This is pretty obvious, but it was surprising to me how much of a barrier accounts can be.

Stumbled upon at The Future of Web Apps Summit, San Francisco, CA, September 13, 2006 (wiki).

Tom Coates — Directions in social change on the web

Friday, September 15th, 2006

Tom Coates of Yahoo! UK gave an excellent presentation:

Below are a few things to remember. Make sure you check out the whole presentation/podcast once it becomes available (sorry for paraphrasing):

  • Topic of his speech: How people can interact to make something that’s greater than the sum of their parts.
  • Social successes: Sites that are harnessing collective intelligence are doing well.
  • People function better together than alone.
  • How can you use social software to build aggregate value? In a nutshell:
    • An individual should get value from their contribution (individual motives)
    • These contributions should provide value to their peers as well (social value)
    • The organization that hosts the service should derive aggregate value and be able to expose this back to the users (business/organizational value)
  • There are two ways you can go about doing these three things: Consensus (e.g. Wikipedia, ridiculously difficult and unlikley, hard to replicate) or polyphony (e.g. Flickr, works very well, supports infinite communities)
  • Motives: What drives users to participate?
    • Someone once said: “The only reason anyone does anything in the world is money, power and to win.”
    • Someone else once said: “There are only two reasons, and they are: To get laid, and to please Jesus.”
    • Peter Kollock, The economies of online cooperation: Anticipated reciprocity, reputation, sense of efficacy, and identification with a group
    • Various authors, Open Sources: Voices from the Open Source Revolution lists the following (in order of importance): 1. Learning to code 2. Gaining reputation 3. Scratching an itch 4. Contributing to the commons 5. Sticking it to Microsoft
  • Be wary of clumsy incentives like money, points & competition. You have to be able to reward the right kinds of activities. The problem with money and points is you often end up rewarding the wrong things (there are exceptions).
  • Richard Bartle, Hearts, Clubs, Diamonds, Spades: Players who suit MUDs: Users may move between these types (i.e. socializing, discovery, combat etc.), and — at times — be more of one than the other, but if you’re lacking any one of these types in your community it can fall apart. You have to have a variety of users in social software to create something sustainable. If you reward only one group, the whole thing will fall apart (and you can’t reward without making the site generally less useful).
  • Expose metrics in many ways so people can be competitive in different arenas.
  • Open up social value: Expose every axis of data you can, give people a place to represent themselves, allow them to associate, connect and form relationships with one another, help them annotate, rate and comment, look for ways to expose this data back onto the site, make space navigable, allow for adding on top of that, aggregate data.
  • Be very careful of user expectations around how private or public their contribution is!
  • APIs are cool.
  • Be wary of creating monocultures or echo chambers.
  • Where’s the money?
    • Attention and advertising
    • Premium accounts
    • Building services around the data
    • Using user-generated annnotations and contribution to improve your other services

Overheard at The Future of Web Apps Summit, San Francisco, CA, September 13, 2006 (wiki).

Kevin Rose — The digg story: from one idea to nine million page views

Friday, September 15th, 2006

Some insights from Digg’s Kevin Rose that I though were interesting:

  • Starting with a “basic” (i.e. really crappy) design can actually give you more street cred (”they didn’t even try”)
  • Start extremely grassroots. Hit a core audience of users who want to make the site a better place (even today, Digg still has 20-30 features that haven’t been rolled out yet, because they want their user base to be able to understand the way the platform is going)
  • Digg never spent any money on advertising. So far, simply WOM by people using the site.
  • It’s important to learn what the users are doing and why. Make it more interesting for users and provide new ways for discovery.
  • Give your developers some extra (free) time to just play with things and develop stuff they think is cool (see Google’s 20 percent time)

Overheard at The Future of Web Apps Summit, San Francisco, CA, September 13, 2006 (wiki).

System One: advanced wiki made in Austria

Friday, September 15th, 2006

This looks interesting: System One screencast (via Techcrunch).

From their site:

System One combines human intelligence and machine power in an intuitive web-based application.

And from the screencast:

System One filters the information flood — individually, relevant, in real time.

I met Bruno Haid, System One’s Head of Strategy, at the Hyperscope 1.0 release party in Menlo Park last week. I look forward to talking to him some more at the upcoming Blogtalk Reloaded conference in Vienna.

Interesting, too, how we just saw the demo of Aachen, Germany-based Mnemomap at the recent Web Monday Silicon Valley, who are trying to do similar things on the public web.

Web Monday, September 18: Bremen, Berlin, Jena, Frankfurt, Bielefeld, Münster (and maybe Vienna)

Thursday, September 14th, 2006

Folks, it’s time once again to head to your local Web Monday meetup this Monday, September 18, and mingle with your fellow developers, designers, podcasters, entrepreneurs, researchers, journalists, Second Lifers and whoever else is into the future of the web (numbers in parentheses show number of registered attendees to date):

You know what to do.

Please spread the word and help share what you’ll learn: put your notes on the wiki, blog about the event, take some pictures, maybe make a podcast even? The possibilities are sheer endless.


Monday, September 11th, 2006

In case you haven’t seen it yet, this film is one of the most stunning (and sad) documentaries ever:


On September 11, 2001, filmmakers Jules and Gedeon Naudet were filming a documentary on a rookie New York City firefighter when they noticed a plane overhead. That plane would hit the World Trade Center. The firefighter and the Naudets rushed immediately to the scene. The Naudets filmed throughout Sept. 11 and the days afterward from the firemen’s perspective, as it became clear to them that this was the only known footage from inside the Twin Towers that day.

Today, five years later, where do we stand? Do we have a good understanding of what is going on in the world around us? Can we identify the right threats? Have our responses been wise enough? Are we making the right choices? What are our goals? And what is the moral compass by which our actions should be guided?

Barcamp Nuremberg

Saturday, September 9th, 2006

This just in:

BarCampNürnberg, Germany (01/20-01/21)

So if you live in or around Germany, and can’t make it to either Barcamp Brussels, Belgium (09/24) or Barcamp Vienna, Austria (09/29-09/30) or Barcamp Berlin, Germany (09/29-10/01) or Barcamp Zurich, Switzerland (10/28) or Barcamp Copenhagen, Denmark (11/17) — this may be your chance to get a piece of the action.

In the meantime, Web Monday Nuremberg might be shaping up, too.

Update 10/05/06: Barcamp Nuremberg has been rescheduled for December 16/17, 2006!