Task Launcher - mockups

[Thomas Pfeiffer]

On Thursday 31 January 2013 12:04:43 Aaron J. Seigo wrote:
> On Thursday, January 31, 2013 11:30:19 Thomas Pfeiffer wrote:
> > and generally useful, but isn't what I really had intended. Again: The UI
> > is merely an implementation detail.
> 
> well, post-concept it becomes the design focus .. which is why marco and i
> tend to spend so much time talking about it ;)

Sure. And it does make sense to think about possible implementation obstacles 
early on. I just feared we might reject a general idea merely because the 
suggested implementation doesn't work and wanted to avoid that ;)

> > 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
> > videos) with "Play Videos" / "Play Music", and "Calendar" with the
> > functions to view and manage calendars and create events with "Browse
> > Calendar", "Manage Calendars" and "Create Event", "Marble" with
> > "Browse/View/Navigate Maps"?
> 
> personally, i'm in favour of exploring this further ..  :)
> 
> we've already started down this line with Books and Images. having Videos
> and Music in there which launch PMC directly showing those is a natural
> next step. the user should never "launch" PMC but rather go to viewing
> content (either browsing what is available or opening a specific item).

I'm glad we agree here :)

> Calendars is interesting .. "Browse Calendar" is, following the above
> pattern in which "the verb 'view' is implied in the noun form" this would
> then appear as just Calendars. creating an event would appear in Create.
> "create event" should also be available from inside the calendar app as
> well, so once you are there you aren't repeatedly going back to the Create
> UI .. in this way a calendar is different from, say, writing text
> documents, as adding an event is a form of editting the calendar being
> viewed. so Calendars an exception; Calligra Words should not offer the
> ability to create new documents.

Absolutely. Ideally users would be able to start tasks from whatever point it 
makes sense, and creating an event form a calendar view totally makes sense. 
If a user ever has to "go back" to the Launcher from the point where she 
actually wants to start a task, there is a starting point missing

> another interesting one are applications like KAlgebra. it isn't realy
> consumption -> you use it to, e.g., show graphs for equations you type in.
> is that creation? if so, would it then appear in in Create -> Algebra?
> "graph" would give the wrong impression. it's also not quite creation as
> much as it is exploration, learning ... is that a new verbal category? if
> so, what is it? you can use KAlgebra to learn .. but you can also use it to
> get useful graphs for equations that may come up in the course of a real
> world project you are working on.

Yes, this may be one of the example where no one clear action can be 
associated with an application.
A user-centered approach to finding actions to associate with an application 
(or find out that there aren't any common ones) would be to ask users "What do 
you usually do with KAlgebra?" If you then get 10 completely different answers 
form 10 people, then you know you won't find a good verb.

> Marble is easys: it would just be Maps, the same as PMC is Videos (if Marble
> makes some leaps forward in the future, it could become Locations)

Yes.

> manage .. this is an extension of the settings concept we currently have? so
> i wonder if we could treat this similarly in the UI as Create (i know you
> don't want to talk UI, but i need to figure out how this idea will impact
> the next step of design before knowing if it is something we can
> realistically commit to :) .. there could be a single Settings entry which
> when selected replaces the launch view with setting options. this would
> mean we don't need a settings application anymore, either. just the
> individual panels.

If you treat e.g. adding Akonadi resources as an extension of settings as 
well, then yes. Maybe we should not call it Settings (now I'm shifting my 
focus to details as well, dang! ;) ) because that may invoke associations with 
current system or application settings, and users may not expect to add a 
calendar or email account there.

> if we realy wanted to take it even further, settings could appear IN the
> Launch area as well. 'm not sure how i feel about that idea yet at all, but
> it could enhance the feeling that settings are a part of the system itself
> and make accessing such settings a little faster -> you don't end up with a
> window that opens that you then have close to get back.

I like the idea. It would be similar to the way Sebas put the Broqwser 
settings directly in the content area, and it feels pretty nice there.

> a big question here probably is whether or not one jumps between different
> settings options a lot. e.g. do i open settings to access a specific
> settings page, or do i open settings and visit several? if the former, it
> doesn't matter if the settings pages remain integrated .. if the latter,
> it's probably an efficiency boost to keep them in the same UI as the
> listing of settings pages.

My guess: During initial setup, users visit all sets of settings, but 
afterwards they usually use only a specific kind since related settings should 
all be on the same page anyways. I hope that in the future we'll have a wizard 
for the initial setup anyway, so that could cover that issue.

> and IF we put the settings page listings .. er .. the Manage options ;) in
> the Launch area, then we'll need to explore if we need a listing that shows
> more detail per entry. in the Settings app it shows an icon, a name and a
> description. so: is the description useful?

I think descriptions are useful in general, especially for pages where you 
can't find a self-descriptive name.

> lots of questions waterfall from here.
> 
> to back up a bit .. if it is all in the Launch area, then we have:
> 
> Create -> things you can create -> workflow selection
> Manage (Settings?) -> settings page listings -> settings page
> Consumption -> Entries that are nouns which can be prefaced with "view"
> (view maps, view web site, view files, view books, view videos, ..)

Let's not forget communication. After you've used the KTp Runner to start a 
chat, you don't want to go back to having to open a contact list and click a 
name (let alone having to start an application first) each time you want to 
start a chat with a specific person anymore, so I definitely want to have that 
in PA as well.
I like the idea Björn posted that you first select a person to contact and then 
you're presented with ways to contact that person, based on the person's 
presence status in different communication networks. Currently we're seriously 
lacking in communication capabilities, but with KTp Active progressing pretty 
well and hopefully good social media integration into PA soon, this will 
become a powerful feature.
 
> consumption items could stay in the top level as a full list (they are
> already "complete sentences") with Create and Manage unfolding to show the
> options within those items (to build a sentence/phrase)

Then they'd be more prominent then other types, though. We can decide whether 
we want that or not later, I guess.

> > Just adding a global "Create" button to a grid of application
> > launchers is only a tiny shift from app-centric to task-centric. Do we
> > want
> > 
> > And in
> > the first case: Where do we place all the other tasks that have nothing to
> > do with creating things?
> 
> i think we leave them in the top level, listed after Create and
> Manage/Settings. taken further, we could have: Create (single entry that
> unfolds to show creation possibilities), Manage/Settings (single entry that
> unfolds to show management possibilities), media consumers (single entries,
> all top level) and then non-media consumption items (e.g. games :)

Some kind of grouping of similar tasks may still make sense, though, since we 
would have multiple tasks per application and thus a lot of them in sum. The 
system (and UI) has be flexible enough to incorporate new groups of tasks in 
the future because we can't tell what kinds of tasks will emerge in the 
future.