For simpler launching of both the web and terminal UI components, and to support better domain grouping, we should support a unified command syntax for launching the UIs.

Example commands

Launch the web UI:

git bug ui web [options]

Launch the TUI:

git bug ui terminal

Store a preferred default UI (e.g. in git configuration)

$ git bug ui set-default terminal
$ git bug ui set-default web [options]

Launch the configured default UI:

git bug ui

Historical commands

The historical commands should emit a deprecation notice and be removed in the next major release after this feature is merged (semver syntax: MAJOR . MINOR . PATCH).

These are:

• git bug termui
• git bug webui

sudoforge added label kind/feature 1 year ago

sudoforge added label priority/backlog 1 year ago

sudoforge added label triage/accepted 1 year ago

sudoforge added label area/commands 1 year ago

sudoforge added label area/cli 1 year ago

sudoforge removed label area/commands 1 year ago

Disagree on this one.

Here is the UX guideline I've used and the reasoning behind:

• different UI class (CLI, interactive terminal, web) have different strength and weaknesses. Not only each user has general preferences, but the same users is going to use a different UI for a different task. --> git-but should have all 3 classes built-in, as first-class feature
• first class feature also means trivial to invoke --> require a short invocation (a few key stroke) --> should be at the root of the CLI

Here is the intended usage of each class:

• CLI: integration with other programs (shell pipe, into editors ...), human usage for punctual operations. Roughly: low level plumbing.
• termui: good UX for humans in the terminal (lightweight, efficient), remote operation (ssh), or simply browsing in the same place as other git operations
• webUI: full capability (notably: images and media), at the cost of being heavier and changing the medium (terminal-->browser). Also: public usage.

My key points in this:

• user use multiple UIs, so a default mechanism doesn't work
• there is ever going to be only those 3 classes of UI, so there is little benefit in abstracting behind another CLI hierarchy.

Besides, that's one area where there has been zero UX confusion/problem that I know of.

• git bug ui -> launch my preferred default, your preferred default
  • explicitly, a quicker way to launch the ui than what currently exists
• git bug ui - -> launch the non-default UI
  • i don't see us having more than these 2 but if we did, the meaning of - could change to "the previous one", like in git/cd
  • this might feel very familiar to CLI users
• git bug ui terminal and git bug ui web -> launch the specified UI
  • we could perhaps allow for aliases, such as t and term for terminal, or w for `web
  • this is not something i see users needing to type out with any regularity; especially if these two UIs are the only two that exist (because git bug ui - is probably going to be preferred for anyone regularly typing this out)

personally, i don't envision that most users actively switch between the two UIs with any regularity, and if they do, it's because of a lack of features in one or the other UIs. as a heavy CLI and TUI user, i very rarely go to the graphical UIs for the applications i use. this comment, for example, is being written in my terminal, so that i don't need to go to github in my browser. maybe i'm unique, but i don't think so.

and more to the point: if users do switch between the TUI and GUI regularly, the current approach is clunky, because they'd need to open two shell sessions and run git bug termui and git bug webui (or, sure, run the gui first in a background job, then run the tui... but i you get my point). if we wanted to make running both simultaneously easier, having a command structure like git bug ui would allow for something like --tui and --web flags, which could be passed together, and git-bug could handle running both for the user in a single invocation: git bug ui --tui --web.

the only use case in which i see this proposed command structure add complexity to CLI operations is one in which a user is actively opening the TUI, doing whatever they do, and running into a limitation and closing it so that they can open the web UI. as mentioned earlier, this feels like a thing a user might do because the UI they prefer lacks features they need, and i'd call that a bug -- other than drawing images, i don't see any functionality of a project management tool that can't be implemented in both UIs gracefully.

i'm focused on the TUI and web UI when i say "UI", but as you mention, yes, there are actually three: the CLI. i feel like this command structure is far more aligned with the command groupiing found in most command line applications.

sudoforge added label priority/important-soon 8 months ago

sudoforge removed label priority/backlog 8 months ago

sudoforge added label lifecycle/active 8 months ago

sudoforge removed label priority/important-soon 8 months ago

sudoforge added label priority/important-longterm 8 months ago

pulling this out of 0.8.1 because it needs an RFC, but i do think refactoring and simplifying the CLI is important for a 1.0.

sudoforge removed label lifecycle/active 8 months ago