Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: [...] > I really don't know, but I do think that the most viable path to a > better UX for git is to consider its UX more holistically. > > To the extent that our UX is a mess I think it's mainly because we've > ended up with an accumulation of behavior that made sense in isolation > at the time, but which when combined presents bad or inconsistent UX to > the user. Yep. Moreover, this practice of "making sense" being the primary reasoning factor doesn't work very well even in isolation, for single Git sub-commands. As there is no defined underlying UI model, or rules, or even clear guidelines of how to properly design command-line options, multiple authors, all having their own sense and having no common ground to base their decisions on, inevitably produce some spaghetti UI. The UI model to be defined, provided we are serious about aiming at a good design, in fact has at least 2 aspects to address: 1. Uniform top-level syntax of all the Git commands. 2. Uniform rules to handle command-line options. Being hard to produce simple yet flexible design by itself, the problem is further complicated by the need to absorb as much of the existing UI as reasonably possible. Once a model is defined though, we should be able to at least ensure new designs fit the model, and then, over time, gradually replace legacy UIs that currently don't fit. As a side-note, from this standpoint, discussing deep details of "git switch" options, or even relevancy of introducing of "git switch" in the first place, has still no proper ground. Not even touching (1) for now, let me put some feelers out to see if we can even figure how the rules or guidelines for command-line options design may look like. 1. All options are divided into 2 classes: basic options and convenience options. 2. Minimalism. Every basic option should tweak exactly one aspect of program behavior. 3. Orthogonality. Every basic option should not "imply" any other option, nor change the behavior of any other option. 4. Reversibility. Every basic option should have a way to set it to any supported value at any moment, including setting it back to its default value. 5. Grouping for convenience. A convenience option (usually with a short syntax), should be semantically equivalent to an exact sequence of basic options, as if it were substituted at the place of the convenience option, and should not otherwise tweak program behavior. I.e., a convenience option should be simple textual synonym for particular sequence of basic options. Please notice that in the above model basic option having a short form is formally considered to be a short convenience option that is a synonym for long basic option. There are obviously some other useful guidelines that could be defined, or some alternate approach could be chosen,but the primary point is that if we want a consistent UI, we do need some rules, and we need convenient implementation of the model agreed upon, and then ensure that from all the designs that "make sense", only those that fit into underlying model are accepted. Thanks, -- Sergey Organov
