What baffles users? What help do they need?

Hi All,

While merrily editing chapters in the Calc user guide, I have been wondering about what users have the most problems with. Surely we would provide an important service by addressing those problems in our documentation.

Of  course, there are many types of users with various levels of knowledge and diverse needs. But there may  be some fairly easy steps we could take to more effectively meet their needs.

So, how do we know how to be most helpful for users? We discussed this briefly in the documentation call yesterday and I agreed to raise the issue here.

In my mind, documentation includes the user guides and help files but could also include additional FAQs, tips, and tutorials. (Researching and writing the latter might be good tasks/tests for new volunteers.)

Here are some initial thoughts about understanding user needs:

*Ask LibreOffice Forum *

Several developers and power users have devoted significant time to answering questions on the forum. Have frequent contributors been asked for their opinions about the top problems they see users needing help with?

Is it possible to data mine the forum to glean information about the types of questions being asked?

*LibreOffice Implementation Consultants*

What can we learn from Collabora, Red Hat, CIB, and others about their experience in training clients and dealing with user questions?

*Passive User Feedback*

What mechanisms are there for users to give us comments and suggestions? The guides invite users to send feedback to this mailing list. What has been the result?

What else could be done to encourage users to send their feedback?

*Asking Users Directly*

Have there been focus groups or similar initiatives for understanding user needs?

Has the UX team conducted strategies for obtaining user feedback?

I am sure that many participants in this mailing list have already discussed ways to get a sense of what users need.

Thoughts?

Cathy

Hi All,

Howdy Cathy,

Just a quick comment on mining the ask bot site - added in line.

While merrily editing chapters in the Calc user guide, I have been
wondering about what users have the most problems with. Surely we would
provide an important service by addressing those problems in our
documentation.

Of course, there are many types of users with various levels of
knowledge and diverse needs. But there may be some fairly easy steps we
could take to more effectively meet their needs.

So, how do we know how to be most helpful for users? We discussed this
briefly in the documentation call yesterday and I agreed to raise the
issue here.

In my mind, documentation includes the user guides and help files but
could also include additional FAQs, tips, and tutorials. (Researching
and writing the latter might be good tasks/tests for new volunteers.)

Here are some initial thoughts about understanding user needs:

*Ask LibreOffice Forum *

Several developers and power users have devoted significant time to
answering questions on the forum. Have frequent contributors been asked
for their opinions about the top problems they see users needing help with?

Is it possible to data mine the forum to glean information about the
types of questions being asked?

From a user of the web service perspective there are some easily answered
questions, although a gross answer at best:

So, for example, since the site uses tagging for questions that can be used
to get gross groupings.
Here is the results asking for number of questions with the Module name as
a tag:
11,558 questions Writer
8,792 questions Calc
2,796 questions Base
1,661 questions Impress
1,006 questions Draw

Then I could add an additional tag and get the number of questions tagged
with Calc fand Charts
   188 questions Calc + Charts

That is still 188 questions to be scanned over, that might very well be
worth the time for the person wanting to work on the Chart chapter.

Anyone with access to the database with drives the service could get more
creative about searches.

But even with

Cathy Crumbley kirjoitti 16.11.2018 klo 6.43:

*Asking Users Directly*

Have there been focus groups or similar initiatives for understanding user needs?

Has the UX team conducted strategies for obtaining user feedback?

There have been surveys: https://design.blog.documentfoundation.org/category/survey/

Such surveys are, of course, best-effort and the results cannot be seen as a proper representation of our user base.

TDF ran a tender for user metrics, but apparently got no quotes for it: https://blog.documentfoundation.org/blog/2015/12/16/tender-to-develop-and-incorporate-usability-metrics-collection-for-libreoffice-201512-02/

Ilmari

Hi Drew,

This is useful information that is especially relevant for me since I am working on the Chart chapter.  I  will certainly scan the questions, keeping in mind that people sometimes ask questions without first checking the documentation.

Cathy

Howdy,

inline comments

Hi All,

<snip>

So, how do we know how to be most helpful for users? We discussed this
briefly in the documentation call yesterday and I agreed to raise the
issue here.

In my mind, documentation includes the user guides and help files but
could also include additional FAQs, tips, and tutorials. (Researching
and writing the latter might be good tasks/tests for new volunteers.)

<snip>

*Passive User Feedback*

What mechanisms are there for users to give us comments and suggestions?

So there support in the TDF infrastructure for tracking documentation
deficiencies in the Bugzilla system used to track software defects and
enhancement requests.
There is a wiki page with a couple of predefined searches against the
database of issues, found at
https://wiki.documentfoundation.org/QA/Bugzilla/Components/Documentation/Help

Best wishes,

Drew

Checking the search for open issues against 'Spreadsheet' it finds 30
currently, majority deals with the help system.

The guides invite users to send feedback to this mailing list. What has

Basically, we don't.

Bugzilla tells us about what users expect to be able to do, but are
unable to do.

Surveys give us what users think that the documentation should cover (^6).

Analysing AskBot/web forum data tells what users want to do right now.

Analyzing Amazon book sales data tells what information people are
willing to pay for.
Analyzing TPB/Kat etc. data simply tells us what information people are
looking for, not necessarilly what they are willing to pay for.

None of that provides us with the information that people don't know
that they don't know.

By way of example, BAILS is implemented within LibO, (ignoring that part
of the functionality was eliminated in either 6.1.2 or 6.1.1). This is
great example of something that would be useful in maintaining
compliance with SOX, GDPR, and related legislation. Yet the absence of
documentation on how to use it, means that nobody asks questions about it.

A second example is the built-in version of LOGO --- LibreLogo. There
are two or three videos in English, and either one or two short papers,
describing a very basic program. There is a long paper in Hungarian,
which I don't read, and both Google Translate and Bing Translate mangled
beyond comprehension.(^1) What is needed here, is a document that
provides both the vocabulary and syntax recognised by LibreLogo.
Ideally, a rewrite of K&R, except for LibreLogo, rather than C.(^2)