Posted Jan 29, 2013 17:58 UTC (Tue) by aseigo (guest, #18394)
Parent article: Seigo: Plasma.next()?
Ooh boy :) As soon as I saw which snippet they pulled for the summary I knew there would be fun in the comments. So let me clarify for those who haven't been following Plasma too closely in the last year or two.
Plasma Active is for consumer devices, such as (but not exclusively) tablets. Plasma Desktop is for full on desktop systems.
In Plasma Desktop, we have a very traditional approach to the file system workflow, though augmented by Activities which are also optional (you can freely ignore them if you wish). So you have the file system and the file manager, etc.
On consumer devices, picking through file hierarchies is a lot more painful due to input method limitations. The use cases of such devices is also fairly different.
To make this smoother, in Plasma Active, activities are front and center (and not particularly optional, though you can stick with just 1 if you care to) and we use metadata information extensively. When looking at photos, I probably want all the photos associated with a given activity (e.g. a vacation activity, or a party activity, or a project activity..) or with a given bit of metadata (such as a tag, or perhaps a geographical location).
Given how devices such as tablets are actually used with comfort (and not in the limited fashion seen fit by Apple and Google), this tends to work really, really nicely. Of course, we do let you explore the file system hierarchy (graphically or via a terminal if you wish) but that's simply not the first UI you are presented with and forced to use (usually awkwardly on a tablet, phone or t.v. screen).
(Removable media is treated specially again, in ways that will make people here happy I think, but for brevity (ha!) I won't get into that here..)
I'm a "pry my keyboard from my cold dead hands, and give me those overlapping windows while you're at it" guy (mouse is very nice, but I can live without it if push comes to shove ;), so I'm not blindly in love with devices at the expense of a good desktop. None of our team is, in fact.
What's really compelling, I think, is that with Plasma Workspaces 2, it will be easy to switch between the different workspace shells (and their paradigms) at runtime. So your tablet can become a little desktop if you want without any problems .. and you still get to use Plasma and the rest of the KDE software while you're at it :)
In any case, try it before you dismiss it; don't judge Active by Android/iOS limitations; keep in mind that we retain a full desktop env and like it that way :)
Posted Jan 29, 2013 18:41 UTC (Tue) by pboddie (subscriber, #50784)
[Link]
Plasma Active is for consumer devices, such as (but not exclusively) tablets. Plasma Desktop is for full on desktop systems.
You do realise that you're suffering from the same branding affliction as Microsoft here? On the one hand, having a well-known brand (Plasma) that gets mentioned all the time means that you can build on its supposed popularity, but then it also means that when you try and add qualifiers to it (Active, Desktop, Workspaces) to differentiate between potentially completely different things, you also have to make sure that everyone is able to keep up with those naming decisions and also to remember what all those names mean in the first place.
People likely to care what Microsoft Office is are also likely to remember because the labelling is obvious. Using "Active" as a qualifier is going to challenge people's memory because it's vague and sounds like you've branched out into breakfast cereals. That's why people are getting confused about what you're offering and what you're changing. Using totally different or memorably distinct names helps to keep things separate, but the cost is that you perhaps lose mindshare: people may not realise that the same people are involved in some new thing you're doing.
In fact, not using brand umbrellas like KDE or Plasma keeps everyone honest because developers then have to sell a project on its own merits and not lean on brand reputation. And, of course, nobody feels threatened because it looks like their favourite project is going off in some new and weird direction when it's actually something else that's doing so.
To make this smoother, in Plasma Active, activities are front and center (and not particularly optional, though you can stick with just 1 if you care to) and we use metadata information extensively. When looking at photos, I probably want all the photos associated with a given activity (e.g. a vacation activity, or a party activity, or a project activity..) or with a given bit of metadata (such as a tag, or perhaps a geographical location).
By the way, I use tagging quite a bit for managing photos, but I use hierarchies extensively for other content, too. Activities, however, as they are in KDE 4 (or whatever the full brand-plus-product name is) seem to be a confusing, orthogonal-to-workspaces demonstration of a concept not fully exercised or delivered. Are there any compelling examples of activities online?
Seigo: Plasma.next()?
Posted Jan 30, 2013 10:10 UTC (Wed) by aseigo (guest, #18394)
[Link]
> when you try and add qualifiers to it (Active, Desktop, Workspaces) to
> differentiate between potentially completely different things,
ah, but they aren't completely different things. they different primary interface paradigms that use the same core concepts (e.g. Activities) and even many of the same UI components.
they are different faces to the same software, with the differences being driven by the physical form factor being targeted.
> you also have to make sure that everyone is able to keep up with those
> naming decisions and also to remember what all those names mean in the
> first place.
those involved on the technical side, yes.
for the user, not really; KDE and Plasma (potentially with the suffix "Workspace" when needed for clarification) is the important note there.
my blog is intended for a technical audience, so ... :)
> because developers then have to sell a project on its
> own merits and not lean on brand reputation
leaning on brand reputation is how one builds on earned reputation. starting from scratch each time is absolutely insane. neither the customer nor the producer wins with that strategy.
the time to depart from existing brands is when the product departs (in function or focus). this is not the case here, however, as Plasma was designed from the get-go for this multi-UI-shared-logic approach.
> a confusing, orthogonal-to-workspaces demonstration of a concept not
> fully exercised or delivered.
> nobody feels threatened because it looks like their favourite project is
> going off in some new and weird direction when it's actually something
> else that's doing so
in this particular case, i'd rather deal with people being concerned about their favorite project going off in some new and odd direction than have a group of connected technologies communicated as if they are not. we have to pick our poison here.
i'm happy to correct people's misconceptions as they arise, and over time people will grok the concepts fully.
we're trying to shift the perception of what a desktop shell UI can and should be .. and we know that takes time, education and communication. trying to route around it by adjusting our communication to fit the current (mis)conceptions will not accomplish that.
it is the interrelated nature of the various Plasma Workspaces that grants
> the technology one of its most significant value propositions.
> seem to be a confusing, orthogonal-to-workspaces demonstration
> of a concept not fully exercised or delivered
when we started with Activities, nobody else had really explored this idea. even in academia, relevant concepts were poorly developed: integration with the core shell wasn't well examined and proposed UI concepts were often overly complex (management in 3D, with a large gesture vocabulary, complex boolean constructions). so we were starting from scratch with little to guide us.
rather than spend 3-4 years behind closed doors as most proprietary projects do, we worked in the open. we ran into numerous obstacles; some technical, some related to design decisions.
over time we approached the design concept seen is Plasma Active, in which activities are seamlessly integrated, highly accessible and easy to grok. this was based on the work done in Desktop; so it is in a way an "activities 2.0" :)
the next phase of Activity development on the Desktop is to take the lessons learned in Active and fold them back into Desktop.
at the end of that (stepwise) process, i hope we will all be able to say that the concept will come through clearer and be easier to use.
hopefully that helps clear up the history a bit so you can understand why the feature presentation is where it is, and where we are going with it.
> Are there any compelling examples of activities online?
Plasma Active is entirely driven by activities. The exact same ones as used in Plasma Desktop. It's the same daemons behind the scenes, in fact: kactivitymanagerd (+ optionally Nepomuk). So that's a fairly good example.
Posted Jan 30, 2013 15:35 UTC (Wed) by pboddie (subscriber, #50784)
[Link]
leaning on brand reputation is how one builds on earned reputation. starting from scratch each time is absolutely insane. neither the customer nor the producer wins with that strategy.
Leaning on brand reputation is trading on that reputation but not always building on it. What would have happened if KDE 4 had been called something else? People would have been obliged to consider it more on its merits than on its connection with the KDE brand, which might not have been a good thing for the developers because it wouldn't have automatically directed an audience to that product, but then again people would have been obliged to reset their expectations, which would actually have been a good thing for all concerned.
Starting from scratch is a brave thing for developers to do, what with needing to work hard to persuade people of the merits of the software itself, when the alternative is to capture everyone upgrading from one release to the next.
when we started with Activities, nobody else had really explored this idea.
Really? If you ignore the way people use virtual desktops, there are plenty of examples of grouping content and functionality by activity, at least beyond general window and desktop content management. The most ancient form is the spreadsheet and the use of separate files or sheets to organise different things (albeit with fairly restricted functionality on offer even with object embedding available), but you also find Web-based content management systems like Wiki sites providing activity-specific resources and employing tools that allow people to move beyond the application-centred view and towards a content-centred view that necessitates the integration of different applications or tools.
In fact, the way that Web applications often integrate different kinds of functionality in the same view is precisely the kind of thing that presumably inspired things like Microsoft Active Desktop, Netscape Constellation and, of course, Plasma.
There are also numerous articles online about activities; google provides a good number when searching for "plasma activities", such as this one: http://hanschen.org/2011/02/04/activities-a-change-in-workflow/
I don't think the author makes a good pitch for activities, really. He says, "With activities you can associate a particular window with more than one activity." You could do that already with virtual desktops in KDE 3, to the point where you can choose which desktops can see the window in KDE 3.5. I accept that using the term "activities" makes things easier to explain to people, but then you can argue that using that name for virtual desktops would solve that problem. Certainly, the toy examples I see given about making new activities for every single thing you do aren't going to scale, although I accept that if you do need another workspace it's easier than going into the configuration and adding one.
Having both activities and virtual desktops is confusing. The article seems to advocate one desktop and many activities, stating that you could have many desktops within an activity if you needed that, but then you're navigating some kind of maze just to find that window you were using. When I tried KDE 4 (Plasma Desktop?) recently, the workspace and pager functionality was so poor (minimised windows didn't appear in the panel at all, and the workspace indicator just showed two blank panels), I started to think that one reason for people being persuaded to use activities was that the other functionality just isn't usable any more, sad to say.
I think that activities are obviously an interesting idea and are widely used and proven already in other domains, but I don't think they appear as usable as the existing features for doing this kind of thing in KDE unless the audience is primarily people who need to be told how to organise their work. That would explain the photo activity which, if I were to find a comparable implementation of the concept in another medium, would be similar to having a simple Web photo gallery application, but even with a richer user interface toolkit available the usability just wasn't at the level I would expect: the navigation controls kept jumping around as the picture went from portrait to landscape and back again, and the picture needed resizing in a sometimes complicated set of user interface gestures.
Seigo: Plasma.next()?
Posted Jan 30, 2013 17:21 UTC (Wed) by aseigo (guest, #18394)
[Link]
> What would have happened if KDE 4 had been called something else
then we would not have been responsible for the results, and after things shook out and came right we'd now be left with a recognized brand (KDE) with not relation to what we're actually working on.
what you're suggesting is forking our own community.
> people would have been obliged to reset their expectations
a) that would not have happened as we were no longer maintaining the old code base, so it would be pure smoke and mirrors and our user base would have seen through that in a moment's notice
b) we would have lost countless more users due to the resulting confusion
c) it's good for the product if the group behind it takes responsibility for it. that means putting your name to it. like IBM did with the mainframe and Boeing did with the 747.
> Starting from scratch is a brave thing for developers to do
which is not what we did, btw. yes, the desktop shell got rewritten. everything else was a port. (including many pieces of the workspace itself: from kdm and kwin to various workspace libraries)
> what with needing to work hard to persuade people of the merits of the
> software itself
we had to do that with 4.0 release, despite using the KDE brand :)
people are not nearly as sheeplike as you seem to think
> If you ignore the way people use virtual desktops
> Wiki sites providing activity-specific resources
Activities are not spatial grouping. they aren't content grouping. they aren't limited to grouping at all. we utilize grouping visually in various areas of the Activity presentation, but grouping is not the core concept.
rather it's about contextual relatedness: given what $PERSON is doing in $PLACE at $TIME, what should the computer be doing?
a very simple example that steps outside the bounds of content grouping: when i switch to my Presentations activity, the power management settings on my laptop change appropriately.
or: when i switch activities on my tablet, the people in my address book that "matter" change.
> I don't think the author makes a good pitch for activities, really.
you wanted a sales pitch. i thought you meant documentation. my bad.
> I don't think they appear as usable as the existing features for doing
> this kind of thing in KDE
and all the people who do use them and swear by them are .. what? i think we can agree they are not you. :) but if we step outside of "you" == "definition of usable", we find people actually getting use out of activities that they didn't have access to before.
personally, i don't try and argue with reality when it presents itself, nor do i feel the need to add interpretation on top of such results in order to measure value. "why do these people find activities so useful" is a very interesting philosophical question, and one that can drive future development, but "according to people who use them, activities are useful" and "plasma active's implementation of activities tests very well with the general public" is enough to get to "does the concept work?"
i absolutely will submit that we will find people who do not use them and do not WANT to use them. there are people who hate broccoli too (many/most because of an interesting genetic variation that allows them to taste a compound in broccoli as intensely bitter). so there is no point in arguing about universal perfectness. the question is: does it do well for the people and place it is found?
in the case of Plasma Desktop, you can freely ignore Activities, so it's an interesting discussion perhaps but moot. many do use them there and find great utility in them. they are still a work in progress there, not as far along as in Active (which had the benefit of starting with all our lessons learned from Desktop).
in the case of Plasma Active, they are a core part of the system .. and, thankfully for us, actually works in the hands of people using the devices. there are people who use Active every day. in that sense, we've moved past theory.
i'm not sure how much more there is to discuss given those data points.
> unless the audience is primarily people who need to be told how to
> organise their work.
does a filing cabinet tell you how to organize papers? no. it's a tool to do so.
same with activities. they provide a set of mechanisms by which to create contextually relevant states of being for the machine. you are in control them. they do not tell you how to organize your work.
the original inspiration for activities came while watching a graphic designer tell the *computer* how to organize his work by manually moving files and app icons around between folders and the desktop in the most painful of mouse and keyboard ballets.
so rather than activities telling you how to organize your work, it grants you tools to tell the computer how you'd like to see your work (or play :) organized and handled.
> That would explain the photo activity
not really. that was put there as an example to get people started in a useful direction some releases ago, but it hardly scratches the surface (and was actually put there before we had a number of the current features available implemented). apparently it failed in its mission. :) that can be rectified with a simple git rm ...
Seigo: Plasma.next()?
Posted Jan 31, 2013 0:27 UTC (Thu) by pboddie (subscriber, #50784)
[Link]
What would have happened if KDE 4 had been called something else
then we would not have been responsible for the results, and after things shook out and came right we'd now be left with a recognized brand (KDE) with not relation to what we're actually working on.
I don't think you follow. There is a discontinuity between KDE 3 and KDE 4 in terms of technology and in terms of the developers involved, as I understand it. I get the impression that people didn't want to work on KDE 3 any more, but had KDE 3 been more actively maintained then it might have been inappropriate for KDE 4 to claim to be a continuation of that heritage.
You can claim that most people involved with KDE development moved on and that they have the right to apply that label to whatever they subsequently do, and you can claim that this isn't confusing to the users if what they subsequently get meets their expectations based on what that group produced before, but those expectations are very high indeed: you only need to read the complaints about functionality regressions (or whatever people want to call them) to realise that. Moreover, as the various GNOME forks have shown, being in control of the brand doesn't mean that such a group is actually the best flag-bearer for continuing any traditions or fulfilling any expectations.
b) we would have lost countless more users due to the resulting confusion
Who would have lost users? That's my point: there's the idea that a new project automatically takes over the users of an old project because the new project uses the same name as the old one, but those users are using the old project, not the new one, and they don't belong to anyone. Who do GNOME 2's users "belong" to? Nobody. The only thing "lost" is the opportunity to convince people using a previous product to adopt the current one.
Starting from scratch is a brave thing for developers to do
which is not what we did, btw. yes, the desktop shell got rewritten. everything else was a port. (including many pieces of the workspace itself: from kdm and kwin to various workspace libraries)
I was referring to branding the thing from scratch. I've had the argument about whether some heritage has been maintained in these exercises fairly recently, and many people seem to think that it's confusing to suggest an upgrade to an existing product when the result is actually a different product which can't provide feature parity with the previous one.
Activities are not spatial grouping. they aren't content grouping. they aren't limited to grouping at all. we utilize grouping visually in various areas of the Activity presentation, but grouping is not the core concept.
rather it's about contextual relatedness: given what $PERSON is doing in $PLACE at $TIME, what should the computer be doing?
Isn't "contextual relatedness" just a fancy term for grouping? Or if "grouping" is too vague, how about "showing and doing common stuff in the same view"? I mean I get the examples about laptop settings and address books, and formalising these things is obviously overdue (particularly the former), but I still dispute that "nobody else had really explored this idea".
I don't think the author makes a good pitch for activities, really.
you wanted a sales pitch. i thought you meant documentation. my bad.
Well, that article barely passes for documentation if that's what you think it is.
I know that it's easy to label my misgivings as anecdotal and support from other sources as data points, and it may well be the case that "plasma active's implementation of activities tests very well with the general public" (source needed), but I'd like to know under what conditions. Were people given tuition or did they sit down and figure it out themselves? Were the people doing this in a dedicated period of time or as part of their normal routine?
I'm not accusing anyone of deception but it's very easy to sell a particular story. Every day of late, I have been confronted with an advertisement that gives a supposedly objective assessment of the merits of a particular company's product in the form of a taste test - guess where the advertiser's product is placed in the ranking - and in my idle moments staring at it, it has become obvious how one would game this in several ways to encourage a certain outcome (and not even considering just running many surveys until one gets the "right" results).
Maybe the testing accurately measures the perception of the target audience, but I'd definitely be worried about inadvertently reaching the "right" result and reinforcing an unfortunate strategy. Then again, I'm sure you've given this plenty of thought, so I guess there's nothing to be gained from giving it any further consideration.
Seigo: Plasma.next()?
Posted Jan 29, 2013 18:59 UTC (Tue) by Tara_Li (subscriber, #26706)
[Link]
> On consumer devices, picking through file hierarchies is a lot more
> painful due to input method limitations. The use cases of such devices is
> also fairly different.
I've not found picking through file hierarchies that much more difficult on my Android tablet (WinTec Filemate Identity), in those apps such as CoolReader that expose it. On the other hand, the built-in Gallery app goes through my *ENTIRE* filesystem, and finds all of the cover image thumbnails from my e-books, and presents them as a flat view of folders for each directory that contains an image - but doesn't preserve the fact that those folders were already in folders to group them together.
Frankly, it's asanine, and I hate it.
If people have too damned much trouble understanding folders in folders, then have your app display a file drawer for a folder containing folders, a filing cabinet for a folder containing file drawers (to be cutesy, stack the folders that aren't in subfolders on top of the filing cabinet...), and a file room for containing filing cabinets.
Those kinds of people are not all that likely to be working more than 4 levels deep, anyway.
(I hereby dedicate the idea of icons of file rooms, file cabinets, file drawers, and file folders, used to indicated different levels of containment, to the public domain - or I would, if it weren't so bloody obvious it should legitimately already be in the public domain!)
Seigo: Plasma.next()?
Posted Jan 30, 2013 9:51 UTC (Wed) by aseigo (guest, #18394)
[Link]
> presents them as a flat view of folders for each directory
> that contains an image
So, I ended my post by saying "don't judge Active by the limitations of Android/iOS" ... and what do you do? ;)
and yes, i hate these applications, too. they are ridiculously unuseful. we aren't recreating those applications, however, because we think they suck. we want to do better, and i think we are achieving that.
we're not trying to make another Android clone (a failure i see in most other F/OSS mobile products, btw: androidish but with some differences in the home screen gesture navigation .. it's not enough0, we're trying to make a damn good touch interface.
> If people have too damned much trouble understanding folders in folders
people aren't stupid. folders are stupid. they enforce a single sorting mechanism based on a single tagging that must follow a parent->child relationship. single entry hierarchies break down rapidly as content grows in richness or volume.
we're not trying to fix the UI for people's stupidity, we're improving the UI to match the realities of people's content complexity.
i routinely handle huge hierarchies of files (source code trees, e.g.) and find the metadata approach on tablets far quicker and more powerful in that context.
Seigo: Plasma.next()?
Posted Jan 30, 2013 14:05 UTC (Wed) by sorpigal (subscriber, #36106)
[Link]
> people aren't stupid. folders are stupid. they enforce a single sorting mechanism based on a single tagging that must follow a parent->child relationshi
I'm on board with finding a better way to organize things and I believe that KDE as a project won't take away things just because it's cool, but what is the answer for cases when a user really does want a rigid hierarchy? I have not used KDE4 for a few releases, or the Active stuff at all, but it seems to me that there isn't a known solution to the problem that will satisfy the people who want hierarchies and the people who would find life easier without rigid parent->child restrictions (especially since sometimes these are the same people).
Are you hoping that a purely non-hierarchical system won't be as unpleasant as people seem to fear or do you know of a solution that is known to satisfy both cases?
Seigo: Plasma.next()?
Posted Jan 29, 2013 20:02 UTC (Tue) by ibukanov (subscriber, #3942)
[Link]
> On consumer devices, picking through file hierarchies is a lot more painful due to input method limitations.
This is a bad interface limitation. Just consider an interface that presents 10 000 files as a 4 level hierarchy with average 10 items per level based on whatever heuristics/preexisting folder structure grouping. Then each file is reachable within 4 clicks or touches even on a small display. This is way faster then a keyboard search on a touchscreen. Plus such search does not work well if one is unsure about the name while grouping allows quickly see neighboring groups/folders providing valuable clues.
Seigo: Plasma.next()?
Posted Jan 30, 2013 9:46 UTC (Wed) by aseigo (guest, #18394)
[Link]
> This is a bad interface limitation.
It is driven primarily by the size of our fingers and hands. Our hands can only hold devices of a certain size (and our bags and pockets also put practical limits there). So unless we change human physiology, touch remain limited in this manner.
> Just consider an interface that presents 10 000 files
> as a 4 level hierarchy
Sounds horrific; but also (thankfully) utterly unrealistic for the common use case for tablets. So instead, lets Consider 10k files but organized by metadata, activity and tags. Most of that information is automatically generated.
This allows us to avoid the file system hierarchy, lets files appear in more that one "area" of the metadata space AND lets us get to them quickly by defining sets of tags.
In the file manager you can go to the "Tags" sidebar and select as many tags as you wish. So instead of a 4 level hierarchy, we would have an N combination tag set.
Perhaps a good example is portable (and other) music players: good ones let one quickly go through the content by artist, album, genre, name, etc. as well as custom playlists. Where are they on disk? Doesn't matter.
This brings that same concept to all files. Due to the flexibility of tags and metadata it is far more efficient. Metadata from e.g. the camera that took a picture or a location tag can be used to automatically group. Tags are easy to create and use. There's also a (zoomable!) timeline included.
So you could have one document tagged with "peer review", "PLOS" and "Neurobiology" (to pick sth rather at random). Then you can see that document, along with its peers, by selecting any combination of those tags. You might start with "peer review" and then go to "Neurobiology". you might start with "Neurobiology" and then decide you want to narrow it down to only peer reviewed papers.
Honestly, it kicks the living crap out of single entry hierarchies.
> search does not work well if one is unsure about the name
which is why search includes more than just the name. welcome to the 21st century in terms of information storage and retrieval :)
> grouping allows quickly see neighboring groups/folders
tags are groups that are more flexible than a static hierarchy.
Seigo: Plasma.next()?
Posted Jan 30, 2013 10:38 UTC (Wed) by micka (subscriber, #38720)
[Link]
> Perhaps a good example is portable (and other) music players: good ones let one quickly go through the content by artist, album, genre, name, etc. as well as custom playlists. Where are they on disk? Doesn't matter.
Really bad example. I'm still searching for a music player that allows me to select music by filesystem location. Any ("consumer device" as you say) I can find shows you your music by artist or album or genre, and it doesn't pose me a problem (I won't use it though) as long as I can select files and whole directories from a filesystem.
Because I know where the music is on the filesystem even where I don't know the tags (because i'm the one who put the files where they are).
Even when I find one program that allow (a limited and degraded) filesystem based selection, it never allows to choose a directory and "play recursively".
Every music program will show me a pile of all the music files it can find on my device with some tags whose content is foreign to me (because I didn't tag them myself).
Actually, it's the same for ebook readers. they insist on either having each their own book directory (separate from the other app, so you won't share resources) or show you a "drawer" with all the books it can find. I'm happy to bypass this bookshelf view each time I can.
By the way, the very first program I _must_ install each time is a two panel file manager.
And tag systems relies on the existence of a complete and maintained tag database and tagged object database.
Seigo: Plasma.next()?
Posted Jan 30, 2013 13:07 UTC (Wed) by foom (subscriber, #14868)
[Link]
No, really good example. Because for the other 99% of people, navigating their music by any of the multiple tag fields rather than a single directory hierarchy *is* an improvement.
Seigo: Plasma.next()?
Posted Jan 30, 2013 13:51 UTC (Wed) by micka (subscriber, #38720)
[Link]
I'm sorry being a minority (in reality, I'm not 1 % by myself).
By the way, you didn't source your "99 %" frequency.
Seigo: Plasma.next()?
Posted Jan 30, 2013 15:48 UTC (Wed) by dan_a (subscriber, #5325)
[Link]
>> Perhaps a good example is portable (and other) music players: good ones let one quickly go through the content by artist, album, genre, name, etc. as well as custom playlists. Where are they on disk? Doesn't matter.
>Really bad example. I'm still searching for a music player that allows me to select music by filesystem location. Any ("consumer device" as you say) I can find shows you your music by artist or album or genre, and it doesn't pose me a problem (I won't use it though) as long as I can select files and whole directories from a filesystem.
Any player which supports Rockbox (www.rockbox.org) will fulfill the filesystem location requirement.
Personally I prefer tags, but it'd be a strange world if everyone was alike.
Seigo: Plasma.next()?
Posted Jan 30, 2013 20:33 UTC (Wed) by aleXXX (subscriber, #2742)
[Link]
I have to agree.
I organize my music in folders: artist, then album.
Easy to navigate.
Each time I try to use some tagging mode (doesn't matter whether rockbox or amarok or something else), it screws up.
The tags e.g. for the artist usually use different ways to spell the name, or what to do with spaces, or umlauts, so I end up with multiple folders for the same artist, just written in a slightly different way. Then having to figure out in which of these folders the album I'm looking for is located is too much.
Maybe it wouldn't be a problem if editing the metadata would be straight forward, but it isn't. Editing directory names is straight forward.
Alex
Seigo: Plasma.next()?
Posted Jan 30, 2013 21:09 UTC (Wed) by raven667 (subscriber, #5198)
[Link]
> Maybe it wouldn't be a problem if editing the metadata would be straight forward, but it isn't.
Is that a fundamental problem with the technological idea or a UI problem with the implementation because it seems that Plasma is about fixing the UI problems to make this straight forward.
Seigo: Plasma.next()?
Posted Jan 30, 2013 21:32 UTC (Wed) by nix (subscriber, #2304)
[Link]
Yeah, that scheme works great. Until you run into classical works, in which the composer and performer are different people. And then there are works with multiple performers or composers...
... it does break down in the end. And when it does, you have to reclassify *everything*.
Seigo: Plasma.next()?
Posted Jan 31, 2013 15:48 UTC (Thu) by sorpigal (subscriber, #36106)
[Link]
It's frustrating. Even with tagging it breaks down, because tagging systems tend to be naive in that they assume either a limited number of keys or a limited number of values for each key (often only one).
The related problem is syncing metadata from tagging systems with files when the move between systems. Embedding tag data in files works well but is format specific and usually quite limited (example: you're reading ID3v2 data from an MP3. Quick, what is the encoding of the textual data?)
The lowest common denominator is directories and file names, because every system has those and no agreement on key names is required.
There's probably a need for a portable file API for tagging. Something that raises the lowest denominator a bit but doesn't mandate an on disk format, indexes, complex protocols, etc..
Seigo: Plasma.next()?
Posted Jan 30, 2013 22:16 UTC (Wed) by mpr22 (subscriber, #60784)
[Link]
I edit the metadata of files I rip locally from CD at the time of ripping, via the check-and-edit stage of my ripping package. I trust files provided through Proper Channels by the artist or their authorized representatives to be correctly tagged, or at least to be incorrectly tagged in an adequately consistent manner.
Seigo: Plasma.next()?
Posted Jan 31, 2013 3:08 UTC (Thu) by mathstuf (subscriber, #69389)
[Link]
> Really bad example. I'm still searching for a music player that allows me to select music by filesystem location. Any ("consumer device" as you say) I can find shows you your music by artist or album or genre, and it doesn't pose me a problem (I won't use it though) as long as I can select files and whole directories from a filesystem.
Check out Vanilla Player[1]. (It's in the F-Droid repo as well).
> Because I know where the music is on the filesystem even where I don't know the tags (because i'm the one who put the files where they are).
That's fine for you and me (I use %albumartist%/%releasedate% - %album%/%disc%[ - %disctitle]/%track%[ - %artist%] - %title%.%format%), but my mom and sister just drag'n'drop music and let the device sort things out, so filesystem browsing is approximately useless.
Posted Jan 31, 2013 9:49 UTC (Thu) by micka (subscriber, #38720)
[Link]
That's one I never saw or tested. So I will have to check this, thanks (it could take some time, though, as I just "lost" my phone...)
By the way, it fits one requirement I didn't express, it's foss (MIT, but you have to open the source to know it, bad ; being on fdroid was a good lead, though).
Seigo: Plasma.next()?
Posted Jan 30, 2013 13:19 UTC (Wed) by ibukanov (subscriber, #3942)
[Link]
> In the file manager you can go to the "Tags" sidebar and select as many tags as you wish. So instead of a 4 level hierarchy, we would have an N combination tag set.
The nice thing about hierarchy is that it is stable as inserting a new subtree only affects very few nodes. So one can use motor and other unconscious forms of memory to quickly navigate to the desired item. A hierarchy where each node fits on the screen is perfect for a tablet as one can literally remember finger movements to get to the item. To the lesser extent this happens with mouse.
I do not see how tags provide such navigation stability. In order to keep all items on the screen (any scrolling kills the navigation speed) a hierarchical structure may need to have ad-hock subtrees. With tags those subtrees-as-tags would just pollute the initial tag set.
> Perhaps a good example is portable (and other) music players: good ones let one quickly go through the content by artist, album, genre, name, etc. as well as custom playlists. Where are they on disk? Doesn't matter.
This just demonstrates how tags nicely work with content consumption where somebody else already created all the necessary information and where there are several well-defined commonly recognizable categories to split the collection. For big collection of images the story is not so good even if one just wants to see them.
Seigo: Plasma.next()?
Posted Jan 30, 2013 17:35 UTC (Wed) by aseigo (guest, #18394)
[Link]
> A hierarchy where each node fits on the screen is perfect for a tablet as
> one can literally remember finger movements to get to the item.
and utterly fails when the collection grows.
the vast majority of people absolutely suck at hierarchical navigation, just as the vast majority of people absolutely suck at remembering numbers longer than a handful of digits.
> I do not see how tags provide such navigation stability.
by removing the need to navigate a non-spatial data set spatially.
how often do people lose their keys?
how often do they forget what their keys look like, or which keys are on their keyring?
> For big collection of images the story is not so good even if one just
> wants to see them.
the movements to tag a big collection of images into the same organizational array as represented by a bunch of folders is approximately equivalent (can be slightly better, can be slightly worse, can be the same; depends on the exact structure).
the problem most people have with tags (me included, btw) is that the mechanisms provided to tag things have SUCKED (as in: too labor intensive, not part of the primary workflow so always extra work rather than "for free" during usage) only to have really weak tools built around the semantic data sets such as "a tag cloud" or "if you show this sidebar and then change the view appropriately, you can reduce the current display by a given tag." which means the input effort totally outweighs the output benefit.
i have, actually, used Plasma Active to tag large sets of photos such as ones i took on a vacation last year. the one thing i really wanted available was a "show me pictures i haven't tagged yet" (something like a negative tag filter) .. it's on my todo in any case :) we have a full "importing large photo sets" type workflow already designed out, it's a matter of getting to the implementation (which will happen eventually; we're moving at a good pace as can be seen over the short lifespan of Active so far :)
keeping in mind that tags are but one aspect of the semantic data we provide access to (time, usage patterns and in-file metadata also are utilized; free text searching, timelines, etc are also provided built into the workflow everywhere) and that the UI limits the input effort and maximizes the output benefit, with a worst case usually being "equal to a hierarchical system" .. it works rather well.
now, one use case i find it is still not good enough for is when you start with a disk full of metadata free pictures that have few if any relationships with each other (iow: migrating to the system from a historically data poor system). we have some thoughts on how to ease such transitions (including mining the existing folder hierarchy if it exists) and will be improving that aspect of things. of course, we first needed a working metadata centric system to migrate too ;) and for touch devices right now, the common use case does not currently include "migrating all the content from my laptop with a 15 year old file structure on it" (which would be my case :) but rather tends to be a "starting from a blank device, adding content to it incrementally during use"
Seigo: Plasma.next()?
Posted Jan 30, 2013 18:06 UTC (Wed) by dskoll (subscriber, #1630)
[Link]
the vast majority of people absolutely suck at hierarchical navigation
You make all these sweeping statements, but you don't provide evidence to back them up. Could you provide some evidence?
Seigo: Plasma.next()?
Posted Jan 30, 2013 21:25 UTC (Wed) by jospoortvliet (subscriber, #33164)
[Link]
I think at least THAT statement is a quite well known fact. People like you and me are at least reasonably good at managing hierarchy's (I'm personally actually to unorganized for it - I create 'temp' folders everywhere in which I just dump 'temporary' files which I keep there for years. But I get the concept just fine).
But go an look at the desktop of the office workers doing your tax papers. They dump most of their files in a single folder... Lots of people do it and I think Mac OS X, with Spotlight, has already shown that search is far more usable than folders for the 'average' person. Now imagine taking that dumb full-text indexing and augmenting it with smart meta-data extracting (including the ability to grab tags from the web etc), linking files to usage paterns etc etc - and you can hopefully imagine how much easier it gets to find what you're looking for with very little effort.
Seigo: Plasma.next()?
Posted Jan 30, 2013 21:29 UTC (Wed) by bronson (subscriber, #4806)
[Link]
Wow, you're really reaching. Are you really disagreeing with the statement you quoted?
Seigo: Plasma.next()?
Posted Jan 30, 2013 21:45 UTC (Wed) by dskoll (subscriber, #1630)
[Link]
I agree that most people don't use hierarchy to organize files and folders. But I disagree that most people are bad at navigating an existing hierarchy.
At my work, we've organized all our documents in Subversion and even the non-technical people have no problem keeping things in a nicely-organized hierarchy: agreements, leads, quotes, etc.
Once you show people a hierarchy and show how easy it is to use, they just get it in my experience.
Seigo: Plasma.next()?
Posted Jan 30, 2013 19:26 UTC (Wed) by dskoll (subscriber, #1630)
[Link]
by removing the need to navigate a non-spatial data set spatially.
This is a very bad thing. Muscle memory is unlike any other kind of human memory in that it almost never fades. If you learn to play the piano, don't play for 20 years, and then go back to it, your muscle memory will be almost 100% intact. I talk from experience here...
Furthermore, memory experts (I mean those who participate in memory contests) specifically make spatial associations with the objects the need to remember because humans have a very good spatial memory and can remember far more spatial relationships than the standard "5 to 9" items in short-term memory. And unlike you, I even have a reference.
Seigo: Plasma.next()?
Posted Jan 30, 2013 21:27 UTC (Wed) by jospoortvliet (subscriber, #33164)
[Link]
I don't get the whole 'muscle memory' argument on computers, tbh. I use my data over different devices, laptop, mobile phone and desktop and hopefully in the future a tablet. Muscle memory will be utterly useless. Even on the same device it makes only sense for often accessed things - which I usually access by typing "alt-F2 - WORD" anyway, or via the 'recent files/locations' section in my filemanager...
Seigo: Plasma.next()?
Posted Jan 30, 2013 21:42 UTC (Wed) by dskoll (subscriber, #1630)
[Link]
I don't get the whole 'muscle memory' argument on computers, tbh
Really? I still use the same key bindings for my window manager (maximize, minimize, bring-to-front, etc.) that I first learned on SunOS in 1990. :) I found the swap of Ctrl and CapsLock on IBM PC keyboards circa 1992 horribly jarring.
And even on my recently-acquired mobile device, I am learning where things are and where to swipe or tap to do various things.
Seigo: Plasma.next()?
Posted Jan 31, 2013 3:14 UTC (Thu) by raven667 (subscriber, #5198)
[Link]
That likely puts you in rare company. I've learned and re-learned the basic UI paradigms at least half a dozen times in that period, DOS, Win3x, Win9x, SunOS OpenLook, Linux, FVWM, KDE1, BeOS, KDE2-3, Blackbox/Openbox, GNOME 1, GNOME 2, Win2k/XP, MacOS X 10.4-10.6 and 10.7-10.8, Unity, GNOME 3, iOS, most of which I've used for a main desktop for some period of time. I've learned to not bother with highly custom workflows and lots of key binding memorization because it dosen't translate when things change, to stick with with the universal workflows and the main theme that each system is designed to support. Every system has a design theme (except maybe for Windows for which design by committee would probably be an improvement) that generally makes sense and becomes easier to use once you discover it.
Seigo: Plasma.next()?
Posted Jan 31, 2013 12:20 UTC (Thu) by dskoll (subscriber, #1630)
[Link]
Ah. My approach is simply not to use systems that can't be made to work the way I like. I don't use Windows or Apple products. And though I have switched window managers and desktop environments a few times, all of the ones I've used could be made to work the way I liked.
Seigo: Plasma.next()?
Posted Jan 31, 2013 21:55 UTC (Thu) by jospoortvliet (subscriber, #33164)
[Link]
now you are talking about something entirely different - physical location of keys. Yes, i rely on that too and hate switching keyboards. But it is not related to a file-hierarchy vs metadata discussion...
Seigo: Plasma.next()?
Posted Feb 1, 2013 12:20 UTC (Fri) by dskoll (subscriber, #1630)
[Link]
I was responding to this: ...by removing the need to navigate a non-spatial data set spatially...
Seigo: Plasma.next()?
Posted Jan 31, 2013 9:23 UTC (Thu) by ibukanov (subscriber, #3942)
[Link]
> and utterly fails when the collection grows.
This is not true. As long as number of items per node is small adding a new subtree affects only few nodes so relearning is quick.
> the vast majority of people absolutely suck at hierarchical navigation,
Yes, I have seen those desktops with over 100 files. But I also observed that people navigate them relatively efficiently because they know where the items is on the desktop using the position on the screen and the icon as rather effective visual hint. They often do not want to introduce folders because common GUI do not permit change the folder icon with minimal efforts. And they hate big time when something changes the order of the icons.
But when the number of files growths, folders and even sub-folders do appear. They are very add-hock and sometimes named so the folder would appear on a particular place on the screen that person uses as a navigational clue.
The tag systems that I have seen completely loose that visual hint about item being at a particular place. For example, a tag system cannot express the hint "to the left of the picture of a dog".
As others already pointed out, tags are brilliant for searching and accessing rarely used files or files from other users, but for navigating big personal working sets one often wants a stable ad-hock structure that has nothing to do with file content but rather reflects personal habits and clues of working with files.
Seigo: Plasma.next()?
Posted Jan 30, 2013 14:42 UTC (Wed) by zlynx (subscriber, #2285)
[Link]
It surely does matter where files are!
Windows Media Player always got this wrong for me. I've got media files that are local, on USB, and on the network. In tag views I get three identical looking file entries. But I only want the local files!
Seigo: Plasma.next()?
Posted Jan 31, 2013 3:38 UTC (Thu) by mathstuf (subscriber, #69389)
[Link]
> So instead, lets Consider 10k files but organized by metadata, activity and tags. Most of that information is automatically generated.
I usually navigate my music in players by tags, but the problem is something that puts 100 songs under the "Greatest Hits" album because it's a fairly common album name and then don't allow narrowing down by artist from there (because "Artist" is a "coarser" search than "Album", nevermind the fact that artists might collaborate on an album…).
Seigo: Plasma.next()?
Posted Jan 31, 2013 17:53 UTC (Thu) by mpr22 (subscriber, #60784)
[Link]
Amarok, at least, lets you permute artist and album either way round. (Of course, neither ordering deals gracefully with things like Fields of the Nephilim and Evanescence both releasing albums called Fallen.)
What I really want - and what none of the music player programs I've actually met seem to provide - is to sort "The Cure" under 'C' instead of 'T', while still presenting the name as "The Cure".
Seigo: Plasma.next()?
Posted Jan 31, 2013 17:56 UTC (Thu) by mathstuf (subscriber, #69389)
[Link]