[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]

Re: [zzdev] Re: [zzdev] a version of the user's guide

Hi Cat!

> > One thing: could you (as an intermediate) make a page which has all
> the
> > figures on it? That would make downloading them all easier.
> Yesterdau evening I was reading Dilbert and there was one strip
> dealing with this issue. Dilbert is having a discussion with himself
> which goes like this:
> - I calculated the total time that humans have waited for
> Web pages to load ...
> - It cancels out all the productivity gains of the information age.
> - Sometimes I think the Web is a big plot to keep people like
> me away from the society.
> :-)))) Dilbert is a great philosopher.
> Anyway, I just though that putting all the images on the same
> page would make the doc too slow to load. (At the moment there 
> are about 30 .pngs and the amount of images is increasing all
> the time.)

I thought maybe you could make an _optional_ page with _just_ the images
(and their numbers) for reference? My problem is that I want to be able to
disconnect from the 'net when working at home, and I don't want to do right
click -- save (or -- open in new window) for every figure.

> > I feel it should also be organized in different structures, like,
> making
> > trails out of it showing how certain structures are build. (That,
> again,
> Hmh, yes. In the current version I've only described how the linking
> of the addressbook-familytree was made, but it would probably be
> a good idea to introduce some other example structures as well.
> On the other hand, according to some writers interested in 
> techinical communication (which is a growing field of research)
> a good user's guide follows the principle of minimalism. 
> Minimalists believe that people don't really have time to
> read user's guides, the smallest possible amount of information
> (which makes the reader understand) should be given. This
> means that the writer thinks that the user can find out creative 
> ways to use the product without a great amount of examples.  

Well, I'm not familiar with communication theory/studies. But I think when
you're dealing with a "whole new world," I feel it's better to have some
examples how to use it -- of course optional, organized in their own "trails."
Stuff meant to be skipped by the people who get it easily.

> Nevertheless, GZigZag is a rather complicated thing and 
> we can link the examples so that you don't have to read
> every example, if you don't want to.
> > > It will be a HUGE document since we want it to cover every
> > > aspect of the use of GZigZag.
> > 
> > I suppose you do accept submissions -- is there anything where help is
> > needed? (Like the cell views -- I'm familiar with them?)
> Hmh, you have been coding GZigZag, are you sure that you can
> take the perspective of the user? ;-) 
> Seriously, according to some writers an ideal writer of a user's
> guide sure knows how to use of the product, and does NOT have
> deep understanding of the techinical implementation. If the
> writer knows too much about the technical stuff, there's a danger
> that this information will end up in the user's guide (even
> though the users are generally NOT interest in that kind of
> information).
> No, I know a good one for you. Tuomas would like to have a guide
> explaining how you can code a specific view for a certain 
> structure (e.g the DayView used in the Cybertext article). 
> According to his opinion I should do this, but I'm not sure 
> whether I want to learn Java. (Well, I know some Java but I 
> don't think programming is fascinating. So learning how to
> make a view with Java sounds like a borig task to me.) Would 
> you possibly like to write that?

I do get your point. Thing is, I don't really have experience in writing
for programmers, and I'm not sure if I'm interested in it. I do have some
experience in explaining computer stuff to non-techies, but then, I usually
don't explain programs I've participated in writing.

On the other hand, writing the CellViews piece I've actually realized some
ideosyncracies about the current code because I "took the user's
perspective" -- so even if you don't think my submissions are good, writing them might
be healthy. :)

> > agree with your earlier comment that gzz has developed a lot of own
> > language which sounds like buzzwords ("relcells?"), a practice which I
> > basically resist -- not limited to computer science, I just hate these
> Specialists in every field have a language of their own.

(philosophical mode on)

Wissenschaft (sciences, social sciences, and the studies of the
humanities) is "meant to" help people. The model commonly employed for that is to have
a "specialist" who "knows best" about a subject. In order to keep their
status, "specialists" deny others the possibility of learning about their

This does not need to be a concious process, and asking them to stop it
completely would be asking too much. We all have privileges and exercise
oppression in many ways; we could all spend a lifetime thinking about them.
However, when people act against oppression/privilege, in this case make a field
more accessible by using easier terms, they should be welcomed, not

There are situations where special terminology makes sense: when
expressing the same in common language wouldn't be clear. However, criticizing the
use of perfectly fitting words as "not sounding scientific" etc. serves no
other purpose than to keep the privilege of the "specialists."

(philosophical mode off)

But that probably doesn't make much of a difference for us.

- Benja :o)

Sent through GMX FreeMail - http://www.gmx.net