On Wednesday 02 October 2013 00:35:17 Sebastian Kügler wrote: > 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.h > tml > > 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.
Thank you Sebas for CC'ing me! This is indeed a very interesting topic for me and I would have missed it otherwise (turns out I just have too many mailing lists to follow with too much "noise" - a.k.a. technical stuff which I don't even understand - so I'm likely to miss important stuff). All of these scenarios indeed fit very will with our visions for both the future of Activities (toward which the way they work in Plasma Active is already an important step) and our concept of Flows which we introduced during Akademy (see https://conf.kde.org/en/Akademy2013/public/events/15 for details). Therefore I'd indeed be glad to work with Michele to further develop those ideas! Cheers, Thomas _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
