Designing the Perfect User Interface (1 Viewer)

[Thales750]

Obviously perfection is impossible, and one size fits all doesn’t not work here either.

As monitors have increased in both size and resolution we (designers) have much more freedom to design. So a balance between what’s on the current screen and what’s on the next screen becomes more involved. With more choices, comes the need to choose.

What are your thoughts?

 

[David Eagar]

First Design the Perfect User !!!!!!

 

[The_Doc_Man]

David and Thales, I can't even define the perfect user, much less the perfect user interface. I'll say this: At work, I don't believe I have to worry about running across such a person. But then, I work with the U.S. Government.

I do recall one day at a former job, though, when we had been slogging through tons of code for several days, running overtime near to exhaustion, and finally were ready to test. Someone said, "Now we need to find someone to test this for us so we can make it foolproof." Someone else said, "We are all too familiar with it. We need to find some fool to test it; otherwise we can never make it foolproof." That was like throwing down the gauntlet, of course.

The next comment was "So let's advertise for a real fool to test foolproof programs." We hypothesized the wording of such an ad. I asked "What fool would apply for such a job?" My assistant asked the obvious follow-up, "What fool would hire such a person?" A few snide remarks flew about for candidate managers we thought would make such a job offer. By then we were laughing so hard that we had no choice but to break for lunch. Nobody was going to get anything done anyway.

The worst part of it is that a few months later we got in a resume' that pretty much qualified the person as a perfect fool. He wanted to change careers because he wasn't going anywhere. His degrees were in biochemistry and the pharmacology of psychoactive substances (Can you say... "Let's get small"?), plus a Master's degree in far eastern literary forms of medieval poetry. But I'll be kind and leave personalities out of it.

 

[Lightwave]

I think about this quite a lot.

I tend to concentrate on a system that is flexible enough to store the information but can allow the production of reports that are user targeted. So the legal section has its own report, the planning section there own report and for instance the accounting section their report.

In an administrative setting although the data is essentially live it drips in slowly. Slowly being manual input compared with live systems that collect their information from some sort of receiver.

In this situation I like simplicity above all. Specifically I have moved towards.

Using search lists that are not field specific. The list box may have half a dozen fields but when you type in the on change event selects the typed string to be searched in all of the fields within the list box. It works really nicely. I am really disappointed with the search facility in Windows / outlook / exporer (xp) for instance which I can never seem to use to find anything.

I also like continuous forms whereby you use the labels at the top to sort the records beneath. Left mouse button AZ right mouse button ZA. And make the sorts subjectively "sensible" Nearly all such sorts for instance will have 2 or three field sort order. For example no use doing a sort on a company and not secondly sorting by the town they are in or a sort on surname with having a secondary sort on the first name etc...

Of course normalization is a given and my design principles tend to be the next level up. The principles of particular subjects are also very useful. For instance double entry accounting and the books of prime entry. For example an accounting system without a sales ledger is totally useless irrespective of whether everything else is brillaintly normalised.

Other than that I concentrate on making it as stable as possible and allowing as many people as possible to view.

But getting users to really want the system just takes a long time.

They're just like me - they think they know best.

I also spend a bit of time trying to make any databases I design as "clean" as possible. Ie removing menus if they are not needed. Preventing shortcut menus on right click. Preventing navigation buttons if I can avoid it. Putting in caption descriptors throughout that kind of thing. And of course shutting and opening forms so that you don't accidentally corrupt fields by overwriting a field in an open form when the same information is being held on screen in the form beneath.

I should say that I have only designed things in A2003. I suspect the other versions will look better but from what I hear are in certain circumstances more awkward to manipulate.

I certainly think that given time you can do some really good stuff and I watch people at my work and wonder why they don't invest a bit of time learning how to design there own rather than taking hand me down systems from others that don't quite work for them.

It really seems to me amazing how many systems are now bespoke. Good if you can design them probably slightly worrying for the user as many off the shelf systems just don't seem to be able to cut it and requesting someone else to construct something for you is a real minefield.

Software design generally seems outrageously hit and miss and possibly why clients are so unwilling to undertake it despite the fact that they often really need it. I do think that the computer industry could be its own worst enemy in this regard. While microsoft are content to continually alter user interfaces dramatically and regularly the developers who design the systems adhere carefully to a somewhat fixed hardware/software architecture from which they create these new UIs - I'm particularly talking of SQL and C variants there isn't enough middle ground to give confidence in design and get super users up and running. I think continual change in procedures for things really frustrates users who then become suspicious of software companies that promise spectcular efficiency gains.

Do people that know better consider that last statement fair comment?

Ultimately there is a growing base of super users who are starting to bridge the gap between hard core programmers and users. I think to make databases truly ubiquitous you need to be encouraging as many as possible into this category. These people are the type of people that will be best placed to manage new system developments even if they are not talented enough to design their own.

 

[Galaxiom]

Good if you can design them probably slightly worrying for the user as many off the shelf systems just don't seem to be able to cut it and requesting someone else to construct something for you is a real minefield.

Many off the shelf systems are very clunky for many reasons.

It is rare for a person to be highly competent in the field they are designing the application for, systems analysis, programming and business management. Without all these aspects in the project leader at least, the design is generally compromised.

Without fully understanding the processes involved in the use of the software the user interface can often be very klunky.

Without sufficient systems analysis skills the underlying architecture often hits brick walls when trying to get features to the next level. This crucial aspect of the design is often underinvested in the attempt to get something running as early as possible. The client's impatience can often be the worst influence.

Without good programming skills and an understanding how structure the program with flexible, reusable functions, code bloat is inevitable. The maintenace and costs of adding new functionality quickly ballons.

The manager of the application writing company often is less competent in any of the other skills than most of the team but carries excessive sway in the design decisions. Often under time pressure they fail to fully understand the implications of the decision they make.

In other cases the manager comes from an application user who saw it could be done better. In frustration they did learn how to program a bit and either saw the opportunity to go into business. Often their original application reflected their limited early knowledge but can be very hard to get away from the implications of those early design decisions, particulary when trying to maintain backwards compatibility.

Software design generally seems outrageously hit and miss and possibly why clients are so unwilling to undertake it despite the fact that they often really need it.

Most clients have their hands full doing their main activity. Those most capable of visualizing the specification or even recognising the need are usually stretched to the limit. Often they spend a lot of time dealing with problems created by the fools they have to work with, both above and below.

Programming requires a different state of mind from many other tasks. The ability to hold the entire project in perspective while intently focussing on details is crucial and quite rare.

I think continual change in procedures for things really frustrates users who then become suspicious of software companies that promise spectcular efficiency gains.

In my experience most users simply want a procedure and have no interest at all in understanding the principles of what they are doing. I have worked with purchasing officers who don't even think they need to understand anything about accounting. The mistakes they make couold only be the product of complete ignorance.

Ultimately there is a growing base of super users who are starting to bridge the gap between hard core programmers and users. I think to make databases truly ubiquitous you need to be encouraging as many as possible into this category. These people are the type of people that will be best placed to manage new system developments even if they are not talented enough to design their own.

Unfortunately many geeks are not very good at interacting with the super users and translating the abstract notions they present into program structure. They often start thinking code instead of structure way too early.

A lot of geeks are also stuck in ruts they fell into early in their career and simply repeat same design inefficiencies that although don't cause immediate problems can limit the versatility of the application for future development.

 

[Steve R.]

I'm finding a lot of "white" space to be useful. My prior forms, to save space became too cramped.

I have the active data entry control highlighted. Keeps the person doing the data entry focused on what is to be entered.

Data entry should match the sequence of whatever is used as a data source, which I guess is really nothing new.

To minimize "bad" data, I try to put in a lot of error detection. However, I also find that this seems to add undue programming complexity. So there has to be a balance between catching really egregious errors and simple programing.

 

[gemma-the-husky]

The decision to go bespoke compared with package is tricky for end-users.

I think the two main reasons for going bespoke are:

a) better fit - there are some facilities that the users just can't compromise on. And re-enginerring a package to fit is often hideously complex, and very difficult. It becomes worthwhile using packages in less important areas (eg ledgers) and bespoke in key areas (order processing)

b) future development. Once they have a bespoke system, as long as it is properly designed, they can often have extras bolted on. It's a serendipity/synergy effect. The users start with simple requirements - but when they see what a well-designed app can do, sepecially with user acceptance, they start seeing other things they can do with it.

Which leads to
c) Once a company has found a designer they get on well with, they Are likely to find extra projects.


With regard to foolproof, I am not sure the DOCMan is correct. I think you can make stuff robust enough to yield a pretty good MTBF.

 

[Galaxiom]

I'm finding a lot of "white" space to be useful. My prior forms, to save space became too cramped.

I agree about whitespace. Often way too much is crammed onto forms. Developers need to remember that they see the form very differently from a user because they built it and are intimately familiar with its content. The user see an overwhelming pile of controls at least until they get familiar. One must also remember that many users have a much lower confusion threshold than the average developer.

Juxtaposed against this is the inconvenience of opening more forms to get to data that is related to the main form.

Often some of the data on these other forms is relavant to the user viewing another form. For example, certain information about a client is often useful shown on an Invoice form but it is obviously impractical to embed the whole ClientDetails as a subform.

So you end up designing a full ClientDetails form and a ClientMainDetails form which you insert as a subform on the Invoice form where you want to see these details.

There is another way using one form for both. I will use Invoice and ClientDetails as a familiar example but the are many places it can be applied. It suits may sense of aesthetics but you can be the judge for yours.

Place the main client details you want to show inside the Invoice form in a corner of the full ClientDetails form. Then on the Invoice form, set the ClientDetails form as the SourceObject of a subformcontrol that is too small to show the whole form, just the bits you want to see on the Invoice form. Turn off the scrollbars. It now looks like a little form with just the main details.

Include a button either on the main form or the subform to open a popup of the full ClientDetails form. If the button is on the ClientDetails form, manage its visibility such that it is not seen when the subform is displayed as the popup. Similarly set a button to close the popup form to only be seen in the full display. (Easily done by locating it in the obscured part.)
The Parent property of the subform can be used to detect the mode the ClientDetails form is opened in.

Now (in A2007 at least) when the ClientDetails subform is opened in popup mode it actually appears right where the subformcontrol was displaying part of it on the Invoice form. This is so intuitive because the layout and position of the part visible on the Invoice form does not change. It creates an illusion that the subformcontrol was simply enlarged.

The recordsource of the form can also be dynamic to avoid unnecessary data being retreived when in part mode. One tidy way to do this is to put the ExtraDetails in another subform which is displayed on the ClientDetails form.

Set the default SourceObject of the ExtraDetails subformcontrol on the ClientDetails subform as the NullString and as the ExtraDetails form when ClientDetails is opened as a popup.

Hope this makes sense and is worth the effort to understand what I am saying.