Skip to main content

Developer Lingo

Lesson 26 from: Modern Web Design Demystified

Andy Pratt, Jesse Arnold

Developer Lingo

Lesson 26 from: Modern Web Design Demystified

Andy Pratt, Jesse Arnold

buy this class

$00

$00
Sale Ends Soon!

starting under

$13/month*

Unlock this classplus 2200+ more >

Lesson Info

26. 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 Materials

Bonus Materials with RSVP

Syllabus - Modern Web Design Demystified.pdf

Bonus Materials with Purchase

Froont.com 60 Day Free Trial Coupon Code.pdf
Ministry of Space Sample Dev Tickets.pdf
Ministry of Space-Sitemap.pdf
Modern Web Design Demystified Resources.pdf
invision.com 6 Month Free Trial Coupon Code.pdf
Ministry of Space Product Brief.pdf.zip
Ministry of Space-FONT for Use with PSD Files.zip
Ministry of Space-Layerd PSD-Desktop Version.zip
Ministry of Space-Layerd PSD-Mobile Version.zip
Ministry of Space-Layerd PSD-Style Guide.zip
Ministry of Space-Sample Site-HTML Wireframes.zip
Ministry of Space-Sample Site-Pattern Library.zip
Ministry of Space-Sample Site-Responsive Home Page.zip
Ministry of Space-Sample Site-Thumbnail Wireframes.zip

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.

user-3d865b
 

I was looking for a class that would not only address the web design basics but also their place and function as part of a workflow. This class did not disappoint and Andy's and Jesse's engaging presentation style made it easy for me to follow along during the 2-day live session. By using real life examples, the presenters provide plenty of tips and strategies how to best work with clients and developers alike — the many, often intangible ingredients that go beyond technical expertise and can make or break a project. Highly recommended.

Student Work

RELATED ARTICLES

RELATED ARTICLES