Workspace Next Sprint Organization

[Marco Martin]

On Wednesday 16 May 2012, 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?

organic: looking less as a computer object, but interacting more as a real 
object: so animated instead of immediate transitions (something appearing 
immediately is "magic"), rounded corners, shadows, preferring direct 
manipulation rather than by some proxy (ie resize by dragging instead of 
writing the number of pixels somewhere) and many things like that.
if you compare with kde3 we are miles ahead on this regard but still not 
there.
note that this is different, and risking to be confused with skeuomorphism 
(http://en.wikipedia.org/wiki/Skeuomorph), that tends to destroy coherence and 
create uncanny valleys, so one moves over a thin line here ;)

scalable: mostly referring to the available space so screen size (or just 
containment size, applets in panels vs desktop)
we started with the formfactor concept and gone forward with the device 
specific qml files for plasmoids (experimental news reader, microblog)

to go in implementation details (ok, we shouldn't too much just yet :p), in 
the future, provided decent quality desktop components will be there, i see 
both workspace and applications being able to work as full desktop apps, 
limited mobile apps and plasmoids with the same c++ logic, and the least 
possible difference in qml files (from experience is possible to do 2 
completely different interfaces still sharing 90% of the qml code)

> > * integration with activities
> 
> How would you integrate BlueDevil or Kamoso with Activities?

like the power profiles right now...
possible scenario: you use often browse the web on the laptop while on the 
train every day, that involves using the 3g phone modem over bluetooth, but 
more powersave for things != from bluetooth in the laptop...
(probably use cases like that should be used as starting point to see what 
could be useful or not)

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

a little inner voice is whispering "presentation with a beamer" ;)
the activity switch causing also the powermanagement settings to switch and 
the right presentation files to open could even be triggered by the detection 
of the projector :p </bluesky>

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

to me the boundaries should blurry more and more until nobody cares what an 
app is, every functionality shared in any way between apps, just going in the 
global environment (like we did with slc) dolphin should be part of the 
workspace without the user even noticing on what they are using (yeah, i know 
that for the developer having the name of his product well visible is 
important and )

> Also there are some parts of the vision I don't understand, imho we should
> explain them or use other words.

yep, i agree especially in last years there wasn't much put out on the outside

> -scalable interfaces ?
> -today's contexts ?
> -direct manipulation interfaces
> -organic look and feel.

hmm, maybe a glossary could be compiled on the wiki? 
also some of them derive from actual psychology studies (like why not having 
sliding animations for appearing things plays bad tricks to the brain), I 
would like having a bit of bibliography on this, but sadly i don't :/

there is a minimum common language that should really be a given for 
participating on a thing like that, I advise to everybody (but especially to 
who is coming there) some good reads (those are more about ux design details 
but are concept useful anyways for a broader vision definition):
http://www.andrewschechterman.com/AndrewSchechterman/Qi_Fa_files/UX%20Glossary.pdf
http://cyborganthropology.com/UX_Glossary
http://blog.usabilla.com/the-usability-abc-part-2/#more-3075
http://uxmag.com/

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

that's a source of important information, problem is making it compelling to 
have others, i think at the moment there is an "have to setup it" barrier
for instance i couldn't live without an identica microblog right in the panel, 
well, i could ;) but i like it a lot

> > * 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? I'd like to read about them
> instead of finding out in different emails because it seems that at the end
> we are agreeing on pretty much the same.

i think most of what's written in a permanent place is there:
http://community.kde.org/Plasma#Interface_Standards_and_Research

sadly quite outdated. a thing that would be very good from the sprint by the 
non coders that will participate is to write, write and write about those 
topics ;)

> > 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.
> 
> Applications are too important to be excluded from it in many ways, the
> vision should include:
> -What the desktop does when an app is executed (for example be quiet and
> not bother)

there calls for a concept of context to complement activities (the location 
manager is a start, other parameters besides location are needed, then current 
behavior is function of activity*context)

> -Application operations (close, launch, install, etc)
> -Application integration.
> 
> At the end a user spent most of its time on applications.

true, but the fact that this distinction exists in the first place may be part 
of the problem (false dichotomy?)

ie with the machine i want to perform task x to produce or view a certain 
thing, not use application y, atomicity of applications is in part a technical 
detail, in part historical commercial reasons to have a product in a store.

Cheers,
Marco Martin