Blog

Recently:  Introducing Aegea  ·  Map and reality  ·  Why are browsers so slow?  ·  The “Buy” button should always work  ·  How accidental promises hurt reputation

   
Ctrl + ↑ Later

Introducing Aegea 

Introducing Aegea, a great blogging engine.

An engine is a program that runs on the blogger’s website. It provides the writing tools to the author, shows the posts to the readers and lets them write comments. Medium.com (or similar) is simpler, but they can shut down and take all your posts offline. With an engine, the blog runs on your own website and you have access to the files and the database (you don’t have to deal with the files or the database, but you own all the data).

I want most people to have access to personal blogging in this way. That’s why it uses the most easily available platform: PHP with MySQL.

Aegea powers this and many other blogs. Among my favourites:

With Aegea, you can use the built-in neutral theme or customise it however you like (this blog is an example). Be flexible with comments: allow and disallow them globally or per post. Refine posts using Drafts. Add images, videos, audio or code to illustrate your point. Organise your writing with tags.

Designers, writers, musicians and software developers use Aegea to show their work, communicate and spread knowledge. They love it because it’s simple and fast yet does everything they need. Aegea is free for personal use and paid for business use.

Learn more and get Aegea at blogengine.me.

   
Dec 29   Aegea   my products   projects   release

Reminders app is so buggy 

Reminders is one of buggiest apps Apple has ever made. Sometimes it forgets to remind, sometimes it reminds twice. It cannot sync anything between Macs, iOS devices and the watch. And now, it decided to remind me of five things:

Reminders app

Thanks, I guess.

   
Dec 27   bugs   iPhone   Mac   software

Emerge 1.3 with video support and replay control 

In 2013, I released Emerge, a page load coordinator:

Normally, when a complex web page is loading, elements appear in random order, causing unpleasant flashing. To replace it with nice and coordinated animations, programming is required. Emerge.js simplifies the task by removing the need to write any JavaScript code. The framework uses a declarative approach, where you specify the desired behaviour for each element and do not think about the implementation.

See also the introductory blog post.

Version 1.3 adds support for video tags and an easy-to-use replay control useful for debugging.

Update for free

If you’ve bought Emerge, you get the updates for free. Just re-download using the same link you got when you bought the script. Or drop me a line if you have any questions.

   
Dec 24   Emerge   release

Map and reality: diagrams 

In the previous two parts, we’ve figured out that the preferred distortion and layers depend on the map’s supposed use case.

With public transport maps, our goal is to help the customer get from point A to point B using the displayed transport network.

This is a map of Paris Metro of 1915:

Paris Metro, 1915

The city is shown in full detail. There are many layers. The metro lines, however, stand out because of the use of contrasting red thick lines.

Compare with the map of London underground railways of 1908:

London underground railways, 1908

The lines of different railways are denoted by different colours. The rest of the city — the roads, the parks and the river — makes one pale-gray layer.

But even this layer is removed by 1932:

London underground railways, 1932

The river Thames is the only non-railway object that remains on this map. And it is the only device that links the railways to the surface geography.

It is always interesting to explore a detailed map with lots of layers. But in this case, the pleasure of exploration is much less important than the customers’ ability to quickly pick out which train to take. The information richness is sacrificed to the comprehension speed.

But as we see, despite all the simplifications, the central part is still rather hard to read. In several places, arrows had to be used to clarify the correspondence of labels and stations.

The engineer Henry Beck has come up with a radical idea. He suggested redesigning the maps using the principles of electrical circuit drawings.

Electrical circuit

Such drawings prioritise the logical connection between the elements over their physical position. What if a railway map also displayed first and foremost the logical connection between the stations?

The Beck’s diagram has replaced the map in 1933:

Beck’s Underground map, 1933

All lines segments were put to the angles of 45° and 90°. The distances between stations were equalised.

The modern diagram has twice as many lines and many more layers, but it inherits the Beck’s principles:

Modern London Underground map

Compare with a geographical map of the same lines:

Geographical London Underground map

The central part here is so dense that it had to be put in a cutaway at a bigger scale. And even so, everything turned out very small. Now we see that showing “true” geography is not universally useful. This geographical map is much harder to read. For the railways’ customers, the diagram excels.

If the distances between the stations are equal, the reader will grasp that it’s just a convention and won’t rely on it. If the lines are strictly at 45° or 90°, the reader will grasp that they do not represent the actual paths of the underground tracks and won’t rely on it either. But this doesn’t mean that you can get rid of any geographical reference.

In 2007 I made a rectilinear Moscow Metro map as an experiment:

While the principles of the above diagram are easy to figure out, there still is a problem: even if you live in Moscow, you will have a hard time finding your station.

Since any map is perceived in reference to the image of reality formed by the geographical maps, you have to respect that. If the reader knows roughly where a station is in the city, they should be able to find it on the diagram, too.

   

Why are browsers so slow? 

I understand why rendering a complicated layout may be slow. Or why executing a complicated script may be slow. Actually, browsers are rather fast doing these things. If you studied programming and have a rough idea about how many computations are made to render a page, it is surprising the browsers can do it all that fast.

But I am not talking about rendering and scripts. I am talking about everything else. Safari may take a second or two just to open a new blank tab on a 2014 iMac. And with ten or fifteen open tabs it eventually becomes sluggish as hell. Chrome is better, but not much so.

What are they doing? The tabs are already open. Everything has been rendered. Why does it take more than, say, a thousandth of a second to switch between tabs or create a new one? Opening a 20-megapixel photo from disk doesn’t take any noticeable amount of time, it renders instantaneously. Browsers store their stuff in memory. Why can’t they just show the pixels immediately when I ask for them?

You may say: if you are so smart, go create your own browser — and you will win this argument, as I’m definitely not that smart (I don’t think any one person is, by the way).

But I remember the times when we had the amazing Opera browser. In Opera, I could have a hundred open tabs, and it didn’t care, it worked incredibly fast on the hardware of its era, useless today.

You may ask: why would a sane person want a hundred open tabs, how would you even manage that? Well, Opera has had a great UI for that, which nobody has ever matched. Working with a hundred tabs in Opera was much easier back then than working with ten in today’s Safari or Chrome. But that’s a whole different story.

What would you do today if you opened a link and saw a long article which you don’t have time to read right now, but want to read later? You would save a link and close the tab. But when your browser is fast, you just don’t tend to close tabs which you haven’t dealt with. In Opera, I would let tabs stay open for months without having any impact on my machine’s performance.

Wait, but didn’t I restart my computer or the browser sometimes? Of course, I did. Unfortunately, modern browsers are so stupid that they reload all the tabs when you restart them. Which takes ages if you have a hundred of tabs. Opera was sane: it did not reload a tab unless you asked for it. It just reopened everything from the cache. Which took a couple of seconds.

Modern browsers boast their rendering and script execution performance, but that’s not what matters to me as a user. I just don’t understand why programmers spend any time optimising for that while the chrome is laughably slow even by ten-years-old standards.

I want back the pleasure of fast browsing.

You should follow me on Twitter, here

   
Dec 20   browsers   programming   rants   software   web

Likely 2.2 for single-page applications and more 

We’ve just released Likely 2.2 which adds support for single-page applications and includes many more improvements.

Ivan Akulov, the project’s maintainer, writes:

Most modern single-page apps use History API which allows developers navigate between pages without refreshing them. Since 2.2, Likely supports this API out of the box! If you place the buttons on a page and then do history.pushState () or history.replaceState (), Likely will automatically catch these changes and update itself. (Navigating backwards and forwards is also supported, of course.)

If you don’t use History API, call likely.initiate () when you need the buttons to update.

Since 2.1 we have a Telegram button, and now we add LinkedIn:

Likely LinkedIn button

There are also great improvements under the hood. As the result, the file size has been cut in half. And the code is now covered with automated tests.

See the GitHub release page for a more detailed description.

   
Dec 17   Likely   release

Map and reality: layers 

In Map and reality: distortion I talked about how distortion is inevitable on a map and the question is what to distort given a particular task.

Now let’s talk about layers. What properties of land should a map display?

Physical and geographical world atlas (1964)

Physical and geographical world atlas (1964)

A physical map shows terrain: oceans, trenches, plains and mountains. On a political map, the land is divided into countries and states. A mineral resources map is covered with the symbols of mineral deposits and oilfields.

One can’t say that a physical map is “truer” than, say, a railroad atlas. The following map shows the history of Amsterdam’s development, and it’s also true. Red houses are the oldest, the blue ones are the newest:

A good cartographer will find ways to display lots of data on a map:

A map of Chelyabinsk region, Russia (1956)

A map of Chelyabinsk region, Russia (1956)

This map displays terrain, the region boundaries, motorways and railroads, settlements, ponds, mountain ridges, height markings, parallels and meridians.

By carefully choosing colour shades, widths and styles of lines, typefaces of text, the cartographer achieves clear separation of visual layers. Background colours that marks the heights are unsaturated to let one see the labels clearly. A particular hatching is used along the region boundaries to make them well distinguishable. The letters У Р А on the left separated by many other designations, are perceived as one label ЮЖНЫЙ УРАЛ (Southern Ural) on the full map thanks to a special typeface.

The more features are shown on a map, the more interesting it is to explore it.

However, there are circumstances that do not suggest an unhurried examination by a curious reader. Sometimes a map should just answer a narrow set of practical questions.

A pedestrian map shows the main landmarks, sidewalks, bike lanes, subway stations, toilets and Wi-Fi zones:

A nautical chart displays water depths, navigational hazards, important routes, harbours and the details of the coastline:

A nautical chart

The depths are marked with numbers — while the shades of blue as used on physical maps are more illustrative, a sailor wants the actual values. The dry land gets very little attention.

The choice of the layers and the way to separate them, as well as the choice of appropriate distortion, depends on the map’s goal and supposed use.

Continued in Map and reality: diagrams.

   

Map and reality: distortion 

Often, transport diagrams do not accurately represent reality. But is this “lying” even acceptable? And if yes, to what degree?

Schematic depiction of the land has been done since rock drawings. By any contemporary measure these “maps” are ridiculously inaccurate. But they include enough detail for orientation.

This is an ancient road map of Roman Empire (created between −1 and 5 centuries; implemented in parchment in the 13th):

Ancient road map of Roman Empire

Here is Rome:

Rome on a map of Roman Empire

We are used to a very different appearance of these territories on a map. It’s quite hard to figure out what’s going on here. However, for a man who haven’t seen other maps, there is no reason to think that something is wrong: the roads actually connect the places.

On Ptolemy’s map of the world (2nd century; reproduced by the engraver Johan Schnitzer in the 15th century) the outline of Europe gets somewhat familiar:

Ptolemy’s map of the world

On Mercator’s map (16th century) it looks the way we are used to:

Transit maps and distortion

And here’s the whole world in Mercator projection:

Transit maps and distortion

Greenland looks bigger than Africa. The area of Antarctica’s looks comparable to everything else combined. But the red circles actually denote the same physical area, which gives you an idea of how distorted the map is.

This is a modern Google Map:

A Google Map of Europe

After a man had been to space, it seems, there are no more uncertainties about the shapes of land and see. But can we say this map is actually precise?

The map is flat and Earth is “round”, so a precise map just can’t exist. Futhermore, let’s look from a distance:

A Google Map

This is Mercator projection!

Mercator projection is one the most important map projections. Its main quality is that it preserves the angles. In each point the horizontal and vertical scales of the map are the same. That’s why when moving from the equator to the poles, the map is artificially stretched vertically the same way it naturally gets stretched horizontally.

Google engineer explains:

The first launch of Maps actually did not use Mercator, and streets in high latitude places like Stockholm did not meet at right angles on the map the way they do in reality. While [Mercator] distorts a “zoomed-out view” of the map, it allows close-ups (street level) to appear more like reality. The majority of our users are looking down at the street level for businesses, directions, etc… so we’re sticking with this projection for now.

Turns out, angles are far more important for navigation than the fair relative representation of land area.

The equidistant projection doesn’t distort area as much, but does distort the shape significantly:

Equidistant projection

The map projections are actually classified by the types of distortions the make. Depending on task at hand, the lengths, angles, areas or shapes can be sacrificed.

When I was designing a map of UZP plant dealerships in Russia, I even split the country in two halves. The Eastern part was displayed at twice smaller scale. This has let me show the much more inhabited Western part in larger detail (I didn’t know then that using such colours was not a good idea):

Map of UZP plant dealerships in Russia

A map from Herbert Bayer’s “The World Geo-Graphical Atlas” the Earth is cut in pieces in order to preserve the shape of the mainlands. For a map that shows the world’s population the fair display of the oceans and Antarctica is not that important:

World population map from Herbert Bayer’s “The World Geo-Graphical Atlas”

To some degree, any map is a lie.

Continued in Map and reality: layers.

   

Sayve with Karaoke 

Sayve 1.1 is out. We’ve added what we call Karaoke:

Sayve with Karaoke

The screenshot is in Russian, but you probably get the idea. When playing audio, we now highlight the corresponding words in the transcription. When playing, tap any word to jump to it in the audio. When selecting among alternatives, tap Play to listen to the selected word only.

We transcribe up to a minute of speech, but the recording can now be as long as you like. Tap audio wave to play. The screen when you have no more recordings looks better. And other small improvements.

The button:

Get for free in the App Store

It won’t be always free.

   
Dec 1   Sayve

Create a new contact or add to an existing one? 

Boy do I hate this question:

Create a new contact or add to an existing one?

Sometimes I tap “Create New Contact” and end up with two records for one person. One with an email, one with a phone number. Turns out, I had this contact already.

Sometimes I tap “Add to Existing Contact” and end up not finding the person in the contact list. Turns out, I was wrong to believe I had had this contact already.

When I don’t remember for sure, I have to flip a coin. But why should I occupy my brain with this? For a programmer INSERT and UPDATE are different database queries. This purely technological difference degrades the user interface. It should be hidden from the user.

In most cases a computer knows a name and can at least suggest adding to a contact if it exists. But even if the name is unknown, just show a searchable contact list and a “+” button together. When I press “+”, put my search query into the contact name field.

Previously in the stupid questions series:

   
Ctrl + ↓ Earlier