On Thu, 2010-11-18 at 06:43 -0500, Marc Paré wrote:
* Ideas: (add any ideas that you may have; ideas that would allow better
work conditions for the design team etc.)
Starting from the needs of the Ubuntu Artwork team, a small group of us
have been thinking about a custom/standalone solution. My own thoughts
wandered towards a project-neutral design process and asset management
solution. So the input I have to offer here might be a bit much ;)
There are several aspects to this:
* The solution and the community around it should function a bit like a
* It should work as a showcase of design done in an open, collaborative
fashion, by volunteers (and professionals)
* Design thinking and methods should be embedded in the infrastructure.
Combined with moderation/mentoring and successful, fully documented
projects as examples, this should turn the solution into a
* Neutrality of the platform should encourage participants to tackle
various projects and to share ideas and experiences across projects.
The underlying goal
Foster quality and quantity of open design efforts and outcomes.
* Open design efforts: Design efforts that exhibit openness to the
public, collaboration, meritocracy, sharing and permissive licensing.
* Permissive Licenses: Licenses applicable to otherwise copyrighted
works that at least allow free redistribution and may also allow use for
any purpose, creating and distributing derivatives. Examples of
permissive license are the GPL and the Creative Commons family
(Non-Commercial and No_Derivatives variants are edge cases).
* Offer a place to go for open design projects
* Increase the visibility of design efforts, outcomes and participants
* Make design more enjoyable, make it happen easier and faster
* remove technical hurdles
* shape social interactions in a positive manner
* encourage feedback. silence hurts
* encourage constructive criticism, discourage unspecific and
* encourage participators to pay attention to constructive criticism
* avoid and protect against flaming, trolling and vandalism
* apply automation
* assist in managing various aspects of design projects
* Offer guidance and education to enable more, and more capable,
* take care of deployment/packaging/distribution
Create, deploy and maintain a website for managing design processes and
Where assets are any kind of content wrapped in files such as images,
audio and video recordings or compound (text and images) documents.
The Why of Formal Design Processes
* Avoid oversights and typical errors by working step-by-step and using
* Increase width and depth of ideation and conception by working
methodically, including the use of patterns
* Avoid chaos by organizing thought, (inter)action and assets.
Social Issues to deal with
* clique-building and power-trips
* unfounded like/dislike reactions
* non-constructive criticism
* flaming, trolling, vandalism
* not taking well to criticism
* Seeker (needs or wants an asset)
* Requester (Owner, Client)
* Organizer (Facilitator, Steward, Coach, Mentor)
* Designer (Contributor)
* Watcher (provides feedback)
* File formats: (Should the Drupal team take into consideration any file
formats for your team? These are mostly for uploading/downloading
PNG and SVG. With SVG it can be tricky to generate good
previews/thumbnails. At least if Inkscape has been used ;)
* Workflows / Procedures:
No matter if it is about visual design or interaction, central questions
* What is the goal, or the problem at hand?
* Who brought it up or needs it solved?
* Who is, has been or is planning to work on it and in which role?
* What's the status/progress of the effort?
* What are the requirements?
* What needs to be researched / what is the outcome of said research
* What are the related assets
* What are the proposals to achieve the goal
I think the main unit of organization should be a (Design) Project. This
can be a representation of a large undertaking like LO itself, or a
specific task. Projects can contain other Projects.
A Project has a Initiation stage/part. Here we document the thoughts
that led to its creation in a loose format. Should be a case of write
once and rarely, if ever, touch again.
Central to almost everything that happens with a Project is the
Briefing. This is the formalized definition of what the Project is
about. Initially based on the Initiation, it may move away from it over
time. A description, checklist and examples should help.
Analysis: document what can be said about the problem/solution domain
based on critical thinking.
Research: Find out what you need to learn, do so, document it.
Requirements: Define them based on the above.
Conception/Drafting/Design: based on the complexity and needs of the
specific project, there may be one or several rounds of design proposals
from rough to refined.
Evaluation: might not appear as separate stage, but be integrated into
Implementation (link to the work, track progress).
Deployment (planning, direct downloads in some cases).
Projects can be linear, but will have to be iterative in cases. For
example, what you learn in Research might make you change the Briefing
(you have to be sure you are solving the right problem).
(I'm not sure if the Initiation should be just the first version of the
So for every proposal and asset you need to know which version/iteration
of the Briefing it belongs to. Similar for all comments/discussion.
Work on assets like mockups should be version-managed, anyway.
Ideally there should be file-manager/file-system level integration, to
require neither commandline nor browser to pull/commit/push ...
Vector and raster images such as photos, drawings, diagrams and mockups.
Sound and video. Text and compound documents, perhaps.
* Edits and Editors
* Contains which other assets
* Is a derivative of which other asset
* Is used in
* Has been branched at and to
Allow branching. I would also mention merging, but that won't work in
many cases. There will likely have to be a pointer to the
thorwil's design for free software:
E-mail to email@example.com for instructions on how to unsubscribe
List archives are available at http://www.libreoffice.org/lists/marketing/
All messages you send to this list will be publicly archived and cannot be deleted
Impressum (Legal Info)
: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (MPLv2
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our trademark policy