Thursday, April 9, 2020

iPad Main Menu

Alexander Käßner (via Kontra):

This concept brings the main menu we know and love from Mac to iPad. It keeps the numerous advantages of a written menu, redesigned with touch devices in mind.

iPad Main Menu helps bring a vast amount of features to iPadOS for people who seek out this power, while keeping the OS accessible for users who prefer a simpler experience.

Riccardo Mori:

Every concept I’ve seen to ‘improve the iPad’s UI’ adds Mac-like elements/ideas to the interface. […] Some ideas are not bad, per se, but I keep wondering, Will we ever think outside of this box?

At what point do you give up waiting for a revolutionary idea that may never come and go with an old idea that works?

Meanwhile, third-party developers try to make the existing design work better.


12 Comments RSS · Twitter

I was simply wondering when someone will start approaching user interfaces outside of the 40+ years comfort zone of the desktop metaphor. But the more time passes, the more this appears to be just like with typewriters and keyboards. Tried and true input device, tried and true layouts.

I'm not exactly waiting for one specific revolutionary idea. More like a desire to get more experimental and approach things differently? Not for the sake of being different but maybe… to see whether there might be an alternative? Something better?

iOS started as a sleek variant of Mac OS X (if you forgive the simplification). Is iPadOS bound to become as 'heavy' as Mac OS X, iteration after iteration? If that's the path, well, okay. Maybe making a Mac OS X touch device 10 years ago would have saved a lot of time and virtual ink, ultimately.

First concept: The background music in the video should be "Start Me Up".

This isn't a criticism - just a question.

Did I miss something, or does this concept only imagine an iPad Main Menu in landscape mode?

> At what point do you give up waiting for a revolutionary idea that may never come and go with an old idea that works?

Looking at how long Apple tried to "reinvent" the filesystem on iOS before giving up and releasing the Files app, after about 10 years.

As for this concept, the idea is better than the design.

@Riccardo I don’t mean you, I mean Apple. I wonder what’s going on behind closed doors. Are there lots of experimental ideas that never shipped, because they thought they hadn’t gotten it right yet? Or are they internally pretending that these issues don’t exist? It seems like the entire iPad strategy was predicated on the idea that they would come up with a different way, but there’s no external evidence of that work being done. If we end up with the two platforms converging such that the main difference is the degree of sandboxing, that would be disappointing.

@vintner Yes, that’s a similar situation. It’s also disappointing because it seems like they gave up on finding a better way, but then we ended up with something much less functional than the Mac file system.

>Looking at how long Apple tried to "reinvent" the filesystem on iOS

I don't see any evidence at all that Apple made any serious attempts to reinvent the filesystem. They pretended for ten years that the problem didn't exist, and then they just wrapped a cut-down Finder window inside a crappy iOS app and called it good.

This kind of stuff is hard. It needs resources. It needs a powerful cheerleader inside the company. It needs really, really good UX designers, it needs developers to create prototypes, it needs researchers to test ideas, it needs iteration, and then it needs communication, to convince people to follow these ideas, to convince developers to support what's being built. There's no evidence that Apple is doing any of that. There doesn't seem to be any leadership or vision, or any desire to improve these things.

@Riccardo I appreciate the sentiment you're expressing, but I think it has an easy explanation: The desktop paradigms we're using now are the result of decades of refinement and constant competition and experimentation in one of the most experimental and innovative fields ever. I.e., it's not comfort, we're using the paradigms we're using because they've already won, they're the best.

There's this strange tunnel vision that happens with iOS where suddenly people seem to be thinking all of the experimentation and competition we've already done with computers is no longer relevant, which I have trouble understanding. New form factors offer some differences, e.g., a computer without a keyboard becomes sensical when the trade off is that you can carry it in your pocket, but expecting all the decades of work we've already done to no longer be relevant for the majority of use cases just doesn't make sense to me.

Sören Nils Kuklau

I do wish Apple had done a better job establishing new paradigms in the iOS era. Conceptually, the Mac was much further along in 1994 (after ten years) than the iPad is in 2020 (again, after ten years).

I also think the customer base wasn't as willing to follow, though. When Apple did make some bold moves in 10.7 Lion, like trying to kill the strange "Save As" command, people revolted. Maybe that's in part because the replacement (saving automatically, offering versions, and offering a "Duplicate" command for when you need to branch off) wasn't as good as it should've been, but I think it's also in large part due to user inertia.

I think the idea that user resist change is overblown. Users have demonstrated they will rapidly migrate to a new way of doing things if there's sufficient benefit to doing so. Some examples are QuarkExpress to InDesign, the popularity of Google Docs and Webmail, and the still in motion progress of digital product design migrating from Photoshop > Sketch > Figma. I think the Save stuff didn't go over well because it's just worse than what it replaced.

Adding to my previous comment, there are some innovations in recent memory that have stuck, the canonical example is apps that abstract away files, like iTunes and iPhoto originally did. This concept is what eventually led to iOS being designed the way it is (an App-centric OS vs. a file-centric OS), so if we're looking for how a successful innovation emerges, that's a great example to look at. One of the interesting things about it is it's created sort of a casual vs. pro divide in app design. Pro apps are generally file-based (Lightroom being the notable exception) and casual apps usually have no files. Which at least partially explains why iOS has been so unsuccessful for pro use cases, the entire model it's designed around hasn't been successful for those use cases either.

>The desktop paradigms we're using now are the result of decades
>of refinement and constant competition and experimentation (...)
>we're using the paradigms we're using because they've already won,
>they're the best

That does not strike me as a plausible hypothesis, for four reasons.

First, it's not true that there have been decades of refinement. We got the desktop and file metaphor with the earliest visual user interfaces in the 70s and early 80s, and we're still using pretty much the same user interface. Little has changed. We got some stuff glued on top of desktop-style file managers, like tags, but they barely work. The only meaningful new feature we got after the initial file manager was fast search, and that is still pretty bad. It's easier to find something on the Internet than it is to find it on your local disk.

Second, the current user interface for file management doesn't really work. How many people do you know who regularly lose track of where their files are? Who accidentally delete stuff they still needed? Who just store everything on their desktop? Who always retrieve files by just searching for them, intentionally avoiding the desktop file system altogether? Conversely, how many people do you know who actually successfully create hierarchical folder structures to store, manage, and retrieve their files? For me, that's zero people, I don't even do that mayself. The way file management currently works is clearly not a good match for a lot of people.

Third, the world has changed. When the desktop paradigm was introduced, people had a few dozen files, mostly created on their own, stored on roughly megabyte-sized diskettes. Today, people have thousands and thousands of files going back years or decades, stored on terabyte-sized local disks, on multiple different computers, on network drives, on cloud storage systems, and on file repositories. These files belong to companies or projects, and are often being worked on by teams of people. This world is so different from what people did in the past that it often isn't even possible to show these files in a regular old desktop-style file manager in any kind of meaningful way.

Fourth, a lot of applications that aren't themselves file managers, but deal with managing a lot of files (iTunes, for example, or versioning system clients), do not go for the traditional desktop-style file representation. Once people stop thinking of an application as a file manager, they never opt for the traditional desktop metaphor. It's only when people set out to create a file manager that they go with that paradigm.

It seems to me that there is good evidence for the idea that traditional desktop-style file managers are a bad idea, and only exist because they're, well, traditional.

@Lukas Those are all great points, I don't disagree with any of them (yet files remain).

I would summarize my counterargument this way:

1. I believe users switch easily to better solutions when they present themselves, see my other comment ( for some examples.
2. Users haven't switched off of files to another solution for many use cases. In reality, files have lost a ton of ground to DB-backed apps and URL-based web apps, largely for the reasons you've listed. It's just that some use cases haven't budged a bit from files, so if you want to support those use cases you need files (and all the baggage that comes with them). I'd also take that as proof that for those use cases, files are still better than the other solutions, regardless of their flaws.

Sören Nils Kuklau

Pro apps are generally file-based (Lightroom being the notable exception) and casual apps usually have no files. Which at least partially explains why iOS has been so unsuccessful for pro use cases, the entire model it’s designed around hasn’t been successful for those use cases either.

It may look that way on the surface, but you point out Lightroom as a counter-example. Aperture (RIP) also heavily relied on you not thinking of photos as files. Many of its concepts like stacks really wouldn’t have worked well otherwise.

But there are quite a few more counterexamples. A ton of LOB apps (which surely count as “pro” apps! it’s what people working — i.e., professionals — use to get by their day) are basically database front-ends. They may have some form of access to individual files, but the main metaphor to think of is typically records — of contacts, invoices, projects, notes, whatever the case may be. You may take a record and export it, such as to a PDF, Excel sheet, etc., but you don’t really think of the record itself as an individual file. (Nor could you, at a technical level. You’d need to first collect and aggregate lots of other related records.)

So from that vantage point, files actually aren’t that common in many a person’s daily work.

Yet quite a few types of apps are still on the file train. For those who don’t do accounting in a database, they’ll probably use spreadsheet files. Writing letters typically involves files. Writing code involves a lot of files, and in plain text no less, with all the weird limitations that implies (Smalltalk tried to tackle this almost half a century ago, and basically failed). We’re literally comparing lines of text in a tool like diff, and version control builds on top of that. How barbaric, and error-prone (tools like SemanticMerge have tried to tackle this, with limited success).

I was hoping for more on this front from Apple, and while I’m glad the Files app is there, I think Michael is right:

It’s also disappointing because it seems like they gave up on finding a better way, but then we ended up with something much less functional than the Mac file system.

(I also wish Bento hadn’t been discontinued. That market must be hard. But why wasn’t Bento part of iWork?)

Leave a Comment