I actually thought it was appropriate. The resolution of the issue is of less interest to me; I thought the point of having the developer as tech support as an excellent way to identify the most salient pain points in the app.
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.
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" :)
ngrok also opens a command prompt window when double-clicked, which I'd classify as useful even to people who know that ngrok should be used via the commandline (it's far more convenient than opening Command Prompt and cd'ing to the correct directory; and most people don't know about the shift-right-click "Open Command Prompt Here" trick). And that's in addition to displaying help text.
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.
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!
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.
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.
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?
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".
21 comments
[ 4.7 ms ] story [ 55.1 ms ] threadThe 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.
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!
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.
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?