[AccessD] User interface

Agreed. I almost never use the build in buttons now and use big simple icons
(usually, ummm, borrowed from Google images).  Some of these I get creative
with not matter how out there I get, the users seem to love them and
understand them, I blame the whole iPad, Apple, app thing.  There is
definitely a fine line between being too simple and too complicated though.
Users expect things to work in a certain way and I try hard to emulate those
familiar functions of the browser or email etc.

I also tend only to show what the users need to know about and nothing more.
I do like the Apple approach of keeping the UI simple and clean, but it
depends on the requirements of the client. Some folks like a busy dashboard
too, with lots of data everywhere.  I often build both so they can toggle
between one view or the other, but i really depends on their needs.

Often I will start with a single button, and that will reveal more options
(depending on their user permissions and data etc).  Then reveal more
options as you go along.

I try to be consistent with images and colours throughout the app so the
user get a feel for how it all works. I do add in old school stuff like
double clicks as well for users who like that sort of thing (me for
example). So a user can pick from a list and press the "Use" icon, or they
can just double click the item in the list to select it.

I usually use unbound everything as it makes it simple to have two functions
once a record has been altered  "Save" and "Exit without Save".  Many users
do not understand that in a bound form the changes are saved instantly, they
seem to like to have the ability to exit and not keep the change if they
have made an error.  Unbound of course, let you do this easily.  Bound it
can be done, but it is a bit more stuffing around to make it happen.

Just my 2 cents.
Cheers
Darryl



-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Robin Lawrence
Sent: Sunday, 28 August 2011 10:28 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] User interface

Hi all,
As I've always been a part time Access developer so I don't often contribute

to the list, but I'm always lurking.

I've written a ticketing application for a theatre run completely by 
volunteers with many retired people and non computer users amongst them.

I designed the application as a 'wizard' by using tabbed pages with hidden 
tabs in a subform, using large green left arrow/ right arrow icons to move 
forward or back (previous tab / next tab) as necessary.

Validation is carried out as the icon image is clicked, and appropriate 
messages displayed to persuade the users to do the required.

Seems to work well and I've converted many of those users who said 'Oh I 
can't use a computer!'
But that was as much to do with training and talking to them as the 
interface......

Regards
Robin Lawrence
training
----- Original Message ----- 
From: "Arthur Fuller" <fuller.artful at gmail.com>
To: "Access Developers discussion and problem solving" 
<accessd at databaseadvisors.com>
Sent: Sunday, August 28, 2011 12:36 AM
Subject: Re: [AccessD] User interface


> You and I differ on this point significantly, but that's ok with me.
>
> My take is that the user should be able to view any number of forms at any
> given moment. Granted, some forms will open in Dialog mode, but that
> exception aside, I see nothing inherently wrong with having, say, the
> Customers form and the Orders form open simultaneously. Yes, I have to add

> a
> bit of code to synch them (i.e. choose another Customer and the Orders 
> form
> automagically goes to that Customer's most recent Order)
>
> This is not about arguing that my strategy is better. This whole thread is
> about learning how other developers approach the UI problem, so anything
> said by me or anyone else participating in this fruitful thread should 
> bear
> that in mind.
>
> I think it was Gustav, but it may have been Colby, who submitted a class
> that deals with the "focus" issue; with a couple of declarations, any 
> given
> form is handled automagically. In the given sample code, the control with
> focus was turned Cyan. IIRC, there was a problem with coloring combo-boxes
> and list-boxes, but for all other controls it worked beautifully. I didn't
> use that code in my most recent app, so I'd have to back-track and dig it
> up, but it was very slick.
>
> One other question I'd like to add to this thread: does anyone make use of
> the Wizard concept? There are several ways to build Wizards, but I wonder
> whether anyone has bothered to build them into an app. I am trying to do 
> so
> in my current client's app, the idea being that when you create a new
> Customer, you must also create at least one Customer_Locations and after
> that, at least one Customer_Location_Project -- this all to be done within
> the wizard; Then the backdrop, as it were, has been set, and thereafter 
> all
> the combo-boxes can be populated with meaningful data. The FE also allows
> additions to the various combo-boxes, but ideally the wizard pre-empts the
> necessity to do so.
>
> A.
> -- 
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com