Hi, everybody. I’m super happy to be here
today. And, yes, I can make the best apple strudel in the world. Thanks for the intro.
Yeah. After this amazing key note and kicking off this nice conference, it’s now our chance.
And we will talk about automating UI development. My name is Katrin and I work as a web developer
and a UX designer in Austria. And I’m also one of the organizers of the Conf. And I’m
here with my colleague, mentor and friend, Stefan.
please check it out, let me know what you think. We feature interviews and conference
talks. And so, I guess there’s something in there for everybody. And let me know what
you think. And like Kathryn said, we work at Dynatrace. And I want to the spend just
a few words about Dynatrace so that you know where we are coming from and which challenges
we face and what we’re going to show you today. Dynatrace is in software applications. We
create a software monitoring tool. And we monitor the full stack. End to end. Keep your
stack running in your Docker container on your Kubernetes cluster on your most favorite
cloud provider. That’s a thing. We know what’s going on. And as you have seen from the product
screens, there’s lots of stuff going on. It’s lots of different screens focusing on different
problems and on different problem domains. And that’s how we organize ourselves as well.
We are working in different expert groups. And each expert group is focusing on one particular
problem domain. If you’re talking about more than 600 developers and product managers working
together on a single product which also means a single product UI. And you can think of
that as having the most specialized solution for the current problem you’re working on.
With all those different expert groups and all the things that are going on here, you
can think about your UI as being highly specialized. You can put the problem you’re looking at.
With lots of generic and very flexible components. KATRIN: And as you all probably know, good
UX design means also consistency. And therefore, we are using UI components, for example, files.
And we maintain the four UI components in an Angular components library. So, this is
one of the examples. A screen that we are currently working on. The cloud foundry screen.
And as our UX designers work on this screen, they may come to the point where one of the
core components does not really fit there. And therefore, and for the purpose of this
presentation, we are going to activate the button. So, the first thing the first step
in this process is to talk to the other designers and developers.
Our design team at Dynatrace works cross lab and also all over the world. Which means they
have to discuss all the possibilities for a new button design. They have to make sure
that a new proposal fits the product, but also all other UI components. So, in the end
they decide with which version we will move on.
And the next step is to update all mockups that are currently in the queue and where
they are currently working on. Our design team works with the tool that is called Sketch.
And Sketch is a software to create mockups in UX design. The cool thing about Sketch
is that it uses this symbols library. And the symbols library holds all our UI components,
and everything should be reused in the UI. You could think of it like the Angular components
library, but instead of code, it just holds the visual representation of the components.
And with these symbols, it’s much easier to make sure that our mockup and afterwards our
product has this consistent look and feel. We have the library, so, therefore all our
designers are always up to date with the latest design changes.
And we also have a library as a basis for our design system. Our design system is called
barista because we love coffee. And it holds all the resources for our colleagues. Of course,
also UI components, the core components. All the definitions use cases and documentation.
About all the varieties of a button, for example, a secondary button, primary or icon button.
And also, interactive information and API documentation.
This is a very important and powerful tool for us because it helps us to keep design
teams and development teams together. And therefore, it’s crucial that the design system
is always up to date with the latest design. Now it would be time for some code. But wait
a second. At this point in the process, and that’s also the problem with it. We have no
idea how this design change might affect the rest of the product.
Because in the end there is not only the cloud foundry screen, you can see the other use
cases for the Dynatrace and we have no idea how this will be affected by our code change.
But as we move on and changing the code in our Angular library, this will affect the
product and therefore the whole design. Some of our processes up from the initial
idea we kicked off the whole design process. And we updated all designers with our Sketch
symbols library. And then we got to the code part. We updated our Angular library and therefore
also the product code. The Angular components library as well as the Sketch symbols library
come together to produce the design system. And now it’s time for the process and why
we changed. So, as you probably all know, sometimes designs don’t work out as you planned
to. So, you have to go back. And maybe you have to go back to the initial idea. And if
you’re lucky, you can continue coding. Sometimes this does take too long, and the end goes
directly to the destiny. And yes, there are special ideas, but you don’t know why.
So, this is a broken process, as you can see. This is a waterfall organized in sprints.
And each and every of these steps could and will take it. We have to change this because
this is slow, cumbersome and frustrating for everybody. Most importantly, our design and
Dev teams are never influenced. they live in completely different worlds.
So, now that we know we want to change something, we have this idea of taking the thing at the
very end of our Angular components library and put this in the center of everything.
So, now then when we change, for example, our button color together with our designers,
we can have this change immediately in our design systems and also in the products code.
From there, we could then update our designers. So, that’s the big question. And that’s the
basis of our project we are pretending to be. How could we possibly get these code changes
automatically to our designs and to our mockups? We could therefore use the Sketch library.
As you remember, the library is the basis of our mockup and of our design.
STEFAN: So, yeah. So, how do we get to an automatically generated Sketch library? In
terms of at the very end, focusing on that right now. So, let’s see what we need to create
the Sketch library, a Sketch symbol library and find our way back to the Angular component
library. And I don’t know if you know it, but Sketch is merely a bunch of files, so
we can unzip that, and you can look at JSON files. They are huge. Takes several megabytes,
but if it’s JSON, you know what it means. If you’re a developer, it means that we can
hack that. And that’s actually what we do. So, we are looking for is CSS equivalents
for catch phase. Let’s take the button example because buttons are very easy to reason about.
But make it even simpler and let’s remove the text. Just look at button without any
text. The blue rectangle. And for Sketch, elements are organized in groups. And those
groups spend a frame. Like in this example. The frame has the exact same dimensions as
the CSS that is represented. So, in that regard it is with 120 pixel and
the height of 32 pixel. But with the frame alone, you don’t have any shape yet. It’s
just a canvas where we can draw upon. What creates a shape, then, is, well, layer with
the shape path. So, instead of drawing a rectangle and creating a shape path that spans a rectangle,
it has the coordinates zero to one to one. And we need to apply the fill color. That’s
directly from the background color in CSS. This is a very simplified version of what
a simple rectangle could look like. The truth is a little bit more verbose. It looks something
like this. [Music playing] Yes. That’s quite a lot. But truth be told,
it’s not just CSS properties that we translate, there’s also lots of properties in there that
are specific to Sketch like is this layer locked or can it be transformed? There’s also
some metadata in there. What output and which page is it on? All things that don’t happen
in CSS, but we need for Sketch anyways. Those are default values, we can justify them. Speaking
of properties, those are the properties we are able to parse. And we can packet them
in four different groups. One group would be shapes. So, everything that is respective
to width, height, shadows and borders. And also, for the radius. You can translate into
quantitative in Sketch. This is the first bucket. The second bucket is all about colors.
So, fill colors for SVG, background colors for normal CSS and HTML elements.
We can translate them as well. Third group is all about fonts. Font family, letter spacing,
font size, everything, you can translate that. Also, and the last one, is all about visibility.
Being entirely visible, entirely invisible, something in between, that’s also something
we can translate. And to all those properties we also feature default values. And you can
think of those default values as some sort of browser stack. In the browser, when you
write CSS, you can write properties that are different from what the browser writes already.
And we need certain rules if a shape or group meets a certain rule, we can find it in our
CSS declaration. You can find it there, combine the two things and create the shape. Yeah.
The first thing is done from every element and every CSS declaration, we can create groups
and respective. But that’s not all. Now we know if we have a bunch of CSS declarations,
we can make it fit. The cool thing here is this is fully automated. We don’t need to
worry about that like other solutions. We can round that in our CI and do that with
the commit master. The question is how do we get to those CSS declaration files. And
for that, we wrote too much rules. One is a component demo application which shows a
single component of another. So, just one component which you can look at and you can
parse and then the next one. And those components have a direct reference
to our Angular component library. So, those are the Angular components that we create.
The other thing is the CSS scraper. And the CSS scripter does one thing. It can check
It works particularly well with the web application. But in theory, and in practice, it works with
every web application. This has one particular way, it transverses the DOM element by element
and calls two functions. First, it calls get computer style. And get computed style gives
us all the necessary CSS properties without looking at the cascade and inheritance. The
cascade and inheritance are applied to those properties and you get everything for the
element. It doesn’t have the cascade, it doesn’t have inheritance. We need everything at this
particular element. And we’re also calling get bounding client
rec. And this gives all the information about dimensions with position. And we need that
to form the frame and position in our accounts. We’re doing the same thing also for nested
elements. We have the wrapping element, the wrapping div. We call the same two methods
because, you know, the inheritance, and the test case, not knowing where the properties
come from. Might be nested groups. So, we take this and parse that as well. And
also, nested element. Which also means you can have nested. You take all that information
and send it back to the CSS group. The CSS grid now, I told you that this particular
app is special because we look at every component after another. Every component in detail without
any descriptions. And the CSS grid has another thing, it tells it to update. In the next
step, the CSS scraper calls update. The application loads the old component, loads in the new
and the whole thing starts again. Okay. We’re getting there. Now, we have a
component app and run it to the CSS grid. We get CSS declarations. The generator. We
are almost there. But we are not yet at our Angular component library. We need something
to automate that. We could do it ourselves, manually code it. But you know what happens
if somebody has to do something manually? It never happens in the future again. So,
we want to generate this app as well. And finally, we have it here with our Angular
component library. And our Angular component library like yours is written in TypeScript.
It’s a good feature that’s crucial for us. TypeScript has an API where we can look at
the code that’s been parsed and fetch things out. And we’re doing that with all the decorators
that give us meta information about all the components that you’re looking at. The first
thing that we do is we run the Angular component library through TypeScript. And we get the
syntax 3. It contains the meta information. And from that, we need to get two things.
The example and the varieties of the component. What do I mean by that? Let’s look at the
example first. The few examples, the button, for example,
might look something like this. It’s the simplest and most easy form that a component can take.
There’s no more distractions, and they’re supplied, also with the event handlers, and
you have the markup and put it in your app and you have a simple button. And we’re looking
at the template. We are fetching this basic template. Next, we want to get overran. And
for that, we need to look at the component itself. And the component, it’s a simplified
version of a button and has input decorators. Input decorators, why does the API put this
component? This is our way to change something in the component, get something for that.
In that case, the API is called, and for TypeScript, we know which we are using, primary and secondary.
And you need one more thing from the component, that is the selector. And when the selector
you can match everything in the example with what you have in the component and that’s
how we can apply all those properties and lines to the pure example and generate all
those pages. So, in the next step, you take everything,
combine it, generate simple pages from just one component at a time. We do that for every
component. And generate this Angular application, this Angular component application that we
run from the outside. There we are. We made the full journey from the sketch library,
from the Sketch library to the Angular component library. Again, you can fully automate it.
Going back to Katrin’s example. We made a change, we made a color for our previously
green button. Once this commit happens in Mars in our component library, it kicks off
and the new code is sent to the app generator. The app generator creates the component and
checks the component app and downloads all the CSS information it can find. Every component
where I am. And sends it to the Sketch generator. The Sketch generator does its magic and a
new Sketch library is born. And that’s how it looks in action. This is
a small demo that we recall. You can start it. Now we are generating the application.
The application takes a little time to boot up. Just a little time. And this is where
the fun begins. So, this is my most favorite part. In debug mode, you can see a Chrome.
And we have a ton of libraries. 660, something like that. We are getting the components.
Takes time. But we are fetching CSS for each component. By the way, we can also do SVG
just on a side note. And we generate the Sketch files, the Sketch library, the Sketch symbol
library. The icons, those are button varieties, we have a couple of them And the cool thing is you can take Angular
components inside your Angular components and do the same thing in Sketch. We have Sketch
symbols inside Sketch symbols and we are changing the color to yellow much against the designers.
Yeah. It’s the truth. KATRIN: That’s amazing, right? That’s pretty
cool. Let’s have a look at what this really means for our process. So, we came from this
ugly cumbersome and slow process to something really cool and synchronized. We have this
change that now we have a singular source of proof that lives in code. And our development
and design teams are now 100% aligned with this automatically. Even the names of the
components are the same because they are generated from the component library. But this also
means that we can now verify any design teams. Core design teams immediately and across the
whole Dynatrace set. No more handovers from sprint to sprint, from development to design
back and forth. And we got new contributors. Because now our designers can update their
Sketch files with code. We also have all these code updates immediately visible in our design
system. And all of this brings me to the question, if we can use this with every web page and
every application? Then we can generate our symbols, is there more?
STEFAN: Yes. There is a little bit more. So, we have this workflow where a designer creates
a full page screen mock at some point in time so you goat a feel how the page look like,
which component it has, and this is the initial goal for having it in the product. From time
to time our designers have to make an iteration and put it on the page. Half a year later,
several months later. And, you know, during that time everything that happens in the product
evolves much, much faster and you would always have to start a new one. Because they’re outdated
very, very fast. But with the technology that we have, with the agent that can be checked
into any web page that there is and with information that we have from our Angular components which
translate directly into text symbols, we are working on a prototype that is a small Chrome
extension that affects the CSS agent and sends out data to our servers and creates a Sketch
file to download. And once we open that, wait for it we have
the exact same page. And also, with the construct tech. This also means that we have all the
information about the symbols we are using in our symbol library and the designers can
start with the next iteration. I think this is pretty amazing. Speaking of amazing, there’s
a person in the audience today, Lukas, who is the creative mind behind all that. He actually
worked his he worked his ass off in the last six months to get to all of that. And Lukas
is here in the audience today. And please have a round of applause for Lukas because
he did such a great job. [ Applause ]
All right? KATRIN: Yeah. That brings us to the end of
this presentation. If you have any questions, don’t be shy. Come to us in the office hours
or reach out on Twitter. Whatever fits you best. And it was a pleasure to be here. Thanks
for having us. STEFAN: Thank you.