The Machine That Changed The World — Transcription of the interview with Larry Tesler

March 2, 2020
by Riccardo Mori
Tech Life

MCTW Tesler interview

Introduction

The recent passing of Larry Tesler hit me harder than I thought. Even if I didn’t get to know the man, I felt as if I had lost a friend. And knowing the magnitude of his contribution to computer science, I was rather annoyed that basically all news outlets, in giving the sad news, just labelled him as “the inventor of Copy and Paste”. At least John Markoff’s article in The New York Times gave a more encompassing profile of Tesler, and I do recommend you read at least that to have a better idea of who Tesler was and what he did.

Another thing worth reading is this Twitter thread by Chris Espinosa.

I wanted to put together something as a personal homage to Larry Tesler, but I didn’t know how. A summary of his accomplishments and inventions felt too much like a school assignment. Writing a deeper, more meaningful profile, would have required that I knew the man more closely, or that I had access to, and direct communication with, people who knew him better. But I chose not to bother anyone out of tact and respect.

So I decided to let Tesler speak for himself, in a way. As I noticed when transcribing the lecture he gave with Chris Espinosa in 1997 on the origins of the Apple human interface, Tesler possessed this admirable mixture of clarity of thought and simplicity of discourse. That’s why I chose to carry out another transcription, this time of an interview he did for a five-part documentary series, The Machine that Changed the World, that aired in 1992.

For a comprehensive look into the series, I recommend checking out the excellent work by Andy Baio in 2008 on his waxy.org website.

About the interview

The video of the interview (at least, the video I found) can be watched here. [Update, March 2022 — I’ve been notified that the original YouTube link doesn’t work anymore. You can watch the interview here instead. Note also that the video is accompanied by a transcript on the WGBH website, but it doesn’t look accurate in certain places; maybe it is an automated transcription?]

According to the description, this is the full-length interview, and only portions of it were featured in the documentary series. Its total length is 1 hour and 45 minutes, and it’s divided into two parts. The first part lasts little more than one hour and is the proper interview/conversation with Larry Tesler. In the second part, Tesler is at the computer giving some demonstrations of software applications and explaining the Macintosh’s user interface a bit. This second part is somewhat more chaotic and, really, it’s way better to just watch it than reading a transcription. That’s why I have only transcribed the first part of the conversation with Tesler.

There was very little to edit in the process of transferring the conversation to the written word, thanks to Tesler’s extraordinarily lucid and articulate responses. I actually had a more difficult time understanding the interviewer — he didn’t sound as he was miked, and his questions or remarks could be a bit meandering at times.

Topics of the conversation include bits of computer history and Tesler’s beginnings, what it meant to be a programmer in the era of big mainframes, several insights on how computers and their roles changed through the years, Xerox PARC, programming languages, the future of computing. What struck me most about this last topic is how accurate Tesler’s predictions are, despite him saying, So all the predictions that I’ve made today are very unlikely to be correct based on the track record of our industry. (Remember, this interview took place in late 1991 — early 1992).

Quite the contrary, Larry. Thank you for everything you contributed to the history of computing.

Disclaimer: I have done this transcription work and chosen to publish it here in good faith, for educational purposes. I don’t make any money from my website, as it is completely ad-free. In any case, should any copyright holder contact me requesting the removal of the following material, I will certainly comply.

Enjoy the conversation.

Read More

Let’s talk about discoverability

February 28, 2020
by Riccardo Mori
Software

There’s been a fair amount of criticism regarding the poor discoverability of UI elements and interactions in recent iOS versions and especially iPadOS. Of course, sooner or later in the debate, comparisons with Mac OS had to be drawn. I’m not entirely sure whether it’s even the right comparison to draw, because a multi-touch interface and a traditional mouse+keyboard interface lacking direct manipulation are bound to have different paradigms and affordances. A better idea would be to compare, say, iPadOS with Android on tablets, or with Windows 10 on a Microsoft Surface device. But here we are.

In his recent Undiscoverable UI Madness, Matt Birchler writes:

We have a couple Mac users in the office so I went around and asked them how to do some things on macOS, which as we all know, is much better than iPadOS at making important, useful UI elements easily discoverable. I talked to 3 people who have been using Macs for years at work and home.

Basically, Matt performed a quick test of these people’s knowledge of parts of Mac OS’s interface and user interaction. The idea, I guess, was to see whether Mac OS’s user interface could have its areas of undiscoverability or poor discoverability.

By Matt’s own admission, this was just an informal thing, but I have issues with his conclusions all the same. After the examples, he writes:

I stopped there because we had to get back to work, but without even leaving the Finder and Desktop I was able to find a bunch of things that long-time Mac users had never known about because they never discovered them in their daily use.

Perhaps they never discovered them because they never use menus on a Mac. But let’s analyse Matt’s examples.

First test — A Finder window with several items displayed, but a hidden scroll bar.

Result (quoting Matt): 3 out of 3 knew they could scroll, so good so far. I asked how they would know if they could scroll in another window, and they said you basically just try to scroll, and that’s how they find out.

The removal of persistent scroll bars in the Finder is a personal pet peeve. Removing them was a silly decision, usability-wise. Still, if you’re presented with a Finder window and don’t know whether there are more elements than those displayed, another quick way to check is to change the window’s view. You could switch to List view, for example, and that would reveal that the folder contains more elements than what you could see in Icon view.

And you can switch view in at least two ways, both discoverable: by clicking the relevant toolbar icons (which are visible by default), or by going to the Finder’s View menu and select as List. Using the menu, you also find out there are keyboard shortcuts to switch icon view: ⌘-1 (View as Icons), ⌘-2 (as List), ⌘-3 (as Columns), and ⌘-4 (as Cover Flow). I’m still on Mac OS 10.13 High Sierra, maybe the shortcuts are different under 10.15 Catalina.

Second test — Previewing an image without using the Preview app.

Result: 1 of 3 could do it, with the others really impressed that Quick Look was a thing and said they never would have guessed to hit space to do it.

I honestly have a hard time believing that people who “have been using Macs for years at work and home” didn’t know about the spacebar shortcut for Quick Look. But anyway. Suppose you don’t know that either, and you’re given this test. How could you find a way to do what’s asked? Well, by exploring the interface before you. You’re in the Finder. The image is in a Finder window. The default toolbar of a Finder window has an Action button (the gear icon). You click on it and a pop-up menu appears. One of the menu items is Quick Look “[file name]”. There you have it.

Is the image (or other kind of file) on the Desktop? You go to the Finder File menu and, again, one of the menu items is Quick Look “[file name]”. There you have it.

Third test — How to right-click on a folder.

Result: One knew how with the Magic Mouse, but the other 2 agreed they needed to do it on their trackpad because Apple’s mouse only has a single click. None knew you could also Ctrl+Click to bring this up.

While not knowing that Ctrl-click is the historical Mac shortcut equivalent to PC’s right button mouse click seems to me even more incredible than not knowing about Quick Look’s spacebar shortcut (simply because Ctrl-click is a shortcut that’s almost as old as the Mac itself), I’d like to point out that even without knowing you can right-click (or Ctrl-click) on UI elements, you can achieve the same effect in another way. Again, you either use the Action button in a Finder window’s toolbar, or the Finder’s File menu. Again, familiarising with the Finder’s menus is a double discovery: you find out all the actions you can perform on an item, and you find out that most of these actions have a keyboard shortcut assigned to them.

Fourth test — Matt writes: While here, I right clicked on a PNG file and asked how to make that file type always open on Photoshop instead of Preview. None knew you had to hold Option while using the “open in” option.

Again, holding the Option key while using the Open in command is not the only way to do this. This can be discovered, for example, by opening the Info panel of the file (File → Get Info) and looking at the Open with section. The pull-down menu clearly tells which application will always open this file by default, but by using that same menu you can change such application and select another to open that file — and you can also specify that your choice will be the new default for opening all the files of the same type.

Is this alternative as direct and straightforward as holding the Option key while selecting Open in? No, but it is discoverable by exploring the user interface.

Fifth test — Enabling the Do Not Disturb feature.

Result: None were able to do it, even when I said it was in the notification panel. Hint: you need to scroll down to see it and night shift.

My wife is a long-time Windows user. She’s not very familiar with Mac OS’s user interface. I asked her to do the same. She clicked on the Spotlight icon and typed Do Not Disturb in the search field. The top hit was the Notifications preference pane. She selected it, System Preferences opened and the Notifications pane came up:

Do Not Disturb in System Prefs

At this point, she clicked on the icon next to Turn on Do Not Disturb in Notification Centre. This opened the Notifications pane and both Do Not Disturb and Night Shift were visible. When I asked her why she thought that the icon was clickable, she said that she recognised the shape of the switch in the icon, and clicked on it believing that it was the actual switch to turn on Do Not Disturb. This is definitely not a very well-designed user interaction, and is perhaps one of the best examples of poor discoverability in Mac OS. But still, it remains discoverable by exploring the interface.

Sixth test — How to navigate to the folder above the one you are in.

Result: No one was able to, and telling them that they could by hitting Cmd+up arrow or Cmd+clicking on the directory name in the title bar was deemed the most hidden thing thus far.

I don’t know why people don’t use the thing they have in front of their noses. When I read this example, I confess I did not remember an alternative way of achieving the same result. I’ve been having the ⌘-↑ keyboard shortcut in my muscle memory for so long. But a brief exploration of the Finder menus led me to discover that if you select the Go menu, there’s the Enclosing folder command right there, and with the relative keyboard shortcut of course.

The important point about discoverability

Matt writes:

None of this is meant to say macOS is garbage or anything like that. It’s just interesting to see when people who love the Mac and are so critical of “discoverability” on the iPad. I’m not even saying the iPad is better than the Mac here, I’m just saying that “discoverability” is one of the big things that has people in a tizzy right now about the iPad, but I think some are laying into the iPad harder than is warranted.

The term discoverability applied to a user interface refers to something that can be discovered within the interface. A UI element or interaction may not be immediately evident. If it can be found within the interface through exploration, then it is discoverable. If it can be found through knowledge only, and such knowledge lies outside the interface, then by definition it is not discoverable.

The problem with the iPad (and to a certain extent with the iPhone) is that certain gestures, controls, and operations, are essentially undiscoverable. You can stumble onto them by chance, but I hesitate to call this discoverability.

On the Mac, a user may not know about a certain keyboard shortcut or mouse/trackpad gesture to execute an operation, but that’s just a shortcut for the default way to do such operation, which in most cases simply involves pointing and clicking on a button or application menu, as we’ve seen in my counterexamples above. The default way can be explicitly found within the interface. It’s not something you can only find in a user’s guide, instructions manual, or Apple’s KnowledgeBase.

If the only way to Quick Look a file on the Mac were the spacebar shortcut, and you couldn’t find any hint in the whole user interface telling you about that, then yes, I would say that such feature is undiscoverable without external knowledge. But it’s not the only way. And the traditional way — using the mouse or trackpad and invoking a menu — can definitely be found; it’s not that complicated or obscure.

Now think again about multitasking on the iPad. Imagine you don’t know how to do that. Where do you find how to do it within the user interface? Is there an element of the user interface of iPadOS you can use to perform the necessary multitasking gestures without failing? There is not. I would really love to conduct some user testing and ask someone who has no idea how to do multitasking on the iPad if they can find out even by simply messing around in the interface and stumble onto it by chance. (Is there even a mention of multitasking in the Tips app, by the way?)

Different interfaces, different ways to approach discoverability

Designing for point-and-click interfaces and designing for multi-touch interfaces involves different ways in how elements and possible actions are presented to the user. In traditional point-and-click interfaces, due to the inherent precision of the pointing device, you typically have smaller UI targets, and you can have a lot of them displayed in a single window or desktop. This allows you to delegate several functions to menus and toolbars, for example. Not to mention the fact that you can have more than one way to execute an action, given the additional help of keyboard shortcuts.

With touch-based interfaces, designing user interaction is trickier. You don’t have a desktop metaphor where you can freely move different application windows around. You don’t have menus. You don’t have small targets. You can’t rely on keyboard shortcuts as backup because a physical keyboard is an optional accessory for a tablet. And if your user interface is not designed for a stylus as primary input device, you can’t place small buttons and UI elements as additional tools to add functionality or help discoverability. (Well, you can, but that would have other repercussions usability-wise).

You have to design for the finger: targets need to be big enough to be easily tappable. You have app icons, buttons, switches, sliders, you have big lists of tappable items, you have panes, you have gestures. Little else. Making an element or action discoverable is more difficult, but not impossible. One of the side effects of the post-iOS 7 flattening of the UI is that it has also become terser. With touch-based interfaces in particular, it’s important to offer visual cues that effectively give little nudges to the user, as in: you can move this pane out of the way; you can swipe in this direction to reveal more contents or more of the app’s interface; you can drag your finger from the bottom upwards to invoke a secondary, overlapping pane; you can see at a glance that this UI element is in an active state or is in the foreground via the use of colours and shading. And so on.

These are just a few examples of affordances. If you remove them because you give more prominence to gestures — which are ’invisible actions’ — then you also make things less discoverable, or not discoverable at all. In the early versions of iOS there were fewer gestures and more actions based on buttons. This might look ‘inelegant’ today, but it was also a less ambiguous approach than what we have now. Especially when today we’re given a more complex gesture vocabulary that differentiates between, say, a flick-style swipe and a slower finger-drag.

Here’s a small example of how BlackBerry 10 OS handles a case of potential ambiguity when it’s time to perform a gesture. Say you wake your BlackBerry device and you don’t remember the correct way to unlock the screen and enter your home screen. After tapping two or three times on the display, a helpful tooltip appears for a few seconds:

BB Tooltip

Is this an easy way out, design-wise? Perhaps. Could this have been designed in a subtler, sleeker way? Perhaps. But it’s so much better than leaving the user guessing and feeling stupid. It’s also an effective reminder for people like me, who handle different devices from different platforms and sometimes lose track of which gesture does what on which device.

Closing thoughts

Discoverability is important and is one of the things that help make an interface and a device more intuitive, usable, and user-friendly. It’s certainly harder to make elements and actions discoverable or more discoverable in a touch-based interface than in a traditional computer’s user interface which is historically and inherently more fine-grained.

Harder, but possible. You have to keep feature creep in check, and you have to always keep the whole system in mind when you ‘grow’ new features or iterate on previous ones. Otherwise you risk burying something beneath UI layers or beneath other stuff you, as a designer, are now taking for granted. Which is what I feel has happened in certain areas of iOS and iPadOS.

The criticism towards discoverability in iPadOS is not unwarranted, in my opinion. No user interface is perfect. But one tends to be more forgiving when the undiscoverable UI element, action, command is tied to some minor system feature or infrequent operation. The keyboard shortcut for turning off your Mac’s screen (Shift-Ctrl-Eject or Shift-Ctrl-Power button) is virtually undiscoverable. I myself found it out by chance when I reached this Apple support page while looking for something else entirely. But not finding it, not knowing about it — you’ll agree — is not a big deal.

However, for something as essential to the productive use of an iPad as how to handle multitasking and interoperation between running apps, its poor (or rather, nonexistent) discoverability is unforgivable. Especially, as I already said elsewhere, because it’s Apple we’re talking about. The company that made user interface, user experience, and usability fundamental parts of their DNA. The company that seems to overlook these fundamentals a bit too often, lately.

Mac OS Catalina: more trouble than it’s worth (Part 3)

February 18, 2020
by Riccardo Mori
Software

Additional feedback and follow-up

More complaints, but also more positive feedback

Since publishing Part 2 of this ‘accidental series’ on Mac OS Catalina, I have received a couple dozen new email messages. Not all of them were negative, thankfully. The email count is currently at 107. This is a visual representation of the kind of feedback I received at the time of writing:

Catalina feedback

Among the negative email messages, there was one (thanks, Yaroslav!) reminding me of a specific issue regarding the loss of 32-bit apps in Catalina: “Right after I’ve ‘upgraded’ to Catalina in September, I’ve discovered that I am able to play almost none of the countless number of games that I have on my Steam account. For some reason, the majority of the games that have macOS ports are only in 32 bits. Since September, I can’t play any of them natively on my Mac.” Yaroslav also points out something I did notice myself, but forgot to mention: there are a lot of Mac games on Steam, even recent releases, with the following warning:

This product is not compatible with macOS 10.15 Catalina. Click here for more information. 

Clicking on the link directs you to a Steam Support page called Steam and macOS 10.15 Catalina, providing some frequently asked questions on the matter. In replying to the question What are my options to make sure I can continue to play my 32-bit Mac apps?, Steam offers three solutions which can be summarised as follows: 1) Don’t upgrade to Catalina; 2) Upgrade to Catalina, but also install Mojave on another APFS volume together with Steam, and reboot into Mojave whenever you need to play 32-bit games; 3) Use Bootcamp to launch your games in Windows.

Being a Mac gamer has always been problematic. In the pre-Intel Mac days, the excuse for the relatively little amount of triple‑A titles for the Mac was that it was hard to port games for the PowerPC platform and that Macs were equipped with lesser, non-upgradable graphics cards than Windows PCs. When Macs adopted the Intel architecture, things started to improve, and more games have become available; but even today, a lot of famous game franchises are still Windows-only. 

With Mac OS Catalina rendering a lot of existing titles unplayable natively, gaming on a Mac becomes an unnecessarily annoying affair. And maybe some of you don’t care about games on the Mac, and that’s fine, but even if you’re not into gaming, this remains a concern for the Mac as a platform.

 

As I said at the beginning, I also received messages with positive feedback. Jon writes “Just the upgraded Photos app is worth it alone for me”. Wes started by telling me about some initial issues after upgrading to Catalina (his Mac had become ’sluggish and unreliable’), but also added that after applying the last 10.15.3 update, things have suddenly and drastically improved (“This update has truly resurrected this machine”). He also reported no issues on two other Macs, a 2018 MacBook Air and his wife’s 2015 MacBook Air. 

Hans too writes to point out how the 10.15.3 update appears to have improved his MacBook Pro’s reliability and responsiveness. This other remark of his is also worth mentioning: “I confess I didn’t trust Catalina enough to just upgrade over the previous Mojave installation, so I did a full backup with Carbon Copy Cloner on another disk, and then I did a fresh install of Catalina. Would be interesting to know how many of the people who say are happy with Catalina also did a fresh install like I did. I have the feeling Catalina is a kind of release you better install from scratch…”

I have the same feeling. 

The security aspect

Patrick wrote me and raised another interesting question:

One thing that I’m always curious about, though, is security. A huge part of what I pay Apple for, and probably my number one motivation to ever upgrade, is the hope that it will make it harder for malicious actors to get malware running on my machine, steal my data, etc. If that’s going well, people aren’t going to notice much, but they’re getting a lot of value.

[…] But… it’s hard to gauge how well you’re being protected. 

In recent years, security concerns have quickly reached the top of the list of reasons to upgrade or update your devices. Whenever I talk about my reluctance to upgrade my Macs or iOS devices, invariably someone pops up in my inbox telling me it’s ill-advised on my part to postpone updates (or to not apply them altogether) because in doing so, I’m unnecessarily exposing my machines to malware.

After all, isn’t malware for Mac on the rise? Well, it is. But we need to remember one important thing here: All software viruses are malware, while not all malware is software viruses. Virtually all malware today needs a social engineering element to succeed, and Mac malware is no different. In other words, users have to be fooled into thinking that they’re clicking on legitimate links or downloading legitimate or useful software, so that they themselves can authorise the malware-disguised-as-good-stuff to do naughty things on their Macs.

But Mac viruses? As in, software that can auto-install on your Mac without user intervention or authorisation, and that can replicate and infect other machines by itself? That’s another story. As Ben Lovejoy writes in his Comment: Mac malware is growing, but there are three important riders, “macOS doesn’t allow unsigned apps to be installed without user permission.” The last Mac virus I’ve dealt with was before Mac OS X, and I don’t even remember its name or what it did.

In other words, avoiding malware for Mac is a relatively easy task once you learn to pay attention and don’t just install whatever application or browser extension that ‘seems legit’. Doing a little homework pays a lot. Only install and execute apps and extensions from trusted sources. Read email messages carefully and before clicking any link, try to preview it by hovering the mouse over it. 

Some messages are very well constructed, and I myself have received email notifications from “Apple” requiring me to log into my iCloud account “to verify my credentials” that really looked like emails from Apple. The logo, colours, fonts, even the language used, everything looked valid. But the link on the “Sign in to iCloud”, when previewed, clearly pointed to a very different website, certainly not Apple’s. Similarly, remember that your bank never sends you emails that require you to access your bank account. And remember, you never win prizes for contests and competitions you never participated in. 

Before you jump down my throat saying that I’m minimising a crucial subject such as computer security, I’ll say that staying up-to-date is undoubtedly important because OS upgrades and incremental system security updates contain patches that hopefully fix known security vulnerabilities.

I’m still on Mac OS 10.13 High Sierra, and this release will receive security updates until Mac OS 10.16 comes out, since Apple typically keeps patching the two Mac OS releases prior to the current one. So, to those who wrote me saying that I’m a fool for not upgrading to Catalina because I’m leaving my Macs unprotected — Thanks for your concern, but my Macs are still fine at the moment. When 10.16 comes out, I’ll upgrade them to Mojave and they’ll remain protected for another year. This also buys me time so that I can see how Catalina evolves and what kind of release 10.16 will be.

Meanwhile, I can’t help making the following observation. I still use plenty of older Macs that connect to the Internet for long periods of time. My older 2009 MacBook Pro is online pretty much all the time, and runs Mac OS X 10.11 El Capitan, a system release that isn’t receiving security updates anymore since Mojave was introduced in 2018. I have several PowerPC Macs running Mac OS X 10.4 Tiger and 10.5 Leopard which certainly still have a lot of unpatched security vulnerabilities. I still haven’t encountered any malware-related issues while using these older machines. But yes, I’m definitely not an average computer user and I know what I’m doing. 

Note: the message here isn’t, Don’t worry about security, you’ll be fine. It’s more like an attempt to consider security from different angles and wonder — at a practical level — where are the actual security risks when using older Mac OS versions and where is the FUD. And again, while I’m not minimising the importance of security, I also have the feeling that it’s increasingly being used as an excuse to induce people to update their devices, whether they’re ready or not. (‘They’ here refers to the people, but in some cases it can also refer to the devices).

And finally, as Patrick said, even when you have all your devices up-to-date it’s hard to gauge how well you’re being protected. The most useful thing a security update does for your Mac is to patch known vulnerabilities (emphasis on known). But no security update can automatically and reliably protect you from yourself. If your carelessness makes you download and execute dubious software, your beautifully updated system won’t do much to stop you. You have to stay informed and alert. Sometimes, a simple Web search is all it takes to find out that apps with names like “Awesome Mac Virus Defender Free” are a scam and the last thing they’ll do is keep your Mac safe.

Yes, Catalina goes out of its way to stop you from executing untrusted software. You may like this Let’s lock down as many parts of the system as possible approach. Some non-tech-savvy users are perhaps better served by being treated this way. I simply think that turning an operating system into the software equivalent of a paranoid police state isn’t a particularly refined solution, just the easiest to apply. Too bad it also has a serious impact on the development of legitimate software, as Mac developers today have to carry out a not insignificant amount of additional work to make their software compliant with Apple’s strictness. 

Is this worthwhile? Well, this blunt approach to security certainly benefits some users, but it also feels overkill and exceedingly hostile towards a lot of other users with a minimum of experience using a Mac. This kind of security approach works wonders on iOS, but that’s because it’s also more compatible with the inherent structure of iOS. iOS was designed from the start to be a more compartmentalised system. Mac OS, quite the opposite. Transforming the nature of an open and versatile system as Mac OS by enveloping it in a stifling security blanket designed for iOS is a simplistic and coarse-grained solution — effective to a point, but not without collateral damage.

The “Selection bias” argument

Part 2 of Mac OS Catalina: more trouble than it’s worth was picked up by sites like Hacker News and Lobsters. When Hacker News picked up my first post on the subject, I went there and checked out the discussion, and even joined it where I thought I could clarify some points. It largely felt like a waste of time and, yes, I should have known better. 

I did not make the same mistake the second time around, but I briefly went and checked out Lobsters because (apologies to Lobsters’ users) it was the first time I had heard of it. In passing, I read someone commenting that the anecdotal data I presented in Part 2 didn’t really prove anything and my assumptions were affected by the so-called Selection bias.

In other words, since the majority of feedback I’ve received on Mac OS Catalina is negative, I can use this to conclude that Catalina is a terrible release. Look how many people are having trouble! 

But that is not the point I’m making. In fact, in Part 2 I didn’t write “Mac OS Catalina is a terrible release and it’s giving all kinds of issues to most Mac users”. What I did write is that the initial observation I made in October 2019 (what Catalina takes away from me is more than what it gives me) “four months later seems to be true for a few more people”. And that’s it. I never planned to use the feedback I’ve received about Catalina — which is clearly anecdotal data — to prove a point. 

Nothing openly prescriptive

In fact, I did not and do not need to use (negative) feedback to back up my assessment of Mac OS Catalina. I know it is, at best, a disruptive release. I know because I’ve collected enough information over these past months to have a pretty clear picture of what I would get into should I decide to upgrade.

The big misunderstanding here is that I’m somehow urging people to avoid upgrading. I’m not. Remember, all this started from a very personal angle: Catalina is more trouble than it’s worth… for me. I’m at a point where I cannot afford to potentially lose time and sleep over a Mac OS release that is more likely to give me headaches than anything really worth upgrading. 

Plus, given that my iMac has a regular hard disk and the new APFS file system is not optimised for hard disks (it has been designed to take advantage of SSDs), why would I risk a noticeable decrease in disk performance? 

I still rely on some 32-bit apps, and enjoy many games that would become unplayable under Catalina. I still enjoy a stable and reliable Mac OS release that gives me access to software I wouldn’t be able to use under Catalina without resorting to more convoluted solutions like virtualisation or dual-booting. Why would I want to upgrade?

If I need to use Catalina for something work-related, I’ll get a used Mac that can run it, and perform a fresh install. Sure, it feels expensive and overkill. I shall take a page from Apple’s security approach here — Better safe than sorry.

But this is me. These are my assessments of Mac OS Catalina. This is my strategy. My initial article only wanted to outline this — Personal observations, personal strategies, commentary on the direction Apple is driving Mac OS. My only intent was to raise awareness about Catalina’s disruptive qualities. And that Catalina is a disruptive release — both from a technical standpoint and from a user interaction standpoint — is a fact, not an opinion.

The best feedback I have received is from people who didn’t know much about the changes Catalina introduced, and who thanked me for the information provided. That in turn helped them think more about their strategy and make some hopefully more informed decisions.

And that’s really it.

A heartfelt thank you to all the people who have been reading and taking the time to send me feedback via email. It’s really, really appreciated.

 

 

Previously:

 

Mac OS Catalina: more trouble than it’s worth (Part 3) was originally published by Riccardo Mori on Morrick.me.

Mac OS Catalina: more trouble than it’s worth (Part 2)

February 14, 2020
by Riccardo Mori
Software

I should have listened to you. When I read your post Mac OS Catalina: More Trouble Than It’s Worth I honestly thought you were just bashing Apple for the sake of bashing. I thought your critique was too subjective to be taken as ‘advice for everybody’ if you get my drift. I read your post and thought, “Well, he doesn’t want to upgrade his machines and he has his reasons, but I don’t share his concerns, I’m gonna be fine.” Hoo boy, was I mistaken.

I don’t know if mine was just sheer bad luck, but since installing 10.15 I’ve run into so many issues. First, when I went on and updated my Mac mini from Mojave to Catalina, the installation didn’t complete. It just hung for hours, and I mean hours as I left the mini at that all night and the morning after there was no progress whatsoever. So I just switched off the mini and reinstalled Catalina from scratch, a fresh install. I thought I could restore the important stuff from a TM [Time Machine] backup. This time Catalina installed properly but then TM didn’t even recognize the backups from my external drive.

Luckily I also have an older MacBook, and while I don’t keep everything in sync, I was able to access most of my stuff and transfer files and everything to the mini. I manually copied my Mail archives and tried having Mail on the mini to import them, but no joy. Every time Mail in Catalina crashed. At the moment I have no way to access the most updated files of the past two weeks.

[…] Does my backup strat suck? Yeah it probably does. I’ve always been a “TM is enough” sort of guy. I’ve always trusted Apple not to screw things up, and honestly everything up to now has always worked for me. Never had a problem with my Macs, hardware or software. But I didn’t expect this ordeal when I went to update to Catalina. Now obviously I’m not going to touch the MacBook. Has Mojave and stays on Mojave. And honestly I don’t know what to do with the mini. It has a fresh install of Catalina, it’s like starting from scratch again, and I’m already tired of clicking on dialog boxes asking me permission for so much stuff like accessing folders that OBVIOUSLY I want the OS to access. I’m tempted to wipe the mini again and downgrade to Mojave. Maybe it’ll recognize my TM backups again and I can go back to before this nightmare went down.

This is a good chunk of one of the latest emails I have received from people (some I know from the Internet, some are friends, some — like this example — are strangers) complaining about Mac OS 10.15 Catalina. The only part I’ve left out is this person’s criticisms regarding the new first-party apps (Music, TV, Podcasts), their UI, and the splitting of iTunes into different apps.

The amount of feedback I’ve received about Catalina in the past few months is staggering, to the point that I have created a dedicated folder in Mail to collect all the messages that keep coming on a fairly regular basis. They’re 83 so far and — spoiler alert — 98% of them are complaints. The remaining 2% are neutral. They’re from people who simply wrote me to let me know they have upgraded to Catalina and ‘survived’, and that they have no issues to report so far.

The complaints are varied, and go from minor things like begrudgingly accept the loss of 32-bit apps, or disliking the strictness and user hostility of the added security measures. To more serious troubles like the partial loss of email archives, unexpected system freezes and applications crashing, preferences that don’t stick, Catalina’s poor handling of external displays connected to MacBooks, inability to access previous Time Machine backups, and so forth. I chose to publish the email excerpt above because it was one of the most detailed I had received, and it came from what appears to be a rather tech-savvy person.

But some of the feedback from regular folks is just as sad. People asking me “Where the heck is iTunes? Where’s my music?”, or shocked that some of their applications don’t work anymore (32-bit apps, I assume). An acquaintance of mine was crushed when she realised that not only did Aperture not work under Catalina, but that Apple had stopped developing it some time ago. Another was overwhelmed and bewildered by the initial barrage of security-related dialog boxes, to the point that they were afraid they had done something wrong (or something had gone awry) when installing Catalina. Another made a remark that was as bitter as it was funny: “Sooo… I upgraded. Can you summarize what’s changed here compared to Mojave, apart from the desktop background?”. Another person wrote me an email with the subject, I have updated to macOS Catalina and here’s what I found; the body of the email simply said, Bugs bugs bugs bugs bugs bugs.

I take no pleasure in reporting this, but a good amount of messages had another thing in common: people were apologising to me for having disregarded my advice to avoid upgrading straight away without doing some homework first, or for criticising my piece on Catalina as being too excessive, too subjective or too negative, like many people did when it was linked from Hacker News. (Not to mention those basically calling me an idiot, a luddite, an entitled teenager(!), or someone who doesn’t ‘get’ tech).

Almost four months have passed since I wrote Mac OS Catalina: more trouble than it’s worth and my opinion hasn’t changed at all. If I do end up installing Catalina, it’ll be a fresh install on a Mac that will be acquired for the specific purpose of running Catalina, just in case I need to test or translate applications that have Mac OS 10.15 as minimum requirement. But I’m not going to compromise my production machines.

It’s interesting to me how — apart from the usual fanboys — I still haven’t seen any unequivocally positive feedback about Mac OS Catalina. I still haven’t found someone saying, Oh man, everything is so much better after upgrading to Catalina. I can take advantage of these new features, and my workflow and productivity are so much improved compared with Mojave or High Sierra. I’ve either read people saying, Yeah, I upgraded and nothing broke, thank goodness, or complaining about something they’ve lost or having changed in a disappointing way. What I haven’t seen is something I used to see more frequently in the past when a new major release of Mac OS X was introduced — enthusiasm.

If you read the Macs section of Howard Oakley’s blog, you can appreciate a more technical explanation of the many under-the-bonnet changes introduced in Catalina, and a generally neutral position on what has changed for the better, and what keeps being problematic. But having to dig this deep down the technical side to find something positive in Mac OS Catalina, to me, feels a bit troubling.

When Mac OS X 10.6 Snow Leopard was introduced as having “no new features”, even regular folks understood what that meant; they understood it was a release aimed at fixing past bugs and improving the general stability and reliability of the system. Judging from the feedback I’ve received, the general impression with Catalina is that 1) most of what’s new doesn’t strike as being much better than what Mojave and earlier versions offered, and 2) unlike Snow Leopard at the time, every ‘invisible’ change doesn’t seem to bring more stability or reliability, just more disruption in a way or another.

In October I wrote:

But Catalina is a decidedly controversial upgrade, and in my case I didn’t even have to debate too much whether I should upgrade or not. The answer is no. The reasoning behind it is quite simple, actually, and it boils down to this: what Catalina takes away from me is more than what it gives me.

Four months later, this seems to be true for a few more people. And Catalina looks more and more like a transitional release Apple needed to push out while preparing for what’s next (preparing the ground for an architecture shift, for example). It increasingly feels like an entirely skippable release, just as Yosemite was. (Oh yes, it was). What we’ll see in Mac OS 10.16 is probably going to be the proverbial moment of truth.

Related reading

 

Mac OS Catalina: more trouble than it’s worth (Part 2) was originally published by Riccardo Mori on Morrick.me.

Other platforms — The Nokia N9

February 9, 2020
by Riccardo Mori
Tech Life

Swipe

Introduction

I was interested in acquiring this smartphone because I wanted to understand what was so special about it; why it had reached a ‘cult’ status; why it’s so much sought after. I had been seeing eBay listings with relatively high asking prices for N9 units in good condition.

Fortunately I was able to acquire one just for the cost of shipping. As luck would have it, someone saw my tweets about the BlackBerry Passport I revived, and told me I could maybe have some fun with their old handset, which runs yet another OS. I thought they wanted to donate a Nokia Lumia 800, but it turned out to be an N9.

The phone is in very good condition, and with a battery that is still quite healthy, lasting almost two days on a single charge and with cellular and Wi-Fi connections enabled.

Quick Specifications

Introduction Announced in June 2011, released in September 2011
Dimensions Width: 61.2 mm — Height: 116.45 mm — Thickness: 7.6 to 12.1 mm
Weight 135 g
Display 3.9″ AMOLED, 16M colors, 854×480 pixels
CPU Texas Instruments OMAP 3630 SoC that includes 3 processor units: 1 GHz ARM Cortex-A8 CPU (for OS and apps); Imagination Technologies PowerVR SGX530 GPU supporting OpenGL ES 2.0; 430 MHz TI TMS320C64x Digital Signal Processor (image processing for the camera, audio processing for telephony and data transmission)
Memory & Storage 1 GB RAM, 16 or 64 GB storage
Connectivity GPS and A‑GPS, Compass, WLAN 802.11 a/b/g/n (2.4 and 5 GHz), micro USB 2.0, Bluetooth 2.1+EDR, NFC, FM receiver
Audio 3.5 mm audio jack; supported codecs: MP3, AAC, AAC+, eAAC+, WMA, FLAC
Video 720P, H.263, H.264, MPEG‑4, WMV 9, Matroska
Camera Rear: 8.7 MP AF camera with Carl Zeiss optics, dual-LED flash, wide-angle lens (ƒ/2.2, Focal length: 3.77mm / 28mm). Front: VGA resolution
Operating System MeeGo 1.2 “Harmattan”

What makes it unique

While MeeGo is certainly an interesting OS, and the Nokia N9 appears to be the only handset featuring it, what really makes this device stand out is the design of the user interface and the whole user experience.

When the N9 was introduced, Nokia created an entire mini-site to illustrate the user interface and interaction design guidelines. Since 9 years have passed now, those materials aren’t accessible anymore. Fortunately the whole mini-site, complete with downloadable assets, has been preserved and mirrored by the owner of the n9.dy.fi website: Nokia N9 UX Guidelines

What I really love about the user interface is that it’s based on solid foundational principles that in turn guarantee a very consistent, predictable, intuitive user interface.

The Guidelines strike me as being concise, sharply-focused, clear and straightforward, and more importantly extremely thoughtful. They are indicative of a great deal of depth, and at every turn you get the feeling that all the people involved in the hardware and software design of the Nokia N9 had very clear ideas and goals in mind.

With all the gestures and gesture combinations we have to learn on current smartphones (iOS and Android alike), it’s truly refreshing to see how the purposefully limited set of gestures (mostly swipes — the swipe is at the core of the user interaction on the N9) you perform to navigate the N9 operating system, give you access to everything you need without becoming overwhelming. The core gestures are extremely easy to memorise, remain consistent everywhere, and are sufficiently distinct so that you don’t run the risk of doing something wrong or destructive by executing them partially or incorrectly.

Central to the user experience is the flow — eliminating as much friction as possible was clearly one of the goals here, and was entirely achieved with an effectiveness I haven’t seen anywhere else.

Nokia N9 overal ui model

As I mentioned earlier, the swipe is the core gesture, and it’s how you access almost everything on the N9. The first thing you notice is that the N9 has no Home button or other physical or persistent software buttons for navigation. The only physical controls present on the device are Volume Up/Down buttons and a Power/Lock button located on the right side. Nothing else.

Like on Windows Phone handsets Nokia would introduce later, when the N9 is idle, time and notifications (such as new mail or app updates) are displayed persistently. The display is AMOLED, so this feature doesn’t impact battery life much. To wake the phone, you can either press the Power/Lock button or simply double-tap the screen. The screen becomes brighter, the lock screen wallpaper will appear, together with any notification that came when the phone was idle.

At this point, you can access the Applications screen by swiping down, or access the last view you were in by swiping right from the left edge:

Nokia N9 lock screen

 

Nokia N9 home 1

Once in the Applications screen you can swipe right to access the Events screen, where you’ll find notifications and feeds; or you can swipe left to access the Open Applications screen, where you can multitask by switching from an open app to another, or quit apps you no longer use by selecting them. Open apps can be viewed on a 2×2 or 3×3 thumbnail grid. You make the thumbnail bigger or smaller by pinching in or out. The most recently used apps are always on top.

Another little touch that I love is that you can cycle through these three main screens simply by continuing to swipe. For instance, if you’re in the Open Applications screen, there is no need to swipe right twice to go back to the Events screen: you just swipe left once more. No matter the screen you’re in, you can keep swiping in either direction; it’s a carousel:

Events ↔︎ Applications ↔︎ Open Applications ↔︎ Events ↔︎ Applications … etc.

And that’s essentially it — you’re in these three main screens 95% of the time. Each of these screens doesn’t have ‘sub-screens’ or multiple pages. There isn’t a separate Notifications pane and Today view like on iOS. It’s all on the Events screen. The Applications screen is just one: as you install new applications, you just scroll down to find them. You can use folders to keep things tidier — and of course you can rearrange the apps in exactly the same manner as you do on iOS — but you don’t have separate pages like on Android or iOS. Scrolling is very fluid, so it’s not really a problem.

Judging by what I’ve told you so far, you might find this UI model limited or too inflexible, but I actually think that it’s very efficiently organised. The gesture language is minimal but consistent. The spatial arrangement is such that you intuitively know that moving left and right in the UI changes the view, while going down gives you more of each view, so to speak.

The two remaining parts of the user interface you can access are:

Status menu

1. What Nokia calls the status menu. This is always accessible by tapping on the status bar (or status area, as Nokia calls it). When you tap it, it clicks like a button (it really gives you a haptic feedback). I love the design of the two volume sliders. Volume can be adjusted by tapping on the bar. Profile (ringer) also works with the phone’s volume buttons. As you lower it, the bar enters Beep and Silent status.

Quick launch bar

2. The quick launch bar. As the user manual explains, “In all applications, and even on the lock screen, you can easily make a call, or access the camera, web, or messages. When holding your phone upright, drag your finger from below the bottom of the screen onto the screen, and hold your finger in place, until the quick launch bar is displayed.” In practice, it feels like you start a meaningful, slow swipe from the bottom, and at one point you release and the launch bar pops up, as if you were uncovering something that was hidden under the bottom of the screen, if that makes sense.

Designing the UI around the swipe: today, it seems trivial. Swipes are everywhere, in every touch interface, on smartphones, tablets, smartwatches; but the Nokia N9 is the only device where this essential gesture is implemented in a natural, intuitive, cohesive, frictionless way. Take for example the act of dismissing an app when you’re done with it. You don’t need a button to return to the Home screen, but you also don’t need to remember how to swipe and which direction to swipe. You exit the app by swiping wherever you want — up, down, left, right, whatever is most comfortable at the moment.

Earlier I wrote that, once you unlock the phone, “you can access the Applications screen by swiping down, or access the last view you were in by swiping right from the left edge”, but the truth is you can access the last view you were in by swiping in any direction. This is consistent with the way you dismiss an app, because you’re essentially doing the same task — dismissing a UI layer you don’t need anymore.

Tone and language

There is an interesting section in the Getting Started part of the Nokia N9 UX Guidelines that gives the prospective developer of an N9 app some advice regarding the tone and language they should employ in their app. While I’m sure this kind of suggestions are present in the UI Guidelines of other operating systems, I just wanted to point out how sensible these are. Further, they easily apply to any system you’re developing for. Here are a couple of examples:

• The tone and language we use is straightforward and conversational. This means we avoid engineering terms, overly technical words, obscure acronyms and industry jargon.

• Nokia N9 is friendly — But it’s not overly friendly. […] [W]hile we encourage you to keep the UI strings short whenever possible, we do not recommend you do so at the expense of a more friendly tone. You need to make a judgement call between space and warmth. […] Having said that, we avoid exclamations like ‘oops’, ‘eek’, ‘oh dear’. Though these can add personality, they are too widely used and add to the on-screen word count. We’re always looking for a balance between brevity and cordiality.

Quick aside on the hardware

At this point I’m going to state the obvious: the Nokia N9 is the best smartphone I’ve ever handled when it comes to one-handed use. It’s no mystery that it’s designed from the ground up to be used with one hand, and it shows. Size-wise, this is a phone in the iPhone 5/5s/SE range. But the curved polycarbonate shell of the N9 is sculpted in such a way that it feels particularly great in the hand. It’s never cold to the touch, and it’s smooth without being slippery.

When introducing the N9 in 2011, Marko Ahtisaari (Nokia’s Head of Product Design at the time) said this about the phone’s body:

The body is precision-machined from a single piece of polycarbonate, in inherent colour. What ‘inherent colour’ means is that the polymer is coloured throughout; and that means if it scratches, it’s still the same beautiful [colour] that you see here.

When speaking of the material employed for the case, he also throws a quick jab at Apple’s iPhone 4 and the then-infamous ‘Antennagate’:

The polycarbonate is also good for another reason: it gives us extremely good antenna performance. So, unlike some competitor products, you don’t need to hold it in a special way to make reliable phone calls.

And while ‘Antennagate’ was a stupid thing that got blown out of proportion, I must say that I’ve been using my N9 with a secondary SIM card for a few months now, and both cellular coverage and call performance have been remarkably good.

Back to the software: the visual design

Nokia MeeGo icons

Unsurprisingly, the visual design of the user interface is as consistent and well-thought-out as the rest of the experience. I find the icon design particularly pleasing. Icons have a unique shape that’s been called squircle because it’s not a square (like on BlackBerry OS), it’s not a circle (like on Android), and it’s not even a square with rounded corners (like on iOS). If anything, it’s more like a circle that’s just starting to morph into a square.

As you can see in the image above, the icon’s æsthetic is an excellent mix of skeuomorphism and flat design, and I personally think it has aged very well. First-party app icons are tasteful, and I particularly like the added depth to the main pictogram, so that it nicely stands against the background without trying too hard to look tridimensional.

In the Launcher Icons Guidelines document, icons’ design and properties are outlined in detail with simplicity and precision:

One light source

 

In app icons

 

Naturally, the squircle shape is a recurrent character throughout the system. It’s not just limited to icons (application icons, in-app icons, status area and lock screen icons, etc.), but it also appears in buttons, switches and sliders.

Settings

Another important element of the UI’s visual design is, of course, the system font. It is called Nokia Pure, and was specifically designed by the Dalton Maag type foundry. When the N9 was new, the font was used on the Nokia website and has been part of Nokia’s visual identity ever since.

Nokia Pure font

I find it very nice to read, and remains legible even at very small sizes. If you download the Toolkit in the Downloads menu of the Getting Started section of the Nokia N9 UX Guidelines, you’ll get the whole Nokia N9 UI as Adobe Illustrator files, plus a folder containing the three weights (regular, bold, light) of the Nokia Pure font in TrueType format.

Some examples of nice UI touches

ShotMee
How did I take these screenshots? The Nokia N9, surprisingly, doesn’t have a built-in action to capture screenshots. I found a cool app, ShotMee, that you open and keep in the background; when you need to take a screenshot, you double tap the phone on the right side. That’s right: the phone, not the screen!

 

Status area
The status area. I love the design of the two volume sliders. Volume can be adjusted by tapping on the bar. Profile (ringer) also works with the phone’s volume buttons. As you lower it, the bar enters Beep and Silent status.

 

Camera settings
Part of the camera settings. The N9 camera app features a fair amount of manual controls and the experience resembles more that of a compact digital camera than a smartphone camera. You can manually select the ISO (range is 100–800), aspect ratio (16:9, 4:3, 3:2), and resolution. You can also toggle Face detection and Continuous shutter.

UI-wise, you can appreciate once again the consistency of the icon design, and the clear contrast between the active and inactive states of a button.

 

Mail views
Mail app — List view and Message view. Nothing groundbreaking, just a simple, effective interface. The Nokia Pure font is quite readable even at this size. The contact’s profile icon and the Back button are, again, a squircle. The toolbar icons are tasteful and unambiguous.

 

Clock - Alarm
Clock app — Alarm view. Once again, a clean and simple design that allows you to set the alarm time with just one hand without friction. The Hour and Minute circular sliders are exactly where your thumb will be. Notice also how the subtle shadows give just the right amount of depth to the UI elements, striking a good balance between skeuomorphism and complete flatness. On a more curious note, the Clock app doesn’t feature a stopwatch or timer.

 

Nokia N9 device icon
To transfer files, pictures and music on the Nokia N9, you just connect it via USB to your computer and access the relevant folders. Just like you did with, say, the Palm Prē. It’s the simplest method and doesn’t require dedicated apps. By the way, when I connected the N9 to my Macs, I was pleasantly surprised to see it was given its correct icon!

 

Music app 1
Music app. This is the typical interface when an album is playing. Nokia was doing ‘dark mode, whoa!’ in 2011 already.

 

Music app 2
You want to see the other songs in this album? You tap once on the artwork and the track list appears.

 

Music app 3
When you tap the Back button (←), you return to the Music app’s ‘main’ page, showing the various album artworks. If an artwork image is not available, one is created using the album title and an accent colour. Much better than a generic ‘music note’ icon. Notice also how you can still see which track from which album is playing at the moment (Morphine’s You Look Like Rain in this case).

 

Music lock screen
When you’re playing music and you wake the device, a minimal controller will appear on the lock screen.

Is it still usable today?

This, admittedly, is the less exciting part. It’s a 2011 smartphone, but the fact that it’s a 9‑year-old phone isn’t really problematic per se. I also own an iPhone 4 and an iPhone 4s — introduced in 2010 and 2011 respectively — and when it comes to ‘things that still work’, they’re both more usable than the N9. That’s due to their software. I may have become very critical of Apple in the past few years, but one thing is undeniable: iOS is the mobile operating system that has aged better of all, functionality-wise. Take any other smartphone from ten years ago, with any mobile OS version it supported at the time (BlackBerry, Android, webOS…) — you won’t get much done with it, as is.

The Nokia N9 is on this same boat. You’ll have to tinker if you want to restore some of its functionality. The N9 is the only handset that came with the MeeGo ‘Harmattan’ OS. It was just before Nokia switched to Windows Phone. Support was dropped soon. If you acquire an N9 today, you’ll soon find out that, out of the box:

  • All features relying on Nokia services don’t work. So, for example, forget Maps and driving directions, and forget Nokia’s app store or music store.
  • When inserting a SIM card, the N9 will prompt you to connect to your Nokia account. But since you can’t create a Nokia account anymore, that is going to be problematic.
  • Social network clients that came built-in, such as Twitter and Facebook, won’t work because they make use of now-deprecated APIs. Same for services like AccuWeather, Skype, Dropbox, Flickr, YouTube, etc.
  • Web browsing is going to be hit-or-miss. Lots of websites relying on secure connections with modern protocols won’t load.
  • If you acquire an N9 with an older version of the OS (the last was MeeGo Harmattan 1.3), the phone may tell you that there’s an update available, but since the Nokia servers delivering such updates are now unreachable, you won’t be able to just update it over the air.

I’ve probably forgotten other issues, but I’d say these are the bigger ones you’ll encounter first, and may sour your initial experience with the device. If you want to leave your N9 untouched because you don’t feel like applying a few mild hacks to make some stuff work, and you’re just curious about the UI and the general feel of the N9, you can still use the device in a limited way. Mail should work (Gmail is giving me problems recently, but up until January it was working), the Music and Video apps work. Basic Web browsing is feasible. Calendar, Clock, Contacts, Messages, Camera, Calculator, Documents (a nice document viewer), Feeds and Notes all work. Not much, but better than nothing. At the very least you can use it as a pocket camera, MP3 player, and alarm clock.

Since I always wish to put vintage devices to good use, I was willing to tinker a bit to make my N9 more usable. The problem is that I did the majority of fixes and workarounds the very first days I received the phone, at the beginning of November 2019, and I was so excited and eager to make the most of this N9 that I forgot to take notes of everything I did. As soon as I have some time, I’ll be writing another piece on the various steps to perform to ‘revive’ the N9 so that it can be more useful today. Meanwhile, an essential starting point is this page: Resurrect Your N9.

Media

 

Nokia n9 colours

Final thoughts

Now that I finally own a Nokia N9, I understand why I always get some kind of enthusiastic feedback when I mention it. I’ve been really blown away by the sheer amount of great user interface ideas and by its tight hardware/software integration reminding me of the ‘good’ Apple of a few years ago.

It’s truly a pity that this device was sort of doomed from the beginning. As the Wikipedia entry for the N9 states, “Nokia planned in 2010 to make MeeGo their flagship smartphone platform, replacing Symbian, whose N8 flagship launched that year. Thus effectively N9 was originally meant to be the flagship device from the company. On 11 February 2011 Nokia partnered with Microsoft to use Windows Phone 7 as the flagship operating system to replace Symbian, with MeeGo also sidelined. Nokia CEO Stephen Elop promised to still ship one MeeGo device that year, which would end up as the N9.”

I’ve grown to know and love Windows Phone as a mobile operating system, and I’ve already said that, in some aspects of its user interface, it was more innovative than Android or iOS. However once you reflect on the history of the Nokia N9 and MeeGo, you can’t help but think about what would have happened if things had gone differently; if Nokia didn’t partner with Microsoft and kept developing other MeeGo smartphones with the same, excellent user interface as the N9.

Whenever I pick up my N9, feel it in the hand, wake it up and use it, everything about it just clicks. The care and thought that went into the entire design of this device, from the hardware to the software, is so evident it somehow hurts that this device had such a limited lifespan and success when it was available. It hurts when you use mainstream platforms like iOS and Android and stumble onto gestures, features, and UI ideas that feel so clearly bolted on, or inconsistent, or simply poorly designed and frustrating to execute — and then you go back to this 9‑year-old smartphone and everything feels so tight and coherent.

(In case you were wondering: In my day-to-day, I usually carry more than one smartphone. My main unit is still an iPhone, but I typically have another handset with me. And since I now have accumulated a fair amount of devices from other platforms, they’re on rotation. I’ll have the Nokia Lumia 1020 with Windows Phone 8.1 for a few days, then switch to the BlackBerry Passport, then to the Palm Prē 2, then to the Nokia Lumia 830 with Windows Mobile 10, then to the Nokia N9, etc. But the N9 feels so great to have around that I found myself keeping it with me anyway. So yes, sometimes I’ll have three phones with me and maybe even an older iPod as well. I’m fine, there’s no need for an intervention.)

But it’s not all lost. Fortunately, many of the concepts of MeeGo’s swipe-based UI live on in Sailfish OS, another linux-based OS developed by Jolla, a Finnish tech company. As noted in its Wikipedia entry, “The OS is an evolved continuation of the Linux MeeGo OS previously developed by alliance of Nokia and Intel which itself relies on combined Maemo and Moblin. The MeeGo legacy is contained in the Mer core in about 80% of its code; the Mer name thus expands to MEego Reconstructed. This base is extended by Jolla with a custom user interface and default applications. Jolla and MERproject.org follow a meritocratic system to avoid the mistakes that led to the MeeGo project’s then-unanticipated discontinuation.”

Still, I wish Sailfish OS were less of a niche system than it currently is. Android and iOS need competition. All the mobile operating systems that tried being an alternative failed mainly due to the Not Many Apps syndrome, and at the same time every one of them had at least some features or some UI concepts that were much more interesting and innovative than Android and iOS. (And, as we’ve seen, the Nokia N9 has many of these). It’s a very frustrating pattern. Meanwhile, the iOS/Android duopoly has slowed down innovation in mobile operating systems and in their UI in particular. Think about the last four or five releases of iOS and Android: a lot of iteration and refinements, in some cases verging on more complication and feature creep, and a lot of ‘playing safe’ overall.

Anyway, I’d really love to try installing Sailfish OS on a compatible handset and explore the user interface. It appears that it can be installed on smartphones such as Sony’s Xperia X and XA2. If you own such a device, or another in the list included in Sailfish OS’s Wikipedia entry, and you don’t use it anymore, let me know if you’re willing to donate it. I’ll certainly document my experience here on this blog.