I'm working on a tool designed specifically for developers.

Most of us (developers), spend their time in a Terminal and very rarely on GUIs. The advantage of a CLI is that things are scriptable.

For example, Docker introduced a GUI for their Desktop product.

Docker Desktop for Mac

I've personnally never used it even though I'm using the tool daily.

The main cons of developing a GUI would be, for me :

  • High cost of development
  • High cost of maintenance
  • Requirement to handle multiple platforms (macOS, Windows, Linux)

What would be the arguments for a GUI ?

  • 1
    Easy to learn, easy to navigate. Developers certainly have the ability to read reference manuals or long -help printouts, but that doesn't mean they're the most efficient way to get familiar with a program. Once you are familiar with it, you can often be faster with a CLI. In fact, I don't know of many skilled users who would actually click around your average GUI; they use keyboard shortcuts and macros and hence it's like a CLI anyway :) But also, some functions are much faster visually, e.g. drag-and-drop sorting of items rather than typing in indices, or live previews of rendered visuals. Feb 26, 2023 at 5:25

2 Answers 2


Plenty of developer tools exist without GUIs, so I would say a GUI isn't needed. It can, however, be beneficial:

  • GUIs can help onboard new users to the tool
  • GUIs are more intuitive to use than the CLI (when designed well)
  • GUIs allow people to use the tool without needing to read documentation
  • GUIs make it so that non-developers, or people who aren't comfortable with a CLI, can use the tool. Maybe you don't see a use case for that, but you might be surprised. For example I'm a designer and I rely on the Docker GUI daily. I also use GitHub's desktop app so I don't have to use a CLI.

Most of us (developers), spend their time in a Terminal and very rarely on GUIs

This is a faulty assumption. The stackoverflow survey shows that VSCode is used way more than command line editors like Vim, Emacs or Nano. Game engines like Unreal Engine or Unity use GUIs. So depending on what kinds of tasks your target audience are doing, it may be that they aren't all CLI all the time, or even most of the time.

What would be the arguments for a GUI ?

The main benefit of a GUI is that they tend to have affordances while CLIs tend to not have any. That is to say, GUIs have buttons, icons, menus and so on which guide you through a task interactively, while CLI tools tend to expect you to type in command options options options and give you the result at once. Without reading the help pages or looking up tutorials, it's generally impossible to intuit how the tool works.

For example, let's say we want to convert a video from MP4 to WebM and it's our first time using the relevant tools.

As CLI users, ffmpeg is our tool of choice here, so let's summon it:

$ ffmpeg
(tons of configuration info, versions, copyright)
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'

From this description we have a vague idea of the order it expects parameters, but we don't yet know for example how to tell it which codec to use. A further trip into ffmpeg -h reveals the relevant parameters (-c) and another into ffmpeg -codecs shows us the list of every codec under the sun. Armed with this info, let's try:

$ ffmpeg -c mepg4 -i infile.mp4 -c webm outfile.webm
Invalid decoder type 'mpeg4'

Huh! Where did we go wrong? Does MP4 not mean mpeg4?

This user story might continue with trying different options, specifying more or less parameters, figuring out that mp4 containers may (and usually: do) contain another codec (h264) and perhaps even looking up tutorials online, to finally figure out that all that was needed was ffmpeg -i infile.mp4 outfile.webm, but I'll cut it short here. Point is, learning a CLI tool can be quite painful and difficult, especially when the help pages are just a list of "this is literally everything this tool does".

Compare this to our GUI tool of choice, handbrake:

Handbrake detail

Even though as far as GUIs go, it is quite cluttered, the two functions we care about are right there: A format dropdown in which we can specify our codec, and a "start encode" button. We can do our task quite easily, and without consulting a manual or tutorial.

This is the power of affordance. And yes, we do give up some functionality here, and some information is staged in tabs (eg which exact codec is being used at which settings), but it simply is way easier to learn.

The main cons of developing a GUI would be, for me: High cost of development, High cost of maintenance, Requirement to handle multiple platforms (macOS, Windows, Linux)

As we are on the user experience stack exchange, my answer to this is "so what?". Yes, building a nice user experience is difficult, that's why there's so much jank around. Especially if your tool is any useful to a wider audience, it'd be a shame to design it in a way that only the most elite of CLI wizards can work with.

Documentation can help with that, but is also expensive to create and maintain. The original creators of the app I'm working on at the moment made themselves a jail of documentation, where they would avoid making major changes because doing so would require updating dozens or hundreds of pages worth of documentation.

That said, I acknowledge this is a business decision to be made. If the audience for your tool indeed are just people who use the CLI for everything, then making a GUI for them probably isn't worth it. If there is however a large overlap with programming-adjacent folk who may need them too (designers, power users, QA testers, etc), a GUI may give you an edge.

FWIW, there exist multi-platform GUI things, most (in)famously Java and Electron and I've heard good things about QML/Qtquick and Flutter, too. It may be worth giving a simple GUI a shot anyway, just to assess how much effort would be involved in creating/maintaining a larger version would be.

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.