My single-serving web site, IsAlternateSideParkingInEffect.com was featured in the New York Times Blog this morning.

Alternate side of the street parking, which was introduced by the city in 1952 to facilitate street cleaning, is one of the more burdensome rituals of New York City life…

So how to keep track of the state of the parking regulations, especially since so many of the holidays are set by a lunar calendar, and thus vary each year?

(This is an extended version of an email I wrote to one of the local tech mailing lists here in New York, in response to a developer's question. It seemed generally useful enough that I'm reposting it here.)

A very common design problem in web services project these days is the issue of user search. Most web services now involve pools of data that are far too large to be entirely "browseable", even if we're only talking about finding another user on the service. Very quickly you start to see a specification develop of increasing complexity, involving boolean ("AND/OR") concepts, keywords, and all kinds of other demands targeted at extremely precise results tailored very exactly to the knowledge domain or data set. What's the best way to go about building this user experience?

(This is a continuation of my series on understanding and analyzing web service and software businesses. If you'd like to start from the beginning, go to part one, "Core Value Proposition.")

Monetization

If you've created a service that has a compelling value proposition, and delivers on that promise for its end users, you've succeeded at the most difficult part of building a growing online business. Turning it into a profitable online business, however, takes more than simply making users happy. You have to find a way to generate revenues from your users that doesn't unnecessarily compromise that core value proposition.

There are two primary ways of generating revenue from an online service:

• Direct service charges
• Advertising revenue

This is an extension of an earlier post, which covered how one goes about calculating customer lifetime value (CLV). In this series, I'll be examining the key levers you use to maximize your business, seen through the perspective of CLV.

In my previous post around customer value, I reduced the CLV equation down to two key components:

• How much profit you make off each transaction with the customer - i.e. monetization
• How many transactions you get with the average customer - essentially, retention

To transition this a bit more to a customer-centric, rather than monetization-centric, view, your typical business has three key components:

1. The core value proposition to customers - what do they expect to get out of interacting with the company, service or product
2. The monetization of that interaction - how does the company make money off of delivering the core value proposition?
3. Customer acquisition - how does the company find and acquire new customers that find its value proposition compelling?

I'd argue that for most web businesses, it's all about these three components. Everything else is a support function. Any successful business will have to necessarily address all three of these, at least implicitly - you may not have an active acquisition strategy, for example, but that just means you're implicitly depending on word of mouth or another passive method. If you don't have a value proposition, well, that's somewhat more troubling.

I'll cover these each in separate posts. I'm going to start with value proposition, because not only is it the heart of the business, but it's also the one component you can't take a passive approach to, whereas there is at least (some) argument that you can leave the mechanics of acquisition or monetization until after you've solved the central value proposition question.

Weather24 isn't operating any more because it's just not necessary to login constantly to check the weather forecast outside. We highly recommend the Ambient 7 Day Weather Forecaster (shown at right) for your home or office - I've used one of the older models for years now since I walk the dog several times a day. It's right on the inside of our front door, it's always up to date and it's there when you need it. Setup is essentially just putting in the AAA batteries and finding a place to put it up. For rapidly changing information you need as often as the weather, a dedicated device is the way to go.

Back in September, I wrote a little more about Ambient Weather Watchers when the most recent model came out.

If you'd still like to check your weather online, or you need to look up the weather for somewhere far away from your current location, we recommend the following web sites:

• Umbrella Today?
• Yahoo! Weather
• Weather Underground
• Weather.com

Thanks for visiting!

A week ago I posted about trying to jump completely over from client-based email to only using Gmail's web interface. In particular, this was prompted by the recent availability of offline mail reading for that interface, which made it unnecessary to have Thunderbird downloading copies of all my email so I could work on reading and answering messages when not connected to the net.

Now that's the kind of conversion rate I wish I could achieve more often. Based on a Google Website Optimizer run on one of my sites from January 14th to today, February 3rd. And the best part is that the aggregate percentage has been rising steadily over the past week, which means that the current effective conversion rate may be 5 to 10% higher than this.

My first experiences with email were all server-side applications. Bulletin boards, Compuserve and dialup Internet, then the Athena Unix terminals of my years at MIT. At the time, it made sense - modems were slow, downloading messages took time, and there weren't attachments.

In the interim, I've been a die-hard user of desktop email clients. At my old finance job, I regularly received 100-150 emails a day, which sounds like a lot until you realize that if you're working on 10-12 projects or pitches, that's only 10 emails between team members per day. (Bankers tend to use CC: reflexively, but you are expected to be up to speed on all the threads even if you're not the direct recipient.) I was an Outlook power user by day and a Mozilla Thunderbird wonk by night, plus I carried (and still carry) a Blackberry that gets checked compulsively. (The dog, mind you, gets jealous about how much attention the berry gets.)

Even when not connected to the net, I want access to my email - it's not just a communications tool, it's also a major database of filed information I need when working. But with the addition of offline Gmail access via Google Gears last week, the final issue tying me to desktop clients has been resolved - I can now read and write emails on flights and away from wifi using Gmail.

For the next week, I'm going to try using Gmail's web interface exclusively when at my computer, a MacBook. I've removed Thunderbird from my application dock so I don't open it by mistake, and I've installed Google Notifier in my menu bar so I can see when a new message has arrived. There's a printout of the cheat sheet for Google Mail keyboard shortcuts and I'm going to to my best to force myself to use them so I can get up the learning curve faster. And I'm going to see how using a web-only interface to my email box works out.

I'll admit I'm skeptical... I have a hard time seeing how a web-based app can outperform a "sovereign" application like Thunderbird or Outlook. (Although I was never really happy with the keyboard shortcut support in Thunderbird, relative to Outlook.) But there are a lot of obvious benefits as well, including the ability to get the same interface wherever I can access a web browser. I'll post in a week how it's been, and whether I'll be able to remove Thunderbird from my MacBook permanently.

I'm a huge fan of using patterns when designing web services, especially when it comes to user interaction and non-core tasks. There's a number of reasons why:

1. You can focus on what differentiates your service, rather than re-designing what others have already worked out through trial and error
   
2. Users are happier with interaction flows they expect -- and generally, they expect what they've seen before when using other products
3. If you're working with a team, they'll generally understand and build a known pattern faster  and more correctly than a totally new design, even if the new one might be marginally better
   

Sometimes though, using patterns can get you into trouble even if they do fit the immediate requirements. As part of building IsAlternateSideParkingInEffect.com, I utilized a very standard pattern for validating new users -- sending an email to a user with a unique token, then requiring that they provide the token from the email to the system in order to fully activate their subscription.

Frankly, it worked well -- too well. Only about 50% of users would complete the validation (and I assume that the number of spurious submissions is well below half.) For a service where the risk of a faked registration is almost nothing, the pattern was costing me way too many users in the process of guarding against them. The guards were protecting the front gate, but they were eating all of the villagers' food.

I've since changed the process to an "opt-out" model - when a user submits their email to the site, they are immediately "activated", but every message they receive from then on has an unsubscribe link at the bottom. Making this relatively simply change from the established pattern immediately doubled the yield rate of subscribed users per unique visitor to the web site. It was simply a case where the "best practice" pattern didn't fit with the realities of a very specific service design, and acknowledging that reality.

"We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that."

David Heinemeier Hansson has this evening posted a remarkable missive about the merging of Rails and Merb, two independent but parallel frameworks within the Ruby community.

While the merger itself is huge news for anyone who works with Ruby, Rails or Merb, the letter and the merger are also of broader interest to anyone who follows online communities. In the face of a broad trend of fragmentation, division, and overall entropy within special-interest online communities, the friendly (and, potentially, massively productive) merger of two relatively healthy collaborative programs is worthy of note.

When corporations merge, one of the reasons they always cite is the cost savings from eliminating redundant infrastructure and employees ("synergies") despite the fact that they are seldom realized. Conversely, for volunteer or open-source efforts, this effect is too often overlooked entirely - creating situations like what used to exist between Rails and Merb, where two essentially similar communities were building very similar products in parallel, for a similar user base, and in the process duplicating a lot of effort that in reality was of little consequence to their respective constituencies. By agreeing to "unbranch" these two technology platforms (I use quotes because they did not, in fact, arise from the same original code base), these teams have the opportunity to spend a greater portion of their time on work that really matters rather to their user base. And that is a good think (TM) for everyone.

There's another parallel this brings to mind: real world churches have traditionally fractured, split, grown or withered, but almost never merged. It's not easy, but there are good reasons to do it if you're able to be flexible. (Unfortunately, churches don't generally have "flexibilty" high on their list of traits.) In the process, a lot of good community work and effort goes to waste, because either a church keeps growing, or it gradually withers away and disappears. Open-source projects have traditionally suffered similar fates. Hopefully, intelligent, thoughtful mergings of communities, not just technologies, like the Rails/Merb merge, will be the future trend.

Updated: David has written more about the situation, talking about it at a more conceptual level.

As someone who loves to drive (and travel) but doesn't own a car, I rent a lot of cars -- I've probably rented for between 25 to 30 days from Avis this year so far. I do like them as a company in terms of their service execution -- the cars are ready for me when I arrive, I don't have to wait for them, and the prices are usually reasonable, if not rock bottom. But their web site drives me absolutely bonkers, it's so badly designed.

First of all, to login, you have to use your "AVIS Wizard Number" -- a randomly assigned alphanumeric mishmash with absolutely no relation to anything else. Mine is something like 1MQD32Z. All of the airlines and credit card companies have discovered the concept of a "user name" some time ago. Not AVIS. They've got their wizard numbers, and well, fuck you if you don't like it.
 
Worse, rather than using some kind of rational system for locations, AVIS uses whatever their internal coding is for locations. So midtown Manhattan? That's "M1H", you silly bastard. Why don't you know that? If you do manage to login and enter a date and a time for a rental, then search for a location, the system isn't smart enough to say, not show locations that _aren't open_ on the days you want to rent a car. (See the above graphic, which came about three screens after I had entered my target date and chosen a location.) Nor will it always tell you what times that location is actually open, so you might adjust your reservation. I guess that's a company secret or something.

Finally, to add insult to injury, if you do follow the directions in the error message and click on the "Modify >>" hyperlink to change your reservation, you'll probably end up right back at this page. That's because the new search form will have that "M1H" location filled in, so even if you enter your city and state again, it will ignore that and put you right back to the same location on the next try.

Now, if you don't mind. I'm going to have a stiff drink and try reserving a car again, for the tenth time.

The NYT has an article on the launch of Cuil.com, a search engine by some Google alums. It's interesting, but I'm getting a lot of weirdness in the results for searches. When I search for "Tom Karlo" (Doesn't everyone throw their own name into a new search engine during the first session?) I get some really odd responses, including Google.com and on occasion, either 600,000+ matches, or zero matches. And when it does come back with matches it often has the weird pairing of my home page, and an image I've never seen next to it as my "photo". It also spat out fails for "Britney Spears," "George Carlin" and didn't include itself in the front page results for "Cuil." I suspect they're having some first-day issues.

It's such a great little hack on Twitter, it's hard to do justice. Just go look at Favrd.

Forms are one of the tougher problems in web usability and something I've been thinking about lately. Here's a short list of some of the better resources I've found; some of them are older but the findings still apply. I'd have to assume users have gotten a little better at using forms over the past couple of years, but it also depends on how web-savvy the target audience is.