place for design docs

Aaron J. Seigo aseigo at kde.org
Sun Jul 13 21:33:52 CEST 2008


On Saturday 12 July 2008, Celeste Lyn Paul wrote:
> On Saturday 12 July 2008 21:45:43 Aaron J. Seigo wrote:

> For example, I have a collection of wireframes and specifications for both
> new UIs and adjustments to existing UIs.  It would be useful to have a
> place to put them up (besides my blog) for developers to review UI
> documents or use elements in the document as patterns.
>
> There are a lot of other proposals for things like Kickoff
> changes/substitutes.  It would be good to have a single page dedicated to
> these things so we can work on improving the good ideas and not repeating
> the bad ones.

this is the slightly different topic of design experimentation and development. 
i'm thinking more about things like "how the wallpaper gets drawn": technical 
design decisions that get made, documenting the internal workings of the 
system.

i think some sort of web driven interaction for the design process, 
particularly of visible components, would be great, though. a wiki would 
suffice, though something even more purposeful would do; sort of like how a wiki 
would suffice for patch submission, but review board is waaay more useful.

> I also agree this is also a good place to document discussions or decisions
> made on mailing lists.  For example, there have been a number of topics
> which have been repeatedly discussed on the KDE-Usability mailing list over
> the years.  Documenting the problem and solution and referencing a mailing
> list thread would provide a better historical document of the design
> decision than saying "We've discussed this already, check the archives".

yep ...

> > * where should we host them? (first instinct was the wiki, but then i
> > thought inside the source repository itself  ... the latter can be more
> > easily accessed offline. both are easier to find things in than the email
> > archives)
>
> I think a wiki makes sense because it makes them easier to edit, access,
> and publicly available.  In this case, the public == future design
> contributors and not users.  Hiding them in SVN would make it difficult for
> both contribution and access.

we'd make it at least readable via the web.

i'm not particularly interested in having random contributions to this area, 
though the current plasma dev wiki shows this doesn't happen anyways =)

> Granted, we don't have many non-developer designers in KDE, but I think it
> should still be brought up.  I have an SVN account, but I would probably be
> less likely to add/update an SVN document than a wiki document or 

that's probably true. i wonder how much we'd lose ... hrm.

> link to
> archive file in a wiki.

if it was in svn, i think we'd have to publish it to a website somewhere. so 
linking wouldn't be a problem.

a wiki still leaves the following problems unaddressed:

* offline access
* easy moving of documents around (e.g. between draft status and implemented 
status; would require a lot of hand work for TOCs, for example)

pros and cons.. will need to weigh them..

-- 
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: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080713/1c369cb8/attachment.pgp 


More information about the Panel-devel mailing list