Re: [libreoffice-marketing] [Design] Design team needs and Drupal site development

On Thu, 2010-11-18 at 06:43 -0500, Marc Paré wrote:

> Your requirements
> ==================
>
> * 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
design agency.
* 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
teaching/learning environment.
* 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.

Definitions:

* 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).


How?
====

* 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 
      unfounded criticism
    * 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, 
  participators
* take care of deployment/packaging/distribution


Mission
=======

Create, deploy and maintain a website for managing design processes and
assets.

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
checklists
* 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
==========================

* laziness 
* clique-building and power-trips
* unfounded like/dislike reactions
* non-constructive criticism
* flaming, trolling, vandalism
* not taking well to criticism


Roles
=====

* Visitor
* 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 
> concerns.)

PNG and SVG. With SVG it can be tricky to generate good
previews/thumbnails. At least if Inkscape has been used ;)


--------------------------------------------------------------------------


> * Workflows / Procedures:


Central Questions
=================

No matter if it is about visual design or interaction, central questions
are:
* 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
...


Unit
====

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.


Stages
======

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 
Conception/Drafting/Design.

Implementation (link to the work, track progress).

Deployment (planning, direct downloads in some cases).


Versioning
==========

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
Briefing, actually.)

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


Assets
======

Vector and raster images such as photos, drawings, diagrams and mockups.
Sound and video. Text and compound documents, perhaps.

Track:
* Creator
* Edits and Editors
* License
* 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
main/official/trunk/head version.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/


-- 
E-mail to marketing+help@libreoffice.org 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