[scribus] are you experienced?
gregp_ky at yahoo.com
Sun Mar 20 04:32:33 CET 2011
On 03/19/2011 10:52 PM, John Jason Jordan wrote:
> On Sat, 19 Mar 2011 21:56:49 -0400
> Gregory Pittman<gregp_ky at yahoo.com> dijo:
>> If you are, read my new entry in the wiki blog (even if you're not,
>> you can read it too):
>> I have little idea how much time and work this project will take, but
>> it's one of these brain itches I need to scratch at a bit.
> Whenever I need to use software that I am unfamiliar with I generally
> start with a simple project. And then another project, perhaps months
> later. And another. And another. In fact, the initial project is
> probably what drove me to try the program in the first place.
> A big advantage of learning a program this way is that I learn the
> parts that *I* need to know about for the kinds of work that *I* do. It
> is also very efficient. And I remember what I learned better because I
> learned it by doing it. The disadvantage is that there will always be
> holes in my knowledge of the program. To me, the advantages far
> outweigh the disadvantages.
> Because of my way of learning programs I strongly support your idea of
> task-oriented Scribus. However, I'm not sure that creating
> documentation aimed at specific types of tasks is necessarily useful.
> If the documentation has a search feature I can look things up as I
> need them - assuming I can figure out what the feature I am looking for
> is called. Knowing the terminology of a new program is always
> I also like the idea of workflow documentation although, again, I
> wonder about its usefulness. On the other hand, when I gave a recent
> talk about Scribus the audience (Linux heads, programmers, computer
> science people) were amazed at ideas like line screen and banding,
> colors out of gamut, and even CMYK. Some didn't even know the
> difference between a vector and a raster image. I think the workflow
> idea might be very useful as a framework for general DTP stuff.
Even as I advocate for this new approach, I also share your concerns.
The next layer of my thinking is that this new approach
will/could/should be a mixture of some documentation and what we might
call meta-documentation, something like each task being the hub of a
wheel, with spokes that may point in various directions for specific
how-tos about individual parts, such as creating frames, working with
text, and so forth.
Like a wheel, you end up with some sturdy, durable information, but you
lessen the weight of the new material. You also allow for multipurposing
of the bits or spokes if you will.
This might allow for someone to take their own path from one wheel to
another (I may be getting bogged down in the metaphor at this point).
This also might allow for those who have particular knowledge in some
esoteric part of this, such as color management or fonts, to create
something that interacts with or complements this work.
I'm trying to answer the question of "why is Scribus so difficult to
learn?" without simply accepting that it's just the way it is.
This is from my part an exploration at this point as I try to answer
this question for myself. We know that there are many now who have had
the need or desire to face up to the challenge of learning Scribus. Can
we tap into that knowledge to help those who have just started or are
part of the way to learning Scribus?
More information about the scribus