- 1 Intro
- 2 WHY?
- 3 PRIOR CONSIDERATIONS
- 4 THE STRUCTURE OF USER DOCUMENTATION PROPOSAL
- 5 HOW DO WE DO IT?
- 6 End?
As the plans for TB3 are settling down more and more, I propose a structured idea about the user documentation, help and support for Thunderbird 3. [Note that this regards also the Calendar, at least as Lightning. So when I say mail or Tb or momo, please consider also the calendar integrated.]
I intend to get the attention on this side of the user experience and invite MoMo to at least decide on intentions on help, if not to actually define a plan and set some goals for mid to short term perspective. I hope to establish what we want and what we can do in time for 3 release. This will be subject to discussion in dev group or other places.
This normally is not about more load on the developers side and coding and is more about content and organizing it. Which makes me think could be kind of a parallel process with no need to prioritize against or despite other dev goals and resources.
Why? Email is broken. If you ask someone bout mail the answer is "it's ok, what more?" Well, we all agree there could be so much more. I'm trying to say here kinda same about "help". Is there more to it? sure thing ..
- Open soft is different in the way relation with users take place and "You're on your own" is the feeling is often here.
- The ideal support case is person to person, which in open soft is less probable to happen aside from forums and groups where users help users
- Somehow I find documentation as well as guides, models, presets or other resources very much lacking in open software. (extensions may be exception, but that is another discussion)
- Various contributions are spread around web in many forms and many versions leading to some entropic effect
- Contributors are naturally attracted in certain areas resulting in points or features not covered or poorly addressed
- The reliability of the sources is usually hard to determine, ratings or other ranking missing or based on few reviews
- Mail and communication deals with some procedures that are not so simple (i.e. compared to browsing) and with sensitive data. Thus users are more in need of guidance.
- Mail needs setup, data management and storage, reliability
- Mail is hard to migrate, definitely not like opening in another app if not convenient
- Mail and communication is more about offline and sync and the guidance needs are accordingly different
- Specifically on Thunderbird (and calendar) this is another area mostly ignored
- TB is lacking the very basic content of help to date, the rest being kinda fragmented all over the place IMHO (see links below for work done)
- There is always Mozillazine, but in that some areas get treated in detail while some features are still missing
- There is a great community giving support in forums and news groups. Still, people seam to get hard the appropriate place for their issues. Not to mention some are rather not responsive (wishes, hendrix?)
- I see user docs, help and guidance as very important part of the user experience, communication with users, presenting the product
- Overall improvement of User Experience may need guidance(following some momo goals ..)
- Increase the friendliness and reliability of the product, at least in perception. Adds to a mature "complete pack" image
- Invite people to features and exploration (extensibility, community).
- Part of the issues will find easy solutions unloading some support groups and forums and also bugzilla
There may be more ..
here are some links about works done till now: (to do)see wiki page above Help content Help Viewer extension Some bugs
This could be very well about a general moz help project, sumo etc. I'd prefer to derive it from TB/cal/AB product than make a general thing out of it, cause: *I do believe in the differences there and
- I do not believe in support as being a separate thing from a product.
(I'm not that familiar with sumo and the intentions there, also.)
or how to look at this
This viewpoint is presented with more detailed descriptions and mockups. It presents my vision on this and is supposed to be a starter. So:
- Do consider this as open as possible and if the result is a completely different thing, I have no problem with it, as long as it is really helpful to the main product and UX. (I'm used to not fall for my own ideas and shift if needed, dayjob thing ..)
- Some considerations may need further explanation to be complete. Respective links will be placed with examples or other specific details.
- You'll find in the page above this some comments on how the state of support resources are now (my limited opinion) and some links to various resources
- There are areas still fuzzy on features and specific stuff. I do not consider necessary to discuss them immediately. Not to get lost in details. Some may be updated later. (again with respective links)
As we talk about support, we have to consider all kinds of users:
- Please see this detaching from personal approach. Usually here end up advanced users, not to mention wiz and gurus. Try to think this for your granny or for a child or for someone that is not used to computers much or doesn't care for comp insight.
- Good idea is to "consider your customers [users] as very intelligent, but very busy"
- Try to think about the differences Tb vs Ff. There is always a temptation to relay on Ff. And it's ok, but I'm interested precisely in the difference
One thing not described there is the actual UI and implicit UX, which is the first step in helping the user, with self explanatory, intuitive etc features and also efforts like the current account setup automation fall under the same intention.
Ideal software is so natural and intuitive that one doesn't need any support. Until then :) set's see..
THE STRUCTURE OF USER DOCUMENTATION PROPOSAL
Please consider this schematic image. I'll try to focus on the main ideas and describe the detailed features later.
The main idea is to have a documentation (center) and have a way to manage it online and offline in a way that allows easy communication with user. In the right, I place the things that user may get from web in a structured way, so that one takes what needs and finds them integrated. In the left I place the feedback processes, where users need to post/put questions, share stuff, add to community and eventually contribute.
First, let's look at the center 3 elements
HELP AND STUFF
In the center you see it divided in 3 areas, "Help", "User Docs and Guides", "Support"(+Feedback?) arbitrary names I picked
- basic content and specific issues solutions,
[-e.g. on tags we may describe options, taging, on views etc] -this is probably essential to have as a complete as possible and as base for further talk. One has to have the reference to a specific menu etc if to talk generally about some features. Here's the work for now
Having reasonably complete Help Content is probably the biggest challenge. Today we have some here. http://wiki.mozilla.org/Thunderbird:Help_Documentation:Outline http://wiki.mozilla.org/Thunderbird:Help_Documentation:Base ( http://ilias.ca/blog/2007/04/please-help-with-thunderbird-options-documentation/ ) People contributing to that and others are not around much. I was thinking for a start, to try and fill in by asking in the support ng and putting them there myself. Thinking this may: attract some other people to contribute there, have the answers already available in ng and gg, thus findable independent of the success of content filling, getting more feedback on the approach. And some are in kb / mozillazine.
So, I'm thinking a start from the Tb2 way (already there) will do, even if it is about 3. Easy to update and change along, anyway.
User Doc and Guide
- more general guidance for features, approach in context
[-e.g. on tags we may talk about how they work, managing data and views, models for usage etc] -I do consider this as essential to make sense out of detailed features and menu items. And may find some in mozillazine, more or less related to specific features or problems.
Guidance and User Documentation can be considered starting from "Getting started", "Get organized" proposals, tips and tricks, general functions and ways etc. up till proposing usage models and templates.
Same issues arise here, though I would apply same action, by asking supporters for models, usage ways etc .. And encouraging people to provide templates and other resources along with/aside addons.
More on this in the guides area or in the usage models area. Another example could very well be http://opensourcearticles.com/thunderbird_15/english/part_01
- Direct interaction, q & a, as in ng and forums
[-e.g. on tags we may try to take the user through a guided approach so that will land in the right place for asking] -people are still confused about proper groups or places to ask for q, rfe present ideas etc ..
I'll talk less on this as it is a whole new range of things. I'll just say there are several places to look at and some ideas in the feedback and putting in a sys that cover this.
The main idea is to guide people towards -the proper place to ask -the proper way to ask for rfe /let's guide them, see in help, ask in support, see some extensions, eventually RFE (bugzilla) -the guided way to determine a problem, test it, ask about it and eventually file bug -feedback that counts -sharing and maybe even getting involved
VIEW AND MANAGE
Content, structure, system (right side and bottom in picture ..) This may be the most interesting one. How much online/offline? How to make things more integrated?
Structuring the user docs
[This is one key idea that I would like to debate ..] Should be as simple as using category or tags. This essentially will solve updating issues, integration of extension help and info, contextual approach, maybe even customization from user side. Well, wiki now does some but is just a crude instrument or workaround. And sumo may be of an example.
Nothing new, really, but I stress on this for the following model: -Help could provide general guide, particular solution, add some extension help paragraphs when present, propose extra functionality with link to some amo or others, show inside links vs external reference, eventually ask your opinion or explain about bugzilla etc. -This should insure also separate updating, external resources, etc
The example mockup lays here for some Amo like thing.
Online and offline
[This is another key idea that I would like to debate]
This seams another issue to establish according to aims and possibilities.
I would consider same content to be available more or less on both sides. Maybe with the ability to customize what to download and what not. Meaning that some content we may consider necessary while extra stuff can be downloaded by user (and fall inline local paragraphs)
In this way, extensions may add their content in proper place. This may be essential for calendar or other big feature pack extension. Also, some reference to extensions would show users what features can be extended and invite them to explore that part.
! Essentially I think of this similar to the amo/extension manager window, but where some are already locally available and some are "loading". On a simpler basis, this could be only an option to dld help for offline, thus not making it available in the original pack but afterwards.
What kind of viewer would this offline need?
- A separate viewer pane/window?
- A special tab (special as color of header and as navigating only inside help files not interact with msg)
- An extension? see .
- Directly inside Addon manager? with panel resizing accordingly ..
This is not just a viewer thing, though it does have advantages. I think of it also as presenting updates available amo style, and also cause is a technology already there.
Another idea would be that, eventually, amo, templates/models, and support resources may become more integrated. As "resources" or something. In fact those are all extra resources for usage and usability .. See this mockup in this respect to Resources. I do think that this will really invite people to see the extensibility in Tb and the community around it. Which is the very difference to other soft and is still not exploited enough.
(As a future work, this may even go further for resources available on local machine, on lan!, on web. But this is already complicated and it may be better to think of when corporate issues come into attention ..)
CONTEXT AND ASSISTANCE
Help should be contextual, depending on what you do and where you are. And other resources could be available contextually the same. See the discussions on the templates creation for precisely this idea bug wiki or the acc setup works.
- Simple "?" aside some panel or aside areas will do. But also this could lead to having link to "resources", like "?", "extensions", and "templates" i.e.
- All in all, the context regards triggers from various areas in TB UI to get related assistance, but also tagging content so that extension and other pieces of content fall in the right place inside User docs.
- Bugs and feedback may benefit from this too. These may be interesting and helping.
- this is still fuzzy, but I would consider some guidance here
- A template or other material will always add some understanding of the logical approach.
- templates and usage models may come with some presets or resources, or may allow you to create your own from fresh or starting from a model
FEEDBACK AND SHARE
- In the left side of the picture
less to talk here, I think. This is aiming generally to gather user feedback in a more effective way. Could cover:
- about/future of communication etc
- news and stuff to keep people interested or even involving..
- give thoughts - hendrix today
- Rfe and ideas -guided "support to bugzilla" thing. but treated differently than issues.
- Problems and testing -guided "support to test to bugzilla" thing. To ease and guide the way to buggy.
- Easier sharing of templates, signatures or other resources
- this could be subject for yet another part of amo
This may also be about getting in touch with the community. Posting templates with ease after "creating your own" is one thing, but discussing it is gonna get it better. Posting or linking to or rating some useful material may just be the first step in contributing.
PUTTING IN A SYSTEM
- GATHER, TAG, RATE ..This is about the left side but mostly the top of the pic.
And is less to discuss about maybe, as it is rather about how to better index the resources out there, for help and others.
I was basically thinking of a "TB connector" or "TB context" (or MoMo connector) widget for net. Either a thing to publish that people can put on their site [along with or within] Get TB link or a place where people put links and rate stuff they consider TB related. Aiming to have a tool that makes finding and organizing TB stuff easy rather than try to gather them in one place.
This may go even for good extensions not listed in amo (paolo kaosmos site ..) or to indicate how up to date things are. Or connecting bugs to threads or other forum/groups discussions.
And eventually, having easy access from inside TB would make a difference. Fuzzy and organic soft, organic
This is kinda far thinking and still fuzzy. Let's just say that you are suffering also from splitting discussions and things among different media (wiki, web, blog, bz etc). For now It may only contain things that are already Amo, mozillazine and maybe couple more.
HOW DO WE DO IT?
I would like to establish here what is appropriate and feasible and how to proceed.
- First we should agree on what make sense and what not. Or to separate long term from short term goals. The level of importance of this user docs is also subject.
- The approach and the correct place to take discussion, action etc is the next subject.
- correct me about place and way for such help planning.
- And how much is MoMo and much Moz? (this is more or less related to the future web sites division and resource placement)
- I also had a bugzilla scheme with about 30 bugs and relations, but that is not a way (the horror..), not to consider cross product etc.
- this spans cross moz/TB/calendar web pages area and products themselves. Which I'm not sure I follow now as divided work. ]
- The features of online/offline approach are a key subject to make this more than usual help files (more or less used). I would like to draw some conclusions on such even if they will land later than Tb3. I could very well proceed in pieces, asking for AMO to host templates etc as described or to gather/index them, but this is more about the big picture.
- How to make it easier for contributors?
- People may find this not only hard, but also a computer/geek thing. So they may just pass by without even thinking of such contribution needed.
- Also this is related to extension developers and how extensions are promoted and integrated.
- And eventually, what is your experience with users, usage, help etc? What do you consider necessary, useful, fancy or trouble?
Well, I try to take into account the things already under work and focuses, but on a limited perspective. So please indulge.
I also consider the limited time some contributors may have and thus try to open this now rather than later.
thank you and hope this will lead somewhere and not wasting your time and concentration
- ov 12:42, 15 July 2008 (PDT)