dhis2-documenters team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Hi Jens,

I took a look at one of the documents you sent. Coming from an academic
background as an engineer, I spent a lot of time in my early days using
expensive pieces of equipment with thick user manuals.It was not always
clear to me why.  I think what you have started to write is more of a
practical laboratory exercise manual. Right now, what we have is a basic
operators manual  (What button do I press to use this mass spectrometer?) ,
but it says nothing about how to interpret the results, or how to use it to
solve a particular problem. Personally, I think we may need to go a lot
further, and specify why certain graphs/reports need to look the way they
do. Why use a choropleth map at all? What is the significance of such an
output and when should it be used? Which output do we need to answer a given
question in the most effective way? A map? A table? Some other type of
report? These questions are far from clear from either the user manual or
the document you have shared.

I have long been a critic of the approach of "give them a Pivot Table and it
will solve all of their problems". It has not worked in several places I
have been and part of the reason is that people who need to look at the data
do not always know necessarily how data should be visualized. They may be
capable in interpreting "canned reports" or dashboards which have been
created by people familiar with data visualization techniques and M&E, but
may not be capable of creating them themselves. I think what you have
started is a sorely need end-user training manual and exercise book. I
peursonally think that the use of the sample data set, where possible, would
be ideal, as it would allow standardized training materials to be developed.
And of course (and you knew I was going to say this) I think it should be
written in DocBook and committed to the documentation branch. Creating Word,
HTML and PDF is simple from DocBook but not the other way around.

Just a few thoughts.

Good work. Keep it up.

Best regards,
Jason

2011/6/10 Jens Johan Kaasbøll <jensj@xxxxxxxxxx>

> Obviously no success. Use the web links below instead
>
>
> On Fri, 10 Jun 2011 14:38:23 +0200, Jens Johan Kaasbøll <jensj@xxxxxxxxxx>
> wrote:
>
>> Seems like the attachments did not come through, even if they are in
>> my Sent box. Strange. Try again.
>>
>
> During discussions on user learning in Tanzania, two issues came up. First,
> users struggle with finding out how to generate reports for their health
> management tasks. Second, many are confused as to aspects of the overall
> structure of the HMIS, including both health information and DHIS.
> Problems of coupling the DHIS functionality to health tasks may be eased
> through changes in the user interface and documentation. Pushing the Reports
> choice under Services takes you to a page void of health tasks. For
> instance, the explanation of Chart is
> “View and add charts. Charts are based on indicators and either
> organisation units or periods.”
> If we rather start with health tasks, we could for example write:
> “To get an overview of the facilities in your area for a health service,
> choose Charts.”
> Likewise, manuals and slides could also be designed based on health tasks,
> see attached drafts. These drafts also includes examples of how the
> structures, components, concepts and principles of DHIS and HMIS could be
> presented. The drafts are for slides
>
> http://www.uio.no/studier/emner/matnat/ifi/INF3280/v11/ChartReportTestSlides.ppt
>
>
> and for a document which is closer to a textbook than a manual.
>
> http://www.uio.no/studier/emner/matnat/ifi/INF3280/v11/ChartReportTestTextbook.doc
>
> http://www.uio.no/studier/emner/matnat/ifi/INF3280/v11/ChartReportTestTextbookAnnotated.pdf
>
>
> Shorter versions could also appear as instructions on the right part of the
> screen as context-sensitive help when running the DHIS, possibly as videos.
> Are there any opinions on these matters?
> Is it worthwhile trying to design documentaiton in this way?
> Managing documentation of the same thing for different media begs for a
> more systematic way of storing and generating it than the Office files I
> produced. This is another, but related topic for discussion.
> Regards,
> Jens Kaasbøll
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~dhis2-documenters
> Post to     : dhis2-documenters@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dhis2-documenters
> More help   : https://help.launchpad.net/ListHelp
>