Code Literacy & Developer Tools
Lesson 25 from: Modern Web Design DemystifiedAndy Pratt, Jesse Arnold
Code Literacy & Developer Tools
Lesson 25 from: Modern Web Design DemystifiedAndy Pratt, Jesse Arnold
Lessons
Day 1
1Class Introduction
09:10 2The Design Flow Basics
18:27 3The Designer as Co-Creators
06:48 4Get to Know Your Material
17:07 5Responsive Vocab: Floats, Flows, & Images
11:58 6Mobile First: Working Small
09:46 7Future Friendly: Embrace Unpredictability
14:17Collaborating with Your Clients
13:52 9Prioritize Your Users
39:42 10Best Practices for Defining Success
08:58 11Intro to Scrum
04:24 12User Stories & Epics
35:53 13Content Basics
27:40 14Defining the Visual Language
22:31 15Starting with Type
35:31 16Starting with Grids
15:40 17Gutcheck & The Product Brief
22:03 18Working With Developers
12:33 19Communicating with Developers
16:25 20Finding a Common Language with Developers
06:28 21Code Literacy
04:37 22Sitemap & Wireframe Basics
33:48 23Prototyping Basics
12:02 24HTML Prototypes
13:28 25Code Literacy & Developer Tools
11:46 26Developer Lingo
07:23 27Interface Personality & Behavior Galleries
17:27 28Designing for Performance
18:19 29Progressive Enhancements
07:00 30Designing a System: Discovery to Pattern Library
12:25 31Workflow Examples
20:25 32Applying the Style Guide to the Pattern Library
09:08 33Alternative Workflow
23:04 34Alternative Workflow Part 2
21:52 35Tech Requirements
21:53 36Retrofitting an Existing Site
12:15 37Project Cupcake: Building a Site from Scratch
24:08Day 2
Lesson Info
Code Literacy & Developer Tools
We are in the browser. We are using some tools that actually represent getting closer to what we're actually trying to build. So at this point we get into this idea of code literacy and how that's different than writing code. So Jonathan Berger says code literacy correlates with more sustainable projects and more successful outcomes. I think most modern design shops and agencies encourage their designers to be aware that the things that they're making have to live in a production environment. So let's just talk about what code literacy is and what code literacy is not. Code literacy is reading and understanding short blocks of code, discerning the basic difference between some languages. What does JavaScript look like versus what PHP looks like. What HTML looks like versus what CSS looks like. This is your primary goal. You need to know what HTML is, what CSS is and what the appropriate actions to take. We wanna learn to copy and paste an item and begin to make small alterations to cod...
e. Change some variables, alter the class name, create duplication if you want to sort of iterate on an idea, create a list item possibly. Code literacy is not writing HTML, CSS, or JavaScript from scratch. This is not what we're asking you to do right off the bat. We are not expecting people, your team is not expecting you to write every line of code and describe what it does. Or even read every single line of code and understand where you are within a code file. And you're not contributing code, or responsible for contributing code that's going into production. You're in the sandbox area, where you're gettin', you're articulating, you're playing with the same material but your not responsible necessarily for code that's gonna get in front of the user, ya know, and cause breakage. So again working with a developer, working with code, becoming literate. There's three sort of general ideas I wanna talk about. There's empathy, we just wanna know before you design something it's important to know how hard is this, how difficult am I making somebody else's life. How like on the border between like browsers is this? Having some general empathy just keeps us in check as makers on a team. Material. Knowing the underlying qualities of a language help us frame design solutions and not fight the code. And finally, you're not writing that finish, like same way when we're working in PhotoShop we make a mess, you're allowed to make a mess. You know, you're not writing buttoned up stuff that's gonna straight, you're in there making stuff that's gonna sort of be temporary. Again we got in the browser and looked at some online tools. We looked at CodePen, that introduced us to this idea of the view on the left, the markup on the right. In the top right that's HTML. In the bottom right that's CSS and that's styles, right? So this idea is within this multi-frame experience, I begin to get an idea that's more accurate and closer to how the components within my website are actually constructed and built. So this whole process, we're gonna migrate this idea that we learned into CodePen and we're actually gonna use some code with developer tools in Chrome. And these are three ways of looking at this. First we're inspecting, meaning we're picking a component, we're picking an object, we're gonna take a closer look at it. We're gonna experiment with styling. We're gonna look at the CSS, we're gonna change a value, see that value take place in the browser. That's gonna inform how we QA and have conversations with a developer. Next, we're gonna use emulation, which is built into Chrome developer tools, to start looking at what devices are necessarily. There's a browser built into my iPad, there's a browser built into my Android. I wanna be abLe to look at those devices, and Chrome developer tools allows you to do that. So first up, inspect element. Pretty straight forward. If you use the copy search select menu and you're in Chrome there's an additional element called inspect element, a list item. So I'm selected, highlighted the word Earth, I've right clicked, I get the call out and I'm going to highlight and select inspect element. Just sorta zoom in for ya. Skipping past these standard operations and getting straight to inspect element. What happens at that point is depending how you have it configured to your window, I'm using the right alignment configuration for code inspector. I think by default it might sort of align at the bottom but just, again to show you how similar it is to CodePen this idea, I wanted to show it off to the right. So now my HTML is exposed. I've selected the letter Earth, and now I'm seeing the HTML that is present alongside the view. Here's the really cool part and I kinda wish that CodePen did this. I can select the chunk in the view, and see the relationship to that piece of code. So I don't gotta dig, I don't gotta like ah, don't, no, that's noise, that's lots of things I don't get. But it's this one-to-one relationship, this object relationship that shows me this is the visualization of this piece of information. And that's where code literacy comes in. The bridging the gap between something abstract and between something visual. Next up, so that's the markup of the object. Next up is the styles. It's the window that we expand directly underneath the markup window. This is the CSS. Again I'm gonna highlight and object here, I'm gonna get that object here, and these are the associated styles with that object. This is how these three windows work together. Very similar to CodePen, whereas developer tools gives me more visual queues to let me know what's going on, how they're all related together. And this is where the experimentation starts. So I've, now I've found the color that allows me, that's specific to this element within the view, and I can edit that value and change that value in real time in the window. This allows me to start doing some QA stuff. Maybe the wrong colors were assigned to the wrong elements. I can start investigating which color has been assigned to this element, find the correct color and then have a conversation specific to hero P. The paragraph element, nested within the hero component. That color is what we're talking about. I've been able to isolate the context of this element. The other thing that we can do is we can actually edit font size. This gets a lot closer to what I actively work with the designers. The colors are pretty set, it's usually the font sizes that get bumped around. And usually they get bumped around between break points. So I do a lot of work in this space. So designers will freely edit and make sort of minute adjustments to the font sizes and then send me those edits as they come up with them. And again there specific to this break point, paragraph, I need them to render as 2 M rather than the current setting. Again, I've got the variable, I've got the element, I've even got the break point. I can now tell the developer what's happening where and when, and I can start to have a conversation. Next up, I can actually play around with edge cases and copy. I can not only click in an edit CSS values, I can actually click into the HTML window and like begin editing HTML, HTML content. Again, I click directly within the HTML markup and I add additional text there. Device emulation, there's an icon, upper right-hand corner of the call out for inspect element. I click on that icon and my window changes. It's gone from browser to device emulation. I select from the dropdown, upper left-hand corner, I get a list of devices. This is gonna give me a list of devices. I've selected iPad three from that list of devices. I can change that to any Android device, there are even some smart books listed in there so it's not just mobile stuff. You can even get into network emulation but most of your work is gonna happen in device emulation. Some devices have different orientation. Again, there's a button here within a third panel that comes up underneath the CSS window, this is the emulation window and it's gonna allow me to flip those measurements and again change the orientation in real time, in the view window. It sorta dropped underneath this slide. So again why are we doing this? What's the effective use of this within the workflow? We're doing QA, we're looking at design details and we're ensuring design integrity. We're writing better tickets. We're writing tickets that are more informed by class names, properties, and values. And then we're learning and we're actually adapting. We're learning what the tech can and can't do, our design's not fixed and so we move on. So again I highly recommend that you dig in and sort of experiment into CodePen. Yeah, at this point. I just wanted to add one quick thing to that. So, as designers right? If you start increasing your illiteracy and using a tool like inspector. Now all of a sudden, you're empowered, right? You have this extra ability, not just to be frustrated, being like ah, I just wanna move that thing over just a little bit. You can go in and play, and see cause and effect right there, and it's not going to hurt kind of any of the real code, it's all temporary, ya know? So you can kind of go and play and then that's gonna allow you to kinda give that feedback to the developer. So this is a really kind of important thing to play with that everyone can kind of just dive in, open up a website that you like, and just start to see, you know, how it was made. And just start to kinda change things and see what happens. It's really, really fun. Yeah and basically you can't hide behind this, oh I can't see the code I'm not exactly sure what you're talking about, like you can't do that anymore, you have to like actively embrace yes I have access to the same code you do. Like, it's exposed. You are part of this conversation and I encourage you to kind of dig in and participate.
Class Materials
Bonus Materials with RSVP
Bonus Materials with Purchase
Ratings and Reviews
CityGirl
I've already taken several web design classes, but there were still some details that I found confusing. Andy and Jesse did a great job of explaining things like; programming languages and how they interact to form the structure of a site, work flow responsibilities between team members and the blurry lines between them; and agile methodologies applied to work flow. They used case studies to illustrate how this all happens, where variations crop up, and how to address them. If you're new to web design, or just want to understand the functions of other team members, this is a great real world look at the whole process. I haven't found this in any other class, either on-line or local. Andy and Jesse are both very experienced working designers with current knowledge. They're very responsive to questions and seem to really enjoy teaching. Having two instructors is a great benefit because you get double the perspective, knowledge, etc.
Junko Bridston
I worked with Andy when he was a Creative Director at Funny Garbage, a design studio in New York City. I found him to be knowledgeable, articulate, and lovely to work with. I learned so much from him at the beginning of my career. In response to a previous comment: it seems silly to dismiss this class because Andy wears t-shirts with his blazers. If you think leaders only wear suits and ties, then maybe this class isn't for you. But if you want to learn from someone with loads of experience and a friendly manner, I really recommend it. You won’t be disappointed.
Jesah Segal
From A to Z, this class methodically covers everything you need to know to create a website from scratch. Great class. The teachers are great too.