Last time we wrote that this series was finished. A sequel arrived almost immediately.
After launch we opened the site on our own iPhone. Frankly, it was a poor piece of work. While building it we had looked at almost nothing but a desktop screen.
This is the record of that, and of the repairs.
Turning “somehow it looks wrong” into numbers
The first reaction was “this is ugly.” That sentence on its own fixes nothing. So we started by measuring what was wrong, and by how much.
The measurements were more concrete than expected.
1. The bottom 68px of every page was permanently hidden
We had fixed a “Chat with us” bar to the bottom of the screen. 56px tall, 12px of space below it. But we had never reserved that space on the page itself, so on every page the bottom 68px sat underneath the bar, out of reach forever.
What was hidden was the last line of the footer. The link to our privacy policy could not be tapped from a phone.
2. Scroll down and the menu becomes unreachable
The header was not pinned to the screen. Read an article to the bottom and the hamburger button has scrolled away off the top. From there, not a single route to another page remains.
Worse, the code said this:
// The header does not follow the scroll, so jump to the top before opening
if (!open) window.scrollTo({ top: 0, behavior: 'auto' });So once you had finally scrolled back up and opened the menu, you lost your place in the article. We wrote that ourselves, and then it caught us out.
3. Footer links were 15px tall
Apple suggests at least 44px for anything you tap; Google suggests 48px. 15px is a third of that. You can hit it, but you will often hit its neighbour instead.
4. Headings broke in the middle of a word
A Japanese heading was splitting mid-word, in a place no reader would ever break it.
We had added word-break: auto-phrase, a rule that makes Japanese wrap at sensible phrase boundaries. Safari does not support it. On an iPhone it was doing nothing at all. On desktop Chrome it worked, which is exactly why we never noticed.
The order we fixed them in
Biggest effect first.
Reserve space at the bottom. The hidden 68px came back, plus room for the iPhone home bar.
Pin the header. However far you read, the hamburger is there. The line that jumped to the top is gone. Close the menu and you are back where you were reading.
Make tap targets bigger. Footer links went from 15px to 41px, and the text from 13px to 14px.
Make headings slightly smaller. Instead of leaving the line breaking to the browser, we shrank the type on narrow screens so headings fit on one line in the first place.
Not taking over the bottom of the screen
We rebuilt this part.
The chat button is no longer a full-width bar. It is a small round button in the bottom right, about a sixth of the area. On top of that, it tucks away while you are scrolling down. Stop, or move up slightly, and it comes back.
The chat window itself used to open full screen. That makes it look like a separate app, cut off from the site, so we changed it to a drawer that slides up from the bottom. A strip of the page stays visible above it, so it reads as something sitting on top of the site. Tap the dimmed area behind it to close, or drag the handle at the top downwards.
The category filter on OS Notes was wrapping onto two lines. It is now a single row you swipe sideways.
A different bug, found along the way
While checking the repaired screens we noticed ** appearing literally in the body of articles.
The cause was a rule in Markdown. A closing ** is not recognised when the character before it is punctuation and the character after it is a letter.
✗ **This matters.**And then... → the ** shows up as text
✓ **This matters**. And then... → it becomes boldIn English there is almost always a space after a sentence, so this rarely happens. It is a trap you only fall into writing Japanese.
We found over 200 occurrences across 17 articles in three languages. All fixed, and the rule is now written into our authoring notes.
What we learned
The person who builds it only ever looks at their own desktop.
That is the whole of it. On a 1440px screen everything lined up. Because it lined up, we believed we had checked it.
The same thing happens on site. A wall looks finished when you stand in front of it; crouch down and the seams stand out. Some faults only appear when you change where you are looking from.
This time we checked every page at six widths: 320, 375, 390, 430, 560 and 768px. From now on that goes into the pre-launch routine.
There will be places we still have not noticed. When we find them, we will fix those too.
In this series