|
|
| Line 1: |
Line 1: |
| | + | |
| | + | |
| | + | |
| | + | |
| | [[ Apache OpenOffice User Experience|< AOO User Experience Home]] | | [[ Apache OpenOffice User Experience|< AOO User Experience Home]] |
| | | | |
| Line 14: |
Line 18: |
| | | | |
| | *[[Media:UX_Merge_Assessment_-_Dockable_Task_Pane_-_1.1.odt|UX Merge Assessment - Dockable Task Pane - 1.1.odt]] | | *[[Media:UX_Merge_Assessment_-_Dockable_Task_Pane_-_1.1.odt|UX Merge Assessment - Dockable Task Pane - 1.1.odt]] |
| − |
| |
| | | | |
| | ==Design Exploration== | | ==Design Exploration== |
| Line 20: |
Line 23: |
| | How might we make high frequency actions and options more available and discoverable within the editor's primary workspace so that user's can access advanced editing commands from a persistent, contextual, mode-less property panel. | | How might we make high frequency actions and options more available and discoverable within the editor's primary workspace so that user's can access advanced editing commands from a persistent, contextual, mode-less property panel. |
| | | | |
| − |
| |
| − |
| |
| − | We can think of them as insight, the problem or opportunity that motivates the search for solutions; ideation, the process of generating, designing, developing, and testing ideas; and delivery, the process of generating design work products and deliverables, including detailed design guidance and recommendations, to serve as an input into development's implementation activities.
| |
| − | =====Exploration-oriented=====
| |
| − | The reason for the iterative, nonlinear nature of this approach is not that design and development is disorganized or undisciplined, but that design and development is fundamentally and exploration process. When done right, it can invariably make unexpected discoveries along the way, and it would be foolish not to find out where they lead. Often these discoveries can be integrated into the existing products without disruption. At other times the discovery can motivate our community to revisit some of our most basic assumptions.
| |
| − | ==Opportunity backlog==
| |
| − | =====Starting point=====
| |
| − | Unlike a product road map or release plan, which traditionally seeks to map specific proposed features to a schedule, an opportunity backlog is collection of insight and opportunities discovered throughout the project life cycle which serves as the starting point for further product innovation (research and design).
| |
| − |
| |
| − | =====Insight-driven=====
| |
| − | Opportunities in the backlog can come from anywhere -- AOO certainly has no shortage of sources for user feedback and product insight. To focus efforts, a backlog should also seek to prioritize our design and development explorations to align with our broader product vision and community goals. The opportunity backlog is a snapshot of UX-oriented insight and opportunities for improvement, as identified through our research and feedback activities. Backlog serves and a pool of exploration candidates.
| |
| − |
| |
| − | ==Format==
| |
| − |
| |
| − | =====Title=====
| |
| − |
| |
| − | A backlog item should have a brief title to describe the item. Anything works, as long as it makes sense. It could be in the form of a question, a comment or even a user story. No wrong answers.
| |
| − |
| |
| − | =====Brief=====
| |
| − | The opportunity brief is the classic starting point of any project. Brief is the backlog item description. Almost like a scientific hypothesis, the brief is a set of attributes that give the project members a framework from which to begin, and a set of objectives to be realized. The brief is not a set of instructions or an attempt to answer a question before it has been posed. Rather, a well constructed brief will allow for serendipity, unpredictability, and the whims of fate - for this is the creative realm from which break through ideas emerge. If you already know what you are after, there is usually not much point in looking.
| |
| − |
| |
| − | Opportunity backlog item brief should include seek to describe:
| |
| − | * What problem are we trying to solve? (why are we doing this)
| |
| − | * Who are we trying to solve this problem for? (target persona or user)
| |
| − | * How will we know if we succeed? (what is the outcome we are hoping for
| |
| − |
| |
| − | ==Backlog drives design exploration==
| |
| − | =====Ideation=====
| |
| − | Through ideation (design and development explorations), we can untangle the initial ideas or assumptions about the solution from the problem that this feature is intended to solve. The reason this is so important to do is that so often our initial attempts at solving the problem don't pan out, but the problem still remains. We want to make sure we solve the problem, even though we may have to try several different features or approaches. Ideation is about opening up and closing down. It is about opening up the possibilities to creative thinking, exploring the future potentials, generating ideas from many different perspectives, stretching the context and exploring the extremes. It is then about closing down, focusing in on the best ideas, evaluating them in terms of user and community needs, and driving an informed design decision. Once an idea is ready for feedback, it can be shared with the community for discussion on the mailing list.
| |
| − | =====Delivery=====
| |
| − | When an idea or design enhancement has been discussed on the mailing list and has been updated to reflect community feedback, it can be promoted as a formal enhancement proposal. If successful, the enhancement would be created in Bugzilla and included in the product roadmap. Around the same time, design work products and deliverables, including detailed design guidance and recommendations, could be to serve as an input into development's implementation work. Once implement, the item would be removed from the UX opportunity backlog.
| |
| − |
| |
| − |
| |
| − | ----
| |
| − | ----
| |
| − |
| |
| − | INSERT LIST OF OPP BACKLOG HERE - Create tables clustered by themes
| |
| | | | |
| | <br> | | <br> |
| | | | |
| | [[Category:UX]] | | [[Category:UX]] |
Both LS and AOO currently provide task-oriented views which allow users to surface common actions. The task views can either be rendered as floating views, or as docked sidebar panes. While the basic window management is similar between the offerings, other aspects of the user experience are significantly different. Differences include: content, default presentation, and navigation.
AOO surfaces the dockable task panes as floating windows which the user can choose to dock on the side of the work space. All task panes are hidden by default, and only emerge when the user evokes the view command. Each task panes is independent from each other. The number of panes and content available in the panes is limited. See analysis for more information.
LS surfaces the dockable task panes as a docked sidebar views, with supporting navigation tabs. By default the tabs are closed in the document and spreadsheet editor, and open in the presentation editor. The presentation editor also includes a similar slide view. LS offers a rich set of panes and supporting content. See analysis for more information.
In support of the Lotus Symphony 3.0.1 (LS) and Apache OpenOffice 3.4 (AOO) code merge activity, Apache OpenOffice UX has prepared the following user experience merge assessment. The outcome of the assessment is an understanding of which aspects of the dockable task pane user experience should be migrated or merged from each offering into the new code base.
How might we make high frequency actions and options more available and discoverable within the editor's primary workspace so that user's can access advanced editing commands from a persistent, contextual, mode-less property panel.
