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.