I´m currently planning to develop a software that generates a Product catalogue. The software reads data from the database then apply business logic in order to create the catalogue which will be outputted in PDF.
In order to determine the miniworld -The part of the company that will be represented in the database- and deliver a catalogue applicable by the end users, I am communicating with different stakeholders.
summarized, the expectation of some stakeholders maybe expressed as follow:
I find it really difficult to find out some patterns and to describe a product clearly and uniquely using this illustration. Because of that I would like to share my observations and get some feedbacks about design smells and improvement ideas.
- The characters A, B, C, ... appear as if out of thin air with no explanation. I asked if it is possible to give some self-descriptive property names. As a reply I got that this is common way to mark technical data. I don´t agree with that argument, because if something is very common we can not conclude that it is usable. At the same time I am wondering if the use of self-descriptive property names will make the dimensioned drawing unclear and the table will become more wider.
- According to the rule of logical flow the dimensioned drawing should be labeled from top-to-down and from left-to-right.
- Redundant usage of (mm) in the table header. As a suggestion I would take it from the table header and introduce a foot note which states that the measurements are in mm.
- According to the data in the table: the properties K, L and M do not concern Product No. 1, Product No. 2, ..., Product No. 5. These violates the design principle rule of Grouping. I would create two tables, where the first one containing the tuples of Product No. 1, Product No. 2, ..., Product No. 5 and the other contains the complementary tuples. The same rule can be applied on Product 2, Product 4 and Product 5 based on the property MS, where MS stand for Mit Sensor[in German] translated to English is With Sensor. Would this approach for splitting the table practical?
Could anyone give some suggestions or critiques in order to improve the design. I appreciate any feedback.