
Sweat the small stuff - jessaustin
https://inconshreveable.com/09-09-2014/sweat-the-small-stuff/
======
pbnjay
Great post. I think just as UX has been growing as a field, CLI apps are
surprisingly lacking in this arena. I guess technical types just assumes other
technical types are willing to dig in and figure it out... but really, ALL CLI
apps should pay attention to the experience like this.

Personally, I think it's a key factor in assuring tools are adopted and
shared, and by extension a key avenue of ensuring the success of the developer
behind it. A lot of stuff just gets released and forgotten about or the devs
try to recover through marketing and adding new features. First impressions
are everything!

------
TheMakeA

        print out some additional help text that explains that you shouldn’t try double-clicking it from explorer again.
    

Why not? If a large number of your users want to double-click it, why tell
them that they are wrong? It sounds like you already support it now anyway.

~~~
inconshreveable
Your point is well taken.

The thing is that ngrok does not do anything useful beyond printing out the
help text when double-clicked, and without the text, I'd be worried that a
user might actually try to double-click it _again_ when it doesn't do what
they want instead of typing the command with useful arguments, if that makes
sense.

~~~
kulkarnic
How about asking people for the command line arguments once they double-click?

Telling users they are wrong seldom works in the long run, because this
requires a change in the mental model. The program model most people using
GUIs assume is "you open a program, then you tell it what to do". The CLI
model of "you first decide what the program must do, then you run it" just
requires more thinking. As Steve Krug points out, "don't make me think" :)

------
yoha
Before I switched to Linux, I encountered this kind of issue. The popping
console is annoying, even when you know how to use a terminal : navigating
through the filesystem is painful in cmd.exe an starting an instance from
explorer is not always an available option.

Netcat had an interesting approach: when you start it without any command line
argument (say, by double-clicking), it opens a prompt and wait for a command.
Using this idea together with some help message might be the simplest
solution.

------
dkador
Alan's one of the most thoughtful engineers I know. No surprise to see this
post from him. Nice job!

------
metacorrector
yuk. this is the sort of issue that should be solved at the level of the OS,
not for every app.

*nix is pretty much "the" cmdline people refer to, and the unix cmdline was well established and in use at microsoft when microsoft created DOS and broke it to shit. No reason to retrofit the breakage backward.

plenty of unix tools don't say anything when you run them with no args, and
they're not supposed to, "we" like it that way.

If you have a GUI that can't handle cmdline executables, how about distinguish
GUI executables from cmdliners. don't foul the cmdline space with cruft, cruft
that works in one context but not in many others. You are explicitly testing
to see if you are a descendent of a specific program?

~~~
metacorrector
i just want to add, you have actually introduced a bug. if your program has
any longevity, this misfeature of it will, i predict with confidence, break
the program at some point, sooner rather than later, and for no reason other
than "it's a hack".

------
cetra3
Would it make more sense to include some sensible default configuration (i.e,
have it run on port 80)?

------
kazinator
Microsoft KB article about the problem of console applications quickly
flashing a console window and disappearing when launched from Explorer:

[http://support.microsoft.com/kb/99115](http://support.microsoft.com/kb/99115)

TL; DR: an application can guess (via an ugly cursor position based hack)
whether it is running in a console window that was allocated just for it by
the console startup code (the unwanted case), or whether it is in an inherited
window (the intended use case for the code).

A reasonable solution, also, is simply to build two executables: a regular
application and a console version of the program. Make the regular application
(myprog.exe) attractive for clicking by giving it a icon, in comparison to
(myprog-cmdline.exe) which has no icon. myprog.exe just puts up a usage dialog
box and quits. Alternatively, they can both be console applications that are
almost identical, except that the one with the click-bait icon pauses for
console input before quitting.

------
markrages
Interesting article; unhelpful title. Please re-title.

~~~
scrollaway
Are you used to people obeying your every whim just because you ask nicely?

~~~
markrages
The admins here retitle submissions all the time.

~~~
Guvante
Typically the original title is favored. This matches the original title.

