Posted on 27/03/2020 09:43:22
Hi Soren,
Thank you for your answers.
Based on what you answered, I believe I did not make myself very clear.
I am not talking about data validation on import or export. I am talking about ways of validating the data in the PIM UI, when the user documents the product.
If you think about an admin documenting 50 fields for 500 products and then publishing the products to a channel, you would probably understand the admin frustration if they will get a couple of hundred error messages back when trying to publish the products. This would mean the admin will have to start all over again and correct the errors. While if there would have been a client-side validation in place, the admin could have been warned by the wrong format right in the interface when entering the values.
Think about the validation of the address for example. In the old days, the validation was server-side. You would fill the form, send it to the server and the server would answer back that you have filled a wrong email. Nowadays, the validation is client-side, before sending the values to the server. And it makes a lot of sense.
I will give you another example from the current implementation. You guys have added EAN as a standard field. Which is perfectly fine. But most of the marketplaces will actually validate that value to be a real EAN and they will reject anything that's not EAN valid. For one thing, it should only have numbers. Not to mention validating the last digit to be the calculated based on the first n digits (depending on the EAN format). I understand there are several EAN formats out there and it's hard to validate against all of them. BUt II hope you see where I am getting at.
It's not hard to add a mask or regex to an input field in the UI. It is a matter of acknowledging the problem and agree to fix it. It will obviously require some more advanced changes on field definition but I really feel that in the end, the product will be better by eliminating potential frustrations of the admin.
What I have learned in these years of selling and implementing solutions is that you might have a very good piece of software that does a lot of complex stuff but as long as the people using the software will not be happy with working with it, they can easily convince the decision-makers to ditch your solution and find another one.
Coming back to your answers, here are my clarifications:
1. Right now, the only client-side validation is done based on simple field type and string length. While for some fields this may be enough, for other fields masking, regex validation or even more complex rules might be necessary.
2. I am not talking about default values. I am talking about a List field that already has 4 values defined and the admin needs to add a 5th one. It should be allowed to add that new value from the interface without editing the field settings in another area. This can be implemented in a lot of ways. I would implement it as a Text field with a virtual list based on the values that have already been populated on that field for the entire catalog. This way, if the user wants to add a new value, he can add it and the next usage will also include the recently added value. But feel free to use any approach as long as it has the same outcome for the admin
3. In some cases, a characteristic might require a minimum value and a maximum value. Like, for example, frequency range. A device can cover a range starting from 40Hz to 20.000 Hz while another device might cover 8.000Hz to 19.000 Hz. And this property is called "Frequency range".
4. Ok. It would be good to have it as standard.
Thank you,
Adrian
