The devil is in the details...! 😈
Model-driven apps (MDAs) are at the forefront of modern application development. They offer a robust framework for creating data-driven solutions with the use of components and a structured layout that ensures consistent user experience (UX) across all of them.
Recently (D365 2022 Wave 2 release), Microsoft (MS) introduced the integration of fluent-based user interface (UI) controls with the MDAs. The update breathes new life into the apps’ UI and gives them a more modern look & feel. But in general, the subject of UX in MDAs is not commonly discussed as the assumption is that there is not much to address.
However, it's essential to remember that even with a predefined framework, we still need to plan for certain aspects of the user experience.
Why?... As the devil is in the details!
Some of the UI and UX elements require careful consideration and it is more than just simply relying on the default settings. If you have been building MDAs for a while, the below points might be obvious to you. However, I hope it might be a valuable insight for those who just started building their first model-driven apps and finding their way around them.
In this blog, I would like to share with you a list of dos and don'ts that can improve the overall user experience - or we can just call it "my recipe".
List of Ingredients
Forms
Views
Timeline
Widgets
Subgrids
Navigation
Command Bar
PCFs
Security Roles
1. Mastering Forms
First of all, when dealing with out-of-the-box entities, my approach is to start by saving the main form as a custom form.
Why? This way I avoid the risk of Microsoft releasing updates that could unexpectedly overwrite my customised form. If a customer has someone who monitors and controls the updates, it’s great. However, this is not always the case.
So let’s future-proof the build and avoid a possible situation when one day our users open a familiar to them form and... things have changed unexpectedly.
While this might not directly impact the initial user experience, I believe it's a good starting point for addressing form-specific UX aspects.
It also helps to keep the original form in the system and showcase to the users what changes have been done by comparing the 2 forms.
What else can we do?
The forms are primarily used to collect and display data. Therefore, when designing a form, it's crucial to collaborate closely with the end-users to understand how they work with data consider a daily basis. Based on the outcomes, we should be able to decide on the details for the tabs, sections, and fields. More details below.
a. Tackling Tabs
Tabs are the main building blocks of a form. To enhance usability, we should consider to:
Engage with users to identify frequently accessed data - that should be featured on the first tab.
Reserve subsequent tabs for less frequently accessed or secondary data to ensure that users don't have to navigate through multiple tabs to find essential information.
Move elements between all the tabs to better align with user needs.
For the custom entities and forms, follow the MS approach:
Utilise 3-column tabs for more complex forms with a significant number of fields and for forms requiring a timeline.
Opt for 2-column tabs when dealing with simple forms that have just a few fields.
b. Section Sensibility
Let's talk about sections. Most section names on the key MS forms are CAPITALIZED – a convention not universally loved... (or am I wrong?!)
Here, consider two choices:
Either lowercase the existing sections, turning "ACCOUNT INFORMATION" into "Account Information" or "Account information,"
Or.... Stick with the all-caps style. That means that for any new custom entities (tables) also use the CAPITALISED name for the sections.
The decision should involve your customer as it affects the consistency and aesthetics of the section names, ultimately contributing to better UX.
Tip 💡
There is no need to update all the tab and section names manually. Easy Translator tool can be used via XrmToolBox.
c. The Name Game
Out-of-the-box field names use title case (e.g., "Field Name"). However, usually customers want to use sentence cases (e.g., "Field name"). Ensure uniformity by discussing naming conventions with your customer. If there are multiple team members within the dev team who are creating new fields, make sure that there is a common understanding of how the new fields are created.
While some may consider it a minor detail, maintaining consistency in field naming can improve the overall user experience.
2. Re-viewing the Views
In MDAs, views are lists of records for a specific entity that is displayed in the application.
a. Taming the Out-of-the-Box Views
Did you know that for example the Opportunity entity (table) alone boasts over 20 system views in the Sales Hub app? So while it seems like a testament to Microsoft's thorough thinking about the end-users’ potential needs... It's worth reviewing these lists.
The recent addition of the search option in the view list was a good boost to the UX. Yet, if feasible, streamline any entity list to the views users genuinely need. If the users are unsure, teach them how to use the Advanced Find and how to craft their own 1 or 2 key views instead of wrestling with a list of 20.
For more complex view requirements that vary between the teams and users who require multiple pre-defined data filters, use security roles. That approach allows for shortlisting the views for the individuals or teams.
b. Name and Column Consistency
My few tips are:
Choose the view names thoughtfully - they should be descriptive but not too long. Lengthy names don't sit well with user experience.
When creating new views, maintain consistency in column order within a specific entity. This fosters familiarity and harmony for users.
Resist the idea of overcrowding views with columns to avoid excessive vertical scrolling. If a view is labelled "Active," it does not need a status reason column, does it?
Remember to show users how to adjust the number of records displayed on the entity list as it is a personal preference. This can be done via personal options, with a maximum record count set at 250.
Consider creating charts instead of multiple views for different statuses or criteria. Clickable chart elements allow users to swiftly filter records by status, etc. sparing them the hunt for a specific view on a lengthy list.
When adding views to a dashboard, avoid placing similar views for the same entity on a single dashboard. Instead of that, leverage the view selector option.
3. Timeline, Widgets, and Subgrids
For familiarity that improves the overall user experience consider the below:
Place Timeline, Reference Panel, and/or Knowledge Search widgets consistently in the same columns on forms. The out-of-the-box forms usually position the Timeline in the middle column on top, with subgrids on the first right column.
Maintain the same layout across all the forms. That helps users effortlessly access information, eliminating the need for excessive tab-switching or scrolling.
4. Streamlining Navigation
In the world of model-driven apps, the navigation menu is a constant on the left side of the application. Remember that:
We have the power to show or hide Home, Recent, or Pinned options. By default, they're all set to "Yes". However, sometimes, showing all of them might not be necessary. Consult your customer before toggling these options.
For custom apps, the best is to mirror the navigation of the native apps. Microsoft has been at it for years, and its ideas provide valuable inspiration that can be then tailored to the users’ needs.
It's better to avoid cluttering the navigation bar with a long list of ungrouped options. Organise all the pages (i.e. entities, dashboards, URLs) in different groups. Show the key groups in the main area and the less frequently accessed groups in a separate area.
5. Command Bar
The command bar is a set of buttons that offer contextual options across the app on entity forms and entity lists. Couple of points to consider:
Some out-of-the-box forms come with a very generous set of buttons, leading to overflow options that are hidden under the vertical ellipsis symbol (â‹®).
Depending on requirements, you might not need to display all the options.
Prioritize what users truly need for a clutter-free experience. Overflow should be the exception, not the norm.
Harness tools like the Ribbon Workbench to fine-tune your command bar.
6. Power Apps Component Framework (PCF) Component
If you're new to the Power Platform or D365 and haven't yet explored PCF components, you're in for a treat! These components, including SLA timer controllers or auto-complete, are game-changers. An array of bespoke components can enhance the user experience by visualizing data across D365 and how users can interact with a model-driven app. What can we do:
Use PCFs on forms, views, and dashboards to add controls for reading, adding, or updating information.
While MDAs focus on data, a large volume of records or fields can overwhelm users. When important information might get lost in the shuffle, consider PCF controls as visual cues.
Use them lightly though - excessive PCF controls can slow down form loading and impact the performance, which can result in a negative user experience.
My personal experience with PCF - example of a user case
7. Leveraging Security Roles:
Security roles can be strategic tools for refining user experience. Why?
If multiple versions of a main form are needed for a single table, consider limiting forms or views based on security roles.
This approach simplifies UX without the need for multiple apps.
There is actually much more to it, but I would like to create a separate blog that covers more details. So watch this space!
Summary
Model-driven apps are considered to be easy to build and easy to use. The consistent user interface in the MDAs ensures a great starting point for creating a positive user experience. However, to optimise that experience, a few fine details should be considered when it comes to design and customization. By strategically organising the tabs, sections, and field names, we can ensure that users have a seamless experience when navigating through an app. Close collaboration with the end-users, joined up with careful consideration and applying a few simple rules, is usually all we need to add that final touch.
Also, users usually do not know immediately what they want or need. When possible, grant them access and allow them to test the app that you are building for them. The end-user feedback will help to improve the experience for them - at the end of the day - you are building the app for them! Sometimes, even multiple iterations are required before the final build is complete, which also applies to the form and overall application design.
If you are new to the model-driven apps, don’t hesitate to get in touch with me, I will be happy to help! 😊
Nice article. Congrats