[H-GEN] In office scheduling program...

Anthony Towns aj at azure.humbug.org.au
Thu Jun 1 01:47:08 EDT 2000

On Thu, Jun 01, 2000 at 10:37:18PM +0000, Andrew Draper wrote:
> > One day I'd like someone to take me through the logic that shows
> > intuitiveness is (the best|the only|a reasonable) measure of
> > the ease of use and general worthiness of any given piece of software.

"intuitiveness" is a reasonable measure of "ease of use" in that it's
an exact measure of "ease of use given no background knowledge". Most
people start with no background knowledge, so it's a relevant measure
for most people who'll use the product for at least a couple of hours
of the product's lifetime. If you assume everyone's a complete idiot
incapable of learning anything to do with computers, it's an even more
accurate measure of "ease of use".

The most intuitive program is a special purpose one where you can just
say "doit!" and have exactly what you want done.

> In response to this, from a management perspective, a business would 
> adopt an inferior product if it required less staff training and 
> offered the features desired or close to it (more or less).

From a management perspective, minimising both:

	C_t = C_u + t * C_o
and	C_u

is important (where C_t is total cost of ownership, C_u is upfront cost,
C_o is ongoing cost per unit time, and t is the lifetime of the product).

For small businesses, minimising C_u is important because you don't
necessarily have the $_u. So to speak. But it's far from the only part
of the equation: for large t, minimising C_o can be worth a somewhat
higher C_u.

Factors affecting C_u include training, and cost of the software. Factors
affecting C_o include maintenance (upgrades, bugfixing, recovering lost
data, maintaining hardware requirements, etc), retraining (if you want
to do something more complicated, can you just tweak a few things and
not have to introduce new software?), and other things.

Having stuff work "intuitively" is generally good for minimising C_u, but
it generally means you don't get any benefit in "retraining". That is,
the learning curve looks like a square wave:
	impossible   |       |
	             |       |
	             |       |
	hard         |       |
	             |       |
	             |       |
	easy         |_______|

	               functionality ---->

Lengthening the bottom edge of the square (ie, making more stuff both
possible and easy), introduces a larger cost in maintenance (more system
requirements, "smarter" programs taking care of more stuff, with the
corresponding greater possibility of catastrophic failure).

> In my line of work, people still deal in pen and paper. 

Pen and paper isn't that easy to work with. Everyone's already spent how
many years learning how to write? And how many years learning to add
numbers together? With a computer, you can just press the little keys
with the numbers on them, and not have to worry about how you grip the
pen. Then you can move the little mouse thing until it's on the nice
little "add it all up" picture, and not even have to know what 2+2 is.

You need some fairly nice motorskills to do the mouse thing, but it's
not too difficult to pick up, and you need to be able to read, and
knowing where the keys are on the keyboard makes things a lot faster,
but you don't need four years of intensive training to do it...

> For me to train staff myself is too costly, and I can't afford to pay 
> someone else to do it. [...] The merit value of a 
> software application is the time cost in its use. Sure, MS Office 2000 
> almost needs a supercomputer and a personal loan to buy and run it, 
> but it lets almost any dribbling idiot perform "real" work quickly.

Which is why most secretarial staff take courses in how to use it?

In addition, if you're willing to shell out the large C_u for MS Office
2000 and the supercomputer to run it ($1k + $2k?), then a more cost
effective purchase might be a cheaper computer ($1k), some free software,
and a significant amount of training in that software ($2k).

This applies better to gcc vs Visual C++, as there's already a market for
gcc (and emacs, ddd, gdb, whatever) skills, so an employee can transfer
those skills pretty successfully to other organisations, and a buyout
won't necessarily require lots of retraining. Traning staff in LaTeX and
emacs, or LyX might be less transferable though, for example. Similarly,
there's the problem of finding someone who'll teach your staff something

Supposing your free software then has a learning curve looking something

	impossible   |              
	             |                    ___
	             |              _____|
	hard         |         ____|
	             |     ___|
	             |  __|
	easy         |_|

	               functionality ---->

and your staff are already on the second or third top rung, or so after a
$2k course. They can already do pretty much all they could do with Office
and if they need to learn more, that's a much smaller step up. They
can do more stuff than they could before, there's lower retraining and
maintenance costs, and a similar (?) upfront cost. In theory, that's a
win-win situation. In practice, there's a bunch of caveats, some of which
are mentioned above.

But intuitive software isn't necessarily a silver bullet for expenses.

> With that in mind, there needs to be a structured logic present within 
> the user interface that allows people to guess where the feature 
> lives.

This isn't the whole picture. There's a very complete, structure logic
underlying emacs, for example, but that doesn't make it intuitive.

The underlying logic needs to be *simple* to be picked up rapidly,
but conversely it needs to be complicated to be expressive enough to do
lots of stuff. That's why we have shells and programming languages (with
their accompanying complicated logics) rather than just icons and menus
(with their much simpler logics).

> Let's bring these things into the public, argue, debate and maybe 
> we'll get some interest going and might even create a new solution, or 
> discover a perfect one is already out there.

Arguing and debating in free software rarely gets anything done. Getting
something done (ie, prototyping), and then discussing it works much more
effectively. But you do have to get the order right.


Anthony Towns <aj at humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.

  ``We reject: kings, presidents, and voting.
                 We believe in: rough consensus and working code.''
                                      -- Dave Clark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 350 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20000601/ef20e9d7/attachment.sig>

More information about the General mailing list