Workspace Next Sprint Organization

[Aaron J. Seigo]

On Wednesday, May 16, 2012 05:24:56 Alex Fiestas wrote:
> On Tuesday, May 15, 2012 10:07:08 AM Björn Balazs wrote:
> > Have you been aware of this vision?
> 
> No.
> 
> > If no: looking back would it have been helpful for your work if you had
> > known it (and how)?
> 
> No (I don't see how to apply it on Bluedevil / RandR / Kamoso).

two that are immediately applicable:

* "organic" and scalable user interfaces
* integration with activities

beyond that, bluedevil (to pick an example) will also have its own goals that 
are not generic to the overall shell development, just as, say, the microblog 
plasmoid does.

> > Is it too general / just right / too specific?
> 
> I think it is focused on the shell while we are working towards a workspace,
> which includes more things than the shell

in your opinion, in what ways is it focused on the shell?

> (working out a definition for workspace would be nice too).

so we can determine what "is" and what "is not" part of the workspace? 

(just to be clear before i start writing about it, only to find out i'm writing 
about something you weren't talking about ;)
 
> > Is there anything missing or unnecessary in it?
> 
> I'm surprised that the word "application" doesn't appear even once, the most

this is where i pop out of a giant birthday cake and yell "SURPRISE!" ;)

applications are a means to an end. imho: the various aspects of how to 
interact with applications (launch, switch..) can be viewed as specific use 
cases to define and accomodate, but applications are not the primary focus of 
the workspace in the sense that everything else is secondary to that.

> basic thing to do with the shell is switching and launching applications.

so is setting the network, checking the time, etc.

> Once that is done in a excellent way, then we can think on how complement
> it.

this is considering mechanism ("how to do X") before defining the principles.

i think it would be great if people wish to focus on making application 
interaction fantastic, but be clear that can not be an overarching vision.

btw, when it comes to applications specifically, some principles we agreed on:

* the workspace components should look distinct from applications so it is 
immediately clear which is "mine" and which is "the system"

* the workspace should frame applications nicely but not get in their way

* the workspace should provide centralized, consistent management and display 
of services applications use (downloading, notifications, etc)

(p.s. instead of "in an excellent way" i would suggest "in an elegant way"; 
"excellent" is an personally subjective value judgement, while "elegance" has 
a definition for what it means to the end product .. prefer objective over 
subjective statements in these exercises as that will make creating results 
based on the resulting goal statements easier to keep consistent.)

> My answer is based on my experience using the current shell. A possible
> objective for the "next thing" would be change that habit and make users
> spent more time on the shell.

s/make user spent more time on the shell/make the shell something people want 
to spend more time with/

the question is, of course, "why?" nothing should be done "just because".

i do think that the shell should receive more time by the person using the 
computer, and the "why" is that it can do a rather good job as a starting 
point and overview of tasks and information in a way that individual 
applications can't.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120516/888655ab/attachment.sig>