undefined | Better HN

story

0 pointsreid15y ago0 comments

Even if your users have JavaScript enabled, they still need to download and run it before using your complex application.

Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar? It takes 2-4 seconds for that to go away on my computer. If you design for progressive enhancement, you can interact immediately and when JS is ready, it simply enhances what's already there. If done right, it's all the same interface.

If you don't mind waiting, your users may not agree: Google and Amazon both have noted significant losses in revenue at page delays much shorter than 2 seconds.

0 comments

steveklabnik15y ago

> Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar?

Well, taking a look at "Basic HTML view"... considerably less awesome.

reidOP15y ago

My point was that Google solves this problem the wrong way.

Instead of making two interfaces, they should make one interface. If JavaScript hasn't loaded yet (or if it's disabled), the majority of the interface can still be available immediately.

JavaScript should always add to the experience. It doesn't make sense to show GMail's Chat widget until JS is loaded-- but it really doesn't make sense to show nothing at all until the Chat JS downloads and runs!

You should be able to show the message list right away. You can start scanning your messages immediately. You can click normal links and submit forms.

Bonus for JS enabled users: a few seconds later the links, buttons, etc. all get hooked up to JavaScript. The Chat widget appears. By the time you click, things may even happen all AJAXy-- and it appeared to load instantly by loading JS in the background.

Now that's awesome.

steveklabnik15y ago

But what about features that _need_ JS to work? Should they be in the interface until the JS loads and they work? Then when I try to use them in the first few seconds, they're broken. If they're added afterwards, they just pop into existence...

I don't mind waiting the second or two.

reidOP15y ago

No. Those features should not be in the HTML markup if they are bonuses that require JavaScript. At least, they must be hidden until its script loads. But you shouldn't have to hide everything.

I'm pretty happy browsers don't show a big "Loading..." message until everything is loaded instead of painting the page as soon as possible. Shouldn't we be avoiding that too?

The bulk of that interface can be progressively enhanced.

For example, the message list and side navigation can be normal links. When JS comes along, they get actions (show this view, show this message) that override the default actions of those links (navigate to the page /message_view?id=foo).

If you try to use them in those first few seconds, they act as normal links-- they aren't broken, they just weren't enhanced yet. You can start using the page faster.

j / k navigate · click thread line to collapse

0 comments

steveklabnik15y ago

> Consider GMail. How awesome would it be if you didn't have to wait for its "Loading..." progress bar?

Well, taking a look at "Basic HTML view"... considerably less awesome.

reidOP15y ago

My point was that Google solves this problem the wrong way.

Instead of making two interfaces, they should make one interface. If JavaScript hasn't loaded yet (or if it's disabled), the majority of the interface can still be available immediately.

You should be able to show the message list right away. You can start scanning your messages immediately. You can click normal links and submit forms.

Now that's awesome.

steveklabnik15y ago

I don't mind waiting the second or two.

reidOP15y ago

No. Those features should not be in the HTML markup if they are bonuses that require JavaScript. At least, they must be hidden until its script loads. But you shouldn't have to hide everything.

I'm pretty happy browsers don't show a big "Loading..." message until everything is loaded instead of painting the page as soon as possible. Shouldn't we be avoiding that too?

The bulk of that interface can be progressively enhanced.

If you try to use them in those first few seconds, they act as normal links-- they aren't broken, they just weren't enhanced yet. You can start using the page faster.

j / k navigate · click thread line to collapse