Report creation best practises Part 1, UX

Sometimes when a report is run, multiple tests are gone through in order to find if the filtering or parameters for the report is set correctly or as intended. For example user might have left out some important filter which causes the report do unexpected things.

Therefore user must be asked to confirm if the operation he is going to perform is really started with firm intentions, or is it just an accidental click to test what this and this thing does. This is especially important with the functionalities that delete something from the database.

In the old days, user was asked each time if he is sure he wants to go on with the suspicious setting, ending up user clicking multiple times "Yes", until he finally manages to get the report run. This causes aggravation and is just frustrating - when you can just collect all the suspicious parameters in one window and show it to user at once and ask if the suspicious parameters are indeed what he meant to do when inserting or leaving them empty.

Luckily this approach has been adopted with Microsoft and NAV developers as well, because it has enormous impact on user experience.

The same pattern goes very well with error messages, and in Dynamics Community pages there is already an entry for (IMHO very heavy) error handling pattern: https://community.dynamics.com/nav/w/designpatterns/236.error-message-processing

A bit lighter version can be found from Report "122 Reminder - Test", where all the errors are gathered to an array and then shown in the printout. This functionality can easily be transformed to use with very light version where developer adds all the questions that possibly arise to a single string separated with linefeed, and finally right before running the report asks confirmation to all questions at once. Should all the tests to the data be ok, then user is asked only confirmation if he really wants to go on with the report or quit.

For demo purpose, I created a sample report where three things are checked and added to string, shown to person running the report for confirmation, and then depending the reply abort or continue. Demo report is used to delete unused SKU's for items. It can be run from item card or from menusuite.

This report has actually multiple "Good Things To Have" when it comes to user experience and convenience of using NAV:

  • Report filter fields are pre-set, so user knows what he is supposed to filter the report with
  • DataItems that user is not required to filter on are hidden
  • ML translations are used with text constants
  • All suspicious things and confirmation questions are collected and shown at once, no multiple Yes-clicking
  • Default answer is set to confirmation dialog
  • If all checks come out clean, user is asked if he/she wants to continue running the report -maybe he clicked it accidentally and really did not want to delete anything
  • Confirm -dialog ends up with question mark
  • User is shown a summary what the report has done
  • Report uses ISEMPTY for best performance (instead of COUNT, FINDFIRST, FINDSET...)

 

This raport can be run either from Item Card or Item List pages, or from MenuSuite. You can add PageAction code below to set default filtering:

CompanyInformation.GET;
Item.SETRANGE("No.","No.");
Item.SETFILTER("Location Filter",'<>%1',CompanyInformation."Location Code");
REPORT.RUNMODAL(REPORT::"Delete unused SKUs",TRUE,FALSE,Item);

 

For reference, you might also want to check report "339 Suggest Vendor Payments", which is really nasty. After each problem an error is shown and the report is cancelled. In the worst case you have to run the report 5 times before you have everything right. And NAV should be user-friendly...

I will continue this blog post later with changes that need to be done if this report is going to be run by NAS.

As usual, if you decide to use this report in your projects, it is all yours, but I take no responsiblity if something unexpected happens!

Comment List
Anonymous
Related
Recommended