I solved an interesting problem - to make a visual editor-configurator of windows.
I will share the details of the development process with you, colleagues.
UPD Added screenshots.
I interview the customer.
1. This is a module for a site that should work in arbitrary popular cases.
2. In editing mode, the program should allow you to specify the number and location of openings in the windows.
3. In editing mode, the program should allow you to specify the method of opening the openings in the windows, five options: no opening, left, right, left and recline, right and recline.
4. In the display mode, the program should display a window configuration at an arbitrary scale.
5. No need to store and work with information about the size, proportions, color and other characteristics of the window. Pictures should be color and clear. ESKD in this case is not the case.
6. It should not be buggy, stupid, it should be cross-browser, it should work on tablet browsers and smartphones, etc.
At this stage, together with the customer, we search through the Google image search interface for similar products. By searching the sites we find sellers of windows, and we visit a dozen sites to look at the interface of online configurators and in general the range of window configurations. We are discussing what should be with us and what should not be.
Now we supplement business requirements with technical conditions in order to formulate the technical task as a result.
1. Based on the requirement of arbitrary scaling - there is an understanding that the graphics should be vector. A cross-browser solution that will satisfy is HTML5 canvas.
2. Obviously, there should be two modes: editing mode and display mode.
3. In edit mode, data should be stored in input type = hidden. I will not make changes to the CMS - why do I need extra bunts? I’ll just add one field to the forms for adding and editing, to the DBMS and to the corresponding models (for me it really happens in one step, if you don’t, it probably makes sense to reconsider the structure of the program).
4. In the editing mode, the previously created visual configuration of the window should be restored from the data located and substituted automatically in the input type = hidden field.
5. In the display mode, the CMSka will give the data as a property of some div, and my program should have this data: a) detect, b) draw a window on them.
In this case, I will not do the specification, but I will follow the path of least resistance. A good part of the vision of the solution is already present, so I will start the implementation immediately.
Harsh programming reality: I don’t want to complicate my life, and therefore I initially create scalable and maintainable solutions. Therefore, DRY, therefore abstractions and layers - right away, by default.
When I looked through window varieties, I sketched a small catalog in a notebook with a pencil in order to understand what was to be drawn. When I did these sketches, the understanding came that I did not want to do this in CSS (probably in vain), and continue to work with