I'm developing a distributed project management tool with a command line interface. I have two commands relating to initially copying a project to/from a hub. The export command looks like this:

prog export PROJECT HUB

This reads well when compared with the English "export this PROJECT to the HUB".

The import command could have the same order of arguments if I also want it to match with the English "Import the PROJECT from the HUB":

prog import PROJECT HUB

There is possibly some value in having a consistent order with the two commands. An alternative however is to enable the importation of several projects (or even all) at once, by reversing the order of the arguments:

prog import HUB [PROJECT-1 .. PROJECT-N]

English can also be massaged to work this way "Import from HUB all projects, or the following projects: PROJECT1-N". This also has the advantage that it is a similar order to the "git clone" command which has familiarity for software developers, although git is the last tool I will be modelling my interface on :)

Which order of the import command arguments would you prefer, and why?

  • Meta question: Is this the best place to ask such a question? Commented Jun 19, 2013 at 0:51
  • Reads like you're asking us to do a review of your application. UX.SE does not do that. Please refine your question to manageable proportions. It is also necessary that you should avoid polling for subjective opinions. Commented Jun 19, 2013 at 6:26
  • 2
    Why enforce any order at all? Use named parameters as in prog -action:import -project:xxx -from:hub. If you find that too verbose, you could (also) allow for short versions: prog -a:i -p:xxx -f:hub (Of course there are no breaks or spaces after the hyphens, that is just the formatting by the browser). Commented Jun 19, 2013 at 6:53
  • 2
    Deer Hunter, How much more refined than "Which order would you prefer, and why?" can I get? That is a binary question with an answer "version 1" or "version 2". If the rest of the contextual information is too much then I'll happily remove it, but it feels relevant to me. Usually one is accused of not providing enough information. Commented Jun 19, 2013 at 10:32
  • 1
    Marjan, there are good reasons for positional arguments, verbosity being one which you have already mentioned, and where they are always (or nearly always) required is another. Would you like to be typing "ls --directory:." all the time? I find usability is helped when one can differentiate between information which is necessary to be given, and that which is optional (hence the term "options") Commented Jun 19, 2013 at 10:49

4 Answers 4


Unless you're going to actually write the entire sentence, you can't rely on the language to clarify the directionality of your command. Like you already found out, a sentence could be constructed to support either direction.

In stead, the directionality we're used to in the left-to-right part of the world is much stronger. If the command will move data from A to B, it should read move A B, i.e. from left to right.

Svn uses this syntax, which took me some time to get used to, but also makes sense while working the other way around:
$ svnadmin load /var/svn/restored < repos-backup


In sense of cognitive processes it is good to use first the objects of manipulation, because they are primary ones, and at the second — the context of activity. It seems, that projects are primary objects in your commands, and hub in some extent is just a property of the project (the hub itself is not the primary artefact of your application's goals).

So it is better to use first sentence (prog import PROJECT HUB). Additional consistency with export option adds more value to such solution, because command line languages are rarely associated directly with natural ones (and for non-english speakers there will be no such connotations) — and it is better to maintain one simple logic without informal, similar to natural languages (but NOT them) characteristics. Also, you should maintain this logic in other commands.

You may use commas or double periods to point to numerous projects for expert users:

prog import PROJECT1..PROJECT4 HUB

So, your first solution is the most saving cognitive efforts to memorise all statements, and I'd recommend to use it, especially if you maintain such order in other commands.


I agree with Alex Ovtcharenko's answer, with one amendment: why not make these terse command line options the synonyms for old-school switches:

prog import Proj1 MyHub

would be equivalent to:

prog import --Project:Proj1 --Hub:MyHub

or shortened:

prog import -p:Proj1 -h:MyHub

That way, it can be as unambiguous as the user desires.


CLI design tends toward use of flags rather than argument order, for this reason. Extant tools that use ordering tend to confuse users (tar being one example), though if you can only have one 'output' and multiple 'inputs':

tar cf output.tar input1 input2 input3

that helps disambiguate a little.

The principle I prefer is to identify the 'primary' target of the command, make that a bare argument, and have a flag for all the others. E.g., for tar this redesign would be:

tar -f output.tar input1 input2 input3
tar input1 input2 input3 -f output.tar     <-- synonym

which looks identical, but isn't. (tar is weird.)

For your example, it sounds like the project is your primary noun this would end up:

prog import project -h HUB
prog import project1 project2 project3 -h HUB
prog import -h HUB project1 project2 project 3   <-- synonym for above

I tend to shy away from requiring flags for both direct and indirect objects (prog import -p project -h hub); it's even wordier.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.