The User Interface

[Isaac]

How do you determine the balance between too much info on one screen, and too much popup opening?

I interpreted this a bit different than other early responders, I figure you know how the process of designing an app works, but are more wondering what the philosophical approach is to things - details that the end users probably don't tell you, and frankly, in many cases shouldn't, because they don't know what will work best or what design components/capabilities you are working with.

I would say I would lean a bit toward the screen containing a lot of information. The ability to see a 'next layer' of detail, and the ability to Edit that information, would both be more likely popups.

For example, there may be a drop down, Select Client. With an Edit pencil to add or edit Clients which would become a popup, then requery the combobox when popup's business is finished.
Another example, there may be a summary: "18 New Applications Waiting". A Details link would open those details.

Etc.

 

[The_Doc_Man]

I don't know if this will make sense in your context, but for my craziest project, I didn't have ANY data on the screen until someone clicked an action button that suggested what they were planning to do. I then would enable and/or make visible a bunch of related controls needed for the function in question. And NOTHING ELSE would be on the screen at the time. Then when the function was completed, the related controls vanished again, leaving only the list of action buttons. Sort of a "minimalist" viewpoint.

 

[Isaac]

TL;DR I avoid dense to favor workflow. Popups are no problem here.

We are at the end of the year 2023 and ALL of my users use smartphones. Therefore, all of my users are more familiar with the web standard than the windows forms standard.

When I open a smartphone app, what I see is simplicity and lots of feedback, so I apply those two concepts into my designs. In doing that, I don't have to provide training to my users, because it's intuitive for them. They often say "Oh, it's like whatsapp", "Oh, like sending an email, right?", "This looks like the app of my bank", etc.

Things that made sense in 1995 don't make sense in 2023. My users obviously don't want to use paper for data entry, so I design forms that take advantage of the computer medium, instead of making them look like paper forms. They're no longer used to paper forms anyway, so I won't bring back ancient solutions when there are objectively better options. So, instead of dense forms, I design workflows.

If you want to know what I mean, I will share with you my inspiration app, this entire site is amazingly well detailed and it will surely give you some great inspiration:
https://experience.sap.com/fiori-design-web/when-to-use-which-floorplan/

Here's a few screenshots:
View attachment 111470 View attachment 111471 View attachment 111472

Also look at the many other design principles used in that app:
https://experience.sap.com/fiori-design-web/action-placement/
View attachment 111473View attachment 111474

Or this, which is a workflow I love applying because my users understand it so easily:
https://experience.sap.com/fiori-design-web/navigation/

View attachment 111475

Navigate that site, it's incredible. I have another one, from a UI framework I use for web apps, here's a few links and screenshots:
https://ant.design/docs/spec/navigation
View attachment 111477
https://ant.design/docs/spec/proximity
View attachment 111476

Make sure to browse the other categories, they give amazing insights about form design.

Most of these things can be applied to Access.

I absolutely love this post for the things that it said about what users are already used to and therefore what you know will be more intuitive for them versus less intuitive. And I agree that the two things that the general public is most familiar with are web pages and smartphone apps, therefore whatever intuition they are trained for in those environments can also be often assumed in the access environment.

For me personally this means immediately doing the necessary actions to prohibit access from overly or over aggressively auto saving everything at the slightest touch. But that's just my personal way of applying the concept -- my MAIN point here, is that I like the concept.

Users don't care or know what is normal for Microsoft access and neither do I when I'm developing it. I only know and care what the user's expectations are because the closer I can come to meeting their expectations that goes a long way toward what they will consider a functional app.

 

[Isaac]

Some people prefer "webby" designs and others don't. This is a data collection focused app. Forcing people through multiple screens to complete a record seems to me, at any rate, to be less user friendly. To me, that's the wrong approach for rapid data collection.

You make a good point. For apps or screens that are heavily focused on intensive data entry, it's all about stuff like setting the focus in intuitive places and moments, as well as partially validating stuff as it's being typed in and not waiting till the end. Prefilling where possible making intuitive suggestions where possible.

 

[Edgar_]

For me personally this means immediately doing the necessary actions to prohibit access from overly or over aggressively auto saving everything at the slightest touch.

Indeed, users really don't want to deal with that behavior when the standard is being able to choose to save.

 

[tvanstiphout]

I don't know if this will make sense in your context, but for my craziest project, I didn't have ANY data on the screen until someone clicked an action button that suggested what they were planning to do. I then would enable and/or make visible a bunch of related controls needed for the function in question. And NOTHING ELSE would be on the screen at the time. Then when the function was completed, the related controls vanished again, leaving only the list of action buttons. Sort of a "minimalist" viewpoint.

If you want to go down this road, my presentation about Task Driven Development may be useful.

 

[gemma-the-husky]

Indeed, users really don't want to deal with that behavior when the standard is being able to choose to save.

Except for standard, you can often read old fashioned.

Users might think they need a search key field to find a customer, for instance, because that's what old systems used to do, but what they really want is a better search tool. So give them a better search tool.

 

[Thales750]

Except for standard, you can often read old fashioned.

Users might think they need a search key field to find a customer, for instance, because that's what old systems used to do, but what they really want is a better search tool. So give them a better search tool.

What's better than key word searches?

 

[gemma-the-husky]

What's better than key word searches?

Multiple partial string searches.

For instance, for a customer or product we used to have a short name alternative to the full name

We then changed that that to allowing up to 3 short substrings from the full name, which was much easier to use and worked better.

But if you hadn't seen the second way, you might think the first way was what you wanted, if you were asked what you wanted as a user.

 

[Thales750]

Multiple partial string searches.

For instance, for a customer or product we used to have a short name alternative to the full name

We then changed that that to allowing up to 3 short substrings from the full name, which was much easier to use and worked better.

But if you hadn't seen the second way, you might think the first way was what you wanted, if you were asked what you wanted as a user.

How does that work?

 

[gemma-the-husky]

How does that work?

Maybe it depends on how many items you need to search.

If you have a file with 500 products, then it may be enough to use a partial name entry, starting from the last (combobox) or search for a single substring in each record.

With a slightly bigger file size, it's easy for a user to enter "steel screw 8" and get a manageable number of products to pick from. Otherwise you end up needing a complicated system of cascading filters, which still might be awkward to use.

In the UK I tend to give up very quickly when searching for clothing from most large retailers.

I find eBay much more useable than Amazon. Amazon seems to make it very hard to return true matches, to me. It doesn't really help when your search returns 12000 results.

Maybe Amazon and eBay get their sellers to give their products multiple tags, and your search finds products where all your tags work. It's difficult if you want to find a ring in size P, say, as searching for P as a substring won't work. Not all domains use size letters. You try to find candidate 9 carat yellow gold rings with no stone, in size P or P.5, and see how many false matches you get.

But not every product has a size that is a single letter. Clothes sizes don't work like that. You even have multiple different size charts for clothes.

For my projects, allowing up to 3 substrings worked well enough to reduce the full list to a manageable size.

There's a difference between the way you manage an accounts receivable file with 1000 sales accounts, compared with an accounts receivable file for a business with hundreds of thousands of customers. In the latter case you probably don't ever want to see a full listing. What value is a 1000 page report. You have to manage everything by considering exceptions instead.

 

[Isaac]

The one technique that I sometimes find workable is to find the 'amazon Store' of a certain brand. I.E., I like Carhart heavyweight tshirts, and fortunately they have an Amazon Store for their own brand so that is helpful. Also Wranger I think has one, which yields many reasonable shirts and shorts.

 

[Thales750]

The part under the Yellow Section is for navigation and filtering. It manages entities like customers/project/task/ contacts etc.
The Blue Section manages contacting people.
The Yellow Section is useful for more than just filtering communications.
Here is the question.
1. Would you make a subform for the Yellow Section and use it in other main forms?
2. Make subform of the part under Blue Section and use different subforms on this Main Form
3. Both
4. Just add a tab control to the Blue Section
Edit: After writing this out. I've decided that I would probably go with option 2. This will allow quicker switching back and forth between various operations in the Blue Section while keeping the same selection in the Yellow.

 

[AHeyne]

TL;DR I avoid dense to favor workflow. Popups are no problem here.

We are at the end of the year 2023 and ALL of my users use smartphones. Therefore, all of my users are more familiar with the web standard than the windows forms standard.

When I open a smartphone app, what I see is simplicity and lots of feedback, so I apply those two concepts into my designs. In doing that, I don't have to provide training to my users, because it's intuitive for them. They often say "Oh, it's like whatsapp", "Oh, like sending an email, right?", "This looks like the app of my bank", etc.

Things that made sense in 1995 don't make sense in 2023. My users obviously don't want to use paper for data entry, so I design forms that take advantage of the computer medium, instead of making them look like paper forms. They're no longer used to paper forms anyway, so I won't bring back ancient solutions when there are objectively better options. So, instead of dense forms, I design workflows.

If you want to know what I mean, I will share with you my inspiration app, this entire site is amazingly well detailed and it will surely give you some great inspiration:
https://experience.sap.com/fiori-design-web/when-to-use-which-floorplan/

Here's a few screenshots:
View attachment 111470 View attachment 111471 View attachment 111472

Also look at the many other design principles used in that app:
https://experience.sap.com/fiori-design-web/action-placement/
View attachment 111473View attachment 111474

Or this, which is a workflow I love applying because my users understand it so easily:
https://experience.sap.com/fiori-design-web/navigation/

View attachment 111475

Navigate that site, it's incredible. I have another one, from a UI framework I use for web apps, here's a few links and screenshots:
https://ant.design/docs/spec/navigation
View attachment 111477
https://ant.design/docs/spec/proximity
View attachment 111476

Make sure to browse the other categories, they give amazing insights about form design.

Most of these things can be applied to Access.

The concepts presented in your links are very interesting.

Your last sentence in particular tempts me to ask you whether you have any examples of how you have implemented something in Access.

Can you show us something, possibly just screenshots?

 

[Edgar_]

Can you show us something, possibly just screenshots?

Well, here's an example of an empty state that I recently posted:

Form blank when no records found

On my form, I have a StartDate and EndDate fields for the user to search records. I am using the AfterUpdate event on the EndDate field to trigger the action. If my vba code is set to: Me.Requery The code works perfectly and displays the records within the chosen date range. However, if the...

www.access-programmers.co.uk

The OP wanted to do something else, but I posted it in case someone googling that topic brings a user there.

Similar to what's described here:

Empty States | SAP Fiori for Web Design Guidelines

There are a lot of design examples in the links that I posted, are you interested in anything in particular? Maybe I can prepare (or discard if not possible) something.

 

[Isaac]

I also appreciate the phrase, "I avoid dense and favor workflow", I feel exactly the same.
Having said that, I'll confess to having created some very busy screens in my time. But what I'm much more proud of is a simple, minimalist layout that smartly guesses what the user needs to do based on who they are and many other contextual factors