Linked by Thom Holwerda on Fri 29th Jun 2012 22:55 UTC
OSNews, Generic OSes "Whenever there is a conversation about the future of computing, is discussion inevitably turns to the notion of a 'File'. After all, most tablets and phones don't show the user anything that resembles a file, only Apps that contain their own content, tucked away inside their own opaque storage structure. This is wrong. Files are abstraction layers around content that are necessary for interoperability. Without the notion of a File or other similar shared content abstraction, the ability to use different applications with the same information grinds to a halt, which hampers innovation and user experience." Aside from the fact that a file manager for Android is just a click away, and aside from the fact that Android's share menu addresses many of these concerns, his point still stands: files are not an outdated, archaic concept. One of my biggest gripes with iOS is just how user-hostile the operating system it when it comes to getting stuff - whatever stuff - to and from the device.
Thread beginning with comment 524407
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Stupid, stupid
by Doc Pain on Sat 30th Jun 2012 03:13 UTC in reply to "RE[2]: Stupid, stupid"
Doc Pain
Member since:
2006-10-08

Then it is the job of the OS to not misplace it.


That approach might be limiting. If a user wishes to do a certain action in a specific way, should the OS interfere and disallow it explcitely, or should it silently do something different? However, if the whole interaction process can be designed to work without such worries, the better! It doesn't imply that the user is separated from the results of his actions. An intelligent interaction concept takes that into mind,

In the world of apps, we already utilize this idea. There is no manually downloading of some file, extracting it into some directory, finding it again, and then executing a program that installs another program to a different directory, which we then start to open files. Installing an app is much easier - as it should be, because it can be made easy. Similarly, you can say the same about easyness for installing a program on a UNIX or Linux system with a package management system. Instead of selecting from a list of icons, you simply name the program you want to have installed, e. g. "pkg_add -r opera". "Behind the curtain" some program deals with files and directories, but it's not neccessary to know about that to get the job done.

We shouldn't be punting the failures of UX design to the user.


Fully agree. Certain GUI concepts are really faulty by design, and help desks have to deal with it on a daily basis.

Of course it does. People value their time.


But they often don't realize time as a resource worth investing in, to grow it. Every handcrafter needs to know the content in his toolbox, and he needs to practice using the tools. It's not sufficient that the box is present to get the job done.

Things shouldn't go wrong.


But they do, in reality.

Files should be secure.


But they aren't, in reality.

Security is a process, not a state. The weakest element in the chain often is the user. Operating systems and services can help, but cannot make things 100 % "idiot proof".

The user shouldn't concern themselves with the implementation details of things. Its archaic and wrong.


It is, just as it is archaic and wrong to burn coal to make electricity from it to light the room, throwing more than 75 % of energy away in this process. :-)

Still those archaic concepts is what even modern web frameworks are based upon, their innermost workings are, if you look at them, archaic. There are many layers of abstraction to hide that compexity from the next levels. The end user of a product will not notice them, even though they are in there.

They can exist, the user doesn't need to know about them.


But in many cases, it does benefit them to know. I'm not talking about any specific implementation, but about the general concept. It can even be transitioned to reality in a non-IT related context: Instead of putting all things "linearly" on a long shelf, they can be put into cardboxes labelled with a category name. Dealing with this method (selecting from a category to find an object that belongs to that category) can make life easier.

Note that it doesn't apply everywhere. There are other concepts, such as tagging: Here one wouldn't even talk about files and directories anymore, but instead of objects which have certain properties, and there is no hierarchical ordering in the first place. It's obvious that there are many ways for an implementation of that concept.

Users don't need to know the inner workings of their car to get to work. That would make life harder.


Thanks you brought up a car analogy. Because people love car analogies, here's the conclusion:

In order to participate in traffic, it's not sufficient to buy a shiny car. You need to know how to operate it, where to accelerate, where to brake, how to shift gears. You need to know where tu turn the lights on at night, and how to add fuel. But that's also not enough. You need to know the traffic rules, the funny signs and colorful lights, the arrows on the street and the policeman waving his arms at a crossing. And it's still not enough. You actually have to prove that you know all this. Even worse, if you fail to drive your car properly, it's possible that you will not be allowed to drive it anymore (e. g. after driving while being drunken and causing an accident).

I'm not saying what kind of traffic situation we would have if we'd apply "IT attitudes" in traffic. :-)

But I agree with you that -- again using the car analogy -- things shouldn't be made more complicated than they need to. A certain level of complexity will always be present (please differ complexity from complicatedness). To deal with this complexity requires learning. It's not wrong to learn things. Never.

Users should not have to know about file system mechanisms and other low-level information. But it will help then to organize their stuff if they have any concepts at hand, be it the hierarchical concept provided by files and directories, or a tagging concept using some database mechanism. Please note that files and directories do not exist "per se", but that it helps to utilize them. They are here as a useful means promoted to the "upper levels" (to be used by the user), not only be present at the "lower levels" (operating system and application internals).

Edited 2012-06-30 03:20 UTC

Reply Parent Score: 3

RE[4]: Stupid, stupid
by Nelson on Sat 30th Jun 2012 03:31 in reply to "RE[3]: Stupid, stupid"
Nelson Member since:
2005-11-29


That approach might be limiting. If a user wishes to do a certain action in a specific way, should the OS interfere and disallow it explcitely, or should it silently do something different? However, if the whole interaction process can be designed to work without such worries, the better! It doesn't imply that the user is separated from the results of his actions. An intelligent interaction concept takes that into mind,


Where possible this kind of friction should be avoided. If the OS can (in what it deems to be safely) perform the users intended action, then so be it. Keep them in control, until their own control jeopardizes the integrity of the system as a whole.

I think complexity and control don't inherently coincide with danger though, so I'm also unopposed to burying the complex concepts, but not burying them too deep.

Any power user who wants can dip into the fray and get dirty with a command line shell and manipulate objects in the OS in their primitive states.

Windows 8 for example, for all its glitz and glamor and abstractions .. is even more powerful when used in tandem with Powershell scripting. I'm a huge fan of that kind of stuff.


But they often don't realize time as a resource worth investing in, to grow it. Every handcrafter needs to know the content in his toolbox, and he needs to practice using the tools. It's not sufficient that the box is present to get the job done.


Sure. They should be able to learn it, if they are so inclined. However I think presenting it as a default to users is a bad choice. Not every user particularly cares for such things. For the ones that do, great, knock yourself out.


Security is a process, not a state. The weakest element in the chain often is the user. Operating systems and services can help, but cannot make things 100 % "idiot proof".


Well, I didn't mean it to be 100%, what I mean is, as much as possible, OSes should strive to ensure the integrity of themselves and the data they are responsible for.

I'll again use the car analogy, every owner of a car shouldn't need to be a mechanic just to drive. If something goes wrong (and car manufacturers should strive to reduce this) they can always visit a mechanic who does care for the details.


It is, just as it is archaic and wrong to burn coal to make electricity from it to light the room, throwing more than 75 % of energy away in this process. :-)

Still those archaic concepts is what even modern web frameworks are based upon, their innermost workings are, if you look at them, archaic. There are many layers of abstraction to hide that compexity from the next levels. The end user of a product will not notice them, even though they are in there.


Yes, I don't think we should remove them. They're time tested and work well. Just from a user interaction POV they're completely unacceptable.


But in many cases, it does benefit them to know. I'm not talking about any specific implementation, but about the general concept. It can even be transitioned to reality in a non-IT related context: Instead of putting all things "linearly" on a long shelf, they can be put into cardboxes labelled with a category name. Dealing with this method (selecting from a category to find an object that belongs to that category) can make life easier.

Note that it doesn't apply everywhere. There are other concepts, such as tagging: Here one wouldn't even talk about files and directories anymore, but instead of objects which have certain properties, and there is no hierarchical ordering in the first place. It's obvious that there are many ways for an implementation of that concept.


I was just about to mention that. Instead of users spending time throwing everything in folders, just let them organize it in a way that feels natural.

You can organize it by date and location (included, say in image data) and you can do facial recognition to organize it by people and friends. You can let the user annotate it with key words and when his friends comment on the photo you can sort it by number of comments.

There's so many ways to automatically visualize data in a much richer fashion than we do today, without resorting to forcing users to throwing things in folders.

Being thoughtful and out of the way should be guiding principals to this.


Users should not have to know about file system mechanisms and other low-level information. But it will help then to organize their stuff if they have any concepts at hand, be it the hierarchical concept provided by files and directories, or a tagging concept using some database mechanism. Please note that files and directories do not exist "per se", but that it helps to utilize them. They are here as a useful means promoted to the "upper levels" (to be used by the user), not only be present at the "lower levels" (operating system and application internals).


I agree, I think there's a lot of room for improvement on how we present data. There's so much information out there, and we present it in a really dumb way a lot of the time.

Things like http://flipboard.com/ are awesome because they present data that already exists out there, in new and exciting formats.

Reply Parent Score: 2