Sweat the small stuff
inconshreveable.com
inconshreveable.com
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!
print out some additional help text that explains that you shouldn’t try double-clicking it from explorer again.
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.
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" :)
After reading a bit into what ngrok actually is, kulkarnic's suggestion of an interactive mode probably makes more sense. Easier than building a full GUI, but an experience close enough to a GUI that even users unfamiliar with a commandline should be able to use it without difficulty.
> In the process of writing up this blog post, I wondered if I could do even better. Is there a way I could eliminate that last support email? After searching around for a bit, I stumbled on cmd.exe’s /K option which instructs cmd.exe to run the program and remain open after it terminates. The soon-to-released ngrok 2.0 contains the final iteration of this feature. When you double click it from explorer, it will relaunch itself using cmd /K so that it executes as if you had opened the prompt yourself and run the command.
There are many good reasons to limit users and user interactions to the appropriate existing context. A "double-click" is a Windows metaphor and not a Web metaphor and should ignored if not actively discouraged. I have nothing against Windows but it's simply not appropriate to extend its behavior to the web.
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.
*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?
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.