Here are three constraints that I think are holding the web back. Kind of like how Macromedia adding streaming video to Flash indirectly created Youtube, there is a lot of value that could be unlocked if these were solved.
1. Desktop notifications
A lot of traditional desktop applications function by alerting the user when something happens - a download is finished, an IM comes in from a friend, it’s time for a meeting, etc. Web applications can’t do this very well. Without making a user install client software, the best choices are email (often too slow and heavy-weight), javascript alert() (limited), or playing a sound and flashing the document title.
The solution is a standardized one-click button for users to grant a host permission to send them notifications. Sites could then send quick notifications to any user who either has clicked the button, or who currently has a browser window on the site (even if they haven’t clicked it). The notifications would do something like Growl. There are lots of ways this could be implemented, as an open standard, or part of Flash, or a new browser extension, but the three important things to make the product work are:
1. A significant userbase that has the ability to get notifications. This is important so that web developers will bother to put in the button. Right now so few users have Google Gears installed that very few sites bother building for it.
2. Seamless one-click authorization by users. Right now the need for desktop notifications is so bad that some apps like Gmail and Friendfeed have built special desktop notifier applications. These serve the rare cases where notifications are so valuable that users are willing to download and install a client, and developers are willing to put in the effort to build an entire desktop application. Getting rid of this friction is important to let notifications happen everywhere.
3. An easy way for users to get rid of sites that abuse the channel. This is important to prevent developer abuse of the channel in the first place. Developers need to know that every time they send a notification, if the user doesn’t want it, they are risking losing the ability to send anything to that user forever. (On a tangent, a related problem in Windows 95 was applications constantly popping up and stealing the focus. Microsoft responded by making it difficult for applications to do this. See the constraints under AllowSetForegroundWindow)
When an IM comes in on Meebo, or on Facebook, or in Gmail, it’s pretty easy to miss it right now because of this gap. Email is getting flooded with notifications that should never have been in email in the first place.
Also, it seems like there is an attempt to add this to Gears here but it hasn’t been added and Gears doesn’t have enough distribution yet.
2. Native dropdown menus
Desktop applications do a good job of managing UI complexity with menus, but very few websites have menus. Implementing menus on top of javascript and the DOM is possible but in practice they end up flickering or having little delays that make them almost unusable. Amazon is a typical better-than-average implementation that’s unpredictable enough that I rarely end up using it. When I click on menus on Windows or OS X, the menu shows up instantly, the highlighting follows as I hover my mouse over the choices, and sub-menus keep even further complexity out of the way. Even if the javascript and DOM updates only add 50-200ms, it’s upredictable enough that I can’t navigate as a natural action. Every time, I need to click, wait for the menu to show up, and make sure I keep my mouse exactly within the bounds so it doesn’t disappear and I get the right item.
Hotmail is an example of a pretty quick implementation - right click on messages in the inbox and mark them as read or unread. Google docs is also decent. But the real problem is that every site has a slightly different implementation, and users have no confidence that a menu on the web is going to work.
Browsers need to standardize on one system for this and the problem will get solved. This sounds like a small enhancement but I think it’s one of a small number of problems that are preventing bigger productivity applications and small convenience applications from moving to the web.
3. Lightweight payments (not micropayments)
The success of the iPhone app store and cell phone ringtone sales is pretty good evidence to me that people would be willing to pay small (and sometimes large) amounts of money for things on the web if it were easy. The problem is that Paypal (and the alternatives) aren’t lightweight enough. If there were a button provided by the browser (or Paypal via javascript) that would let people make purchases on any site without leaving the page or entering in anything beyond a password, I think that in aggregate, payments would make more money for web developers than advertising.
The main barrier here is fraud, and specifically spyware. Part of the reason why Apple can make the payment process on the iPhone seamless is that with the operating system locked down, they can guarantee that when a user enters their iTunes password, the user is actually the one making purchase. It’s not spyware because nothing can run in the background, and it’s not someone who stole the phone because they wouldn’t know the password. Because of spyware that can log keystrokes on desktop computers, a password isn’t even necessarily proof that the user entering a password even wants to make the purchase. There’s also the potential phishing risk - if users get used to entering their password in a pop-up dialog that doesn’t have the https://www.paypal.com/ url at the top, it will be easier for fake websites to get a user’s password. These things make the fraud problem a little more difficult for Paypal, and they have reacted by making the checkout purchase high friction and taking very few risks in trying anything new. I am pretty sure this can be solved though, since Paypal is able to deal with spyware as things are. In the worst case it might require some kind of browser integration to give users a guarantee like “whatever you type into this password dialog will go only to paypal.com.”
Update: I should clarify the difference between this and micropayments. Micropayments usually means payments in the range of pennies or tens of cents, and the main issue there is making the credit card processing cost lower than the current $.20 overhead that gets added to any payment. I am talking only about making a better user interface for the exact same payment processing that Paypal does today. I think $1 transactions are small enough for most purchases. That has worked just fine for the iPhone app store. We just need to get an experience like the iPhone has onto the web.
Historically a lot of innovation has followed from changes in possibilities provided by the underlying platform: AJAX created all of these dynamic web apps, Flash 7 created all the video sites, and Adsense created tons of content sites. Recently there haven’t been a lot of fundamental changes in possibilities on the web, which has made most of the innovation go into areas higher up the stack like Facebook platform, or onto the iPhone. If some of these were fixed I think we’d get a lot more innovation on the web.
Leave a comment if there’s anything you think I missed.
Why is it that web sites can’t use IM as a good notification mechanism? Maybe because IM is closed off into proprietary networks that are difficult to access, and because it’s hard to put links into notifications?
In any case, it’s not entirely fair to say that Gears “doesn’t have distribution” — your proposed solutions aren’t distributed yet either. Making any change at all to the Web platform seems to take something like 5 years. The Gears/HTML5/WHATWG process seems to be everyone’s best chance for getting things into the next 5-year plan.
The pull-down menu example seems very specific. There’s a lot of UI widgets people try to do with DOM that go beyond the basic form controls. In reality no built in set of UI widgets is ever enough — nontrivial desktop apps always end up rolling their own “custom controls”, for example. Is there something more significant about event handling and focus management? Put another way, suppose you wanted to write a totally kick-ass awesome reliable pull-down menu implementation in the DOM and share it so that everyone would use it and the problem would go away. What stops you?
As I’m sure you’re well aware, people have been dreaming of micropayments forever. How is what you’re talking about different?
Posted by Dan on April 8th, 2009.
I think the main reason sites don’t use IM for notifications is the friction involved in users authorizing them. Connecting to an AIM bot requires entering a screenname into a website or sending an IM to a bot with some kind of code and XMPP involves entering a Jabber ID into a site and approving the request. These are both much higher friction than clicking a button like follow on twitter. There’s also a lot of overhead on the developer side writing for multiple services and potentially deals that need to be made with the IM networks if the app gets to scale. There are some other minor things like IMs being heavier interruptions than something like Growl. Maybe the Friendfeed guys can tell us how well their XMPP support is working.
I think Flash or Internet Explorer implementing something non-standard are probably the most likely sources of a web app notification system in the near term. I am just pointing out the constraint in the hope that there will be more focus on eliminating it. The constraint will still be there even if Gears implements their proposal because they don’t have the distribution.
In practice I have never seen a dropdown menu implemented on the DOM that worked as well a native one. I’m not completely sure what’s causing this but I think interpreting javascript and updating the DOM for every step the mouse moves might be too slow. I think dropdown menus are particularly important compared to other controls because almost every desktop app uses them, and because they are difficult or impossible to implement via the DOM right now.
Usually the dreams about micropayments are about driving down the $.20 transaction cost that makes charges like $.10 impossible. I think $1 is low enough for most uses and the bulk of the problem is the user interface friction on approving a transaction, not the money transaction cost.
Posted by Adam on April 8th, 2009.
Digging this analysis.
Posted by Jared Morgenstern on April 8th, 2009.
Re: Desktop Notifications
I went quite far down the path of building a general web notification API, with an Erlang back-end, and desktop clients for Windows and Mac.
A good number of emerging websites were using the system, but I hit upon the “chicken and egg” problem quickly. (It was a good idea, but a bad choice for a first-time, one-man startup.)
The idea of Desktop Notifications was a surprisingly hard idea to communicate. It seems obvious folks like us who spend all day in front of a computer and are familiar with technology. Almost everybody else either:
- Equated it with popup advertising.
- Didn’t see the value of a website telling them about “every little thing”
- Didn’t understand that the notifications would be personalized, like an IM.
Just as I started debating the wisdom of pushing on, Adobe announced Adobe Wave, desktop notifications based on AIR. (http://labs.adobe.com/wiki/index.php/Adobe_Wave) I will be interested to see how it goes, and honestly hope that they have better luck than me, because it is a long overdue idea.
Posted by Rusty Klophaus on April 8th, 2009.
Fantastic thoughts D’Angelo. I agree entirely that we need to work with Apple, Microsoft, and the Linux community to create a general notifications system that we can all use.
Agreed on the payments front as well. I think there is a future where payment friction becomes low enough that pro accounts become not only a normal experience, but the way we do business on the web.
Great to see you back in the fray
Posted by Dave Morin on April 9th, 2009.
I think about the payments question a bit too. What has happened with the iPhone is certainly very interesting - people paying for software.
I agree that a smooth payments platform would be awesome. Renting a movie through iTunes is so great because you just click ‘Rent’ and don’t even have to enter a password.
As technology moves on, it feels like someone will develop a smooth payments system that is awesome.
This may lead to people buying more movies, books, music and other things online. Will it lead to a flourishing of the freemium model for online services/software, just as the iPhone platform has seen a flourishing in people paying for software? I’m not sure. A big trend of the last few years has been the falling of prices for online services. You used to have to pay for lots of inbox space, or for storing photos online, but now you get those things for free. It feels like the prices of online services will continue to fall - hardware is still getting cheaper and there is more and more open source software out there making it easier to build online services.
One thing that is happening with the iPhone platform is that there is very little supply of software for it, compared to the web, and so this keeps the price for iPhone apps high. A year ago the only SSH client on the iPhone platform cost $4, and now there are some more and the cheapest is $99.
So, I think a question is whether falling prices of technology, and increasing supply of software, will always drive the prices of online services to near zero, no matter how smooth the payments system.
Posted by Richard Price on May 29th, 2009.