In the desktop world, we have the option to use the command line: a uniform interface for a multitude of apps that would otherwise be very different when implemented as GUIs.
Using the same interface, I can move or edit files, cross out tasks on my to-do list, retrieve my password for my email account (using Bitwarden or pass), etc. All in the command line. The GUI for each of those are wildly different.
The other benefit is it is very easy to create a new command line app, as opposed to a GUI.
Is anything like this possible for the smartphone world (even if it doesn’t or will never exist)? What would it look like?
Since smartphone typing is much slower, we can’t simply reuse the command line. We’d need something different. An interface that can still support a various spectrum of different operations, yet ergonomic for a smartphone. What are your thoughts?
I really don’t think that the command line is a uniform interface. Every command has its own syntax, its own take on what its switches mean, its own take on regexes/globs and so on. Moving and editing files is something completely different: one is a simple command to move a file elsewhere, the other is a whole experience which replaces the command line with something that looks completely different and is controlled completely differently. What they do have in common is just the medium - the terminal.
Many developers of command line tools try to at least keep a similar design language as the rest of the world, but it is far from perfect. A lot of these interfaces are like they are for mostly historical reasons without proper planning of the user interface, so imho even something like Material Design is already closer to being the “same interface” in the GUI world than the various command line interfaces are.
We absolutely can and some of us do. I often manage my files, todo list, etc. in Termux. Its not always the best thing to do, but I like that I can keep a consistent interface no matter what device I am using. Its still the same terminal, just on a smaller screen with a worse keyboard.
Powershell was kind of an answer to that. All commands are supposed to emit objects and take objects as input. For me though it is horribly unintuitive. Id love to see an open source attempt at it, but it would be hard since by necessity every dev works on their own tool, while Microsoft could enforce something because they own all the tools.
Well, the fact they emit objects doesn’t really help that much with the user interface. This just means that the standard input and output of commands is (usually) more unified and parse-able. I really like the idea, and have seen multiple attempts at it including PowerShell, however none have reached the level of usability that the good old *NIX shells provide.
Here you go!
It seems the difference stems from *Nix treating everything like a file (or stream) from day 1, while windows was built from DEC Alpha, which had a completely different approach.
(In the early 90’s a group of DEC Alpha engineers were laid off, and Microsoft hired them. Technet magazine had an article (written by Mark Minasi I think), showing how clearly NT reflects the structure of Alpha. They may have been working on NT before that, but the influence of DEC was pretty clear).
I’ve spent a significant amount of work time for a few years working with Powershell. There’s a hell of a lot it does right, and it’s set up such that the grand majority of commands and modules follow the same syntax in terms of pattern and terms. It’s not hard to just pick up and go with new stuff within it. That is it’s biggest strength, and it makes Windows SysAdmin work a hell of a lot smoother.
That said, there’s a shit ton of little idiosyncracies that would catch me every time if I wasn’t using VSCode/ium with Intellisense suggestions.
Specifying the properties to return from Get-ADUser? Use -Properties. Specifying the properties to return through Select-Object? Use -Property.
Working with Exchange Online? Import the module. Confused that the commands you need don’t exist after you imported it? You have to use the Connect-ExchangeOnline command to authenticate, connect, and generate and load a new temporary module first with just the commands for shit the account you used to authenticate has access to. This is the only module I’ve found that does this.
Need to send an email using your script? I sure hope you like using third party modules or loading dlls to do .Net/C# shit through PowerShell, because if you use the built in Send-MailMessage function we’ll give you a warning that it’s insecure, with a link to more info that’s just a wiki page on github for .Net, not PowerShell, without any actual info that notes this has been an issue for six fucking years! The warning even states that there is no built in alternative in PowerShell despite it being insecure.
Don’t even get me started with the absolute clusterfuck of the multitude of modules for working with Azure, half of them deprecated without equivalent functionality existing in the replacement. The latest and greatest one doesn’t even has documentation pages with shit like “NOTE: FILL THIS INFO IN LATER” in them.
Like ffs, am I using a professional product developed by one of the largest corps in the world, or someone’s open source project? It often feels like you get the worst of both worlds.
Don’t get me wrong, I love PowerShell, it’s an amazing tool for Windows environment sysadmin work. I just often find people’s attitudes about it to be either “it’s a neat toy” or “it’s the most amazing tool on Windows ever” when the reality is between.
I don’t consider this a different interface. Where you draw the line is a personal choice, but I’d be happy with a smartphone equivalent where the differences are similar to command line tools having different syntax.
I should have clarified, but by editing files, I don’t mean the vim-like full text editor experience. I mean things like appending text to a file with echo
>>, or using sed, etc.Yes, legacy baggage exists. This only furthers my point, that things could be even better using the same principles, without legacy baggage.
I only use Termux out of necessity (app or functionality I can only access via a terminal). If an app with good ergonomics exists, I wouldn’t look at Termux. But I would still look at command line on desktop.
My point was that I think we have that already. The medium is a touch screen, and apps have over time adapted to that the same way they have to the terminal. Here we scroll by swiping up and down, move between tabs by swiping to the side, etc. All held together by system-wide gesture navigation. And yea, every app does stuff differently, and so does every terminal one.
I feel like this is exactly what Google was attempting to do with Material Design: a good, consistent interface / design language. It really was a fairly fresh start using what we learned from the smartphone apps that came before, with the design done intentionally. What do you think they missed?
Another thing to keep in mind is that the terminal is built around text and files, while the GUI is not. You cant expect every problem to be cleanly / ergonomically solve-able inside an Android app, just like you cant expect a good Snapchat / Instagram client in your terminal. There are file manager apps, there are text editors, there are todo lists, but the terminal is just a better platform for some tasks while worse for others.
That’s more like a GUI than a CLI. You have input boxes, buttons, sliders, gestures, scrolling, drag and drop, etc, and their different combinations. Many apps do almost the same thing, except giving you a different interface and a different combination of these steps. You listed some of those variations yourself.
How is that the same as the uniformity of the text only interface? That’s far more different than differences in syntax, but still text. Two hyphens instead of one hyphen for a CLI flag is a really small difference.
Even as a heavy user of CLIs, claiming that their text-only nature somehow makes them more uniform, feels a bit overly reductive to me:
To start with, there’s simple fire-and-return commands, interactive commands, full-blown TUIs and so on. Then there’s the parameters, which aren’t really consistent either across applications either. Neither in the naming of arguments, nor their grammar. The representation of the output is also all over the place.
With all those things, it’s really not so dissimilar from the different layouts of GUIs. Not to mention that there’s also lots of CLI tools that do the same thing but have a different interface, so yeah.
I’m excluding TUI’s because you’re right, they’re pretty different and share some of the ununiformity of GUIs. Still, the command line world remains vast and with that interface you can do a lot, and it is fairly uniform.
That doesn’t change the uniformity of the interface. Of course every application will need different parameters. Now do they receive these different parameters via a similar and uniform interface? I say yes. I enter it via keyboard, and for the most part they all use space delimited flags, most of them hyphenated. I’d call that pretty uniform.
To phrase it another way, if all GUIs started using the same names for all parameters, it remains non-uniform interface, and it wouldn’t solve 1% of the issue with GUIs.
Out of curiosity, if you don’t see the CLI world as more uniform, why do you use it and for what benefit do you prefer it?
I use the CLI because it’s keyboard-focused (though I use lots of mouse-enabled TUIs) and because it’s programmable.
Generally though, I kind of get what you’re trying to say, but ‘uniformity’ feels like an unfortunate choice in the context of your question, as the meaning can be very arbitrarily defined, hence the confusion. I could, for example, claim that GUIs are more uniform because all chat apps, browsers etc… are so similar to each other that once I’ve learned one I can use all.
Which is why It’d probably be better if you tried to reword your initial question avoiding that term, focussing more on describing the desired benefits of your definition of uniformity.
Otherwise I’d point towards voice recognition, as that’s very similar to a CLI, but probably not what you had in mind, I’m guessing?