In search of a tool that can minimize the translations of values, in context to UI design space, I was toying with an idea of Ditto, a simplified version of the tool that can look familiar to the different roles involved in the process and at the same time it will align with a process that is about having the same source files at any of the stages of the process and can align with any design system with easy configuration mechanism.
This approach of Ditto was mostly about the conversion to application code via using a controlled configurable UI pattern library serving as the base element for a dynamic IDE that would help to reduce the gaps between the roles.
The idea involved a ‘single source’ based process that can work with standard pattern-libraries/design-systems.
Earlier to this, back around 2013-14, I had experimented with conversion of design files (PSD/AI/PDF etc.) to style guide through prototypes like Specstra as an early attempt to bring automation into design process to reduce the manual intervention around drafting style guides.
This was another different kind of approach, similar to which there are many solutions are available including Adobe Extract and Avocado etc.
Sometime back, while conceptualising the BetaStudio that focused on envisioning the automation aspects to include the usability dimensions of application testing as a part of an automated eco-system more aligned to DesOps mindset, I was playing around OpenCV and its ports in JS that can have a different perspective than my earlier approach to define a set of design benchmarks (the 1st circle in the stages defined in below image) to compare against the models/metrics towards the later part of the stages.
But this time I wanted to explore apart from the two above said approaches, there can be any other practical approaches, which can help building a UI design-automation solution component for the flow. For this I came up with a conceptual workflow “Pattern-AI” that involved some image recognition through a live camera and matching that for potential UI patterns by processing the camera input using computer-vision technologies, as shown in the flow below:
Based on this my set up was very simple, good enough for a hello world type validation of the concept, having a webcam output, being processes through a Kinetic based web application running in Chrome, which tried to identify the matching pattern (a simple image, icon and button ) drawn on the paper to that with a predefined pattern array with those object names. Though I never went beyond just matching the name, it was obvious that as I was able to match a pattern, generating a predefined HTML-CSS code was a piece of cake post that.
This experimentation helped me to later see that possible variation on this line can also be a part of the high level vision of bringing design automation especially in UI design space, like a missing puzzle piece.
However, this also made it clear that whatever, the potential approach might be, finally what we need is a “consistent and scalable design system model” that is essential to ensure whatever is getting translated from the different types of source through any of these various approaches, as that is the point where all these information is getting mapped and the meaning of each pattern is formed.
The basic questions that arise from these were…
When the system gets a clue from the input/source design (or hand-drawn wireframe) as a dropdown, can it consistently map it to a target design system or a pattern-library or even a brand-system based widget-library consistently?
Also even assuming that it does able to identify the pattern, for example as a button , how it can select or define the target implementation code a in a consistent manner? In this example case, a button can be defined as a <input type=’button’ /> or <div id=”button”></div>or even <button></button> etc. ?
This was an eye-opener, as it was clear from this that, irrespective of the technology used, and irrespective of the methodology is used to generate the required information for design benchmark, without the essential “common language” among the design-systems in use, the translation of those information/artefacts might not make sense to the systems running the automation. And this is where the whole purpose of DesOps mindset will fail.
This actually hints on a problem statement about the gap that currently our design systems have — i.e. a consistent way to define the patterns (and note this is not just limited to UI focused design-system) that can be scalable, and coming up with some approach to bring “semantics” to the design-systems in focus.
We will dive more into it in next posts. Meanwhile you can explore these links:
Previous post of this series: https://www.linkedin.com/pulse/open-design-system-adding-semantics-part-1-background-samir-dash/
Nuclear Design: https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-2-nuclear-model-samir-dash/
Open Design System Ontology: https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-3-open-ontology-samir-dash/?
(c) Samir Dash, 2018. All rights reserved. This content including the images are licensed under a Creative Commons Attribution 4.0 International license
#nucleardesign #design #desops #designops #designsystem #opendesignsystem #odso
One thought on “Open Design System – Adding Semantics to Design System (Part-2): Roles of Pattern Library in Design Automation”