[AccessD] User Interface

Dan Waters df.waters at comcast.net
Fri Sep 2 14:24:04 CDT 2011


Yes - they know they're right.  It's my job to ask enough questions to
discover what they really need, and then later show them that they were
right!  ;-)

Dan

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
Sent: Friday, September 02, 2011 2:23 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] User Interface

Users rule. They are always right even when they are wrong. ;-)

Jim


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darryl Collins
Sent: Monday, August 29, 2011 4:12 PM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] User Interface

Yes, absolutely!  In fact I get annoyed with fellow developers who think
user feedback and concerns are a pain. To me their feedback is usually pure
gold.  Keep them happy and content and you'll keep your job for a long time.
I am a big fan of not letting option be available until they are ready to
work flawlessly.  Why on earth show them an active print button if it is
going to fail on print because they are missing some information.

For really unskilled users I normally have even made up little tick lists
that show where they are in the process and what else they need to complete
to finish the task.

Yes, it takes a lot more time to put this sort of thing together but it pays
very big dividends, especially when you have hundreds of users all over the
country and there is no way you can give them all your personal assistance.

Cheers
Darryl. 


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: Tuesday, 30 August 2011 1:27 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] User Interface

Here here for the "No False Moves" strategy. The most important thing, IMO,
is to make the user feel both powerful and elegant: nothing that should not
happen should be permitted to happen. I know from experience that this is a
PITA to deliver, but it inevitably is correct: foreclose the options that
should not be available in the given context. A silly example, but I hope
meaningful -- unless a given OrderID has been selected, then dis-allow the
printing of an Invoice.

The point here is ultimately, "Make the user feel graceful"; not merely
competent, although that is Step One, but Graceful (that is Step Two). I
have followed this strategy for about 20 years and it invariably has worked
in my favour. In fact, I have learned some things from the users of my apps
which I didn't even consider, because I don't actually use my deliverables,
but just test them and then deploy them; the people who use them use them
frequently, and are quicker than I to detect annoyances. I do listen to
them, and I try to deliver smoother avenues on next deployment.

I'm not claiming any expertise in this area. My rule of thumb is, Shut Up
and Listen. I don't often run the systems I deliver, especially all day
long; so I trust my customer-base to tell me what is a PITA and what is
nice; then I go back to the drawing board and try to design the PITA out.
Sometimes this strategy doesn't work, but most of the time it does. Users
Rule; it's not about Referential Integrity or Validation Rules etc., it's
about the user-experience, and about getting from Here to There in the
fewest possible clicks and keystrokes. That's my design goal, anyway. I
don't want the user (God, I hate that word, it reminds me of drug-dealers!)
to have the simplest possible path toward creating a new Customer with its
ancillary tables, or to update an existing Customer and her Locations, and
her Location_Projects.

I want all the background stuff to be invisible to the current Customer.
This should all happen under smoke-and-mirrors, and then once the scaffold
has been laid, everything else should happen automagically

On Mon, Aug 29, 2011 at 9:18 AM, William Benson (VBACreations.Com) <
vbacreations at gmail.com> wrote:

> I think you all write applications for many more users than I do. I 
> have not written anything for more than about 3 users at a time and 
> basically they are easily trained. The most important things have been 
> to get work done
in
> the fewest number of steps. And no "false moves". On one app I built
lately
> there are several buttons down the right hand side of each of the main 
> forms. I can put anything I want in their captions then handle all 
> button clicks through a test of screen.activeform.name, 
> screen.activeform.ActiveControl.Name. I ALWAYS use captions, never 
> images, for just that reason.
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darryl 
> Collins
> Sent: Sunday, August 28, 2011 7:46 PM
> To: 'Access Developers discussion and problem solving'
> Subject: Re: [AccessD] User Interface
>
> Hah, that is pretty much what I wanted to say, but as usual, waffled 
> off topic a fair bit...
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Tony Septav
> Sent: Monday, 29 August 2011 12:36 AM
> To: 'Access Developers discussion and problem solving'
> Subject: [AccessD] User Interface
>
> Hey John
> In designing a user interface I always try to keep it clean, simple 
> and intuitive. Always keeping in mind that you are 
> programming/designing not for the 99.9% but the .1% of the users ( a 
> friend of mine used to laugh at
this
> "You spent a lot of time trying to solve the .1% problem", that was 
> until he worked with me on a project).
>
> I am always trying to keep in mind when designing, the lowest common 
> denominator ,my theoretical "computer illiterate user". Meaning I 
> control what a user can and cannot do. I am always trying to second 
> guess the user and trying to shut any backdoors they may sneak into and
open.
>
> I like to use single simple forms/single tab forms There is no HELP 
> (the form should visually flow/display to the user what and how things 
> need to be done) There are no menus.
> The information intuitively flows from top to bottom Where applicable 
> some information may be highlighted in coloured boxes. I use colour 
> sparingly as it can tend to make the form look goofy or too busy.
> The forms contain all the things, buttons, my navigation bars (when 
> needed), list boxes, pop ups, etc. necessary to let the user carry out 
> the activities the form is designed to perform.
> Where necesary the form may contain my own (not Access) message boxes 
> intrusive - ".....Sorry cannot do that..." and nonintrusive - ".... 
> Are
you
> sure? Continue Y/N?"
>
> As most of you have probably done, I will design  what I thought was a 
> pretty cool form, but a week later when I go back to continue my 
> testing, the form just doesn't seem to flow the way it should (not 
> intuitive). So I tear apart and rebuild it and start again.
>
> Nothing new here, just my 2 cents worth.
>
>
>
>
>
>
> --
> 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
>
> --
> 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

--
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





More information about the AccessD mailing list