Workspace Next Sprint Organization

Wed May 16 10:54:16 UTC 2012

On Wednesday, May 16, 2012 11:14:46 Alex Fiestas wrote:
> On Wednesday, May 16, 2012 09:49:22 AM Aaron J. Seigo wrote:
> > 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
> 
> I don't exactly now what those are, can you explain? or better, can you
> apply those concepts to the current BlueDevil implementation?
> 
> > * integration with activities
> 
> How would you integrate BlueDevil or Kamoso with Activities?
> 
> For RandR I could add the posibility of modify the default settings and tied
> them to Activity (pretty much like PowerDevil does right now). Not that
> interesting imho.
> 
> > > > 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 ;)
> 
> Well my objective would be "So we can create a vision around it".
> 
> So, what is the workspace for you?
> 
> Considering that applications like Dolphin or Gwenview are part of it as
> well as Solid (hardware integration) I find many parts of that vision
> vaguely applicable or at least not clearly applicable.
> 
> Also there are some parts of the vision I don't understand, imho we should
> explain them or use other words.
> 
> -scalable interfaces ?
> -today's contexts ?
> -direct manipulation interfaces
> -organic look and feel.
> 
> I can understand Steve's or President John F. Kennedy visions without having
> to know specifics about politics, device designing or any particular area.
> > > > 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.
> 
> That applies to the current vision I guess.
> 
> > > basic thing to do with the shell is switching and launching
> > > applications.
> > 
> > so is setting the network, checking the time, etc.
> 
> How many times do you do operations with your applications and how many
> times you do other things?
> The only thing I do repeatedly with the shell (now that you say it) is
> checking the time.
> 
> > * 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)
> 
> Are all these things docummented somewhere?

there was something started quite some time ago by .. i forget who? .. here:

	http://community.kde.org/Plasma/TheWaysOfThePlasma

there are other bits spread around the wiki there as well. i am fully 
supportive of streamlining and updating the text.

> > 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.
> 
> I can imagine a future where my workspace acts as a iGoogle
> (www.google.com/ig) or something like that, and I can imagine that being
> sorted by activity etc I saw it in Active and I like it but I don't think
> that should be the vision but instead part of it.

here's where you lose me because that *is* the vision we've been working 
towards. device spectrum, organic scalable interfaces and activities.

arriving 4 years into that and then saying "let's not" to those who have been 
doing the work is .. well ... :/

the alternative proposed of "make applications launch great" is anemic in 
comparison. it is very clear you have a set of concepts you wish to work on, 
and that is important. but i'd like to challenge you to look around those 
concepts and place them within the context of a larger scope of ideas, and 
then design from that point of reference.

this is what "vision" and "design" do for each other ... 

> Applications are too important to be excluded from it in many ways, the

i agree that applications need to be well supported. how that happens needs to 
be derived from the goals of the workspace in terms of user benefit, which 
means knoing what those goals are. 

"support application work flow" is not a vision. perhaps where you and i 
disagree is that i do not think any one uses an app because we like using 
applications. i believe we use apps because they let us accomplish specific 
things like "read a web page". and we do those things because they fulfill 
needs for information, social contact, etc etc etc.

those are the elements of the goals that need to be met. the eventual design 
needs to reflect a deep awareness and respect of those goals.

there are N different ways to launch, switch between, integrate, etc. 
applications. which one(s) do we want to create? well, that depends on what we 
want them to help the person using the system accomplish. which means: the 
design needs to be prefaced by the goals, or vision.

> vision should include:
> -What the desktop does when an app is executed (for example be quiet and not
> bother)

i assume you read that i wrote almost exactly this in my previous email, yes? 
:)

> -Application operations (close, launch, install, etc)

these are implementation details. that does not dismiss them as important 
things to do, but they do not make up part of a vision. 

> -Application integration.

absolutely .. we started with "centralized, consistent management and display 
of services applications use"; i'm sure we can go much further, too. the 
question is: to accomplish what?

the centralization was to provide single well-known places to do common things 
that run (from a user's POV) largely external to an application (aka the 
window we can see) in a consistent manner. the hope is to limit the number of 
things / places people need to learn and think about when using the system.

that principle, extended, brings us to things like SLC ... 

what other sorts of application integration can we do, based on that goal?

and, btw, i can think of other sorts of application integration we could do 
that don't meet the principle above. which is why starting with principles is 
important, because otherwise saying "integrate applications" will likely not 
result in a coherent and usefully designed thing, but a bunch of features 
smacked together because they are cool or seem to look nice.

> At the end a user spent most of its time on applications.

is that why they are using the computer, to use applications? or is there 
something more fundamental going on for them, and applications are a means to 
that end? if so, what is it and how can we support that.

looking at mechanisms like "we use applications" and deriving from that the 
goal of making that use case well supported is a feature definition. and i'm ok 
if that's where we want to take this as long as it mates well with the overall 
vision for the workspace (whatever that might be in the long run).

-- 
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/d06c716f/attachment.sig>