hello, is there a preferred way to share documents in the mailing list? is an ubuntu one link an acceptable option? Thank you,
2013/9/21 Michele Kipiel <michele.kip...@gmail.com> > 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