Are any of you developing FileMaker solutions that use mainly FileMaker's native toolbar (prev, next, new record etc...), custom menus and different view modes instead of creating the end user's UI from scratch with layout objects (navigation, buttons, button bars...)?
I was thinking about the Open Quickly feature and tried to think what kind positive things it could bring, after I got over from the first come defensive, negative and risk based attitude towards it. That made me think about developing solutions by leveraging FileMaker native UI and functions more.
I have mostly developed solutions by hiding "the FileMaker" parts from the end user, but have also used solutions where FileMaker's native functionality is used in very efficient and effective ways. Usually those may not look so nice but can provide very advanced functionality.
I’m a big fan of the built in tools. They all respect the security settings, and they bring in a lot of utility. Rebuilding them in the UI is time consuming and, I think , mostly wasted time. I have better things to do than make pretty go to next record buttons.
I would like the status bar placement to be optional. I would also like a much simpler way to handle menus for those situations where I simply want to remove one or two options.
Never built a solution exposing menus, the status bar or the toolbar to a user…… lose control over navigation sequence/workflow, data validation, and scripted behavior are not things I’d like to see in anything except maybe the most simplistic solution.
We have mostly retained the status bar, but always use custom menus, which controls the buttons on the status bar.
The biggest negative of this approach, and the reason I have campaigned for years to have a complementary ‘OnRecordLoad’ script trigger, such as ‘OnRecordUnLoad’ or OnRecordExit’, is the control of validation, which is almost entirely script driven in our solutions. We have lost hundreds of hours trying to get around this missing trigger, which would not be a problem using custom buttons, albeit every navigation script would have to include the data validation check from the context it is running in.
Other than this, we don’t really see the point of rewriting something that has worked well over the years, despite a bug having crept in over the last few versions where the status bar will hide, for no apparent reason.
As debated in another post in the soup, our belief is that Open Quickly doesn’t add to any exposures within a system, it adds another way of exposing them. I was very anti the addition of the Advanced Tools when they were included as an optional addition in the single Pro version. I’m glad to have been wrong, as this has helped debug problems on users’ computers many times and I’m enjoying eating my humble pie on that one. I hope I’m not wrong on Open Quickly.
An exception to exposing the status bar for us is on modal windows, which also have their own custom menus, or on WebDirect layouts, which we don’t want to appear as FileMaker layouts.
I agree 100% with you. A good UI is one where the user can't jump everywhere from anywhere. You know what they say: garbage in, garbage out ! That« is why validation is so important. On top of that, sometimes a process may need the user to proceed on a specific order. This is where the UI is so important.
I have seen a system where users where users were using the the Layout list to navigate in the solution. That means users must know the Layout names !!! I talked with the, hum, specialist who created the app, and told him this is not the way to go. His answer was: It's there, I use it
Custom menus but not visible to a user. As mobile first is a common and almost universal design philosophy, along with web direct for performance, menus have no usability beyond eliminating or redirecting existing command functionality. Logic decisions made on content is common, and branched layout navigation to support defined workflow is imperative.
25+ years ago, heading up the design for a reservation system for a global airline, they had hired the person that was at the time the worlds foremost expert on what we now call UX or User eXperience…..then known as performer centric design - excellent lessons learned there. Present the information needed for decisions in the same place at the same time was one key concept. Workflow sequence was another.
Allowing users to jump wherever? The complete opposite of transactions. I can’t (actually I can) imagine the data quality issues with direct layout access. Just managing the layout scrip triggers that would emulate the scripted action of navigational scripts would be a nightmare.
A recent client FM solution was 2,200 TOs, and around 4,000 layouts. The long standing layout selection option of only displaying 256 layouts and data complexity completely eliminated allowing users direct layout selection access.
I use them all the time. Rosemary T got me early in my development career (FMP 9) on just letting FileMaker be FileMaker. Then with the advent of Custom Menus, you can hijack the controls for deleting and creating records, or disabling functionality. This can also all be based on privilege sets or whatever else you add to your custom menu calculations.
Pros
More granular control over basic functions that are given to you via FileMaker.
Respects FileMaker Security settings so it can't be overridden by a change of the script..
Eliminates the need to go to each layout and make sure that the right button on the right layout with the right script is attached, etc.
Cons
If you're not familiar with Custom Menus, it can be a bit of a learning curve to get to know them, but once you get the hang of using them it's a really great asset. Custom menus can be over-used, and it can become difficult to know what's happening from page to page.
Interesting... In my solutions, I provide custom menus, which it turns out that almost ZERO of my client-users ever access because all navigation, script activation, etc. are provided in the UI. Status bar (and formatting bar) is not accessible to users at all. It's not only ugly and dated IMHO, it also is a source of confusion and potential mistakes for some.
I realize this is a very personal and probably subjective topic, and I respect those who prefer a different approach, but my users want a real "don't make me think" UX, so that's what we strive for. However, our clients are typically not "tech" people, while many are scientists, analysts and the like, many are also general office or client services personnel. The scientists and analysts express appreciation for well controlled U/X because they must work with a lot of proprietary software for advanced testing instrumentation (with bad UI/UX) and find our solutions very comfortable and intuitive to use.
Fortunately, we (FM devs) have a lot latitude/options in terms of our design choices.
