On 02/23/2011 10:25 PM, Yuval Levy wrote:
On February 21, 2011 03:32:18 pm Gregory Pittman wrote:
very interesting idea to write the manual first :)
If we do this, it would be nice if some could show some prototype ideas
of what this might look like or how this might work. What would the
workflow be? How would documenters interact with coders?
this discussion about writing the manual first has been going on for a few
days now... and nobody has mentioned things such as mock ups or functional
specifications?
Well written specs are like a very detailed manual but you don't want to
unleash them on the user because of too much detail that is relevant to
analysis and coding but not to usage.
It's a chicken and egg problem. or a feedback loop.
First there is a vision. It is analyzed, dissected, recomposed and fleshed
out; articulated into specifications including screens mock ups and functional
specs.
Then it is implemented into code and manual. The processes are parallel and
influence each other, with close/fast feedback loops.
In an ideal world the initial analysis is so perfect; both coders and
copywriters get it the first time so that when the software and the manual are
delivered to the users, all they can say is wow!
In reality nobody is perfect. The analysts are likely to miss something in
the func specs; the coders are likely to interpret / implement different than
intended; the tester are likely to find new ideas that would significantly
influence the vision that the analyst had not thought of in the first place;
and so the stage is set for the next cycle leading to v+1.
Simply taking a user manual as a specification document is not enough. If it
is, that manual is not user-friendly.
There is no perfect workflow either, just put the people in the same room and
get them to talk, talk, talk, until they understand each other, develop a
common sense of purpose and leverage each other's skills.
But it is not a user manual to drive the development. It is use cases,
analyzed and articulated into mock ups and func specs.
If I understand what Louis and a.l.e were trying to suggest, it was that
to some extent documentation should try to stay ahead of development,
before code is even written, so that a comprehensive, cohesive, and
sensible workflow shows the program where to go. I think we can imagine
that this is precisely how Steve Jobs has driven the development of
various Apple products, by focusing on the user experience. One might
also compare this to some authors of novels, who say that they begin a
book by creating a set of characters and situations, and then let the
characters determine where the story goes, and thus the book "writes
itself."
The main question is, how do we translate this to an open source
situation, with scattered volunteers working on a project? Those in the
proprietary world might argue that we can't, and this is why open source
is inferior. If we who are in various ways part of libre graphics don't
agree, it's up to us to show some results that prove that. This is
something that could be revolutionary, benefit every single project, and
attract more interest from those willing to help.
There is a certain amount of creative play that can go on with a libre
graphics program, but in many cases we begin with a mental concept of
something we want to create, then try to most efficiently translate that
to digitized form using whichever program(s) we choose. If we can manage
to progress from needing to push a long series of buttons (keystrokes
and mouse clicks) to something more like setting a row of dominoes
toppling with a few pushes, we begin to make the process less effortful.
Greg
_______________________________________________
CREATE mailing list
CREATE@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/create
