Simplicity always wins
This is a great quote from James Crowter, a fellow mvp and friend from the UK. He said this while presenting UI best practices for the phone client last year at Directions USA.
“The Beauty of simplicity”
This was the slogan that Navision software used for selling its ERP in the 1990ies.
In my Master Class I spend a considerable amount of time on simplicity, partly because it is one of the core values of Dynamics NAV, but also because the meaning of simplicity is changing over time.
When Navision talked about simplicity they meant that you could install the product from two 1.44″ floppy disks or later a CD-ROM using next-next-next-finish.
This type of simplicity is long gone if you see what you have to do to make single-sign on work with Office 365.
Navision also used the term simplicity for the applications architecture using the same code and table structures that caused the application to be learned in an efficient way. We now call them “Design Patterns”, I hope you have heard of that. 😉
This type of simplicity is also a lot harder to recognise nowadays since the application grew organically and by aquisition and the patterns today are hard to reverse engineer and in a lot of application areas Microsoft is not following their own patterns and guidelines.
With project “Madeira” simplicity is back
When we talked about project “Madeira” during meetings with Microsoft over the last few years (hey I did not know it would be called like this…) we spend a lot of time debating about wether or not NAV is still simple. My opinion was that simplicity was kind of lost and that was for me the reason to start writing my first book and the Design Patterns project that Microsoft hooked into later.
Both the infrastructure, code base and the application had lost simplicity and it was hard for new consultants and developers to learn how to work with Dynamics NAV.
The first step back to simplicity was the Role Tailored Client where Microsoft did a first attempt to rearrange the user interface to specific roles in the organisation.
A second step towards simplicity is the way project “Madeira” is hosted and installed. You can start using it like the old days except it is not a floppy disk but an “app”.
The application made simple
The core NAV architecture is designed to be very flexble in setup but the options are all accross the application and creating a new company from scratch is hard. Over the years Microsoft has made several attempts to simplify setup. Remember the templates in Navision 4.0 and the Step-by-step Setup?
The wizards in Madeira take setup of the application to a whole new level and the Walk-Me makes it easy to get started.
What is especially smart about project “Madeira” is that Microsoft ook the application back to core finance and inventory. Just like Navision Financials 1.00 but with all the improvements we added in 20 years.
Design Patters for the User
When Microsoft Dynamics C5 2014 replaced the old C5, the developers made a first attempt to simplify (error) messaging. This is an area that Navision has always been particulary bad in which is primarily caused by the existance of the AL command TESTFIELD.
These patterns are also implemented a little in project “Madeira” but not nearly enough. Real usabilty would be created if the TESTFIELD command would be enhanced taking the user to the error in the UI.
For example: If I progam CompanyInformation.TESTFIELD(“Bank Account No.”) I want NAV to open the page with company information with the cursor on this field, or I want NAV so send an email to the application manager that a user has hit a restriction in the system to she/he can solve it.
Adding more modules
One thing we discussed lately with Marko is the strategy to add more modules to project “Madeira”. Microsoft wants “Madeira” to be extendable using extensions but for that to be done the application needs to be loosely coupled. This is currently not the case.
For example: The current core finance engine and core inventory engine lack a good API. The way the application areas work together is hard coded and not event driven which makes it hard for developers to find places to hook into the core.
My suggestion would be to take the opportunity with project “Madeira” to rearchitect the application to be loosely coupled so that Jobs, Manufacturing or Warehouse can be an extension to the core finance and even the core inventory should be an extension.
Not an extension in the technical sense, meaning a delta file, but an extension in the architectural sense meaning you can delete the objects without causing compile errors or functional misbehaviour of the application.
Other Extension modules
Many years ago I’ve created a Transport Management add-on for NAV which was completely loosely coupled exept for a few objects we touched. If project “Madeira” allows architecture like that other ISV’s could create their own Lean Manufacturing App or Pallet App or Automotive App which would no longer be coded inside the existing Manufacturing tables or inventory codeunits, they would be apps that co-exist side-by-side with other Manufacturing apps.
This requires a different thinking for ISV’s that are now used to “hack” the Microsoft source code which will no longer be possible with Extensions in the future.