Proper interface design and the database abstract rant

dt01pqt

Certified
Local time
Today, 20:28
Joined
Mar 22, 2004
Messages
271
Is it just me or are lots of people are relying too much on wizards and not considering the best design for the user interface? Access has great capability for interface design. I blame those bloody 'made simple' guides for not emphasising the importance of good design. Also many don't understand the abstract of databasing. A lot of people think a database record collection is like a spreadsheet table. Record collections don't in theory have to be in table form at all. The most important thing is how well data is stored and recalled. The problem with practical people (bless them) is they are totally stumped when what they fathom goes from what they can realise or visualise in front of them to something more abstract. As far as interface design goes these are my top pet hates.

  1. Continuous forms
    Why? One page one record simple. If your interface looks like a db table then it's pointless. Interfaces are supposed to make easy to enter, find and most importantly view that data. The only time I would consider using continuous form is on things like project time sheets but then again I think I would use an ActiveX control like a table (in the spreadsheet sense). With a dropdown for a the week # displaying the ‘table’ for that week with rows for projects and columns for the days of the week. Meaning one page equals one week of work. But in order to get an accurate week you need to ask them how many hours they spent on each project during the week and make it simple by allowing them to do it in one go rather than having to enter each project hours individually to the correct week and day. The code behind this however is not simple. Continious are reports fine.
  2. Over use of subforms
    Use subforms sparingly. If you are using subforms to save space on a fixed height form consider a different solution such tab controls.
  3. Poor validation and crap data
    Always validate data at the earliest and most stable point i.e on the table itself if at all possible. Controlling validation at interface level is much more difficult and is considered 'house keeping'. If you find yourself trying to code your way out of bad data then consider starting from scratch.
  4. Poor control choice
    Speaks for itself
  5. Shit data entry
    Make sure you make that critical distinction between data entry and data viewing if you don’t the lines will be blurred and most likely your user will look for the easiest way to enter data.

That’s my rant over! :) :p :)
 
Last edited:
dt01pqt said:
Is it just me

Yes! :rolleyes:

How would you reconcile bank statements, monthly accounts etc. etc. without a continuous form?
You obviously don't have many one to many relationships either or unbound main forms with a combo box search in the header with the subsequent results displayed in an unbound subform, (continuous of course :eek: )
 
Yes there are times when continuous forms are appropriate true but the majority of times they are used inappropriately. Most of the time they look extremely messy and difficult to read especially if a wizard has been involved. I said that subforms should be used sparingly what you talk about is perfectly appropriate. Also the subform doesn't necessarily have to be in a continuous format it depends how many fields you are displaying if it is a lot it is better not to.
You obviously don't have many one to many relationships
Yes I do. :p

Do you not agree with the gist of what I'm saying in the rant? It is more about bad interface design and relying too heavily on wizards.
 
I wouldn't agree that the use of continuous forms is decided by the number of fields, it's more to do with the limitations of datasheets.

and I would have thought the advantage of Access is the Wizards, albeit with a little tweak here and there
 
Maybe the way to look at is.

Can you do without wizards ?.

If you would be totally stuffed without them then you are probably not making the best use of the facilities available.

Hmmm

Len B
 
I think that's about right maybe I was overreacting a little bit. I don't really use wizards very often only occasionally for controls. Obviously it is not the wizards themselves that are problem more a lazy haphazard approach to design and being too reliant on wizards and lack understanding of the code they generate. I suppose I've created 'wizards' before such as CAD automation.
 
Rich said:
I wouldn't agree that the use of continuous forms is decided by the number of fields, it's more to do with the limitations of datasheets.
It's not a question of 'decided' it's a question of good design. Lots of tightly packed fields, and narrow pages makes it difficult to read and often completely unnecessary. If you are going to use it like this than you might as well just use a table as the child. Idiot proofing is a large part of the effort and you want to create something that is straightforward and won't confuse the user in anyway or cause them to use the database incorrectly. A lot of this ties in with what I said about crap data.
 
I haven't used a wizard in two or three years. Bastards! :rolleyes:
 
Is it just me or are lots of people are relying too much on wizards....

It's you -- get some sleep. Sunday morning at 0630 is much to early to be that angry.

You're not perchance 'Mike375' with a new moniker, are you?

Bob
 
Ive got a couple of things to say

1. Client needs and wants
2. Speed of development

With regard to the first, some clients don't want tabbed forms and fancy searching buttons etc and are quite happy looking at 'datasheet'

With regard to the second, wizards do a geat job of saving a developer time and ultimately money.
 
Come on these wizards are not that great. How fast can you type? I am all for automation but these wizards hardly do anything to help me save time they are just the very basic functions and are poor on layout. You are better off creating your own automation if you want to save time.
 
raskew said:
It's you -- get some sleep. Sunday morning at 0630 is much to early to be that angry.

You're not perchance 'Mike375' with a new moniker, are you?

Bob
What? Since when did I get up at 0630 on a Sunday? More like 1330 :D I never heard Mike get angry why do you mention him? I am much more mardier than him. ;)
 
And lets not forget, with respect to some of the wizards, they are producing VBA that - since Access 95 - is defunct.
 
Mile-O-Phile said:
And lets not forget, with respect to some of the wizards, they are producing VBA that - since Access 95 - is defunct.
Good point you'd think they would follow their own advice. :rolleyes:
 
Mile-O-Phile said:
And lets not forget, with respect to some of the wizards, they are producing VBA that - since Access 95 - is defunct.
still works though :eek:
 
Rich said:
still works though :eek:

For purposes of backwards compatibility even thought there's no Convert to Access '95 option. :rolleyes:
 
You'd think they would spend more time updating the software rather than the help files. :rolleyes:
 

Users who are viewing this thread

Back
Top Bottom