Survey of Ubuntu Users [long]

[Sean Wheller]

African Greetings,

For the last two or three days we have been having intermitant discussions 
about documentation requirements for Breezy. Since it is hard to develop 
documentation without some knowledge of our users and their environment, I 
have suggested that we perform user and environment analysis that will enable 
us to more accurately define an overall information plan and document 
specifications for each of the documents we have proposed so far.

However, before we get into the details of the analysis, it is important to 
place this in context of the documentation project for Breezy as a whole.

My rational for performing analysis is so that we may gather information from 
our users and use it as knowledge on which to base our decisions in 
developing documents. The greater our understanding of the users and their 
environment the better we can address their requirements. It is important 
that we know as much possible about our users as they are our audience. We 
don't write documents for ourselves.

Our role as authors is to act as a conduit between the subject matter experts 
and the people who use their creations. Our job is to package knowledge so 
that it may be transfered between these groups. In doing so we have several 
challenges. The first and most important of which is to package information 
in a way that is understandable so that a user may accomplish a task safely 
and efficiently. 

At first glance this does not sound difficult, but a closer look tells us that 
not all people in the user category have the same level of proficiency with 
computers. So, we cannot create a single user profile detailing the level of 
skill or knowledge of our audience and write to that. For if we did, we would 
certainly fail. Some users would get lost in techno mumbo jumbo, other would 
get frustrated at reading such simple documents and feel that we insult their 
intelligence. Both results are undesirable. Somewhere inbetween we would 
cover a percentage of users at the expense of the others. For example, it is 
likely we would be covering a middle band of users who are computer 
proficient and that does not need as much help as new users. With this in 
mind, it is obvious that within our user group we have people with different 
backgrounds, motives, objectives, knowledge and experience with using a 
computer. It is impossible for us to write for the unique requirements of 
each and every user as an individual, so we need to identify and develop a 
creative way of identifying groups of user types, categorize them and package 
information with structure and content that each group can digest.

At this point I want to point people to SVN where I have committed some 
documents in https://docteam.ubuntu.com/repos/trunk/teamstuff
The files are:
* audience-analysis.xml  
* content-specification.xml  
* environment-analysis.xml  
* information-plan.xml

So, assuming we have an understanding of the user profiles and have 
categorized them, how does this fit into our content development life-cycle?

In short it fits into our planning phases. For purpose of brevity, I am not 
going into great depth here. It should suffice to say that the planning phase 
is comprised of two phases: 
Phase 1: Create an Information Plan
Phase 2: Create a Project Plan

My focus for now is Phase 1, the "information plan."
The information plan documents the basic organization and content of the 
publications we intend to build. This plan is the end product of a research 
effort that includes findings about the user and the product.

This bring me nicely to the survey. 

We are working in a virtual environment. We don't have the luxury of sitting 
face to face with our users or watching over their shoulders how they use 
Ubuntu. In order to assist us in performing user research we need to find 
another way to gather some information upon which we can make decisions. We 
need to turn our guesses into educated guesses. While to be fully effective 
on understanding users we need a combination of observation and interview 
techniques, I think that at present we know nothing and having 50% of the 
user information is better than 0%. On the product side we have our computers 
so it is safe to say that we have 100% ability to research in that area. If 
user and product are each 50% of our total research effort then an educated 
guess would be that we can, at best obtain 75% of the information required 
for our research. Which, in my opinion, is better that the 50% we currently 
have that only pertains to the product.

To obtain the additional 25% I have formulated two questionaires:
* User Analysis
* Environment Analysis

I would like to put these up on the Ubuntu Web Site and let users complete 
them, gather the results and, with team help, gather the results of our 
research into the information plan.

From this point we can develop content specifications for each of the proposed 
publications. It is highly likely that we may have to scrap our current ideas 
and replace them with the new ideas we have uncovered.

I believe that this initiative will have use beyond the scope of the 
documentation project, in which case it would be good to receive their input. 
However, I must ask that the relevance of any input be limited to the scope 
of our documentation effort. I fear that creeping beyond this scope would 
defocus what we are trying to do and protract the time it will take to 
execute.

Normally, I factor in that 10% of my project timeline is allocated to this 
type of research and planning. I have never tried this in an open source 
environment so I cannot with certainty say that it will take 10% of the 
Breezy development timeline. I would there like to set a milestone, but since 
I have no way of knowing when the survey will go live it is a bit of a moving 
target at present. However, at some stage we should set a milestone and 
cut-off for the planning phase.

In closing, I would like to outline the five phase model that I an other 
Technical Authors use to quality the stages of a publicationsdevelopment life 
cycle.
Phase 1: Information Planning 10%
Phase 2: Content Specification 20%
Phase 3: Implementation 50%
Phase 4: Production 19%
Phase 5: Evaluation 1%

Our i18n phase comes into Phase 3. As documents are completed, we release them 
as POT files. When they return as PO files they become part of Phase 4.

Each of these phases needs a milestone. Each phase has sub-phases that have 
their inner-cycles and milestones.

In general I think that this type of formal approach may meet resistance in an 
open source environment. I mentioned this in an earlier thread responding to 
the most excellent critique posted by Mathew (mpt). Some people said they 
were for a formal approach, many did not answer. I hope however that you will 
all give what I have proposed the due consideration it deserves and provide 
me with constructive input.

Please note that I will take silence to equal consent and will make my 
decisions to move ahead or not based on the input and support within our 
team. So if I get back one positive response, I will be "go." If I get back 
one negative response, I will be "stop."

Enjoy,

-- 
Sean Wheller
Technical Author
sean at inwords.co.za
http://www.inwords.co.za
Registered Linux User #375355
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20050417/6cbe1c34/attachment.pgp>