That may be so (1024x768 being the default resolution for Linux for ages), but 90% of the ingimp users so far are Windows users (see http://www.ingimp.org/stats/system_stats ). So your explanation of the result doesn't explain this finding.
Yeah, I'm kind of surprised no one is talking about privacy, either.
But then again, we are very upfront about what data we collect and the ways your privacy could be affected. And... you can always inspect the source code if you have any privacy concerns.
Qualitative methods like the ones you suggest -- observations, interviews, ethnographic methods, contextual design -- are some of the best methods out there to uncover the data you suggest should be collected. In fact, my HCI class focuses exclusively on these methods. They're cheap, they're fast, and you got a lot of data very quickly.
ingimp doesn't intend to supplant these techniques. In fact, it would be a mistake for people to assume it could or should. And the GIMP project already has a good group of people who are using the very techniques you propose (see http://gui.gimp.org/ ).
However, GIMP is a very general purpose application and there are limited resources to improve it. How should future development efforts be prioritized? Are most users experts or novices? Do they use it to color correct images, crop and resize them, or are they doing more sophisticated things like graphic design over hours of use? What are common workflows? Are they the same workflows we assume people are doing, or are they completely counter to our expectations?
Quantifying broad usage is not something that can be done by qualitative methods alone, but it can help to focus future development efforts if you can better characterize your user base, how they're using the software, and how many people are using it in various ways. With this data, you can optimize for the minority or the majority -- at least you know who you are optimizing for.
One of the benefits of this data is that longitudinal patterns of usage can be discovered that wouldn't come out in laboratory based usability studies. For example, if a new feature is added, these stats can help you determine whether people are adopting and using the new features as expected. Longitudinal data is rare -- we're building a longitudinal data store right now unlike any other in the open source community.
One of the challenges that is glossed over is that creating a sustainable usability infrastructure is no trivial task. We're collecting data in a very unobtrusive way that requires very little effort on the part of the user, and that data has a fairly high degree of ecological validity -- people are using the software in their own environments, not in an artifical usability lab. Again, while not a replacement for qualitative methods, the data we collect do help answer other questions valuable to guiding development efforts in a resource-constrained environment. Other ideas on creating a self-sustaining usability infrastructure, which does not overly burden the developers or users, are certainly welcome.
On a final note, there are benefits to this data beyond usability itself. For example, we've found that people use the most frequently used command stats to discover features/commands/plug-ins they weren't previously familiar with, and which they find valuable. The data set is a bit richer than it at first seems.
With the OSS version, you know exactly what data is being collected and where it is being sent. And, we make it all available for anyone to analyze, so you know who can potentially see it and make use of it. These are typically all unknowns with closed source software.
Because involvement in human-subjects research is voluntary, there will always be a self-selection bias. (That is, we cannot force people to use this software any more than we can force people to come into a usability lab to participate in a usability study.) However, we can still estimate the representativeness of the population by understanding the types of people likely to download and install ingimp, and those who are not. If you fall in the latter camp -- you'd never want to use ingimp -- we really want to talk to you. Send us an email at the email address given on the site: http://www.ingimp.org/contact.
We're working to be a part of the official Debian distribution, we have a single Windows installer, and we're readying a Mac port -- we want to make it as easy as possible to download and use this distribution so it's not just "self-selecting geeks":)
But self-selection will always be a problem. If you have ideas on how to get around self-selection bias in human subjects research -- where people must volunteer to participate -- please let us know!:)
And just to clarify, we're not trying to find usability problems as much as we are trying to quantify behavior/activity/system setups. Other efforts are helping to identify critical usability issues (see http://gui.gimp.org/ ). Our data provide an additional perspective on GIMP usage in the wild -- data that exist nowhere else. We're also quite unique among both commercial and open source projects: No other software collects this type of usage data, makes the data collection and dissemination process as transparent as we do (especially since it is open source), and makes all the collected data available for anyone to analyze. We're building a very valuable repository not only for understanding GIMP's usage in the wild, but also for research involving data mining, intelligent user interfaces, and so on.
There is a very active group of individuals who are currently doing things like expert walkthroughs and observational studies: See http://gui.gimp.org./
Our data is intended to complement this data by quantifying the ubiquity of tasks/activity/system setups. For example, what are typical resolutions of monitors? This type of information can help focus design by indicating what types of interaction designs are feasible and not feasible given the hardware of current users. What we've seen so far is a far greater number of 1024x768 resolutions than anticipated. Breaking these numbers down to see where in the world these resolutions are being reported is one of the next steps we plan to do to better contextualize the data. See http://www.ingimp.org/stats/monitors.
We also have some emperical data to support the notion that the multiple windows design choice is not the best. Our data indicate that the percentage of the monitor covered by the document window is typically about 50% for most users (again, see http://www.ingimp.org/stats/monitors ). Most Photoshop users seem to maximize their document windows; with GIMP, this seems to happen much less frequently, probably because doing so obscures GIMP's other windows.
One of the things we do to combat the potential issues you identify is to carry out observations of real users to understand what high-level behaviors are associated with the low-level log data. For example, we discovered that some users occassionally duplicate a document and then immediately close it. Doesn't happen often, and only with a subset of users.
Why do they do this? Because they are Photoshop users using Photoshop key bindings in GIMP -- Ctrl-D deselects in Photoshop and duplicates in GIMP. So with this set of actions in the log, we can identify Photoshop users using GIMP.
The other way we address this problem is to provide multiple perspectives on the data. Looking at the Command Stats, you'll notice that we break down the most frequently used commands in a number of ways: By session, by user, and so on. There are multiple ways to consider "most frequently used commands" and we are sensitive to the fact that any one perspective is not the one correct way. As an example, raw counts of command use will put tools like the paint brush at the top of the list. But perhaps only 10% of the population uses the paint brush. So we also provide information on the percent of users who use a particular command to grant you these additional perspectives.
Finally, we're constantly adding new stats; we've only just begun mining this data.
Because involvement in human-subjects research is voluntary, there will always be a self-selection bias. However, we can still estimate the representativeness of the population by understanding the types of people likely to download and install ingimp, and those who are not. If you fall in the latter camp -- you'd never want to use ingimp -- we really want to talk to you. Send us an email at the email address given on the site: http://www.ingimp.org/contact.
In any case, having some data is better than having no data at all. Currently, there is a very active and vibrant group of individuals working on GIMP usability issues (see http://gui.gimp.org/ ). ingimp's data complements this other data to help quantify the ubiquity of behavior/activity/computer hardware setups in the wild.
I can't help but mention a project similar in flavor that we did at MERL and the Everyday Computing Lab at Georgia Tech. It's called Social Net and its basic premise is to use patterns of physical proximity, over time, to infer relationships between people.
The basic notion is this: we regularly spend time physically near people we are related to. We can thus go the other way and use physical proximity data to infer relationships between people. For example, during weekday business hours, I am near business colleagues, while at night and on weekends I am near friends and family. By simply observing these patterns of who I am near, when, and for how long, the system can infer the types of relationships I have with the people I encounter (for example, it can distinguish between business and social relationships).
The first application of this idea was Social Net, a system to introduce users to new people. Social Net notices patterns of physical proximity over time (i.e., frequent and/or long encounters) to infer that two people are engaged in a similar activity (or that they share interests). If the two people don't know each other, Social Net looks for a mutual friend (ie, someone who knows both). If a mutual friend is found, he/she receives a message suggesting the two people should be introduced.
Using physical proximity data, over time, allows Social Net to infer shared interests between people without requiring them to identify what those interests are. It has the nice property of filtering out chance encounters with people on the street, since we it considers the duration and frequency of an encounter. Finally, the mutual friend brings accountability into the whole process, so that your device is not telling you to go up to a complete stranger and introduce yourself.
There are other neat things you can do with this data. For example, an app can infer business vs. close interpersonal relationships, then attenuate a cell phone's ringer when the user is near friends or family (since it will be able to infer that the other people are friends or family based on past histories of physical proximity). An app could also automatically exchange music lists between people as suggested by Korteum, but use patterns of physical proximity to infer shared interests, rather than requiring users to manually enter those interests in. The real hurdle to getting these apps out there, of course, is finding the one killer app that makes people less wary of transmitting presence information into the environment.
Actually the parallel port card reader I have from Lexar Media is fast enough for any of my applications on Windows - it takes about 1 or 2 minutes to download a whole 64 MB card. It'd be nice to be able to read that in through Linux, though.
Actually, I knew about the Apple II's, but they were seen as elementary school computers. I needed a computer for college, and Intel boxes with DOS was the status quo in my area (Western NY).
But have you ever gotten a machine from an OEM with some funky DOS/Windows drivers supplied by the OEM to work with their funky hardware? OEM's often have to coordinate their specific hardware with the OS, so why not do the same with the BeOS? Of course there won't be as many resources (read programmers, etc.) to pair the two together, but with plain vanilla hardware, the task will be much easier.
As for the reasons to sell a machine with BeOS (and Linux, too, for that matter): more choices for the consumer, more bullet points in the advertisements, and all the free publicity generated for being the first kid on the block to sell a box with 3 OS'es pre-installed.
I didn't want to run DOS in the 80's, but I didn't have an alternative (and didn't know about the Mac), so I got an 8086 with DOS. That's part of the problem today - consumers don't know alternatives exist because Microsoft won't let OEM's provide alternatives (apparently).
But say Gateway advertised their boxes with Windows 95 and BeOS as OS options. As a typical consumer, I'd be like, "What's this BeOS thing?" Maybe I'd do a little reading on it. Maybe I'd find that it might be a cool thing to try out. And if it came for free, I'd definitely order a box with it on there - people love to get stuff for free. Once I started using it, maybe I'd find it did something better than Windows, and so on, and so on.
A demand may be there for Be, but Microsoft is attempting to preemptively squash any prospect of demand. That's one of the points Gassee's making.
./'ers will appreciate this movie. And don't get hung up by the fact that at one moment the guy's screen is a Mac, and the next moment it's showing a DOS "C:\" prompt. Just take it as a cross-platform jab at computers;)
The "gangsta" soundtrack and film style of some of the scenes was the genius of this movie.
...which is exactly what the character in the movie says: "Yeah, they did it in Superman III, and some hackers did it in the 70's and got caught for it."
No one pretended to be clever in the movie, which was refreshing - you didn't have some one magically cracking into the CIA's computer from a van parked outside (a la "Mission Impossible"). And when they check their bank statement after running their siphoning program, they find out the program had a bug in it and transferred too much money. That, too, was refreshing: a confident hacker's code had a bug in it and really screwed up (how many times have you seen that in the work place?:).
Actually, there are two alternative Dvorak layouts. The "official" breaks the brackets up, while the alternative puts them right next to each other (in the same spot as the - and = keys on a QWERTY).
I liked the idea of the Datahand a lot, and used it for a couple of weeks. However, if you look at the layout (for those who haven't tried one), many of the keys you have to "press" require a lateral (side-to-side) action of the fingers. Furthermore, I use the control key a lot, and its position required me to use my thumb a lot in an awkward position. These motions were not natural for me, and soon I had aches and pains of a different sort than I had with a regular keyboard. I also found it hard to relax my hands when using it.
Let me add that I use the Dvorak layout and the people at Datahand were very accomodating to this fact - they even offered to burn a Dvorak-specific layout ROM chip for the keyboard. By that time, however, I had determined that it wasn't my cup of tea, and had returned it. Their customer service is superb, however.
I think Datahand is on the right track - we need to completely rethink how we input into a computer, and drop the old paradigms. A combo of the Datahand, a dataglove, and the Bat (which does chording) might be a step in the right direction:)
Soulfry
A game's "concept" versus its "rules"
on
Tetris Under Fire
·
· Score: 1
Where it gets sort of fuzzy is the difference between a concept and a specific set of rules which govern the game. The concept of a flight simulator or a first person shoot-em up game is quite different than the exact rules of how a Tetris game proceeds. You can sit down and write out a clearly defined set of rules which govern the Tetris game; you can't do that with a flight sim or a Quake-like game. That is, you can say, "You have pieces of 4 blocks each, in each of these different shapes. They drop down and when a solid line is formed, it is removed, etc."
You might argue that you can say, "Well, in Quake, you shoot at something, and when it gets so many bullets, it dies. And you have health, which can be replenished with a med pack, etc." These "rules" are much more vague than the Tetris rules, and allow for a lot of room for interpetation. Hence, no one is suing over Quake-like games.
What is needed is someone familiar with this type of law to take a look at the case.
Soulfry
Can you copyright the rules to a game?
on
Tetris Under Fire
·
· Score: 1
The "look and feel", as others have pointed out, seems to be a baseless claim, as no one has succeeded in winning a l&f case in court. But what about the "rules" to the game (which I think the company is really alluding to in its email)? Can you copyright those to some extent?
If you took the game Monopoly, and replaced the squares and pawns with an "Open Source" theme (20 lines of source required to stay overnight on Debian Avenue, with the pawns being Eric Raymond, Richard Stallman, etc.), and just simply named it "The Bazaar", would you be in violation of Parker Brothers' copyright? The name doesn't sound like "Monopoly," but the rules and flow of the game are exactly like Monopoly's. I think you'd be asked to remove it pretty quickly from their legal team.
A lot of shareware games have seemed to dodge this issue by modifying the game just slightly so that it feels a lot like the original game, but is tweaked just enough that it's not a blatant copy. I think of PacMan and Galaga in the early days (there was "MunchMan" on the TI-99/4A, for example, and Ambrosia Software made its business making copies of popular arcade titles). The precedent set in the industry, thus, seems to be that it's OK to copy an original, just as long as it's not an exact copy - i.e., add some "value" to it.
I think it's an interesting issue because I'd like to do a PalmPilot-version of the board game Quorridor. It's a great game with simple rules, and can even be played with a piece of paper and pennies. But since its rules are so simple (and perfect they way they are right now, in my mind), I wouldn't change the rules a bit (and then, without a doubt, I'd be ripping off someone else's great idea).
Slashdot Mirror
That may be so (1024x768 being the default resolution for Linux for ages), but 90% of the ingimp users so far are Windows users (see http://www.ingimp.org/stats/system_stats ). So your explanation of the result doesn't explain this finding.
Michael Terry
Yeah, I'm kind of surprised no one is talking about privacy, either.
But then again, we are very upfront about what data we collect and the ways your privacy could be affected. And... you can always inspect the source code if you have any privacy concerns.
Michael Terry
Qualitative methods like the ones you suggest -- observations, interviews, ethnographic methods, contextual design -- are some of the best methods out there to uncover the data you suggest should be collected. In fact, my HCI class focuses exclusively on these methods. They're cheap, they're fast, and you got a lot of data very quickly.
ingimp doesn't intend to supplant these techniques. In fact, it would be a mistake for people to assume it could or should. And the GIMP project already has a good group of people who are using the very techniques you propose (see http://gui.gimp.org/ ).
However, GIMP is a very general purpose application and there are limited resources to improve it. How should future development efforts be prioritized? Are most users experts or novices? Do they use it to color correct images, crop and resize them, or are they doing more sophisticated things like graphic design over hours of use? What are common workflows? Are they the same workflows we assume people are doing, or are they completely counter to our expectations?
Quantifying broad usage is not something that can be done by qualitative methods alone, but it can help to focus future development efforts if you can better characterize your user base, how they're using the software, and how many people are using it in various ways. With this data, you can optimize for the minority or the majority -- at least you know who you are optimizing for.
One of the benefits of this data is that longitudinal patterns of usage can be discovered that wouldn't come out in laboratory based usability studies. For example, if a new feature is added, these stats can help you determine whether people are adopting and using the new features as expected. Longitudinal data is rare -- we're building a longitudinal data store right now unlike any other in the open source community.
One of the challenges that is glossed over is that creating a sustainable usability infrastructure is no trivial task. We're collecting data in a very unobtrusive way that requires very little effort on the part of the user, and that data has a fairly high degree of ecological validity -- people are using the software in their own environments, not in an artifical usability lab. Again, while not a replacement for qualitative methods, the data we collect do help answer other questions valuable to guiding development efforts in a resource-constrained environment. Other ideas on creating a self-sustaining usability infrastructure, which does not overly burden the developers or users, are certainly welcome.
On a final note, there are benefits to this data beyond usability itself. For example, we've found that people use the most frequently used command stats to discover features/commands/plug-ins they weren't previously familiar with, and which they find valuable. The data set is a bit richer than it at first seems.
Michael Terry
With the OSS version, you know exactly what data is being collected and where it is being sent. And, we make it all available for anyone to analyze, so you know who can potentially see it and make use of it. These are typically all unknowns with closed source software.
Michael Terry
Because involvement in human-subjects research is voluntary, there will always be a self-selection bias. (That is, we cannot force people to use this software any more than we can force people to come into a usability lab to participate in a usability study.) However, we can still estimate the representativeness of the population by understanding the types of people likely to download and install ingimp, and those who are not. If you fall in the latter camp -- you'd never want to use ingimp -- we really want to talk to you. Send us an email at the email address given on the site: http://www.ingimp.org/contact.
Michael Terry
We're working to be a part of the official Debian distribution, we have a single Windows installer, and we're readying a Mac port -- we want to make it as easy as possible to download and use this distribution so it's not just "self-selecting geeks" :)
:)
But self-selection will always be a problem. If you have ideas on how to get around self-selection bias in human subjects research -- where people must volunteer to participate -- please let us know!
And just to clarify, we're not trying to find usability problems as much as we are trying to quantify behavior/activity/system setups. Other efforts are helping to identify critical usability issues (see http://gui.gimp.org/ ). Our data provide an additional perspective on GIMP usage in the wild -- data that exist nowhere else. We're also quite unique among both commercial and open source projects: No other software collects this type of usage data, makes the data collection and dissemination process as transparent as we do (especially since it is open source), and makes all the collected data available for anyone to analyze. We're building a very valuable repository not only for understanding GIMP's usage in the wild, but also for research involving data mining, intelligent user interfaces, and so on.
Michael Terry
There is a very active group of individuals who are currently doing things like expert walkthroughs and observational studies: See http://gui.gimp.org./
Our data is intended to complement this data by quantifying the ubiquity of tasks/activity/system setups. For example, what are typical resolutions of monitors? This type of information can help focus design by indicating what types of interaction designs are feasible and not feasible given the hardware of current users. What we've seen so far is a far greater number of 1024x768 resolutions than anticipated. Breaking these numbers down to see where in the world these resolutions are being reported is one of the next steps we plan to do to better contextualize the data. See http://www.ingimp.org/stats/monitors.
We also have some emperical data to support the notion that the multiple windows design choice is not the best. Our data indicate that the percentage of the monitor covered by the document window is typically about 50% for most users (again, see http://www.ingimp.org/stats/monitors ). Most Photoshop users seem to maximize their document windows; with GIMP, this seems to happen much less frequently, probably because doing so obscures GIMP's other windows.
Michael Terry
One of the things we do to combat the potential issues you identify is to carry out observations of real users to understand what high-level behaviors are associated with the low-level log data. For example, we discovered that some users occassionally duplicate a document and then immediately close it. Doesn't happen often, and only with a subset of users.
Why do they do this? Because they are Photoshop users using Photoshop key bindings in GIMP -- Ctrl-D deselects in Photoshop and duplicates in GIMP. So with this set of actions in the log, we can identify Photoshop users using GIMP.
The other way we address this problem is to provide multiple perspectives on the data. Looking at the Command Stats, you'll notice that we break down the most frequently used commands in a number of ways: By session, by user, and so on. There are multiple ways to consider "most frequently used commands" and we are sensitive to the fact that any one perspective is not the one correct way. As an example, raw counts of command use will put tools like the paint brush at the top of the list. But perhaps only 10% of the population uses the paint brush. So we also provide information on the percent of users who use a particular command to grant you these additional perspectives.
Finally, we're constantly adding new stats; we've only just begun mining this data.
Michael Terry
Because involvement in human-subjects research is voluntary, there will always be a self-selection bias. However, we can still estimate the representativeness of the population by understanding the types of people likely to download and install ingimp, and those who are not. If you fall in the latter camp -- you'd never want to use ingimp -- we really want to talk to you. Send us an email at the email address given on the site: http://www.ingimp.org/contact.
In any case, having some data is better than having no data at all. Currently, there is a very active and vibrant group of individuals working on GIMP usability issues (see http://gui.gimp.org/ ). ingimp's data complements this other data to help quantify the ubiquity of behavior/activity/computer hardware setups in the wild.
Michael Terry
Cheers,
Soulfry
The basic notion is this: we regularly spend time physically near people we are related to. We can thus go the other way and use physical proximity data to infer relationships between people. For example, during weekday business hours, I am near business colleagues, while at night and on weekends I am near friends and family. By simply observing these patterns of who I am near, when, and for how long, the system can infer the types of relationships I have with the people I encounter (for example, it can distinguish between business and social relationships).
The first application of this idea was Social Net, a system to introduce users to new people. Social Net notices patterns of physical proximity over time (i.e., frequent and/or long encounters) to infer that two people are engaged in a similar activity (or that they share interests). If the two people don't know each other, Social Net looks for a mutual friend (ie, someone who knows both). If a mutual friend is found, he/she receives a message suggesting the two people should be introduced.
Using physical proximity data, over time, allows Social Net to infer shared interests between people without requiring them to identify what those interests are. It has the nice property of filtering out chance encounters with people on the street, since we it considers the duration and frequency of an encounter. Finally, the mutual friend brings accountability into the whole process, so that your device is not telling you to go up to a complete stranger and introduce yourself.
There are other neat things you can do with this data. For example, an app can infer business vs. close interpersonal relationships, then attenuate a cell phone's ringer when the user is near friends or family (since it will be able to infer that the other people are friends or family based on past histories of physical proximity). An app could also automatically exchange music lists between people as suggested by Korteum, but use patterns of physical proximity to infer shared interests, rather than requiring users to manually enter those interests in. The real hurdle to getting these apps out there, of course, is finding the one killer app that makes people less wary of transmitting presence information into the environment.
Actually the parallel port card reader I have from Lexar Media is fast enough for any of my applications on Windows - it takes about 1 or 2 minutes to download a whole 64 MB card. It'd be nice to be able to read that in through Linux, though.
Actually, I knew about the Apple II's, but they were seen as elementary school computers. I needed a computer for college, and Intel boxes with DOS was the status quo in my area (Western NY).
Soulfry
But have you ever gotten a machine from an OEM with some funky DOS/Windows drivers supplied by the OEM to work with their funky hardware? OEM's often have to coordinate their specific hardware with the OS, so why not do the same with the BeOS? Of course there won't be as many resources (read programmers, etc.) to pair the two together, but with plain vanilla hardware, the task will be much easier.
As for the reasons to sell a machine with BeOS (and Linux, too, for that matter): more choices for the consumer, more bullet points in the advertisements, and all the free publicity generated for being the first kid on the block to sell a box with 3 OS'es pre-installed.
Soulfry
I didn't want to run DOS in the 80's, but I didn't have an alternative (and didn't know about the Mac), so I got an 8086 with DOS. That's part of the problem today - consumers don't know alternatives exist because Microsoft won't let OEM's provide alternatives (apparently).
But say Gateway advertised their boxes with Windows 95 and BeOS as OS options. As a typical consumer, I'd be like, "What's this BeOS thing?" Maybe I'd do a little reading on it. Maybe I'd find that it might be a cool thing to try out. And if it came for free, I'd definitely order a box with it on there - people love to get stuff for free. Once I started using it, maybe I'd find it did something better than Windows, and so on, and so on.
A demand may be there for Be, but Microsoft is attempting to preemptively squash any prospect of demand. That's one of the points Gassee's making.
Soulfry.
...was when he was dreaming that his boss was having sex with his girlfriend and he (the boss) takes a sip from his coffee mug.
Soulfry
./'ers will appreciate this movie. And don't get hung up by the fact that at one moment the guy's screen is a Mac, and the next moment it's showing a DOS "C:\" prompt. Just take it as a cross-platform jab at computers ;)
The "gangsta" soundtrack and film style of some of the scenes was the genius of this movie.
Soulfry
...which is exactly what the character in the movie says: "Yeah, they did it in Superman III, and some hackers did it in the 70's and got caught for it."
:).
No one pretended to be clever in the movie, which was refreshing - you didn't have some one magically cracking into the CIA's computer from a van parked outside (a la "Mission Impossible"). And when they check their bank statement after running their siphoning program, they find out the program had a bug in it and transferred too much money. That, too, was refreshing: a confident hacker's code had a bug in it and really screwed up (how many times have you seen that in the work place?
Soulfry
Actually, there are two alternative Dvorak layouts. The "official" breaks the brackets up, while the alternative puts them right next to each other (in the same spot as the - and = keys on a QWERTY).
I prefer the "unofficial" layout for coding.
Soulfry.
I liked the idea of the Datahand a lot, and used it for a couple of weeks. However, if you look at the layout (for those who haven't tried one), many of the keys you have to "press" require a lateral (side-to-side) action of the fingers. Furthermore, I use the control key a lot, and its position required me to use my thumb a lot in an awkward position. These motions were not natural for me, and soon I had aches and pains of a different sort than I had with a regular keyboard. I also found it hard to relax my hands when using it.
:)
Let me add that I use the Dvorak layout and the people at Datahand were very accomodating to this fact - they even offered to burn a Dvorak-specific layout ROM chip for the keyboard. By that time, however, I had determined that it wasn't my cup of tea, and had returned it. Their customer service is superb, however.
I think Datahand is on the right track - we need to completely rethink how we input into a computer, and drop the old paradigms. A combo of the Datahand, a dataglove, and the Bat (which does chording) might be a step in the right direction
Soulfry
Where it gets sort of fuzzy is the difference between a concept and a specific set of rules which govern the game. The concept of a flight simulator or a first person shoot-em up game is quite different than the exact rules of how a Tetris game proceeds. You can sit down and write out a clearly defined set of rules which govern the Tetris game; you can't do that with a flight sim or a Quake-like game. That is, you can say, "You have pieces of 4 blocks each, in each of these different shapes. They drop down and when a solid line is formed, it is removed, etc."
You might argue that you can say, "Well, in Quake, you shoot at something, and when it gets so many bullets, it dies. And you have health, which can be replenished with a med pack, etc." These "rules" are much more vague than the Tetris rules, and allow for a lot of room for interpetation. Hence, no one is suing over Quake-like games.
What is needed is someone familiar with this type of law to take a look at the case.
Soulfry
The "look and feel", as others have pointed out, seems to be a baseless claim, as no one has succeeded in winning a l&f case in court. But what about the "rules" to the game (which I think the company is really alluding to in its email)? Can you copyright those to some extent?
If you took the game Monopoly, and replaced the squares and pawns with an "Open Source" theme (20 lines of source required to stay overnight on Debian Avenue, with the pawns being Eric Raymond, Richard Stallman, etc.), and just simply named it "The Bazaar", would you be in violation of Parker Brothers' copyright? The name doesn't sound like "Monopoly," but the rules and flow of the game are exactly like Monopoly's. I think you'd be asked to remove it pretty quickly from their legal team.
A lot of shareware games have seemed to dodge this issue by modifying the game just slightly so that it feels a lot like the original game, but is tweaked just enough that it's not a blatant copy. I think of PacMan and Galaga in the early days (there was "MunchMan" on the TI-99/4A, for example, and Ambrosia Software made its business making copies of popular arcade titles). The precedent set in the industry, thus, seems to be that it's OK to copy an original, just as long as it's not an exact copy - i.e., add some "value" to it.
I think it's an interesting issue because I'd like to do a PalmPilot-version of the board game Quorridor. It's a great game with simple rules, and can even be played with a piece of paper and pennies. But since its rules are so simple (and perfect they way they are right now, in my mind), I wouldn't change the rules a bit (and then, without a doubt, I'd be ripping off someone else's great idea).
So, can you copyright the rules to a game?
Soulfry