Plasma/Active/Development/TaskCentricBrainstormMinutes: Difference between revisions

From KDE Community Wiki
(Created stub for linking)
 
(First version of the meeting minutes)
 
Line 5: Line 5:
Location: Freenode, #active
Location: Freenode, #active


<span style="color:red">Content yet to be created</span>
Participants: Björn Balasz, Bogdan Cristea, Thomas Pfeiffer, Carl Symons and  mcamaret (both joined towards the end)
 
Meeting goal: reating preliminary ideas for a task-centric system for Plasma Active, which can be further designed during the PA4 release cycle and potentially implemented during PA5 cycle
 
== Background / Current Situation ==
Users prefer working task-centrically, but today's software environments are mostly application-/tool-centric, presumably because that's how the market is shared in proprietary software environments.
 
In a Free Software environment, the market does not dictate separation into applications. This gives the opportunity to center around tasks instead of applications, thereby being more flexible
 
Example: A user is reminded of a friend's upcoming birthday and wants to write a letter to the friend.
* App-Centric: Calendar app pops up a reminder. The user has to start the word processor, has to select the correct template, copy &amp; paste address from address book, and use a full-blown word processor UI to write a simple letter
* Task-Centric: From the birthday reminder, the user can directly start the word processor with the friend's address pre-filled, the correct template selected and the UI optimized for writing personal letters
 
 
The above would be a long-term goal that we think is much easier to achieve in the Free software world than in the proprietary software world
* Activities will play an important role in this, as they are a step in the task-centric direction
* Technologies like Nepomuk play a key role as well, with them we can do things the competition simply can't do (aka something "audacious")
** Example: People find photos by context, we can help them with that
 
 
Observation: Users currently are trained to think file-centric
 
== The Way Towards a Task-Centric Approach ==
The principle should be to use as much of the already existing underlying technology as possible and combine existing applications to form task -specific workflows
* Long-term goal: Users should be able to define tasks (including optomized UIs) themselves and share them via GHNS/Add Ons App
* Creating task-specific UIs and combining them to form workflows should be made really easy
* Tasks are like "UI templates" in which tools are inserted
 
 
Users can install tasks directly from the Add Ons App. If additional applications or templates are needed for the task, they are installed automatically
* If several applications are available for a task, the user should be allowed to select which app to use during installation
* Tasks should be adapted when applications which support them better come out
 
== The Case of Calligra Active ==
Calligra Active wants to support file creation. A startup screen for Calligra Active where users could choose which type of file to create would be app-centric (user has to start the application first). The goal instead would be that users can choose which task they have, and if it's a task which contains creating an office document, Calligra Active is started with the corresponding UI and template optimized for the task
* We need to have a UI for starting tasks soon, so that the Calligra Active team does not have to implement their own start screen but instead we call CA with the parameters needed
** Different ways to start a task: Keyboard, mouse/touch, sensors, ...
* Björn has already talked to the the Calligra (Active) and Kontact (touch) teams, and they would be willing to cooperate to create a workflow/UIs for the task "Write a letter to a specific person"
 
== Next steps ==
The idea is to pick any one example task and create an optimized workflow for it, then define a set of most-used tasks to support next
 
A good first task example could be taking meeting notes, which would encompass Words, Calendar and Activities (both the calendar event and the notes would be connected to an Activity)
* The Activity Screen could be the starting point for this type of task
* Another way could be creating a new Activity for note-taking from an event
* Another example could be reviewing/commenting on a document
* Aside: Calligra Active / Plasma Active in general would ideally support handwriting recognition
 
 
What we aim to have in the end:
* A set of commonly used tasks
* Tool building blocks, as many and as atomic as possible
* A UI to connect the blocks to form a task workflow
* A way to share / get them
* A tool to easily create new UIs from templates
* A way to start a task with given parameters
 
 
More design meetings should be done during the PA4 development cycle, implementation won't start before the PA5 cycle
 
== Further considerations ==
Tablets might be too weak for resource-heavy processing operations, these should ideally be done by more powerful machines (servers) over the network
 
What happens if a user realizes at some point that the UI optimized for the selected task is too restricted to accomplish her goal?
* Option A: Offer an option to switch to the "full application UI" from within a task as a fallback
* Option B (preferred by most participants): Transition from a simple task to a more complex task which offers a more complex UI but stays within the task-centric paradigm
 
--[[User:Colomar|Colomar]] ([[User talk:Colomar|talk]]) 21:27, 14 January 2013 (UTC)

Latest revision as of 21:27, 14 January 2013

Meeting minutes for the brainstorming meeting on the topic of a task-centric approach for Plasma Active

Date: 2012-12-29, 14:00-16:00 CET

Location: Freenode, #active

Participants: Björn Balasz, Bogdan Cristea, Thomas Pfeiffer, Carl Symons and mcamaret (both joined towards the end)

Meeting goal: reating preliminary ideas for a task-centric system for Plasma Active, which can be further designed during the PA4 release cycle and potentially implemented during PA5 cycle

Background / Current Situation

Users prefer working task-centrically, but today's software environments are mostly application-/tool-centric, presumably because that's how the market is shared in proprietary software environments.

In a Free Software environment, the market does not dictate separation into applications. This gives the opportunity to center around tasks instead of applications, thereby being more flexible

Example: A user is reminded of a friend's upcoming birthday and wants to write a letter to the friend.

  • App-Centric: Calendar app pops up a reminder. The user has to start the word processor, has to select the correct template, copy & paste address from address book, and use a full-blown word processor UI to write a simple letter
  • Task-Centric: From the birthday reminder, the user can directly start the word processor with the friend's address pre-filled, the correct template selected and the UI optimized for writing personal letters


The above would be a long-term goal that we think is much easier to achieve in the Free software world than in the proprietary software world

  • Activities will play an important role in this, as they are a step in the task-centric direction
  • Technologies like Nepomuk play a key role as well, with them we can do things the competition simply can't do (aka something "audacious")
    • Example: People find photos by context, we can help them with that


Observation: Users currently are trained to think file-centric

The Way Towards a Task-Centric Approach

The principle should be to use as much of the already existing underlying technology as possible and combine existing applications to form task -specific workflows

  • Long-term goal: Users should be able to define tasks (including optomized UIs) themselves and share them via GHNS/Add Ons App
  • Creating task-specific UIs and combining them to form workflows should be made really easy
  • Tasks are like "UI templates" in which tools are inserted


Users can install tasks directly from the Add Ons App. If additional applications or templates are needed for the task, they are installed automatically

  • If several applications are available for a task, the user should be allowed to select which app to use during installation
  • Tasks should be adapted when applications which support them better come out

The Case of Calligra Active

Calligra Active wants to support file creation. A startup screen for Calligra Active where users could choose which type of file to create would be app-centric (user has to start the application first). The goal instead would be that users can choose which task they have, and if it's a task which contains creating an office document, Calligra Active is started with the corresponding UI and template optimized for the task

  • We need to have a UI for starting tasks soon, so that the Calligra Active team does not have to implement their own start screen but instead we call CA with the parameters needed
    • Different ways to start a task: Keyboard, mouse/touch, sensors, ...
  • Björn has already talked to the the Calligra (Active) and Kontact (touch) teams, and they would be willing to cooperate to create a workflow/UIs for the task "Write a letter to a specific person"

Next steps

The idea is to pick any one example task and create an optimized workflow for it, then define a set of most-used tasks to support next

A good first task example could be taking meeting notes, which would encompass Words, Calendar and Activities (both the calendar event and the notes would be connected to an Activity)

  • The Activity Screen could be the starting point for this type of task
  • Another way could be creating a new Activity for note-taking from an event
  • Another example could be reviewing/commenting on a document
  • Aside: Calligra Active / Plasma Active in general would ideally support handwriting recognition


What we aim to have in the end:

  • A set of commonly used tasks
  • Tool building blocks, as many and as atomic as possible
  • A UI to connect the blocks to form a task workflow
  • A way to share / get them
  • A tool to easily create new UIs from templates
  • A way to start a task with given parameters


More design meetings should be done during the PA4 development cycle, implementation won't start before the PA5 cycle

Further considerations

Tablets might be too weak for resource-heavy processing operations, these should ideally be done by more powerful machines (servers) over the network

What happens if a user realizes at some point that the UI optimized for the selected task is too restricted to accomplish her goal?

  • Option A: Offer an option to switch to the "full application UI" from within a task as a fallback
  • Option B (preferred by most participants): Transition from a simple task to a more complex task which offers a more complex UI but stays within the task-centric paradigm

--Colomar (talk) 21:27, 14 January 2013 (UTC)