Merger-generated synergy is more than just layoffs (or "redundancies" as the Brits say). It also includes sales and marketing schemes such as cross-promoting products between subsidiaries (whether they make sense or not), and bundling applications (at a "reduced price" unless you're Amazon) from one division with hardware from another. After all, you've (supposedly) just reduced the sales cost on one product, so you can afford to discount the sale price on the total transaction.
Another synergy is to cut costs (in product/program development) and increase revenue by selling the same or similar products under different brands. Retain the old entity names after the merger (example: HP/Compaq, IBM/Sun), but replace competing product lines with rebranded versions of the "best version" (probably cheaper to build or more profitable, but possibly highest volume). Eventually, customers will forget that there's really less competition and less choice. (At least, that's the theory.)
Just remember this: synergy is all about benefits for the producer; any advantages for the consumer are secondary to that. It's a marketeer's dream (and a savvy consumer's worst nightmare), but it's still synergy.
Boldrin and Levine have posted the bulk of their book Against Intellectual Monopoly on the Web. So, if you don't want to purchase a dead-tree version of the work, you can download what amounts to an e-book (free of charge, but minus the front and back matter) from Mssr. Boldrin's website.
Last time I checked, there was a copyright regime in place for published works. I call these authors enlightened, not hypocritical, for finding a middle ground. Their publisher, Cambridge University Press, probably requires a copyright on any works that they distribute, if for no other reason than to protect their investment. The publisher also shows a degree of enlightenment, in allowing the simultaneous posting in digital form without DRM, unlike most publishers these days. By the way, Lawrence Lessig has followed a similar approach with his book Free Culture. (That work is also copyrighted, but the PDF version on the Web is released under a Creative Commons license.)
Apparently I was unclear in my critique of Mark Shuttleworth's proposal to replace the "filing system" model implicit in GNU/Linux. Understanding the hierarchical model of UNIX file systems works for me, but not for a user like my mother. (I helped introduce her to computing at age 72 or so, though she opted for Windows over the MacOS approach that my spouse and I originally recommended. I watched how files piled up on her computer over time. It's clear that she doesn't grok files and directories, but she doesn't need to understand that model for what she does.) By the same token, her "filing scheme" would never suffice for the thousands of files that I use in my own projects.
Perhaps the easiest problem to tackle is that there appears to be no consistent set of rules for saving files by default. Application A stores files in one place, and application B in another. Your 99.9% of users probably expect that data is data, and therefore that it should be "all in the same place" unless they say otherwise. Turns out that their expectations are more sophisticated than the "system design", which is little more than aggregating applications from disparate sources.
Mark could make a notable contribution to usability if he could get the developers of widely used applications -- Open Office, Gnumeric, Acrobat Reader, Firefox, the GIMP, etc. -- to save files in a consistent fashion -- consistent across applications. Then develop some kind of Spotlight-type wrapper for "find" for those users who don't use an explicit filing system to organize/retrieve their work. Such a scheme would make it easier to form an accurate and useful mental model of how the system works in this regard. It's not revolutionary technology, but would make life easier for a lot of users (myself included), and just might be simple enough (to implement) that developers would buy into the idea. A more radical approach is likely to die on the vine.
From the headline I thought this was going to be about lost/cross-linked clusters not idiotic users forgetting where something is saved.... These changes are independent of the underlying file system...
Alas, Mark Shuttleworth chose to use the term "file systems" in referring to the method(s) that people use to organize data on their computers. Before 1972 or so, few people would have been confused. However, I'm intrigued by efforts -- such as Jef Raskins' Archy project -- that appear to deliberately conflate the two notions in service to the end-user.
That said, I'm not keen to use a system that forces me to use somebody else's scheme for document storage and retrieval. In 25 years of using UNIX, I've developed (and continue to refine) my own filing schemes. I'm more than comfortable with the "files and folders" model and my understanding of the underlying (hierarchical) storage scheme serves me well.
Beware the new dogma, especially when it's based on the notion that "one size can fit all" -- apparently the implicit guiding principle behind Windows and MacOS. Not always, but often, there's too much dumbing down in the process of presenting the system through a GUI. As an expert user, I hate to be slowed down for routine or repetitive tasks by moving a mouse, highlighting icons, and selecting from menus; give me the command line interface. For tasks that I don't perform very often, such as configuring a network interface, invoking a calculator program, or (shudder) launching a word processor, I appreciate a simple, easy-to-use GUI with consistent behavior across the O.S. (There's the rub.)
If Mark's goal is a one-size-for-all file storage model, then I will likely never agree with it. Not because I think I'm better or smarter, but because people don't think alike or work alike. Give us systems that support diverse filing schemes -- not just by content/topic or file name, but by date, tagging (user-supplied metadata), origin, file type, whatever.
Understanding the low-level model of a UNIX file system plus a few commands (including the byzantine "find") allows an experienced user to do some of this, but that initial learning curve can be a bitch. So find ways to make that expressive power accessible to beginners and occasional users. And do so in ways that help them develop a useful mental model of what's going on, and facilitate the transition to power user status (for those who want it).
*** Rant off
I'd settle for simple consistency in the menus for common operations such as opening and closing files from applications with GUI front ends.
I agree that there's a place for simulation, but some commenters seem to think that it is sufficient. So Boeing built and successfully flew a 777; that says nothing about how easy it is for the pilot to use the controls, or the mechanic to repair a tailfin assembly, or for a passenger to put their pants back on after using the restroom. Can a simulation package replace feedback from a pilot's attempt to use a control panel? (For that matter, DOES it even make sense to simulate this with a CAD model? Well, I suppose there's always a virtual reality setup...)
Ditto with antenna design. The value of the simulation software is in optimizing effectiveness at receiving a signal. That has nothing to do with the ease or difficulty of installation.
Have you tried to change motor oil and filter on a recent model subcompact car? It's much harder than it was 25 years ago, unless you have a lift (or mechanic's pit), sometimes special tools, and can reset the onboard computer so that it doesn't report you as voiding the warranty. It's obviously not a design objective to facilitate owner-performed maintenance. There could be any number of reasons for this, but it seems to me that "easy to change the oil" would also translate into more productive mechanics at service stations and car dealerships, maybe even lower prices and/or higher profits. We may never know.
I object to the dismissal (or de-emphasis) of issues or concerns that can't be simulated by hand-off software packages -- such as installation and upgrades; ease of use; maintenance and repairs; you know -- all that stuff that involves a messy human. (And maybe someone who ultimately might determine whether you remain employed and/or your employer remains in business. Ah, if only it were that simple...) Alas, your Pointy-Haired Boss can sabotage any attempt to do the right thing, so you might need to use people skills -- you do have some, don't you? -- to make your case.
Certainly there's a place for simulation(s). If it makes it any more palatable, then think of prototyping as a hands-on simulation that attempts to address the interface(s) where user meets product. Of course, you need a lot more intelligence in the data analysis stage, as there's no software to substitute for thinking.
Check out the examples cited in "The Craftsman" by Richard Sennett, along with anecdotes in "The Design of Everyday Things" by Donald A. Norman in order to broaden your perspective on design to include a "user". Just maybe you can rise above the undesirable consequences of designs that don't account for the ultimate consumer of a product.
Slashdot Mirror
Merger-generated synergy is more than just layoffs (or "redundancies" as the Brits say). It also includes sales and marketing schemes such as cross-promoting products between subsidiaries (whether they make sense or not), and bundling applications (at a "reduced price" unless you're Amazon) from one division with hardware from another. After all, you've (supposedly) just reduced the sales cost on one product, so you can afford to discount the sale price on the total transaction.
Another synergy is to cut costs (in product/program development) and increase revenue by selling the same or similar products under different brands. Retain the old entity names after the merger (example: HP/Compaq, IBM/Sun), but replace competing product lines with rebranded versions of the "best version" (probably cheaper to build or more profitable, but possibly highest volume). Eventually, customers will forget that there's really less competition and less choice. (At least, that's the theory.)
Just remember this: synergy is all about benefits for the producer; any advantages for the consumer are secondary to that. It's a marketeer's dream (and a savvy consumer's worst nightmare), but it's still synergy.
Boldrin and Levine have posted the bulk of their book Against Intellectual Monopoly on the Web. So, if you don't want to purchase a dead-tree version of the work, you can download what amounts to an e-book (free of charge, but minus the front and back matter) from Mssr. Boldrin's website.
Last time I checked, there was a copyright regime in place for published works. I call these authors enlightened, not hypocritical, for finding a middle ground. Their publisher, Cambridge University Press, probably requires a copyright on any works that they distribute, if for no other reason than to protect their investment. The publisher also shows a degree of enlightenment, in allowing the simultaneous posting in digital form without DRM, unlike most publishers these days. By the way, Lawrence Lessig has followed a similar approach with his book Free Culture. (That work is also copyrighted, but the PDF version on the Web is released under a Creative Commons license.)
Apparently I was unclear in my critique of Mark Shuttleworth's proposal to replace the "filing system" model implicit in GNU/Linux. Understanding the hierarchical model of UNIX file systems works for me, but not for a user like my mother. (I helped introduce her to computing at age 72 or so, though she opted for Windows over the MacOS approach that my spouse and I originally recommended. I watched how files piled up on her computer over time. It's clear that she doesn't grok files and directories, but she doesn't need to understand that model for what she does.) By the same token, her "filing scheme" would never suffice for the thousands of files that I use in my own projects.
Perhaps the easiest problem to tackle is that there appears to be no consistent set of rules for saving files by default. Application A stores files in one place, and application B in another. Your 99.9% of users probably expect that data is data, and therefore that it should be "all in the same place" unless they say otherwise. Turns out that their expectations are more sophisticated than the "system design", which is little more than aggregating applications from disparate sources.
Mark could make a notable contribution to usability if he could get the developers of widely used applications -- Open Office, Gnumeric, Acrobat Reader, Firefox, the GIMP, etc. -- to save files in a consistent fashion -- consistent across applications. Then develop some kind of Spotlight-type wrapper for "find" for those users who don't use an explicit filing system to organize/retrieve their work. Such a scheme would make it easier to form an accurate and useful mental model of how the system works in this regard. It's not revolutionary technology, but would make life easier for a lot of users (myself included), and just might be simple enough (to implement) that developers would buy into the idea. A more radical approach is likely to die on the vine.
From the headline I thought this was going to be about lost/cross-linked clusters not idiotic users forgetting where something is saved. ... These changes are independent of the underlying file system ...
Alas, Mark Shuttleworth chose to use the term "file systems" in referring to the method(s) that people use to organize data on their computers. Before 1972 or so, few people would have been confused. However, I'm intrigued by efforts -- such as Jef Raskins' Archy project -- that appear to deliberately conflate the two notions in service to the end-user.
That said, I'm not keen to use a system that forces me to use somebody else's scheme for document storage and retrieval. In 25 years of using UNIX, I've developed (and continue to refine) my own filing schemes. I'm more than comfortable with the "files and folders" model and my understanding of the underlying (hierarchical) storage scheme serves me well.
Beware the new dogma, especially when it's based on the notion that "one size can fit all" -- apparently the implicit guiding principle behind Windows and MacOS. Not always, but often, there's too much dumbing down in the process of presenting the system through a GUI. As an expert user, I hate to be slowed down for routine or repetitive tasks by moving a mouse, highlighting icons, and selecting from menus; give me the command line interface. For tasks that I don't perform very often, such as configuring a network interface, invoking a calculator program, or (shudder) launching a word processor, I appreciate a simple, easy-to-use GUI with consistent behavior across the O.S. (There's the rub.)
If Mark's goal is a one-size-for-all file storage model, then I will likely never agree with it. Not because I think I'm better or smarter, but because people don't think alike or work alike. Give us systems that support diverse filing schemes -- not just by content/topic or file name, but by date, tagging (user-supplied metadata), origin, file type, whatever.
Understanding the low-level model of a UNIX file system plus a few commands (including the byzantine "find") allows an experienced user to do some of this, but that initial learning curve can be a bitch. So find ways to make that expressive power accessible to beginners and occasional users. And do so in ways that help them develop a useful mental model of what's going on, and facilitate the transition to power user status (for those who want it).
*** Rant off
I'd settle for simple consistency in the menus for common operations such as opening and closing files from applications with GUI front ends.
I agree that there's a place for simulation, but some commenters seem to think that it is sufficient. So Boeing built and successfully flew a 777; that says nothing about how easy it is for the pilot to use the controls, or the mechanic to repair a tailfin assembly, or for a passenger to put their pants back on after using the restroom. Can a simulation package replace feedback from a pilot's attempt to use a control panel? (For that matter, DOES it even make sense to simulate this with a CAD model? Well, I suppose there's always a virtual reality setup ...)
Ditto with antenna design. The value of the simulation software is in optimizing effectiveness at receiving a signal. That has nothing to do with the ease or difficulty of installation.
Have you tried to change motor oil and filter on a recent model subcompact car? It's much harder than it was 25 years ago, unless you have a lift (or mechanic's pit), sometimes special tools, and can reset the onboard computer so that it doesn't report you as voiding the warranty. It's obviously not a design objective to facilitate owner-performed maintenance. There could be any number of reasons for this, but it seems to me that "easy to change the oil" would also translate into more productive mechanics at service stations and car dealerships, maybe even lower prices and/or higher profits. We may never know.
I object to the dismissal (or de-emphasis) of issues or concerns that can't be simulated by hand-off software packages -- such as installation and upgrades; ease of use; maintenance and repairs; you know -- all that stuff that involves a messy human. (And maybe someone who ultimately might determine whether you remain employed and/or your employer remains in business. Ah, if only it were that simple ...) Alas, your Pointy-Haired Boss can sabotage any attempt to do the right thing, so you might need to use people skills -- you do have some, don't you? -- to make your case.
Certainly there's a place for simulation(s). If it makes it any more palatable, then think of prototyping as a hands-on simulation that attempts to address the interface(s) where user meets product. Of course, you need a lot more intelligence in the data analysis stage, as there's no software to substitute for thinking.
Check out the examples cited in "The Craftsman" by Richard Sennett, along with anecdotes in "The Design of Everyday Things" by Donald A. Norman in order to broaden your perspective on design to include a "user". Just maybe you can rise above the undesirable consequences of designs that don't account for the ultimate consumer of a product.