Default superschema view

[ConvertFromOldNGs]

by Robert Barr >> Tue, 14 Mar 2000 21:51:03 GMT

...... Would you want all the different applications you use every day to all have a different color schemes, be covered with logos, have different styles of buttons and controls, and all work in different ways?

Yes I would.

I look at so many unwanted blue title bars, grey backgrounds and black borders every day that I have to concentrate that bit harder to find the information I want amongst all the clutter. A visually simple, or stimulating design helps my eye find it's target.

This is not a religious argument (Sean's Luddite reference is very appropriate), it's just one of pragmatic design suited to the problem at hand. A number of BC Hayes comments were valid - quicktime overstretched a paradigm that did not translate directly onto a computer screen. However concluding that application interfaces lacking unnecessary 'windows' clutter are bad, is just bollocks.

The WIN32 libraries are becoming less of a restrictive *framework* and more of a flexible toolset. Of course this freedom provides more scope for mistakes in design, but also more opportunity for creativity - not for it's own sake, but to build better quality interfaces.

[ConvertFromOldNGs]

by James Plank Icon Communications >> Tue, 14 Mar 2000 23:21:30 GMT

Has anyone actually looked at the consumer home owners software these days. Its great! Very firendly and intuitive, and makes my kids want to use it. Guess what ! my clients love it too, because its less confusing because someone has spent a lot of time over make it friendly.
Your right no blue title bars, grey backgrounds and black anything, and whats more its fun to use.

More and more interfaces are designer by graphic designers not programmers (ie Juice) this is a good thing.

[ConvertFromOldNGs]

by Carl Ranson >> Wed, 15 Mar 2000 2:53:00 GMT

If Juice is, as it appears to be, an after the fact alteration of an application, it can hardly be considered design. At best its make-up.

I think the problem needs to be looked at as two different jobs

One job is user interface design, and the other is program design & development.

There is a general assumption in our industry that these jobs are the same and can both be done by developers. They're not, and cant. They involve quite different skillsets and goals, and its quite common for the goals to be opposed. eg whats easy for the developer is not good from the users point of view

Lets take an example from our favorite software, Jade. When I delete a property I can get multiple confirmations from Jade for instance.
From a user design view, Jade should establish the consequences of deleting a property and inform me once (if at all - many would argue that it should just do it and have an adequate undo feature).
It was obviously easier for the developer to have multiple warnings for references, inverses and general confirmation even though this is quite unacceptable interface design. Since there was no interface designer, this is what we got.

For products like Jade that are marketed as "world-class", the lack of interface design is painfully obvious. It doesn't happen by accident and even the best developers will fall on the side that is easiest for them a lot of the time.

CR

If the real world were built by developers ....

Man walks into a bar.
<man> I'ld like a beer
<bartender> Its made of barley you know?
<man> Still want one
<bartender> It contains alcohol, are you sure?
<man> YES!
<bartender> So, you want a beer then?
<man> (SLAP)

[ConvertFromOldNGs]

by Robert Barr >> Wed, 22 Mar 2000 1:20:10 GMT

<snip>

If the real world were built by developers ....

Man walks into a bar.
<man> I'ld like a beer
<bartender> Its made of barley you know?
<man> Still want one
<bartender> It contains alcohol, are you sure?
<man> YES!
<bartender> So, you want a beer then?
<man> (SLAP)

Is this an area for another 'personal preference'? I like being protected by confirmation dialogs (though not neccessarily against the dangers of drinking beer!). JADE confirmation dialogs appear to fall
into two categories:

a) where there's a danger of permanently loosing work (e.g. delete
xxx) , or
b) on actions where the developer's instructions could be ambiguous (e.g. overrides)



An interesting - and most probably completely irrelevant - parallel:
The bartender does - or at least should - issue the equivalent of a confirmation dialog if the customer is suspected to be under-age. There are also lots of implicit warings about drinking and driving - you don't need to press continue to acknowledge the warning, but they are very in-your-face - and you can't plead ignorance of the law if you don't see them. Is there an equivalent GUI convention to these signs, apart from modal confirmation dialogs which demand you press a button?

[ConvertFromOldNGs]

by Carl Ranson >> Wed, 22 Mar 2000 3:01:38 GMT

<snip>

If the real world were built by developers ....

Man walks into a bar.
<man> I'ld like a beer
<bartender> Its made of barley you know?
<man> Still want one
<bartender> It contains alcohol, are you sure?
<man> YES!
<bartender> So, you want a beer then?
<man> (SLAP)

Is this an area for another 'personal preference'? I like being protected by confirmation dialogs (though not neccessarily against the dangers of drinking beer!). JADE confirmation dialogs appear to fall
into two categories:

Absolutly not. From a purely interaction design viewpoint the confirmations are just an cop out for not having a workable undo function. This is so widespread that we don't even notice it anymore.
Think I'm wrong? Imagine Word without its undo. <user presses delete key after selecting the sentence> <word asks> "Are you sure you want to delete this? Y/N" etc - pure tourture

a) where there's a danger of permanently loosing work (e.g. delete xxx) , or

Jade should trust me to do my job but still allow me to recover where I have, er, changed my mind. The software should accommodate the human, not the reverse.

b) on actions where the developer's instructions could be ambiguous (e.g. overrides)

Jade should provide more feedback to remove the ambiguity. It would be easy for jade to check the name as I type it and indicate visually that the method already has an implementation. I would guess 90% of the time I am overriding on purpose, rather than by accident.

Jade could also maintain a comment line for the method that says
// overrides <classname>.<methodname>

An interesting - and most probably completely irrelevant - parallel: The bartender does - or at least should - issue the equivalent of a confirmation dialog if the customer is suspected to be under-age. There are also lots of implicit warings about drinking and driving - you don't need to press continue to acknowledge the warning, but they are very in-your-face - and you can't plead ignorance of the law if you don't see them. Is there an equivalent GUI convention to these signs, apart from modal confirmation dialogs which demand you press a button?

I think the feedback I suggest above goes some of the way towards this.

The "Starfire project" proposed a solution where the computer knew when the warning had been read (because it could track the users eye movements) and could automatically remove the message.

The real point here is that overriding a method is not usually an error condition. Forcing a confirmation for those cases where it could be wrong lets the product off the hook by burdening the user with a frustrating interruption.

Regards,
CR

[ConvertFromOldNGs]

by Robert Barr >> Wed, 22 Mar 2000 6:21:35 GMT

Yup ... on the confirm/no-going-back cases, a comprehensive and reliable-in-all-situations UNDO would remove the necessity for these time-consuming dialogs entirely (though I suspect more time is consumed on these newsgroups than on confirming deletes). Surely UNDO in the development environment is easy to implement (as it's written in JADE, which supports rollback)? Simply a case of mapping ctrl-z keys to an existing function, I'd hazard ...

I just can't spend as much of my day overriding methods as you. I'll
save my fingertips on this one ... just suffice to say I appreciate the warning JADE gives me. Shame my PC doesn't have an eye-ball reader yet. Or osmosis. But I'm working on opening up my mind ...

[ConvertFromOldNGs]

by Robert Barr >> Thu, 23 Mar 2000 2:09:35 GMT

... Surely UNDO in the
development environment is easy to implement (as it's written in JADE, which supports rollback)? Simply a case of mapping ctrl-z keys to an existing function, I'd hazard ...

I should qualify this tongue-in-cheek claim (especially in light of a recent lengthy discussion with Dean on compounded reorgs). I have in
mind a simple undo function that operates between (not across) reorgs (now that *would* be clever).

I sometimes find my design is flawed after building class aggregation
and inheritance structures, and I need to tear them down again - then
the 'confirm delete' messages are a pain. Craig's class vapouriser is probably more appropriate during this modelling phase than a sequential undo. Also helpful when further generalisation is needed, would be an 'insert class' function to save on class add/deletes.

[ConvertFromOldNGs]

by John Porter >> Wed, 15 Mar 2000 1:14:44 GMT

...... Would you want all the different applications you use every day to all have a different color schemes, be covered with logos, have different styles of buttons and controls, and all work in different ways?

Yes I would.

I look at so many unwanted blue title bars, grey backgrounds and black borders every day that I have to concentrate that bit harder to find the information I want amongst all the clutter. A visually simple, or stimulating design helps my eye find it's target.

I sure wouldn't! I get used to blue being title bars, grey being background etc, and it makes it that much easier to see what's going on. If some title bars were different colors, or had the menus set up differently, it just makes that much more visual and mental clutter it would be hard to find my way around. In fact, I delayed for years upgrading from Word 6 to Word 95 because the Word 95 title bar wasn't the same as the others! Having this sort of commonality means that once I learn to run one program, I have learned to run them all. If they were all different, I would have to learn each one. While some may enjoy that process and find the variety "fun", I would much rather just get the job done with a minimum of fuss.

[ConvertFromOldNGs]

by Robert Barr >> Tue, 21 Mar 2000 22:28:55 GMT

I sure wouldn't! I get used to blue being title bars, grey being background etc, and it makes it that much easier to see what's going on. If some title bars were different colors, or had the menus set up differently, it just makes that much more visual and mental clutter it would be hard to find my way around. In fact, I delayed for years upgrading from Word 6 to Word 95 because the Word 95 title bar wasn't the same as the others! Having this sort of commonality means that once I learn to run one program, I have learned to run them all. If they were all different, I would have to learn each one. While some may enjoy that process and find the variety "fun", I would much rather just get the job done with a minimum of fuss.

Photoshop also has a blue title bar - doesn't mean that Word users know how to drive it!

Take as another example a simple business software package such as a JUICE'd console-style book-keeping package, with no title bar or menus. Any end user who can read can use the software without being scared off by arcane clutter. The title bar isn't needed to recognise the software because it's visual *branding* is so strong that it's *instantly* recognisable. Context-sensitive functions are in the user's face when they need them, rather than being buried in layers of (conventional)
menu heirarchy. In your words John, it helps the user "get the job done with a minimum of fuss". The accountancy firm doesn't need to advertise for 'PC literate' staff.


Title-bar is a minor, but typical example - the important design issue
is prudence, or *context suitability*. I've seen applications with File and Edit menus where they just don't make sense, but everyone else has them, so we have to put them on our menu!? Take menus a step further - they expose every function available all the time. Though some may be disabled (grey) when unavailable, they're mostly still in your face, adding unnecessary context-insensitive clutter. For example, if I can't do anything until I've added a first account, then all I want is an 'Add Account' menu or button, and I don't want to search every menu to find it. Every other function is just clutter until they are in context.

Also relevant is that different types of software require quite
different UI design approaches. Generalised tools like Word and Excel
are designed to provide great flexibility for many users and situations. However custom business software is usually designed to perform very concise and non-generalised tasks - this is workflow-optimised software that guides a user through their business process use-cases in as streamlined and uninterrupted a manner as possible. Of course this is a simplificiation (or we would have a lot more wizards), and ad-hoc flexibility is often required as business processes are usually complex and non-linear. This is where the real skill of the designer comes in,
to balance workflow optimisation and flexibility.

JUICE is just another tool to be used with prudence, as are the many other established GUI paradigms and conventions, and Gregory is correct in saying that some interface artefacts aren't ready to be replaced. indeed, many are excellent. But one day, cars will have joysticks . Which manufacturer will jump first? There are sheep and pioneers on the software business too. Quicktime may not be a business success, but it will be a reference in our industry for years to come.

[ConvertFromOldNGs]

by John Porter >> Fri, 24 Mar 2000 6:07:55 GMT

Photoshop also has a blue title bar - doesn't mean that Word users know how to drive it!

If it has a standard Windows title bar, they know how to use the title bar! If it doesn't, they may not know how to drag it around or maximisise it.

Take as another example a simple business software package such as a JUICE'd console-style book-keeping package, with no title bar or menus. Any end user who can read can use the software without being scared off by arcane clutter. The title bar isn't needed to recognise the software because it's visual *branding* is so strong that it's *instantly*

The title bar isn't just for recognising the software - it also indicates whether the window has focus, allow maximising, etc. One example is PC Anywhere. Every time I use it and the usercode/domain dialog comes up, it doesn't have a title bar, so I think "uh-oh, the dialog box doesn't have focus". Then I remember that this is PC Anywhere, and that's normal. If they simply put a normal title bar on it, that distraction would be avoided.

Take menus a step further -
they expose every function available all the time. Though some may be disabled (grey) when unavailable, they're mostly still in your face, adding unnecessary context-insensitive clutter. For example, if I can't do anything until I've added a first account, then all I want is an 'Add Account' menu or button, and I don't want to search every menu to find it. Every other function is just clutter until they are in context.

One thing I find greatly annoying about Windows Explorer is that it does just that - removes items from menus when they are not useable at that instant. It makes it impossible to tell what all _can_ be done. If the items are there but ghosted, I can tell that the program has the function, but I haven't fulfilled the prerequisites yet, like actually clicking on a file name rather than having the ghosted selection box around it.