Hacker News new | ask | show | jobs
Three constraints that are holding the web back (ugcs.caltech.edu)
21 points by dangelo 6275 days ago
5 comments

* Desktop Notifications - This is solved, I wrote one myself[1]

Try using existing Java/Browser technology.

I would suggest this:

Each compatible web page has a signed applet which can also run resident on the remote machine via Webstart. If the server is not listening yet, start it.

If it is listening, send it a message. The Webstart remote applet then displays the message in the GUI.

My server just bound to a range of well known sockets, and the clients tried each one in turn. Try to keep it simple. I just wrote a string with a carriage return to the socket. No XML, no heaviweight protocol.

* Native Widgets - tough to get right

As soon as you start having native widgets, you cross over into having the users preferences honoured. Great for user, hard for site-consistency and support. Joel Spolksy recommends a complex setup[2] , just to get it right.

This may be a little challenging for the average webapp. Admirable but tough.

* Payments

Good suggestions from the article. A bigger problem I see is the large payment processing fees levied by each different payment provider

For instance £0.20 per transaction when payment is via Debit Cards in UK. If you're selling small items, that can be 35% of the price!!

---

[1] These days I use it to tell me when my ant builds have finished

[2] http://www.joelonsoftware.com/articles/fog0000000306.html

1) Chatterous.com (YC W08) now has an API that can reach user's IM clients. That's exciting. I'm watching out for that one.

2) wince I used to design UI for desktop apps. Menu items have been a dead concept for quite some time, and with good reason. They disconnect the user from the task or object at hand. There's no obvious mental mapping between a menu item and what's on the screen. The web is better off without these.

3) Tipjoy.com =)

I'd replace item #2 (dropdown menus) with Combo boxes and List Controls. Two items which are very useful in native apps and difficult to get right in HTML.
Notifications as a firefox extension:

- Start a listener in Firefox

- Get alerts from websites in the bookmarks toolbar

- Display subtle alert count next to icon in bookmarks toolbar.

No disruption.

Users can control who can send them alerts.

Simply add/remove icons from bookmarks toolbar.

This might kill rss readers since I can track an rss feed placing an icon in the bookmarks bar alerting me when new stories are out.

So, mix alerts with rss alerts for a more complete solution.

Here is an average bookmarks bar:

- Gmail

- Twitter

- Facebook

- HackerNews

- Google Analytics (spikes in traffic)

- Paul Graham RSS

You could easily add family alerts, amber alerts, CNN breaking news, security cam alerts, etc

A new wave of web services will emerge like cnn.com/alerts, google/alerts, yourwebsite/alerts

Possibilities are endless...

I've always thought that web 3.0 would be a 3-way web and this looks like the right place to start.

The mobile world is ahead of us in this aspect.

Ok, Mozilla guys, this one is for you. I would like to see this implemented in Firefox 4.0. Show the world you can do it. Opera will be working on it as we speak.

No listener for the moment, just poll the site every x minutes and make it configurable for every site.

Add these new properties to the bookmarks: [x] Alert. Every [10] Mins

Simple.

How nice of you to sort your idealism in order of plausibility:

1. Desktop Notifications: Terrific idea, and going to take a longass time to happen in a unified way. Already getting implemented via XMPP, perhaps browsers will just end up including an XMPP client where you can add to the roster from the DOM (pending confirmation). If this ends up happening via Twitter instead, there is no hope for this world.

2. Native Menus: a thoroughly mediocre idea -- for starters your webapps should not have fucking desktop-style menus! Furthermore how would you implement File-Edit-View on a mac? If you really need a dropdown, <select> is right fucking there. The only redeeming native-ui feature I can think of would be the ability to add to the browser's context menu, but that would be ripe for abuse if it was even close to useful enough.

3. MICROPAYMENTS: The single shittiest idea in the history of the web, and it's never going to fucking go away. Fucklers will continue to tilt at this windmill forever, and will always fail. There is far more terrific content available that I want to peruse than I will ever have time for, and I'm a guy that spends every waking moment reading. I'm serious, I often read well over 1M words a week (though I haven't instrumented in over a year), almost exclusively on the web, though in college I got 100+ books a year through ILL. There is just too much out there to be nickel & dimed.

We generally go more for the reasoned discussion here then for the swearing.

I agree, micropayments are fundamentally flawed. The reasons have been the same since Clay Shirky said so in 2000: users hate them.

http://www.openp2p.com/pub/a/p2p/2000/12/19/micropayments.ht...

However, I am in favor of absolutely anything that makes it easier for macro-payments to go through. The Apps Store cited is one way to accomplish macropayments with just a click or two, but I am skeptical that that works for the general case.

Honestly I think we're probably going to just get iterative improvements on Paypal at this point -- that is a great leap from the status quo circa 2000 but it leaves me feeling a little annoyed in 2009. There's still a 10x improvement out there... except it would have to decouple e-commerce from credit cards and have instant penetration higher than Paypal. Tough order there.

>I am in favor of absolutely anything that makes it easier for macro-payments to go through

Be careful what you wish for. Do you want to have to think before clicking, lest a 3000-word article cost you the day's lunch money? I personally am very glad that there is no good, lightweight, user-friendly architecture for micropayments. I hope it stays that way.