Ubuntu needs Guided Help

http://en.wikipedia.org/wiki/Apple_Guide

I want to point this out as another method of the same. I think this paradigm is vastly better than MS'.

I don't really see how this would help anyone... the MS guided help is essentially just a way of showing people precisely what to click on for each step in a procedure. It is necessary because it is very difficult to describe, in an effective way, which button a person should click to do a certain operation (wait, should i click to button labeled "apply" or to check box labeled "apply on reboot"? or whatever...).

The example Jerome pointed out is, like its windows equivalent, just another solution to the "what do I click on now?" problem.

IMHO GNU/Linux already has an elegant solution to this problem: the command line.

It is infinitely easier, even for a novice, to follow a series of directions if all that is required is copy/pasting a series of lines into a terminal window. Try to describe, fully and completely using only words, how to install an app called "some crazy app" using synaptic. Now compare it to the description using the terminal.

type the following into a terminal window and press the enter key: sudo apt-get install somecrazyapp

One line (assuming the person knows how to launch a terminal, 2 lines if they don't).

I think the resistance among many people to using the command line is natural since the command line is seen as "geeky" and complicated. But the answer to this problem isn't "be more like microsoft", the answer is to make the terminal more accessible to beginners and to provide ample instructions in using it. Basically, we should be trying to make the terminal less scary rather than trying to make it less necessary.

This is a much easier task since it won't require thousands of lines of new code (that then must be maintained) and it is, inherently, distro-neutral (for the most part) since all the major distros (AFAIK) include bash.

People are ALWAYS resistant to change, no matter what it is, so it is to be expected that many people making the switch to ubuntu (or any GNU/Linux) from windows will dislike certain things about their new operating system and having to type commands into a terminal is only one of many many of these things (just google "going back to windows").

To sum up, the best way to help people make "the switch" successfully is not to make ubuntu just like windows, but to make it as easy as possible for people to learn to use the new and powerful features ubuntu has to offer (such as a fully functioning command line interface).

Just my opinion.

"I think the resistance among many people to using the command line is natural since the command line is seen as "geeky" and complicated."

No, the main problem with the command line is that it is ugly and that it depends on typing which is scary because you often don't know what the result of a typo might be. Clicking stuff is easier because either you're doing something you know you want to and you click "Apply" or something, or you're not sure and then there's always the comfort of the "Cancel" button.

I've implemented something which can sort of do this, if it's of any use:

http://philbull.livejournal.com/43421.html

Basically, it just runs a bash command when you click a specially formed link on an HTML page. It will only execute commands which appear in full on a whitelist. You can allow user interaction by using zenity.

> No, the main problem with the command line is that it is ugly and that
> it depends on typing which is scary because you often don't know what
> the result of a typo might be. Clicking stuff is easier because either
> you're doing something you know you want to and you click "Apply" or
> something, or you're not sure and then there's always the comfort of the
> "Cancel" button.
>
when you copy-paste from a forum post or help dialog there is no
change of a typo provided the original command was vetted properly
(which I would assume to be the case if we put them in the docs)...

Look at how many windows users screw up their computers just by
pointing and clicking, it's just as easy to do as with typing
commands. Actually I would argue that typing commands provides
insulation against errors since most CLI utilities won't run if you
mis-specify an argument. Also, command line tools each do one thing,
once you've opened a dialog box of some sort with root permissions
ANYTHING you click can take effect if you mess up.

The simple fact is that most users learned windows and are used to the
"windows way" of doing things. Once they get used to the *nix way of
doing things they'll be fine. Our job should be to help them along
the path to learning the new way of doing things.

Of course I'm not suggesting that every ubuntu user has to become a
crazy CLI-guru (I'm sure not). But at the same time, we shouldn't
vastly increase the complexity of the docs or the OS itself just so
that people can avoid learning anything new. That makes more work for
the devs and doc-writers and actually does a disservice to the users
since it makes them dependent on a non-standard way of doing things.

-George

~ George T. Lesica
<email address hidden>

On 9/27/07, Phil Bull <email address hidden> wrote:
> I've implemented something which can sort of do this, if it's of any
> use:

I like this a lot personally, it creates a pretty good middle ground
since it (shouldn't) be too complicated to implement (it's only html
with some scripting after all...) and it could be designed in such a
way that users can become familiar with the command line but have a
graphical fall-back (sort of like training wheels on a bike). For
instance, the Welcome Centre could let the user know when it is
running a command that the user might want to be aware of in the
future (a la the basic-commands help file).

-George

--
~ George T. Lesica
<email address hidden>

"when you copy-paste from a forum post or help dialog there is no
change of a typo provided the original command was vetted properly
(which I would assume to be the case if we put them in the docs)..."

Well, yeah, but then you don't know what you're doing (not that most people know when they are clicking things in a window, but they have the feeling they do), which is the reason that is scary.

On 9/27/07, Vincent <email address hidden> wrote:
> "when you copy-paste from a forum post or help dialog there is no
> change of a typo provided the original command was vetted properly
> (which I would assume to be the case if we put them in the docs)..."
>
> Well, yeah, but then you don't know what you're doing (not that most
> people know when they are clicking things in a window, but they have the
> feeling they do), which is the reason that is scary.

Exactly, it's scary because it's different and unfamiliar. Clicking
is like a safety blanket for people because, in most cases, that's all
they've ever done. So even when they have no clue what they're
clicking on, they feel safe because the button metaphor is familiar.

I'm just saying that we should make a serious effort to introduce
people to a different metaphor rather than trying to maintain a huge
repository of information about what to click in a given situation.
The less complex things are the less likely there will be bugs.

Not that they can't coexist to some extent, I think it's fair to say
that anything involving editing a config file is fair-game for a gui
because describing the gui in this case is easier than describing the
CLI version (e.g. "look for the section labeled "foo", you might have
to scroll up and down, it will be surrounding in brackets... etc.").

-George
--
~ George T. Lesica
<email address hidden>

So when trying to solve the problem of people not yet knowing how to do something in the GUI, you should invite them to do the same thing in the command line instead? Now you have two problems.

This bug report has nothing whatsoever to do with the command line, and it's unfortunate that it got sidetracked into that topic. GiuseppeVerde, I think this is an excellent idea, and one I've long advocated (see for example <http://mail.gnome.org/archives/gnome-doc-list/2006-December/msg00038.html>). However, as already demonstrated, an ubuntu-docs bug report is not a productive place for the suggestion. I suggest working with the Gnome and Yelp <http://live.gnome.org/Yelp> developers to make their software scriptable such that it can support this kind of help.

On 9/27/07, Matthew Paul Thomas <email address hidden> wrote:
> So when trying to solve the problem of people not yet knowing how to do
> something in the GUI, you should invite them to do the same thing in the
> command line instead? Now you have two problems.
>
> This bug report has nothing whatsoever to do with the command line, and
> it's unfortunate that it got sidetracked into that topic.

From the bug description:

"A common complaint about Linux is that it requires cryptic
command-line operations in some circumstances.

Windows does requires cryptic command-line operations in some
circumstances, but they provide a set of programs called "Guided Help"
to do the operations or to help step the user through them."

Sounds to me like it has something (a lot) to do with the command
line... the way the bug was framed suggested that guided help would
serve to prevent people from having to touch a command line.
Therefore, given this, I think it was perfectly logical and in-line
with the purpose of the bug report to question the wisdom of that
goal.

> list/2006-December/msg00038.html>). However, as already demonstrated, an
> ubuntu-docs bug report is not a productive place for the suggestion.

Ouch. I thought the point was to discuss the merits of different
ideas. I never attacked anyone, nor did I denigrate, in any way,
people who prefer GUI tools to CLI tools or any other types of users.

All I was saying is that I don't see the logic in intentionally
steering people away from the command line, which it seemed to me this
bug report advocated doing. Maybe I misunderstood, but if so I think
the report needs to be re-worded and/or expanded to clarify what the
goal is.

-George

--
~ George T. Lesica
<email address hidden>

Fair point. GiuseppeVerde, can you give more detail about why you mentioned the command line? As far as I can tell, Guided Help doesn't involve the command line at all. <http://blogs.msdn.com/activecontentwizard/> Anyway, I still think this would be better addressed to the Gnome and Yelp developers -- the Ubuntu developers don't really have the resources to implement something of this magnitude.

Command-line was mentioned because I was introduced to Guided Help through a KB article which had Guided Help or some command-line things. I didn't know that it encompassed more. Only after a conversation with GNOME devs did I realize that it could be larger. Besides, implementing a command-line version of this is pretty straightforward and should be considered both low-hanging fruit and a helpful, friendly way to introduce users to the command line.

The long-term solution would be something larger and more flexible. The/a Yelp dev is interested, provided he can get some people to help out.

GiuseppeVerde did you check out what Phil Bull had worked up? I
thought it was interesting since it could handle command line as well
as some other functions.

-George

--
~ George T. Lesica
<email address hidden>

It does look interesting, but I've not time to delve into it in detail.

My main concern is security, which looks like it's addressed to an extent.

I've had a stab at doing things in a graphical, step-by-step way. Make sure that:

 * You are running GNOME
 * You have the python-dogtail and python-xlib packages installed
 * You have ticked 'Enable assistive technologies' in System -> Preferences -> Universal Access -> Assistive Technology Preferences
 * You have logged out and then logged back in again *after* ticking 'Enable assistive technologies'

Then, download the Python file that I've attached, make it executable and run it. You should see your mouse properties get messed with.

What do you think?

The discussion on this bug has become so long and complicated that it is impossible to understand easily what it is about. Since the issues are complex, I'd recommend writing a specification/blueprint to clarify the ideas and then discussing it on the ubuntu-doc mailing list if there is interest in taking this further. I'll close the bug for now.