I've seen software with the opposite problem-- simulation tools applied to problems outside the range they were designed to handle. For example, a tool that idealizes gases in a room as well-mixed, used to analyze smoke movement during a fire. Or a program that assumes ducts have no air leaks, used to estimate energy losses in a duct system. In cases like these, the results aren't total garbage, but they do have to be interpreted very carefully.
For some software, a feature list isn't just "what the software does." It's also a list of warnings about where the results should be taken with a grain of salt.
Aren't they the same thing? Feature lists describe what your software can do, which shapes what people can do with your software.
That GarageBand for iPad is accessible to all might be more to do with the platform than the featureset.
How to remove Red-eye in Picasa http://graphicssoft.about.com/od/picasa/ht/redeye.htm
Both pieces of software can remove redeye. For Picasa the instructions boil down to "Click the Fix Red-eye button" whereas Photoshop involves layers, Gaussian blur, saturation, eye droppers.
Which would you say is more accessible for someone maintaining a photo album? Photoshop has more features, but Picasa is more useful to me (in a certain context, obviously.)
http://help.adobe.com/en_US/photoshop/cs/using/WSfd1234e1c4b...
The original post seemed to be saying 'it's not the features, it's how usable they are', to which I agree wholeheartedly. I just felt that the clever title was a confusing way of saying 'usability trumps features'.
Furthermore, I'd suggest that the iPad is what makes GarageBand so usable and compelling an experience for audio newbies; it's not purely down to the software (although it's certainly excellent). My friend's kids love djay for iPad, for example, but they think my physical decks are 'lame'.
Technically, they had the feature but the feature didn't help the doctors be better doctors. Features don't automatically translate to outcomes.
Technically, they had the feature but the feature didn't help the doctors be better doctors. Features don't automatically translate to outcomes.
How can you determine utility of a feature before it is built? Well the answer is you cant! And surely not for a High End Medical device!In fact your whole argument is based on incorrect assumptions, well if you are building something like a GarageBand or one of the Me Too To Do list/Collaboration apps, go ahead sure do whatever you want. But when you are creating an EMR software or an MRI machine which costs Millions of dollars you better make sure that it has all types of features and customization capability.
The problem is that you are confident in your skills as a developer to predict the needs, While your hunch might be correct with software that is used in daily life, it might be totally wrong while making something that is not
Also "What people can do with your software" is a subset of "What software can do". Thus its the software that is the limiting case.