Discussion: philosophy of UI design

[psemianonymous]

I've become dissatisfied with the UIs I create. Specifically, I'm talking about how my entire application works.

This is how I've done it (for the last application I wrote):

-Default menus and toolbars, no additions (that's right, INCLUDING the tantalizing-but-disabled 'design' button)

-Default report toolbars. All the help I give is how to use the Access features (like if they ask "how do I print more than one copy?" I say "Go to File->Print and mess with the dialog")

-Switchboard-style menus, if not actually using the switchboard add-in. I hate the switchboard, but I can't think of a better menu system, so the style stays.

-Data entry forms are also the editing forms are also the place where you delete records (record deletion is strongly discouraged in the help docs). Entirely bound forms on data entry, because we're dealing with a relatively small data source. Always have the record selectors and record navigation buttons enabled. Allow filtering, allow sorting, allow whatever the users are willing to try.

-Most data entry forms (at least, where applicable) can be opened to the entire data set, a (relatively) large size. So I include a "find record" combobox at the top of each form that lets them navigate to any record in the set. My theory: it's easier to search using a combobox than using Access' 'Find and Replace' dialog. It turns out that I didn't use the 'continuous form' option at all this time, something I think I should have, somewhere.

-Subforms are used for some of those 1:M relationships, using a subform control and a record navigation button for the subform control.


-A generalized search form (which I am proud of, but which is HUGE) that acts like a wizard. This can be set to open a form to a subset of the data (think "[ID] = 2", or think "[DATE_FIELD] BETWEEN #1/1/2000# AND #12/31/2000#"). It can also be used to open a report in a similar fashion. One or more criteria may be used to construct these where clauses.

-Mostly in-Access reports, but also uses some mailmerge documents (faq181-5088). Never directly prints the report. Always opens the report in print preview.



Things I didn't use at all:
-listboxes
-built-in help
-treeviews (always wanted to mess with these)
-a single ActiveX control
-unbound form data entry
-context menus (right-click)
-custom toolbars/menus


I'm dissatisfied because the interface is ugly. I originally was working hard to make it maintainable (which it is, brilliantly so). Now I wish I had worked a little harder on making it more like a real application. Anyone else have these sort of issues? Do you try and hide every scrap of Access, or do you just let it all hang out (like I did?) Do you mess with fancy controls, dependent listboxes, or elegant data validation UI (I use messageboxes)?

It's not a problem of understanding how to do something; it's a problem of knowing which to do.


Pete

 

[sillysod]

In my latest effort ive decided against switchboards

I have made a splash screen, which shows a logo and a few other tit bits, namely the current users windows logon (this is used to stamp records with a creator and replaces the need to "log on" to the database.
Any restrictions to forms etc are based on the windows logon, although i could easily add an "override" feature)

The current client version, my database runs a check with a "master client" and if the database version differs then the user is locked out and asked to run the client update programme, which is an exe file which just copies the latest client from server.

I have used a custom tool bar as the navigation, this allows users to go anywhere from anywhere. Which i see as a big bonus.

All access features are hidden.

I tend to try and make things user friendly and pretty first then worry about the technicalities.

List boxes i sometimes use, but often they need to take up alot of space on a form, especially when most users res is 1024*7xx

never really bothered with right click menus myself, not found a use for them yet

maybe they'd be good for right clicking on date fields and getting predefined options such as today / tomorrow / next week / next month

what are the benefits / cons to unbound form data entry?

I have also found that if you change the font to something a little more easy-on-the eye and change the background colours from grey to a less boring colour (light blue for example) it can help alot.

I also try to avoid having buttons with names on them as i think this is a little ugly, instead a standardised set of XP style icons is used across the app and tooltips to give a further explanation.
eg for anything to do with view on the toolbar i use the "eye" icon or the "glasses" icon , deleting is always a "trash Can" icon

something else i do not do is allow users to delete records.
I just let them think they have...
Records have a "delete" field if = true then this fieldis excluded from everything never to be seen again - but theres always a backdoor so that deleted records can be recovered.

regards,
sillysod

 

[Lightning]

I'm dissatisfied because the interface is ugly. I originally was working hard to make it maintainable (which it is, brilliantly so). Now I wish I had worked a little harder on making it more like a real application. Anyone else have these sort of issues? Do you try and hide every scrap of Access, or do you just let it all hang out (like I did?)

The correct answer to this is, of course, "There is no single correct answer to this."

It depends entirely on what the client wants the app to do, and what the client wants to do with the app.

If your client wants a specific-use application where every task is defined and security is a high requirement, then you lock everything down so the users can only do what the UI lets them do.

At the other end of the spectrum, if the client only knows what they require the app to do now, but not where it is likely to develop in the future, then a locked-down app is not going to help them to develop its usefulness over time.

Do you mess with fancy controls, dependent listboxes, or elegant data validation UI (I use messageboxes)?

I tend not to use ActiveX controls in my projects usually because there is no guarantee that the client will have access to these controls on all PCs that have to run the app. (I've never been involved with having to package and deploy an app - that's always been an issue for the client's tech support area - so I try to stay within the bounds of a straight Access app, using automation to the other Office applications as required.) I guess my approach has always been the K.I.S. style, bearing in mind Murphy's Law. If you don't need it for functionality, why add it?

As far as looks go, I've found that beauty is definitely in the eye of the beholder. One user will love the UI while the next one will hate the colours. Another will dislike the uncluttered forms because "you could squeeze so much more onto the screen if there was no white space.". In general, if you follow the client's corporate colours and don't try to squeeze too much onto one screen, the users will be, if not happy, at least not too unhappy.

Just my opinion, for what it's worth.

HTH
Lightning

 

[MichaelRed]

I tend toward the functionality above all else, so stick to the basic (built in) controls and menus.

I consider functionality to include a level of V&V suitable to the (target) end user. In many (most?) apps, there is some range of this, but typically the lowest common denominator works for all except a few. Message boxes and input boxes tend to domimate the actual code.

While I usually allow the deletion of records, I advise the client of the pitfalls and try to have them include archiving the deletions. For sensitive apps, I also attempt to have them include an audit trail (faq181-291 or something similar).

A "Look and Feel" is important to some and totally un-necessary for others. I have had clients who laid out every control on ever form and report as well as dictating color schemes and a "required progression" through individual controls (yuou can't enter this until that is entered and verified) and coloe codes for the various states od a control (Lt Blue for controls which were always locked, dark blue for ones which were currently locked, but would become unlocked when something occured, Green for where the focus (unless it was Locked, in which case ...) I sometimes wondered if the app was just an entry level test for hiring ... if so, I must have failed!

So, the answere is presented by Lighting above. Discuss the CLIENT's wants and needs WITH THE CLIENT, with some emphasis on the DISCUSS part. If you can, have a 'portfolio of screen shots with different looks and go over the advantages and Costs of each with the client. Same with features. Some are pratically free (e.g. my versioin of the Audit trail) in theit actual implementation, but have ancilliary requirements (SECURITY) which can complicate the use of the app and a 'cost' in maintenance which is recurring (Somone nees to move the archives to secure storage on an regular basis).




MichaelRed
mlred@verizon.net

 

[cgarts]

Hmmm... maybe it's presumptious for someone still learning Access to toss out UI design preferences to a forum with lots of seasoned pros, but I have a really good UI concept, and I use it pretty much everywhere..

It's driven by several ideas.
1. Visual simplicity wherever possible.
2. Show very few controls to the user at any moment.
3. And only those controls needed at the moment.
4. Use a familiar "driver's seat": virtually all my forms have some hint of the "look and feel" of a web page: control buttons on the left, and data on the right.

That all said, basically everything user visible on the form is on two tab controls:

A Tab Control with just navigation and control buttons is on the left approximate third of the form.

A Tab Control with context appropriate tab pages for data entry and/or display is on the right two thirds.

Only the controls and commands for, say, a new record will be available to the user when a new record is being created.

The left and right hand sides are always kept in sync programmatically.

What's visible at a given time on either side is based what page has the focus on those tab controls. The tabs themselves are removed by setting the Format> Style property to "None" to drive actions and navagation solely programmatically..

All navigation within the form, and from record to record is programmatic and is is run off toggle buttons in option group's on the left side. After Update events with select case statements do the driving.

Tab pages shown on either or both sides of the form may change with user navigation.
Select Case OptNav
Case 1
APgNav.SetFocus
BPgNav.SetFocus
Case 2
APgNew.setfocus
BPgNew.setfocus...

(To keep me sane navigation Tab Controls and their pages on the left are A named: AThis and AThat, and Tab controls and their TabPages on the right side start with B.)

This way I swap commands on the left - and I swap data entry/visiblility items on the right to show only relevant items.

It's a lot more work presenting things simply, but after a little time it becomes second nature. The first time you set up a form like I am describing I can almost guarantee you a headache, but then after you do a few more, ordinary forms will feel nasty and unfriendly.

Best,

C