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. _______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active