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