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