More on the iPad Pro

In fact, the iPad Pro hardware, engineering, and silicon teams are probably the most impressive units at Apple of recent years. The problem is, almost none of the usability or productivity issues with iPads are hardware issues.

Found Craig Mod’s essay about the iPad Pro from two years ago. It’s an excellent essay, and perfectly relevant today.

It reminded me why I bought an iPad Pro to begin with: The sheer possibilities inherent in such an ultra-portable, powerful device.

But he also hits on everything that makes the iPad so frustrating to actually use. The way it wants to keep everything sequestered and hidden, when to really get some work done on it I need to have access to everything, instantly, and sometimes all at once.

I can get that on a Mac. I can’t on an iPad.

Which is why I disagree with him that the iPad is good for writing. So much of my writing time is actually spent editing, not drafting, and editing is exactly the kind of thing — lots of context switching, needing to see multiple views of the same document at once — iPad’s are terrible at.

I sincerely hope that renaming the operating system “iPadOS” means Apple will start fixing some of these glaring problems with the iPad’s software. It’s just so tragic that the hardware is being held back from its full potential by the OS.

iPad Pro: 10 Years Later, and One Year In

Looking Back

The iPad’s 10 years old this month, and so there’s a lot of retrospectives going around.

Most of them express a disappointment with it, a sense that an opportunity has been missed.

And they’re right. From UI design flaws to bad pricing, the story of the iPad is one of exciting possibilities constantly frustrated.

For my part, I’ve owned three different iPads over the past few years. I’ve ended up returning or selling them all, and going back to the Mac.

My current iPad Pro is the one I’ve had the longest. It’s made it a full year as my primary computing device, for writing, reading, and gaming.

But here I am, back typing on my 2014 Mac Mini instead of writing this on the iPad.

So what’s making me switch back?

It’s All About the Text

For a machine that should be awesome to use as a writer — it’s super-portable, it’s always connected to the internet via cell service, it lets me actually touch the words on the screen — the iPad is very, very frustrating in practice.

Most of that is due to the sheer incompetence of the UI when it comes to manipulating text.

Want to move a paragraph around? Good luck:

  • You’ll need to tap the screen once, to activate “entering text” mode on whatever application you’re in.
  • Then you’ll need to double-tap, to indicate you want to select some text.
  • Then you’ll need to move two tiny targets around to select the text you want. Tap anywhere else than exactly on those targets, and you’ll leave select-text mode entirely, and have to start over.
  • If you should accidentally need to select text that’s slightly off-screen, more fool you: once your dragging finger hits the screen edge, it’ll start scrolling like crazy, selecting all the text you find. And getting back to the start means lifting your finger off the select area and scrolling, which will kick you out of select-text mode. You’ve got to start over now.
  • Even if all your desired text is on one screen, those tiny endpoints you’re moving can start to stutter and skip around at the end of a paragraph or section of text. You know, exactly where you’d probably want to place them.
  • If you should somehow succeed in getting just the text you want selected, you need to move it. Press on the text, but not too firmly, to watch it lift off the screen. Then drag it to where you need it. Try not to need to drag it off the edge of the screen, or you’ll get the same coked-out scrolling from before. And don’t bother looking for a prompt or anything to indicate where this text is going to end up. Apple expects you to use the Force, young padawan.

That’s right. A process that is click-drag-Cmd-c-Cmd-v on a Mac is a multi-step game of Operation that you’ll always lose on an iPad.

So I’ve gotten in the habit of writing first drafts on the iPad, and editing them on the Mac.

But that assumes iCloud is working.

iCloud: Still Crazy After All These Years

Most of the writing apps on the iPad have switched to using iCloud to sync preferences, folder structure, tags, and the documents themselves.

Makes sense, right? Use the syncing service underlying the OS.

Except it doesn’t always work.

I’ve had docs vanish. I’ve popped into my iPhone to type a few notes in an existing doc, then waited days for those same notes to show up in the document on my iPad.

iOS 13 made all this worse, by crippling background refresh. So instead of being able to look down and see how many Todos I have left to do, or Slack messages waiting for me, I have to open all these applications, one by one, to get them to refresh. It’s like the smartphone dark ages.

Since my calendars, email, etc aren’t getting refreshed correctly, my writing doesn’t either. I tell you, nothing makes me want to throw my iPad across the room more than knowing a freaking block of text is there in a doc because I can see it on my iPhone but it hasn’t shown up in the iPad yet. Because not only do I not have those words there to work with, but if I make the assumption that I can continue editing the thing before sync completes, I’m going to lose the other words entirely.

But there’s Dropbox, you say. Yes, Dropbox works. But Dropbox is slow, the interface is clunky, and their stance on privacy is…not great.

You Still Can’t Code On It

I’m a multi-class programmer/writer. I write words and code. I need a machine that does both.

The iPad has been deliberately crippled, though, so no matter how fast they make the chip inside, it’ll never be able to do the most basic task of computing: Allow the user to customize it.

You can’t write iOS software on an iPad. You can’t write a little python script and watch it execute. You can’t learn a new programming language on an iPad by writing code and seeing what it does to the machine.

You can’t even get a proper terminal on it.

You’re locked out of it, forever.

And that’s the ultimate tragedy of the iPad. Not that the UI was broken, or the original Apple pricing for its software was wrong.

It’s that its users aren’t allowed to take it to its full potential.

Because that’s what it needs. Users have to be able to fix the things that are broken, in whatever creative way they see fit, for a piece of technology to become revolutionary.

And they have to be able to do it right there, on the device, without having to invest thousands of dollars in a different machine that can run the bloated thing XCode has become.

It’s that barrier, that huge NO painted across the operating system, that ultimately frustrates me about the iPad. Because it doesn’t have to be there. It was designed and built deliberately, to keep us out.

If Doorknobs Were Software

If we designed doorknobs the way we design software, each one would come with a user manual.

They wouldn’t be guaranteed to work. You could spend hundreds of dollars on a new doorknob, only to find the handle doesn’t turn, and the manufacturer doesn’t offer a warranty.

Your doorknob would have options for direction of turn, speed of opening, and click sound, but not shape or color.

Most doorknobs would be sold without locks. You could get a knob with a lock, but it would be $10,000.

Each door in your house would need a different doorknob, depending on what year it was built. Doors from 1994 would need completely different knobs than 1993 doors. Sometimes you’d be able to put a 1995 knob in a 1993 door, but not always.

Modern doorknobs — made only for modern doors — would understand some voice commands, like “What time is it?” and “When did you last close?” But only from one person in the house, and the commands for opening and shutting would be different depending on which knob you bought and which door you installed it in. Most of these voice doorknobs wouldn’t have handles, at all.

Some people would lay awake at night, wondering if our doorknobs were getting too smart, and would one day rise up and kill everyone.

Tubes by Andrew Blum

A nice, quick intro to the physical infrastructure of the internet. Doesn’t really go into how all those pieces work — there’s no discourse on the technology behind a router — but does build a mental image of the boxes, buildings, and people that keep the world connected.

Three things I learned:

  • ARPAnet’s first Internet Message Processing machine was installed at UCLA in 1969. The machines were manufactured on the East Coast, but only West Coast universities were open to the idea of the network at the time.
  • In 1998, The Netherlands passed two laws to pave the way for fiber everywhere. One law required landowners to give up right of way for holes to be dug, second law required any company digging a hole to lay fiber to also let other companies lay their own cable in the same hole and share the costs. The one-two punch made it cheaper and easier to lay fiber, and also blocked anyone getting a monopoly.
  • The busiest route in the world is between London and New York, with more internet traffic than any other line.

Seven More Languages in Seven Weeks: Elm

Between the move and the election and the holidays, took me a long time to finish this chapter.

But I’m glad I did, because Elm is — dare I say — fun?

The error messages are fantastic. The syntax feels like Haskell without being as obtuse.  Even the package management system just feels nice.

A sign of how much I liked working in Elm: the examples for Day Two and Three of the book were written for Elm 0.14, using a concept called signals. Unfortunately, signals were completely removed in Elm 0.17 (!). So to get the book examples working in Elm 0.18, I had to basically rebuild them. Which meant spending a lot of time with the (admittedly great) Elm tutorial and trial-and-erroring things until they worked again.

None of which I minded because, well, Elm is a great language to work in.

Here’s the results of my efforts:

And here’s what I learned:

Day One

  • haskell-inspired
  • elm-installer: damn, that was easy
  • it’s got a repl!
  • emacs mode also
  • types come back with all the values (expression results)
  • holy sh*t: “Maybe you forgot some parentheses? Or a comma?”
  • omg: “Hint: All elements should be the same type of value so that we can iterate through the list without running into unexpected values.”
  • type inferred: don’t have to explicitly declare the type of every variable
  • polymorphism via type classes
  • single-assignment, but the repl is a little looser
  • pipe syntax for if statement in book is gone in elm 0.17
  • case statement allows pattern matching
  • case statement needs the newlines, even in the repl (use `\`)
  • can build own complex data types (but not type classes)
  • case also needs indentation to work (especially if using result for assignment in the repl)
  • records: abstract types for people without beards
  • changing records: use `=` instead of `<-`: { blackQueen | color = White }
  • records look like they’re immutable now, when they weren’t before? code altering them in day one doesn’t work
  • parens around function calls are optional
  • infers types of function parameters
  • both left and right (!) function composition <| and |>
  • got map and filter based off the List type (?)
  • no special syntax for defining a function versus a regular variable, just set a name equal to the function body (with the function args before the equal sign)
  • head::tail pattern matching in function definition no longer works; elm is now stricter about requiring you to define all the possible inputs, including the empty list
  • elm is a curried language (!)
  • no reduce: foldr or foldl
  • have to paren the infix functions to use in foldr: List.foldr (*) 1 list
  • hard exercise seems to depend on elm being looser than it is; afaict, it won’t let you pass in a list of records with differing fields (type volation), nor will it let you try to access a field that isn’t there (another type violation)

Day Two

  • section is built around signals, which were removed in Elm 0.17 (!)
  • elm has actually deliberately moved away from FRP as a paradigm
  • looks like will need to completely rewrite the sample code for each one as we go…thankfully, there’s good examples in the elm docs (whew!)
  • [check gists for rewritten code]
  • module elm-lang/keyboard isn’t imported in the elm online editor by default anymore

Day Three

  • can fix the errors from loading Collage and Element into main by using toHtml method of the Collage object
  • elm-reactor will give you a hot-updated project listening on port 8000 (so, refresh web page of localhost:8000 and get updated view of what your project looks like)
  • error messages are very descriptive, can work through upgrading a project just by following along (and refreshing alot)
  • critical to getting game working: https://ohanhi.github.io/base-for-game-elm-017.html (multiple subscriptions)

The Shock of the Old by David Edgerton

An excellent antidote to the normal narratives of invention and progress.

But Edgerton isn’t a Luddite, or a cynic that doesn’t believe in progress. Instead, he sets out to fill in the stories that normally get glossed over in normal histories: the importance of horsepower to the modern armies of World War II, the communities in West Africa that have grown up specifically to maintain the cars and trucks they inherit from the developed world using local materials, the resurgence in whaling in the 1920s and 1930s driven by demand for whale oil to be used in margarine. It’s fascinating, incredibly readable, and it changed the way I read stories of technical progress and achievement.

Three facts in particular stood out to me:

  • India and Taiwan produce more bicycles each year than the entire world did in 1950.
  • In 2003, the largest R&D spenders weren’t in biotech or the internet; they were car companies: Ford, Daimler Chrysler, Toyota, etc.
  • The rickshaw, which I always assumed was an old tech lingering in the modern world, was in fact only invented in 1870, in Japan.