One of the most disturbing aspects of the 2004 US Election was the degree to which voters (and the media often) ignored "truth" and "evidence" in favor of faith and authority in making their decisions (see, for example,
PIPA's report on the "knowledge" of Bush and Kerry supporters. It is sad and more than a little disappointing to see the same mistakes being made on SlashDot's own forums.
The simple fact is that many of the comments already made were clearly made by those who haven't bothered to read the actual report or even it's summary of findings (well linked). The simplest summary is that given a wide variety of independent variables (i.e. data that might have some causal relationship with the outcome) and one independent variable (namely the shift in support from Dem to GOP in the presidential race between 2000 and 2004), the only significant movement occurred in predominantly Democratic counties with electronic touch-screen voting machines. The statistical tests reject virtually any possibility that these shifts were related to number of voters, income, Hispanic population, or voter turnout.
The question, of course. is what does this mean? Well, in isolation, not much. It is likely that some other factors not included in the independent variables were very significant. Unfortunately, when these results are combined with the discrepancies between the early exit polls and the vote counts. And contrary to a lot of analysis, past history has these exit polls much more accurate than they seem to have been this year.
Was there fraud then? We don't know. Evidence suggests that there may have been something going on (and the spread from 130K-260K has to do with uncertainty as to what kind of error might have taken place since misassigned votes are worth twice the difference of phantom votes). And the reality is that the rush to unauditable e-voting has made it more difficult to determine what kind of errors may have taken place.
Actually, this is a key question. One thing that is sorely lacking from most of the literature about this kind of stuff (both academic and general audience) is a real attempt to evaluate the methods or "patterns" against alternatives. Systems are developed with little or no reference to other systems and no basis for comparison.
One of the hallmarks of the scientific method is the need to develop theories that are testable. These theories are then evaluated on the basis of how well their predictions meet testable evaluation criteria. One of the main reasons that Pattern Languages are not theories is the lack of such testability and then of course evidence that could validate or falsify them.
If I want to design systems that I can trust I need design theories, their justifications and their boundaries. I can't build reliably if I don't know the justifications for these design theories and if I don't know when they can and cannot be applied to a given situation.
This is a great idea, but I think it needs to go further. I'm involved with a research project that is building a distributed filesystem and object database called NODAL. It is described in a white paper at http://nodal.sf.net.
It is focused on the general problem of knowledge and structured information sharing between collaborators, but will definitely be useful for personal information organization as well.
Actually, what I've said is that they've claimed to be studying usability and describe some principles of usability, but then actually constructed the tests so that they were actually looking at transparency instead. All of the recommendations are descriptions of ways to make the system more transparent.
A system really needs both properties, yet virtually all GUI development and research concentrates on transparency while supposing that it is discussing usability. If you are only interested in serving naive or casual users then transparency is fine. The issue of transition from naive to natural and improvement of the power user's subtle interpretation and interaction with the system is almost never considered.
In designing systems and user interfaces, it is
fundamentally important to not confuse two distinct concepts: usability and transparency.
Usability is directly related to the efficiency of
performing tasks and the ability to anticipate the
user interface for new tasks.
Transparency is the "intuitiveness" of the interface or system. It is primarily a measure of
how easy it is for a naive user to come into the
system and get a something done.
Transparency is intimately related to the experience of the users being examined. In a certain respect, it is a measure of familiarity.
Unfortunately, you will get high transparency
scores nowadays if you simply look and act like
MS Windows.
Usability is a whole other bag of onions. Some of
the features of a transparent interface are relevant in assessing usability, but only to a point. While transparency is something critical for new or casual users, it can be almost completely irrelevant to an experienced user. Once a certain level of familiarity is acheived, usable systems are those that make the most common tasks the most efficient to access and provide easy means of aggregating and controlling common
sequences of tasks. Emacs is an immensely usable
system that has a very low transparency score.
It is interesting to note that the Usability Principles in this study seem to be correctly labelled: they *are* related to interface usability. However, the assessment methodology seems to be primarily measuring *transparency*.
I'd say that this is a basic flaw in the study and
colors the recommendations highly.
It would be nice to see someone do a similar study
but concentrate on the power users and address the
issues around high performance usability.
This is a great opportunity for the Open Source movement, but it needs to be formulated and focused in the right way.
In general, groupware systems have suffered from the notion that the real problem is to integrate a number of different communication and planning applications into a useable, multi-user system.
This is a perfectly respectable, goal but will never lead to the revolution that is necessary.
What is really needed is vision of a whole system for collective knowledge management and group work. The most important pieces of this are a shared, interactive, structured document store that allows for live collaboration in the production of collective knowledge. Doug Engelbart (who has actually been working towards these goals for at least 40 years now) calls this component a Dynamic Knowledge Repository, and he has a very clear understanding of what its requirements are. Given this substrate, a wide range of tools for task management, workflow management, and user modelling (amon other things) can be brought together with (hopefully) minimal effort.
You might see where I'm going. There has been a lot of work done in researching this problem and there have been a number of different groups working toward this goal. Engelbart's group at McDonnell Douglas actually implemented a system of this sort and called it Augment. It would be a shame (and sadly not atypical of open source projects) to ignore the insights of this man and his work.
More specifically, Doug and a number of us have been engaging in a design process for some time. I think we have a fairly clear idea of what such a system will look like using modern technologies and approaches. Mail me for more information. Or visit the OHS Project pages (currently pretty thin).
Check out the tsmApi Public License. It is essentially the Mozilla PL with a few more guarantees as far as extension of patent rights by developer, notification of the original developer, and API compatibility.
We have not as yet sought OSI certification, but it definitely conforms to the Open Source Definition.
You're missing the point completely (and the above article articulates it well for once). The GNU/Linux name is not about ideology at all, it is about vision. It is about the GNU Project, which although fueled by ideology can easily be considered on its merits alone.
The GNU Project has always been about creating a 100% free (in GNU terms) computing environment. The kernel is only a small (albeit important) part of that. The project "adopted" non-FSF free components because they were good solutions and contributed to the overall goal. They have never claimed credit for them.
There is no doubt that Linux has been a key component of the realization of the GNU project (although RMS will argue that it is by no means complete). But frankly, it has always been the GNU project, and was for long before Linus Torvalds came along. Free software existed before the FSF, but RMS and the FSF created the "free software movement" that you are so fond of. This is about easily verifiable history folks. And its not rocket science to check it out.
What amazes me about this whole debate has been the bile directed towards RMS and the FSF over this issue when all it really comes down to is the question of credit. There has never been any attempt to take credit for Linux away from Linus in any way. The system, as a whole though, has never been his and he has never taken credit for it all. What the FSF claims credit for has always been the vision, the plan, and the creation of free replacements for what essential non-free components of the system. And if you'd actually pay attention rather than going off half-cocked whenever you hear the GNU/Linux moniker, this would be obvious.
What you get on your SuSE, RedHat, Debian or Slackware CDs is the GNU system as RMS articulated it 15 years ago. All most hackers ask for is credit where credit is due, and here it is definitely due.
Slashdot Mirror
The simple fact is that many of the comments already made were clearly made by those who haven't bothered to read the actual report or even it's summary of findings (well linked). The simplest summary is that given a wide variety of independent variables (i.e. data that might have some causal relationship with the outcome) and one independent variable (namely the shift in support from Dem to GOP in the presidential race between 2000 and 2004), the only significant movement occurred in predominantly Democratic counties with electronic touch-screen voting machines. The statistical tests reject virtually any possibility that these shifts were related to number of voters, income, Hispanic population, or voter turnout.
The question, of course. is what does this mean? Well, in isolation, not much. It is likely that some other factors not included in the independent variables were very significant. Unfortunately, when these results are combined with the discrepancies between the early exit polls and the vote counts. And contrary to a lot of analysis, past history has these exit polls much more accurate than they seem to have been this year.
Was there fraud then? We don't know. Evidence suggests that there may have been something going on (and the spread from 130K-260K has to do with uncertainty as to what kind of error might have taken place since misassigned votes are worth twice the difference of phantom votes). And the reality is that the rush to unauditable e-voting has made it more difficult to determine what kind of errors may have taken place.
One of the hallmarks of the scientific method is the need to develop theories that are testable. These theories are then evaluated on the basis of how well their predictions meet testable evaluation criteria. One of the main reasons that Pattern Languages are not theories is the lack of such testability and then of course evidence that could validate or falsify them.
If I want to design systems that I can trust I need design theories, their justifications and their boundaries. I can't build reliably if I don't know the justifications for these design theories and if I don't know when they can and cannot be applied to a given situation.
In a series of essays on my weblog, I've started to explore some of these ideas in more detail. I'd appreciate feedback.
This is a great idea, but I think it needs to go further. I'm involved with a research project that is building a distributed filesystem and object database called NODAL. It is described in a white paper at http://nodal.sf.net.
It is focused on the general problem of knowledge and structured information sharing between collaborators, but will definitely be useful for personal information organization as well.
Actually, what I've said is that they've claimed to be studying usability and describe some principles of usability, but then actually constructed the tests so that they were actually looking at transparency instead. All of the recommendations are descriptions of ways to make the system more transparent.
A system really needs both properties, yet virtually all GUI development and research concentrates on transparency while supposing that it is discussing usability. If you are only interested in serving naive or casual users then transparency is fine. The issue of transition from naive to natural and improvement of the power user's subtle interpretation and interaction with the system is almost never considered.
In designing systems and user interfaces, it is
fundamentally important to not confuse two distinct concepts: usability and transparency.
Usability is directly related to the efficiency of
performing tasks and the ability to anticipate the
user interface for new tasks.
Transparency is the "intuitiveness" of the interface or system. It is primarily a measure of
how easy it is for a naive user to come into the
system and get a something done.
Transparency is intimately related to the experience of the users being examined. In a certain respect, it is a measure of familiarity.
Unfortunately, you will get high transparency
scores nowadays if you simply look and act like
MS Windows.
Usability is a whole other bag of onions. Some of
the features of a transparent interface are relevant in assessing usability, but only to a point. While transparency is something critical for new or casual users, it can be almost completely irrelevant to an experienced user. Once a certain level of familiarity is acheived, usable systems are those that make the most common tasks the most efficient to access and provide easy means of aggregating and controlling common
sequences of tasks. Emacs is an immensely usable
system that has a very low transparency score.
It is interesting to note that the Usability Principles in this study seem to be correctly labelled: they *are* related to interface usability. However, the assessment methodology seems to be primarily measuring *transparency*.
I'd say that this is a basic flaw in the study and
colors the recommendations highly.
It would be nice to see someone do a similar study
but concentrate on the power users and address the
issues around high performance usability.
This is a great opportunity for the Open Source movement, but it needs to be formulated and focused in the right way.
In general, groupware systems have suffered from the notion that the real problem is to integrate a number of different communication and planning applications into a useable, multi-user system. This is a perfectly respectable, goal but will never lead to the revolution that is necessary.
What is really needed is vision of a whole system for collective knowledge management and group work. The most important pieces of this are a shared, interactive, structured document store that allows for live collaboration in the production of collective knowledge. Doug Engelbart (who has actually been working towards these goals for at least 40 years now) calls this component a Dynamic Knowledge Repository, and he has a very clear understanding of what its requirements are. Given this substrate, a wide range of tools for task management, workflow management, and user modelling (amon other things) can be brought together with (hopefully) minimal effort.
You might see where I'm going. There has been a lot of work done in researching this problem and there have been a number of different groups working toward this goal. Engelbart's group at McDonnell Douglas actually implemented a system of this sort and called it Augment. It would be a shame (and sadly not atypical of open source projects) to ignore the insights of this man and his work.
More specifically, Doug and a number of us have been engaging in a design process for some time. I think we have a fairly clear idea of what such a system will look like using modern technologies and approaches. Mail me for more information. Or visit the OHS Project pages (currently pretty thin).
Check out the tsmApi Public License. It is essentially the Mozilla PL with a few more guarantees as far as extension of patent rights by developer, notification of the original developer, and API compatibility.
We have not as yet sought OSI certification, but it definitely conforms to the Open Source Definition.
http://oss.sgi.com/projects/jessie/
http://oss.sgi.com/projects/jessie/
You're missing the point completely (and the above article articulates it well for once). The GNU/Linux name is not about ideology at all, it is about vision. It is about the GNU Project, which although fueled by ideology can easily be considered on its merits alone.
The GNU Project has always been about creating a 100% free (in GNU terms) computing environment. The kernel is only a small (albeit important) part of that. The project "adopted" non-FSF free components because they were good solutions and contributed to the overall goal. They have never claimed credit for them.
There is no doubt that Linux has been a key component of the realization of the GNU project (although RMS will argue that it is by no means complete). But frankly, it has always been the GNU project, and was for long before Linus Torvalds came along. Free software existed before the FSF, but RMS and the FSF created the "free software movement" that you are so fond of. This is about easily verifiable history folks. And its not rocket science to check it out.
What amazes me about this whole debate has been the bile directed towards RMS and the FSF over this issue when all it really comes down to is the question of credit. There has never been any attempt to take credit for Linux away from Linus in any way. The system, as a whole though, has never been his and he has never taken credit for it all. What the FSF claims credit for has always been the vision, the plan, and the creation of free replacements for what essential non-free components of the system.
And if you'd actually pay attention rather than going off half-cocked whenever you hear the GNU/Linux moniker, this would be obvious.
What you get on your SuSE, RedHat, Debian or Slackware CDs is the GNU system as RMS articulated it 15 years ago. All most hackers ask for is credit where credit is due, and here it is definitely due.