Jonathon Exley <Jonathon.Exley@kordia.co.nz> wrote;
That's the problem - as a propellorhead I don't make the purchasing decisi ons. I can recommend products but low cost speaks more loudly than "this g ear is a dog to work with". I don't really believe that manufacturers make crippleware user interfaces for thier products to encourage people to buy a more expensive range. I a m more inclined to think that the software developers didn't have a good r eq uirements spec to work from and made it up off thier own back. With the wealth of experience of people using these devices in this forum, maybe we could collate some good advice on what features of a UI are real ly important. Hopefully there are some manufactures listening who can take the advice on board for the next product they develop.
The trick to deailing with this as a propellorhead[sic] is to include a *monetized* estimate of the increased manpower OPEX of using the 'dog to work with' box. And a TCOS figure over the projected lifetime of the units. No need to 'fight' with management about it, just understand 'how' they make the decisions, and give them the informatin they need to make the decision come out 'your way'. Aside -- on your other point, there are *many* _documented_ cases of manufactuers deliberately crippling certain features so as to not cannibalize the sales of higher-riced units. IBM was medium-notorious for this. The original IBM-PC keyboard had 'non- standard' positioning for several keys (the extra key between 'z' and 'left shift', the location of 'caps lock', and the bastardized shape/position of 'enter') -- *expressly* to discourage using a PC in place of a dedicated higher-priced IBM 'word processor' (the Displaaywriter ??). Also, the PCjr used the _same_ floppy-controller chip as it's big brothers, *BUT* the interrupt line was not connected, and _extra_ hardware had to be included in the to compensate for the failure to use the interrupt. This was done exprerssly to cripple performance -- so it was useful only for hobby/game use, and not for any 'real' work (i.e. couldn't do serial I/O _while_ any floppy I/O was in prgress. To do file transfers, it took custom code that would 'suspend' the serial port operation while reading/writing the floppy, and then 'resume' it after the floppy operation was complete. There is absolutely no doubt that this was a deliberate 'crippleware' design, given that they had to -add- extra hardware, vs doing it the 'compatible' way. Yup, they deliberately spent extra money to make it 'incompatible'.