Date: Thu, 18 Jun 1998 21:58:44 +0100 From: Nik Clayton <nik@nothing-going-on.demon.co.uk> To: Sue Blake <sue@welearn.com.au>, Nik Clayton <nik@nothing-going-on.demon.co.uk> Cc: Tim Gerchmez <fewtch@serv.net>, freebsd-newbies@FreeBSD.ORG Subject: Re: Pine and Pico Message-ID: <19980618215844.62661@nothing-going-on.org> In-Reply-To: <19980618101150.14704@welearn.com.au>; from Sue Blake on Thu, Jun 18, 1998 at 10:11:50AM %2B1000 References: <3.0.5.32.19980615232720.007f66f0@mx.serv.net> <3.0.5.32.19980615232720.007f66f0@mx.serv.net> <19980617002803.07527@welearn.com.au> <3.0.5.32.19980616123420.007ede10@mx.serv.net> <19980617002151.21641@nothing-going-on.org> <19980617180012.64598@welearn.com.au> <19980617205005.51409@nothing-going-on.org> <19980618101150.14704@welearn.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 18, 1998 at 10:11:50AM +1000, Sue Blake wrote: > > And, when you think about it, you only pass the parameters when you > > 'invoke' the program. > > Sure, it all makes good sense. It's just that people like you seem to > have the ability to pull the correct word out of the air and then go find > it. I usually work out half a dozen synonyms and then find the manual > writer has used yet another :-) When I find it, I go "oh yeah, come to > think of it, that sounds like the word a computery person would use" It's a skill that comes with experience -- I think. After a while you have learnt enough that the interconnections between what you know spark new associations. I know of no magic bullet for this problem, short of investing a lot of time and effort in coming up with lots of synonyms for terms and conducting 'user interviews' to work out what terms they use. I've done this for a couple of websites I've worked on to try and make the pages easily found when indexed by search engines. It can be a very long job, and not one that any Unix has traditionally accomplished. Two other things spring to mind. First, the information Tim was looking for was not buried too deeply within the manual pages (as I say, ~ 75 lines into sh(1)) and it is findable with some cursory digging. It helps if you glance/skim through manual pages for unfamiliar pieces of software. You won't take it all in, but you will get an overview of what it can do. Later, when you're trying to get it to do something you go "Ah, I remember reading about that." and can go digging for the info armed with a bit more knowledge. The second is the risk of being blind to the information that's available to you. A little anecdote which may illustrate this; Yesterday I was called over at work by one of the secretaries who was putting together a Powerpoint presentation. Someone else had worked on the presentation before her (and wasn't around) and they'd added some shadow to some text. She was trying to remove it, and couldn't work out how. The button that *she* used to add/remove shadow from the text wasn't working. Not being overly familiar with this particular aspect of Powerpoint, I immediately pulled up the help and searched for "shadow". A couple of useful items came up, one labelled "Removing shadows". Following that information, it transpires that there are two types of Powerpoint shadows, one on the text, and on the *box* that the text is in. She was turning off the text shadow, but was not affecting the box shadow. 2 mouse clicks later and she's thanking me effusively. Now, leaving aside for the moment that this behaviour is somewhat surprising (I wouldn't have expected Powerpoint to have two different shadow types), she had access to all the information she needed to fix the problem herself. But she was so convinced that she knew how it worked that she didn't bother to check the help before calling me over (and destroying a quarter-hours worth of careful database schema I'd been mulling over in my mind -- such is life). I think this may happen to people new to Unix quite a lot. Because Unix doesn't behave the way they expect in many respects, they try to solve problems using the same approach they've used in the DOS/Windows/Mac world. Sometimes this works (but is sub-optimal), other times it's just not feasible. I can certainly remember this happening to me on my first exposure to Unix. The notion, for example, that I could have several programs running at the same time *from the console* without needing to run a windowing system was quite startling. Of course, I didn't know enough to call it the console then either! > > > There isn't a glossary anywhere, is there? > > > > Probably, but you'll need to shell[1] out some money. I would imagine that > > O'Reilly do a decent shell programming book which probably has a glossary. > > I don't know that a shell programming glossary would be enough, but it > would cover a lot of what I'm missing. I suspect that a lot of the > language that is used, in man pages and general communication about > problems and how things work, is language that is familiar to C > programmers. Most of the books I've seen show how-to, but skimp on > important concepts and definitions in order to be more appealing. Unless you've got specific counter examples, just about anything by O'Reilly is good, but assumes some experience. I think they do a _What to do when you can't find your System Administrator_ which is excellent. The _Dummies guide to Unix_ is, despite the title, also very good. N -- You are in a maze of twisty signature files all the same. -- You are in a maze of twisty signature files all alike. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-newbies" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980618215844.62661>