Difference between revisions of "HowTo Request User Experience Assistance"
From Apache OpenOffice Wiki
Lutz Hoeger (Talk | contribs) m |
(→What can you expect from UX?) |
||
| (17 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
{{User Experience}} | {{User Experience}} | ||
| − | ''' | + | == Why work with User Experience? == |
| + | A good user experience is critical for the success of OpenOffice.org (OOo). User experience (UX) engineering '''advocates the user perspective''' by providing insights to the user’s mental model. Within the development process, UX can take on a variety of tasks, from '''UX design''' (interaction, user interface (UI), graphic design, layout, terminology), through '''usability evaluations''' (requirements engineering, competitive analysis, heuristic evaluations, usability studies), up to '''Human-Computer Interaction (HCI) research''' (HCI know-how, UI style guides, usability metrics). | ||
| − | + | Involving UX '''as early as possible''' in the development cycle helps you to '''design with the user in mind''' right from the beginning. | |
| − | * | + | == When '''''do''''' you need UX? == |
| + | Some changes have a '''high impact on users'''. We strongly advise you to include UX into the development of such features or issue fixes. Here are some general examples for these features: | ||
| + | * Changes to the '''"first impression" part of the UI''' (overall appearance, main menu, tool bars, standard shortcuts) | ||
| + | * '''Work flow''' changes (introducing new work flow steps, dialog boxes, error messages, streamlining the work flow) | ||
| + | * Changing '''default settings''', in particular if this affects one of the two above | ||
| − | + | == When do you '''''not''''' need UX? == | |
| − | * UI | + | Changing the UI does not necessarily mean that UX engineering needs to be included. For changes that have '''lower impact on users''', you can often apply common HCI guidelines by yourself. Here are a few examples for changes, where you do not need to include UX engineering: |
| − | * | + | * Changes to '''"well hidden" parts of the UI''', like the "more"-part of a rarely used dialog. |
| − | * | + | * Changes that have '''already been designed''' (or sketched out well) in a related specification document. |
| + | * Changes for which you '''know how to apply [[User_Interface_Guidelines|HCI or UI design guidelines]]''' on your own. | ||
| + | == How to contact UX / how to request assistance == | ||
| + | There probably never are as many [[User_Experience_Community|UX engineers]] as there are development engineers, so we need to dispatch UX requests efficiently. The good news is, that all tools are in place (Issue Tracker, mailing lists), and most people in the OOo community are used to use them. | ||
| + | '''When you need UX assistance''', or even when you want to know, if you need UX assistance, | ||
| − | + | '''send an e-mail to mailto:request@ux.openoffice.org'''. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | == What UX needs from you == | ||
| + | Your e-mail needs to include at minimum: | ||
| + | * The '''issue ID''' of the issue you are working on. | ||
| + | *: The easiest way to do this, is to add the e-mail address request@ux.openoffice.org to the cc: list of your issue. | ||
| + | If your request originates from an issue filed in OOo Issue Tracker, the following information should be included into the issue description. If there is no issue yet, include it into your e-mail. | ||
| + | * Brief description of '''what''' you want to change / what your patch changes, | ||
| + | * Very short statement '''why''' you (want to) change this, | ||
| + | * If your change affects the UI, ideally provide a '''mock up''' - if you actually provide a patch that affects the UI, instead, include a '''screen shot''' of your patch in action, | ||
| + | * The name of the '''Child Workspace (CWS)''', if your issue is associated with one, | ||
| + | and, last but not least: | ||
| + | * '''Clearly state which action you request from UX.''' | ||
| + | Additionally - but this is entirely optional - you may provide a URL to an install set (preferably Windows, but Linux/MacOSX/Solaris works, too) where one could evaluate your patch in action. | ||
| − | + | == What can you expect from UX? == | |
| − | * | + | * For issues, the normal response will be, that someone from the [[User_Experience_Community|UX community]] '''replies within the issue''' (if there is just one simple question), or asks to assign the issue to themselves in order to work on it. |
| − | + | * For e-mails not attached to any issue, your request may be forwarded to the mailing list mailto:discuss@ux.openoffice.org for further discussion and an answer. | |
| − | * | + | * If there is no UX engineer available to help you with your request, we will let you know as soon as possible. |
| − | + | When can you expect an answer? | |
| − | * | + | * Ideally, you will get an initial response immediately, i.e. within a few hours. However, the normal turnaround time likely will be '''up to a few days''' (depending on local work hours). |
| + | * If you don't hear back from us within this time frame, you may want notify the UX project via our main mailing list mailto:discuss@ux.openoffice.org. (This is an optional step, just in case your initial e-mail got lost.) | ||
| + | * If after two weeks, you don't hear back from us, it is fair to assume that the change suggested is not critical from our point of view, so you can just proceed without our input. | ||
| − | + | [[Category:How to]] | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 13:10, 1 August 2007
|
|
|---|
|
Quick Navigation Team Communication Activities |
Contents
Why work with User Experience?
A good user experience is critical for the success of OpenOffice.org (OOo). User experience (UX) engineering advocates the user perspective by providing insights to the user’s mental model. Within the development process, UX can take on a variety of tasks, from UX design (interaction, user interface (UI), graphic design, layout, terminology), through usability evaluations (requirements engineering, competitive analysis, heuristic evaluations, usability studies), up to Human-Computer Interaction (HCI) research (HCI know-how, UI style guides, usability metrics).
Involving UX as early as possible in the development cycle helps you to design with the user in mind right from the beginning.
When do you need UX?
Some changes have a high impact on users. We strongly advise you to include UX into the development of such features or issue fixes. Here are some general examples for these features:
- Changes to the "first impression" part of the UI (overall appearance, main menu, tool bars, standard shortcuts)
- Work flow changes (introducing new work flow steps, dialog boxes, error messages, streamlining the work flow)
- Changing default settings, in particular if this affects one of the two above
When do you not need UX?
Changing the UI does not necessarily mean that UX engineering needs to be included. For changes that have lower impact on users, you can often apply common HCI guidelines by yourself. Here are a few examples for changes, where you do not need to include UX engineering:
- Changes to "well hidden" parts of the UI, like the "more"-part of a rarely used dialog.
- Changes that have already been designed (or sketched out well) in a related specification document.
- Changes for which you know how to apply HCI or UI design guidelines on your own.
How to contact UX / how to request assistance
There probably never are as many UX engineers as there are development engineers, so we need to dispatch UX requests efficiently. The good news is, that all tools are in place (Issue Tracker, mailing lists), and most people in the OOo community are used to use them.
When you need UX assistance, or even when you want to know, if you need UX assistance,
send an e-mail to mailto:request@ux.openoffice.org.
What UX needs from you
Your e-mail needs to include at minimum:
- The issue ID of the issue you are working on.
- The easiest way to do this, is to add the e-mail address request@ux.openoffice.org to the cc: list of your issue.
If your request originates from an issue filed in OOo Issue Tracker, the following information should be included into the issue description. If there is no issue yet, include it into your e-mail.
- Brief description of what you want to change / what your patch changes,
- Very short statement why you (want to) change this,
- If your change affects the UI, ideally provide a mock up - if you actually provide a patch that affects the UI, instead, include a screen shot of your patch in action,
- The name of the Child Workspace (CWS), if your issue is associated with one,
and, last but not least:
- Clearly state which action you request from UX.
Additionally - but this is entirely optional - you may provide a URL to an install set (preferably Windows, but Linux/MacOSX/Solaris works, too) where one could evaluate your patch in action.
What can you expect from UX?
- For issues, the normal response will be, that someone from the UX community replies within the issue (if there is just one simple question), or asks to assign the issue to themselves in order to work on it.
- For e-mails not attached to any issue, your request may be forwarded to the mailing list mailto:discuss@ux.openoffice.org for further discussion and an answer.
- If there is no UX engineer available to help you with your request, we will let you know as soon as possible.
When can you expect an answer?
- Ideally, you will get an initial response immediately, i.e. within a few hours. However, the normal turnaround time likely will be up to a few days (depending on local work hours).
- If you don't hear back from us within this time frame, you may want notify the UX project via our main mailing list mailto:discuss@ux.openoffice.org. (This is an optional step, just in case your initial e-mail got lost.)
- If after two weeks, you don't hear back from us, it is fair to assume that the change suggested is not critical from our point of view, so you can just proceed without our input.
