Tag Archives: web apps

The Merits Of Online Publishing

Jason Fried of 37 Signals, the guys behind web applications like Basecamp and Tada List and Backpack , have published a book on how to build web apps. And they’ve proven a point — that publishing online can be the smart way to go. Jason tells me they’ve sold 4,000 downloadable digital copies of their new book Getting Real in the first week — at $19 a copy, or $49 for a site licence that allows users to make up to 10 copies for co-workers.

That’s $85,000 in pure profit, Jason says. Which I have to say is pretty good. I can’t imagine the same thing would happen, or does happen, for every tome. I asked Jason why he thought the numbers were so high. Here’s his response:

  • It’s easy. buy it now, get it now. you just download the PDF
  • we’ve been talking about our Getting Real process for a long time on our blog, and now people can get the whole thing in a $19 book
  • Lots of interest in how we work. How we’ve been able to build 5 products, write a book, and write Ruby on Rails in 2 years with only 7 people

Interesting. In other words, if a book really adds value to something that has already attracted a lot of interest, you have a ready audience. Even if you keep a blog, and tell everyone what you’re doing and how to do it, there will still be people interested enough to buy the book to read more. And $19 isn’t cheap: That’s a hardback book where I come from, but somehow online, being able to just grab it in PDF in a second, somehow makes the price seem reasonable. As Jason puts it:

I think there’s a big story here… The idea that authors with audiences don’t need publishers anymore. You can take your message direct to your audience. AND you own the rights to your work.

Online Calendars – An Opportunity Lost?

A great piece by Joel Spolsky on calendar software, where he complains that all these online calendars don’t really offer very much, are half-baked and may just be efforts to attract buyouts from the big boys:

For all the Ajax calendars that are appearing, it’s a shame I can’t find one which really meets my needs. I tried out Trumba, Kiko, 30 Boxes, Yahoo! Calendar, and Spongecell. I couldn’t recommend any of them.
My needs are probably weird, but not that weird.

As Joel then goes on to point out, actually these calendars allow very little customisation, and surprisingly little basic functionality, such as alarms, events that don’t fit neat intervals (like flights) and making some events private.

I’ve tried a few of these offerings, and I’d tend to agree with Joel. All the calendars I’ve tried are basically reruns of offline software, but without many of its deeper functionality. There are some nice elements — Trumba’s way of showing events that span more than a day is quite nice — but most are small potatoes in the face of a much greater potential. Surely calendars, of all Web Apps, should be almost endlessly customizable, given that their job is to try to reflect as accurately as possible the endless weirdness and variety of our lives? When was the last time you met someone who had even vaguely the same kind of habits, schedule and needs as you? We’re all different and calendars, of all things, should reflect that.

Let me offer some suggestions, just in case you’re not following (and any of these calendar developers are listening):

  • viewing options: If we’re going to go to the effort of entering all this data on your website, the least you can do is to offer us multiple ways of viewing said data. I’m not just talking boring day/week/month/listings, but color-coding time off, time on; how many 3–hour workday slots are still open in February; how many hours I’m spending in meetings with Client A; the best options for a long weekend where there are no, or few events on Friday or Monday.
  • synchronize with other calendars, especially Outlook. How many people are going to spend time entering data into an online calendar but not have an offline one? (Trumba offers synchronization with Outlook but I must confess: I haven’t managed to make it work properly yet.)
  • anticipate me: If I’ve entered a repeating event, say, notice it and ask me if I’d like to repeat it automatically. If I keep making the same trip figure this out offer to auto-fill the details next time I start entering that data in the calendar.
  • minimise the clicks: Let me enter data, including labels/tags/categories into the calendar. I don’t like pop-up windows, and I don’t like moving between fields if I can help it. Let me just type “Meeting Bob Conference_Room 12:30 Tues” and let the calendar do the heavy lifting: “Meeting” gives the event a specific color and label, Bob is a name from my address book and so can be automatically filled in with family name and company affiliation, “Conference_Room” is clearly a place, and so can be assigned to that field, if it exists, while the time and the date/day are self-explanatory (why would it be anything other than the next Tuesday coming up?) This saves us time (which we don’t have much of; that’s why we’re using a calendar) and it also helps build a database to let us slice and dice our information later (when am next meeting Bob/using the conference room/having a lunch time meeting?) (30 Boxes and spongecell offer something like this feature, but there are still too many dialog or OK boxes inbetween, and spongecell’s syntax was eccentric at best.)
  • move me: drag and drop, extending or shrinking events using the mouse should all be standard.

There are hundreds more ways that calendars could be more dynamic. I can hear the calendar developers already popping up and saying “You should check out this feature in our calendar” or “We’re working on just that feature in ours”. But my experience is that in fact most of these calendars don’t really have it. They may have one or two interesting new ideas, maybe even one that makes you go ‘wow!’, but there will always be some basic function that either isn’t there, or doesn’t work well. With calendars, it either works as a whole experience or it doesn’t work at all.

As Joel says, the trend these days is to get the stuff out there and add features later. That may work with other tools, because for the most part you can always switch to something else if those features are slow in coming. But a calendar needs to work well for you out of the box. After all, it is your life and you’re not in the mood to put it on hold for the promise of future features, future bug-fixes (how long are you going to stick with a calendar if it makes you miss an appointment?). As Joel puts it:

I’ve talked about this before — it’s the Marimba phenomenon — when you get premature publicity, lots of people check out your thing, and it’s not done yet, so now most of the people that tried your thing think it’s lame, and now you have two problems: your thing is lame and everybody knows it.

A calendar is the thing we build our lives around. Think hard about what you’re offering before you ask us to commit our daily schedule to it.

The Fast-moving Backpack

At the risk of becoming a PR machine for 37 Signals and Backpack, they’ve come out with another interesting feature, this time an API:

Jason Fried tells me that the API will mean “developers…can now build on top of Backpack their own apps, pull Backpack data into their own systems, push data to Backpack from custom apps…” These include “Palm apps, Symbian apps, desktop apps, other web apps… dashboard Widgets for Tiger… you name it.”

“Backpack becomes a platform. Over the next few weeks we’ll see some cool stuff.” One example: Polling a Backpack page to pull book data from Amazon, where Amazon reading lists maintained in a Backpack list are turned into an aggregated list. Interesting stuff.