Pinterest does something really clever related to this - not so much for data placeholder but for images. They have precomputed the dominant color for each image and show that color while the image loads.

http://littlebigdetails.com/post/56782380031/pinterest-befor...

That's a really nice detail. I guess it's like the old "progressive" JPEGs from the dialup days, but the lowest level of them (1 pixel).

Oooh, that's a nice site. Gotta add it to my daily reading!

The email subscription of that site is broken though. Using my own emailaddress is not allowed: > This email address looks fake or invalid. Please enter a real email address

I believe Google images does the same.

Not sure who was first though.

I just checked, and it doesn't look like they do.

They do on the mobile image search at least. Large blocks of the dominant color first, then images load.

Thats well cool! Never noticed that before

Trello does the same

Meteor -- the JS framework -- uses something much like this, which they call "latency compensation". It's a core part of their ideology. Data is prefetched or given default values that give the user at least something to look at until the actual data is fetched with AJAX.

Beyond just using spinners, Meteor will populate the fields with client-side cached data that might be a little old, and then when it receives a response from the server it updates the client-side DB with the new data and refreshes the view. If the data hasn't changed at all, the process can be completely transparent -- just an instantaneous UI update.

Because the Meteor framework encompasses both the client and server side, this can be "abstracted away" from the app developer. The abstraction isn't perfect of course but it makes it much easier to implement these kinds of ultra-responsive Web UIs.

I think this is my favorite feature of Meteor (which I've only used so far as playing around a bit). It's on everything, automatically, painlessly.

Interesting to contrast this to what OS X(certainly Mavericks, maybe others) does. If you restart and opt to re-open previously open windows, they will open with screenshots of their previous states - only when you click on one will it dim the window and admit to you that it's not loaded yet. Personally, I find this a little irritating, giving the illusion that it's ready when it isn't. I find facebooks approach a little better, it doesn't pretend to be usable, but guides your eyes to the right part of the screen.

Personally I find the Facebook placeholders quite distracting. You still have to wait around for something to load, and scrolling down to see something that has loaded means you just have to remember scroll back up again if you want to see what was going to be there.

I prefer that over the alternative, which is to start reading some post and having the rest of the loading content push what I'm reading below the fold.

What about if instead of pushing the content down, you get pushed down with the content? If I'm remembering right, Twitter does something akin to that (at least on mobile)

I'm beginning to think that this effect is deployed purposefully - witness the ad banner that doesn't display until the split millisecond before you click on the link that it pushes out of the way. Then again [1].

[1] https://en.wikipedia.org/wiki/Hanlon%27s_razor

I am of the opposite conviction of the author. I hate it when content is the last part to be loaded.

You'd prefer to see nothing (or nothing but a spinner) until everything is available to be shown?

Yes. Asynchronous image loading and rendering is already built into the browser, and the rest of the content shouldn't take long to load to begin with. Fancy dynamic Javascript frameworks that break up what should have been a single response into 20 different responses, asynchronously firing dozens of superfluous repaints as the data trickles in, cause far worse performance, latency, and usability problems than rendering a single chunk of HTML ever did.

Nobody says this has anything to do with 'Fancy dynamic Javascript frameworks that break up what should have been a single response into 20 different responses, asynchronously firing dozens of superfluous repaints ...'

The use-case for this type of solution can occur in a relatively simple app (web app or native), with a master/detail layout when the user loads the 'detail' view for an item (and it has to fetch network data).

I'm looking at my desktop Spotify app and seeing places where this approach is applicable. Of course it loads so fast to me it seems unnecessary, but that will not be the case for everyone in the world.

> The use-case for this type of solution can occur in a relatively simple app (web app or native), with a master/detail layout when the user loads the 'detail' view for an item (and it has to fetch network data).

Would probably be better to spend developer time on more aggressive preloading then.

If there are 30 items visible in the master view, and each is 1 kB of JSON, then just load the 30k of JSON in the background (after a delay, of course).

> Would probably be better to spend developer time on more aggressive preloading then.

That should be considered regardless, it's not an either-or situation.

> If there are 30 items visible in the master view, and each is 1 kB of JSON, then just load the 30k of JSON in the background (after a delay, of course).

I said simple app, not completely trivial app! :)

You can't really win with web apps. A native app that painted either way would be called 'broken' and not pass QA. Yet we swallow things like this without blinking.

Not really. See Launch Images in iOS: https://developer.apple.com/library/ios/documentation/UserEx...

That's ok at launch (to cover up how awful web apps paint). But what then? Change forms or screens and it fails again. Or hit a button - no visual indication you hit it; app hangs; screen updates in spurts.

Not all web apps, but certainly a large fraction.

Badly implemented apps are badly implemented, native apps aren't immune to this phenomenon.

Not totally sure I get you, native apps tend to use a combination of placeholders and spinners too (when loading network content). Are you saying people are harsher in their judgement of web-apps, or more accepting?

Vastly more accepting of web apps. Web apps stall, spin (or worse yet don't spin yet are unresponsive), paint in embarrassing frames and masks with old content showing through the holes, and on and on. A native app that did that would be criticized roundly; web apps get a pass for some reason.

I hate when "fonts" are lazy loaded

.. whenever the fonts are loaded, the whole page changes, and I cannot longer keep a sane reference of what I was reading

I'm actually surprised I haven't seen this done more around the web.

It does take more work to actually have to build everything twice (first placeholder, than actual filled content) but just using some CSS classes and any decent framework like Angular would make this pretty easy to do.

You haven't worked on an AJAX app since 2000?

I'd take his comment with a pinch of salt, that is years before ajax applications were even mainstream.

gmail wasn't even released until 2004, and that was probably the first mass-market application that really unleashed the full power of ajax and made people stand up and notice.

What's your point with gmail? It wasn't the first AJAX app- Building HTML/PHP websites and using file uploads to a server allowed clients to edits web sites asynchronously. This is clearly before your time.

XMLHttpRequest wasn't around yet, but there were certainly ways of doing AJAXy things before GMail was popular with things like invisible refreshing iframes. I worked on such an app around 2001-2002.

No I mean the way it was written sounded dated, 2000-ish. If you did a tiny bit of research you'd know. But you'd rather fire off a 1 liner response.

I meant using the content placeholders like Facebook does.

This technique goes well with two-way binding libraries (Knockout, Angular etc). You give data fields default values as DOM is constructed and replace them with the real values after the actual data comes in. However, DOM reflow/layouting issues remain if some portions of data are conditionally displayed. Then some elements (placeholders) are hidden/removed after loading the actual data and that still causes the UI to jump around.

You can get a long way there with a server-rendered app, either via something like airbnb-style Rendr, PhantomJS (which has now hit 2.0), or React. Cache heavily if possible and you can get a really responsive render. It doesn't help of course for infinite scroll-style interactions, but nothing beats preloaded, static HTML! The difference, especially on slow mobile connections, is night and day.

Apps like this often look broken when they are loading (you see something like "0 results") and often don't give clear indication that this is normative, so often you don't know if this is yet another FUBAR app or if the server is slow or if you should just leave the US and move to a country which is not so dead-set against investing in broadband.

We do this in Sandglaz. On page load the skeleton of the app is there without content, and once data is ready we render the rest.

I'm a fan of this approach – another good example (although a bit more subtle that Facebook) is Trello.

Cool I'll make sure I check out Trello!

Regarding the apostrophe in the title, you generally don't put apostrophes when pluralising acronyms.

It's a valid style. Although, it was already falling out of vogue by the time I was out of primary school. This was also around the time that many were changing over to a single space after periods and colons.

yay, css spinners utilizing the full cpu time. anyway: it's worth to mention that specially for developing countries and other areas with bad link, this is an improvement and even construction of a website should acknowledge that things are slower than at your development setup.

Don't see how this is different from ajax conceptually. It is mentioned that a single page application framework is required. While an SPA framework is preferred, everything seems pretty doable with JQuery, just not as nicely prescribed.

The item individualized custom placeholders I haven't seen as a standard pattern, but I'm not sure it's worth the effort.

I'm not sure you understand the point of this post? We're not talking about AJAX or an alternative to it. This has to do with page layout and design in conjunction with delayed asset loading, whether it's slow loading or AJAX.

I personally think placeholders/known sizes are a must in web design. It really annoys me when I'm reading something and it gets pushed down due to slow loading images, etc.

> Don't see how this is different from ajax conceptually.

This is essentially a more user-friendly version of the common spinning .gif people use when they're making something load via AJAX.

Is something wrong with your system? This is what I see: http://i.imgur.com/9yWsXIx.png

The contrast between the font and the background is low for the body text (65% alpha black text on solid white background), which makes it harder to read for people with poor vision.