which do you think is better user experience?

[ggodw000]

i am working on several automated tools with uniform command line parameters. I have to decide format and design corresponding API for handling those parameters.

I am contemplating two choices regarding the parameter that is followed by its value:

1.

Code: Select all

<cmd> -<param1> -<param2> -<param3> <param3 value>
example:
boot.py -F6 --noreset --F2 500

2.

Code: Select all

<cmd> -<param1> -<param2> -<param3=param3 value>
example:
boot.py -F6 --noreset --F2=500

First one appears more user-friendly, DOS-like or linux-like to me.

Code: Select all

mount -t cifs  -o username=asdd

... etc.,
But require more elaborate processing.

Second one appears bit less user-friendly, different than convention. But it is easier to process since parameter and its value is lumped together as one word in sys.argv
To make up for "less user-friendliness" I am thinking to publish rock-solid help for each command and its supported parameters.

If I go either way, there is no turning back or turning back will be a major effort, so I wanna ask for opinions.

[alexfru]

It's easier to press the space bar than the +/= key (large key, can use any hand).

The rest is not as clear-cut.

[Brendan]

Hi,

There's a huge difference between new users (with no prior familiarity) and old users (where the best choice may be to make it identical to whatever they were familiar with regardless of how bad that is for new users).

For "new user's experience":

• Using the actual file name is a mistake. It looks messy/confusing and is unnecessarily fragile (e.g. if you replace "boot.py" with "boot.exe" everything breaks). Better is to separate command names from file names (e.g. have a list of aliases or a set of symbolic links or something).
• Commands should be named appropriately. For example, "boot" should only be used to boot the OS, but that doesn't make sense because you can't use the "boot" command unless the OS has already booted (maybe "reboot" would be better?).
• Parameters should be named appropriately (e.g. I have no idea what "F6" or "F2" are supposed to be, and maybe "F2" is supposed to be a time delay until reboot happens and should be called "delay").
• The use of "-" is confusing (looks like negation)
• The use of "--" is pointless repetition (and is ugly and confusing too)
• The "=" gives an important clue on the relationship between pieces that assists readability/understanding and reduces mistakes. This is more important than how quickly mistakes can be typed.
• If you use strict "name=value" you no longer have a reason to have any special character prefixed onto parameter names, and it becomes much much easier to read because there's no "value without a name" to confuse unsuspecting victims (e.g. "foo bar baz" vs. "foo input=bar output=baz").
• Sometimes programmers are lazy and do what is convenient for themselves rather than doing what is convenient for end users. An example of this is not having code to correctly auto-detect the type of file system being mounted and instead having a "-t" option that should never be needed.

Cheers,

Brendan

[onlyonemac]

I've seen equals signs used like that. There's nothing wrong with it if it makes things clearer or easier to remember (and easier to parse).

[OSwhatever]

I'm like better having "--option=value" command line as it is more clear what value belongs to which switch. It is also easier to parse if don't allow spaces between the option and the value.

In Linux world, having a single '-' is often used for one letter options and '--' is used for word options, like "-f=filename" or "--inputfile=filename". Often both single and word options are provided so that people don't need to write words over and over again, like a shorthand. That's how it is in those systems and you will not have a swat team in your home if you do it another way, even if Linux nerds often suggest that.

[SpyderTL]

One of the reasons I'm writing my own OS, and not just using Linux is because of the lack of a standardized command line interface. This means that the user must learn each command and each utility, individually, which greatly increases the learning curve for any user not already familiar with that specific command on that specific system. Even common Linux console commands vary between distributions...

My approach, which is probably not what you are going to want, is to share the same commands and calling conventions between the API, the batch scripting language, and the console command line, and to require metadata that will allow the UI (shell or GUI) to provide the user with enough information and documentation to be able to find the correct command, and the correct parameters on the very first usage. I'm following the Java/.NET approach of grouping everything into namespaces and classes, so that related commands can be easily discovered (without necessarily having to reference any external documentation). Each class, method and method parameter can be independently documented and displayed to the user as they are typing/clicking to assist them in real time.

If you can somehow integrate this same type of functionality into your system, you would actually have a feature that I consider to be missing on virtually all other OSes, including Windows and Linux. OSX probably comes the closest to this, as it has some concept of being able to execute a command from a list of commands inside of an application from a script -- Automator -- but it does not extend this functionality to the command line.

[Sik]

The use of "-" is confusing (looks like negation)

The worst of the bunch are those using - to enable and + to disable. Yeah, those exist.

Sometimes programmers are lazy and do what is convenient for themselves rather than doing what is convenient for end users. An example of this is not having code to correctly auto-detect the type of file system being mounted and instead having a "-t" option that should never be needed.

Ugh I'll never understand this one. Even worse when you have to guess the exact spelling of the filesystem it wants, especially when it gives them names nobody uses outside of that program (how am I supposed to know which of the names for FAT actually belongs to FAT12/16/32?). Bonus points when it wants you to specify the hardware type too.

I can understand that in some cases autodetection just may not work reliably - go happily throw an error in that case then. But most of the time it should work and the arguments should not be required. Even a loose heuristic (e.g. if it has this name then try assuming it's this kind of drive) tends to work for most common uses.

[Nable]

I can understand that in some cases autodetection just may not work reliably - go happily throw an error in that case then. But most of the time it should work and the arguments should not be required. Even a loose heuristic (e.g. if it has this name then try assuming it's this kind of drive) tends to work for most common uses.

Modern Linux works exactly like this (you don't have to specify FS type except for network file-systems, kernel tries to detect the type automatically and throws an error if it failed). But it leads to loading a lot of modules for the file-systems that I never use and I don't like this behavior.

[Brendan]

Hi,

I can understand that in some cases autodetection just may not work reliably - go happily throw an error in that case then. But most of the time it should work and the arguments should not be required. Even a loose heuristic (e.g. if it has this name then try assuming it's this kind of drive) tends to work for most common uses.

Modern Linux works exactly like this (you don't have to specify FS type except for network file-systems, kernel tries to detect the type automatically and throws an error if it failed). But it leads to loading a lot of modules for the file-systems that I never use and I don't like this behavior.

Linux is a "joke OS" that never does anything well; and for OS design discussions what Linux does/doesn't do only matters if you're looking for examples of mistakes to avoid.

If Linux does load a lot of modules for the file-systems that you never use; then it's an example of "programmers that are too lazy and do what is convenient for themselves rather than doing what is convenient for end users" that I was talking about earlier. They don't have code to correctly auto-detect the type of file system being mounted (and only have "try all the file system modules and see if something works" instead).

Note that for GPT, to auto-detect the correct type of file system you only need to look at the 16-byte "partition type GUID" in the partition table entry. For MBR partitions there's an 8-bit "partition type" that is only a hint (and isn't conclusive) but most file systems have some kind of marker in the first sector (and if you design a file system you can make sure there's a nice marker in the first sector), and it isn't hard to figure out the file system type before loading/starting any file system module (and not hard to only load/start a file system module after you're already "very sure" that it's the right one) just by looking at the first sector. For networked file systems I doubt it's any different (a tiny amount of work to determine if it's NFS or SMB/CIFS or something else before starting any module).


Cheers,

Brendan

[Sik]

I honestly doubt Linux is actually loading the modules just to do the autodetection anyway...

I guess I can see the logic behind not trying that much on networked filesystems since they could be slow to access... but 1) you could just query the first sector once for little effort and do autodetection there and 2) wait shouldn't a networked filesystem like that be handled by the host anyway, meaning autodetection isn't even relevant? (at worst just figuring out which protocol the host is using)

...oh, you need a new connection to probe each possible networked protocol, don't you? <_<; (unless the host provides some mean to just tell you what it supports, that is)

[Schol-R-LEA]

Linux is a "joke OS" that never does anything well; and for OS design discussions what Linux does/doesn't do only matters if you're looking for examples of mistakes to avoid.

Just out of curiosity: in your opinion, are their any existing operating systems with significant user bases which don't fit that description?

Mind you, I am not disagreeing, I just don't see how it differentiates Linux (or any other *nix) from Windows, MacOS, iOS, Android (OK, technically that's Linux, too), or pretty much anything else I am familiar with (yes, even Genera and PilotOS, though I admittedly never got to use a LispM personally and my only experience with a Xerox Star was watching someone do some word processing on one once while I was working as a security guard at the Xerox HQ, back around 1988).

Also, I was wondering what OS you are using as your development host. You don't need to answer if you choose not to, I was just wondering.

[Brendan]

Hi,

Linux is a "joke OS" that never does anything well; and for OS design discussions what Linux does/doesn't do only matters if you're looking for examples of mistakes to avoid.

Just out of curiosity: in your opinion, are their any existing operating systems with significant user bases which don't fit that description?

While that description could be applied to other OSs (with wildly varying degrees of applicability); Linux is unique and earns that description more than any other OS for multiple reasons; where the largest reason is their inability to effectively coordinate disparate groups of developers (the "herding headless chickens" problem).

Note that I am mostly reacting to assumptions (that are false assumptions more often than not) that take the form "Linux does it like this, therefore ..." (e.g. "therefore any other way won't work", or "therefore that must be the best way", or "therefore I'm not going to bother to think for myself", etc).

Also, I was wondering what OS you are using as your development host. You don't need to answer if you choose not to, I was just wondering.

For better or worse, I'm currently using Gentoo Linux; mostly because I know that changing the OS (or even updating the existing OS) will be a massive chore that will probably take down my entire LAN for up to a week. When AMD releases "Zen" server CPUs I'll build a new server to replace this one and do a "10 minute swap" when I'm confident the new server is configured/working correctly; but I honestly have no idea which OS I'll use on that new server.


Cheers,

Brendan

[Kazinsal]

I think the best user experience when it comes to command-line arguments is having proactive autocompletion and not having any dashes, in an effort to make your command line flow better. Compare this:

Code: Select all

ping -W5 -Ienp1s0 -s512 -c12 172.168.24.1

to this:

Code: Select all

ping 172.168.24.1 timeout 5 interface ethernet1/0 size 512 repeat 12

Which one is immediately parsable? Which one do you need to pull out the manual to figure out the switches for?

The problem with the command line isn't its existence. The problem is the trend of making it intentionally as terse as possible with magic switches that are about as self-descriptive as a strained can of spaghetti-os and that are hopelessly inconsistent even between programs from the same authors and historical origin (-n, -c, and -s on unixlikes are particularly bad about this because between programs you can never guarantee what each one does).

[MichaelFarthing]

Exactly my view!

[Schol-R-LEA]

The novice Unix user is always surprised by Unix’s choice of command names. No amount of training on DOS or the Mac prepares one for the majestic beauty of cryptic two-letter command names such as cp, rm, and ls.

Those of us who used early 70s I/O devices suspect the degeneracy stems from the speed, reliability, and, most importantly, the keyboard of the ASR-33 Teletype, the common input/output device in those days. Unlike today’s keyboards, where the distance keys travel is based on feedback principles, and the only force necessary is that needed to close a micro-switch, keys on the Teletype (at least in memory) needed to travel over half an inch, and take the force necessary to run a small electric generator such as those found on bicycles. You could break your knuckles touch typing on those beasts.

If Dennis and Ken had a Selectric instead of a Teletype, we’d probably be typing “copy” and “remove” instead of “cp” and “rm.”

Proof again that technology limits our choices as often as it expands them. After more than two decades, what is the excuse for continuing this tradition? The implacable force of history,AKA existing code and books. If a vendor replaced rm by, say, remove, then every book describing Unix would no longer apply to its system, and every shell script that calls rm would also no longer apply. Such a vendor might as well stop implementing the POSIX standard while it was at it.

A century ago, fast typists were jamming their keyboards, so engineers designed the QWERTY keyboard to slow them down. Computer keyboards don’t jam, but we’re still living with QWERTY today. A century from now, the world will still be living with rm.

For more Unix-hating fun, consult your pineal gland, or these two links: UHH in PDF format, and ESR's bleated riposte, UUH Revisited from 2008.