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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel