KDE framework 5 - a humble idea

[Michele Kipiel]

Il giorno sab, 21/09/2013 alle 01.51 +0200, Sebastian Kügler ha scritto:
> Hi Michele,
> 
> A few thoughts inline. I've also explained a bit of the technical 
> underpinnings of the ideas you propose, just to give you a general 
> understanding of how the system is handling these things, and how the concepts 
> could be described technically.
> 
> On Wednesday, September 18, 2013 11:26:21 Michele Andrea Kipiel wrote:
> > hello everybody,
> > 
> > the following message is part of an email i sent a few days ago to Marco
> > Martin, who then asked me to share my thoughts on this mailng list.
> > 
> > ***
> > my name is michele kipiel and i am a ux designer. I currently work for the
> > Kering luxury group, where i design and user test the checkout processes
> > and the overall UX of the luxury sites.
> > 
> > i recently came across a video showing the new KDE framework 5 improvements
> > (the one posted by phoronics, in case you were wondering).
> > 
> > watching that video reminded me of what immediately struck me when i first
> > tried KDE 4: the apparent lack of a true purpose for the plasmoids. as a ux
> > designer i constantly strive towards simplification and rationalization of
> > the user experience, and the first thing i noticed about the plasmoids was
> > that they didn't improve my experience in any relevant way, while taking up
> > lots of space on my small 13" laptop screen.
> 
> I think others have already pointed it out, but let me clarify that. The video 
> (it was probably me who took it) shows test and demo code. The goal here is to 
> exercise all kinds of graphical objects on the screen. This helps us in 
> porting a whole bunch of other widgets to Plasma 2. They're basically just UI 
> tests and examples and have zero purpose for an actual user.
> 
> That is to say that we're getting closer to having the basic components in 
> place to make Plasma 2 actually useful, and it's certainly a good point in 
> time to think about higher level ideas such as workflows between these 
> components.
> 
> > i asked myself a simple question: what do i need on my desktop? what i came
> > to realize is that i could really use a desktop which acts as a connection
> > point between the hundreds of apps that live on my hard drive.
> > 
> > current plasmoids act as discrete information bubbles (weather, rss, im,
> > social feeds etc..) and threy don't communicate with each other, which in
> > my opinion hampers their usefulness. in other words: what would happen if
> > KDE added a common backend to connect all the plasmoids (i'm thinking of
> > something similar to what elementary OS is doing with contractor)?
> > 
> > imagine this scenario: i have a file manager plasmoid open on my desktop,
> > along with other ones. i want to share one of my pictures to facebook. i
> > drag and drop the picture from the file manager plasmoid onto the "facebook
> > feed" plasmoid, which in turn activates the sharing feature, allowing me to
> > add a caption, tag my friends and eventually share the picture.
> 
> This gets me thinking that we can use Share-Like-Connect for this, in a 
> sligthly different manner. Many widgets and a handful of applications 
> "publish" their current document (url, or link to a file on the filesystem) to 
> other apps. The Share-Like-Connect widget uses this to offer sharing options 
> for this. I imagine, that a "gimp" plasmoid could use this same information to 
> offer a bunch of image transformations. You pick one, and the published 
> document becomes that newly transformed image, then you head over to the 
> share-like-connect widget to post it. This is just an example, but would be 
> entirely possible with how Plasma works today.
> 
> > now imagine i want to turn the picture in b/w before sharing it: i just
> > drag and drop the picture onto the "gimp" plasmoid, which shows me a
> > preview of the picture and lets me select an action form a pool of simple,
> > predefined functions. once my picture is rendered, i just have to drag it
> > from the "gimp" plasmoid onto the "facebook" one to share it.
> 
> Let's look into what we have for drag and drop support, in more detail. 
> Widgets can offer themselves for a certain mimetype being dropped onto the 
> "Desktop" (the containment in technical terms). We have applets which can 
> handle images for example. The picture frame registers itself as being able to 
> "handle" images (it doesn't tell what it does with it), so when you drop an 
> image onto the desktop, you get offered the picture frame widget. 
> Additionally, for images, you can set them as wallpapers. For text, you'll get 
> a Notes widget, etc.
> A widget defines what it can handle in its metadata, those can be two things:
> - a number of mimetypes (Picture frame has image/png, for example)
> - a regular expression to match a url
> 
> What happens when you drop "something" onto the desktop (the drop data can 
> contain either file data with a certain mimetype, or one or more urls):
> - We look through all installed applets, if we find one that can handle the 
>   dropped data's mimetype, we add that to the offers
> - If the dropped data only has a url, no data and no mimetype, we check the 
>   url's destination file for its mimetype, and use that to find suitable 
>   widgets
> - We look through all installed applets for one that supports a url and 
>   matches one of the urls passed in the dropped data
> We then end up with zero, one or more widgets that can handle the dropped 
> data, if there's one, we create that right away at the drop location, if there 
> are more, we pop up a menu offering the widgets.
> This whole mechanism also works for remote files (everything that's understood 
> by KIO).
> 
> From a higher level point of view, this means, for example:
> - You can drop an image from anywhere on the desktop and create a folderview 
>   there
> - You can drop an image on the desktop -> it creates a folderview
> - You can drop text there, get a notes widget
> 
> One thing that I had working at some point, but which never made it into a 
> release was dropping emails onto the desktop and showing a small widget with 
> the email's content. This worked by passing urls to emails in Akonadi, you 
> could drag and drop emails from kmail onto the desktop, and from there back to 
> kmail. 
> 
> Then, we have individual widgets that can receive dropped content. There, you 
> can basically do anything you like, check the dropped data and play tricks on 
> it or the urls destination. Go wild. An example for this is the pastebin 
> widget, which can post dropped content to "paste sites", depending on what 
> data it is.
> 
> That is to say that the system is already *very* flexible. I think the point 
> really is: How do we harnish this power to create awesome workflows. From the 
> user point of view, this will need a bit of design work, and probably fixing a 
> few things here and there to allow for some newly found usecases. I think one 
> of the most important shortcomings of these possible workflows I describe 
> above is discoverability. It's hard to see these workflows if they only show 
> up in small bits, on certain actions. They do not "offer" themselves to the 
> user. That may be a good thing, it should not get in the way, but there's a 
> fine line to reach how to make these things discoverable, while being non-
> disturbing.
> 
> One vision that I have about Activities is that you should be able to drop all 
> kinds of artifacts onto an activity, and in that way group these things, so 
> Activities. This is mostly possible today, but I think there are quite a bunch 
> of details in workflows which haven't been tested and polished.
> 
> > in these scenarios each plasmoid acts as a graphic frontend that exposes
> > some functions of the related programs, which don't even need to be
> > launched. it could be even possible to create predefined sequences
> > connecting different plasmoids (think of yahoo pipes, for instance).
> 
> One key difference with how the plugin system works is that the options are 
> not offered as actions, but as new objects. For example, you get offered a 
> Picture Frame widget, but not to apply a cool effect. (Not that this code 
> exists today, it just serves as a nice example that you brought up.) In the 
> SLC widget, you do actually have actions available, which again might be a bit 
> closer to the concept you present.
> 
> > i don't know whether this is possible or not, but i believe it could be a
> > massive leap forward for the KDE desktop paradigm.
> > ***
> > 
> > thank you in advance for every comment, positive or negative.
> 
> I think it would be good to do a couple of things:
> 
> - map out a few workflows that would be really useful
> - describe these workflows, possibly visually
> - design a solution around the above described discoverability problem
> - map the needed and missing functionality
> - design and implement the bits needed to realize the workflows
> - test, iterate
> 
> Hope my comments are useful.
> 
> Cheers,

hello,

thank you very much for this fantastic reply, you gave me lots of
information i was missing or unable to figure out. This really gives me
a lot to base my wireframes and workflows on, which is a great thing. 

I hope to come up with some workflow examples in a few days, so we'll
have something to talk about.

Thank you again
MK