Modern Web Design Demystified

Lesson 26 of 37

Developer Lingo

 

Modern Web Design Demystified

Lesson 26 of 37

Developer Lingo

 

Lesson Info

Developer Lingo

We're gonna be having a lot of conversations. It's important that I give you some context to some language that developers use, that you'll also be using, too, since you're in a production environment. The old way of doing things - you've got everybody familiar with FTP, people FTP things? Yeah. You never have to do that again. Sweet. So, FTP was this idea that I worked on, a static version on my website. I'm like, "Is it ready to go live? Is it ready to go live?" Sweet, boom, button, done. That's cool when it's just one person, one client, one website. But I have 12 developers, I got clients all over the place, I got all these people contributing; I can't use FTP anymore. It just doesn't work. So, multiple team members, we kept overwriting each other, it doesn't work. It's not very efficient and effective when you get really large files. And there's no history and backup sort of built into it by default. We came up with this new method of working, called Deployment, which allows me to...

work not just locally in a static site, but run a server, on my machine. Which means I can run third-party services, like Typekit. Stuff that gets kind of fancy that requires "local host, colon, number." I can do that now, on my machine. And before it gets in front of the public, before it goes straight out to production, I got this, sort of, safer box, called Staging. Staging is not here locally on my machine; it exists out there in the cloud, and only certain people get access to it. Again, the design decisions I'm making here aren't gonna get seen by everybody right away. They get to be tested. They get to be used by people before they go to production. For me, as a designer, it takes the pressure off a little bit. I can work locally in an instance, which is my local copy of the application. I can then push to something that everybody else can help me QA. We can all share the responsibility for making sure it's right, before it flows into active production. So, I'm not carrying this burden of "it has to be right the first time", you know? For me, learning all this stuff really took the pressure off me as a designer. Again, Working Locally, design in-browser, outside services (like) Typekit, Device Preview, from Adobe, works with that. The things that require URL, you can't just look at the file straight up in the browser. Staging Server is a place to do QA. This place in between you and the real world. And Production, is this layer on top where it's available to the public. This other idea that you'll hear about, which we'll take a look at real quick, is Versions. Have you ever done this? "Alright, I think we're good. OK, OK, no, no. I'll make the edits you guys talked about. Sure, sure. Here's the second file. One more time, there's this version of it, where I take out that one little thing that you didn't like. Oh, this other stakeholder had another idea. OK, this is it. Everybody's agreed. This is the final slide. We're not gonna do this. OK, one more time. That's it, though. No more. And let's just, OK. Just a couple more." We don't have to do that anymore. The easiest way to understand this concept of Version Control, is to think of file history in Photoshop. Version Control helps keep our files structured and tidy. We won't have to be creating multiple copies of our files anymore. We're working towards a place where we have a centralized and shared storage of all assets. Services like Dropbox and Google Drive already have a revision history, and there are other services coming online that are going to help us with this idea. Just real quick, this is what Versioning looks like. Has everybody here heard of GitHub or Git? Git is a shared online repository where all developers are working on the code together. It's saving versions based on every save that someone adds to the file. Now, if I go to make a change to this file, I don't want to be in conflict with somebody else. What I'm gonna do, is I'm gonna branch my file from the shared collective understanding of what this file is. Within Git, that's called a "branch", I'm gonna check it out. Meaning, I'm going to open something that exists in parallel to the shared collective understanding of what this final file is. While I'm on that branch, I'm gonna make edits. I'm gonna ask for feedback on those edits. But again, I'm outside of the saved version. Once I have approval, I'm gonna ask that my edits be merged back in. And now, my edits, those saves, those adjustments, are added back in, and added to the collective understanding and agreed-upon status of that file. Again, we don't have overwrites, we have these versions that exist as these temporary instances. Branching is a temporary thread. As I open a file, this is a version that I'm working on at a specific period of time. It does not overwrite. It does not conflict. I am free to make edits to this thing. The only way that I know how to describe this to you currently, is using GitHub. I'll show you a third-party software that allows you to start thinking about this in Photoshop. There's this idea of a Pull Request; once I've made my edits, I ask everybody, "Are these edits OK?" So I'm not overwriting on top of the shared file that's final. I'm not creating another thing. I'm just creating a temporary instance. I ask to merge back in, and then, finally, I can merge that file. Pixelapse is just acquired by Dropbox; it's gonna allow you to start doing this in Dropbox. Any file that you add to Dropbox, you'll be able to save every version of it. You won't have to rename it. You're gonna know that every time I hit 'Save', I get a visual instance, I get a visual cue, that lets me know I can revert back to that last Save. It's a very cool thing. I encourage you to check it out. I just wanted to show you a quick example of the way that that would work. In Git, I've checked in both these files. And Git, allows me to create a diff, which compares both of these files. Again, they're both named the same thing. But I saved them at different times. I've asked Git to compare those two files for me. So, I can see, oh, "Sleeping in Space" was the current edit. We changed the copy, we flipped the image, "Walking in Space." And then, I can approve one or the other. Again, I did not save separate files here. This is the same file, at two different instances in time. Again, I encourage you to look into Pixelapse. Investigate, and just know, this is where we're going. We're getting away from this idea of many versions of a thing.

Class Description

Online web design is not just about choosing fonts, colors, and layouts. The days of throwing a static visual comp over the wall are ending. Designers are now encouraged to work side by side with clients and developers. In Modern Web Design Demystified you’ll learn how to communicate with developers and collaborate with your clients in order to design websites that function as well as they look. You’ll learn about: 


  • The fundamentals of responsive web design
  • Working with Clients to identify and prioritize goals
  • How to communicate with Developers
  • Best practices for project workflow
 
In this online web design course, Andy and Jesse will share real world case studies to help you understand exactly what goes into creating and launching a website from the ground up. They’ll tell you about the tools they use and offer tips on working with everyone from the coder to the client.

High-quality web design is complex, but it gives businesses and orgs the opportunity to really connect with their users. Learn the ins and outs of the entire web design workflow process in the Modern Web Design Demystified course.


Bonus materials include: 
  • Sample Dev Tickets
  • Responsive HTML Wireframes
  • HTML Pattern Library
  • Sample High Resolution Visual Comps
  • and more! 

Reviews

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.