User: Password:
|
|
Subscribe / Log in / New account

Seigo: Plasma.next()?

Seigo: Plasma.next()?

Posted Jan 29, 2013 15:50 UTC (Tue) by sebas (subscriber, #51660)
In reply to: Seigo: Plasma.next()? by ibukanov
Parent article: Seigo: Plasma.next()?

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


(Log in to post comments)

Seigo: Plasma.next()?

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

> 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 (subscriber, #71022) [Link]

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]

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 (subscriber, #71022) [Link]

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]

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

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]

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

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]

> 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 (subscriber, #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]

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

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 (subscriber, #34497) [Link]

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

Yes - yes I am.

Seigo: Plasma.next()?

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

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]

(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]

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]

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 (subscriber, #23785) [Link]

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

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 (subscriber, #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]

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]

"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]

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]

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

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

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]

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 (subscriber, #307) [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".

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]

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

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 (subscriber, #313) [Link]

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

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 (subscriber, #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]

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 (guest, #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.


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