Design/Kick-Off/WhatWeNeed

    From The Document Foundation Wiki

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate

    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 Brainstorming rules⁠Wikipedia logo v3.svg).

    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

    Short Name Task Description / Ideas / Examples Source Status Importance / Urgency Owner Comments / Proposed Structure

    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
    		 Christoph, Bernhard Undecided i o
    • 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)?
    		 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.
    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
    		 Michel, Christoph Undecided i o

    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?
    • ...
    		 Björn, Michel, Christoph, Bernhard st i o
    • Christoph: This also related to the product strategy which should be discussed with the Marketing guys.
    Short Term Improvements Clarify what we can improve in and how we can improve LibreOffice in the short term

    Examples:

    • 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.

    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
    		 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?
    Regular Design Tasks Identify and handle regular design tasks
    • 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)
    		 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.

    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
    		 Bjoern, Christoph, Michel Undecided i o c
    Make Users Visible Make users visible in the development and decision process 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

    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.
    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)
    		 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.
    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)
    		 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 :-)
    		 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, ...).
    LibreOffice Requirements Clarify handling of LibreOffice requirements Clarify how to report and track LibreOffice requirements Björn Undecided i o c

    LibreOffice Technical Basis

    LibreOffice Framework Enhancements Clarify status with the development and ask for improvements concerning the LibreOffice framework

    Frameworks and technical stuff needed:

    		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.

    Cooperation and Communication Within the Design Team

    Clarify Decisions Making
    		 Clarify how to make quick and transparent decisions

    A defined way to decide on e.g. officially approved graphics or user experience / usability related questions is required. Ideas:

    • 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.
    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).
    		 Bernhard Undecided i o
    • 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)
    		 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
    		 Christoph Undecided
    		 i o c

    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
    		 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
    		 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?
    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, ...)
    		 Björn, Christoph Undecided i o
    • Bernhard: Knowledge about the developers working on such topics (bugzilla keywords? "UX needed", "UX involved", "Visual design". "UI" ...)
    Provide an Easy Hacks Collection Collect, verify and publish Easy Hacks for the development

    Examples for information sources:

    • 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.

    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)
    		 Michel Undecided i o c
    Document Tools Document preferred tools
    • 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
    		 Klaus-Jürgen, Christoph Undecided i o
    • Klaus-Jürgen: Accessibility also relates to barrier-free web pages.

    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 ...
    		 Bernhard Undecided i o
    • Christoph: See also "Care about Branding Requirements"
    • Bernhard: The resources should be easy to discover ("visible").

    First approach: The Design Gallery

    Cooperation and Communication With Other FLOSS Communities

    FLOSS Usability Have a look at the FLOSS community and try to get in touch with them.

    Examples for FLOSS usability communities:

    		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.

    Other Team's input

    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
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=Design/Kick-Off/WhatWeNeed&oldid=161476"