Re: [SLUG] Moving forward on the Training Issue

From: Ian C. Blenke (icblenke@nks.net)
Date: Thu Jan 30 2003 - 14:39:31 EST


On Thursday 30 January 2003 13:49, bpreece1@tampabay.rr.com wrote:
> Most newbies have a few bad habits. They think in Pictures with this is how
> it should look.

I think in pictures how it should work. I'm a very visual person. Only in my
world, I have a command-line handle to that bit of the diagram in my head
instead of some dialog box buried under 17 button clicks.

> I am use to using a GUI that has taken the commands and hidden them with a
> script that runs in the background cause I do not care to see what makes
> this work I just want this to happen attitude.

And this is why the Linux desktop is such a difficult battle. Unless you make
the transition from one UI to another painless, the users will revolt until
they manage to learn the new way. This is why distros like LycoriX have the
appeal: Microsoft people "just get it", it "looks" the same - and generally
behaves similarly.

> Most get the I want the click and point only thing and to see cute little
> animations and my mouse is my tool because I also do not want to take the
> time to learn how to use commands to fix things, tweak things nor to have
> to use things I normally would never use. Not to mention I pay for tech
> support so some one can talk me through each step. This is why I do not
> want to learn Linux because it is too difficult if I have to do these
> things.

And do you blame them? Computers *should* just work. These are the types of
folks I point toward Macs and tell them to have at it. Nothing wrong with
them (hell, I'd like to run a network of OS/X desktop machines - they're just
so expensive). It does prove, however, that Unix/Linux boxen CAN be made user
friendly with the appropriate talent and focus.

Microsoft's UI simply isn't as intuitive, but the userbase is far larger than
any other desktop computing segment.

> These are the most common responses I hear. They just want to plug it in or
> have some video guide to walk them through it and turn it on then click and
> go. This is why they also use things like AOL they want cute and click
> things.

Human interface design is a fascinating field on its own merit.

> While we know you can make it that easy as well with some tweaks and
> patches etc., They don’t want it.

They don't want to know the tweaks/patches. If you hide this complexity from
them, they're quite happy to ignore it. Take the Windows registry for
instance.

> Next they are afraid to give up Games and certain apps. So then you have to
> convince them that there is equivalent or even better things out there.

That's the real eternal battle for Linux as a viable desktop. Fortunately,
it's the same battle for Macs and any other non-Windows platform as well.

> So the approach has to address these issues and next it has to be simply
> worded so that they do not get over whelmed. Not to mention get scared from
> the concept of learning something new.

Ignorance exists due to the fear of knowledge.

> Now matter what the teaching methods being Video, Books or and Instructor
> is to give easy examples and dialog. Make sure you come up with a method
> that makes them excited and drawn in to want to do this.
>
> We should come up with our own material that anyone can use. Next if we can
> get people attending the meetings who bring Laptops and Pc's to agree to
> work as teams with others who do not nor who dose not have any equipment
> that they can bring in at the meetings to learn on.

I've been considering using VNC recorded sessions with audio commentary. Turn
it into MPEG video for a VCD/SVCD/DVD, or keep it native and make a VNC/MP3
Java playback tool for a website. Not rocket science, really.

The difficult part is gauging your audience and planning out a course that
works at a speed where you keep that audience. I've given up on more than one
video tutorial because it's simply so damn slow. Also, it helps if you can
intersperse visualizations of concepts as diagrams between commands, so that
users "get it". Typing a command is one thing, diagramming the ideas behind a
command is something entirely different.

> Next we should also try to start with basics. If we go Redhat, S.u.S.E.,
> Mandrake, Knoppix etc., they already get into a position that they will
> only learn on one type of distro that come up a certain way Graphically to
> when they see something else then they already get lost when starting up
> the machine.

You really need "themed" tutorials at this point, one for each flavor distro.
Take that dialog that you made for a previous tutorial and doctor the
commands to fit another distro. This does make for a bit of repetition
though.

> So then we come up with a basic series of teaching manuals or video showing
> a distro using the basic of a default install of the distro. Starting with
> is this Distro compatible with your equipment ? ? Why you want to check
> and how to check. Now lets say we start with KDE for now.
> Once it is installed we then talk about the basic commands with how to
> check your available amount of memory, etc.,
>
> How to use the Console mode to do basic commands and things we normally
> would check.
>
> I could go one for hours with this but this is just a beginning point. Next
> we would need to have a website and I think using IRC would be a great way
> to have to simulate a classroom online environment and we could also use a
> streaming audio for those who have broadband.

There's something to be said about recording the sessions on a shared
"whiteboard" VNC desktop for later playback. With UML, I don't even mind
running a few of these on my public external servers (tucked neatly away
behind some firewall rules, of course).

> I know it will get flamed but this is just a suggestion.

I don't see the flamage. There are some good ideas behind this. Flying a
project like this with more than one contributor with a bit of free time is
the real challenge. They work us like the dogs we are here ;)

-- 
- Ian C. Blenke <icblenke@nks.net>

(This message bound by the following: http://www.nks.net/email_disclaimer.html)



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 14:02:19 EDT