The User Interface

[tvanstiphout]

That's why I've tried to expand and modernize the way the old switchboard looks.

Let's see it.

 

[gemma-the-husky]

What you called "one line menu bar" are the tabs of the Ribbon.
Users of this app all have desktop computers and full size monitors.

I see what you mean now. I see. In that case, I'm not keen. I thought that was a new feature. In A2003 the top line, dropped down a column of options, which didn't use screen space, it just temporarily displayed the options over the open form. I just feel the the ribbon takes far too much space compared with a few text options, especially on a lap top.

I have never really used the ribbon, although I looked at how to manipulate it. I use an A2003 menu bar, and that appears as an option in tools/addins in later versions. I just found I get more options in a smaller area.

 

[GPGeorge]

Here's a little app you can test for book searching and stuff, let me know if you want me to add features... it's using google's book api

Vite + React

obscene-boundary.surge.sh

I made it mobile first, but it will look ok for desktop too. Just to show a book app shouldn't be a nightmare to navigate.

Here's an example of the kind of data one can get from the Google API. There are other data points in the returned JSON file which I discard because they're not relevant to the purposes of this app.

I used the "Type" option in order to show the ISBN used for the search. It works the same with a scanned bar code. If there are multiple co-authors, they show up as list in the Author control. And I see the publisher option is broken. "I swear it worked the last time I used it."

 

[GPGeorge]

Here's a little app you can test for book searching and stuff, let me know if you want me to add features... it's using google's book api

Vite + React

obscene-boundary.surge.sh

I made it mobile first, but it will look ok for desktop too. Just to show a book app shouldn't be a nightmare to navigate.

I have to deploy this on a cellular enabled tablet or a smart phone; browsers or desktop applications are not currently an option.

Screen real estate is pricy in that environment.

Buttons have to be large enough to actually press them discretely with one finger. And they have to be spread far enough apart to minimize accidental presses on adjacent buttons.

But I feel like I've verged away from the original intent of this discussion, so maybe it's time for me to back out.

 

[Edgar_]

That's just an internet search, right? Will that accept a barcode?

I'm using Google's book API: https://developers.google.com/books/docs/v1/using
Anything you see there, the app could do. Reading the thread further I see that George is also using the same API in his app and mentioned he scans the ISBN identifier, so searching for that can look like this: https://www.googleapis.com/books/v1/volumes?q=0007322593
Try it out. As for the barcode, I've never done such a thing, but I've been following this library for a while now, maybe I can give it a try if you're interested.

But I feel like I've verged away from the original intent of this discussion, so maybe it's time for me to back out.

We're still discussing UI, so I personally don't think it's Off topic.

I admit I have no idea of what tools you have available to develop with PowerApps. However, if I open this thread using my smartphone and I scroll to your app's image, I see that my index finger covers too many controls to have any precision with that layout. If that's how it looks on a smartphone screen, then users have to zoom in and out to navigate that, which is a bad user experience. But it can be rearranged in many ways to adapt to a small space.

The app I deployed is one example of how you can arrange the information and place action buttons to make it interactive for a small screen, which is called "responsive" design. If you open the app on a desktop screen and you resize the screen, you'll see how the elements shrink or expand to take different proportions, if they have space to share, they share it, if not, they take the entire screen and stack on each other in a decent way so that a smartphone user can still see the information without having to zoom. You can also choose to hide information according to the screen size, so it becomes very handy.

Here's the breakpoints that I'm using:

There are lots of UI design resources for web development, a lot of them can be used for Access.

 

[GPGeorge]

I'm using Google's book API: https://developers.google.com/books/docs/v1/using
Anything you see there, the app could do. Reading the thread further I see that George is also using the same API in his app and mentioned he scans the ISBN identifier, so searching for that can look like this: https://www.googleapis.com/books/v1/volumes?q=0007322593
Try it out. As for the barcode, I've never done such a thing, but I've been following this library for a while now, maybe I can give it a try if you're interested.


We're still discussing UI, so I personally don't think it's Off topic.




I admit I have no idea of what tools you have available to develop with PowerApps. However, if I open this thread using my smartphone and I scroll to your app's image, I see that my index finger covers too many controls to have any precision with that layout. If that's how it looks on a smartphone screen, then users have to zoom in and out to navigate that, which is a bad user experience. But it can be rearranged in many ways to adapt to a small space.

The app I deployed is one example of how you can arrange the information and place action buttons to make it interactive for a small screen, which is called "responsive" design. If you open the app on a desktop screen and you resize the screen, you'll see how the elements shrink or expand to take different proportions, if they have space to share, they share it, if not, they take the entire screen and stack on each other in a decent way so that a smartphone user can still see the information without having to zoom. You can also choose to hide information according to the screen size, so it becomes very handy.

Here's the breakpoints that I'm using:
View attachment 111496

There are lots of UI design resources for web development, a lot of them can be used for Access.

Did I mention spacing and size of controls? I am reasonably sure I did mention that. I use this app only on a tablet or a browser or in the desktop app. It runs on a smart phone, but as I started out saying, IIRC, in order to make it truly usable on a smart phone, it would have to be spread out over multiple screens. So we agree on that point.

 

[Edgar_]

Did I mention spacing and size of controls? I am reasonably sure I did

Yes, but...

in order to make it truly usable on a smart phone, it would have to be spread out over multiple screens. So we agree on that point.

I think what you've shown can fit on one screen without any problem. We can stack things up neatly and use the full width, and important actions can be put in discreet buttons, as demoed in my app. There are easy ways to make navigation smooth. But if there's more to it that I might not be getting, I trust you as the designer.

 

[GPGeorge]

Edgar, you said,

"However, if I open this thread using my smartphone and I scroll to your app's image, I see that my index finger covers too many controls to have any precision with that layout."

And also:

"I think what you've shown can fit on one screen without any problem. "

It fits on one smart phone screen, yes, but it is not usable on one smart phone screen.

Well, that's not 100% true. I can use it personally, but that's only because I created it and I know what all the parts are without having to be able to read the labels. Others who did beta testing on an iPhone and on an Android phone both refused to continue using it after a couple of attempts. My user with a iPad loves it.

 

[Edgar_]

@GPGeorge
I must have a issue communicating my idea, because I totally agree with this:

It fits on one smart phone screen, yes, but it is not usable on one smart phone screen.

It is not usable. However, if the layout is rearranged like this, for example, there would be no problem on mobile, maybe?

 

[GPGeorge]

@GPGeorge
I must have a issue communicating my idea, because I totally agree with this:


It is not usable. However, if the layout is rearranged like this, for example, there would be no problem on mobile, maybe?

View attachment 111515

Thanks. Although I'm not interested in a redesign, others may want to see alternatives.

However, I would suggest that on a smart phone, that font size would be so small as to be difficult to read and use. What does it look like on your smart phone?

 

[Edgar_]

What does it look like on your smart phone?

It looks small.

I quickly put together an example in Excel instead of dealing with CSS for styling, so it's not super precise. But, if we switch to just one column for the Google vs Foundation section instead of two, it'll look OK for mobile. I'm not sure what the app does, so excuse me if this is off.

 

[GPGeorge]

It looks small.

I quickly put together an example in Excel instead of dealing with CSS for styling, so it's not super precise. But, if we switch to just one column for the Google vs Foundation section instead of two, it'll look OK for mobile. I'm not sure what the app does, so excuse me if this is off.

Thanks for providing the alternative approach. It does look nice in this environment. And your confirmation of the usefulness of the Google Books API is reassuring as well. It's a powerful tool. In fact, I could not have created the LTF data collection app without it, but that's different story for another context. If anyone is interested, though: Why I helped create the LTF application.

However, this thread started out, IIRC, wondering about different approaches to interface design for Access. We veered off into web interfaces, which are obviously quite different from what can be done in Access. In today's world, many people do prefer it.

As Tom demonstrated, an information-dense screen can work really, really well in Access.

There are other equally viable approaches. The "web look" is yet another.

My offering is aimed at a small niche: Mobile devices, and more specifically designing for the form factor that provides an acceptable compromise between usability and information density. In other words, it really works well on a tablet--an iPad or Galaxy, etc.--but not on an iPhone or Android phone. User feedback made that clear. It could be redesigned for the smaller screen size, but I am not particularly interested in going that route for this app. It's just not worth it for this particular app.

BTW, You can find some insights into good interface design for Access in this video from a few months ago.

 

[Isaac]

I thought I would start a thread on art and ergonomics. I imagine a thread of this nature could generate broad discussions,
I'm going to start it with one topic, Form Density.

Do we start with a question, or a statement? How about a question.

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

There that should get us started.

I edited this for punctuation and clarity. They still might be screwed up, but it is an improvement.

I put a heavy preference/weight on Tasks that the user will need to do, corresponding with Permissions that different staff levels have.
Thinking along these lines generally gets me to a Tab Control with permissions-based tabs and the occasional popup for adding stuff to lookups or when the tab page is just getting too busy and I am sick of nesting tabs.

 

[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 an interesting observation - the fact that along with web environments, seems to also automatically come an incredibly dumbed-down sequential process of data validation and branching - like really really really layered, almost to an extreme.

Most database architects aren't interested in making 20 screens to complete an order, and most db users aren't expecting to have to look at 20.

There may be other reasons that webby designs tend to go those long routes - I'm thinking they have to pertain to a more diverse audience, and you have to code to your least sophisticated consumer/denominator.

Whereas database entry applications (etc), are meant for a small group of people who are trained to use them. Intuitive, self-explanatory designs are always excellent, of course, but you don't necessarily have to design your db screen to an audience of 8 billion, whereas a webpage you often do.

 

[GPGeorge]

You make an interesting observation - the fact that along with web environments, seems to also automatically come an incredibly dumbed-down sequential process of data validation and branching - like really really really layered, almost to an extreme.

Most database architects aren't interested in making 20 screens to complete an order, and most db users aren't expecting to have to look at 20.

There may be other reasons that webby designs tend to go those long routes - I'm thinking they have to pertain to a more diverse audience, and you have to code to your least sophisticated consumer/denominator.

Whereas database entry applications (etc), are meant for a small group of people who are trained to use them. Intuitive, self-explanatory designs are always excellent, of course, but you don't necessarily have to design your db screen to an audience of 8 billion, whereas a webpage you often do.

I am no expert on web design, but I think you make a good observation about the design approach in most web apps. For example. PowerApps, while they have many good features, are defined as a "low code" solution. I have argued for the hybrid approach for that reason. Only those parts of the application which require remote data collection (going into a warehouse to scan product codes for a stock-take using a mobile device) need to be, and should be, in that format. And the minimum number of screens to accomplish that is a goal.

One of the most frustrating things I've had to come to grips with is the inability to create public functions so that code can be consolidated in one module. In the app I illustrated, I need to refresh certain Collections, which in PowerApps are more like in-memory temporary tables. I have to replicate that code in every place it needs to be done. Well, there is an ugly work-around which negatively impacts performance, so it's not recommended. It is better to rely on Copy/paste. Sort of like everyone's first accdb interface, right? But here it's by design. It's a function of the browser environment and the implementation for PowerApps. Each screen is largely self-contained to some extent.

Again, I fear we've veered too far away from the original intent of looking at Access interfaces. Mea culpa.

 

[Edgar_]

Don't forget about Wizards, guys. A sequential form that shows what is necessary of the user in order to continue, in a logical way, with default values, ideal configurations and lots of feedback. People have learned to trust they just have to click next and the program will be installed.

Compare and contrast that with tools that require training not only for usage, but for installation even. Like those terminal window tools. Very handy if you know the commands, but if you don't? it's like comparing Word with Vim, a world of difference.

 

[Thales750]

I'm kind of with the younger folks who have said they don't really care what they have been using. In as much as often they were making do. And, as often as that they hated it.
I refuse to work for companies that dictate to their employees. The people are more qualified than their bosses in most cases.

Lastly, making it mimic old stuff just makes it that much harder to train new people. Hence the making things look like MS Office. I don't use very much color, only to highlight the currently most important things, and only with subtle shades.

No Christmas Trees please.

 

[gemma-the-husky]

To be honest I prefer to consider what the staff think they want, and then try to give them what they really need.

Where this gets tricky is that if they want to search for a "term", then you can add a search key to the table. Another way is to search every record for the search term(s) as a substring in the item name or even search the whole record, but this can be slow with a large table. Maybe you could use a Soundex to find near matches. If you knew how, which I don't you could what Google do, and gave a super fast context search.

Users would never specify some of these, I expect, but if you can give them more of what they really need, rather than what the are currently used to it can be a great help.

How did Unix achieve a "grep" out of interest? However generally we need searches to retrieve records from the sea of data.

 

[Jason Lee Hayes]

Did a small database way back in 2006; even uses the legacy switchboard. Quickly grew to the point where it needed rebuilding from new. The customer always required something adding ad-hoc to which there is only so many tabs you can use lol. It worked will for their requirement and is still being used today.. Must have done something right...

 

[gemma-the-husky]

Did a small database way back in 2006; even uses the legacy switchboard. Quickly grew to the point where it needed rebuilding from new. The customer always required something adding ad-hoc to which there is only so many tabs you can use lol. It worked will for their requirement and is still being used today.. Must have done something right...

MTBF. Mean time between failure.
I like to think my stuff does well on that, as well.