Darryl Collins
darryl at whittleconsulting.com.au
Mon Aug 29 18:50:12 CDT 2011
Yeah, that is good advice, How often is it the last though... I was lucky in my last role as my boss was very big on the UI looking and working beautifully and he really understood the value in getting it right. Lead to some entertaining meeting with the other developer though as he didn't worry too much about the look and feel and felt it was a waste of time ;) Too often the UI is just tacked on top of the geeky stuff, and frankly the end users don't care about the nuts and bolts under the hood, or the limitations of data and software. I guess it is a bit like many of us don't care about how our cars work etc, so long as they look good and perform in a predictable manner we are ok. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Stuart McLachlan Sent: Tuesday, 30 August 2011 9:29 AM To: Access Developers discussion and problem solving Subject: Re: [AccessD] User Interface The key is close interaction with users during the development phase. Get as many users as possible trialling the interface as early as possible and keep modifying it based on their comments. Generally the UI should be the first component that you start and the last one that you finish. -- Stuart On 30 Aug 2011 at 9:11, Darryl Collins wrote: > 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