kde plasma workspace structure

[Aaron J. Seigo]

On Saturday, June 9, 2012 13:11:21 Alex Fiestas wrote:
> On Sat, Jun 9, 2012 at 11:13 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> As notmart said in one of the threads where we discussed the vision,
> does the user want to execute an application or what he/she wants is
> to read the pdf?

that does not make the application a part of the workspace. otherwise EVERY 
application that some group of users relies on is part of the workspace.

it seems people are confusing "needed by a user" to mean "is part of the 
workspace".

what is in the workspace is not determined by importance. it is determined by 
thematic inclusion: what is part of the computer system (hardware interaction, 
application interaction, search, settings, ..) and what are things (windows, 
applications, however you wish to divide them) that deal with *my* data and 
information.

that is a clean logical split and one you'll find most users naturally 
gravitate towards.

they don't see the panel as an application. they do see their photos as 
something different. why? because they have a different personal relationship 
with those tools.

that is the division we're striving for.

btw... if "is important for users" is the metric for workspace inclusion, 
ksysguard (and all process monitoring UI) does not meet that requirement and 
should not be part of the workspace.

but if the workspace is about the division between "sytem" and "user" tasks, 
then it quickly sorts itself out cleanly.

(and btw, there are computers used every day out in the real world that never 
view a single photo. these limited use systems are found in offices all around 
the world ..)

this does not mean that the applications should be random in appearance or 
have no points of integration (in fact, the workspace representing the system 
means it must integrate for things like background jobs or passive 
notifications). it just means that these components are not part of the 
workspace itself.

when you start to work on the design of a desktop shell and then switch to an 
application, the different design requirements start to become apparent. you 
can get away with a lot more in application code than you can in workspace 
code, from resource usage (CPU, etc.) to UI uniqueness to API design to 
ergonomics ...

> > the desktop shell, the command runner, the window manager and various
> > other
> > components are started on behalf of the user to make the system
> > essentially
> > usable.
> > 
> > system settings and similar applications are there to interact with the
> > system itself, not to grant access (view/manipulate) the user's own
> > information (files, contacts, websites, etc.)
> > 
> > if we go down the path of "what application is essential to the user"
> > we'll be utterly screwed because:
> > 
> > * that changes over time
> 
> Great ! if we are aware of this we can react quickly and provide
> applications that will fit our users needs.

which users, which time scale, do they all change at the same pace / time?

> > * that changes between use cases
> 
> We have to define personas, targets, whatever it takes so we can focus
> in a group of people.
> If the group of people is large enough then we should give priorities to it.

you can't make the messy world tidy just by wishing it was tidy.

90% of users use 10% of the features, but which 10% they use is different 
between users. (Linus was the first person i heard say this clearly :)

one finds that the choices are:

* go for a large user base and deliver enough features to cater to them
* go for a limited user base and offer a tightly focused feature set

the latter doesn't work out economically. for proprietary systems you can't 
make enough money to pay for the engineering. for open source systems you 
can't keep enough developers to get the engineering done.

> Good example of this is Active, even if we had a super wonderful
> workspace in there (which we do) it wouldn't so useful if we weren't
> able to view pictures, browse the web etc...

again, "important" is not the same as "it's part of the work space"
 
> So what is really worth is Active workspace + bunch of applications
> that will make the experience complete.

agreed .. but the applications are still not part of the workspace.

they are not designed with "this is part of the workspace" in mind.

if we want to get dolphin, gwenview, etc. more harmonized and following more 
common ideas that's terrific and i am very much in favour of this.

we can certainly also find integration points with the workspace that they can 
use (SLC is one example that springs to my mind, of course :)

and yes, this will make them even more compelling when paired with the 
workspace.

but the workspace is not the applications. and the applications are not part 
of the workspace.

btw, this also ensures the workspace remains a happy place for people who, 
say, use KDevelop or do video editting or $WHATEVER_ELSE. this clear mental 
separation is critical to keeping the workspace generally useful as opposed to 
highly useful only for a mythical persona and poorly useful for everyone else.

if you don't believe me, look around at the other options out there right now. 
see which ones people like and which ones people are having a hard time 
swallowing. the success of MacOS isn't that the applications are part of the 
workspace; the lack of enthusiasm around gnome-shell is inspite of their 
taking a "everything is part of the workspace" approach.

instead, try to sort things into categories:

* workspace
* core apps
* everything else

design the workspace to be an awesome frame and set of support tool for the 
latter two.

make the core apps seamless with each other, ensure they use all the 
integration points offered by the workspace.

everything else will then take care of itself.

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