[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: KDE framework 5 - a humble idea
From: Michele Andrea Kipiel <michele.kipiel () gmail ! com>
Date: 2013-09-23 12:45:53
Message-ID: CAOeydTWiXMerqr1mT8ebsfNc=QZSnEDuC35KmxK8Pn1kO9LUmg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.kipiel@gmail.com>
> Il giorno sab, 21/09/2013 alle 01.51 +0200, Sebastian K=FCgler 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 fo=
r
> 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. a=
s
> a ux
> > > designer i constantly strive towards simplification and
> rationalization of
> > > the user experience, and the first thing i noticed about the plasmoid=
s
> 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. Th=
e
> video
> > (it was probably me who took it) shows test and demo code. The goal her=
e
> 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, whic=
h
> in
> > > my opinion hampers their usefulness. in other words: what would happe=
n
> 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 th=
e
> > share-like-connect widget to post it. This is just an example, but woul=
d
> be
> > entirely possible with how Plasma works today.
> >
> > > now imagine i want to turn the picture in b/w before sharing it: i ju=
st
> > > 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 dra=
g
> 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 c=
an
> > 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 dro=
p
> 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 suitabl=
e
> > 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 dropp=
ed
> > data, if there's one, we create that right away at the drop location, i=
f
> 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 int=
o
> 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 pastebi=
n
> > 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 descri=
be
> > 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 offere=
d
> a
> > Picture Frame widget, but not to apply a cool effect. (Not that this co=
de
> > 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 b=
e
> 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
>
>
[Attachment #5 (text/html)]
<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>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic