[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-active
Subject:    Re: Task Launcher - mockups
From:       Thomas Pfeiffer <colomar () autistici ! org>
Date:       2013-01-31 12:01:03
Message-ID: 6097600.CdiOVUzILQ () localhost
[Download RAW message or body]

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 obstacl=
es =

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 applicatio=
n =

(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 answ=
ers =

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 Mar=
ble
> 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 w=
ith =

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, b=
ut
> 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 sho=
uld =

all be on the same page anyways. I hope that in the future we'll have a wiz=
ard =

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 sho=
ws
> 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 t=
hat =

in PA as well.
I like the idea Bj=F6rn posted that you first select a person to contact an=
d then =

you're presented with ways to contact that person, based on the person's =

presence status in different communication networks. Currently we're seriou=
sly =

lacking in communication capabilities, but with KTp Active progressing pret=
ty =

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 wheth=
er =

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 th=
at
> unfolds to show management possibilities), media consumers (single entrie=
s,
> 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. Th=
e =

system (and UI) has be flexible enough to incorporate new groups of tasks i=
n =

the future because we can't tell what kinds of tasks will emerge in the =

future.
_______________________________________________
Active mailing list
Active@kde.org
https://mail.kde.org/mailman/listinfo/active
[prev in list] [next in list] [prev in thread] [next in thread]