Hi Natalie, > I never said "automated GUIs". CLI options can be presented in a GUI > with documentation available when you click the "?" button for > example. There is no need to dumb anything down, just to be a bit more > graphical in the way an app interact with the user (who may choose to > use the CLI but it should be a choice, not an obligation). In some > instances, a GUI could also say "for such and such options, use the > CLI". Like it or not, users are getting used to touch screens and > such, so having to type in text (or copy and paste text) seems a bit > unfriendly to them. GUI is only about presentation and interaction, > it's not about anything automated, it's not about content.
I remember when things like Tcl/Tk came along, there was a GUI application that would poke about the output of a command's --help output and concoct a GUI form allowing the user to invoke the command after deciding its arguments. Not robust, obviously, but it's not a new idea. The problem is that text is so much more expressive than the limited palette a GUI can present from which the same desired outcome needs to be expressed. What tends to happen when faced with this is the palette becomes bigger, hierarchical, more complex, and therefore only of use to more expert users, defeating its initial purpose. Sure, for some users they should never need or see a command line. They've limited use for the machine, web, email but probably webmail, local media playing, e.g. DVD. The user account can be locked down, present them with a limited interface, and they're happy. I suspect a few of us know of relatives that want nothing more. But once a user wants to do a bit more. Pick and choose applications, install fonts, and generally wander more off of a chosen path then I don't think it's unreasonable that they should have to know about the command line so they can execute the help given or questions asked when there are problems. For starters, it's quite possible that there is no GUI way of doing the particular combination of commands sought because unless the GUI-programmer foresaw that particular need the GUI won't be able to do it; we're back to the lack of expressiveness above. The second major problem is even if the GUI provides the mechanism to do what's desired the actions have to be expressed in words, e.g. on a forum! System -> Preferences -> ... -> ... tab -> right-click ... and so on. It's tedious for the advice-giver to work out, although he knows it's important to be precise, and users rarely understand that importance when reporting a problem so a lot of the helper's time can be wasted. So it's far easier for the advice to be in the form of a command line that can be cut-and-pasted and the output to be similarly sent back, even if the GUI did happen to support it. For everyday actions, sure, have a GUI for the user to click through but I don't think it's realistic to expect all unwanted behaviour to be investigated only through a GUI. Cheers, Ralph. -- Next meeting: Crown Hotel, Blandford Forum, Tuesday 2010-11-02 20:00 Meets, Mailing list, IRC, LinkedIn, ... http://dorset.lug.org.uk/ How to Report Bugs Effectively: http://goo.gl/4Xue
