Deconstructing Web Systems

Apr 1, 2016

–

1:30 pm

–

A pattern language is a method of describing good design practices within a field of expertise. This talk is an exercise to coalesce a pattern language for web development, in particular the discipline of front-end web design and development. It goes beyond the elements that comprise a design system or style guide focusing on the larger system of practices that contribute to delightful experiences for those that craft and code the experiences and interact with our web applications.

This talk is meant to spark a conversation. It is by no means a definite list of all the patterns, that can only be accomplished collectively.

Transcript

Chris Coyier:

A back from lunch. I have a weird hat because every single time I run into Claudina even she takes my hat. So it sucks. It's an amicable trade.

Claudina Sarahe:

I crashed your off vibe.

Chris:

Two people, two ideas, two conferences. You have to hold the button down. There we go. From Dominican Republic. This talked is about deconstructing web systems. A language for web development.

Claudina:

A pattern language.

Chris:

Welcome.

Claudina:

Thank you. Amazing. I don't know if I have room in the luggage for this hat. You may have to take it. Make the slides actual show up. There we go. Awesome. Good afternoon, how is everyone? Super full. We are obsessive design enthusiists. I feel like I could have a thousand conversations with everybody. Huge round of applause for Gina, first time conference. I was with her when she picked the name. It's cool to see this happen. I find it really rad to listen to all the talks how closely aligned all the speaker are in terms of our ideas and approaches to is design systems. It's interesting that in the industry we are seeing a path. But even there is sorta way there are multiple ways, so we get those ways. I was nervous that my talk might not be obsolete at the end of the day. But it not. For context, as Chris pointed out, I worked with Miriam and the oddbirds until 2015. And it was during my time there that I got to solidify these philosophies, about how we work and maintain these systems. And you heard about that yesterday in Miriam's talk. I have been working with pass word. And I took it as an opportunity to acquire systems. I work with a team of 15. And I work on everything from building our processes and documentation, shaping and hiring what we are doing, and setting up front end. There wasn't anything there. The idea for this talk. Destructuring front end or a patterning language. One of the biggest things I have with my team is it's a relatively junior team. I began to think, if only there was a guideline or book I could point them to. And we have these weekly jam sessions to bring them up to date, but there wasn't anything I could point to. And my mom has started to code. And she is working were her H T M L website. And she comes to me with questions, and there are articles in this thing, and this way, and it's really hard to explain to her, the whole system of what front end is, and the different pieces that make it up and how you can and I can choose how to put it together. That would be this talk, about maybe we could develop a language we could use. So turned to architecture. So I turned to Christopher Alexander who talk about patterns. As designers and developers, our surrounding is the web and the industry is the web. Therefore patterns become much more than design T H S and J S. They are a set the practices that we put into place to effectively work together better. So they work with process and tools to the design systems themselves. So pattern language is a method of describing good design problems within a field of the expertise. So this was the first person to talk about patterns. And he is an architect and educator. His career was influential to other fields, notably programming. This is one of his books from the 60s. It was required reading for computer scientists. It helped inspire many programming ideas. Can be traced back to ideas in this book. So O O C S less than six degrees away from Christopher Alexander. You don't need an architect to build things all the time. Anyone can be empowered to do this. When I started working a Casper, and thought about it, I thought what can we do as seniors to empower our teams. The book has 200 and 83 different patterns that he discovered and put together that are meant to create timeless buildings. And the way that you read the book is not from cover and on cover. You pick what you want to do and go through a pattern and from that pattern you either jump to other patterns that it's related to or draw a connection from. So in this way you can develop a network. He intended the book to be released in a three ring binder. So you could add to remove patterns as needed. Now, I'm sure that a wonderful website with hyperlinks would suffice. It shows that he was thinking of something important. Patterns are not dogma, they can change and adapt. So the things we are saying now work well in the context we are in now. But we should be aware of fact that these of a fast moving target. So. What makes up a pattern? In a pattern language, each pattern is comprised of the following metadata. They each have a name, but it also has context which tells you how and when it's used. And when possible, you can try to relate this to other patterns. Problem, what is the issue out there where you will turn to this tool? Solutions, how you can use this pattern, or how we solve the problems in the pattern. And then related parts and an important part, what other things can you check out? What other ideas can you use? Maybe you think you need another pattern when the one you have will suffice. We will work with the naming pattern, that's hard. So the name is naming, I our context, we need a way to identify things. So our problem, we need to identify thing so that everyone knows what we are talking about, having a shared vocabulary that is understood by all is difficult and hard to attain. You can work with stakeholders. Or make sure you get buy in before you decide to name it. And then some related patterns. So do we need a pattern language for front end? This is my question I am posing to you as I go through this talk. For me this an idea that I have been thinking, and I felt, what you person time, here at Clarity conference, and we can share with them, and they can tell me if it's a good thing or stop. Here is why we could benefit from a pattern language. First, patterns are used to formalize decision making values. It's difficult to document and pass on these decisions to novices. If we have a pattern that shows how it works, this is something we can share. Also they are very effective tools and structuring our knowledge and understanding of complex systems without oversimplifying it. And web is a complex system, front end is a complex system, there are a ton of pieces to make it up. Even when we think about J S C S S and design. This forces us to remember that we are working in a system and a system is made up a bunch of other parts and not just one thing so we can keep the perspective and recognize that we are but a small piece of the whole. Design systems to me are part of the language but they aren't the whole language. To me they are a pattern and they describe one subset. There is a much larger system to front end. There is more than systems. Here we go. Pattern language for front end web systems. This is by no means complete. It's in progress. So the book divided patterns into four sections. The organization is to you can help understand and create a logical grouping. But ideally because everything can be related to everything else. Take these with a grain it is salt how these are organized. Here is how you see a language for front end. First we would have our global patterns. These are global development patterns that define the practice of front end for the web. What is apparent about these patterns is they can never be individually designed in one fell swoop. They take a lot of time. They take input from our community and outside of it this include, what I a call temporary autonomous zones. Independent disciplines. These are web guidelines, open borders, and accessibility. Second level are process patterns. These define the philosophy of our work and how we work. So with few patterns would include purpose, planning and management, code reviews, cross functional team. Single origin of truth. Documentation naming and here is where I would put design systems. Because they help inform our process but they are part of a much larger whole. Planning is how we scope our projects. You can put whatever flavor of agile in there. The 3rd is our work space pattern. So tier 3 and 4 is where we as individuals can have the most impact. Because we make these decisions on our own. But if you want to have your team on the same page, I think it's important to set team standards and have them as guidelines. So these include editor, what text editor do you use, your command interface are you using. Syntax highlighting. Key. Shortcuts learning them. GIT and GIThub, how we keep things sane. And configuration and settings, which also relates to things like your editor configure and finding ways to store things and saved and can be easily used across projects. And last we get into project patterns these are the specific decisions we make per project. Whereas work space patterns are ones we ideally make and remain over all our different projects. To build tools, how you want to budgets your dependency, linter, which means not having everything is none directory. Being able to build your project from a bunch of smaller projects of the H T M L template, external data, and then identifiers. Now I would like to show how we have been using these products. And how we did nightshade is by building on top of a new static front end system we call "ando." At a company like Casper we are moving everything over to static. Which excite, which allows us to open our border and bring designers and nontechnical people into our stack in an easier way so ando is a generator and a system. We bake everything into the generator, they don't have to think about it, it's all there, they can work quickly on their features. Back to the idea of patterns. A couple of ideas I had was, naming and purpose. The reason we went with the name "ando." The purpose there should be a why. Why did we name it Ann o. That believes that to change the dwelling, and to change society. Casper, is to change your bedroom sleeping experience is going to change your life. His style so to create a haiku affect. The idea that as we are working in our system, our front end system could change our selves as front end developers and our team and how we work together and it could create a restful and enjoyable process in the process. That was the tone we set forth. Here are some of the patterns from before that we decided to use to remember the ethos of our project. I will talk about the ones I found helpful that change the qualify of the my work. Open borders. The context, working with people across different disciplines. The idea behind this name is to keep the borders ohm we don't want to have silos. It's trying to provide a way for everyone to work on the same code base and contribute their skills regardless of their expertise. So before they had to install tons of thing that's not nice to them, and created a lot of complexity and over head. The solution was to use a system that had minimal dependencies. It was a core ethos that allows us to pick the tools we needed to pick. Ours was static, and it was back to basks. This is bad photo of me and Becky, on her computer, it takes 10 to 15 minutes to get it up and running. Some additional related patterns to this, cross functional teams, the idea of people working together and build tools, are the back bone to the system. Let's talk about documentation. A way to record decisions. Pretty simple. What's the problem here? Code is not self documenting. And we need to capture our decisions and we have a lot of them. People need to be able to find this. Some solutions use community vetted code tools. Pick one place to store the documentation that is easy to access, by all members of the team. And aim for the same standard across the file type. So Sass doc, wonderful tool. And J S doc, and you can use tools like read the docs and GIThub or Wiki. Here are things we are doing, this is an example of the cool thing about Sass doc is it's based on J S doc. It's basically the same style and the same way of documenting. So this is our S C S S. And we can carry that over to our J S. So everything is documented in the same way and same style. So you don't have to learn a new documentation for your file format. Like pressers, H T M L needs a lots of love. If you are not using a templating language, you should start to use one. It can be easily shared. But H T M L is verbose, so it's hard to maintain. We can use a templating language as a solution. Here are some options. Nunchucks, Jade and Swig, and Handlebars and Mustache are common. All these have interesting teach features which allow you to create reusable code. Some related patterns, naming also related to this, documentation, directory structure. Here is an example of how we are using these. Here are two components. We will call this the content panel. It has an image and contents. And we can make a macro called "content panel" which is basically like creating a mix in, and then we can patch in different parameters to it. So this is how to looks in practice. Whenever we want to use the content panel instead of having to write a bunch of H T M L we call and it pass in a title. And the age, image subscription and what with to call it, so it makes it easy. It helps enforce the open borders pattern. And it makes it easy for a designer to come in and say I can edit this myself, I know I want to change the header and content, and I feel comfortable doing that. Directory structure. Organizing and grouping project files. We need a way to do this so it's easy to comprehend and we know where thing belong and we don't have to waste a lot of time looking for the file. What are some solutions? There are traditional directory structure and component directory structure and establishing naming rules singular and plural, and where to put the file in the folder. Traditional directory is there. You usually have assets folder and a separate folder for images and J S and your views directory, you would divide things out based on what that page is. Your home page and your product page. So files are spread all around the app in this case. And Cruft can remain in the code base because when you want to delete one thing you have to remember that that one feature, say the product page, might have some images associated with it so you don't have to grock around a lot to find it. This was a problem for us, we had a bunch of stale code in our product. So. This was nothing new, and in this type of directory structure, is you group all the files and all the pieces of the component within a folder for the component instead of having images and everything in different areas. Your component, in this case, product, contains everything it needs to substantiate inventory, so if you need to delete it you just delete the folder. So it's very helpful, and organized. We have a nightshade core, which we use in our actual app organization we organize our views by this process. We extended it to everything, and it's working really really well. The cool thing about this is when you pair it with a build tool, it doesn't matter where things are anymore because you just tell your build tool where to look. You want to compile everything in the H T M L, and we underscore our partials. Here is an example of recompiling our templates. We have a core directory where we move a lot, as I mentioned our entire design system patterns are in an external repo, so we need the build tool to search there. When we are watching, we, again, tell it where to look, it's not that complicated. It is anymore to logically group things in different ways if we don't have to continue to follow the traditional structures we have had. These are some of the ways they have been applying these patterns to all our work. I'm very curious to see what people think about these. If they think this could be helpful depending on your team constraints, if you want to get into these patterns, let me know, I will be putting up the repo that shares the one I put up earlier. So I would love feedback. Thank you.

[Applause]

Claudina:

Let me get my hat.

Chris:

I don't have that many questions. I was reading back on my code base while you were talking. That was mind blowing to me. I have a C S folder, and you are saying, screw that, I want to component level and that was the first time I have had seen that.

Claudina:

It's working really really really well. I have the one I E style sheet now. And we have extra Cruft in there, and it's ugly, and now I have a little file for the partial I E file.

Chris:

Do you bust it down by pattern?

Claudina:

Yes, exactly for pattern, when we look at our components we believe the that it should contain anything related to it. So you should not have to go looked for it.

Chris:

So you have tabs?

Claudina:

That cool H T M L. Macros is our naming convention, and most of our patterns are macros.

Chris:

And the word macros is meaning executed?

Claudina:

It's a nunchucks pattern for mix in, a way of passing arguments and reusing code.

Chris:

And tabs E S S?

Claudina:

There is an issue that has not been moved into Sass yet, but I believe it will be. Tell abide by the same rules, it knows that that is your entry point. The new Sass file, that that is your entry point.

Chris:

We have been making sure that our entry point is C S S. That's a convention I have used typically anyway. It's a master one, it will require other stuff. That maybe tabs and you keep the I E styles and you keep the sheet in there. It not some master value of I E sheets that is installed in all your patterns?

Claudina:

Yeah so the I E style is

Chris:

It seems like global process works space pattern is a lot.

Claudina:

Work space project.

Chris:

Project, right. Meaning, I don't know, meaning you pick accessibility in global that applies to all your projects? Does is trickle down? In a project you might use a different preprocesser, but they all share the same principals?

Claudina:

The idea is that the global ones everybody can share. If your team decided you are going to make accessible a standard.

Chris:

It's like how you have people's choices mixed in with code choices. So it has, it's a choice of how many tabs you have.

Claudina:

I think more and more, it's we have we make a lot the decisions in code and we are technical people and we work with other people and really become interested in other people and those decisions carry equal weight as your code decisions, and making sure those decisions are sound will govern the end result of your project.

Chris:

People have talked about naming being hard. What is your structure so far in naming? Do you have any philosophy about how you approach it?

Claudina:

As we develop our pattern system, we want to make sure that the language we are using makes sense for everyone. So whenever we are looking at a new design or are going to codify a pattern. And we sit down and ask what do we want to call this things and we have various meetings and then take the solutions WI come up with, and have a jam session, at the time when we want to share things and naming for us goes down to what we call the processes of our macro. We want to make sure everything makes sense. Like a consistent, is the parameter, one we ran into, do we use U R L or path? And then we decided, U R L and path are both different things, semantically, so we want to disambiguating and make it a priority. If you don't have sound names you can't communicate with your team.

Chris:

It's like the end result of this is preprocessers is what you get out is a static bug.

I'm beginning to wonder if we need to have our websites cobbles to things any more. If you have a really nights A T M I. You are good to go.

Claudina:

Very simple and easy.

Chris:

Was anybody worried about this? This is inside baseball stuff. Is anybody worried that you can't have a log in system then? Is Casper, like, 90 percent front end static stuff?

Claudina:

We are mostly, if you look at our website is static, we are going to have we are going to be reading from a content A P I that will have that content, and we will also have a data A P I. It's all A P I driven.

Chris:

Cool. I want to see it.

Claudina:

I can show you after. A different set of dependencies in the world. Best of luck.

[Applause]

Video

Sketch Notes

Transcript