solar flucuations are the most important part in our temps
How are solar fluctgations the most important part? I thought it was Earth's facing angle during the year what caused the most temps change. What makes it "obvious" the effect some sun spots have on climate?
Good point. If you didn't post as AC I'd elaborate an answer, because your insight is limited.
I am a geek and a programmer, so I understand your concerns. My geek specialty is non-geeks, so I could point you in the direction to understand their own concerns.
As far as hierarchies go, we already have a standard.
Yeah but why should a filesystem be a hierarchy? Only because current operating systems have evolved around that particular retrieving model. If we had to redesign it all again (and we do if we think of the Web as a platform), rethinking all of the ancient design decisions, we could create a system that take in consideration the needs to retrieve hundreds of terabytes, and took advantage of the computing power of current machines - instead of just relying on a fixed static index, which is what old filesystems where.
The difference is... we don't blame the machine for our own screwups. That would be like blaming your file cabinet when you put a piece of paper in the wrong folder.
You can't really compare computers to physical machines. You could, if file cabinets have magical gnomes to whom you handled your paper to store it, and you had to utter the right enchantment to get it back.
If you rely on the law of physics, then yes, it's your fault if you screw with them. But when everything depends on the whims of the programmer that created the automatic procedures, you can't blame the user for not reading the programmers mind.
Because all applications use the filesystem consistently, but almost no one have standard interfaces. For this to work it has to be used exactly the same by all applications - so a GUI-level library is out of question.
Read my previous post. Even if you show the whole directory tree, you still have two abstraction levels: the filesystem and the Save/Open dialogs.
At least the "stupid fake roots" get rid of the filesystem abstraction, so that users only need to learn the other one. (Or you can try to create applications that didn't use the Save/Open dialogs metaphor. Good luck.)
Users aren't asked to do what the assembly instructions do, they're expected to understand how the world that's presented to them works. It can be simple or complex to a large degree independently of how much code is spent to built it.
Funny thing is, users don't have access to the code (if they had, they'd be developers). So how are they supposed to understand how the world works, if they don't have access to its laws of physics?
Tags won't be just as bad, they'll be worse. They require a considerable effort to tag consistently. You also have to think of all the possible tags that could be related to the file. Is it "friends", "acquaintances", "buddies", etc? Is it singular or plural? Will "birthdays" be enough, or you also have to file it under "parties", "celebrations" and "events" in case you remember the file you need was related to some sort of celebration but you can't remember which?
What happens with categories that are diffuse, change meaning, or their contents?
Did you know that good requirement analysis involves changing the existing tools when they no longer fit the requirements? Ubuntu requirements are not served by the existing userland, they require user-centered design.
A lot of that goes to motivation: people learn some pretty damn complex activities when it comes to earning a driver's license, for example
That's because cars only have one level of user interface. If they were sometimes required to directly push the levers to turn right, cut the ignition wire to stop the car, or remove and disassemble the motor (and then rebuild it) to recharge fuel, they would all use taxis.
So the user decides not to pay attention to where the file was saved
Of course the user paid attention to where the file was saved: it was saved in Word, inside the Save As... dialog. But when she tried to recover the file using the Open..., the file was no longer there. That's what Shuttleworth means when he says there are two completely different mental models of content storage: one is tied to functionality in applications, the other is a tree of folders and files.
Users understand perfectly that it is a machine that should do only what they tell it to do. They get upset when the machine *doesn't* do what they told them, because the machine changed their data to a different level of abstraction that they don't know about. To someone without a complete mental model of the inner workings of a computer, those different abstraction levels are a source of utter confusion.
You geeks only see the last one, and typical users only see the first one - and when they are required to jump the gap between the two completely unrelated abstractions, they are lost. At least the "My Documents" kind of folders tries to simplify the model so that users don't have to learn the two models.
The "My Documents" folder is not a weird place, is the only one that can be accessed in a sane way from the Save and Load dialogs. Normal user data is tied to the applications they use (the filesystem *is* the weird place to put data), so it's just natural that their mental model of storage is mediated by the application storage functions.
I wish I could diplomatically barter with another player for control over a star system's spice flow that we've worked hard to get control of. And I don't want that player to just be able to kill me (or have some other random player run up and kill one or both of us) without consequence.
Have you heard of Literate programming? In that programming paradigm, documentation is part of the code. Usage manuals are outside of source code by any definition, but think of doxygen / javadoc. Is it code what they generate, or not?
If you only count as code what can be feed to the machine, you should look at the size of the compiled binary. Source code is meant to be read by *humans*, so comments do count. That's why the GPL requires them to be left in the files (the "preferred form" to edit), otherwise it wouldn't be source code.
If you only count as code what can be feed to the machine, you should only count the compiled binary. Source code is meant to be read by *humans*, so comments do count.
Slashdot Mirror
I'm a TuringTest, you insensitive clod!
How are solar fluctgations the most important part? I thought it was Earth's facing angle during the year what caused the most temps change. What makes it "obvious" the effect some sun spots have on climate?
Sounds like this advanced restaurateur simulator is reality at last!
Maybe the header in that section, "Conveying Non-Source Forms"? If he has given the source code, he is not bound by article 6.b)
Good point. If you didn't post as AC I'd elaborate an answer, because your insight is limited.
I am a geek and a programmer, so I understand your concerns. My geek specialty is non-geeks, so I could point you in the direction to understand their own concerns.
Yeah but why should a filesystem be a hierarchy? Only because current operating systems have evolved around that particular retrieving model. If we had to redesign it all again (and we do if we think of the Web as a platform), rethinking all of the ancient design decisions, we could create a system that take in consideration the needs to retrieve hundreds of terabytes, and took advantage of the computing power of current machines - instead of just relying on a fixed static index, which is what old filesystems where.
You can't really compare computers to physical machines. You could, if file cabinets have magical gnomes to whom you handled your paper to store it, and you had to utter the right enchantment to get it back.
If you rely on the law of physics, then yes, it's your fault if you screw with them. But when everything depends on the whims of the programmer that created the automatic procedures, you can't blame the user for not reading the programmers mind.
Because all applications use the filesystem consistently, but almost no one have standard interfaces. For this to work it has to be used exactly the same by all applications - so a GUI-level library is out of question.
Read my previous post. Even if you show the whole directory tree, you still have two abstraction levels: the filesystem and the Save/Open dialogs.
At least the "stupid fake roots" get rid of the filesystem abstraction, so that users only need to learn the other one. (Or you can try to create applications that didn't use the Save/Open dialogs metaphor. Good luck.)
Funny thing is, users don't have access to the code (if they had, they'd be developers). So how are they supposed to understand how the world works, if they don't have access to its laws of physics?
I think that project was the inspiration for KDE's Nepomuk, and yes, that engine is on the right track to solve this problem.
People seem to manage it exceedingly well.
Did you know that good requirement analysis involves changing the existing tools when they no longer fit the requirements? Ubuntu requirements are not served by the existing userland, they require user-centered design.
Nice, except for the fact don't allow you to save your documents, so they are no good as storage abstracions.
That's because cars only have one level of user interface. If they were sometimes required to directly push the levers to turn right, cut the ignition wire to stop the car, or remove and disassemble the motor (and then rebuild it) to recharge fuel, they would all use taxis.
I think that was the point Mark Shuttleworth was trying to make.
Of course the user paid attention to where the file was saved: it was saved in Word, inside the Save As... dialog. But when she tried to recover the file using the Open..., the file was no longer there. That's what Shuttleworth means when he says there are two completely different mental models of content storage: one is tied to functionality in applications, the other is a tree of folders and files.
Users understand perfectly that it is a machine that should do only what they tell it to do. They get upset when the machine *doesn't* do what they told them, because the machine changed their data to a different level of abstraction that they don't know about. To someone without a complete mental model of the inner workings of a computer, those different abstraction levels are a source of utter confusion.
You geeks only see the last one, and typical users only see the first one - and when they are required to jump the gap between the two completely unrelated abstractions, they are lost. At least the "My Documents" kind of folders tries to simplify the model so that users don't have to learn the two models.
So don't blame the users of something that is fault of the software designer because of their insufficient research about the human API. Throwing layers upon layers of abstraction is a good way to tell programmers how the machine works, but it's not good for everybody else. If you designed a machine that only required one abstraction layer to be used efficiently, users would love to learn it to the highest proficiency.
The "My Documents" folder is not a weird place, is the only one that can be accessed in a sane way from the Save and Load dialogs. Normal user data is tied to the applications they use (the filesystem *is* the weird place to put data), so it's just natural that their mental model of storage is mediated by the application storage functions.
Sounds a lot like EVE Online.
Have you heard of Literate programming? In that programming paradigm, documentation is part of the code.
Usage manuals are outside of source code by any definition, but think of doxygen / javadoc. Is it code what they generate, or not?
Comments are also code.
If you only count as code what can be feed to the machine, you should look at the size of the compiled binary. Source code is meant to be read by *humans*, so comments do count. That's why the GPL requires them to be left in the files (the "preferred form" to edit), otherwise it wouldn't be source code.
Comments are also code.
If you only count as code what can be feed to the machine, you should only count the compiled binary. Source code is meant to be read by *humans*, so comments do count.
So you should pick the topic *after* drawing the comic?
You've been reading too much Irregular Webcomic again?
At the end of this Portal there's cake.