KDE framework 5 - a humble idea

Sebastian Kügler sebas at kde.org
Tue Oct 1 22:35:17 UTC 2013


Hi Michele,

On Wednesday, September 25, 2013 22:46:29 Michele Kipiel wrote:
> Il giorno lun, 23/09/2013 alle 22.02 +0200, Aaron J. Seigo ha scritto:
> > On Monday, September 23, 2013 14:45:53 Michele Andrea Kipiel wrote:
> > > is there a preferred way to share documents in the mailing list? is an
> > > ubuntu one link an acceptable option?
> >
> > as long as it is available without requiring special software installed or
> > an  account, it doesn’t particularly matter where it is stored.
> >
> you can find the scenarios document here
> http://ubuntuone.com/6E70KbRoRSEFLu9he3OptU
> 
> there's only three for now, i am currently working on the fourth, which
> will be called "the fluid desktop"

Well-written scenarios, I think they're quite useful. Some thoughts:

Scenario #1 is something that describes how Activities can be used: as a way 
to organize the working environment. My experience with using Activities is 
that it allows you to have multiple clean working environments and have it 
easy to switch between them. In Plasma Active, the document-centric approach 
is much more pronounced, here you can connect documents, links, and other 
"Things" (defined by what we can describe using Nepomuk) to an Activity. This 
is a neat concept that is almost invisible in today's Plasma Desktop, 
unfortunately.

Scenario #2 would, from the technology side, need two things: A powerful RSS 
reader, and making sure dragging and dropping of feeds works. (For example, 
does dragging a URL to an RSS feed actually offer the "News" widget when 
dropped onto Plasma?). We have some RSS tools, but I don't think they allow 
the level of features you propose at this point. There's the News and RSS Feed 
Plasma widgets, and Akregator, which would need some design and code love. 
This scenarion is just as interesting when you replace the News with Email. 
Using Akonadi in the background, these things could possibly share quite some 
code, while being totally different things to the user.
Imagine by the way this guy to help with filtering and sorting or the feeds: 
http://steckdenis.be/post-2013-09-25-the-end-of-the-google-summer-of-code.html

Scenario #3 raises an interesting topic: "How do people find their 
applications?". That's a complex problem which can be viewed from different 
angles:
- The user just wants to get something done, she's not interested in a 
specific application, but needs her problem solved
- There are multiple tools doing the same in different ways, some are for 
power users, some are more basic (imagine photo management with gwenview vs. 
digikam, for example). How to suggest the right tool?
- Matching packages against user requirements ("install me something that can 
do X and Y")
- Having the necessary software installed doesn't mean the user automatically 
knows a good workflow for it, often interaction between more than one tool is 
needed, complexity rises. This comes back to your original thoughts of 
workflows-across-components
- The user knows the name of the tool and just wants to run it, it might not 
be installed yet, so that should be easy to do. This is I think a 
comparatively simple, but basic and essential feature.

Interesting prior art does exist, Aleix Pol has created Muon Discover, which 
takes a non-traditional approach to what technically, a package manager can do 
for you. There's also the Kickoff / PackageKit integration, which shows you 
hits for applications from the launcher menu and offers to install them.

Next steps would be:
- Refine scenarios with use cases and detailed description of workflows
- Test and evaluate what works today, and what needs changes (preferably 
  prioritised)
- Define technical requirements, create a task list of things to solve
- Find people to work on that, this could be in the form of "Shouting who 
wants to help solve these problems?", a Season of KDE / Summer of Code 
project, an internship, or, best, by someone scratching their own itch.

Reading the scenarios made me realise that I personally would prefer to have 
this on our wiki at community.kde.org/Plasma. There's matching information 
already there. Maybe it could be moved next to it and be refined from there? 
Quite relevant in the light of the scenarios is the work we did on persona's 
last year. You can find them at 
http://community.kde.org/Plasma/Workspace_Sprint/Personas , I've written a 
blog entry about that some time ago, you can find it at: 
http://vizzzion.org/blog/2012/06/plasma-personas-carla-and-raj/ . A good 
person, and one of our interaction guys is Thomas Pfeiffer (dunno if he 
follows this list closely, so I've CC:'ed him to make him aware of this 
discussion.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9


More information about the Plasma-devel mailing list