Likely, the social sharing buttons that aren’t shabby

Please welcome Likely, the nice social sharing buttons:

Why:

looks good;
Twitter, Facebook, Google Plus, VK (Russian thing) and Pinterest;
any text or no text;
two themes, for dark and light background;
three sizes;
Retina support;
18 KB (including icons).

Everyone should use Likely. Tell your friends to use Likely (i. e. by socially sharing its page). If you’ve switched to Likely on your website, drop me a line at (ilyabirman@ilyabirman.net).

A proposal for custom website loaders: loading.html

In a browser, when you enter a website address and press Enter, the first thing you see is white screen — no matter how fast your internet connection is. When you launch an app on an iPhone, you see the app immediately — no matter how old your phone is and how slow the app is. The trick is that every iPhone app includes a screenshot of its own initial state. Usually it is the app’s first screen without any content.

The browsers could copy the iPhone’s behaviour to improve the perceived speed of the web. In addition to the real page, a web server could serve an HTML file with a temporary content to show while the real page is loading. We’ll call it loading.html, but it could be anything pointed to by a link tag.

When the user goes to a site for the first time, the browser loads it in a regular manner. But if it figures out loading.html is available, it downloads the file and saves it locally. When the site is open again, the browser renders loading.html immediately and then replaces it with the real content when it becomes available.

This is not caching: browser shows loading.html while, not instead of loading the real page. And it will reload this file when it changes, like any other resource.

The difference between nothing and something is huge: immediate feedback, even approximate, is one of the main things that make user interface great. Enter:

A proposal for custom site loaders: loading.html

The following aspects of loading.html should be considered:

External resources. It seems sensible to disallow usage of any external resources for the file. They defeat the purpose of the file: the browser should not spend any time loading images or fonts for this temporary screen (which, hopefully, will be visible for only a second). The browser could cache those, but this may become a debugging nightmare. Embed all the styles, scripts and images — or make do without them.
File size. Since a browser should store this file for every site you’ve visited, the file should be small. Also, its loading should not tax the visitors who open your site only once.
Interaction and continuity. Interaction with a page that can vanish and get replaced with another one any moment seems strange. At first I though that it should be completely prohibited: no links, no listening to JavaScript events. But then I thought, what if I put a site’s menu in loading.html? If a user clicks a link, the browser could switch to loading it (it, by the way, could have its own loading.html, see also Scope). But badly implemented this could be frustrating. Say, a user is typing a search query into an input of loading.html when it gets replaced with a real page. The browser must make sure the typed letters are not dropped and the caret position is maintained.
Progress information. It would make sense for loading.html to want to display a spinner or a progress bar itself instead of relying on the browser. For this to work, the progress information should be available to it. A way to implement this would be with an event sent to the page, i.e. onLoadingProgress (in which case disallowing all events is not an option).
Location. From the point of view of the scripts on the loading.html page, its location should probably be the same as for the real page it’s temporarily replacing (even though in reality, obviously, loading.html was loaded from another URL).
Cookies and localStorage. These should probably be available to loading.html as for the real page also. A use case would be showing the name of the signed-in user right on the loading.html page.
Scope. A loading.html page might want to specify the scope of real pages it works as a loader to: only the one it is linked to, a range of pages, all pages on the given domain name.
Expiry. A loading.html page might want to specify its expiry date.
The switch. When should loading.html be replaced by the real page? Waiting for the full page to load is surely not optimal. Perhaps, a browser should use the same heuristics it uses now to start displaying a page when following a link. But I would consider giving a loading.html-aware pages some additional control over it.

I don’t have experience with Offline Web Applications APIs, but going by the description, I assume at least some of the described behaviour could be implemented with them. It would, however, be too complicated for anyone to bother.

This feature will probably be abused by some designers to show splash screens and ads. That’s not a problem. On the iPhone, some apps also show splash screens, and though this sucks, in no way is it a reason to remove the feature (actually, if we remove every feature that has a capacity of being abused, we’ll remain with nothing).

I’ve long been concerned with how web pages look and behave during loading, as you may have guessed looking at Emerge.js (just updated, by the way). There is a lot we can do as front-end developers. But to make things significantly better, help from the browser vendors would be required.

Ideal link underlines don’t care about letter descenders

Traditionally an underline was used for emphasis:

Some logos use it to look important:

Some logos use underline to look important

Above, underlines are part of the message: they interplay with the letters, drawing the readers’ attention to the underlined words.

But the use of underline for links, especially in paragraphs of text, is semantically different from this classical use. Such underline should not be an obstacle for the reader who choses not to care about the link. The design should only hint at the option to click the link, not scream about it. In fact, the words should not change their meaning the slightest when the linking is removed (i. e. when the text is printed).

In Crafting link underlines on Medium, Marcin Wichary says that an “ideal” link underline would look like this:

But this is not ideal, this is exuberant. You don’t want to break one underline into six stubs with funny optical effects at the gaps. You want the underline to be modest and quiet.

This is not as bad as the new Safari rendering though:

The new Safari underline rendering is disgusting

Only four lines here, but they are thick as logs. And the vertical distance from the text is smaller than the white area around the descenders. Only a blind person could come up with this crazy design.

To make the text and the underline both clear, put them in separate visual layers (see Tufte’s Envisioning Information, Layering and Separation). Make them ignore the existence of each other:

The text and the underline in separate visual layers

Notice how this underline is very thin. It resembles a hair on a piece of paper.

Why not thicker? Again, because it is not a part of the text, it should not divert the reader. It should be as thin as possible, as long as you can see it (see Tufte’s Visual Explanations, The Smallest Effective Difference).

The mystery of Tufte’s stem-and-leaf plot

In his books The Visual Display of Quantitative Information (page 140) and Envisioning Information (page 46) Edward Tufte shows a stem-and-leaf plot of volcanos’ heights:

As Tufte says, this plot “constructs the distribution of a variable with numbers themselves”. Numbers to the left of the stem represent thousands feet. To the right, hundreds, for each volcano. For example, 17 | 92 represents two volcanos of heights 17 900 and 17 200 (rounded).

This diagram has confused a lot of designers.

Usually, in a stem-and-leaf plot the values to the right of the stem are ordered. In the Tufte’s example, however, they don’t look so:

13 | 47830

On his own website, Tufte answers a question about this oddity, emphasis mine:

In the late 1960s John Tukey made the stem-and-leaf graphic by hand from an almanac that showed the volcano heights listed probably alphabetically. And so after finding the range of the data, and settling on intervals, John simply wrote down the next signficant digit on the leaves. Nowadays we would ask to the computer to sort the leaves in each bin in order.

However this answer is doubtful. The order of digits does not look completely random. Notice these descending ranges:

Stem-and-leaf plot of volcanos’ heights: descending ranges

This diagram is also shown in another book, William S. Cleveland’s “The Collected Works of John W. Tukey”, as found by my colleague Vadim Yumadilov:

The Collected Works of John W. Tukey by William S. Cleveland

Here we see the full name of the almanac from which Tukey took his data: The World Almanac, 1966. Even the pages numbers are given. Unfortunately, I wasn’t able to find it online. It’s available for sale on Amazon, but I did not want to buy it, pay for shipping to Russia, wait for a month for it to arrive.

Luckily, I’ve found a couple of these almanacs on sale on Ebay and Abebooks. So I wrote to the sellers and asked them to send me the pictures of the pages 282 and 283. Soon, I got a response from Barbie Berquist:

I have attached 2 pictures of the pages on the volcanoes. I hope they help.

Yes they do.

So in the almanac the volcanos are not, in fact, ordered alphabetically. They are ordered by height, but also grouped by region. Hence the descending ranges in the Tukey’s diagram.

Here are, for instance, the volcanos corresponding to the line 13 | 47830 — in Cameroon, Hawaii, and three in Guamemala:

The World Almanac, 1966. The volcanos of 13 to 14 thousand feet

Mystery solved. But I am still confused by lack of curiosity by Tufte. How could he ignore the oddity twice in the books and then content himself with “probably alphabetically” in the forum?

On iPhone sizes

In September, Apple introduced iPhones 6 and 6 Plus, both bigger than iPhones 5s and 5c. I’ve tried holding the new phones in my hand and found even the 6 to be way too big.

I would prefer an old-size phone but faster, with a better camera and with Apple Pay. I am not alone. But there are no new phones at the old size. If you don’t like the new size, you will have to get the last-year model.

Maybe Apple is saying goodbye to the 4-inch screens and we will have to accept this. But I am not sure that’s what Apple is doing. Look at this picture from the September event blog:

There is no clear separation between the last year models and the new models. This is simply “iPhone lineup” with the phones of three sizes: 4-inch, 4.7-inch and 5.5-inch. Showing three new devices at the same time could be just too much for one event. But Apple could update the 4-inch models next year.

A phone is a device where the size is a matter of preference, like a laptop or a TV. There is no “right” size: bigger screen shows more (good), but takes more space (bad). Apple has now accepted this truth. So maybe in the future when you buy a new iPhone, you will be asked not only “what color?”, but also “small, medium or large?”

How Apple Pay could work on Apple Watch without Touch ID

When Apple revealed Apple Pay, they first showed it on an iPhone with Touch ID and later mentioned that it would also work with the Apple Watch. But how does Apple Watch know that you are you without Touch ID?

Here is an idea.

Apple Watch requires the iPhone. It would make sense if Apple Pay on the Watch required the iPhone with Apple Pay support. The only such phones are the 6 and the 6 Plus. Both have Touch ID.

Apple Watch can tell if someone is wearing it using its heartbeat sensor. When no one is wearing the watch, it will not work with Apple Pay. When you put the watch on, it will still not work with Apple Pay, as it does not know who is wearing it. As soon as you use Touch ID for the first time to unlock your phone in a close proximity, the Watch will enter a “secure state”: now it knows that it is put on your hand. From that moment Apple Pay will work until you take the Watch off or the phone gets too far away from it.

The chance that you are trying to buy something before you’ve unlocked your phone for the first time during a day is almost zero. And in this rare case the Watch can just ask you politely to confirm the payment with Touch ID.

Ångström: convert time and time zones

The new version of Ångström codenamed Greenwich is now available. Everyone can now convert hours to seconds, weeks to minutes etc. Paid users also get timezone conversion:

What time is in New York when it’s five o’clock in London? Now it is as easy as typing “5lo”. We know when and where daylight savings time is in effect.

Also, we’ve finally done the rounded corners right:

We’ve finally done the rounded corners right in Ångström

Ah, so much better now! It took effort on Alex’s side to make this work fast and reliably on all supported devices.

We’ve added more currency symbols, including Turkish lira, Cambodian riel and Armenian dram (by the way, we’ve always had Bitcoin):

We’ve added more currency symbols to Ångström

And finally, we do a little bit better job explaining what you get with an In-App Purchase. Instead of listing unit symbols, we spell out the whole names.

Thanks to Federico Viticci of Macstories for a great recent review:

The result is an incredibly fast conversion process that only takes a few taps and doesn’t require you to scroll long lists or bookmark favorites for quick access. For me, typical usage of Ångström goes like this: I open the app, type a number, insert the first letter of a unit, and I’m done.

If you are not yet using Ångström, you should:

Download in the App Store for free

Stay tuned.

Stopping

When you cancel a Time Machine backup, it takes some time to stop:

Actions of programs have no inertia, they can be stopped immediately. If stopping something would leave a system in an inconsistent state, and you need to clean things up first, that’s what the user interface should say. But “Stopping” makes no sense. Just stop.

This problem is not uncommon, and I was thinking about writing a post about it for some time. But here is what happened recently. Mail in Yosemite Beta had already been “Disabling” my account by “Closing” something for several minutes, so I decided to cancel it — and got this: