|
|
Log in / Subscribe / Register

Seigo: Plasma.next()?

[Posted January 29, 2013 by corbet]

Aaron Seigo describes the development plans for the Plasma framework. "However, in Plasma Active we've made two purposeful decisions: do not expose the hierarchical file system (unless the use case dictates that as a requirement) and do not expose details that are not relevant to the usage of the device (e.g. I care that I can open that spreadsheet, it's less important at that moment that the application is Calligra Sheets). Thus to open a spreadsheet one opens the file manager and goes to Documents, or simply searches for the document from the Launch area directly. No file system, no application launchers."
to post comments

Seigo: Plasma.next()?

Posted Jan 29, 2013 15:13 UTC (Tue) by jpfrancois (subscriber, #65948) [Link] (5 responses)

What if there are several app to open a given file, and the default suck ? Should I go in some device configuration menu to specify the application.

Viewer != Editor

Premature Simplification is the root of all evil. All this 'The computer can magically find what you want to do' has already failed numerous time before.
I hope lesson have been learned and the computer program has more intelligence than previous attempt at helping the poor user by making wrong choice for him.

Seigo: Plasma.next()?

Posted Jan 29, 2013 15:20 UTC (Tue) by jpfrancois (subscriber, #65948) [Link]

Hmm, I am ashamed I did not read the entry before jumping to conclusion based on LWN's carefully chosen quote ;)

My viewer != editor problem is adressed (vaguely) in the paragraph below LWN's quote.

Seigo: Plasma.next()?

Posted Jan 29, 2013 17:08 UTC (Tue) by drag (guest, #31333) [Link] (3 responses)

> What if there are several app to open a given file, and the default suck ?

Change the defaults?

The application launching stuff is standardized pretty well. Change your defaults.list file and you should change the defaults for everything.

https://wiki.archlinux.org/index.php/Default_Applications

Seigo: Plasma.next()?

Posted Jan 29, 2013 19:11 UTC (Tue) by arekm (guest, #4846) [Link] (2 responses)

What if default sucks for some files and other variant suck for different files (eg pdfs with bunch of text (okular is nice for these) vs pdfs with huge svg (okular is crap for these)) ?

Seigo: Plasma.next()?

Posted Jan 30, 2013 10:16 UTC (Wed) by aseigo (guest, #18394) [Link]

the invention of possibilities, though unrealized in practice, is the #1 cause of UI erosion through feature extension.

we have yet to run into the possibility you highlight on devices. note that on desktop it is common, and the workflow there remains as it always has been as a result of that.

(this is why it is so important to keep in mind that we design for different F+I+U [form factor + input method + use case] when creating different Plasma Workspaces. yes, they share 98% of the code and are highly interoperable .. they also present different workflows appropriate to the F+I+U tupple. so the touch focused UI works differently from the desktop one in this case)

as for the touch case .. if we find that this indeed becomes an issue on tablet as well, then we will address it in the UI there. my expectation would be to go the route of something like "long tap to select an alternate viewer", but that's just an immediate thought pulled by from my rear facing protrusion ;)

Seigo: Plasma.next()?

Posted Jan 30, 2013 17:56 UTC (Wed) by drag (guest, #31333) [Link]

> What if default sucks for some files and other variant suck for different files (eg pdfs with bunch of text (okular is nice for these) vs pdfs with huge svg (okular is crap for these)) ?

Oh.

Well for Apple they 'solved' this problem originally years ago through their use of resource forks in the file system.

http://en.wikipedia.org/wiki/Resource_fork

The file manager would read the resource fork for a file and would launch the appropriate application when you opened a file. So while there were defaults for all the file types Mac OS would keep track of the application that created a particular file and things of that nature. That way the system could intuitively deal with applications on a per file basis.

I think Windows has some sort of mechanism for managing per-file stuff, but I don't know what it is.

And, of course, nothing I've noticed in Linux addresses this.

Seigo: Plasma.next()?

Posted Jan 29, 2013 15:22 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (52 responses)

> do not expose the hierarchical file system

I wonder who is exactly a target user of such a desktop that hides hierarchy. Clearly she is not a developer. But she also cannot be, say, a writer creating documents with videos and images. It is very natural to have one folder for such document where all the relevant stuff can be placed and that brings hierarchy and the need to effectively navigate it.

But if the target is a consumer who only occasionally needs to create something, that would be presumably OK. But those consumers can just have a tablet without any need for a desktop computer.

Seigo: Plasma.next()?

Posted Jan 29, 2013 15:26 UTC (Tue) by milliams (guest, #71641) [Link] (2 responses)

The information you are quoting absolutely does not refer to the desktop version of KDE's Plasma, only to "Plasma Active" the tablet version. If you read the blog post you would have seen this.

Seigo: Plasma.next()?

Posted Jan 29, 2013 16:03 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (1 responses)

Sorry, I have to write not tablets, but consumer-only devices.

Recently as an experiment I tried to use Nexus 7 to work with a few hundred of images and videos to see if the interface allows that (the hardware definitely does). It turned out with a default setup one cannot do that. Just opening a file was pain. To mitigate that I installed a file manager, and split the collection into folders based on a time stamp. Then it became manageable to the point of allowing to create a movie with several videos and slide-shows. However, as video editors for Android that I tried do not permit to insert all images from folder, creation slide shows was very time-consuming.

The bottom line is that I do not see how one can avoid hierarchy when composing documents or projects from other, potentially numerous, documents. And its a pity that the current development assumes that a touch interface is only for consumption and occasional simple modification of a single file rather than trying to explore possibilities for content creation/aggregation with it. There are things that one just cannot do efficiently with mouse/keyboard that touch in principle allows.

Seigo: Plasma.next()?

Posted Jan 30, 2013 10:20 UTC (Wed) by aseigo (guest, #18394) [Link]

I will repeat what I said below: Don't judge Active by Android/iOS limitations :)

I completely agree with your assessment that Android absolutely *blows* as a productivity environment. It's a fine phone UI, but for a "real" computer it falls very flat.

We're not emulating that system, but instead creating something that (we intend) to work well without being afraid to consider the use of concepts (such as non-hierarchical organization) just because other efforts got it horribly, horribly wrong.

it's like watching someone fall off their bike because they are texting instead of keeping their hands on the handlebar, smash their face into the ground due to a lack of helmet and then coming to the conclusion that you should never attempt riding a bike. how about just keeping your hands where they should be and wearing a helmet? :)

Seigo: Plasma.next()?

Posted Jan 29, 2013 15:50 UTC (Tue) by sebas (guest, #51660) [Link] (48 responses)

"No filesystem" does not mean "no ordering". In Plasma Active (not in Plasma Desktop, indeed, as milliams notes), the filesystem is not presented directly to the user. Rather, its file manager uses semantic information to order, present and search documents, images, etc. This semantic information can be its creation or modification date, but also tags you have assigned to it, or connection to a certain activity (which immediately makes your file easily accessible within that context, no searching even needed).

Of course you can still use a file browser and just go through your documents this way, but if you look at the Plasma Active UI as a whole, you will find that putting a "semantic" view central fits in very well (in fact much closer than many file system usages) with how you would naturally organise your "stuff".

The same features are also available in Plasma Desktop, where it serves as an add-on to traditional file system usage. You can for example connect any file to your current activity, and have files connected to this activity shown where you need them. You can even use a file manager to browse through your activities. It's a neat way to make multitasking saner, and if you don't use it, it doesn't get in the way.

Seigo: Plasma.next()?

Posted Jan 29, 2013 16:26 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (12 responses)

> you will find that putting a "semantic" view central fits in very well (in fact much closer than many file system usages) with how you would naturally organise your "stuff".

Consider a simple task: work with hundreds photos from a camera from the last trip. To manage the task a good starting point is to split photos into groups/folders with each group fitting on a screen. Doing that based on approximate timing with a file manager is very quickly even if one needs to move files between groups to get better semantic match between groups and the content. Then as each group fits on the screen, it is very easy to navigate between them and remove clearly bad photos.

The nice thing of such grouping is that it *quickly* creates a natural hierarchy, like whole-project-name/group-name/photo that allows later to find pictures by a trivial navigation in a file manager/open file dialogs. Again, the fact that group fits on the screen is rather important to avoid any scrolling while allowing image recognition in the brain to pickup the photo. So just by effortless initial setup I can locate an image among thousands using few clicks.

I see how the touch interface can help with such workflow. But can Plasma do it faster?

Seigo: Plasma.next()?

Posted Jan 30, 2013 10:23 UTC (Wed) by aseigo (guest, #18394) [Link]

> a good starting point is to split photos into groups/folders with each
> group fitting on a screen

and in Plasma Active you do that with tags.

which is even faster because you don't need to navigate back and forth, create a folder that shows along side files and then drag files things to it in the same view ... you just drag to an existing tag (or on to "new tag").

you can tag things with multiple tags. many of the photos probably have metadata put their by the camera. there are also tags the system can infer such as "mark all these photos as related to this activity".

when viewing, you select a relevant tag set (which can be 1 or more) and optionally a time slice.

so you get all the organizational power of folders without the drudgery of the folder UI or the limitations of single entry hierarchies.

Seigo: Plasma.next()?

Posted Jan 30, 2013 11:03 UTC (Wed) by bluebugs (guest, #71022) [Link] (5 responses)

What if you are using a nice photo camera linked to a GPS or if you have GPS track with time associated with your travel. Then you could imagine that the GPS information will get tagged automatically on the image. This way you will automatically group them by location. This would give a more accurate separation than timestamp, would be more accurate to what people do anyway at the end and fit the semantic approach quite well.

Seigo: Plasma.next()?

Posted Jan 30, 2013 12:27 UTC (Wed) by micka (subscriber, #38720) [Link] (4 responses)

The GPS unit is _of course_ disabled on my camera and my phone. I sometimes happy to share my photos, and the timestamp is (more than) enough information to leak.

Seigo: Plasma.next()?

Posted Jan 30, 2013 12:31 UTC (Wed) by micka (subscriber, #38720) [Link]

Can't edit, I forgot to add that it's usually better for the device battery duration.

Seigo: Plasma.next()?

Posted Jan 30, 2013 13:07 UTC (Wed) by bluebugs (guest, #71022) [Link] (2 responses)

This is a different problem. I wish that web browser where more responsible and propose to remove this meta data when uploading file. Hopefully a semantic aware environment would care about that. It is clearly a shame to restrict ourself localy just because of crappy tool.

Seigo: Plasma.next()?

Posted Jan 30, 2013 13:55 UTC (Wed) by micka (subscriber, #38720) [Link] (1 responses)

Well, I don't share my photos using websites either :)
And when I put them on a web reachable location, I don't do it with my browser (but they are access restricted anyway).

But when I share photos with others, I can't control what they will do with them, so I can't be sure they won't be uploaded somewhere.

Seigo: Plasma.next()?

Posted Jan 30, 2013 18:16 UTC (Wed) by raven667 (subscriber, #5198) [Link]

But tools to automatically strip sensitive metadata such as GPS tags make sense in any case because that is something anyone will rarely _want_ to share.

Seigo: Plasma.next()?

Posted Jan 30, 2013 11:28 UTC (Wed) by jospoortvliet (guest, #33164) [Link] (4 responses)

you would do the exact same thing on plasma active but the folders are called 'tags' and files are not constrained to being in a single 'folder'.

Seigo: Plasma.next()?

Posted Jan 30, 2013 12:06 UTC (Wed) by andresfreund (subscriber, #69562) [Link] (3 responses)

While tags are a nice, they don't really map nicely to everything. Exactly because there is no such constraint. Consider e.g. the storage location. On most tag based systems its incredibly ugly to copy data on internal storage to an SD card or the reverse.
To the point where google uses that as justification for not putting in SD card slots in their nexus phones...

Seigo: Plasma.next()?

Posted Feb 2, 2013 10:08 UTC (Sat) by jospoortvliet (guest, #33164) [Link] (2 responses)

As folders, no matter how you slice and dice it, are nothing else than a tag on a file, it's kind'a weird to claim that there is anything tags can't do but folders can.

There is no reason not to have (automatically assigned) tags which denote on which file system a file is, or which even represent a hierarchical relationship ("folders"). The fact that this is not done or not done properly doens't mean it can't be done.

Similar situation: Microsoft, Google and GNOME are trying to develop one UI which works on multpiple devices but are failing. Does that mean it is impossible and there is no way to share code/UI concepts between touch- desktop- mobile- and 10-feet devices? No, just look at KDE Plasma - which is doing exactly that (but a lot smarter, yes).

Seigo: Plasma.next()?

Posted Feb 2, 2013 13:00 UTC (Sat) by andresfreund (subscriber, #69562) [Link] (1 responses)

> As folders, no matter how you slice and dice it, are nothing else than a tag on a file, it's kind'a weird to claim that there is anything tags can't do but folders can.
> There is no reason not to have (automatically assigned) tags which denote on which file system a file is, or which even represent a hierarchical relationship ("folders"). The fact that this is not done or not done properly doens't mean it can't be done.

To quote yourself somewhere nearby:
> Now that is a lame reply. "Yeah, there IS a way to do it, it just can't actually do it".

Sorry, that was just too easy bait to let go.

And no, folders are different from a tags because files are only stored in one location (and no, don't argue with hardlinks, that doesn't change anything). You could possibly do it by inventing some sort of tag category and only allowing one tag of that category (e.g. location:device/path) but designing a good ui ontop of that isn't all that easy.

I have yet to see any tag based system that deals with different storage devices graciously without resorting to a folder based system for that part.

Seigo: Plasma.next()?

Posted Feb 11, 2013 10:02 UTC (Mon) by jospoortvliet (guest, #33164) [Link]

Sorry, that was just too easy bait to let go.

Yeah, but it's not the same thing. This can do it ;-) And yes, folders are the same thing, they're just a property on the file system. Which stores stuff in inodes organized in RB trees or stuff like that - the physical location has no relation to the directory hierarchy. True that a file can have multiple tags but as I said, the fact that you haven't seen any system working with it doesn't mean it isn't possible. I haven't had a good look at how the PA guys do it but I do look forward to seeing it ;-)

Seigo: Plasma.next()?

Posted Jan 29, 2013 16:43 UTC (Tue) by dskoll (subscriber, #1630) [Link] (13 responses)

you will find that putting a "semantic" view central fits in very well (in fact much closer than many file system usages) with how you would naturally organise your "stuff".

No. I naturally organize my "stuff" hierarchically and I hate tag-based ways of organization. I also hate "semantic" views because what the view author considers to be important semantics might not be what I do.

By all means, offer the choice of tags and semantic organization to those who want it. But don't hide the file system or demote it to second-class status.

In my experience, tags are great for searching, but not for organizing. They are two completely different use-cases.

Seigo: Plasma.next()?

Posted Jan 29, 2013 17:05 UTC (Tue) by Tara_Li (guest, #26706) [Link] (12 responses)

Yeah, let's look at this "semantic" stuff and how it can even apply to something as simple as a file list...

Ok, we've got a bunch of files from some random image site.

-----
1.jpg
01a.jpg
0000001b.jpg
001c.jpg
1g.jpg
-----

Now, your nice "semantic" thing has slipped in here - since leading zeros are ignored in computing the value of a number - let's just ignore them when we're sorting the files! According to Nautilus - those filenames are in order! (And no, setting collating order, language or anything else I can find fixes it...)

Except, well, leading zeros are dropped when they're *NUMBERS* - why should they be ignored for sorting file *NAMES*?

Seigo: Plasma.next()?

Posted Jan 29, 2013 18:37 UTC (Tue) by mgedmin (guest, #34497) [Link] (8 responses)

I'm pretty happy that Nautilus lists these files in this order:

slide1.png
slide2.png
...
slide9.png
slide10.png
slide11.png
...

Are you saying this sorting order doesn't make sense to you, and you'd prefer a strict lexicographical order, i.e.

slide1.png
slide10.png
slide11.png
...
slide19.png
slide2.png
...
slide9.png

?

Seigo: Plasma.next()?

Posted Jan 29, 2013 18:49 UTC (Tue) by Tara_Li (guest, #26706) [Link] (2 responses)

Yes - yes I am.

Seigo: Plasma.next()?

Posted Jan 30, 2013 16:56 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Wyhat happens if I'm trying to number months? This EXACT problem bit me ...

1041_JAN
1052_FEB
...
...
113A_OCT
114B_NOV
115C_DEC

That's the order I *want*. Except the order I *get* thinks that October comes before January ...

Just because the computer thinks that A is not a number, doesn't mean I'm not counting in hex...

Cheers,
Wol

Seigo: Plasma.next()?

Posted Jan 31, 2013 4:01 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

This sounds like some metadata that could go into a .directory file beside the files. Now if only `ls` would read those as well…

I certainly don't want a file browser sitting there for 5 minutes trying to figure out that I format filenames by "%Y%b%0d, %a, %H%M%S - description" for some directory and sort accordingly if I can just give it that information.

File sort order

Posted Jan 29, 2013 21:19 UTC (Tue) by dskoll (subscriber, #1630) [Link] (3 responses)

(Re sorting slide19.png before slide2.png)

It should give you the option.

I tend to live in the terminal and not use file browsers, but I think a canonical sorting order used by all File Open dialogs, file browsers, and the like should be observed. It should be a desktop setting that all clients obey.

File sort order

Posted Jan 30, 2013 0:48 UTC (Wed) by Company (guest, #57006) [Link] (2 responses)

The KDE solution to all of life's problems: Give users an option!

File sort order

Posted Jan 30, 2013 3:14 UTC (Wed) by dskoll (subscriber, #1630) [Link] (1 responses)

The KDE solution to all of life's problems: Give users an option!

And a very good solution it is, too. Much better than the GNOME solution which is "Don't give users any options."

File sort order

Posted Jan 30, 2013 3:44 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]

I would say neither is entirely true and neither is always give a good thing to do. Sometimes pushing the choice to end users is absolutely the wrong thing and I think KDE does that way too often and GNOME has gone the other direction too much as well although compared to prior versions within the major release, there has been some course corrections. Personally, I would love to see more focus on sharing interfaces and low level implementations such as standardizing on default ordering of apps in a cross desktop way

http://www.freedesktop.org/wiki/Specifications/mime-actio...

Seigo: Plasma.next()?

Posted Jan 30, 2013 7:14 UTC (Wed) by callegar (guest, #16148) [Link]

But should filenames be exposed at all in this approach? Aren't them just another filesystem detail? The names automatically given to files by cameras, which are usually totally meaningless for a human show that it can be so. Isn't the name just another tag? Shouldn't files like those in the previous example be identified by queries like "type is slide and progressive is 02" rather than by "slide02.xyz"? When one creates a new file or document, at the time of saving shouldn't the user be asked just for tags and attributes instead of a filename? And is the filesystem the best way to store things in this approach? Wouldn't it be better to reserve the filesystem for the OS files (that are historically organized in this way) and use a database for all the user data?

Seigo: Plasma.next()?

Posted Jan 29, 2013 23:37 UTC (Tue) by renox (guest, #23785) [Link] (2 responses)

1) I don't see the link with semantic here
2) One easy way to solve your issue is to allow the user to sort the files by 'alphanumerical' or 'alphabetical' order.

Seigo: Plasma.next()?

Posted Jan 30, 2013 0:52 UTC (Wed) by Tara_Li (guest, #26706) [Link] (1 responses)

The order is semantic - ordered by parsed and extracted meaning, rather than simply by what it *is*.

Seigo: Plasma.next()?

Posted Jan 30, 2013 10:33 UTC (Wed) by renox (guest, #23785) [Link]

> The order is semantic - ordered by parsed and extracted meaning, rather than simply by what it *is*.

Wrong: what you have is a string and there is no only one way to parse it, so it's up to the user to select the correct way, usually the alphanumerical is the correct default but not always.

Seigo: Plasma.next()?

Posted Jan 30, 2013 3:27 UTC (Wed) by shmerl (guest, #65921) [Link] (20 responses)

I'm fine with this approach as far as one can would be able to switch between semantic view and regular filesystem view in the same mobile application. I don't want to install touch unfriendly Dolphin just for the sake of viewing the filesystem. One simply can't avoid using the filesystem view for operations like moving or copying files, explicitly accessing different directories for whatever reason and so on. Both use cases are legit, and in spirit of KDE user should have an option what view to chose.

Seigo: Plasma.next()?

Posted Jan 30, 2013 10:30 UTC (Wed) by aseigo (guest, #18394) [Link] (19 responses)

"One simply can't avoid using the filesystem view for operations like moving or copying files"

from where to where?

if you mean between storage devices (e.g. internal storage and a connected USB stick or an SD card) that is already supported in the Files application. each device has an entry at the top and you can drag things to it.

if you mean between directories on the device, the question then becomes: what is the use case? the valid use cases we've come up with are so far all in the edge case, and so we do not optimize for it.

you can go into a specific directory, however, by running a search for the directory and then pressing/clicking on the folder in the results. voila, hierarchical browsing begins. it just isn't what the UI is optimized for in terms of common usage .. because for common usage that mechanism is slower and less useful than the metadata system.

design is hard. it means stepping back and examining the "why" behind the things we desire; identifying the use case(s) behind the mechanisms; challenging ourselves to come up with better ideas rather than default to the least-worst thing we already have. that all requires a lot of thought, a lot of discarded ideas (few of the ideas in Active were our first attempts :) and a high amount of domain knowledge. so it does not surprise at all that the above is not immediately obvious .. until one uses the results of that process and finds it actually works ;)

cool discussions here so far, in any case!

Seigo: Plasma.next()?

Posted Jan 30, 2013 12:01 UTC (Wed) by dskoll (subscriber, #1630) [Link]

if you mean between directories on the device, the question then becomes: what is the use case? the valid use cases we've come up with are so far all in the edge case, and so we do not optimize for it.

I guess I must be an edge-case in my entirety which explains why I find your software so non-optimal.

Yes, shiny new ideas can sometimes be good. But sometimes old ideas are also good and throwing them out or making them harder to access makes software worse.

Hierarchical organization

Posted Jan 30, 2013 13:48 UTC (Wed) by dskoll (subscriber, #1630) [Link] (16 responses)

Let me expand on why hierarchical organization is incredibly useful.

Take a collection of photos. Organizing it with tags assumes that we'll actually take the trouble to tag the photos. Raise your hand if you've ever sat down to 500 holiday snaps and relished the thought of classifying them. Thought so.

On the other hand, I can pretty quickly find the photo I need using my file system hierarchy. I know that it's likely to be in Albums/2012/08-Trip-to-Zurich. I also know that by changing into that directory, I'm not going to see extraneous photos... I can shut out the rest of the world from my visibility, reducing clutter.

In effect, by dumping my holiday snaps in that directory, I have mass-tagged them all at once, without any need for assistance from the UI. Merely copying the files serves to categorize them.

Now, take backups. If I don't know where all my files are, how do I know what needs backing up? Yes, the UI can help with a dedicated backup tool, but suppose some random app drops files in a location the UI tool doesn't know about... what then? If I know where my data is, I can feel confident in my backups. If I don't, then I have no idea.

And suppose I lose a particular file and want to restore it from backup. How do I do that? I don't know where it is, either originally or on the backup volume. I'm drowning in a sea of tags with no location information.

The human brain seems to be hard-wired for hierarchical classification systems. Try to convince biologists to abandon their classification system for species. Sure, there may be disagreements about where on the hierarchy a particular species belongs or even small disagreements about how the hierarchy should be organized, but no-one seriously proposes abandoning it. It has proved incredibly useful. Similar classification systems abound in most human endeavours.

design is hard.

Yes, it is. And if you plan on bucking the trend established by decades of computer science and hundreds of years of human progress, you'd better have a pretty good flame-proof suit. :)

Hierarchical organization

Posted Jan 30, 2013 16:55 UTC (Wed) by aseigo (guest, #18394) [Link] (14 responses)

> Organizing it with tags assumes that we'll actually take
> the trouble to tag the photos

I think you're assuming tagging is harder than dragging it to a folder. In the Files app, it isn't. It's the exact same motion: select, drag, drop. Voila. (There's a "New" entry at the top to create new tags as well)

> I can shut out the rest of the world from my visibility, reducing clutter.

exactly how tags work. press on the tag(s) you care about and voila, the rest of the world is shut out from your visibility

> Merely copying the files serves to categorize them.

"default tag as part of the copy process" is one of the workflows we've sketched out but haven't yet fully implemented. it's pretty easy already, but once that is completed it will be as easy as your "copy 'n dump"

> Now, take backups. If I don't know where all my files are, how do I know
> what needs backing up?

files remain in your home directory. they aren't magically hidden in a wormhole between the sectors on the disk ;)

and for such backups, i'd recommend taking the metadata with the files as well. (well, for the metadata that isn't already in them, of course)

> UI can help with a dedicated backup tool,

all backup tools are "dedicated backup tools" in the sense you describe. except they are dedicated to raw fs hierarchy. i agree we need some spiffy backup/restore software (first syncing tools are landing in PA4, btw), but that will be no different than any backup software used.

the caveat indeed is that if you are using the metadata system, and then you want to go around and micromanage manual backups it won't be as smooth as it would be. that's a definite trade off.

the goal / assumption is that in the case of Active by using the system that, um, you're using you won't need to go to those lengths. which leaves your use case in the "edge case" category.

i will be the first to admit that the tablet interface in Active may not be for everyone. we're not trying to make something acceptable for everyone, because that usually means great for, statistically speaking, nobody.

if you find the semantic metadata system so inconvenient on your tablet (though i still suggest you may be surprised!), then i can offer a few options: don't use Plasma Active on it ;) .. or use (or make!) a more "normal" touch friendly file manager (i already know of one being written with QML, btw) ..

> but suppose some random app drops files in
> a location the UI tool doesn't know about

no such thing. all user-writable files are indexed.

> And if you plan on bucking the trend established by decades of computer
> science and hundreds of years of human progress,

ah, but you see here's where you're rather wrong. hierarchical file systems were designed for technical uses and users and within the limitations of computers (both in terms of hardware performance *and* in terms of data volume and variety). computer science has moved on some time ago from hierarchical systems. we merely need to point to google.com to find an example.

what hasn't changed is the implementation facing the user. this is particularly noticeable on mobile devices where there have been two approaches: ignore it and expose hierarchies all over the place; try to hide the file system and eviscerate the applications in the process (which you can get away with on systems that don't have high file management demands such as phones, at least for most people). mobile is a distinct use case from the desktop and the hierarchical systems just become more and more awkward there.

besides a couple decades of accumulated usability research to touch upon, we actually do user testing. at times that testing comes back with negative results and we adjust accordingly until we get positive results. so we're not shooting entirely in the dark, nor creating a self-serving echo chamber. we're probably more critical of what we do than most on the outside ... which leads to results that we are relatively confident about once they get this far :)

> you'd better have a pretty good flame-proof suit.

yeah, no problem there.

Hierarchical organization

Posted Jan 30, 2013 18:09 UTC (Wed) by dskoll (subscriber, #1630) [Link] (2 responses)

I think you're assuming tagging is harder than dragging it to a folder.

In my workflow, it is. Here's how I copy files:

cp /media/disk/*.jpg /target

I don't use "motion", "select", "drag" or "drop". And I use "directories", not "folders", so get off my lawn! :)

I think the rest of your post is simply your opinion (as, I suppose, are my points.) So we will have to agree to disagree.

Hierarchical organization

Posted Jan 30, 2013 20:11 UTC (Wed) by jospoortvliet (guest, #33164) [Link] (1 responses)

seriously, you use only command line on your tablets? Oh, you're not talking about a touch-only interface? Then what are you arguing about, as you must have noticed that Aaron was very clear on the fact that Plasma Active is for touch devices, while Plasma Desktop is for - surprise - desktops...

Hierarchical organization

Posted Jan 30, 2013 23:38 UTC (Wed) by dskoll (subscriber, #1630) [Link]

seriously, you use only command line on your tablets?

I don't own a tablet. I do own a Nokia N-900 touchscreen phone, and while I don't use only the command line on that device, I do use it quite a bit.

Plasma Active is for touch devices

The N-900 is a touch device, but still has a hierarchical file browser for which I'm grateful.

Hierarchical organization

Posted Jan 30, 2013 18:11 UTC (Wed) by dskoll (subscriber, #1630) [Link] (3 responses)

I see you did not reply to one of my questions:

How do I restore a specific file from backup without knowing where in the directory hierarchy it is?

In my experience, this is an uncommon thing to want to do, but not so rare as to be labelled an "edge-case".

Hierarchical organization

Posted Jan 30, 2013 18:32 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Actually I would say this is the most common case. In my experience, accidentally deleting an important file is the leading cause of restores from backup.

Hierarchical organization

Posted Jan 30, 2013 18:54 UTC (Wed) by hummassa (guest, #307) [Link] (1 responses)

IMHO the answer to this question is: "the backup/restore tool must offer the same view of the backed-up data as the viewing tool offers for the original data".

Hierarchical organization

Posted Jan 30, 2013 19:21 UTC (Wed) by dskoll (subscriber, #1630) [Link]

IMHO the answer to this question is: "the backup/restore tool must offer the same view of the backed-up data as the viewing tool offers for the original data".

That's fine if all the systems you might conceivably connect the backup device to run the same software. But once you move beyond hierarchical directories, that is unlikely to be the case.

Yes, a hierarchical directory structure full of files is the "lowest common denominator". But importantly, it's the lowest common denominator and is likely to be useful on any device or desktop.

Hierarchical organization

Posted Jan 30, 2013 18:34 UTC (Wed) by dskoll (subscriber, #1630) [Link] (6 responses)

computer science has moved on some time ago from hierarchical systems. we merely need to point to google.com to find an example

I'm not sure what you mean by that. Could you elaborate?

If you mean Google as a search engine, then yes: Hierarchical classification systems are not useful for searching. But doing a Google search is in no way analogous to organizing my files and documents.

Hierarchical organization

Posted Jan 30, 2013 20:16 UTC (Wed) by jospoortvliet (guest, #33164) [Link] (5 responses)

It's 2013 and you claim to not know what Aaron means when he says we've bumped into the limits of hierarchical organization, pointing at Google... You must've noticed the demise of 'hierarchical search engines' on the web?

Search is search. You can use a hierarchy to find things, but this scales badly. That's why computer science has moved on to other search methods - indexing and analysis of links between pages is what google used to do. Full text indexing, metadata-extraction, semantic analysis, tracking of user habits and explicit tagging is what Plasma Active uses. These technologies might be a tad more complicated than a simple hierarchy but they scale beyond the 1.44 mb floppy disk.

And again, in case you still don't understand it - nothing gets lost, as 'folders' (hierarchical or not) are nothing else than exclusive labels.

Note how Gmail (which uses tagging) works just fine with IMAP (which uses folders): mails which have multiple tags just show up in all the 'folders' in traditional UI's. Works just fine.

Hierarchical organization

Posted Jan 30, 2013 21:45 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

> Note how Gmail (which uses tagging) works just fine with IMAP (which uses folders): mails which have multiple tags just show up in all the 'folders' in traditional UI's. Works just fine.

however, you note that people still use the concept of folders (and sub-folders) to navigate the tags.

You could do exactly the same thing with traditional IMAP servers via single-instance-store of the file at multiple places in the filesystem.

Hierarchical organization

Posted Jan 31, 2013 3:18 UTC (Thu) by raven667 (subscriber, #5198) [Link] (1 responses)

I'm not sure what you are describing is functionally or technically different than tags, it's just semantically different. Well, trying to shoe-horn a filesystem (with hard-links for example) into a tagging system brings along baggage such as enforced parent/child relationships that artificially constrain and complicate the system and should probably be worked around by using something designed for tags.

Hierarchical organization

Posted Jan 31, 2013 4:58 UTC (Thu) by dlang (guest, #313) [Link]

my point is that tags are not something magic that achieve things that could never have been done before, and they don't require you to throw away the filesystem info.

Tagging is extremely useful to supplement filesystem location info, but trying to have it substitute for that info is wrong.

Hierarchical organization

Posted Jan 30, 2013 22:43 UTC (Wed) by dskoll (subscriber, #1630) [Link] (1 responses)

Search is search

Search and categorization are two separate things. My collection of files is not a massive glob of data that I content-search very often.

I'm all for indexing, full-text searching, etc... bring it on!

But don't hide the hierarchy as if it's some ugly stepchild.

Hierarchical organization

Posted Feb 1, 2013 20:41 UTC (Fri) by pboddie (guest, #50784) [Link]

The funny thing is that the Internet as searched by Google is organised hierarchically. It's just that Google exposes it through terms produced by their indexing activity. And when someone wants to access a specific resource, and especially update such a resource, they typically don't navigate to it by trying to fish it out using a combination of search keywords. It isn't a matter of "scp article.html editor@[linux,news,lwn,latest]" and hoping that it connects to the right place.

One can argue that this hierarchical organisation is imposed by physical constraints and that beyond the first level, one could use tags, terms, categories or whatever just as successfully as a path to a particular resource, but the issue is convenience for the specific task being performed.

Hierarchical organization

Posted Jan 30, 2013 18:53 UTC (Wed) by Wol (subscriber, #4433) [Link]

Just to add, I have a perl script that parses the exif data, and puts all my photos into dated directories. I then add a tag to the directory ... so the same sort of thing :-)

Although I will add that if I put photos on a tablet, that's not my primary copy :-)

Cheers,
Wol

Seigo: Plasma.next()?

Posted Jan 30, 2013 20:13 UTC (Wed) by shmerl (guest, #65921) [Link]

Example - I want to organize my books/photos/music etc. in directories, in order to be able to use the same structure across various devices (some of them can have very different semantic approaches, not compatible tagging and etc.). Directory structure remains one solid interoperable organization approach since filesystem abstraction is virtually the same across most OSes (especially POSIX ones).

So, I need to be able to easily do the following:

1. Creating / deleting directories.
2. Moving files / directories to another directory.
3. Renaming files / directories.
4. Creating files knowing which directory they go to after the creation.

Doing search on directory name to access it in the interface sounds rather awkward to me and very non optimal from usability perspective. I'd prefer just to ssh to the device from another computer and move stuff in the terminal, rather doing the above. You once noted, that device is supposed to be for the user (make play live) and not forcing user into some predefined consuming mode. It means there should be no artificially imposed deficiencies which hinder the workflow. Usual KDE approach (at least on the desktop) differed from Gnome in a sense that KDE didn't dictate "the right way" forcing all users either to bend or to leave. Rather KDE offered some sensible (from designers' perspective) defaults, with giving an option to do things differently, if there is a real need for it. I consider it a major plus for user friendliness in KDE. Why should Plasma Active be devoid of the same user treating.

So the way I see it - Files should offer both modes with easy way to switch between them. Triggering filesystem view mode using Search method doesn't sound normal at all.

Seigo: Plasma.next()?

Posted Jan 29, 2013 17:32 UTC (Tue) by hitmark (guest, #34609) [Link] (2 responses)

So Plasma Active will follow iOS and Android down the rabbit hole?

One argument Google has fielded for leaving out SD cards in their recent Nexus devices are that people can potentially be confused about where their images and such end up. this again because they are not exposed to the file system, but instead is supposed to interact with the images files via the camera and gallery apps.

IMO, that path leads to madness.

Seigo: Plasma.next()?

Posted Jan 29, 2013 20:45 UTC (Tue) by ibukanov (subscriber, #3942) [Link] (1 responses)

Few clicks in Goggle Play on Android devices allows to install a file manager that presents the file hierarchy both when used a standalone application and as a file open dialog.

But I agree with you, the default setup is madness.

Seigo: Plasma.next()?

Posted Feb 9, 2013 16:24 UTC (Sat) by hitmark (guest, #34609) [Link]

While true, said apps will not be even considered when Google make future changes. Android 3.1-3.2 introduced MTP and in the process changed the SD card (no helping that confusingly the internal storage is referred to as the SD often thanks to a hackaround by various companies to try match the Apple induced fad of large internal storage spaces) mounting defaults permissions to read only unless you were part of the preinstalled apps group.

This was done silently and caught a large number of users off guard when updating their shiny tablet from 3.1 to 3.2. While in 3.1 they could use the file managers to write random files to the card in the slot, 3.2 just gave access denied errors. And this even tho the UNIX rights looked ok.

The workaround seemed to be to go via the MediaStore database, the supervisor of the MTP implementation in Android, and in essence pretend that the file came from a computer attached via USB. But even when done that way, you could not delete files, or directories, once created...

Never mind that said database had a bad habit of getting silently out of sync if you used a file manager on the internal storage area (that infuriatingly still carried the old RW permission system, confusing users even further towards thinking the issue was a broken SD card rather than Android changes). Meaning that what a computer would see via MTP, and the actual state of the Android device, may not line up at all.

And i fear that future Android changes will likely bring more of this, thanks to the policy that the user should not touch the FS.

Seigo: Plasma.next()?

Posted Jan 29, 2013 17:58 UTC (Tue) by aseigo (guest, #18394) [Link] (39 responses)

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 :)

Seigo: Plasma.next()?

Posted Jan 29, 2013 18:41 UTC (Tue) by pboddie (guest, #50784) [Link] (4 responses)

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] (3 responses)

> 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.

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-wor...

(randomly selected .. :)

Seigo: Plasma.next()?

Posted Jan 30, 2013 15:35 UTC (Wed) by pboddie (guest, #50784) [Link] (2 responses)

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] (1 responses)

> 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 (guest, #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 (guest, #26706) [Link] (2 responses)

> 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] (1 responses)

> 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] (30 responses)

> 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] (29 responses)

> 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] (10 responses)

> 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] (1 responses)

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 (guest, #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] (4 responses)

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] (1 responses)

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] (1 responses)

> 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.

[1]https://github.com/adrian-bl/vanilla

Seigo: Plasma.next()?

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] (13 responses)

> 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] (12 responses)

> 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] (3 responses)

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 (guest, #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 (guest, #4806) [Link] (1 responses)

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] (6 responses)

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 (guest, #33164) [Link] (5 responses)

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] (4 responses)

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] (1 responses)

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 (guest, #33164) [Link] (1 responses)

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 (guest, #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] (2 responses)

> 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] (1 responses)

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]

Like this[1]? (From Vanilla Player).

[1]http://imgur.com/wA8drjC

Seigo: Plasma.next()?

Posted Jan 31, 2013 16:37 UTC (Thu) by Aliasundercover (guest, #69009) [Link] (4 responses)

When I see words along the lines of "not expose the hierarchical file system" I anticipate the need to learn yet another file system with new and different rules and methods. The need for a file system never goes away, we must store things and find them again. Perhaps a simple and constrained appliance can benefit from a focused design. Still, different always starts out behind as existing knowledge and habits don't apply.

Personally I hate tags and like the hierarchical design. I like grouping corresponding things together and being able to handle them all as a unit. That and a name is usually all I need. Entering or managing tags is unwelcome.

Ever notice how every microwave oven is different from every other one? They seem to burn out once a season in my office so we get to see lots of different ones. They are all so different only the most dedicated lunch cookers bother learning how to do more than turn them on and off. The latest one even takes some fishing around to find which button means off assuming one does not want to trust the safety interlock and simply open the door in frustration. I think the people who design these things have a club. Anyone who makes a new microwave oven to work like an old microwave oven gets thrown out of the club in shame.

The hierarchical file system is a great success in computing. I wish designers would embrace it, not try to hide it in shame.

Seigo: Plasma.next()?

Posted Feb 1, 2013 14:21 UTC (Fri) by HelloWorld (guest, #56129) [Link] (3 responses)

Tags offer a superset of the functionality that a hierarchical structure can offer, because a file's path (including its name) can be seen as simply another tag. "list the contents of directory /foo/bar" then becomes "list all files whose path tag begins with /foo/bar/". So in fact, you're already entering and managing tags.

otoh, in a hierarchical structure it's often not clear where a file belongs. Where do I put the images that belong to my bachelor's thesis, in ~/thesis or in ~/images? This kind of thing crops up all the time.

Seigo: Plasma.next()?

Posted Feb 1, 2013 20:20 UTC (Fri) by dlang (guest, #313) [Link]

> Tags offer a superset of the functionality that a hierarchical structure can offer, because a file's path (including its name) can be seen as simply another tag.

This is true, but what people are objecting to is tagging and depriciating the filesystem hierarchy.

I don't think anyone is objecting to tags being available (they just question how well they work in practice, with examples of when they don't)

Seigo: Plasma.next()?

Posted Feb 4, 2013 15:56 UTC (Mon) by micka (subscriber, #38720) [Link]

> Where do I put the images that belong to my bachelor's thesis, in ~/thesis or in ~/images

Very clearly ~/thesis, because I don't want to see the images related to my thesis with my hinking photos.

Actually, their location is also constrained because the build system for my thesis expects them at a specific place.

> because a file's path (including its name) can be seen as simply another tag

But sometimes, a specific case is easier to understand and use than the general case. And I think that's the case for hierarchy compared to tags.

Seigo: Plasma.next()?

Posted Feb 13, 2013 20:28 UTC (Wed) by hasard (guest, #47410) [Link]

I would not like to use tags the way you suggest:

$ find ~/ -mindepth 2 -type d | wc -l
20575

This indicates that (even not counting the base level of the hierarchy to avoid counting all the .config/ directories), I would have to deal with a flat list of 20575 tags. On the other hand, in each directory I most of the times do not have more than about ten or twenty objects (some may be directories).

Using a flat list of tags works well if their number can be kept reasonably low. Once their number grows, hierarchy becomes useful again (gmail uses hierarchical tags for instance).


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds