Forum ideas and priorities
Jason Barnabe (np)
-End users seeking support (they will have already searched the KB and
were unable to find a solution)
-Contributors providing support
-Administrators
Each of these types of users has different wants and needs which can
be in conflict with one another. We should try to fulfill the wants
and needs of each group without causing other groups significant harm.
After discussion with the community, here are some of the major ideas
raised:
Contributors need complete information from end users, but end users
may not want to provide it (additional work) or may not know what to
provide. Whenever possible, we should automate the information
gathering. Information we could gather automatically:
-OS (from user agent)
-Firefox version (from user agent, or prompt the user if the user
agent isn't Firefox)
-What the user has searched for already
-What articles the user has visited already
Other information can't be gathered automatically. We could prompt the
user to include this information with separate text fields for each
piece of information (like the Bugzilla Helper) or with instructional
text. Not all text may apply for all situations. Information we could
prompt for:
-URL
-Short description of the problem (thread title)
-Steps to reproduce
-Expected results
-Actual results
-When the problem started happening
-Configuration info such as add-ons installed
-Error text
-Screenshot
Contributors want to be able to find certain threads, such as:
-Threads they've posted in. This is likely possible out of the box.
-Threads via arbitrary criteria - advanced search. This is likely
possible out of the box.
-Threads where the user is still looking for help. Allow end users to
mark their question as answered, like Clearspace. After a period of
time, allow contributors to mark the question as assumed answered.
-Threads by subject. This would require the end user to enter the
subject of their question when posting. This would perhaps post
threads in different sub-forums.
End users will need to find their questions after posting them.
-Prominent link to threads they've posted in.
-E-mail notification, possibly defaulted to notify.
-Feed.
End users will want to not be distracted by other threads and options
that may be useful to contributors. We should provide two different
views - one for end users that lets them track their questions and
post new ones, and one for contributors that's like a normal forum
(forum list, advanced views, etc.). The different views could be at
different URLs with a link between them, which allows end users and
contributors to self-identify and not require setting of roles or
permissions. By default, the software should assume people are end
users.
End users may not want to register to post a question. This conflicts
with contributors' desire to help, as having multiple anonymous users
posting in a thread can be confusing, with administrators' desire to
do nothing (can cause spam), and with end users' own desire to be able
to find their questions. To mitigate these problems
-Force the end user to at least give themself a name, and remember
this name (via cookie) for future posts.
-Use a captcha or similar to prevent spam.
-Make registration and posting a single step and encourage end users
to register.
Contributors will be linking to KB content often when helping users,
so we should make it very easy to do.
-Allow contributors to use wiki syntax (double parenthesis) for links.
Should be possible out of the box.
-Automatically link very common terms, like Safe Mode or Profile
folder
End users may reach others' threads when looking for a solution. To
ensure they get the best information from this path:
-Encourage end users to create a new thread rather than re-use someone
else's thread. While the end user may think the problem is the same,
the same symptoms can be caused by multiple issues, which confuses
things. New threads will also put the end user through the information
gathering process.
Contributors will want to know what the KB is lacking. We need to
create metrics (manual or automated):
-Top questions being asked not answered in the KB (encourage people to
create this content)
-Top questions being asked that are answered in the KB (encourage
people to better the existing content)
Contributors will want to discuss things with each other that aren't
support requests. Give them a forum or forums to discuss things with
each other.
End users will want to talk about non-support issues. Give
contributors a button to click that would make a post telling the end
user to go to mozillaZine or other places for this discussion.
Of the above, here are the priorities:
-Gathering of data from end users - OS and version and prompting for
Bugzilla-like details
-Simplified interface for end users, including "My questions" link
-Marking a question as being answered and filters for contributors to
see what hasn't been answered
-Anonymous posting, including name requirement and captcha
kray2...@gmail.com
wrote:
> The forums will be used by three types of users:
> -End users seeking support (they will have already searched the KB and
> were unable to find a solution)
> -Contributors providing support
> -Administrators
I had thought sumo was going to replace the kb, or that eventually the
kb would be pulled into sumo. Am I mistaken? I had thought we would
want people to come to sumo before or instead of the kb. But then, I
have never been fond of the kb.
> Each of these types of users has different wants and needs which can
> be in conflict with one another. We should try to fulfill the wants
> and needs of each group without causing other groups significant harm.
> After discussion with the community, here are some of the major ideas
> raised:
Are there going to be types of forums? I assume we would want some
forums to be admin only, yes?
> Contributors need complete information from end users, but end users
> may not want to provide it (additional work) or may not know what to
> provide. Whenever possible, we should automate the information
> gathering. Information we could gather automatically:
> -OS (from user agent)
> -Firefox version (from user agent, or prompt the user if the user
> agent isn't Firefox)
> -What the user has searched for already
> -What articles the user has visited already
> Other information can't be gathered automatically. We could prompt the
> user to include this information with separate text fields for each
> piece of information (like the Bugzilla Helper) or with instructional
> text. Not all text may apply for all situations. Information we could
> prompt for:
We can get some of this automatically. Perhaps we should confirm it is
ok with the user, but it can be done. In particular, the URL, and the
screenshot, and the list of plugins, the list of extensions and the
list of non-default preferences (aka options) can be automatically
gathered.
Also, I know all of these types of systems have "expected results" and
"actual results" listed separately, but I always think it is silly and
most people ignore one, or put minimal answers in one and fill out the
other. People want to describe what they expected and what they saw
together. It is how people think. We should not perpetuate this
artificial distinction in the response.
> -URL
> -Short description of the problem (thread title)
> -Steps to reproduce
> -Expected results
> -Actual results
> -When the problem started happening
> -Configuration info such as add-ons installed
> -Error text
> -Screenshot
>
> Contributors want to be able to find certain threads, such as:
> -Threads they've posted in. This is likely possible out of the box.
> -Threads via arbitrary criteria - advanced search. This is likely
> possible out of the box.
> -Threads where the user is still looking for help. Allow end users to
> mark their question as answered, like Clearspace. After a period of
> time, allow contributors to mark the question as assumed answered.
> -Threads by subject. This would require the end user to enter the
> subject of their question when posting. This would perhaps post
> threads in different sub-forums.
How about threads with recent and/or a lot of activity?
We should make it as easy as possible for a contributor to turn a post
into a bugzilla bug. There should be an explicit link between the bug
so created and the thread. Navigation links should be created from one
to the other.
> End users may reach others' threads when looking for a solution. To
> ensure they get the best information from this path:
> -Encourage end users to create a new thread rather than re-use someone
> else's thread. While the end user may think the problem is the same,
> the same symptoms can be caused by multiple issues, which confuses
> things. New threads will also put the end user through the information
> gathering process.
>
> Contributors will want to know what the KB is lacking. We need to
> create metrics (manual or automated):
> -Top questions being asked not answered in the KB (encourage people to
> create this content)
> -Top questions being asked that are answered in the KB (encourage
> people to better the existing content)
Yeah! Hoorah!
> Contributors will want to discuss things with each other that aren't
> support requests. Give them a forum or forums to discuss things with
> each other.
>
> End users will want to talk about non-support issues. Give
> contributors a button to click that would make a post telling the end
> user to go to mozillaZine or other places for this discussion.
>
> Of the above, here are the priorities:
> -Gathering of data from end users - OS and version and prompting for
> Bugzilla-like details
> -Simplified interface for end users, including "My questions" link
> -Marking a question as being answered and filters for contributors to
> see what hasn't been answered
> -Anonymous posting, including name requirement and captcha
Zounds good!
- ray
Majken Connor
Actual results and expected results should only be one sentence each, unless the issue is complicated. The long descriptions should be the steps to reproduce. It's necessary to give proper help to understand clearly what the user *wanted* to happen, and to understand what's going wrong, it's just as important to know what *is* happening. Maybe there's a better way to get this information though, or to phrase what we're asking for to get people to provide both.
There isn't a real benefit to finding threads by level of activity, and recent activity is the default sort for all forums I've seen. Especially in a support forum, I think the only metric that really matters is whether or not the thread contains a solution. We can get good info on whether or not an article is well written, or whether users are hitting a new bug by looking at duplicate threads, and which threads don't have an answer. I think we're more likely to get lots of duplicate threads rather than a thread full of people saying "me, too. Where's the answer?" And if that's the case, then it'll be at the top of the thread list anyway.
I agree that bugzilla should have lots of links to sumo, but we definitely shouldn't make it the other way around. Part of our job as support providers, IMO will be to help people file useful bugs. If people don't know how to use bugzilla we shouldn't "cold transfer" them. Preferably we file the bug for them once we have all the info needed, and then cc them to it, or walk they through what info to provide.
-Majken "Lucy" Connor
Jason Barnabe (np)
> On Aug 18, 1:13 pm, "Jason Barnabe (np)" <jason_barn...@fastmail.fm>
> wrote:
> > Contributors need complete information from end users, but end users
> > may not want to provide it (additional work) or may not know what to
> > provide. Whenever possible, we should automate the information
> > gathering. Information we could gather automatically:
> > -OS (from user agent)
> > -Firefox version (from user agent, or prompt the user if the user
> > agent isn't Firefox)
> > -What the user has searched for already
> > -What articles the user has visited already
> > Other information can't be gathered automatically. We could prompt the
> > user to include this information with separate text fields for each
> > piece of information (like the Bugzilla Helper) or with instructional
> > text. Not all text may apply for all situations. Information we could
> > prompt for:
>
> We can get some of this automatically. Perhaps we should confirm it is
> ok with the user, but it can be done. In particular, the URL, and the
> screenshot, and the list of plugins, the list of extensions and the
> list of non-default preferences (aka options) can be automatically
> gathered.
I can see how with modifications to Firefox we could get add-on and
preference info, but how would URL and screenshot work?
> Also, I know all of these types of systems have "expected results" and
> "actual results" listed separately, but I always think it is silly and
> most people ignore one, or put minimal answers in one and fill out the
> other. People want to describe what they expected and what they saw
> together. It is how people think. We should not perpetuate this
> artificial distinction in the response.
I agree. I was thinking we'd have one box that we instructed the user
to give us steps to reproduce, expected results, and actual results
all together.
> > Contributors want to be able to find certain threads, such as:
> > -Threads they've posted in. This is likely possible out of the box.
> > -Threads via arbitrary criteria - advanced search. This is likely
> > possible out of the box.
> > -Threads where the user is still looking for help. Allow end users to
> > mark their question as answered, like Clearspace. After a period of
> > time, allow contributors to mark the question as assumed answered.
> > -Threads by subject. This would require the end user to enter the
> > subject of their question when posting. This would perhaps post
> > threads in different sub-forums.
>
> How about threads with recent and/or a lot of activity?
Yeah, sure. I'd expect this to also be available out of the box.
Jason Barnabe (np)
> An admin forum, where we can discuss policy and what to do about certain
> issues would be a good idea, but I don't think we'd benefit from it being
> admin *only.* If users can see *why* we agreed on a course of action, they
> can respect it. Certainly we wouldn't want it to be user facing, to keep
> down clutter, but I don't think we'd want to restrict anyone from seeing it
> who would want to. Jason may feel differently, but that's my take. Anything
> supersensitive should probably happen in PM anyway.
I agree, we should keep things public unless there's a reason to be
private. I was thinking we'd have a support forum, a "meta-forum"
where we talk about giving support (including discussing policy), and
possibly an off-topic forum. All would be accessible to anyone, but
we'd only present the links to the second to to contributors.
> I agree that bugzilla should have lots of links to sumo, but we definitely
> shouldn't make it the other way around. Part of our job as support
> providers, IMO will be to help people file useful bugs. If people don't
> know how to use bugzilla we shouldn't "cold transfer" them. Preferably we
> file the bug for them once we have all the info needed, and then cc them to
> it, or walk they through what info to provide.
I agree with this. If end users see a "make this thread a bug report"
link, I think most of them would click it immediately, and that's not
what we want. I also don't see it being very useful, since if we
wanted to file a bug and include all the information, we would just
have link back to the forum thread.
Ray Kiddy
Well, I am still trying to get the URL in an extension that I am working
on, but I think I am going to be able to get to it. Using the XPCOM API
is like peeling an onion. There is always another layer.
As for the screenshot, that is easy. I have been working with several
different ways to use the same canvas-snapshot-to-PNG that reftest uses.
For just one example, see
http://xoatlicue.blogspot.com/2007/07/way-around-my-gordian-knot-with.html
<snip>
- ray
Jason Barnabe (np)
>
> <snip>
>
> - ray
I know that we can get a screenshot and a URL from the user's browser,
but we want a screenshot and the URL _of the problem_.
Jason Barnabe (np)
wrote:
> Contributors need complete information from end users, but end users
> may not want to provide it (additional work) or may not know what to
> provide. Whenever possible, we should automate the information
> gathering. Information we could gather automatically:
> -OS (from user agent)
> -Firefox version (from user agent, or prompt the user if the user
> agent isn't Firefox)
> -What the user has searched for already
> -What articles the user has visited already
> Other information can't be gathered automatically. We could prompt the
> user to include this information with separate text fields for each
> piece of information (like the Bugzilla Helper) or with instructional
> text. Not all text may apply for all situations. Information we could
> prompt for:
> -URL
> -Short description of the problem (thread title)
> -Steps to reproduce
> -Expected results
> -Actual results
> -When the problem started happening
> -Configuration info such as add-ons installed
> -Error text
> -Screenshot
Here's a semi-functional mock-up of this feature: http://userstyles.org/newpost.html
It seems to me there are too many questions being asked. Could some be
combined? Are some not important?
I'm concerned about how hard it will be for users to list their
extensions and themes. Is there a good way to do this? Will we need to
include instructions? Ideally, this is something sumo could read
automatically, which would require Firefox modifications.
Ray Kiddy
I think that the "Are you currently using the Firefox instance that
you're having problems with?" should be a radio button. I would be
afraid to push the button and have the stuff I might have written
cleared or submitted before I was ready.
The FF version and OS versions should be menus and have the same options
as in bugzilla.
Either we should ask for all the info we will need about the plugins,
themes and extensions, or we should get it automatically. Since we would
need to ask for all the version numbers and whether things are enabled
or not, this is not workable. We either need to get this automatically
or not at all.
The rest of it looks ok, though it needs some white space. The lines are
a bit too crowded together.
- ray
David Tenser
> the KB being referred to is the SUMO kb, not the mozillazine kb.
>
> An admin forum, where we can discuss policy and what to do about certain
> issues would be a good idea, but I don't think we'd benefit from it
> being admin *only.* If users can see *why* we agreed on a course of
> action, they can respect it. Certainly we wouldn't want it to be user
> facing, to keep down clutter, but I don't think we'd want to restrict
> anyone from seeing it who would want to. Jason may feel differently,
> but that's my take. Anything supersensitive should probably happen in PM
> anyway.
Absolutey, I agree 100% here. Let's keep communication transparent
whenever possible.
> I agree that bugzilla should have lots of links to sumo, but we
> definitely shouldn't make it the other way around. Part of our job as
> support providers, IMO will be to help people file useful bugs. If
> people don't know how to use bugzilla we shouldn't "cold transfer" them.
> Preferably we file the bug for them once we have all the info needed,
> and then cc them to it, or walk they through what info to provide.
I agree here too. The aim should always be to help our users as much as
possible.
/ David