September 2018 – DesOps .IO

Open Design System – Adding Semantics to Design System (Part-3): Heredity and Inheritance of Attributes

Posted on September 10, 2018 by Samir Dash

The word “evolution” was first found to be used around 1647 which was more popularised by the Naturalists towards the end of 18th century who upheld the age old pre-socratic Greek philosopher Anaximander’s view that humans must have evolved from an animal and this evolution must have sprung from sea. From Darwin’s theory of evolution, we see two important characteristics :

In the eco-system the individuals of the same species are likely to differ in their measurable characteristics
Such kind of variations are inherited (heredity).

For any complex and growing (evolving ) echo-system when we try to find the model to explain the behaviour of evolution, these two characteristics helps build a model that can provide meaningful reasoning behind the complex variations that exist.

Darwin’s The Desent of Man was more focused on hypothesis that variations are transmitted from parent to the off-spring, though it was a few years after established.

During mid 19th century, Gregor Mendel’s extensive pea-plant breeding explained and came up with a meaningful model.

This model was able to interpret and explain Darwin’s hypothesis around heredity, where it toys around the questions such as —

“is it possible that an animal having, for instance, the structure and habits of a bat, could have been formed by the modification of some animal with wholly different habits? Can we believe that natural selection could produce, on the one hand, organs of trifling importance, such as the tail of a giraffe, which serves as a fly-flapper, and, on the other hand, organs of such wonderful structure, as the eye, of which we hardly as yet fully understand the inimitable perfection?”

The natural life-forms and their associated complexity of variations, basically, was well explained by the model of heredity. The moment we envision a design-system that can explain the variations in life-forms, it would be no surprise to be in similar lines of what Darwin had deduced. In the similar lens, when we take the case of any design-system, we see similar attributes. The variations of any entity can be explained with inheritance of attributes from parents.

Irrespective of the typical design system maturity level, in order to make a design system scalable, it should have this very characteristic of having the model to define variations and inheritance.

In typical sense of “design system”, as we refer in our day jobs in techno-design industry revolving around software application and related eco-systems, we face the use-cases that are the tip of the iceberg of the operational problems we face in a design process. The activities like, the categorization of UI patterns and mapping them to the user interface needs, manual export of the semantics while different teams work on different tool-chains especially in open and collaborative design scenarios along with long hours of religious debates” of the utilitarian values of widgets proposed to be used against the variants that are in the implementations, are some of such examples, which has become the part of the job, where unaccountable time, effort and of course organization money become under-utilised.

Design System help generalize the the diversified aspect of patterns we use in design. But, the offshoots of the design systems across the industry, to cater to the need of the individual organisation, who are developing them, are not solving the issue of bringing a normalization, rather they are making it more distributed. There are no two design systems that are equal in structure or in the approach they follow to define the patterns in them.

So the “design system”s which are supposed to be a “common-language” for their respective design process that every team member can adhere to in order to produce a consistent design, do not have a “common language” among themselves.

Along with that, none of the design systems, as of today has a model that can help explain any other design system. Even, the basic smallest pattern or the building button, they define, does not explain the variations we see across cross domain, organization and technological context.

A simple case of a “button” pattern, does not seem anymore simple, where we try to connect the dots between the variation we see regarding that.

For example how is a button different from that of a toggle button, or a text-link or a simple radio-button? Even a simple hyperlink with some background color and cursor properties can cloak itself as a mental model of the user defining the concept of a ‘button’. Also the technological dimensions to variation can span beyond the technology used, platform it is rendering and the framework or language in play.

This is a perfect example even in such a narrow definition of a design system (i.e. a pattern library for UI or a basic brand-system or style guide), how it is fit case for the need for a model to define these variations and inherent relationships among the entities to explain in a logical way how these variations are linked to each other.

(Fig. Ref: https://www.linkedin.com/pulse/desops-prepare-today-future-design-samir-dash/)

When I think about the Design System, it’s not limited to the UI or brand library typically that we refer and try to define, rather, being a part of DesOps mindset, where every organization is a Design Organization (as every organization is in employing creativity in solving the problems for its customers through its products, services etc. ), it spans across and touches different and diversified domains, technological dimensions and information spaces.

(Fig. Ref: https://www.linkedin.com/pulse/desops-prepare-today-future-design-samir-dash/)

For example, a design system can be a knowledge system for system design meant for developers, technical architects, data scientists. Similarly, a design system can define the elementary components and practices for process design – e.g. the elementary blocks of a Design Thinking framework like that of IBM Design Thinking framework can be explained and built using such approach. Or the design system can also cater to the need of the intersection of specific industry need and technological domain at the micro level — e.g. a design system that can define the model for a color system needed for specific type LED monitor manufacturing industry. In all these scenarios, the task becomes critical to define a model that can stand for this “universe” what we refer as a “design system”, where we can branch out or fork and build the shared meaning that can span across all diverse disciplines, domains, technologies and methodologies.

(To be Continued to the next post)

Previous post of this series:

https://www.linkedin.com/pulse/open-design-system-adding-semantics-part-1-background-samir-dash/

https://www.linkedin.com/pulse/open-design-system-adding-semantics-part-2-roles-pattern-samir-dash/

You can also explore the following links:

‘Semantic Design System : Redefining Design Systems for DesOps’ https://www.slideshare.net/MobileWish/semantic-design-system-redefining-design-systems-for-desops-v10-1sep-2018

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/?

Open Design System – Adding Semantics to Design System (Part-2): Roles of Pattern Library in Design Automation

Posted on September 9, 2018 by Samir Dash

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/?

#nucleardesign #design #desops #designops #designsystem #opendesignsystem #odso

Open Design System – Adding Semantics to Design System (Part-1): Background

Posted on September 9, 2018 by Samir Dash

“Design System” plays a critical role in bringing a common language and consistency in experience across different products and brands of the organisation, along with fuelling a collaborative approach towards design, making it easier for different team members to contribute.

Take an example of a representation of information in a tabular form. In HTML, the desired table element does the basic thing work. But most of the real-life sites, utilize the responsive frameworks like Bootstrap, and on the course, they mostly use the framework versioned table component. For advance controlled display, some may use extended components based on the framework, e.g. Bootstrap Datagrid. In some cases due to the need for the two-way data binding and similar needs application might be running Angular JS driven grids. Some other might prefer using some niche components like Data Tables. In many cases, there are hybrid of niche components married to specific frameworks, for example, the Data Tables with Bootstrap 4.

This actually shows how diversified is the form and the usage of components or the UI patterns. When such things happen, the amalgamation of associated design systems takes place. The target design system attributes, directions are used to customize and in the process the guidelines based on which the external components, interactions, patterns and style are changed.

The power of design systems should lie in the fact that they can establish a common, publisher neutral platform integrating distributed computing as well as design eco-systems.

One of the barrier to wider adoption of SWS technology is the lack of tools for creating specifications that can help consumption as well as comprehension of the design systems at large by the systems without much direct human intervention.

The one of the major way out for such a future is using RDF or micro-data formats to define the ontologies through formats like OWL, RDFa etc.

The success of the Design Systems lies in their abilities, in becoming a part of the distributed brand as well as design system, where any of the components or aspects can be extensible. Also the sustainability of the designSystems lies in the fact that they need to be migrated to and converge with any other design system. In the future of design operations, its highly possible in the world of CI&CD, the design systems should be able to be translated from one brand system to another effortlessly without the single human-intervention.

So what’s the way to achieve it?

The solution lies in Semantic Design System. Semantic Design System, is the future. Like the Semantic web, the goal of the Design Systems is to translate from one form to the other and ensure the machine readability and comprehensibility drives the structure and how the design system is fleshed out.

This is also, critical for open design systems, as the typical effort behind such systems is to make them available as more common set of patterns that can be adopted, used and extended by any other brand system. But as we diving towards the world of hybrid design systems, where the aesthetic as well as interaction enablement through CSS, JS frameworks are founding pillars, it is essential to provide a commonly used language that can define the basic relationships among different entities of a design system. The way forward is a design system defined in terms of a shared language or an ontology.

An “Open Design System”, as I envision, is the one that addresses this issue, and focuses on building a design system, that is equally human-readable for collaboration and at the same time understood by the machine by being a “Semantic Design System” for the next generation of design operation with automation, machine learning and artificial intelligence. The talk also introduces, what I believe as “Nuclear Design”, a modelling approach (I will expand on this one in coming part of this series ) that helps to lay out a framework that is the foundation for building design systems with semantics.

The semantics of the ontology can be used by the machine learning or AI systems in a similar manner how it currently uses the data modelling using the graph databases. This opens up a door to the future for the design that can support DesOps (aka. DesignOps) in organisations.

The Graph Data Model

The semantic web uses the graph data model to store data, RDF is the format in which it is written.

(Fig. Source: http://www.linkeddatatools.com/introducing-rdf )

In traditional data bases there are some kind of important elements against which the relationship is defined. In traditional data bases there are some kind of important elements against which the relationship is defined. uses graph structures for semantic queries with nodes, edges and properties to represent and store data.

Welcome to Open Design System Ontology (ODSO)!

(Continued to next post. )

Meanwhile, you can explore the following links:

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/?

#nucleardesign #design #desops #designops #designsystem #opendesignsystem #odso

Semantic Design System (Part -3): The Open Design System Ontology

Posted on September 3, 2018 by Samir Dash

[NOTE: Check the part 1 at : https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-1-gaps-todays-samir-dash/ and part 2 at https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-2-nuclear-model-samir-dash/]

This originally part of a talk I gave at UX-India Pre-Conference Meetup at Symbiosis College, Bengaluru on 1st September 2018, titled: Semantic Design System — Redefining Design Systems for DesOps . The talk explored the existing implementations of design-systems and will be making an attempt to provide high-level approach to define design systems for the next-gen enterprises.

(Continued to next post. )

#nucleardesign #design #desops #designops #designsystem #opendesignsystem #odso

Semantic Design System (Part -2) : The Nuclear Design Model

Posted on September 3, 2018 by Samir Dash

[NOTE: Check the part 1 at : https://www.linkedin.com/pulse/photo-essay-semantic-design-system-part-1-gaps-todays-samir-dash/]

(Continued to next post. )

#nucleardesign #design #desops #designops #designsystem

Semantic Design System (Part -1) : The Gaps in Today’s Design Systems

Posted on September 3, 2018 by Samir Dash

With observation of design systems, we can notice, almost all of them are having different structure and approach to define these, and almost none of them can be directly used in automation of design as they are not semantic in nature. Therefore most of these current approaches to design systems are not future-proof for tomorrow’s design operations (DesOps). Here I coin the “Semantic Design System”, that address this issue, and focuses building a design system, that is equally human-readable and at the same time understood by the machine for the next generation of design operation with automation, machine learning and artificial intelligence. The talk also introduces, what Samir believes as “Nuclear Design”, an modelling approach that helps to lay out a framework that is the foundation for building design systems with semantics.