Why is there a TV icon in Microsoft Word?
-
I venture that you're going to find a hell of a lot more "Contracts" and "Resumes" and "Tax Returns" and "Expense reports" on most people's computers than you'll ever find any sort of correspondance (mail clients excepted - and in this case the "Organize by date" model works because that's how human correspondance works - the latest supercedes the oldest). The content of these things is almost ENTIRELY meaningless in terms of identifying the actual document. In this case, you're likely to find multiples of each, each with sytactically small variations, but semantically separated by worlds - and in only one of these cases is versioning actually relevant to making sure you get the "right one".
Yes, a proper document management system will eschew filenames in favor of metadata identifying a file as a contract with Foobar Inc. for project #83783 which pertains to building shittyapplication.example.org, but these systems are expensive, difficult to administrate, and even harder to get users to utilize consistently - far beyond the realm of anything anybody except the most OCD among us are going to be willing to do on their own - so "shittyapplication.example.org_Contract.docx" it is. What the fuck purpose does knowing what date you wrote a contract serve? Why should you have to memorize legal boilerplate from each specific document? What if you have many, many contracts with the same company? Filenames allow the layman to create their own organizational pattern that works for their own documents. It's ad-hoc, but it's highly effective if the user opts to do it. Granted, many of them don't, but these are typically the people who write emails in Microsoft Word and still save to floppy disks....
.... FULL CIRCLE BITCHES!
-
@Aaron said:
Privacy issues dictate the need to be able to clear this history, otherwise somebody else would be able to see every change you'd ever made.
You're doing something horribly wrong. There is a reason all modern OSes are able to create multiple users.
-
@Justice said:
@derula said:
It's perfectly appropriate in LucasArts point&click adventures and others where you can't die or get stuck.
FTFY.
Now ok, you might say those are the only "right" games, and I'll admit Monkey Island was loads of fun.Ironically, you can die in Monkey Island.
-
@Lingerance said:
@Aaron said:
Privacy issues dictate the need to be able to clear this history, otherwise somebody else would be able to see every change you'd ever made.
You're doing something horribly wrong. There is a reason all modern OSes are able to create multiple users.He's talking about sharing the file with other people, in which case they would see all of the history.
-
@Justice said:
@bstorer said:
@Justice said:
Now ok, you might say those are the only "right" games, and I'll admit Monkey Island was loads of fun. But in every other type of game, it is extraordinarily annoying when you accidentally lose some important item, or use all your grenades fighting the first two forms of the final boss and don't have any left for the third form, or spend all your money on the wrong items, and the stupid game says "Autosave!" leaving you saying "OH SHI-" and then quietly sobbing in the corner. Or something like that.
No form of auto-save well help you in the Sierra adventure games, where failing to pick up a toothpick two minutes in will leave you unable to complete the game, though of course the game won't mention that to you.
Well, at least you won't have to replay the first two minutes...
Sierra seems to follow the same school of game design as Battletoads or Super Mario Bros. 2 (Japanese version), where instead of thinking up interesting challenges, they just say "how much of a jerk can we possibly be to the player?" Sometimes that still works out ok, but it takes a whole lot of fun to make up for it.
I'd actually been thinking of more recent titles. For example, a friend of mine was griping about the autosave in GTA 4, which apparently screwed him over completely by auto-saving after a mission, even though he'd accidentally killed a character that was important to a side plot. I think he'd adopted my manual revision control style of game saving, which helped, but he still lost a huge amount of progress.
There are plenty of arguments to be had about "proper" game design, "realism," and all the other crap we've been bickering about since the NES, but my overall point is this: be it in games or application software, if you don't have some way to undo that boneheaded mistake you just made, then you've lost half the point of having a save function in the first place.
QFT
-
@derula said:
@Justice said:
@derula said:
It's perfectly appropriate in LucasArts point&click adventures and others where you can't die or get stuck.
FTFY.
Now ok, you might say those are the only "right" games, and I'll admit Monkey Island was loads of fun.Ironically, you can die in Monkey Island.
Unless I'm mistaken, the only way to die in Monkey Island is to stay 10 minutes in a specific screen from which it is rather easy to escape. And presumably the game wouldn't autosave just when you are about to die, but rather before you end up in that screen.
-
@tdb said:
Unless I'm mistaken, the only way to die in Monkey Island is to stay 10 minutes in a specific screen from which it is rather easy to escape. And presumably the game wouldn't autosave just when you are about to die, but rather before you end up in that screen.
i think you can walk off the cliff as well ...
-
@Nelle said:
@tdb said:
Unless I'm mistaken, the only way to die in Monkey Island is to stay 10 minutes in a specific screen from which it is rather easy to escape. And presumably the game wouldn't autosave just when you are about to die, but rather before you end up in that screen.
i think you can walk off the cliff as well ...Yeah, but you're saved by a rubber tree.
-
@Aaron said:
Local media and even online media is fast now; do we really need to keep foisting the antiquated concept of hierarchical file systems on paying customers?
Bright-eyed idealistic visionaries have been trying to get away from hierarchies for as long as recorded human history.
It always ends badly.
-
@Justice said:
Video games have had auto-save for a long time, and it's incredibly annoying when the game auto-saves your screwups in a misguided attempt to be helpful.
Going back to the last save is for wimps. If you screw up, you start over.. Yes, even if you didn't mean to walk into that floating eye.
-
@derula said:
@Nelle said:
And then you use a monkey's tail to loosen a screw because in English the name of the tool is "monkey wrench".@tdb said:
Unless I'm mistaken, the only way to die in Monkey Island is to stay 10 minutes in a specific screen from which it is rather easy to escape. And presumably the game wouldn't autosave just when you are about to die, but rather before you end up in that screen.
i think you can walk off the cliff as well ...Yeah, but you're saved by a rubber tree.
Games containing stupid play on words that don't work outside of English should not be sold to 14 years old non-native English speakers :-(
-
@bjolling said:
Games containing stupid play on words that don't work outside of English should not be sold to 14 years old non-native English speakers :-(
I disagree. Sierra adventure games helped me lot with learning english when I was young. Now I'm fluent which makes it easy to troubleshoot over the phone. The conversation goes a little like this:Customer: "Hi my screen is blank. I can't see anything."
Me: "Look Computer"
"The computer is off"
"Turn on PC"
"That does not compute"
"Turn on computer"
"You press the power button. It wont turn on."
"Fuck"
"That does not compute"
"Look room"
"The room is dark. The power is off"
and so on and so forth...
Incidentally if you get the above dialog, then you're old.
-
@DOA said:
I disagree. Sierra adventure games helped me lot with learning english when I was young. Now I'm fluent which makes it easy to troubleshoot over the phone. The conversation goes a little like this:
This has made my day. I never thought about support calls this way and will now think of this every time I'm troubleshooting something. Thank you for that.
[snip]
-
@DOA said:
Incidentally if you get the above dialog, then you're old.
Police Quest? When you are accessing the archives for information on the Death Angel?My written English improved a lot thanks to these kind of games. But it was immensely frustrating when being blocked by a puzzle based on a play on words.
Maybe worth its own thread: what was your first ever Sierra Adventure game? Mine was "Leisure Suit Larry in the Land of the Lounge Lizards". (see also my avatar)
-
@bjolling said:
what was your first ever Sierra Adventure game? Mine was "Leisure Suit Larry in the Land of the Lounge Lizards". (see also my avatar)
Besides Leisure Suit Larry, I LOVED Phantasmagoria. It was a kickass game for its day.
-
Re: hierarchical filesystems being old
Sorry, but I much prefer to put stuff in a directory with a descriptive name inside another directory with a descriptive name. I don't want to remember what I wrote in a 2 year old mail, I want to find it by opening the directory with a name pertaining to the project I was working on, then the folder named after the type of mails I'm looking for, then the one with the date.
This has the advantage over metadata of showing me the whole bloody tree. If there are no mails sent to the directors in June 08, I'll know and I'll try July. If there are 27 mails, perhaps I might decide I'd prefer to open a different one later in the conversation thread.
And it lets me use my visual/motor memory: 'open network drive window, long name in the middle, topmost item, third item with '4.1' in the name, whichever document ends with _NL'.
So beyond helping MS sell more boxes by reinventing the wheel, what the hells is wrong with hierarchical filesystems anyway??
-
@Brother Laz said:
Sorry, but I much prefer to put stuff in a directory with a descriptive name inside another directory with a descriptive name. I don't want to remember what I wrote in a 2 year old mail, I want to find it by opening the directory with a name pertaining to the project I was working on, then the folder named after the type of mails I'm looking for, then the one with the date.
This search of yours would be easier to manage with a many-to-many relationship like tags than it is with a hierarchical relationship like directories.
Imagine your mail files all shared a "mail" tag, and all your project files for project A had a "project_A" tag, and all of your files had creation dates (which they do already). In this case, the mail you need to find is the intersection of two tags, plus a time index. This allows you to have files that would belong to multiple hierarchies without having to duplicate anything. What if a particular mail file contained data related to project B, too? With a many-to-many relationship, you just associate project B with that file and you're done. With a hierarchy you'd need to copy the file into the project_B/mail directory.
While directories can do a lot of things, they are certainly capable of being improved. What's wrong with improving something good to make it better, anyway?
-
@Welbog said:
This is a stupid idea. Why wouldn't you just do it the right way: inmail.txt?
Imagine your mail files all shared a "mail" tag, and all your project files for project A had a "project_A" tag, and all of your files had creation dates (which they do already). In this case, the mail you need to find is the intersection of two tags, plus a time index. This allows you to have files that would belong to multiple hierarchies without having to duplicate anything. What if a particular mail file contained data related to project B, too? With a many-to-many relationship, you just associate project B with that file and you're done. With a hierarchy you'd need to copy the file into the project_B/mail directory.
-
@bstorer said:
This is a stupid idea. Why wouldn't you just do it the right way: inmail.txt?
Sets make me hard.
-
@Welbog said:
Sets make me hard.
True. Everytime I write an SQL query with "foo in (A, B, C, D)", I get that comfortable tingle, down there, and I feel satisfied though a little unclean.
I'm not sure how I feel about dirs vs tags. I only run into issues with my photo collection, where a photo can be filed by date, by set or by some kind of content category. Tagging would be a much better choice there. I currently "fix" things by putting sets in a dir in the date-named folder, and a shortcut to it in a /Sets/ folder. It's a little Meh.
For music, the problem is moot, because foobar2000's component Facets is the ultrabomdiggy.
A tag-based file system will require an explorer based on Facets' customisable multi-panel principle, along with Foobars Search dialog and query syntax.
-
-
@Welbog said:
Imagine your mail files all shared a "mail" tag, and all your project files for project A had a "project_A" tag, and all of your files had creation dates (which they do already).
Not if you use Unix. :-(
-
@morbiuswilters said:
Not if you use Unix.
Switch to a real OS, then.
-
@Welbog said:
@morbiuswilters said:
Not if you use Unix.
Switch to a real OS, then.Quiet, you bourgeois supporter of a convicted monopoli$t!
-
@Welbog said:
Imagine your mail files all shared a "mail" tag, and all your project files for project A had a "project_A" tag, and all of your files had creation dates (which they do already). In this case, the mail you need to find is the intersection of two tags, plus a time index. This allows you to have files that would belong to multiple hierarchies without having to duplicate anything. What if a particular mail file contained data related to project B, too? With a many-to-many relationship, you just associate project B with that file and you're done. With a hierarchy you'd need to copy the file into the project_B/mail directory.
While directories can do a lot of things, they are certainly capable of being improved. What's wrong with improving something good to make it better, anyway?
You just described an OODB. However, OODBs and file systems solve different problems.
-
@derula said:
Also, let's not identify files by file names. All personal files could be in a single folder, just identified by inode and contents. If you want to write a letter, simply press "new document" and start to type something. When you need to go, simply close the text processing thing. If you want to continue, just open "my files", click the documents filter, and if you have too many documents listed, type a few words you know your letter contains.
I think you'd need to combine this with a desktop search engine. Something powerful that can locate anything, and also manage booksmarks and play videos in a random order. Something fast, too fast for indexing....
-
@cdosrun said:
@derula said:
Also, let's not identify files by file names. All personal files could be in a single folder, just identified by inode and contents. If you want to write a letter, simply press "new document" and start to type something. When you need to go, simply close the text processing thing. If you want to continue, just open "my files", click the documents filter, and if you have too many documents listed, type a few words you know your letter contains.
I think you'd need to combine this with a desktop search engine. Something powerful that can locate anything, and also manage booksmarks and play videos in a random order. Something fast, too fast for indexing....Awesome idea! And all documents should just be lines up in a single 2 GB text file. And the search engine should be written in VB, because it creates clearly the fastest executables, even faster than assembler, because it's so close to the hardware.[citation needed] Oh, oh, let's not forget about Random Large Scrolling Font! And alien fliers and dinosaur skin, and holey stones, Boon-Doggle, Jee-Haw, Jam it! Through a spaghetti in here and there, and you have good pasta code![citation needed]
-
@Weng said:
I venture that you're going to find a hell of a lot more "Contracts" and "Resumes" and "Tax Returns" and "Expense reports" on most people's computers than you'll ever find any sort of correspondance (mail clients excepted - and in this case the "Organize by date" model works because that's how human correspondance works - the latest supercedes the oldest). The content of these things is almost ENTIRELY meaningless in terms of identifying the actual document. In this case, you're likely to find multiples of each, each with sytactically small variations, but semantically separated by worlds - and in only one of these cases is versioning actually relevant to making sure you get the "right one".
A little late in the reply here, but since nobody else has...
I'm not necessarily disagreeing that in some (not all) cases, the content will be meaningless; my point is that a file name is equally meaningless for the majority of users. These files with meaningless content will also have meaningless, generic names, such as "contract", "resume", "tax return", or "expense report." The solution for differentiating these is free-form metadata similar to tags, or maybe an actual tag system.
I can tell you that I have many Word and Excel documents, as well as a few HTML and text files kicking around with meaningless file names, but which I would be able to locate via a search. They have names like "SF-Commercial-Finance" (anonymized), but inside the document there will be, at the very least, the name of a company and product/project. There will also be the words "specification", "standards", etc. Even in my bog-standard boring "expense report" files, they will still contain the words "expense report", and the names of the things I expensed. The content of the file is almost always better than an arbitrary file name, and in any cases where a user knows that's not going to be sufficient, or is just anal and wants better organization, he can add his own title attribute and other attributes to the metadata.
You seem to keep glossing over that last point. The search should index the actual content and any user-supplied metadata, which would be far better than some meaningless file name.
Sure, your search will turn up multiple files, maybe 10 or 20 of them, but who cares? In 9 out of 10 cases, the user wants the most recent one (sort by date in reverse order), and in the other cases, they can scan the list fairly easily. Humans are much better at scanning things than naming things.
Your argument is that "file names allow the layman to create their own organizational pattern." Fine, but laymen don't want to create their own. That's the freetarded mindset: don't make any decisions at all, just let the user customize it. And really it's just born out of laziness and indecisiveness on part of the developers. I would much rather have them make a good design for me than waste time coming up with my own manual system, which half the time I would be too busy or lazy to follow anyway.
-
The users understand the hierarchical filesystem, because it's really simple. And since it tends to be static, it has one great feature: geographical positioning. When you look for a file at a directory you recently used, you probably can locate it in "upper left corner" or "somewhere near the middle, under a file with a really long name". I know of people that have directories named "2007", "2008" etc. reproducing the same internal structure. They're not very computer-literate, but they can perfectly work with that solution.
It really helps for everyday repetitive tasks like adding similar reports, writing similar documents etc.
A solution based on dynamic "file find" while entering clues about the file would be great if the search works instantly. If it takes more than a couple of seconds to display a weighed list of files satisfying current conditions, then it's worthless.
Also, if someone actually uses this "desktop search" feature to find a file, they will tend to memorize a precise set of words that gave them the document. And the problem is, once they find it, it works only once - they will have to look for it again next time they want to open it. A hierarchical file system is better here - if you know exactly where to look, you won't try to figure out words that will narrow the search to the file, but go to that directory directly (again, geographic positioning).
Users love the autosave feature, but it has ho have one thing: rollback. A manual save is like "yes, I'm done with it (for now)", an autosave is "thanks, my work is not lost, but I just made this action of removing all formatting from my file and I'd like to have it back".
-
@Aaron said:
The solution for differentiating these is free-form metadata similar to tags, or maybe an actual tag system.
And you intend to visually represent freeform metadata or tags to the user... How?
And you intend to teach all the world's grandmothers of the world how to use metadata and tags... How?
Vista+ NTFS supports both user-specified metadata and tags. NOBODY uses them because it isn't a metaphor which they understand. People intrinsically understand files and folders because they have them in their desks at work. Yes, there's no reason whatsoever technically that we should constrain ourselves to this model, but the user needs to be able to understand the metaphor
-
@Aaron said:
I'm not necessarily disagreeing that in some (not all) cases, the content will be meaningless; my point is that a file name is equally meaningless for the majority of users. These files with meaningless content will also have meaningless, generic names, such as "contract", "resume", "tax return", or "expense report." The solution for differentiating these is free-form metadata similar to tags, or maybe an actual tag system.
If users can't come up with meaningful file names, what makes you think they'd come up with meaningful tags?
@Aaron said:Your argument is that "file names allow the layman to create their own organizational pattern." Fine, but laymen don't want to create their own. That's the freetarded mindset: don't make any decisions at all, just let the user customize it. And really it's just born out of laziness and indecisiveness on part of the developers. I would much rather have them make a good design for me than waste time coming up with my own manual system, which half the time I would be too busy or lazy to follow anyway.
While an overly customized system may not be good for the layman, a too rigid one will probably push away the more advanced users. I tried Gnome a few years back but stopped using it after a few months as I felt it was doing too much behind my back and I couldn't customize it enough. Furthermore, now that a hierarchial file system is already an industry standard and there are millions of users used to it, it would be very hard to suddenly change to an entirely different model.
-
@Weng said:
Vista+ NTFS supports both user-specified metadata and tags. NOBODY uses them because it isn't a metaphor which they understand.
That is not theproblem. Give people a music collection and a proper interface and suddenly they wolf down tags like it's been a long winter, even if they often maintain them sloppily. Tags are not intrinsically hard for Joe Average.
The problem is that NTFS' tag system suffers from a buried, barely visible, malnourished and inefficient interface, which means that nobody actually knows about it.
-
@tdb said:
If users can't come up with meaningful file names, what makes you think they'd come up with meaningful tags?
QFT. They will not.
See "sloppy maintenance" above.
-
@dhromed said:
You might organize your music collection using tags, particularly if you use iTunes or the Winamp library, both of which essentially force tags upon you if you want to be able to actually pick what you listen to. These people are music fans and typically young people who understand tags anyway because some idiot decided that all websites must include tags.That is not theproblem. Give people a music collection and a proper interface and suddenly they wolf down tags like it's been a long winter, even if they often maintain them sloppily. Tags are not intrinsically hard for Joe Average.
The problem is that NTFS' tag system suffers from a buried, barely visible, malnourished and inefficient interface, which means that nobody actually knows about it.
However, the overwhelming majority of "Ma and Pa" users don't. They take their 20 or 30 MP3s and stick them in a folder, and doubleclick them to play them. The advanced members of that group will make playlists.
Also, tags are difficult when you get into the extremely high-volume collections. Past a certain point, it's much more efficient to organize them into heirarchial structures (Artist=>Album=>Song) with strict naming conventions, and then use automated tools to turn that filesystem into the metadata. That is, unless you're filthy rich and source your massive music collection from a service that actually gives you the metadata (pirated music typically comes without tags for some unknown reason)
These high-volume, pirated collections are a nice analog for document storage. The metadata all has to come from you, and you produce a lot of stuff.
Still don't believe me? When I get some copious free time, I'll run a formal usability study on it. Off the top of my head, the best way to do this would be to take a real, representative userdata batch, painstakingly tag the shit out of it, hack up a UI that searches the NTFS metadata and spits out a list of stuff (and then run that as the shell to prevent them using the filesystem)
-
@Weng said:
stuff
This is not a reply to my point. A repeat of my point: NTFS tags may or may not be useful, but the interface is crap so nobody knows about them so nobody uses them.
@Weng said:
Also, tags are difficult when you get into the extremely high-volume collections. Past a certain point, it's much more efficient to organize them into heirarchial structures (Artist=>Album=>Song) with strict naming conventions, and then use automated tools to turn that filesystem into the metadata. That is, unless you're filthy rich and source your massive music collection from a service that actually gives you the metadata
I don't see the relation betwene these sentences. I'm going to break them up.
@Weng said:
Also, tags are difficult when you get into the extremely high-volume collections.
Tags are not intrinsically related to the size of a collection.
@Weng said:
ast a certain point, it's much more efficient to organize them into heirarchial structures (Artist=>Album=>Song) with strict naming conventions, and then use automated tools to turn that filesystem into the metadata.
You use both. Organisation in hierarchies is useful because of an object's ability to be remembered by location, and because some software/hardware may perform poorly as the amount of objects in a single list increases. This has nothing to do with tags.
Your Ma & Pa scenario described the exact situation I started with, when my music collection was still small, and I began structuring my music into folders as it grew, for list display performance and for searchability. The searchability point is slightly moot now, as the files are properly tagged and foobar2000 has real fucking fast Search + Open Containing Folder features.
(On a related note, I would seriously come in my pants for a feature of Explorer where it could un-fold folders, and display the whole collection of files of n-deep folders in a single list, with separator labels containing the folder names.)
@Weng said:
(pirated music typically comes without tags for some unknown reason)
*frown* No, that's not right. What makes you say that?
@Weng said:
Off the top of my head, the best way to do this would be to take a real, representative userdata batch, painstakingly tag the shit out of it, hack up a UI that searches the NTFS metadata and spits out a list of stuff (and then run that as the shell to prevent them using the filesystem)
That's a good experiment, but I don't know what particular hypothesis you wish to test with it.
Tagging is well-established in digital music, and any attempt to port the idea to common files proper, is going to have to have a good look at how it's done with music. A problem might be that all music is in the same category: music. All files are in wildly different categories. Maybe that's not a problem at all. Just search Everything from a single text input field and update instantly.
Just so we're clear on what points we are arguing:
Are you for or against tags? The implementation?
What is the problem? Why are we talking?
I'm for tags.I'm against killing the folder concept, but actually, I'm not sure why. Maybe hierarchies are just coincidentally useful, but increasingly obsolete in the information-rich environment we have created. I find that I am capable of using hierarchies to file away music, because I´m lucky that its main components are of the 1:m relation: a track is part of 1 album; an album is made by 1 artist. This rarely applies to other content, and as I described earlier, I'm already running into issues with my photos. In fact,even for music, mix-albums and collections pose real, practical problems in terms of organization.
Then again, I have no idea how I would organize a server with many website folders on it, into a tag-based system. What would happen to the concept of paths, and a folder's primary ability to limit scope?
I'm disappointed by Window's implementation of the tag/search interface i.e. the barely extant one. It actually never occurred to me it was there as a proper feature until you pointed it out, posts up. Since the interface is so poor, I can't enjoy Winkey+F in the same way that I love Foobar's Ctrl+F and its various Media Library components.
-
Seriously, what's the deal with NTFS tags? I' ve never heard about them and Google/Yahoo/Bing aren' t helping.
"Tag" is a bad word to use on a web search.
-
@Zecc said:
Properties, Details tab. It'll show "permissible" metadata properties depending on filetype. Office docs get things like tags. Pictures get EXIF stuff. Music gets ID3 stuff. Most everything else gets nothing. Now that I think about it, I'm not even sure this is built into the FS - it might just be using metadata within the file itself.Seriously, what's the deal with NTFS tags? I' ve never heard about them and Google/Yahoo/Bing aren' t helping.
"Tag" is a bad word to use on a web search.
(Note: I'm Win7 RC1. Win7 RTM might be different, Vista is probably slightly different, XP doesn't have it.)
-
@Weng said:
XP doesn't have it.
XP has a Summary tab with some sort of field/value thing that varies per file type, i.e. office docs have some extra data; images have width/height, other files have a few generic fields.
-
@dhromed said:
HTML files (or the few I checked on my laptop) have none of the above, not even the summary tab. PDF's and OpenOffice docs have an extra tab.@Weng said:
XP doesn't have it.
XP has a Summary tab with some sort of field/value thing that varies per file type, i.e. office docs have some extra data; images have width/height, other files have a few generic fields.
-
@Weng said:
@Zecc said:
Oh, that. I always thought of that as just a nice interface to edit the existing metadata of files of known type. I don't really think that's directly supported by the FS.Seriously, what's the deal with NTFS tags? I' ve never heard about them and Google/Yahoo/Bing aren' t helping.
Properties, Details tab. It'll show "permissible" metadata properties depending on filetype. Office docs get things like tags. Pictures get EXIF stuff. Music gets ID3 stuff. Most everything else gets nothing. Now that I think about it, I'm not even sure this is built into the FS - it might just be using metadata within the file itself."Tag" is a bad word to use on a web search.
(Note: I'm Win7 RC1. Win7 RTM might be different, Vista is probably slightly different, XP doesn't have it.)
-
-
@Weng said:
Properties, Details tab. It'll show "permissible" metadata properties depending on filetype. Office docs get things like tags. Pictures get EXIF stuff. Music gets ID3 stuff. Most everything else gets nothing. Now that I think about it, I'm not even sure this is built into the FS - it might just be using metadata within the file itself.
Office document metadata, EXIF and ID3 are all part of the file format and have nothing to do with the FS.
-
@morbiuswilters said:
@Weng said:
Properties, Details tab. It'll show "permissible" metadata properties depending on filetype. Office docs get things like tags. Pictures get EXIF stuff. Music gets ID3 stuff. Most everything else gets nothing. Now that I think about it, I'm not even sure this is built into the FS - it might just be using metadata within the file itself.
Office document metadata, EXIF and ID3 are all part of the file format and have nothing to do with the FS.Some formats do not support metadata and windows still supports tags and other meta-data through the use of NTFS secondary streams.
-
@Kiss me I'm Polish said:
The users understand the hierarchical filesystem, because it's really simple. And since it tends to be static, it has one great feature: geographical positioning. When you look for a file at a directory you recently used, you probably can locate it in "upper left corner" or "somewhere near the middle, under a file with a really long name". I know of people that have directories named "2007", "2008" etc. reproducing the same internal structure. They're not very computer-literate, but they can perfectly work with that solution.
You are confusing "system that is efficient, discoverable, and reliable" with "clumsy user workaround to compensate for the deficiencies of the underlying system."
I know of these people too, but I also know of many people who can't be bothered or don't know how to maintain that kind of system, and for the ones that do, it's still criminally inefficient.
An MRU is far more effective than these mental acrobatics. If you haven't touched a file in months, then you won't remember its spatial position in a sorted list anyway (assuming that the list hasn't changed at all in those months).
A solution based on dynamic "file find" while entering clues about the file would be great if the search works instantly. If it takes more than a couple of seconds to display a weighed list of files satisfying current conditions, then it's worthless.
Modern solutions essentially do work almost instantly, and if you limit it to a specific program (i.e. Word) then it would be even faster. Are you one of those people that turns off the indexing service because it "slows down" the machine?
Also, if someone actually uses this "desktop search" feature to find a file, they will tend to memorize a precise set of words that gave them the document.
You have absolutely no factual basis for this claim. Readily-available web search engine statistics contradict it.
Users love the autosave feature, but it has ho have one thing: rollback. A manual save is like "yes, I'm done with it (for now)", an autosave is "thanks, my work is not lost, but I just made this action of removing all formatting from my file and I'd like to have it back".
If you'd bothered to read any of the previous posts, it would have been obvious that a major component of autosaving is journaling or at least saving the undo history. Not only is this straightforward to do in an application that already supports undo, but it would also handle all of the "accidental" cases (you closed the window and hit "yes" to the modal save prompt instead of "no" - why even bother users with that dialog when you can just save it automatically and they can undo when they open it up next).
Honestly, you're really just re-hashing old points that have already been brought up and debunked. All you've added is the "geographic positioning" (which should really be "spatial positioning") argument which is not actually a by-design solution, but merely an end-user coping mechanism.
-
@Weng said:
And you intend to visually represent freeform metadata or tags to the user... How?
And you intend to teach all the world's grandmothers of the world how to use metadata and tags... How?
It's trivial to display 2-3 tags on larger thumbnails - and if you're using the whole window/screen for it, the space is there.
As for the second question, you don't teach anyone, you make the feature discoverable. How do you intend to "teach all the world's grandmothers" how to use a hierarchical file system? Or do you just assume, like a typical UI-illiterate programmer, that they already understand whatever you understand?
-
@dhromed said:
Then again, I have no idea how I would organize a server with many website folders on it, into a tag-based system. What would happen to the concept of paths, and a folder's primary ability to limit scope?
This is the key, and I think the reason so many programmers and IT people freak out when you talk about alternative UIs to hierarchical directories.
If you're a programmer or IT admin, a hierarchical system of "inheritance" is the best way [that we know of] to manage the complexity of system relationships (i.e. permissions, ownership, etc.) Much like if you work in management or HR, you generally use hierarchies to model organizational relationships.
But if you are, for example, a database professional, then you model relationships as something entirely different. You model them as... well, generic relationships, with a few additional properties to define the type of relationship. If inheritance is required then it becomes part of the application domain.
To most users of a system, as opposed to designers/programmers/administrators, the concept of a simple "relationship" is far more intuitive. That does not mean that the system cannot still have a special kind of relationship that defines a hierarchy and is available to developers and administrators. It just means that said relationship doesn't have to be the primary or only model provided to the end users.
The example of photo collections is perfect. A photo may intrinsically have a wide array of different attributes - where it was taken, when it was taken, what the event/occasion was, who or what is in the picture, and so on and so forth. You're faced with so many impossible decisions when you're shoehorned into a hierarchy. Do I put all of the pictures of myself in their own folder? Do I put the photos for my 2009 Summer Vacation in their own folder? And do I make a separate sub-folder for each city I visited, or do I organize them by the type of attraction? What if I want to flag a bunch of pictures for editing or printing, do I need to put them in their own folder? The more you think about it, the less sense it makes. There's no reason we need to throw away the hierarchy, but most people really don't want to see it, and it should probably only be exposed when requested.
-
I haven't looked around Vista/7's new column sorting features much, as that stacking thing seemed to succeed only in replacing icons with icons of plastic cutting boards. Does it prove a Group By <sometag> option? That would be rad.
-
@Aaron said:
Also, if someone actually uses this "desktop search" feature to find a file, they will tend to memorize a precise set of words that gave them the document.
You have absolutely no factual basis for this claim. Readily-available web search engine statistics contradict it.
Web search engine statistics have nothing to do with this, unless you somehow get your hands on statistics for a single user. I believe the point here was that the user would memorize the set of words that got him the particular document and then use those in the future to find it - you can't counter this by "hey look, one million users each used different keywords to find this and that from the web".
@Aaron said:Users love the autosave feature, but it has ho have one thing: rollback. A manual save is like "yes, I'm done with it (for now)", an autosave is "thanks, my work is not lost, but I just made this action of removing all formatting from my file and I'd like to have it back".
If you'd bothered to read any of the previous posts, it would have been obvious that a major component of autosaving is journaling or at least saving the undo history. Not only is this straightforward to do in an application that already supports undo, but it would also handle all of the "accidental" cases (you closed the window and hit "yes" to the modal save prompt instead of "no" - why even bother users with that dialog when you can just save it automatically and they can undo when they open it up next).
I wouldn't want an autosave mess up my timestamps if I happen to accidentally modify a file I'm viewing (I'm too lazy to remember what was Vim's read-only commandline switch, and many graphical editors don't even have that option). Nor would I want to have the file suddenly picked up by incremental backup because the undo history changed, even though the content didn't. If the autosaves and undo history go to a different temporary file (such as with Vim's swap/recovery feature), it's fine (said feature has saved my changes a few times when an ssh connection goes sour).
-
@tdb said:
Vim
ssh connectionRight, well there goes any credibility in the realm of User Experience.
Do you understand that most people have never even heard of these things, much less would ever use them? What's good for a developer (or generic Linux geek) is usually patently awful for a normal user.
From a technical standpoint, the most obvious way to get this working without messing up things like timestamps would be to use forks (or ADS on Windows).
-
@Aaron said:
@tdb said:
Vim
ssh connectionWhat's good for a developer (or generic Linux geek) is usually patently awful for a normal user.
Popular as that notion is, it's also complete horseshit. Developers (and animators, graphic designers, etc) have to deal with most of the same issues as "normal" users, and we suffer the same consequences. The difference is, we invest the time to learn the quirks and oddities of our tools, usually because we don't have a choice about whether or not to use them.
There may be features and options that we want which average users wouldn't care about, but that's not the same as having two different standards for usability. Maybe there are some pathological cases who want to feel like big men and use an interface that was designed by mental patients, and that's their issue. I'd say the rest of us are mainly trying to get stuff done and struggling mightily to keep our tools from getting in our way.
So we have to deal with the same sorts of hassles and issues that plague the poor accounting clerk trying to figure out the correct Excel formula to use. The difference is, because we usually can't do anything about the garbage foisted on us, we just come to think of it as par for the course. And so, we sit down with our Tips & Tricks guide, and we learn the shortcuts and workarounds, because that's the only way to be remotely productive.
Crappy UI is still crappy UI, whether it's sold to programmers or to your Aunt Edna.
