KDE4 Vision Document

[Aaron J. Seigo]

On Wednesday 20 February 2008, Celeste Lyn Paul wrote:
> Is there a formal KDE4 Vision statement anywhere? 

no, as others have noted. i've been very hestitant to try to write such a 
thing because of the pushback that i feel would be innevitable.

the dark secrete i carry ;) is that i already have such a vision statement for 
KDE4 and i present it at conferences around the world on a regular basis. so 
oddly enough the outside world knows what our vision is better than we've 
articulated it internally.

the vision statement i present was derived by looking at all the new 
development in KDE4 (changes to kdelibs, the new frameworks, the new apps and 
the updates to existing apps) as well as the language used in common 
conversation during KDE4 development. i then tried to extract the 
commonalities. so this vision statement is not personal to me, but rather 
what i've discerened from the broader movement. (it would have ended up a bit 
different if it was up to just me alone, but that's the beauty of a team 
effort: it's better than any single one of us)

i came up with three broad topics:

* Beauty
* Portability
* Function

Beauty gets broken down into:
* Breathtaking visual design
* Usability
* Modern graphics programming (made easy)

Beauty -> Visual design is broken down into:
* cues from industrial design in terms of ergonomics and streamlining
* modern art trends
* as a core principle: realization that visual design and usability are linked 

Beauty -> Usability is broken down into:
* HIG (WIP) is important
* Flexibility is good, "interface follows implementation" configuration is bad
	* "passive configuration" -> configuration is a natural part of the interface
	* thinking about how a feature appears to the user, not the app
* Organics
	* The evolution principle: making software exploit the hardwired traits our 
minds and bodies have taken on through evolution in the physical world
	* The "(almost) nothing is square, (almost) everything is gradiated in color, 
and (almost) anything can be put anywhere" principle


Portability gets broken down into:
* "In-bound" portability (greater adoption of fd.o and other external specs 
and technologies; this is the "KDE working with the rest of the world to make 
the rest of the world's technology work better with KDE")
* "Out-bound" portability (our platform choices: Linux, BSD, OpenSolaris, 
Windows and MacOS)

Function gets broken down into:
* Frameworks
* Applications

Function -> Frameworks vision ends up with:
* Consistent APIs that:
	* hide the platform specifics (portability)
	* abstract away changes that may happen (future proofing)
* Integration & Synergy: Solid + Phonon, Solid + Threadweaver, Akonadi + 
Plasma, etc.. our frameworks are meant to work together, and when this 
happens even better things come of it (the "your chocolate is in my peanut 
butter" principle ;)


then there are the "soft" (e.g. non-technical) topics:

* Target audiences
* The spirit of KDE

Target audience topics include:
* A focus on crossing the chasm (yep, ripped that phrase right off ;) from 
early adopter to early majority
* Consumer software for the hip and forward thinking
* Productive software for the professional environment

The spirit of KDE:
* Freedom to the consumer and to the contributor
* Community
* Not chasing other people's taillights, but shooting for the stars

that's sort of the rough sketch of it. i'd be happy to flesh it out into a 
full document on techbase that others can then discuss and we can modify, 
etc, together. my only conditions on doing so are that i don't get smacked in 
the face for "having the audacity to speak for others in the project" and 
that we can discuss changes to the document in a constructive manner. this is 
just because i don't have the energy right now to take on yet another 
initiative that results in me put in the middle of argumentative controversy. 
i'm sort of at my physical limit for that right now. (yeah, yeah, i'm 
fragile.)

i'm also happy to let someone *else* draft such a document. i do think it is 
important and useful to do so, however.

> Having and maintaining this document (I assume in techbase?  where else
> would it go?) is extremely important for all contributors.  Having this

such a document on its own is, of course, not enough. it needs to be part of 
the fabric of the culture of the project. or rather, it needs to reflect the 
fabric of the culture of the project. it needs to take the words and phrases 
we use to talk to each other. it needs to not just express our goals, but 
express them using the terminology and beliefs we hold to be self-evident (to 
borrow another great phrase from history).

that was the reason for the "work backwards from the processes we are engaged 
in" approach.

if the document achieves that, it would be *tremendously* useful for new 
contributors as well as those who may not have the deepest insights into the 
technical coding aspects of the project.

> document is a necessary first step before backfilling on any user research
> and usability work in the future.

agreed.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080221/4b3d0031/attachment.sig>