Can’t login

The main issue is logging into any website, as Web authentication requires a cookie to be stored on the client’s computer.

Can’t interact

Some basic interactions, like adding items to a cart, are not possible anymore.

Can’t even browse sometimes

Some website don’t even load, because a script tries but fails to access localStorage.

I liked the Forbes one in particular.

This browser has no localStorage, we cannot prefetch.

Can GMail without Google

Weirdly enough, by allowing the pattern [*.]google.com, I can log in to GMail without being automaticlly logged in to Google, YouTube, and Blogger.

Is blocking cookies a good idea?

Honestly, it’s a pain to maintain. By using a whitelist strategy, every time I encounter a login form, I need to manually add the domain pattern to the list of approved websites. And when a website doesn’t load at all, I just don’t bother.

Do I feel less tracked and more secure? Of course! /s

To be fair, I can only guess. Whereas you can tell for sure, even without clicking or hovering any of these links, which ones you’ve already visited, because my website changes the colour of visited links.

A journey through time

Browsing the Web is mainly two-dimensional: you either scroll (y-index) or click (z-index).

The colour of links provides a third dimension: time.

• purple links are from the past
• blue links are potential candidates for the present or future

Depending on what you’re looking for, the sight of visited links can trigger two different reactions:

• “Ah yes, that’s the website I was looking for! I’ve already been there.”
• “I’ve already tried this webpage, let’s try the next.”

A list of links as a checklist

Link aggregators like Reddit or Hacker News are one of the few websites to still distinguish visited links from “new” ones.

Google search results are usually processed the same way. Let’s say you’re learning JavaScript and want to know how to check if an Array is empty.

Purple links are processed as completed tasks because:

• you probably don’t want to see the same page twice in a row
• you want to resume your checklist where you left if off

The colour distinction provides information about the state of the list.

Purple links? Eww!

But why are visited links so rare? Because designers (like me) are both lazy and picky.

When finalising a mockup (approved by either your ego or your client), you want the coded webpage to actually match that mockup. You wouldn’t want the user’s browsing history to affect your perfectly balanced design now, would you?

If you’re professional enough, you would design the button’s and input’s different states (default, hover, clicked, focused, disabled). But defining the visited state will never cross your mind.

This is one of the first CSS rules any designer writes:

a {
  color: $anythingButBlue;
}

This affects all links, in any state: hover, active, focus, and visited. It’s like a colour reset. You set it and forget it. You could use the :link pseudo-class but nobody knows about it. Plus, you’d forget to set :visited anyway.

A webpage is a living document: you design for different viewports, different environments, different interface states, different user interactions.

Ignoring the colour of visited links is like caring about browser consistency: believing that every user experience should be strictly identical.

Privacy issue

A few years ago, someone ran an experiment: a website displaying links to the 1000 most visited websites. The website could potentially “steal” your browsing history by computing the colour of each link.

But browsers life Firefox prevent that kind of behaviour now:

Though the color can be changed, the method getComputedStyle will lie and always give back the value of the non-visited color.

(Emphasis mine)

As a result, styling visited links is very limited:

Not all links are equal

Most links do not require a visited colour:

• navigation links (homepage, account, settings) that are repeatedly visited
• interface links that alter the state of the page

How do you decide which links should have a visited colour?

• external links because it provides the user information about a link you’re mentioning (which is why link aggregators do style visited links)
• links to articles (or any page whose content remains identical over time)

To explain, let’s say you’re browsing The Guardian. The homepage is dynamic its content gets updated every few minutes. As a user, you don’t need to know you’ve visited the homepage because:

• you probably already have
• you probably will again

What you would like to know however, is which articles you’ve already read because an article’s content is very unlikely to have changed next time you visit it.

So knowing before clicking on article if you’ve already seen it will define your action depending on your intent:

Next time you design a website, think about :visited!
The Web and its users will appreciate it.

Last week on Hacker News, a developer shared his Google AMP + Jekyll + Medium page that loads in 65 ms, and compared it with both React’s and Jekyll’s homepages. This seemed somehow irrelevant, considering the major differences between these 3 pages, in terms of design, technology, and purpose.

HN user inian commented:

I feel a more apt comparison would have be comparing to a purely static page like a blog hosted on Github

Hey! My blog is hosted on Github! And I tested out AMP 2 weeks ago.

Why not try to optimize my homepage: jgthms.com?

View result

AMP in a nutshell

What AMP provides is:

• loading: the JS library optimizes the loading of external resources
• caching: all valid AMP documents can be cached on a Google CDN (which uses HTTP 2.0)

How do you create a valid AMP page?

1. alter your HTML to match the AMP specifications
2. inline your CSS in the page’s head
3. include the AMP JS library

Optimizing my homepage

Yesterday, my homepage was still non-optimized:

• the whole page was loaded
• the images weren’t compressed

My page used to weigh 2.2 MB. The three main images weighed 1.8 MB. That’s 80% of the total weight. Clearly, there was room for improvement…

Classic optimization: lazy image loading

I used the powerful TinyPNG to compress these images:

My page went from 2.2 MB to 858 KB.

I then applied lazy loading, using the jquery.lazy plugin, which allows images to be only fetched when they appear within the viewport.

This allows the last four images (375 KB, 43% of the page weight) to be ignored during the initial page load.

AMP optimization

AMP pages require a few alterations:

• use <html ⚡>
• add the AMP CSS with <style amp-boilerplate>
• add the AMP JS with <script async src="https://cdn.ampproject.org/v0.js"></script>
• add your own CSS inlined with <style amp-custom>
• img become amp-img elements
• images require both width and height attributes (to define the ratio only)

<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
<script async src="https://cdn.ampproject.org/v0.js"></script>
<link href="https://fonts.googleapis.com/css?family=Karla:400,400italic,700,700italic" rel="stylesheet" type="text/css">
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.4.0/css/font-awesome.min.css">
<style amp-custom>{# capture include_to_sassify #}{# include amp.sass #}{# endcapture #}
  {# include_to_sassify | sassify #}</style>

Results

Conclusion

I’m not sure if AMP is designed to optimize simple pages like mine but it’s worth a try. The main gain was essentially decreasing the page size.

If you’re trying to optimize your website for mobile users:

• focus on page weight: nothing beats a page that only weighs a couple of hundreds of KB
• avoid animations: ever tried pull-to-refresh on twitter? Slowest interaction I’ve ever seen in a mobile browser.
• lazy load your images: it’s so easy to set up, and the initial load above the fold will be greatly improved

Obviously, most websites are not as simple as a static blog with only a few articles and only updated once in a while. Different platforms that serve different purposes require different strategies.

But even a mobile browser only expects HTML, CSS, and JS. And considering the screen size, a phone can only render a small part of a page at once. And if you don’t focus on that initial rendering, the user might wonder why he had to wait 10 seconds to only see a tiny logo, a huge navbar that covers half of the page, and three lines of text.

So ask yourself if loading 1 MB images (like I did) or a JavaScript framework client-side (like others do) is worth infuriating your visitors.

• px pixels
• % percentages
• em relative to the font size
• rem relative to the root font size
• even unitless values (for line-height)

The most natural unit to use is pixels, especially for defining height and width, as it’s an absolute unit.

But relative units, like em, have their benefits as well.

How em works

em is relative to the current font-size value. So if your element has font-size: 12px, 1em equals 12px.

By defining your font-size, you can use em to define relative values for other properties:

• margin
• padding
• height
• width
• etc.

rem acts exactly like em. The only difference is that while em refers to the element’s font-size value, rem refers to the root’s font-size, which is the <html> element.

By updating a single font-size value, you can update other properties:

.button {
  font-size: 16px;
  padding: 0.75em 1em;
}

So you can simply define different button sizes by only altering the font-size:

.button--small {
  font-size: 12px;
}

.button--large {
  font-size: 20px;
}

Why you should use px, not em

Using em is a very elegant way to define both your text size and your layout. It keeps every element balanced and easily sizable. I’ve used it before. It’s a pain.

Fonts need precision to look sharp

Let’s say your default font-size is set to 16px. You have titles at 2rem and subtitles at 1.5rem. Fabulous! Your semantic hierarchy matches your visual one. If you were to change your default text size to 15px, you’d maintain that hierarchy.

But not all font sizes are equal… Considering the text of this website:

Even with bigger text, the problem is present:

Every font needs its own specific size

Another problem with em arises when you want to change the font family, because every font renders differently at each size:

Images need pixels

An image’s dimensions are set in pixels. If you want to vertically align its surrounding text precisely, you need to use a padding-top and a line-height in pixels:

(My logo isn’t an image but it used to be, and they usually are anyway).

Borders need pixels

Let’s say you want your buttons and inputs to be 38px high. Having both equally sized allows to put them next to each other, like in Bootstrap 4:

How do you that with rem?

.form-control {
  border: .0625rem solid #ccc;
  border-radius: .25rem;
  font-size: 1rem;
  padding: .375rem .75rem;
}

All these calculations are based upon a font size of 16px. Now let’s say you have to change that value, like 15px, what happens?

Yep. The border is now set at 0.9375px, and just disappears, rightfully so.

You would think: “Why not use an inset box-shadow?”? Well box-shadow is not the solution:

• every time you want to add a shadow, you need to redefine all other values
• the shadow is not part of the box model
• it can only be a single colour
• you need 4 shadows if you want 4 different “border” colours

Vectors need pixels

Vector elements, like icon fonts need precise pixel values to render correctly.

The default font size for Font Awesome is 28px. If you need smaller icons, stick to 14px. Any other value would look terrible:

Browsers zoom properly now

Browsers used to zoom in a page by simply increasing the font size, making the text bigger but keeping the layout set in pixels at its initial size. To prevent users from breaking the page when zooming in, you had to define a fluid layout, using em or rem.

But nowadays, browsers can simply zoom any layout proportionally. No need for em anymore.

Just use pixels

If you want sharp precise interfaces, stick to px:

• you’ll avoid any cumbersome calculations that involve 4 decimals
• just by looking at a CSS rule, you’ll know exactly how it will look like because there’s no dependency
• preprocessors like Sass allow easy maintenance anyway: you can have global variables for sizes, or use mixins to define variations for your elements
• you’ll be able to align different types of elements that each require their own font-size

You can still use em for things like letter-spacing, some margins, or any property that can be applied on different font-size values. But any reason to apply em everywhere is either outdated or futile.

Twenty is a puzzle game with numbers.

The goal of the game is to reach the tile “20”. You progress my merging similar value tiles. The merge increments the tile’s value by 1. Reaching the tile “20” will make it disappear.

The high score consists of the number of “20” tiles you’ve managed to reach.

Twenty and 2048

The game is reminiscent of the famous 2048 considering you progress in the game my merging same-value tiles.

But there are key differences:

• In Twenty, merging tiles increments the value by 1 ; in 2048, the new value is doubled.
• In Twenty, tile colors don’t follow a pattern ; in 2048, colors follow a specific gradient according to their value.
• Twenty is time-based. 2048 is not.
• In Twenty, new tiles can have any value (provided it already appeared once). In 2048, new tiles can only be of value 2 or 4.

Time-based

Every 10 second, 7 new tiles appear at the bottom. Their order and value is random.

If no other merge is possible, the new line will appear instantly.

Difficulty factor

For a game to remain interesting, it needs to provide a similar experience but different challenge every time.

Instead of simply speeding up the timer gradually, the difficulty comes from random connections that appear between two tiles. It means that they can only move as one, which drastically reduces their movability. You need to merge one of the connected tiles to remove all its adjacent connections.

• After reaching tile “10”, only two tiles can be connected.
• After reaching tile “15”, up to three tiles can be connected.
• After reaching tile “20”, up to four tiles can be connected.

Basic strategy

Because Twenty is a time-based game, the obivous aim is to merge tiles as fast as possible. Which means performing swift movements with your finger across the screen.

(By the way, I highly recommended playing on your phone).

Any move that doesn’t result in a possible merge is wasted time. Make each move count.

The key aspect of the game’s strategy is that not all merges are equal. In other words, the quickest merge is not always the best option.

Build towers

The main problem you’ll face is not being able to access tile, rather than having no merge available left.

Keep all tiles accessible by keeping some columns empty, and avoid making lines (which is the opposite of Tetris basically.)

Focus on the lower numbers

Ask yourself: how many “1” tiles does it take to get a “n” tile?

Let’s imagine the game only spawns “1” tiles. You’ll need 4 of them to get a “3”. You’ll need 128 of them to get a “8”.

Obviously, other tiles than “1” appear, and you keep all the ones you’ve already merged. But you’ll free space quicker by merging lower values.

Keep the tiles ordered

Each tile value should be lower than the one it’s sitting on.

In the best case scenario, you can make towers of adjacent values:

My merging the “10” on top, it will trigger a chain reaction and get rid of five tiles in a row.

Reorder when merging

If a merge possible with a number located at the bottom of a column:

• if it has a higher value than the one on top: merge into
• if lower value: drag it out

Housekeeping

If at least one possible merge is left (which means the timer hasn’t reset), it can be useful to take some time to reorder the tiles and place lower numbers on top.

It also allows to keep one “free” tile in case a better merge is possible after the timer runs out.

(Quick tip: when the timer is about to run out, hold a tile in the “air” to prevent it from connecting with another one.)

Make merge sequences

Try to merge the tile you’ve just “created”. For example, if merging two “7” to create a “8”, look for another “8”. Merge them and look for a “9”.

Doing so means you have at least one “n” tile, and you only need to find a second one.

Break the connections

If it wasn’t for the existence of connected tiles, the game would be very easy: because merging tiles removes one tile from the screen, merging tiles would be a virtuous cycle where keeping an empty (and thus playable) game area allows to easily merge tiles, which empties the area, etc.

So, if multiple merges possible: focus on targetting connected tiles. You’ll allow them to be moved freely, and prevent blocking the ones below.

Use gravity

If two tiles of same value are only separated vertically by another tile, move the middle tile to let the top one merge with the bottom one.

If you’re lucky and the middle tile was of value “n+1”, you can merge it back with the newly created tile.

Prioritize

The difficulty increases exponentially: if during one round you only manage to perform fewer than 5 merges, you’ll suffer the consequences for following rounds as well. Keeping your board “tidy” in the early rounds (before the “10” tile) is crucial to obtaining a high score.

Because time is a constraint, it is difficult to focus on applying all these ideas on each move.

Although keeping tiles ordered is essential, it’s very hard to maintain over time. That’s why focusing on breaking the connections is a great strategy.

In later rounds, because the board can be completely blocked by connected tiles, the problem doesn’t come from the existence of merges or the speed required to perform them, but simply from the ability to perform them.

Sometimes, moving tiles to break 1 connection instead of merging 6 non-connected tiles can be considered a better move in the long run. It also helps focusing on one aspect of the game because connections are easy to spot.

For example, when tapping on a Airbnb link, this modal appears:

The key part of this modal is the bottom part, where 2 options appear:

• Always: subsequent taps on similar types of links will always open the selected app.
  The modal won’t appear again.
• Just once: the link will only open in the selected app this time.
  The modal will reappear next time a similar link is opened.

The problem with this approach is that any action requires 2 taps: selecting which app to use and how subsequent taps will behave.

As a result, choosing the permanent behavior is as easy as choosing a one-time behavior. If a user chose “Always” by mistake, he’d have to dig deep into the phone settings to undo his error, which will also clear the app’s behavior regarding other types of links.

A less error-prone approach

To simplify the opening of a link and to prevent any permanent decision, the modal should look like this:

How it works:

• No app is selected by default.
• Tapping on an app will open the link in that app.
• Choosing that app as the permanent choice requires 2 taps.

The one-time action is quicker as it requires only a single tap.

Although defining the permanent action requires to tap at the bottom and then in the list, opting for a less straightforward approach is deliberate, as it prevents easy mistakes.

If a user wishes to choose an app as the default one, he’d have to actively decide to do so.

To infinity but not beyond

Whoever initially implemented infinite scrolling was probably well-intentioned. The fundamental idea is clever: accelerating the process of finding what you’re looking for by eliminating any hurdle. No need to load a whole new page, nor to take any action at all. The browsing experience is seamless.

But also endless. The flood of results can be overwhelming. The page scrolling can drastically slow down. Retrieving your previous position can be challenging. Bookmarking is almost impossible. Keeping a sense of space (and time?) is troublesome. There’s too much, too quick.

Although some of these issues can be circumvented through technical and layout tweaks, the underlying question remains to know if infinite scroll is necessary at all. Etsy dropped infinite scroll after making the wrong assumption that users wanted both more results per page and faster results. Probably the incessant flow of results prevented the user from taking any decision at all, and led him to forget what he was looking for, or why he started browsing the page in the first place.

A mobile paradigm

The infinite scroll UX paradigm has found its way in many interfaces, especially on mobile. It’s probably due to users (including me) being lazy: swiping (for scrolling) is more convenient than tapping. It’s a more natural, less demanding gesture.

It does makes sense for feeds (Twitter, Facebook) because they only require one page, and are meant to be consumed in one direction primarily. It’s less convenient for search results though, where there’s a sub-page to be accessed, and where the uncertainty to end and probablity to alter your navigation are both higher.

What about a regular pagination? Next and Previous buttons are mandatory, but displaying pages on a mobile device is less of a requirement, or should at least not be interactive.

Simplifying the flow

Some of infinite scrolling’s assumptions are correct, but need to be reduced and/or altered to fit a mobile device’s needs:

• speed up the browsing experience by remaining on the same page
• unburden the DOM from past results
• maintain the possibility to navigate to the previous page
• provide the user with a sense of completion by displaying a milestone (the Load next button)
• keep the user focused by requiring his action to navigate
• design a seamless experience

Demo: http://jgthms.com/lavalamp.js/lavalamp.html

When tapping the “Next” button, an animated element covers up the viewport, remains fixed on top (while the new content is loaded and the page scrolls back up), before it shrinks to match the “Previous” button and then disappear.

Source: https://github.com/jgthms/lavalamp.js

If so, you might wonder where it comes from. For the last couple of months, I’ve been experiencing this issue on a regular basis, without actually understanding why it occured, so it was difficult to find a workaround.

In my case, it only happened in Chrome on my Macbook Air. Although refreshing the page fixed the problem, I wanted to find out what triggered it in the first place.

And then it occured to me.

I’ve been using a Logitech mouse since February. At times, when working with a colleague, I would unplug my mouse, grab my laptop, and sit at his desk. That’s when the black scrollbar would appear.

• When using a mouse, Chrome renders a fixed scrollbar that’s 15 pixels wide.
• When using the trackpad, Chrome uses an “overlay” scrollbar, that doesn’t take up any space, and only displays the scroll handle when interacting with it.

Unplugging the mouse while visiting a page in Chrome would remove the fixed scrollbar and replace it with a black rectangle.

Apart from the Back, Forward, and Favourite buttons, all the other items appear identical. But apart from their visual similarity, their respective position determines their importance ; a higher position denotes a more significant role (especially when using the useful one-swipe-only interaction).

It’s therefore natural to find the ‘New tab’ button in 1st position. But the others buttons’ relative position?

• New incognito tab is seldom used but is 2nd, though its position is probably due to its resemblance with New tab
• I never used Other devices but it’s 4th
• Same applies to Print (7th), for which I can’t see any reasonable use case (printing a web page and via a phone?)
• The more useful Request desktop site (considering the poor state of dedicated mobile websites) is buried third to last
• Settings are second to last

Re-arranging the order of these buttons is a good step towards a more usable interface.

Going further in providing a quicker and better experience, I wonder why all buttons provide the same interactive area while they don’t carry the same importance. I assume it’s due to the less error-prone touch interface. But it makes sense on desktop, especially for people not well acquainted with keyboard shortcuts:

On a side note, hiding the menu while interacting with Back and Forward is bad UX, considering they’re often used repeatedly in a row.