Conditional Formatting For UX
For a video on this post, click here.
What are Rules?
Rules are a function where you can change the state of fields according to an expression. These states include styles, hiding fields and making them read-only.
Styles
Styling is a great way of emphasising fields or just making your app look aesthetically pleasing. With rules, you can make this conditional so that the data dictates what style is shown on the field. We have a couple of examples here: For a video on how to do this please click here
Over-budget/on budget
When using a financial app to track spending, it can be useful to indicate whether the financial budget is on target or over budget.
You will need two styles on your site - one for on budget (possibly green highlighted) and one for over budget (possibly red highlighted). Withh these, you could also make the text bold so that the number is seen more clearly.
Here I have set up a green highlighted style with bold black text:
Similarly, I set up a red highlighted style with bold black text:
Following this, go to the app that you want to apply the style to and open up rules in the advanced section of app studio.
Create a new rule - I have started with this being the one on budget. The filter for this needs to be that if the planned spend is lower than the budget, the style will be shown as green.
As this is an OData filter, it looks like this:
$filter=[PlannedSpend] lt [Budget]
Then select the target field - Planned Spend, and the action needs to be Style, select the green highlight style and aply it to the component.
To set up the red highlight for planned spending being higher than the budget, set up a new rule and call it over budget.
The filter will need to be that if the planned spend is higher than the budget, the field will be highlighted red. The filter for this is:
$filter=[PlannedSpend] gt [Budget]
Select Planned Spend for the target field, add the red styling as the action and apply it to the component
New styles require logging out and back in in order to register the change. Once this is done, you should be able to see the new rules:
Past due date
For an actions/tracking app, you can show when something is overdue through the red styling being applied to a date field.
Past due date is similar to the red styling for being over budget. (Look at the previous section for how to add red styling).
You will need a field for when the task is due and one for date now with the DateNow() expression in this, or a workflow that adds this expression in everyday (depending on whether you want the date to be automatically updated - workflow, or if you want it to run when the record is changed - expression in the field).
Then add in a rule for when the task is overdue. The filter needs to be that if the date duue is less than the date now, it should turn red. This is the filter:
$filter=[DateDue] lt [DateNow]
Add in DateDue as the target field, add an action of red styling applied to the component.
Again, if this is a new style, you will need to log out and back in to see the change. Otherwise, you should be able to see this imediately.
When the date due is in the future, the field will have no styling:
When the date due is before date now, it will be shown as highlighted red
Hidden
Hidden rules can target one or more fields to be hidden from the view of users - this will not delete any data within the field but will mean that the user cannot see or edit it.
Conditional questions
If you have questions that may or may not require a follow up, then you can use the hidden style so that you hide the conditrional follow-up.
For example, you may have a question that asks "Did you encounter any problems?" which is a yes or no answer, but then if the answer is yes, you have a follow-up question which is "If so, what were these?". If they answer no, this question is not applicable and so you can use rules to hide it.
Set up a rule and add in the following filter:
$filter=[Didyouencounteranyproblems] eq 'No'
This means that if the first question is answered with a no, this rule is in effect.
Then add in the target field of the second question (If so, what were these?) and add a hidden action:
The template will look like this if the answer is Yes (or if it is blank):
And then it will be hidden if No is selected:
Selection so certain fields hidden
Similarly, you may have questions/fields that are only applicable to one location/team etc... and you can use the hidden rule to only show the fields applicable to that record.
In this case the fields are conditional to the team:
Operations (Ops) - Customer and Support Provided
Sales - Client and Meeting Notes
HR - Employee and Complaint Details
So selecting a team will then dictate which of the following fields you will see.
For this, create three rules - one for each team. In the ops rule, add in this filter:
$filter=[SelectTeam] ne 'Ops'
This means that anytime the Team is not Ops, this rule will come into effect.
Select the target fields of the ones that are applicable to Ops - Customer and Support Provided and then add the hidden action.
Add in a similar rule for the other two teams:
So when you select each team, you will only see the applicable fields:
Read only
Read-only can target specific field(s) to make them non-editable. This can be really useful for if you have a value in a field that then triggers another one to be read-only.
Making fields non-editable
You may have a field that you want to make read-only after someone has changed the record, for example, after a record has been approved, then a comment text field could be made non-editable so that they are saved and cannot be changed.
Then when the approved is ticked, you can set the comments to be read-only.
Make a rule for approval and add this filter:
$filter=[Approved] eq true
This means that the rule is enacted when approved is set to be true.
Then add in comments as the target field and select Readonly as the action.
This will mean that it becomes non-editable like so (the dotted line indicates that it is read-only).
Please sign in to leave a comment.
Comments
0 comments