What makes good design? (1 Viewer)

isladogs

MVP / VIP
Local time
Today, 23:17
Joined
Jan 14, 2017
Messages
18,186
Talking of design, Daniel Pineault (owner of the excellent DevHut website) has the following two quotes as part of his UA signature:

 

Attachments

  • Capture.PNG
    Capture.PNG
    4.8 KB · Views: 529

NauticalGent

Ignore List Poster Boy
Local time
Today, 19:17
Joined
Apr 27, 2015
Messages
6,286
Re: Employee System Example V4 Info

Talking of design, Daniel Pineault (owner of the excellent DevHut website) has the following two quotes as part of his UA signature:

Not bad...!
 

NauticalGent

Ignore List Poster Boy
Local time
Today, 19:17
Joined
Apr 27, 2015
Messages
6,286
Re: Employee System Example V4 Info

I would say first and foremost, soft colors and logical flow of information. In that vein, numbering the tab-stops correctly
 
Last edited by a moderator:

Pat Hartman

Super Moderator
Staff member
Local time
Today, 19:17
Joined
Feb 19, 2002
Messages
42,977
--The forms/reports should be logically designed so that the required or most important data comes first.
--Forms should never have to scroll except when they contain a subform. The rows of a subform may scroll but the entire subform should always be visible. This can sometimes be a challenge if your users have a multitude of different display devices.
--Colors should be quiet and used more for information than for artistic value. For example, highlighting negative values with red text. Be aware of whether reports will be printed on color or black and white printers and highlight accordingly.
--The functioning of the application should be obvious to anyone familiar with the subject matter. Training might be required to take advantage of shortcuts but basic functionality should be easily discoverable. It should use the terms the people use. If the users call the customer a client, then the application forms/reports should call that person a client.
--The application should protect the user from making typos whenever possible. A good example is date entry. Someone trying to enter 2/4/2019, might easily type 2/4/201 or 2/4/219. Both dates are valid as far as Access is concerned but your app should never allow them unless you are actually entering dates for 1700 years in the past. Birth dates should never be in the future. Employees should be between 18 and 75 years old. Ages outside the range should cause a question to be asked to verify and even then the range should surely be no more than 16-100.
--Combos should be used whenever possible to limit choices for things like department or state.
--Don't let presentation (reports) convince you to make bad table design choices. It may seem easier at first to have a forecasting table contain 12 months for each row but don't do it. Or a timesheet have 7 or 14 or 31 days per row. Don't do it. Or a timesheet have separate columns for regular, overtime, vacation, PTO, etc. Don't do it.
 

deletedT

Guest
Local time
Today, 23:17
Joined
Feb 2, 2019
Messages
1,218
For me good design is only Being Easy to Use
If it's not going to make my job easier, developing an app means nothing.
 

Dreamweaver

Well-known member
Local time
Today, 23:17
Joined
Nov 28, 2005
Messages
2,466

Attachments

  • 2019-08-20 (2).png
    2019-08-20 (2).png
    56.7 KB · Views: 519
  • 2019-08-20 (4).png
    2019-08-20 (4).png
    45.7 KB · Views: 508
Last edited:

isladogs

MVP / VIP
Local time
Today, 23:17
Joined
Jan 14, 2017
Messages
18,186
Hi Mick
Were you asking for our views on each?
In some ways I prefer the original. Partly because I find strong colours like the bright blue quite distracting.

Anyway my main reason for replying is to check whether those screenshots are for real data? Phone numbers, address and emails for yourself and jolycrumpets (Great name!) If so, suggest you amend the images to remove or redact.
 

Dreamweaver

Well-known member
Local time
Today, 23:17
Joined
Nov 28, 2005
Messages
2,466
Hi Mick
Were you asking for our views on each?
In some ways I prefer the original. Partly because I find strong colours like the bright blue quite distracting.

Anyway my main reason for replying is to check whether those screenshots are for real data? Phone numbers, address and emails for yourself and jolycrumpets (Great name!) If so, suggest you amend the images to remove or redact.


No Just found the old program And no the data is all made up but have updated the first as the number and email was dead numbers but changed them just in case thanks.


I have been thinking about maybe putting an option into my preferences so you can change the colours maybe I'll try in on the example as it's simple to do.


thanks mick
 
Last edited:

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 18:17
Joined
Feb 28, 2001
Messages
27,001
My take on form design when contracting with the US Navy was accepted by many (which means that they didn't come after me with torches and pitchforks...)

Up front, I analyzed enough to realize that a LOT of the forms were going to be used for various kinds of maintenance of data, though not everyone would do so. But multiple forms WERE going to be involved. Therefore, I came up with a design and implemented a form that became my "prototype" for everything.

All of the titles and logo images were in place. All of the crucial events had code in them for various purposes (mentioned later). The form had command buttons for common functions that would appear everywhere. The background was set up as a soft color that conformed to some Navy studies regarding color schemes. I had special common formatting routines for ALL controls that would set a control's foreground, background, and border according to various control states (and form states could enter into the equation). For instance, "normal" meant white background, black print, black border. "Dirty" meant a light pink background, dark red print, dark red border. But as a special touch, "normal+in focus" was different as was "dirty+in focus" - and that was true for other states.

The form's OnOpen code could test whether the user was properly registered according to a user role code. The command buttons were managed by a routine that made them visible/enabled or invisible/disabled and shuffled the visible buttons towards the right edge of the form. I.e. no gaps between two active buttons. The Form_BeforeUpdate would test whether the form was dirty AND whether the update was occurring because someone had used the SAVE button. If not, they would get a tweaky little message about saving before navigating or closing and the update wouldn't occur.

All of the buttons had event logging built in so I knew who had clicked a button when and on which table and which record the click occurred.

Once the template was ready, I built all of the other forms from the template, not from the raw form-builder. This meant one other thing: The look and feel of the set of forms was the same across the board. Maybe a bit boring, but once you figured out how to use the form for one of the operations, the other forms became almost "no-brainers." If you knew what the CREATE button did on the SERVER form, you knew the meaning and effects on that button on the SECURITY ACTION form. And the form knew, for every button, whether you were authorized to use that function and just wouldn't show you what you weren't supposed to use. It was a lot more extensive than that - but all of it was based on the idea of a template to preserve "common look and feel" for ALL forms.

That got kind of long-winded (no surprise, right?) but I think it is important to this topic. Designing a form doesn't occur in a vacuum. You are building an entire APP, not a form. Consider the forest as well as the trees.
 

Dreamweaver

Well-known member
Local time
Today, 23:17
Joined
Nov 28, 2005
Messages
2,466
I do try and work the same way with all my free programs once they use one search/print form you can use them all just each has different options.


I try and keep it consistant thoughout the program never built a template but sounds interesting.


thanks


mick
 

AccessBlaster

Registered User.
Local time
Today, 16:17
Joined
May 22, 2010
Messages
5,827
What makes good design?
There are two groups of designers on this forum. Group 1 is designing at a higher level, with hopes of selling their apps.
Group 2 is everyone else. This group has some obscure niche project that 10 or less people will ever see. Its really apples and oranges.
 
Last edited:

CJ_London

Super Moderator
Staff member
Local time
Today, 23:17
Joined
Feb 19, 2013
Messages
16,553
for me, good design should be easy to use and display informative, relevant data in a calm way. I also like to check how users are used to navigating - using mouse and clicking or tabbing through controls. With the advent of touch, screens should not be too busy or 'evented' controls too close together.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 19:17
Joined
Feb 19, 2002
Messages
42,977
You are building an entire APP, not a form. Consider the forest as well as the trees.
To summarize for Doc, consistency matters. It is probably the single most important design concept. I alluded to it. Doc gave the concept some substance. If your users have seen something before, it should work exactly the same way it did on the other form.

I agree with AccessBlaster but only so far. Even people designing for a small app or for themselves will be helped by consistency. Use your creativity to solve new problems. Unless you come up with a better way, use old solutions over and over again. I have a really old solution that I've been using since the 80's. Obviously that was before Access so I've rebuilt the app two more times and now it is Access but the concept and how it works has changed very little over that time. I've posted it here a number of times. It is an app that I add to all other apps that allows me to manage all those pesky simple lookup tables that I don't want to have to be responsible for maintaining. So, I made an app that puts the maintenance in the hands of the user and I no longer have to think about this problem ever again.
 

isladogs

MVP / VIP
Local time
Today, 23:17
Joined
Jan 14, 2017
Messages
18,186
Good to see a consensus emerging on several points.

I probably spend longer designing forms than all the other components of my apps put together. Obviously good table design is essential but it is forms that end users have to work with. In my opinion, unless the end user finds your application easy to use, it has failed.

So I totally agree that good design involves both usability and consistency.
My forms have a consistent design in terms of colours/fonts and layout.
I use soft colours for the detail section and contrasting colours for header and footer.
I use automatic form resizing to ensure forms work well no matter what the monitor size or resolution
As most of my apps have both navigation pane and ribbon removed, i ensure that controls used on all forms such as Close and Print are always in the same place on every form.
I try to ensure forms remain as uncluttered as possible.
As previously mentioned, for touchscreen apps, ensure controls are larger and clearly separated on screen.

And like others, by using a consistent style, it simplifies my development work as i can reuse items in different apps.

I've uploaded many screenshots and example apps which illustrate my approach.
Of course, my idea of good design isn't necessarily what others believe it to be...
 

CJ_London

Super Moderator
Staff member
Local time
Today, 23:17
Joined
Feb 19, 2013
Messages
16,553
one other thing I would add with touchscreen - need to leave room for the popup keyboard or at least ensure any controls that will call it do not get hidden when it pops up.
 

isladogs

MVP / VIP
Local time
Today, 23:17
Joined
Jan 14, 2017
Messages
18,186
How much do other developers use themes e.g. to help create a consistent layout with complementary colours.

Who else uses automatic form resizing to manage different sized monitors and different resolutions? If not, how do you deal with that issue?
 

CJ_London

Super Moderator
Staff member
Local time
Today, 23:17
Joined
Feb 19, 2013
Messages
16,553
How much do other developers use themes
I don't - at least not the MS ones, Most of my apps use black, white, a very pale blue or an off-white/beige colour for background. I tend not to use borders (except Chiselled special effect for underlining).

I do occasionally use form resizing for different monitors/resolutions but tend to design to the smallest typical monitor used by business and use overlapping windows with the access app hidden
 

Users who are viewing this thread

Top Bottom