Design/Kick-Off/WhatWeNeed

Introduction
This page is intended to collect thoughts what the Design Team might need, or what it has to provide to be fully operational for Usability and User Experience Design, and Visual Identity Design. So did you miss something until now (e.g. how to request help from the Design Team, knowing what the Design Team is about, requiring documentation, missing ideas about future versions of LibreOffice, wanting to contribute within the Design Team)? Do you have insight that worked well for other FLOSS design teams? Then, please tell us!

Please consider:


 * This collection is about best practices, methods, tools and documentation.
 * It is not about the change of work products (e.g. refine the logo, change the icons, ...)
 * The first two steps are about brainstorming - so please withhold criticism at the beginning (see ).

The proposed steps and a rough time estimation:


 * 1) Brainstorming by the Design Team (7 days)
 * 2) Brainstorming by the other teams (4 days)
 * 3) Filter and cluster the outcome (4 days, we'll need task owners here)
 * 4) Ask for final agreement by the Design Team (2 days)
 * 5) Announcing the work to the public (1 day, e.g. via blog posting)
 * 6) Transform the topics / groups to work items (3 days)
 * 7) Work on it ... (again, we'll need task owners here)

What We Might Need
{| class="wikitable sortable" ! Short Name ! Task ! Description / Ideas / Examples ! Source ! Status ! Importance / Urgency ! Owner ! Comments / Proposed Structure
 * colspan="8" |
 * colspan="8" |

Design Team Community

 * Joining the Design Team
 * Prepare information and easy problems to start with for people joining the Design Team
 * Prepare information on how to join, what to expect, how to contribute, the team structure... (OOo counterpart: OOO UX How to Join
 * Create a collection of "Design Starters" to start working on (similar to the Developer Easy Hacks
 * Update the "Get Involved" website pages
 * Create a collection of "Design Starters" to start working on (similar to the Developer Easy Hacks
 * Update the "Get Involved" website pages


 * Christoph, Bernhard
 * Undecided
 * i
 * o
 * Christoph: For a growing Design Team community, it is essential to have good information
 * Christoph: For a growing Design Team community, it is essential to have good information


 * Understanding Design Team Topics
 * Create and publish material to spread the news about the Design Team
 * Create a good Design Team start page in the wiki (OOo counterpart: OOO UX Team)
 * Collect and answer Design Myths
 * Define "real" areas of expertise for the members (e.g. improving the Team Page)?
 * Collect and answer Design Myths
 * Define "real" areas of expertise for the members (e.g. improving the Team Page)?


 * Christoph
 * Undecided
 * i
 * o
 * Christoph: Currently, most people still think about "Design" as doing graphics; but its also related to visual identity, usability, user experience and such stuff.
 * Christoph: Currently, most people still think about "Design" as doing graphics; but its also related to visual identity, usability, user experience and such stuff.


 * Promote the Design Team
 * Publish information on the Design Team and interact with other teams to improve the understanding
 * Create a Design Team logo and clarify its use with the steering committee
 * Collect quotes / reference designs from known organizations (especially in the FLOSS world)
 * Blog about recent developments within the Design Team
 * Take part in one of the regular "Developer" interviews
 * Blog about recent developments within the Design Team
 * Take part in one of the regular "Developer" interviews


 * Michel, Christoph
 * Undecided
 * i
 * o
 * Christoph: The page OOo UX External Communication might be helpful.
 * Christoph: The page OOo UX External Communication might be helpful.


 * colspan="8" |
 * colspan="8" |

Goals and Roadmap

 * Goals for the Design Team
 * Set the foundations to make the work more engineering like
 * What is the vision behind the project LibreOffice (the ultimate goal)?
 * What are the chances to make the project smaller (e.g. divide it into different projects each with more focussed target audience)?
 * Who are our users? Who are not?
 * What do want LibreOffice to be used for? What don't we want LO to be used for?
 * What do want working with LO to feel like?
 * In which situations do we want LO to be used?
 * What do want working with LO to feel like?
 * In which situations do we want LO to be used?


 * Björn, Michel, Christoph, Bernhard
 * st
 * i
 * o
 * Christoph: This also related to the product strategy which should be discussed with the Marketing guys.
 * Christoph: This also related to the product strategy which should be discussed with the Marketing guys.

Examples:
 * Short Term Improvements
 * Clarify what we can improve in and how we can improve LibreOffice in the short term
 * Clarify what we can improve in and how we can improve LibreOffice in the short term


 * Helping with the developer's Easy Hacks
 * Driving own initiatives (e.g. collecting usability issues)
 * Focusing on smaller areas (color management, ...)


 * Christoph
 * Undecided
 * i
 * o
 * c
 * Roadmap
 * Create a roadmap and clarify with the development whether it fits
 * Roadmap for the Design Team being based on prioritized goals (see "Goals for the Design Team")
 * Johannes
 * Undecided
 * i
 * o
 * Johannes: Goals should be to ensure a coherent evolution of LibreOffice in the next years.
 * Johannes: Goals should be to ensure a coherent evolution of LibreOffice in the next years.
 * Johannes: Goals should be to ensure a coherent evolution of LibreOffice in the next years.


 * colspan="8" |
 * colspan="8" |

Activities and Work Items Handling

 * Find Areas of Involvement
 * Identify and prioritize areas of involvement for the Design Team
 * Product improvements (work on bugs, create missing tango icons, ...)
 * Website improvements
 * Marketing material improvements
 * Website improvements
 * Marketing material improvements


 * Christoph
 * Undecided
 * i
 * o
 * Christoph: It seems that the few members currently help wherever possible, but this decreases the focus and the efficiency. If possible, we should find a way to focus on the most important items (e.g. helping to shape the international website to have a reference for all local teams)
 * Björn: How can we evaluate the current state of the project in order to find the issues we need to improve?
 * Björn: How can we evaluate the current state of the project in order to find the issues we need to improve?


 * Regular Design Tasks
 * Identify and handle regular design tasks
 * Support the creation of LibreOffice major release material (e.g. update new features graphics)
 * Support the creation of LibreOffice major release material (e.g. update new features graphics)
 * Support the creation of LibreOffice major release material (e.g. update new features graphics)


 * Christoph
 * Undecided
 * i
 * o
 * c
 * Design Task Tracking
 * Clarify how to track running design tasks
 * Clarify what kind of status tracking / overview is desired by the Design Team (issue tracker, wiki, ...)
 * Improve the work items page and / or merge with other status tracking page
 * Clarify the kind of organization of design tasks (by delay, type, form factor, user, difficulty, importance)
 * Improve the work items page and / or merge with other status tracking page
 * Clarify the kind of organization of design tasks (by delay, type, form factor, user, difficulty, importance)


 * Christoph, Michel
 * Undecided
 * i
 * o
 * Christoph: Currently, the Work Items page seems updated rarely.
 * Christoph: We have to make sure that no important work items gets lost ... or is silently dropped by a task owner.
 * Christoph: We have to make sure that no important work items gets lost ... or is silently dropped by a task owner.


 * colspan="8" |
 * colspan="8" |

Knowledge and Requirements

 * Know Our Users
 * Get data / information for design decisions
 * Use e.g. polls at Facebook or other social media to back-up decisions (structured and regular surveys)
 * Re-introduce the User Feedback Program infrastructure
 * Use e.g. polls at Facebook or other social media to back-up decisions (structured and regular surveys)
 * Re-introduce the User Feedback Program infrastructure


 * Bjoern, Christoph, Michel
 * Undecided
 * i
 * o
 * c
 * Make Users Visible
 * Make users visible in the development and decision process
 * Persona / user groups development
 * Make interviews with new users (e.g. from user list)
 * Work on a brainstorming infrastructure (see: OpenOffice.org Idea Handling)
 * Make interviews with new users (e.g. from user list)
 * Work on a brainstorming infrastructure (see: OpenOffice.org Idea Handling)


 * Bjoern, Christoph
 * Undecided
 * i
 * o
 * c
 * Care about Branding Requirements
 * Update and LibreOffice branding and care about its use
 * Initial update of the branding requirements and resources (see the Branding Open Points List)
 * Regular update of the branding requirements and resources
 * Make sure that the branding requirements for (community) material is met and clarify how to do this
 * Develop guidelines / descriptions for all officially approved design elements
 * Make sure that the branding requirements for (community) material is met and clarify how to do this
 * Develop guidelines / descriptions for all officially approved design elements

Bernhard, Christoph


 * Undecided
 * i
 * o
 * Bernhard: The main goal is to allow designers and artist to work on new ideas and designs in a way consistent to our general branding design.
 * Bernhard: The main goal is to allow designers and artist to work on new ideas and designs in a way consistent to our general branding design.


 * Clarify Marketing Questions
 * Collect, clarify and document fundamental questions (with e.g. marketing) that will have impact on our work (and some other parts of the project)
 * Examples:
 * "Single applications" (Writer, Calc, Impress, ... like in OpenOffice.org) vs. "One Office" (LibreOffice like Lotus Symphony)
 * Follower" (mimic known office suites to ease transition) vs. "Independence" (decide to support our users in the best possible way)
 * "Platform specific" (respect the platform interaction guidelines ... e.g. like Mozilla Firefox) vs. "Platform independence" (work the same way on any platform ... e.g. like web sites)
 * "Platform specific" (respect the platform interaction guidelines ... e.g. like Mozilla Firefox) vs. "Platform independence" (work the same way on any platform ... e.g. like web sites)


 * Christoph
 * Undecided
 * i
 * Scott
 * Christoph: Should be documented on a central place, since these questions are raised regularly. (see also "LibreOffice Requirements")
 * Christoph: For some questions, there might be no clear answer - in these cases, at least a general direction should be worked out.
 * Christoph: For some questions, there might be no clear answer - in these cases, at least a general direction should be worked out.


 * Use of Human Interface Guidelines
 * Clarify the use of existing and prepare the creation of own HIG
 * Collect (links to) existing HIG guidelines of the platforms we do support (e.g. Gnome, KDE, Windows, macOS)
 * Clarify the use of the (sometimes) implicit OpenOffice.org Guidelines
 * (If possible) Clarify a reference platform if guidelines differ
 * Clarify with l10n the use of text style guidelines
 * (If possible) Collect common mistakes of our current UI (e.g. feedback by the Gnome team)
 * (If possible) Prepare a structure for own HIG if we need to maintain an own style (rationale: effort for platform specific behavior is too high)
 * (If possible) Collect common mistakes of our current UI (e.g. feedback by the Gnome team)
 * (If possible) Prepare a structure for own HIG if we need to maintain an own style (rationale: effort for platform specific behavior is too high)


 * Christoph
 * Undecided
 * i
 * o
 * c
 * LibreOffice Specifications
 * Develop a LibreOffice Specification Template
 * Clarify how much specification / formalism is required and acceptable
 * Check other projects how they handle it (Ubuntu, OpenOffice.org Specification Project, Fedora ...)
 * Clarify requirements by other teams (e.g. adding hints for QA, terms for the l10n teams, release notes information for Marketing, ...)
 * Develop a specification template and clarify where these specs will be provided and how they relate to other tools (e.g. issue tracker)
 * Document the rationale for using specifications (this question might pop-up regularly) and promote their use :-)
 * Develop a specification template and clarify where these specs will be provided and how they relate to other tools (e.g. issue tracker)
 * Document the rationale for using specifications (this question might pop-up regularly) and promote their use :-)


 * Christoph
 * Undecided
 * i
 * o
 * Christoph: From experience we know, the larger the change, the more important a (more or less extensive) specification (improves communication, preserves decisions, ...).
 * Christoph: From experience we know, the larger the change, the more important a (more or less extensive) specification (improves communication, preserves decisions, ...).


 * LibreOffice Requirements
 * Clarify handling of LibreOffice requirements
 * Clarify how to report and track LibreOffice requirements
 * Björn
 * Undecided
 * i
 * o
 * c
 * colspan="8" |
 * colspan="8" |
 * colspan="8" |

LibreOffice Technical Basis
Frameworks and technical stuff needed:
 * LibreOffice Framework Enhancements
 * Clarify status with the development and ask for improvements concerning the LibreOffice framework
 * Clarify status with the development and ask for improvements concerning the LibreOffice framework


 * Layout Manager to make our dialogs more flexible (important for e.g. localization, platform specific handling)
 * Direct manipulation snippets to provide a fine grained control to users, like outlined at OOo DirectManipulationSnippets or OOo NonModalMessageSystem
 * User Feedback Program that collects data to base our decisions on, e.g. OpenOffice.org_User_Feedback_Program (see also "Know Our Users")


 * Christoph
 * Undecided
 * i
 * o
 * Christoph: Improvement proposals pop-up regularly, who can only be solved (in a reasonable way) if we enhance the framework of both LibreOffice and its development tools.
 * Christoph: Improvement proposals pop-up regularly, who can only be solved (in a reasonable way) if we enhance the framework of both LibreOffice and its development tools.


 * colspan="8" |
 * colspan="8" |

Cooperation and Communication Within the Design Team
A defined way to decide on e.g. officially approved graphics or user experience / usability related questions is required. Ideas:
 * Clarify Decisions Making
 * Clarify how to make quick and transparent decisions
 * Clarify how to make quick and transparent decisions


 * Polls via web infrastructure (e.g. Poll2 Wiki Extension)
 * Decisions via dedicated people (e.g. senior members), similar to the process of reviewing and pushing changes by the developers
 * Veto rights for dedicated members (having deep domain knowledge)


 * Johannes, Bernhard, Christoph
 * Undecided
 * i
 * o
 * Bernhard: Goals should be to have quick, visible, transparent and clear decisions.
 * Bernhard: Goals should be to have quick, visible, transparent and clear decisions.


 * Ideate and Refine Ideas
 * Clarify how to collect and refine ideas and develop (infra)structure
 * An area for collaborative / iterative working on new designs (wiki and mailing list at the moment)
 * A clearly structured place to upload proposals and ideas as basis to work on until they are ready to requesting approval (or to be kept as ideas for future development).
 * An area for collaborative / iterative working on new designs (wiki and mailing list at the moment)
 * A clearly structured place to upload proposals and ideas as basis to work on until they are ready to requesting approval (or to be kept as ideas for future development).


 * Bernhard
 * Undecided
 * i
 * o
 * Christoph: See also "Make Users Visible"
 * Christoph: See also "Make Users Visible"


 * Ease Reviews and Discussions
 * Clarify how reviews and discussions can be simplified via both methods and tools
 * Simplify attachment handling on the mailing list (proposed at: LibreOffice Mail Attachment Service)
 * Application for annotating graphics (similar to what the Fedora Design Team plans: Annotation App)
 * Explain nightly builds (that should be installable side-by-side with the productive LibreOffice version allowing to have a look at all design related patches committed by developers)
 * Application for annotating graphics (similar to what the Fedora Design Team plans: Annotation App)
 * Explain nightly builds (that should be installable side-by-side with the productive LibreOffice version allowing to have a look at all design related patches committed by developers)


 * Michel, Bernhard, Christoph
 * Undecided
 * i
 * o
 * c
 * Improve Communication
 * Clarify how internal communication can be improved
 * IRC channel for continuous availability and instant discussions
 * Regular meetings via phone / IRC for (planned) topics
 * Improve the Design Team wiki structure and content
 * Regular meetings via phone / IRC for (planned) topics
 * Improve the Design Team wiki structure and content


 * Christoph
 * Undecided
 * i
 * o
 * c
 * colspan="8" |
 * colspan="8" |

Cooperation and Communication With Other Teams

 * Product Planning
 * Clarify how to participate in (technical and strategical) planning
 * Regular participation in the developer meetings
 * Regular participation in the marketing meetings
 * Regular participation in the developer meetings
 * Regular participation in the marketing meetings


 * Björn, Christoph
 * Undecided
 * i
 * o
 * c
 * New Tasks
 * Request Design Team Support
 * Wiki page that outlines how to request help (e.g. what to expect, what time will be required, what kind of issues we do care about)
 * Clarify whether the bugtracker can send a status information (e.g. to a mailing list) if an issue (new, existing) is tagged "Design" related
 * Request from developers (regularly?) to contact us on open questions
 * Clarify whether the bugtracker can send a status information (e.g. to a mailing list) if an issue (new, existing) is tagged "Design" related
 * Request from developers (regularly?) to contact us on open questions


 * Björn, Christoph
 * Undecided
 * i
 * o
 * Christoph: Currently, Christoph is listed on Freedesktop Wiki FindTheExpert. Should this be changed?
 * Björn: How can we provide optimal support to developers and other disciplines in their upcoming tasks?
 * Björn: How can we provide optimal support to developers and other disciplines in their upcoming tasks?


 * Running Tasks
 * Report and track running tasks
 * Clarify / add bugtracker keyword and / or component that identifies Design Team tasks (clarify whether Visual Identity Design and UX should be handled separately)
 * Clarify how to deal with the developer's status (direct feedback, bugtracker status changes, daily builds, ...)
 * Clarify / add bugtracker keyword and / or component that identifies Design Team tasks (clarify whether Visual Identity Design and UX should be handled separately)
 * Clarify how to deal with the developer's status (direct feedback, bugtracker status changes, daily builds, ...)


 * Björn, Christoph
 * Undecided
 * i
 * o
 * Bernhard: Knowledge about the developers working on such topics (bugzilla keywords? "UX needed", "UX involved", "Visual design". "UI" ...)
 * Bernhard: Knowledge about the developers working on such topics (bugzilla keywords? "UX needed", "UX involved", "Visual design". "UI" ...)

Examples for information sources:
 * Provide an Easy Hacks Collection
 * Collect, verify and publish Easy Hacks for the development
 * Collect, verify and publish Easy Hacks for the development


 * Mail by Christoph to the discuss@tdf list with some summary Usability Issues ...
 * OpenOffice.org collections (several users provided such collections and documented them in the wiki)
 * OpenOffice.org issues tagged with "requirements" or "usability" (if possible: positively commented by the OOo UX team)
 * Ubuntu 100 Paper Cuts (still unresolved ones related to LibreOffice)


 * Christoph
 * Undecided
 * i
 * o
 * Christoph: Easy hacks are a great way to start both Design tasks and cooperating with development - before we can ask for larger tasks.
 * Christoph: Easy hacks are a great way to start both Design tasks and cooperating with development - before we can ask for larger tasks.


 * colspan="8" |
 * colspan="8" |

Methods and Tools

 * Document Methods and Best Practices
 * Document our methods and best practices
 * How to efficiently present ideas (e.g. text vs. wireframes vs. screenshots)
 * How to efficiently present ideas (e.g. text vs. wireframes vs. screenshots)
 * How to efficiently present ideas (e.g. text vs. wireframes vs. screenshots)


 * Michel
 * Undecided
 * i
 * o
 * c
 * Document Tools
 * Document preferred tools
 * Document tools and highlight preferred ones (partly done via Tools page)
 * Document tools and highlight preferred ones (partly done via Tools page)
 * Document tools and highlight preferred ones (partly done via Tools page)


 * Christoph
 * Undecided
 * i
 * o
 * c
 * Quality of the Design Team Work
 * Clarify how to meet the different kinds of quality
 * Accessibility --> Accessibility mailing list / team
 * Quality Assurance (QA) --> QA team
 * Accessibility --> Accessibility mailing list / team
 * Quality Assurance (QA) --> QA team


 * Klaus-Jürgen, Christoph
 * Undecided
 * i
 * o
 * Klaus-Jürgen: Accessibility also relates to barrier-free web pages.
 * Klaus-Jürgen: Accessibility also relates to barrier-free web pages.


 * colspan="8" |
 * colspan="8" |

Deliverables and Work Results

 * Documenting User Experience Design
 * d
 * src
 * st
 * i
 * o
 * c
 * Documenting Visual Design
 * d
 * src
 * st
 * i
 * o
 * c
 * Provide Visual Design Resources
 * Provide visual design resources in a consistent and accessible manner
 * Resources for designers and artists with source files of all branding elements, approved final graphics, proposals and ideas
 * Provide officially approved resources:
 * Resources for (external) people wanting to promote and refer to LibreOffice and The Document Foundation on their websites, in their businesses, documentation etc.
 * Resources for community members interested in officially approved graphics for their needs, including CD/DVD, fair booths, promotional activites and so on.
 * Resources for officially approved teams representing the community in different fields: in native language or local marketing surroundings, in documentation, on fairs and meetings ...
 * Resources for designers and artists with source files of all branding elements, approved final graphics, proposals and ideas
 * Provide officially approved resources:
 * Resources for (external) people wanting to promote and refer to LibreOffice and The Document Foundation on their websites, in their businesses, documentation etc.
 * Resources for community members interested in officially approved graphics for their needs, including CD/DVD, fair booths, promotional activites and so on.
 * Resources for officially approved teams representing the community in different fields: in native language or local marketing surroundings, in documentation, on fairs and meetings ...
 * Resources for officially approved teams representing the community in different fields: in native language or local marketing surroundings, in documentation, on fairs and meetings ...


 * Bernhard
 * Undecided
 * i
 * o
 * Christoph: See also "Care about Branding Requirements"
 * Bernhard: The resources should be easy to discover ("visible").
 * Bernhard: The resources should be easy to discover ("visible").

First approach: The Design Gallery


 * colspan="8" |
 * colspan="8" |

Cooperation and Communication With Other FLOSS Communities
Examples for FLOSS usability communities:
 * FLOSS Usability
 * Have a look at the FLOSS community and try to get in touch with them.
 * Have a look at the FLOSS community and try to get in touch with them.


 * OpenUsability.org
 * Fedora Design Team
 * Ubuntu Desktop Team
 * also on Launchpad: https://launchpad.net/~canonical-desktop-team
 * ask Sweetshark for details!
 * Canonical User Experience and Design team
 * OpenOffice.org User Experience Team


 * Christoph
 * Undecided
 * i
 * o
 * Christoph: What can we learn from, how can we cooperate with other FLOSS communities?
 * Christoph: Björn is one of the drivers of OpenUsability.org.
 * Christoph: Björn is one of the drivers of OpenUsability.org.


 * }

Accessibility Team

 * waiting for input

Developers

 * waiting for input

Local Teams

 * waiting for input

Marketing Team

 * Clarifying the process for design elements to be used by the marketing, see Mail by Marc
 * waiting for (more) input

Product Support and Documentation Teams

 * waiting for input

Website Team

 * waiting for input