My wife is currently using Affinity and Adobe products to work on illustrations. It works mostly the same for her as on her Mac. She does not care about small, specialised tools, she wants one app that does everything she needs. The iPad is doing a great job running those apps.
I am not sure how many users (outside of the ones who got used to it) want UNIX-like flexibility vs "give me an app that does everything I need". If the later group keeps getting larger the walled garden approach to apps might actually work.
It's not just UNIX-like flexibility, it's human uniqueness, and the uniqueness of the tasks they perform and the ideas they have. It's also the difference between owning and knowing how to use a tool, versus renting someone to do it for you who might help you today, but could rob or hurt you tomorrow.
Just consider how we spend decades to teach new humans to read and write as well as they can learn it, versus just giving them a bunch of emoticons to signal when they're hungry or sleepy or bored. Because we expect them to become full peers, and architects of their world, responsible for the next generation, not just consumers picking options others prepared for them. And we don't care if they want that, because we know what they don't know, yet. We base our judgement on the information we have, not the information they lack.
Making an exception for computer literacy just because it is hard (as if language and reading and writing aren't until you get used to them) set us on a terrible path.
Thanks for this summary of the case for general purpose computing.
But nobody would suggest that someone that can only put together an IKEA nightstand is qualified for carpentry on the level of house building or fine cabinetry. Just because you can water a garden with a hose doesn’t qualify you to work on water mains.
Take this with a grain of salt, as it is based mostly on my own experiences, although I remember at least an essay from Paul Graham talking about how rare it is to have a programmer switch languages after some age.
I’m sure it’s hard to learn to be a serious programmer past a certain age. But it’s not easy to learn a new (human) language or get really good at many of the other skills I mentioned that quickly either.
I think this is crux of the matter. Even outside the Apple ecosystem I see a tendency in people to not think about composing multiple tools but to look for an app that does everything.
I'm talking about my colleagues, working in IT, but in a Windows environment.
And on Windows there's PowerShell, which, although slow and to me not as flexible as bash, still allows one to do quite a lot of things. But people seem to see using it as a last resort, when there's absolutely no way of doing what they want by clicking around some window.
"Magic swipes" could also be redesigned to be more intuitive, e.g. with some background soft-3D effects that make swipe-sensitive areas "stand out" from the neutral background.
Personally I find GUI discoverability to be like the hunt-and-peck model of typing, vs touch typing being CLI, and I don’t think it’s a coincidence that touch typing and CLI go hand in hand: you never leave home row. You think about what you want to do and type the command, instead of looking through panels of icons or more exotically arranged buttons (which in the newest web apps, constantly jump around as the page lazily loads, new elements appear forcing layout changes, fonts load causing text reflow… I frequently tap the wrong menu item because what I really wanted got pushed down by a new appearing element as my finger approached the screen.)
On Linux, `--help` usually... helps. Or there's the man. On Windows, the MS docs are usually usable to find things.
Of course, it may not work 100% of the time, but I find it's a question of philosophy. I'm not a Windows user, so I generally approach it with a mentality of "it would be nice to be able to do this, let me check real quick if there's a way". I usually manage to not have to click around for two hours when I have to do something repetitive.
Take clicking around a Microsoft ISS configuration on Windows 2000 vs an Apache httpd config file and it’s online doc.
I briefly tried both, and didn’t look back
But no desktop operating systems are well suited to being used primarily by professionals, not even Linux. The desktop paradigm is fine, but it was designed with the idea of making computers more accessible, and it inhibits composing different pieces of software together, which is what a professional-first operating system should optimize for.
I'm not sure how viable a good professional OS is. It would arguably require graphical software vendors through the biggest design paradigm shift in their history, to serve a relatively small market. The transition to the desktop paradigm wasn't as demanding — you just switched from taking control of the graphics hardware and controlling the entire screen to doing basically the same thing, just with the OS as a proxy so that you're rendering to a smaller rectangle. Composable graphical interfaces means abandoning the idea of having complete control over your rectangles.
I love macOS and I’m a professional. I mean, I get paid for what I do. I’m a professional, right?
But surely you can imagine ways that macOS could be better suited to your needs. Why (to give an example that's easy to explain briefly, not necessarily the most important one) are the various things you have open organized primarily by which application can open them, instead of which task they're relevant to? You can organize your browser tabs by task by using multiple windows, but why can't those windows hold anything relevant to the task they represent except browser tabs? Why can't you have your terminal and text editor grouped with your webpages? It's because less sophisticated users expect each window to belong to exactly one "application," and because software vendors assume that their job is to make self contained "applications," and not composable graphical components.
I actually used a desktop that let you group content from different application in the same group of tabs for a couple years in college, by using i3/sway and a custom Firefox extension. It's an upgrade over just workspaces. I stopped working this way because I switched to tree-style-tabs and there's no window manager that gives you anything like that, and it was on net a workflow improvement.
Thought it will still be interesting to see where that will go in the next 20 years. Like you said with the convergence of desktop and mobile devices on the one hand I can't see traditional OS's surviving but on the other hand I don't se another option given that's the only medium to build the higher level software.
Why not? The only officially-supported way to build iOS apps right now is using Xcode on a Mac. What would be the difference between using the Xcode app on a Mac or the Xcode app on an iPad with a keyboard?
Xcode for macOS isn't designed for that, but no reason xcode for iPadOS couldn't be.
The Xerox Parc and Smalltalk are the ancestors of today’s WIMP UI. If you look at Squeak (or Pharo) you’ll see how is possible to make a desktop UI that’s more composable than the usual Unix shell. The problem is not the desktop paradigm, but a lack of commercial interest.
I think we can do better than squeak/pharo, but they're fine, really. They're at least the kind of thing I'm talking about.
Yes, Windows and Mac copied the WIMP UI. But, they ignored the composable message passing architecture. The goal of Smalltalk was to make a computing environment with a GUI, the programming language was like C to Unix.
During the 9x-2000 there was a lot of hype on providing the same system composition capabilities in Windows and Mac: ActiveX, Windows Scripting Host, AppleScript, etc. But, these things are dying. Those frameworks are not cross-platform, and they were not designed with security in mind. The interest shifted to the web.
My point is: It's possible to make a programable/extensible desktop UI. But, today the cost of doing it is high, and the interest is low.
> I think we can do better than squeak/pharo
I agree. I used Smalltalk -to work- for 3yrs. Smalltalk is full of good ideas, but it also has many bad ones.
I'll love to see something better too... In a sense JavaScript and the browser share some of the St GUI capabilities: you can inspect, experiment, and browse the code of any app. But, in other aspects the web platform is terrible.
I hope that the competence between Apple (pushing for apps in iOS/iPadOS) and Google (pushing for PWA), will renew the interest on creating environments where anybody can code and tinker with other apps. (if PWAs evolve to have the same capabilities as native apps, Apple will need work hard on removing the app creation barriers to compete -I don't see native Android apps as a competence to Apple iOS... but I might be wrong)
iOS and MacOS are both converging on Shortcuts to accomplish this.
But they cannot in principle accomodate software developers.
Funny, the possibility to do that currently exists in a walled garden, for audio apps: https://audiob.us . This is used by creators and live performers, exclusively. I don't think anyone uses applications in this ecosystem for "consumption" purposes.
The problem was never was the current OSs, it was just about app makers not willing or not knowing how to collaborate amongst themselves. It was also never about open vs closed, since AudioBus is proprietary and 99% of the apps that support it are also proprietary.
The thing about UNIX pipes is that they use plain text. AudioBus uses audio. Those are two things that naturally impose limitations. Developers seem ok with those "natural limitations" but whenever you want to impose limitations to something else you immediately get pushback.
You wouldn't be able to do that in a business CRUD app for example. The amount of wheel-reinvention is too big on those, compared to audio/video/unix-tools.
I haven't been able to play with the shortcuts functionality because I don't have an iPhone, but if it is what I think it is it, it is a powerful tool to do things with.
We shouldn't fail to acknowledge that most, if not all, spend more time consuming than creating.
Then you have the group that isn't served with something as powerful as a real computer. My grandparents would be much better served with an iPad instead of a computer, since all they need is a browser and a system to do video calls.
Now, Smalltalk provides the infrastructure for composability, but Smalltalk by itself doesn't provide us the full-fledged desktop environment and applications that users have come to expect; they would have to be implemented in Smalltalk. But where things get interesting in a Smalltalk-implemented desktop environment is that the live object environment is still there, leading to interesting possibilities. Imagine being able to control a word processing program through scripts written outside the word processor, without the word processing program itself having to implement something like Visual Basic for Applications? Imagine being able to control a spreadsheet with Smalltalk methods on cells instead of having to learn the spreadsheet's language or having to learn Visual Basic for Applications? The possibilities become even more intriguing when objects can interact with each other in ways that are far more general than Unix pipes. This is the desktop environment I dream of using, the unification of the ease of use of GUIs and the flexibility and programmability similar to the Unix shell.
Oddly enough, in the mid-1990's Apple implemented a less-ambitious (but still very ambitious for its time) version of this vision known as OpenDoc (https://en.wikipedia.org/wiki/OpenDoc). There are some wonderful videos at https://www.youtube.com/watch?v=oFJdjk2rq4E (a three minute summary) and at https://youtu.be/2FSFvEIpm5o (a 50-minute demo). OpenDoc was released in 1996, if I recall correctly, and there were some applications written with OpenDoc, most notably the CyberDog web browser (https://en.wikipedia.org/wiki/Cyberdog). However, once Apple bought NeXT in late 1996, Apple committed itself to building its next-generation operating system on NeXT, which had its own collection of object-oriented APIs. The cancellation of OpenDoc led to this famous spat during WWDC 1997 when a disgruntled developer questioned Steve Jobs on Apple's decision to cancel OpenDoc (https://www.youtube.com/watch?v=oeqPrUmVz-o).
Why was OpenDoc cancelled? One can argue that OpenDoc's cancellation was due to Apple needing to have a tight focus during its very vulnerable period in 1997. The proof is in the pudding: mid-1990's Apple before the return of Steve Jobs was an unfocused beacon that was able to produce many interesting technological demos (the Dylan programming language, SK8, OpenDoc), but there was no single coherent vision. The Taligent and Copland projects, which strove to replace the classic Mac OS with then-modern underpinnings, were disasters. OpenDoc was just one out of the many, sometimes competing, visions that Apple had during this time. Steve Jobs was able to turn around Apple's fortunes by having Apple focus on one vision for the Mac.
However, another way of looking at the cancellation of OpenDoc is that its success would have completely upended the software industry. Instead of software vendors selling apps, software vendors would sell components, which users can integrate to create custom workflows. While I believe that this would have led to a lot of flexibility and user-empowerment, OpenDoc would have also been seriously challenged by major software vendors like Microsoft and Adobe, whose empires were built on selling large, proprietary software packages. They were not going to give up their moats without a fight.
Still, I dream of the modern realization of component-based software, and it's something I've been thinking a lot about for the past few years.
Ironically, that was the main interest of Brad Cox who, with Tom Love, created Objective-C, which was acquired by NeXT, and became the way forward for Apple.
In my experience, it is very hard to build a business around software objects. I spent a couple years trying to build an App around the Apple Watch. But, Apple only allows 3rd party complications. It is essentially a component. Apple recommends focusing on doing only one thing.
Moreover, as a component, you the developer often have less control over the UX. On the Apple Watch, when a user opens -say- Spotify on the iPhone, your app is kicked out.
So, a couple weeks ago, I decided to put the Apple Watch development on hold and do something else on the iPad.
However, I believe that component-based software is a natural fit in the FOSS community. One of my favorite Hacker News comments of all time is https://news.ycombinator.com/item?id=13573373, where the author makes the case for why component-based software would have been a better fit for the Linux desktop than the standard approach of trying to build a FOSS replica of large, commercial platforms.
http://pchiusano.blogspot.com/2013/05/the-future-of-software...
And that culminated in
Essentially all code is pure functional and content addressable, meaning it’s inherently distributable and transferable (including closures). Like Smalltalk but with more use of modern programming language theory.
I have good news, iOS user's productivity woes are solved. Using iSH you can pipe text between command line tools all day every day. Finally the power of the iPad is unleashed!
I would like seamless interoperability between CLI and GUI apps, a unified file system, the ability to run virtual machines, containers[1] or maybe just nginx[2].
And then you have the usability issues of the iPad(OS) like external displays being mirrored only, or only recently being able to actually access files from a USB drive...
The iPad is a great media consumption device, that has some limited professional use (art, video editing maybe), but let's not fool ourselves that it's anywhere near being a replacement for a fully functional computer.
In the "mobile app ecosystem", each application is more or less an island. It would be possible to achieve something similar on iOS/Android devices, but the entire "value proposition" of walled garden ecosystems isn't compatibel with this idea of open and creative computing. One prerequisite is that I actually own my device and can do anything I want with it, without the platform owner getting in the way.
The main limitation is the interaction model, and that's just down the the mechanics of touch interfaces. Firstly fingers are imprecise big fat squishy blobs. Secondly the tablet form factor doesn't afford a large physical keyboard. These are the impediments and they're just facts of the form factor. the new multi-tasking interface in iPadOS looks like a great step forward, but it's always an issue.
Here’s one question: hover on focus vs click to focus?
Hover makes sense if you think of the pointer as a finger.
Who are you talking about? Senior citizens? Or maybe people outside of the US in developing countries? Because anyone under 50 in the US has grown up around tech.
Regarding the smartphone point, again, you might be talking about elderly people or self-isolated people. Otherwise all people under 50 have used computers in their school classes and would not be dumbfounded at a PC.
It's somewhat analogous to using Automator and/or macOS' Open Scripting Architecture.
Very true.
> It's hard to imagine how a UNIX-like flexibility can be achieved inside an ecosystem that's optimized for passive media consumption and online shopping though.
Unix-like flexibility is also extremely insecure and easy to screw up.
It’s fairly obvious that the App Store ecosystem can and is becoming increasingly flexible. Things like shortcuts and safari extensions are obvious examples.
Unix-like flexibility will likely never come to iOS, nor should it, but it’s easy to imagine a steady drumbeat of easy to use managed points of flexibility that ultimately provide 80% of what people use Unix-flexibility for but without the insecurity or brittleness.
It’s not so easy to imagine how ease of use, security and robustness can be retrofitted to unix any other way.
Remember iOS is Unix. It’s just a matter of what they build for end users.
The "walled garden app ecosystem" is exceptionally bad for this, and the UNIX shell is exceptionally good, but both are extremes. It's hard to imagine how a UNIX-like flexibility can be achieved inside an ecosystem that's optimized for passive media consumption and online shopping though.