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