Request for comments about the Ubuntu Signpost

[Phil Bull]

Hi Andrew,

Sorry for the delay in replying, I've been Internetless for the last few
days.

On Sat, 2009-07-11 at 14:42 +0100, Andrew Sayers wrote:
> Since the "chatroom" part could be a forum or a mailing list, I've 
> christened the model the "Flowq" - a fusion between a FAQ and a 
> flowchart.  I've put an initial version up here:
> 
> 	https://help.ubuntu.com/community/Flowq

I like the idea of the signpost. There's clearly a big problem with
people repeatedly asking the same questions (I used to hang around a
support forum, so I sympathise), and helping users find the information
that they need is something that we really need to work on. If large
volumes of users are asking the same questions again and again, there's
clearly a discoverability issue with the docs, or not enough people are
looking at the docs before going to a live support channel.

I'm especially keen on the principle of limiting users' options to a
maximum of seven items that you're using. This is something that can and
should be applied to the system docs too (but that's a discussion for
another day).

Is a flowchart the best navigation method? It seems to me that there is
a significant error penalty with flowcharts: If the user picks the wrong
path, they have to expend a minimum of an extra two clicks to get back
on the right path, assuming that they identify their error at the next
node. I anticipate that some users will go down the wrong path, see
nothing obvious and just skip straight to the forum. That is, more
people will be clicking "None of the above" than will be going back up
one level of the hierarchy and trying a different option.

Because the user must typically go through several steps to get to their
destination, the probability of an error occurring stacks up. Naive (and
optimistic!) model: 5% chance of user choosing the wrong option at any
branch node, typical path length of 5 nodes. The probability of the user
getting to the right node in one go is approx. 0.95^5 = 77%. That's
almost a quarter of users failing. How many will self-correct? Based on
this, I'm not convinced that navigating linearly through a tree is
viable.

What about a "filtering" system, where you can remove bad filters? You
still drill-down through a hierarchy, but can remove choices that you
made higher-up just as easily as more recent choices. I quite like the
implementation at dabs.com: Try to buy a motherboard and make a few
choices. It might not scale for our uses, though.

While I agree with the "7 items or less" principle, I wonder if it's
going to generate a massive workload. The concept of rebalancing sounds
nightmarish. I don't think that it will be done by anyone but the most
devoted contributor. Couldn't this be addressed technologically, i.e. by
writing/using software to manage the tree rather than trying to work
sub-optimally within a wiki?

Is splitting a node necessary? Is there any other way of dealing with
the problem? I'm concerned that the need to invent a new branch to
handle an overflow will require more important topics to be relegated
down a level simply because they fit into the new sub-branch. This would
leave less-relevant topics higher-up because they don't fit into a nice
grouping. Is this an issue, or is it be OK to have important topics
further down the hierarchy?

Finally, I strongly agree with your thoughts on NAQLAs ("never-asked
questions I would like to answer"). I think that far too much of our
documentation could be classed as NAQLA, and I'd like to try and
alleviate this problem over the next few release cycles by developing a
culture of user testing and task analysis. Then, we can base our
documentation on actual, rather than perceived, user needs.

Thanks,

Phil

-- 
Phil Bull
https://launchpad.net/people/philbull