Task Launcher - mockups

[Thomas Pfeiffer]

On Thursday 31 January 2013 13:03:11 Marco Martin wrote:
> On Thursday 31 January 2013, Thomas Pfeiffer wrote:
> > > still not wholely formed, but maybe edging somewhere useful.
> > 
> > Well, I see that we have to take this discussion one step back.
> > Both you and Marco mainly criticized my idea of a UI solution, which is
> > fine and generally useful, but isn't what I really had intended. Again:
> > The UI is merely an implementation detail.
> > What we have to decide is: Do we dare the big paradigm shift? Do we want
> > to
> > replace "Plasma Media Center" (with its functions to play music and play
> 
> about this (to go a while in devil's advocate mode), there is one thing i'm
> a bit concerned of which i couldn't think about a solution yet (it all
> depends on how things are done in the end i guess)

It's important to have people which are not easily convinced. By the time we 
have convinced you, you'll have forced us to make the vision much clearer than 
it is rite now :)

> the big great advantage of a paradigm based on "apps" is the virtually
> infinite scalability of the process.
> takes little time for developers to pick up the platform and start to
> develop. also, scales in the sense that being an application something
> quite isolated that just a couple of developers can work on, is easy to
> have, say 1000 developers working to produce software on it, without
> significant coordination problems.
> 
> now, is this the best thing for the user? surely not, indeed the results
> tend to be an uncoordinated mess, but it works in the sense is something
> that can actually be delivered.

Yes, that works well for Apple and Google, but as Aaron once wrote, we're not 
planning to "play the App game". That does _not_ mean we should lock out 
traditional 3rd party app developers, though.
There always has to be a way to start traditional, isolated 3rd party apps. 
That does not mean we can't integrate what the KDE community - and those 3rd 
parties which are interested in tight integration - ships better, though, does 
it?

> Now, the risk i see in a deeply integrated system, is a great difficulty of
> coordination, and a very steep learning curve for 3rd parties, having
> something that looks like a single big application that tries to catch
> everyrhing, without being really efficient in any particular task, and with
> the risk of not being possible to model some task we completely didn't hink
> about.
> 
> Also it shouldn't feel like something that gives the impression of forcing
> the user to "compile a bureaucratic form" before being allowed to do
> something, i'm usually very suspicious to any design that "adds" ui,
> instead of removing it.

Agreed. Nobody wants to add complexity. What I want to achieve is _shift_ it 
from applications to a central workflow and reduce the cognitive load at the 
same time
Take this example: Contacting a person via a specific means of communication 
always needs two steps: Selecting a person and selecting the means.
In the application-centric world, you first choose an application associated 
with a specific means of communication, then you look if the person is 
available and then start the conversation.
In the task-centric view, you just select a person, see what means of 
communication are currently available to contact that person, and then you 
choose the means you prefer.
This is way superior, because
- You don't have to remember which application is used for which means of 
communication
- You don't have to remember which means of communication the person you want 
to contact even uses
- You don't have to know whether the person is currently online in a specific 
network before you choose an application
All that will be possible as soon as the contacts belonging to a natural 
person in all the different menas of communication are associated to that 
person in KPeople. And this is why KDE technologies are so super awesome!

Another example: I just made an appointment by phone and now I go to my tablet 
to create an event for it in my calendar.
App-centric: Open "Calendars", select "New Event"
Task Centric: Create -> Event.
Here the complexity is pretty much the same.

> in the end, is important for me that anything we design is not something
> that is heavier (as resources), feels heavier (as user experience) and
> feels hostile for 3rd party developers.
> I believe is possible to design something that is nothing o the above, we
> just have to constantly keep in mind that

+1000. We want the whole thing to feel natural to users, not artificial. And we 
don't want to lock out 3rd party devs. I just don't think that has to keep us 
from offering users a nicely integrated environment with what we offer 
ourselves.

It's like on the desktop: Sure you _can_ use Gnome applications in KDE. They 
run perfectly fine, but they don't offer you the nice integration KDE apps offer.