some firefox navigation path analysis on mozillazine
Chris Hofmann
I'm started poking around analytics data for the Mozillazine KB and
discovered an interesting pattern in the way that people appear to be
looking for information in the kb and have possible impact as we start
to put together a style guide.
Its pretty apparent that one of the highest ranked travel paths relates
to lost bookmarks... Here is the navigation path
http://kb.mozillazine.org/Knowledge_Base (the highest ranked landing
pages) ->
http://kb.mozillazine.org/Category:Firefox (then to a firefox landing
page,
from here the top link click is to the bookmark page below) ->
http://kb.mozillazine.org/Category:Bookmarks (when users get to this
page they seem to split up the navigation path with the two highest
ranked clicked on links listed below)
The most frequent hit on the bookmarks page had people going to
http://kb.mozillazine.org/Bookmarkbackups_folder
It appears that people might thinking that this might be a solution page
and are attempting go directly to a solution like "tell me how to
find/install a bookmark back up file..."
while others go here for information that relates to the problem I have
described in terms of the problem
http://kb.mozillazine.org/Lost_bookmarks (people that have a
orientation to describing a problem)
There isn't very good content at
http://kb.mozillazine.org/Bookmarkbackups_folder that provides a direct
answer on how to restore a bookmark back up file (its more a definition
page) so then a very high pct of users appear to leave that page and
follow the link to http://kb.mozillazine.org/Lost_bookmarks
As we start to put together ideas for the style guide how should we
should be thinking about article naming conventions that will help in
efficient navigation from pages and search terms?
Should we try to name articles mostly based on a summary of the
problem?, or name articles based on a description of the solution (how
to's) ?, or possibly cross link one or more article(s) that attack the
problem from both ends.
In this particular case it appears that users want to go directly to the
solution, but we might be frustrating that by causing additional link
navigation...
It's interesting that with search the pattern is entirely different.
Top searches related to bookmarks that results in hits to the knowledge
base are
1. "Firefox Bookmarks" (general)
2. "bookmarks" (general)
3. "lost bookmarks" (problem description)
then on to other bookmark topics like
4. "Import Bookmarks"
This might indicate that when people are searching they are describing
the problem, not the solution. Anyone know of some good research in
this are that might help provide some guidelines around optimizing for
directory navigation and/or search?
chris h.
Jason Barnabe (np)
> Should we try to name articles mostly based on a summary of the
> problem?, or name articles based on a description of the solution (how
> to's) ?, or possibly cross link one or more article(s) that attack the
> problem from both ends.
Summary of the problem, definitely. While in this case, one possible
solution is fairly obvious ("restoring from a backup"), I'd say that
in the majority of cases, the solution isn't obvious, or there are
many possible solutions.
Take for example "Toolbar customizations reset on startup". The
solution to this is to open safe mode and pick "Reset toolbars and
windows". Users would have no idea that this is the solution, and
would not likely pick an article named as such (it's even the
*opposite* of what they're trying to do). In the current KB, this
article redirects to "Corrupt localstore.rdf", but this is just done
to prevent duplication across the half-dozen issues that have the same
solutions.
> There isn't very good content at
> http://kb.mozillazine.org/Bookmarkbackups_folder that provides a direct
> answer on how to restore a bookmark back up file (its more a definition
> page) so then a very high pct of users appear to leave that page and
> follow the link to http://kb.mozillazine.org/Lost_bookmarks
I think the solution would be to add some useful "maybe you want to
read this instead" links to the top of that article, and possibly
remove that article from the category.
I have to say this is incredibly useful data. Up to this point
understanding what users are trying to do in the KB has just been
guesswork and anecdotes.
Chris Hofmann
Jason Barnabe (np) wrote:
\snip
I think the solution would be to add some useful "maybe you want to read this instead" links to the top of that article, and possibly remove that article from the category.
Looking back at the talk page and followups to http://forums.mozillazine.org/viewtopic.php?p=2652869 there definitely has
been a lot of discussion in the past on the http://kb.mozillazine.org/Lost_bookmarks
It might be painful again but with the analytics we might be able to improve the navigation and get more data on the distribution among sources of the problem.
When a symtom (like bookmarks are missing/lost) might appear as the result of one of many causes do we have any style guidelines that can help to structure the information?
Right now this particular article seems to wander a bit back and forth between attempting to provide recovery instruction, preventative measures, and diagnosis of the cause, and the analytics seem to indicate that people believe they need to read or search though the entire article, which might also indicate problems in understanding the content and exhaustive searching for something they can grab on to.
One possible style guideline might be to first describe all the possible symtoms... e.g. sections or individual articles for topics like those listed below, and an attempt make to order the list in terms of estimated frequency, or simplicity of the symtom.
Bookmarks appear to be missing after upgrading to Firefox 2.Then provide instruction for recovery under each of these sections or link to another page if multiple symtoms can use a common set recovery instructions. Some examples of common recovery steps might be...
Bookmarks always missing after restart (firefox fails to shutdown)
Bookmarks missing after computer power outages, crashes, or abnormal shutdown
Bookmarks appear in the Bookmarks Manager but not in the main menu (Corrupt localstore.rdf)
Bookmarks missing after inadvertent switch to another user log on account,
Bookmarks missing after inadvertent switch to another Firefox profile.
Finding your bookmark
Restoring bookmarks from backup
...
To me, any "preventing future problems like this" sections or links to other pages should come at the end of all these navigation paths to avoid frustrating users trying to solve the immediate problem or in "maybe you want to read this instead/also" like np suggested..
Would style guidelines like that work? Are there other suggestions that might help to standardize presentation, and improve navigation?
I have to say this is incredibly useful data. Up to this point understanding what users are trying to do in the KB has just been guesswork and anecdotes.
chris h.
_______________________________________________ support-planning mailing list support-...@lists.mozilla.org https://lists.mozilla.org/listinfo/support-planning
Kevin Brosnan
> read this instead" links to the top of that article, and possibly
> remove that article from the category.
>
> want to read this instead/also" like np suggested..
>
> Would style guidelines like that work? Are there other suggestions that
> might help to standardize presentation, and improve navigation?
>
> understanding what users are trying to do in the KB has just been
> guesswork and anecdotes.
>
>
> building the new site and having a bunch of eyes looking at the reports and
> figuring out how to optimize naviagtion and improve content...
>
> chris h.
>
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
>
> _______________________________________________
> support-planning mailing list
> support-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/support-planning
>
>
I would just like to point out that if a user gets help via the
forums/irc/etc. they will likely be pointed directly to a page. This
may skew the numbers you are seeing. For example if a user is having
the corrupt localstore.rdf problem and getting help from IRC they will
be pointed to http://kb.mozillazine.org/Toolbar_customizations_reset_on_startup
+99% of the time. This is because we have canned support responses
thanks to firebot.
It would be interesting if the new support system could give us
breadcrumbs for a random selection of users so that we could better
organize information.
Kevin Brosnan
David McRitchie
> This might indicate that when people are searching they are describing
> the problem, not the solution. Anyone know of some good research in
> this are that might help provide some guidelines around optimizing for
> directory navigation and/or search?
And where does searching from come into account, can you
tell where from.
What if I know I want Corrupt localstore.rdf
and don't want to type it, and want to do a cursory check
of the text with the search results
:: corrupt localstore
and go to what is probably going to be the first hit from
did that constitute a search for me that you see, what if I turn
referrer id off, it certainly won't be
a search for someone who reads my reply of
http://kb.mozillazine.org/Corrupt_localstore.rdf
and which I normally do not show the title of such articles since
they are within the name of the URL.
Structure:
Putting "See also/instead" information at the beginning of
an article would probably be a bad idea and distracting.
The person came to the page to see something, probably
even saw relative description of article based finding search
words. If they don't find what they want or know they won't
find it they end up or go to the end of the article for other
information. The only exception would be if something is
a confusing issue because of spelling or usage you might
include alternatives at the top, with wiki that often means
an article with the same title but different capitalization
(gag, barf but it works).
--
David McRitchie,
Firefox Customizations: http://www.mvps.org/dmcritchie/firefox/firefox.htm
Majken Connor
To me, any "preventing future problems like this" sections or links to other pages should come at the end of all these navigation paths to avoid frustrating users trying to solve the immediate problem ...
This is a hard one sometimes, and the solution is definitely going to partly be in getting people to the right article. Especially for the example we're using here, bookmarks, it's important to have a note on prevention included with the solution. That is, in many cases with lost bookmarks, if they lose them once for one reason, it's entirely possible that they will lose them again for the same reason for some of the causes. Many users would then decide to switch browsers than look for a more permanent fix because they think they've already got the best solution. Again, especially with an article like lost bookmarks that covers many different causes, each having their own solution, putting it at the bottom of the article would mean either almost no one would get to it or everyone would have to read to the end of a very long article, and then figure out which prevention tip applies to them.
Then it's the same idea with links. That article being so long, if people's answer was on another page, we wanted to get them to it ASAP rather than make them read parts of the article that didn't apply to them. I think most of the time links in kb articles are links explaining in more detail what was just said, or they're a "this is happening to you this particular way? Then your solution is in this other article." I think moving either of those to the bottom of the article would be more frustrating than leaving them in context.
When a symtom (like bookmarks are missing/lost) might appear as the result of one of many causes do we have any style guidelines that can help to structure the information?
No, we don't, and that's why it ended up being discussed in the forums. The problem we had with ordering the issues in terms of frequency was that the most common causes involve having to mess around in the profile folder, or uninstalling the program. If someone just ended up in the wrong profile, that's a lot of (scary) work for them to go through to find out that it wasn't even going to help them.
I like that we ended up starting of with a diagnostic to point users to the appropriate section, although it would be interesting to know if people actually read it, or if they skip to the heading that sounds most like them.
There isn't very good content at
http://kb.mozillazine.org/Bookmarkbackups_folder that provides a direct
answer on how to restore a bookmark back up file (its more a definition
page) so then a very high pct of users appear to leave that page and
follow the link to http://kb.mozillazine.org/Lost_bookmarks
I think this is a problem that should be fixed. I think there should be an article on restoring bookmarks from a backup if it doesn't belong in the information article. I'm not sure if I'd say it should be in the information article or not, I'd have to read through others to see how many give detailed instructions on how to use the files. If someone just wants to restore from a backup they really shouldn't be directed to the lost bookmarks article.
On top of that, I think we should be able to easily keep information articles and support articles separate maybe somewhere top level. So people who are navigating because they have a problem already have the articles narrowed down for them to diagnostic ones, and people who want to know what a certain file does or how to use something have those articles in one section to look through alphabetically.
Bookmarks is definitely a special case though, and I'm not sure we want to base our style guides around it, rather it should be an exception. For most articles I agree, diagnosis, solution, prevention, see also, related bugs (maybe we don't want to link to related bugs ourselves). The question is, when there is a comprehensive issue how far do we refine the info, do we create more hops to the solution for clarity, or do we fit in as much as we can.
I think tagging is going to solve a lot of issues as well, and we should encourage people to use the search rather than try to navigate the hierarchy if they have a problem. I think the lost bookmarks article is a good example of where a really good search is going to improve getting users to the answer. If someone searches on lost bookmarks it'd be great if we could pose back a few questions like "did your pc just reboot/crash" and then point them to the right solutions for them.
-Majken "Lucy" Connor
Jason Barnabe (np)
double post.
On Jun 11, 11:41 pm, Chris Hofmann <chofm...@mozilla.org> wrote:
> When a symtom (like bookmarks are missing/lost) might appear as the
> result of one of many causes do we have any style guidelines that can
> help to structure the information?
There's no set guidelines, but what we keep in mind is
-The frequency of the problem (need metrics!)
-The difficulty of diagnosis or solving
-The destructiveness of diagnosis or solving
For the most part, the most common solutions are listed first. But,
like Majken says, given a hypothetical situation where 90% of the
problems will be solved by a new profile and 10% of the problems will
be solved by pressing a button, I'd suggest the button first because
of ease and non-destructiveness.
> One possible style guideline might be to first describe all the possible
> symtoms... e.g. sections or individual articles for topics like those
> listed below, and an attempt make to order the list in terms of
> estimated frequency, or simplicity of the symtom.
Creating section headers based on the symptoms often works, but it
breaks down for articles like Lost Bookmarks. The solutions just don't
have distinct enough symptoms. Like Majken says, I don't know if the
most complex articles are the ones to base guidelines on.
Jason Barnabe (np)
> Putting "See also/instead" information at the beginning of
> an article would probably be a bad idea and distracting.
I think we're just talking about including it in the intro text rather
than having a distracting list. The text would be like what we do at
http://kb.mozillazine.org/Preferences_not_saved - a user might
legitimately think that "preferences not saved" could mean their
preferences on where toolbars are, so we include a possible
alternative they might want to look at.
misb...@gmail.com
> On 6/12/07, Chris Hofmann <chofm...@mozilla.org> wrote:
>
>
>
>
>
> > Jason Barnabe (np) wrote:
> > \ snip
>
> > I think the solution would be to add some useful "maybe you want to
> > read this instead" links to the top of that article, and possibly
> > remove that article from the category.
>
> >https://lists.mozilla.org/listinfo/support-planning
>
> > _______________________________________________
> > support-planning mailing list
> >https://lists.mozilla.org/listinfo/support-planning
>
> I would just like to point out that if a user gets help via the
> forums/irc/etc. they will likely be pointed directly to a page. This
> may skew the numbers you are seeing. For example if a user is having
> the corrupt localstore.rdf problem and getting help from IRC they will
> +99% of the time. This is because we have canned support responses
> thanks to firebot.
>
> It would be interesting if the new support system could give us
> breadcrumbs for a random selection of users so that we could better
> organize information.
>
> Kevin Brosnan
Sorry for asking this at the wrong place, but where could I suggest a
new feature for T-bird? (I'd like to have the option of attaching a
pic to people's names so that when I let autofill complete an address,
I'd get a visual cue that I'm sending to the right person. Would
eliminate some mistakes.) Thanks for your advice.
David McRitchie
Okay, hardly noticeable, so not really distracting. Interesting that
it is not included at bottom and especially because the name is
not shown at top.
Chris Ilias
> In this particular case it appears that users want to go directly to the
> solution, but we might be frustrating that by causing additional link
> navigation...
As I said in my reply to the first meeting notes, search should be the
primary navigation tool. Ideally, a user looking for help, should go to
the support portal
<http://wiki.mozilla.org/images/9/98/Firefox-Support-Mock-Homepa.png>,
and type his/her question. Let's say "can't find bookmarks", or
"bookmarks are gone". This should result in a list of search result,
with the "lost bookmarks" page, hopefully being the top result.
Portal-->Search_results-->Article
By they way, what search engine are we going to use?
What do you think of doing away with "general" pages. In a system, where
search is the primary navigation tool, pages that don't address a
specific task/question do not serve much (if any) purpose.
My big fear is bad terminology:
- favorites disappeared (no results at all)
- my websites are gone (6 results, but none are the lost bookmarks page)
- firefox ate my saved pages (1 result, which isn't the lost bookmarks page)
I see it a lot like searching for a bug in bugzilla; and I've found the
inclusion of DUP bugs in search results to be a Godsend. This is where I
think including forums discussions in search results could really be
helpful.
Jason Barnabe (np)
> What do you think of doing away with "general" pages. In a system, where
> search is the primary navigation tool, pages that don't address a
> specific task/question do not serve much (if any) purpose.
Which pages are you referring to as "general" pages? The Category
pages?
> My big fear is bad terminology:
> - favorites disappeared (no results at all)
> - my websites are gone (6 results, but none are the lost bookmarks page)
> - firefox ate my saved pages (1 result, which isn't the lost bookmarks page)
This would be another useful metric to have... The most common
searches that result in nothing, or the most common searches where the
user ends up posting a question.
Different terminology can be partially addressed by including that
terminology in the page. For example, on http://kb.mozillazine.org/Firefox_hangs,
the words "freezing" and "not responding" are included for the sake of
searchers.
Chris Ilias
> Which pages are you referring to as "general" pages? The Category
> pages?
Yes, category pages would certainly be classified as "general" pages;
but I just don't want to limit the term to category pages. :-)
> This would be another useful metric to have... The most common
> searches that result in nothing, or the most common searches where the
> user ends up posting a question.
>
> Different terminology can be partially addressed by including that
> terminology in the page. For example, on http://kb.mozillazine.org/Firefox_hangs,
> the words "freezing" and "not responding" are included for the sake of
> searchers.
Maybe tags? Meta keywords?
My ilias.ca access logs actually show my what search terms were used,
when a person arrives at my site. I wonder if it's possible to find out
the most common search phrases entered in sumo?