Joel Clermont (00:00):
Welcome to No Compromises, a peek into the mind of two old web devs who have seen some things. This is Joel.

Aaron Saray (00:08):
And this is Aaron.

Joel Clermont (00:15):
Today we're going to take it to the next step in our How We Work series. We're going to talk about not code yet, we're not there yet. But design and wire framing and why we feel it's important to do that. Before we start diving into the code which as a developer we probably view as the fun part, so just to set some context in case maybe you haven't listened to previous episodes. We're at the point in the project where we've qualified the client, they're good for us to work with, and everything lines up there. We've scoped the project, given them an estimate, it's been accepted. Now you've got your first payment, your kickoff or however you do payments and what's the very next thing you do?

Aaron Saray (01:07):
Start coding.

Joel Clermont (01:10):
Writing on paper. Start coding, yeah that is... Boy, that's where I really want to go but we're going to exercise restraint and we've learned why it's important to actually spend some time doing some up upfront planning, design wire framing. But I guess before we dive into that, Aaron, I want to call out one important thing. I know I said it in the context but I'm going to repeat it for emphasis. This is not spec work, this is not part of the sales process. This is part of the paid work, this is extremely valuable work and the client should be paying for it. So I'm just getting that out of the way.

Aaron Saray (01:44):
Yeah. I think it's important then to kind of define what we're talking about because you made a joke about writing on paper which you might do as part of this process. But really, what is wireframes, mockups, prototype? What are all those different things? I'll also acknowledge that for the sake of this conversation, we're going to define the way that we define it. But it's one of those things where each one of those has kind of little bit of a different definition. It's like when you say unit testing, you're like, "Okay."

Joel Clermont (02:13):
Right, yeah.

Aaron Saray (02:13):
"Unit testing but do you mean unit testing, integration testing, end-to-end testing, smoke testing?" "I don't know, the one that I do." The definitions here really are... We first of all we have wireframe. The idea is that it's really just supposed to be wires sort of defining something. It's single line drawn sort of thing. And now that might be on paper but more likely it's going to be in some sort of tool that draws a black and white representation of your thing. It doesn't have colors, just black and white. It's just squares, its shapes. If you're using a bootstrap input versus a material design input, it doesn't tell you that. It just shows...

Joel Clermont (02:53):
It wouldn't know.

Aaron Saray (02:53):
Yeah, it just shows an input. The concept here is that these are reasonably fast to make and that they can provide the first level of visualization of how a process should flow and what information is gathered. It's not about the designs. So we want to be careful with our clients too because a lot of our clients are more visual than programmers who have more numbers and code in their head. We don't want to distract them with designs, we want them to kind of agree on the whole process and the data so that we can start coding and also then work on the designs, right?

Joel Clermont (03:31):
Right.

Aaron Saray (03:32):
Wireframes are just something very basic and sometimes you have to educate your clients on what actual wireframe is. Then the output of that is, while it's possibly clickable it's probably more of a pdf, sort of thing like that.

Joel Clermont (03:43):
We're not talking specific tools because the tool is less important than the process. But the one we use, the wireframes actually look as if they were hand drawn. It looks like it was drawn with a pencil on graph paper. But to your point, Aaron, it's to very clearly communicate, this is not a final design, this is literally just like the shape of the page and where the information goes.

Aaron Saray (04:09):
Yep. Then when we're looking at something like a design, we move to the next step which is like a mockup, it's called. This is something that's like your wireframe but it's got colors on it. It might follow the style guide, it's going to be much more flashed out, it's going to look kind of like the thing will look. A lot of times in wireframes, you'll have a general idea of what the square shape of, let's just say a mobile view board, is but in the mockup it'll be the actual size of the mobile view port and everything is kind of how it's going to look. There's very different levels of functionality that can happen in something like that, but that's something that you might work on or maybe a designer will work on, or whatever. That's really the next step and kind of says, "This is kind of now the design." It's time to start getting feedback on how these things will look and stuff like that.

Joel Clermont (04:58):
Why would you choose one versus another? I typically would reach for the wireframe first, but can you think of times when you've gone maybe more to a mockup earlier in the process?

Aaron Saray (05:09):
Yeah. I usually will go with a wireframe if it's a brand new project and I have a lot of work to do in SpecOut. Or I might go with a wireframe if it's a project that I've consistently worked on and demonstrated, I understand the styles and the style guide and I don't need to spend the time there. I'll go with a mockup more so if it's maybe either a smaller project that I can pump it out pretty fast or if it's maybe a design change where I'm the lead designer on something, which is not very often. I mean, the other thing is that wireframes are much much faster to create. I mean, you can make arguments about whether you know your tool set or not, but with wireframes you put a box somewhere. And if you put a button, it's a button, it doesn't have which state of color is this?

Joel Clermont (06:02):
Primary.

Aaron Saray (06:02):
Is it a primary, is it a secondary button? It's just a button. So you can kind of churn those out faster.

Joel Clermont (06:09):
One other thing I like about the wireframe is that in addition to the speed benefits you mentioned, it sort of focuses you on what's really important at that stage. Because if you build a full mockup, the customer or the stakeholder might get kind of hung up on like, "Well, why are we using this font?" Or like, "This spacing seems a little weird." You know?

Aaron Saray (06:28):
Yeah, right.

Joel Clermont (06:28):
The details, they're important but they're not important at that stage in the project. Versus, well, what information do we want to collect on registration? Versus, what shade orange is this button?

Aaron Saray (06:41):
Not important enough to hold up the project.

Joel Clermont (06:43):
Yeah, exactly. So those things are important, we'll get back to them later. But for the start of the project, that's secondary at this point.

Aaron Saray (06:51):
Then there's a third sort of level here which is something that can be called a prototype. A prototype might actually be some sort of code that runs, or something that provides interactivity or something like that. It doesn't necessarily have to be code, but it's maybe also not the final products output either. Let's just say you're going to create something in view, you might still use quick HTML and some jQuery or something to throw something together to kind of show what something is going to look like. But that's like a third step, a final step. Especially you're trying to demonstrate the workflow from step to step to step, how things flow. Things like that, which can be always reflected exactly. Things like what type of animation are we going to see? You really can't do that in a flat screen but you can do that with a prototype or something like that. It's pretty rare that we'll do those sort of things but that is something that you might need. Or you might just pick portions of your project to prototype out, to demonstrate.

Joel Clermont (07:53):
Yeah, you pick the tool that you need for that client, that project, and that phase. I know one of the other things we've found, maybe we can shift gears a little bit, to why this is valuable before you get into the coding is... I mean, you could just say, "Well, I wrote a scope document. I explained what's covered and what we're doing. Why do you need to see boxes on a paper?" But some people do need that. I know, Aaron, you were bringing this up before when we were talking about it. That this is something you found value in, just different styles of communication.

Aaron Saray (08:27):
Yeah, there's different styles. Some people are more visual, some more written. Also I'll tell you that none of us actually read everything even when we say we do. Your client is not going to read every... I mean, they'll look at it but they may not necessarily read it. You also have to understand, depending on who the client is too, they have a different mindset. They maybe are not detailed people. We're programmers because we're detailed usually and maybe we don't do good in sales and sort of mentality. They're in the sales positions and they're in the vision positions and all those different things too because they maybe don't work that well with the details. You have to understand there's different types of people, there's different communication styles. But even with the same type of people... I'll give an example. Even when you're Joel and Aaron and you're discussing something and you guys both know exactly what you want to build for like the masteringlaravel.io website, when you actually wireframe it out, the other person goes, "Oh, that wasn't what I had in mind."

Joel Clermont (09:36):
Right, yeah. Because there's a hundred different ways to build a feature so not only is it good to finalize that structure with the client to avoid scope problems or, "Oh, what about this thing I thought I was getting that I'd never planned on building?" But just as the developer it really kind of drives out in your mind, "Here is exactly what I'm building." When you then get to the code, it's a lot easier and it's easy to chunk up your work, maybe even to do some kind of planning. Like, "Here's what I think I can get done this week." So there's a whole lot of benefits for investing this time upfront. In regard to planning, it's so easy to sit down a PHPStorm or whatever your code editor is and just start cranking out features. "I'm going to write some migrations, I'm going to do this, I'm going to do that." But working backwards from a wireframe, it's really a nice way of dividing up units of work especially if you're not the only person on the project.
Maybe, "Aaron, you're going to work on this form. Joel, you're going to work on this form." Or, maybe there's even a complex element in the form that could be broken out and one person could go off and focus on that and the other person could do the boring plumbing work to get that set up. But having those wireframes it's like a visual checklist for creating the tasks and planning it out and I know we're going to get into more detail on how we specifically do our planning in the future episode but just wanted to call that out as another nice benefit of wireframing.

Aaron Saray (11:11):
I like looking at packages of food or just anything. Everyone else is on their phone scrolling through stuff, I'm still that person that goes back to the '90s when we didn't have phones and then you would read the... Well, we had phones, but you know what I mean. We'd read the package of cereal when you're eating or... I don't know if you've done this, but in the shower and we're like, "I don't want to get out of the shower." But also, "What am I doing here in the shower?" So you start to read the shampoo container, you're like, "Oh."

Joel Clermont (11:45):
Rinse, lather, repeat.

Aaron Saray (11:46):
Yeah. And what are all these [ates and ates 00:11:47]? This all sounds horrible and good thing I'm putting that on my scalp.

Joel Clermont (11:51):
You know what? Just to interject along these lines. At a restaurant, nothing to do reading the ketchup bottle on the table too. That's another one that I've... It resonated with me when you were talking about this.

Aaron Saray (12:05):
Well, and speaking of that I don't know if you're like me. But I notice at the restaurants when I go to read the menu, new restaurant especially, I'll look through the menu and read all the stuff in the menu. But the first time through, it's just more for show. Like, "I've never actually seen anything on this menu." I don't know what it is, but I'll look at all this stuff and be like, "Oh." Then I have to be like, "Oh, what do I want? I have no idea what's on the menu," and then you have to go back and actually look at it again. Are you like that?

Joel Clermont (12:33):
A little bit, like-

Aaron Saray (12:34):
Or you're normal?

Joel Clermont (12:35):
No, it's maybe a little too overwhelming on the first pass. Or if it's a place I've been to many times, I'll look at it but I know I'm going to get the thing I always get. It�s like, "Why am I wasting anybody's time here?" But, yeah, I can relate to that.

Aaron Saray (12:50):
Anyway, I'm reading packages the other day and I'm looking at this sort of lemonade MiO type stuff that I have. First of all, let's be realistic, obviously it has artificial flavors because it makes a full tasting lemonade type drink out of four droplets of weird goo.

Joel Clermont (13:12):
Yep, right.

Aaron Saray (13:13):
That's not normal, right?

Joel Clermont (13:15):
Mm-hmm (affirmative).

Aaron Saray (13:15):
So this lemonade has artificial flavors. Then also, and this is just sounds weird, but I was also polishing my table and I was using furniture polish because I've kind of really messed it up with some grease. So I cleaned it off and I'm using furniture polish. I'm like, "Wow, this really smells like lemons." So I decided to read that and it has real lemon extract in it, which I think seems weird that the things we're putting in our body is all fake. Then it's like, "Oh, well this thing." Don't eat furniture polished by the way, but it has real lemons in there. What's going on here?

Joel Clermont (13:52):
Yeah, it seems a little backwards. I agree. Okay, Aaron, one more thing about a restaurant scenario.

Aaron Saray (13:59):
Okay, fine.

Joel Clermont (14:00):
We're going back to that?

Aaron Saray (14:02):
Yeah.

Joel Clermont (14:03):
You are ordering your food and maybe your meal, your entree, comes with a salad. "Oh, what salad dressings do you have?" And they'll list off 10 and you'll always just pick whatever the last one is because there's so many of them. It's like, "I can't even remember the first ones but that last one sounded good."

Aaron Saray (14:22):
Are you looking for 15 tips to make your Laravel project better?

Joel Clermont (14:26):
I can't help you there but we do have a book with 17 tips and the book is free. You can download it at nocompromises.io/tips.