First of all, let’s clarify: UX is not UI.
While UI refers to the User Interface (what a human-machine interface looks like), UX refers to the User eXperience (how a human-machine interface behaves).
With Syncplify Server! V6 we think we’ve done a pretty good job at UI… but there are things in our UX that could be improved. For that reason, one of the v6.x upcoming releases will be focused on UX, and on ways to improve and make it easier for an administrator to manage our software.
In order to do that, we had to start with identifying what could be done better, and we have indeed identified a few areas, namely:
Validation
The current strategy is: validate everything, and report all mistakes in a technical way that overlaps with the fields our REST API manages. This is probably still the best for those very few people who know the inner workings of our REST API inside out. But let’s be honest, how many of them are there? We cannot expect our customers to have this type of knowledge, they didn’t design our software, and they don’t only have our software to manage in their daily routine.
So, we need to go from: validate –> report everything (in tech notation)
To: sanitize –> validate –> report if needed (in plain English)
Most things can actually be sanitized. For example, let’s say you created a Virtual Folder for a User, but forgot that all virtual folders must be POSIX-root-based (i.e. begin with a forward-slash). We can simply add that leading forward-slash for you, and not even bother reporting a validation error.
Validation errors will still be reported (but in plain English) only when there is no unambiguous way to automatically sanitize the contents of a field that were filled-in wrong by the administrator.
As a result, our Admin interface will produce a lot fewer error messages (as many mistakes will be automatically sanitized) and the few errors that will be displayed to the administrator will be in plain English, thus far easier to understand and know what to change to fix them.
Reduce the “nulls” to check via REST API
Most modern OpenAPI-compliant JavaScript frameworks are not designed to automatically generate the logic to check for null conditions in every return value. The result is that this logic often has to be written-in by hand by the developer, which leads to bugs and errors.
We’re working hard to ensure that our REST API always returns a predictable set of non-null fields for every call. This will make the UI-side logic abundantly easier and cleaner to design and develop.
