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