Node.js Node+JS Interactive 2018, 19 Oct 2018

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Bridging the Designer-Developer Gap, PWA Edition - Antoinette Janus, PBS Kids

Description

Bridging the Designer-Developer Gap, PWA Edition - Antoinette Janus, PBS Kids

Progressive web applications are all the rage. React, Vue, and Angular dominate the developer field. Recently, Safari announced support for web manifests in their browser, Chrome support pre-existing the announcement. Job postings require developers to know some level of a web application framework. With all of the mentioned buzz around PWAs, developers strive to include these technologies. Problems lie when communicating this excitement and necessity to designers. This panel shares knowledge about what a PWA is, why they matter, and further why they matter to designers. This talk covers the broad strokes of performance (such as first paint, asset management), a brief walkthrough of a web manifest in terms of a designer, and how website audits (such as lighthouse, sonarwhal) are mutually beneficial to both designers and developers.

Antoinette Janus
PBS Kids
Software Engineer
Woodbridge, Virginia
Twitter Tweet Facebook Message
Antoinette Janus is a Software Engineer at PBS Kids. Outside of work, she is working on multiple projects, including a headless WordPress x React client portfolio rebuild, Daily_ToDo (Electron x React), and many small-scale projects including her Zelda Music Maker (https://acjanus.co/zelda-song-generator/). While she has no conference speaking experience, she co-organizes and regularly presents at CodePenDC, has previously presented at DC's API meetup, and multiple other JavaScript meetups.

A

So today, we're gonna be talking about a soft skill that is very underappreciated, which is we're taking the gap between developers and designers and how to talk about web apps to designers, which is one of the most difficult things to do at this current time.

A

So what we're going to be talking about is a very brief definition of what a web app web app is how web apps in design systems coincide with each other and documentation, which is one of the most important things.

A

So what about or what are they we're? Gonna go by Google standards, which are they are fast, reliable and engaging.

A

So what does that mean? That means responds quickly to use their interactions with silky, smooth animations and no jinking rolling.

A

Reliable reliable means that it loads instantly, and always even in uncertain network connections apostles' whatever there is, is or is not data available. It has an empty state when there is no data which we can see here in the visual studio code example or prefecture and engaging means, it feels like a natural app, the independent of the device, and you have an immersive user experience which we see here in Gmail.

A

So, in the end, the product should provide a similar.

A

Should provide a very similar experience, no matter what you are using, which we see here.

A

In Google Docs, which is we see that they are all very similar through everything.

A

So how do we accomplish this uniform feeling across device.

A

Through something called Design Systems going off of Scott column, a design system is a collection of objects aligned by shared principles in aesthetics, so that they may seamlessly work together to form artifacts that provide user value.

A

So wait a minute collection of objects that sounds vaguely familiar something in web apps. Specifically when using things like frameworks, though, as web developers, we use regularly.

A

In that thing, sorry, the wrong direction its components. So this is where front-end frameworks in design systems overlap in the definitions aren't all too different.

A

Both designers and front-end developers think of components in terms of a larger part of a larger product, whether that product is a native app web app or static sites. In this example, in code pen, we can see that a single project is the same thing as a component of a larger project.

A

We can see how this could easily help make things help developers develop faster, while maintaining brand guidelines and provide fluid familiar user experiences by removing unnecessary surprises by remaining consistent or ever used.

A

In terms of components, think of a button.

A

We have an event buttons always trigger events. Well, usually, or they did it. Take you somewhere a.

A

Button should have consistent styles, we here and here we have a background: color font, color font, family in font, styles.

A

We have multiple states. In this example, we have a button that is enabled and potentially a button that is disabled in these states should be consistent and recognizable.

A

So we can see multiple aspects go into one button. So where do we store this information? How do we share it?.

A

That is where documentation comes into place. Documentation has two forms.

A

Documentation for Web Apps has a web manifest, which we saw in the last presentation and designed to some documentation both our locations, that we monitor by both design and development teams. So in this list, let's start with a brief overview of what a web manifest is.

A

We're gonna go with the Google definition by Matt, gaunt and Paul Kinlan. The web manifest is a simple JSON file that tells the browser about your web application and how it should behave when installed on a user's mobile device or desktop.

A

In here we see there's a brief example of what a minute.what manifest looks like it documents how a site behaves across multiple devices, including the behavior of favorite, columns, theme, color and background color.

A

So favicon we'll do a brief overview of those three things. It's in a way to list multiple sizes for your icon house, with a cross-browser and cross-device theme, color most noticeable when looking at the address bar went on a website, especially in Android background color property use on a splash screen when the application is first launched. In these examples, I use my own personal site to show different combinations of how these three aspects and what site manifest are in action. In the first example, we see a favicon, which is the a we have.

A

The name which is at the bottom, is in a background. Color. We can see the theme color here in the middle example in the top bar, which matches the color of the site. We see the favicon in theme color in combination with this third example.

A

Documentation where do this is where the designers get to say they do and do not do nots of component use. It helps developers create reusable components based on design standards. It also holds both design, designers and developers accountable for everything that they work. On.

A

For example, we have a designer that introduces a new loading state, but it's not in the design system developer. He gets the same. Sorry, we can't do this. We don't have the brand guidelines that say that we can do this. It's everything I think almost every developers, favorite thing to do is sell it. Does that or no, but on the other hand, a developer introduces a new interaction functionality. It that's also not documented in the design system. Designer gets to come back to you and say: hey.

A

We don't have this documentation. This is not how this is supposed to function. So let's go look at that documentation again and see how this should actually be reacting.

A

This is where design documentation comes heavily into play. Design, documentation, describes the look and feel of components. This explains how components should and should not be used, how they react in different points of a product, as well as everything that they cannot be used for designers and developers get a document document a site-wide styles such as brand colors, typography and animations.

A

Here we have the United States web design system. It is considered one of those standards for web design documentation as we can see in the example here we have a multiple uses of the different components that go into a design system and web apps.

A

And this is a living document. Developers and designers should both maintain, as we were talking about before components. This is a great example, a great place where we can show uses and code examples.

A

We could show screenshots or box of what it should and should not look like. We could document all associated CSS classes, whether those are utility classes or just visual classes. That should be used, such as the border-radius.

A

We can document pre-existing, use examples if it's an internal design system or have an internal list to reference. We have a new component kamijo. Let's see what else is like that, we can also list possible component combinations and list any internal restrictions.

A

We have a new video. Well, we decided the videos are no longer in modal's cool. We introduced a modal. We now have an idea that this is not a good combination, because we've had this conversation before.

A

And in an earlier example, we can see where to document we see the functionality, we see the Styles, we see different use cases.

A

Functionality, as we said, can trigger different events. Here we have it where it's showing a drop down if it would be Styles, as we talked about background color, color and font family and anything related to the typeface, any use cases we've enabled and disabled well. This looks like a CTA call to action button, so maybe we don't use buttons. We were using links, that's a whole different thing.

A

So all in all, we have a basic requirements of what a web app is. We have what a design system is. We have components that are the commonality between developers and designers.

A

We can showed how documentation helps bridge that gap.

A

And thank you and now I have time for Q&A. If anybody has any questions.

A

A

So this process of a design documentation is that's why it's a living document. We allow for multiple edits, based on who, whether it's a designer order, the developer and overall, it's something that, because of how long a lot of processes take in terms of accepting a new concept, we will be aware early on. This is why it's important to bring in developers and designers at around the similar time period for each new feature.

A

It depends I for us, we have for Mike my work. We have bitbucket documentation, github documentation, but we're also working on a and there's a standalone interactive site just for the design system, documentation, which is where you would show code and design examples.

A

Mm-Hmm yeah, it's important to when talking with the documentation, though it's important to bring in developers into these conversations so that you could have both code examples and design examples that way developers know these products and this project exists so that they know that they too are contributing to this living document.

A

Any other questions no well I will be around. Thank you.