[scribus] are you experienced?

[Gregory Pittman]

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):
>>
>> http://wiki.scribus.net/canvas/Blog:Scribus_Times_and_Gazette/Searching_for_a_new_angle_in_documentation
>>
>> 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
> frustrating.
>
> 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?

Greg