Tsilli Pines & Mark Hoffmann

Digital Creative Director, and Director of Interactive Technology at FINE

Tsilli Pines & Mark Hoffmann

Digital Creative Director, and Director of Interactive Technology at FINE Episode 28 Part 2

Episode Notes

Episode Transcript

Gary:
Hello, and welcome to Part Two of Episode Twenty-eight of Design Edu Today, the podcast series discussing topics concerning the state of interactive design education at institutions of higher learning. I am your host, Gary Rozanc, Assistant Professor of Graphic Design at the University of Maryland, Baltimore County.

In part two of this episode we continue the conversation by discussing responsive web design and the web as a medium in contrast to print design.

Gary:
All right, so, as I mentioned in the previous episode, I’m also re-vamping my Responsive Web Design class. I used to teach it as a Front End Development class where students learned HTML and CSS and how to implement basic Vanilla JavaScript plug-ins. The problem with this approach is it didn’t leave any time to discuss visual design with the students because it took all semester for students to get even a basic understanding of Front End Development and so then I flipped it and I tried teaching the course focusing on visual design using tools like InVision or just last semester, Adobe XD. However, this had the inverse problem where they really couldn’t critique or test their designs in a browser: it’s sort of like students having…having students create a poster and they print it out, they put it on the wall and they can critique if their typography is really working, as opposed to staring at their tiny little laptop, or vice versa with a business card: it’s huge on the screen but it’s small in real life. So, my first question is, how do the visual designers at Fine go about creating designs and then testing them in the browser to ensure that the typography is appropriate, that their grids are responsive? How do you handle that conundrum, I guess?
Tsilli:
Yeah, that is a tough one! The truth is that we really rely a lot on designers coming in with that knowledge because there is a very involved process here in terms of getting something from Photoshop into the browser. We are not a shop that starts out wireframing in the browser and developing content in the browser and then styling that and evolving it. We work very much from visual design to code and as a result, we stay in design files for a very long time before they get translated into the browser. We have a very regimented process for delivering our designs to the development team and so I guess what I’m trying to say, it’s specifically in response to this question is, we have designers who already can envision how their design is going to translate to the browser and they’ve built up that experience by having smaller stakes projects that they themselves have seen translating from one medium to the other or have started out with a very painful experience where they were wrong, but really we assume that a designer can think in Photoshop about how something is going to work in the browser and that is, even for highly skilled and very senior designers, a tricky scenario where we do get into these situations where you’re in development and something that you had thought through in terms of the break points, something that you had thought through either in the grid or the way that the type was going to respond, or whatever, is actually working great at those break points but then there’s all this stuff in between those break points where you…Photoshop is not a good tool for thinking ahead to what’s going to happen if you’ve designed at seven sixty eight and you’ve designed at three twenty; what’s going to happen at five fifty?

So you have to get really good at foreseeing all the gotchas, of being like, wow, if I have a square image and I’m assuming that that image is going to stack at some point, it’s going to be really tall once I get to that weird little moment where it’s going from tablet to mobile and there’s going to be an awkward period where everything is going to look completely out of proportion and I should plan for that by designing my mobile solution a little bit differently; that a super-advanced series of anticipatory design moves. So I guess the short answer to your question is that there’s not a very good way for designers here to vet their designs in code until we are very far downstream, which assumes that they have had the experience of seeing what designs do in the browser, so it would be really good for your students to learn the ramifications of a digital context: whether that means that you’re doing it in your class or it means that they’re working with a developer who can translate their stuff and they run into something working side by side with somebody. I don’t think there’s an answer to how to do all the things in class. But as far as the skill-set that we’re looking for, for your students coming out of school, they would need to have a pretty strong understanding of how a design file translates to the browser without seeing it coded.

Mark:
Yeah, and there’s an inverse to that as well with the developers that we hire. They’re expected to be able to do something similar from the other angle, which is predict whether or not a design is going to present them the challenges that it will and if it looks like it’s going to be challenging enough, we might then choose to spin out some time for prototyping and ask for collaboration between the designer and the developer earlier in the project than we normally would, or something along those lines, if there’s a scenario where we legitimately must see some behavior in a browser. Typically, we get multiple people involved; it’s not always that way. If we have a designer that wants to take the time and has the time available to experiment with code in the browser, they can do that but usually we’ll bring in a developer for support who’s most likely already attached to the project and can say, OK, this part of the page we understand what it’s going to do, those things will stack the way you expect, but this part is complex and we’d like to build out a prototype to see how it will react to someone changing their browser size or looking at it on their phone or watch or whatever!
Gary:
This is the hard part: you have to teach them…you have to make them aware of what they don’t know! Without saying you don’t know what you don’t know and it’s just…it’s really hard to overcome that, but one thing, and I’d just like to ask your opinion on that just occurred to me from listening to your response was, when I teach HTML and CSS, I teach it from a perspective of success; that if they follow these steps, they are going to successfully complete something. I’m wondering if it would almost be better to have it be from a point of failure, have something that they think should just work but then me in the back of my head is like no, it’s just not going to work. Maybe give them a visual design and say, here, try to mock it up in the browser and so they can see that, oh, what I designed doesn’t always necessarily work. Does that make sense?
Tsilli:
I think the biggest learning moment is if they themselves design something that doesn’t translate the way they were expecting and then they have to figure out a solution that will achieve what they were going for but be different than what they were originally envisioning. I think for developers, it’s useful to get a design and try to implement it and see what’s hard about it but for designers, it’s actually the most beneficial part is being the one who designed the thing that didn’t work: there’s no quicker way to learn that skill that we were just talking about of being able to think in a vacuum of code than to have had a really traumatic experience that something you thought was going to be awesome…so yeah, for you it’s tough because there is so much to learn, there’s so many things, you would need so many different kinds of classes to be happening concurrently to teach all the skills in one coherent semester: a class about HTML and CSS I think is actually really great for designers and to try to implement really basic things but in addition, you would need that class running concurrently with it that was trying to solve a design brief and having things that they’re learning in that coding class be coming to mind as they’re doing that, plus the thing that you were talking about before of maybe trying to get them to get to the design brief in the first place; those things are all courses in and of themselves. You can’t do all of those things in one class.
Gary:
And unfortunately, the way most curriculums are built is, they’re already pre-existing print design programs…
Tsilli:
Of course.
Gary:
…and then they just cobble in one or two web design classes and we’re trying to teach all of that in these one, if we’re lucky, two classes…
Tsilli:
It’s crazy!
Gary:
Yeah, that’s the point of this podcast it’s like, OK, I’ve got to find the balance in what little time I have. But thanks for saying that!
Tsilli:
I mean, it’s true; I think graphic design and design for the digital environment, both have a lot of core design skills required but as far as a trade, as far as what you are doing on the ground and the production problems that you are trying to solve creatively along with all of the concepting and all of the other things that you’re doing, they’re two pretty separate tracks; it’s a different medium and it has different challenges so I do find it frustrating watching academia just kind of miss the boat on how different these two things are. I went to school for Graphic Design and I learned layout and type and knowing those things is enormously helpful for the digital environment, of course, but nobody taught me how to do all of the other things that I had to teach myself because at the time there was no infrastructure for that and the state of the art is evolving so quickly, so constantly, that it’s very hard for academia to keep up with it. But also it’s come to the point where it is a robust curriculum of its own so it’s very…you have a very hard job, is what I’m trying to tell you!
Gary:
Thank you! And this leads perfectly into the next question. I still think visual designers need to learn HTML and CSS because they need to understand the medium they are working on, which is a heck of a lot more complicated than understanding ink, paper and the different printing processes. From your experience, stopping short of producing the mythical unicorn, how much HTML and CSS would you like to see your visual designers know, can you give specifics?
Tsilli:
Yeah, well I think that what you were describing earlier from what you were spending most of your class time doing, the time that you were focusing on code, those are the core skills. For me, I used to code back in the day and at this point, everything is completely unrecognizable to me because I’ve been out of code for ten years at this point. But the knowledge that I had just from the early days, and I was of that wave of folks that transitioned from table design to CSS; I was coding actively during that transition and a little bit after that transition. So, going through the exercise of being, wait: what are divs and what’s absolute positioning and what is floating? What are the various challenges and opportunities, and just understanding basically the grain of the web: like the web wants to do certain things and it does not want to do other things and you can work around some of those things that it doesn’t want to do, but it takes enormous effort and just having designers understand the scope of what their design is demanding is, I think, most of what they need to know, they need to know what is a div? How does it live in the page? What does it mean to be inflow; what does it mean to be out of the flow? What is type doing? Those are the basic skills and I don’t even think you have to be too advanced or fancy about it: you just need to know some of these basic things to understand, like you said, with print it’s like paper has a grain. And so does the web. So, just understanding the grain, understanding what you’re asking the developer to do is going to help you plan so much better as a designer and to anticipate a lot of those things that we were talking about before.
Mark:
Yeah, I think that it’s very clear if you receive or you’re working with a designer who doesn’t have a conceptual understanding of various aspects of how HTML and CSS work in the form of recognizing that things are typically laid out as boxes on the page and will behave as boxes on the page. That conceptual understanding gets you as far as you need to go without fully comprehending what the dom is, or the box model, how it behaves. And I also think that an understanding of the difference between JavaScript and CSS and how they’re meant to be used to change things visually on the page. And even the point at which they become relevant when a page is loaded; those kind of things can be really beneficial and do not require a really terribly in-depth knowledge of those things but can be really helpful when planning how the page is actually going to behave because that’s the big bridge you’ve got to cross when you’re translating from Photoshop into the browser is suddenly this thing is jumping around and moving because of some random user’s interaction and we’re trying to predict what that’s going to be. Understanding some of the basics of CSS layout, and the specifics of building those divs and things, it’s very good, but beyond that I think a conceptual understanding that can be provided by just a pretty basic touch of some of those other technologies can be really helpful.
Gary:
All right, so I have one final question because I’ve taken up a lot of your time. And this last one has to do with what you just mentioned, some of those interactions. Another area that I’m having trouble with, and I’m guessing everybody else is too, is micro-interactions. And by that I mean animating a drop-down menu or a button or animating a page transition or a modal or an alert. Basically, some kind of visual clue to help improve the user experience. If I want my students to focus on micro-interactions, I’ve basically got two choices: from my perspective it’s either I spend an enormous amount of time teaching them actual CSS animations so they can make them and then critique them and see if they work, or I teach them After Effects and they kind of experiment around in there to make approximations of it. So, how do you handle, at Fine, how do you handle that?
Tsilli:
Well, that’s a great question. We actually have a bit of a house style on some things so there’s actually less conversation around a few different types of things that over the years, we’ve just established more or less of a standard around so we have a way that we do modals and a way that we do drop-downs and a way that we do fly-out navigation and typically what designers are solving is what those look like, more so than how they come in and the developers will sometimes bring a creative solution to the table during production around how it animates and then we can critique that as a group and sometimes suggest something different based on that straw man that they’ve created. So what we end up doing a lot on our side is we have a production hand-off guide where we’re going through all the different things that a developer needs to know to hopefully be able to code the site without actually opening Photoshop, so we map out the grid of all the different design patterns that we’re using and show what’s happening at three major break-points. We define the type styles and what we would like to see responsively, more or less for them; we put together a color palette and try to define roughly where those things are going to come into play.

And then we have additional areas to talk through responsive image strategy and micro-interactions where we’re showing rollover states for things, open states for things and generally we have a document that goes along with that, that’s a behavioral plan where we talk through all of the features which include galleries and drop-downs and navigations and really any special move that is not clear from a flat design and we sometimes will just point to examples where out on the open web, you say I’m looking for a progressive load-in like this…see the hover have this really special underline animation that’s kind of like this and so it’s not so much like trying to copy what’s out there but the designer will have an idea as they are designing and then they go out on the web being like, is there anything even remotely like what I’m envisioning that I can just point to so that the developer knows what the heck I’m talking about? And that tends to be our process. So we don’t actually do a lot of literal prototyping in After Effects or expecting designers to show a developer a finished prototype that they’ve coded or any of that. We just assume that we’re going to get to that answer in conversation and so I don’t know to what degree I would focus on having designers in your class actually executing the things but I think the thing that’s most important is the ability to communicate with the things and that is what I would focus on. And it can be really a pencil and paper sketch of something if it’s communicating it; or it can be really specific narrative language with a link to JavaScript plug-in or whatever. Whatever gets the point across is what we do.

Mark:
Yeah, and I think I mentioned collaboration earlier and this is another one of those phrases where we will put our developers and designers together and the behavioral plan that Tsilli mentioned is both a record of their collaboration and occasionally it’s the catalyst that forces that collaboration, if it hasn’t happened before then, and the training that we have to do to enable people to be able to use a behavioral plan, or create one effectively, is about both the communication that Tsilli mentioned and identification of what areas are likely to see these micro-interactions and which of them, in our case specifically at Fine, which of those areas will be getting something special outside of what we would usually expect to do there if there is a standard behavior, in our experience we’ve come across a lot of those that we really like and if a designer is thinking to themselves that they want to sue mostly the standard types of interactions, they probably don’t need to mention them at all and their developer will just take care of it. It doesn’t hurt to mention it but generally we would do that and then the real task becomes figuring out OK, where do we want to see a bunch of neat things happen and then maybe take a quick glance at the timeline and budget and verify that we can do what we want and occasionally, increase the scope of what we’re planning to do because of what we find at those times as well.
Gary:
And that’s been actually, you just mentioned, that’s been kind of my approach is when I assign the students, I’ll say, because they’re always…they’re actually very…students are really good at…I wanted to do this…they actually intuitively know what kind of animations they wanted to do but they just have no way of…they have no understanding of how to visually prepare that and so recently, I’ve been just saying, let’s pick one animation through this thing and let’s actually, because in our program they have already had prior experience in After Effects and I say, let’s just try to mock this up in After Effects so you can visually articulate it.
Tsilli:
That’s super-great. That’s above and beyond, in my view. One thing, if we’re closing out this topic, one thing I do one to mention that is a skill that almost no designer has when they start out and that we find gets learned on the job a lot that is maybe food for thought is, we use content management systems for the scale of the sites that we do, both for the depth of content that they have and for client control over content and one of the wake-up calls that a lot of designers get is what that does to the design strategy of a page. In other words, what needs to be standardized and what can be a custom jazz-hands move on every way out that you’re producing? And so that’s maybe an area that’s too deep for the amount of curriculum that you have control over, but it’s worth mentioning because it is another one of those scenarios where we have a lot of pain experienced, where it’s kind of like what we were talking about with the grain of the web, it’s like the web wants to do a certain thing and also content management systems want to do a certain kind of thing and we use an object-oriented sort of approach to content management so it’s not a page-driven content management system and therefore there’s a data model and you have to figure out what is kosher and what isn’t kosher in the wild variation between labs and approaches, as you roll out a site, so that’s just something to chew on.
Gary:
Can you give a specific example, because I’ve built sites using Wordpress, Magento, Jekyll. Can you give me a specific one thing, just to articulate a little bit better for me to understand?
Mark:
Well, I think there’s a really obvious one for us in the form of the amount of text we would hope to see in any given area and then the amount of text that our client decides is appropriate for that area instead, because we use a proprietary CMS and we tailor it as much as we can to really try and protect the integrity of the design, once it gets out into the world, and a lot of the time that means, OK, this intro paragraph that has slightly larger font is actually a separate field in the CMS, just to make sure that nobody makes a mistake with mark-down or something and we’re thinking they’ve got about three sentences-worth of things to say about this product and that’s great, but then you hand over the site later and unfortunately it’s a page and a half right there and design has been pushed below the fold, so to speak, completely because of such a humungous intro-paragraph and in our situation, we wind up immediately going into damage control and we solve that somehow, we can’t just let the design fall apart out on the web so it’s the entire team winds up feeling that.
Tsilli:
Yeah, and from a design perspective, another thing that is a very common pain-point is OK, I’m designing a product page: there’s going to be a hundred products. How do I design a page that is both viable in the CMS and different, sort of, for each product so that there’s not that level of template exhaustion for the user who’s going from one product to the next and going, this all looks the same. So there’s this creative challenge of being smart about OK, I’m providing this kind of image area but if it’s not there, then it degrades gracefully and the kind of asset that they’re going to have always is like a bottle shot but maybe they’ll also have a beauty shot for some of their products, so how do I design a page that can make use of that when they have it but not when they don’t: that’s a pretty common one. Or just even things that are on the tiniest detail level, like you’re using too many type styles and no client is going to be able to really hold up the fidelity of that in mark-down so you just have to take a much more streamlined strategy where you’re doing just a couple of special moves here and there and those are separate fields so that they’re not messing it up, like Mark said: just all those kinds of things that become this kind of additional overhead of thinking about how it’s going to live in the real world.
Gary:
That’s helpful. I personally do that during critiques, when they put whether I’m looking at a mock-up in Sketch or I’m looking at live code because I’ve actually used CMSs before: I can say, that headline works perfect there but somebody’s going to do a two or three line headline and it’s going to blow up your entire design!
Tsilli:
Exactly.
Gary:
And I think that’s actually really easy for us to do, if you’ve had the experience, if you’ve lived through it breaking!
Tsilli:
Yeah, exactly, it does back to what we were talking about before: the painful experience is the one you remember.
Mark:
Yeah.
Gary:
Yep, so again…well, before I let you go, is there anything else that you wanted to…that maybe you’re personally working on or other advice that we didn’t cover, because this has been crazy in-depth and helpful? So if there’s anything else that you wanted to throw out there, I would love to hear it, if there’s anything you’re working on.
Tsilli:
Well, I think we touched on most of the high points. For us, we try to hire designers, usually they’ve been out of school for a few years already and have felt some of the pain somewhere else before they get to us, kind of place. And a lot of times people are coming in at a junior level just from a professional development standpoint, what might be useful for your students to know if, it’s great to just try to be helpful and do whatever you can get your hands on and improve your game outside the studio as much as you can by taking on personal projects and really just try to see what you can learn by shadowing people and look for opportunities to do as much as you can, understanding that you actually don’t want to have too rapid a trajectory into more senior levels of responsibility because you can actually crash and burn a lot faster that way and so it’s really good to just have a slow, steady pace through this industry, I think a lot, because of the speed of this industry, there’s always this hunger for people to get in there and do more and more and more and try to do edgier and edgier and edgier, but really focus on core skills and being able to deliver stable solutions and work your way up and don’t be afraid of looking at the long game and just trying to put one foot in front of the next.
Gary:
Mark, did you have anything to add before I let you both go?
Mark:
Well, I completely agree with everything Tsilli just said and I thought that the curriculum as you described it earlier was perfect because we see a lot of developers coming in these days who have a very cursory knowledge of all the fundamental systems they would be need to know and have focused their past eight weeks of schooling on a brand new, untested, untried technology and that is not a very healthy set-up and those people wind up disappointed in their own skills, not realizing that CSS is actually a huge subject: it’s not a thing you look at and understand a little bit and then move on.
Gary:
Especially now with Flexbox and the new grid spec that’ll be coming up soon.
Mark:
Oh, Flexbox: we’ve been loving Flexbox!
Gary:
Yeah, I finally ripped the band-aid off and said no, I’m going to stop…I still teach floats but now I’m also introducing Flexbox and it’s kinda hard because I don’t even fully understand it yet enough to teach it!
Mark:
Yeah, same here. We were very reticent to move forward because of browser support and things like that and we decided just recently, OK we’re going for it and it’s been fantastic and there’s the one CSS tricks Flexbox article, we probably hit that from our office fifty times a day!
Gary:
I hit it a couple of times too! I’d love to see their analytics right now for that page!
Mark:
Yeah!
Gary:
All right well again, I want to thank you for being so generous with your time, this was amazing and it was really, really helpful.
Tsilli:
So happy….
Mark:
Yeah, thank you, it’s been great.
Gary:

That’s all we have time for today on part two of episode Twenty-eight of Design Edu Today. I want to thank today’s guests, Tsilli & Mark for being so generous with their time. I want to thank the audience for listening and I want to thank the Design Edu Today hosting sponsor DigitalOcean and CDN sponsor Fastly for making the hosting and distribution of these podcasts possible. Finally, I want to thank the AIGA and the AIGA Design Educators’ Community for their generous support of my research that lead to this podcast series.

If you want to discover more about the Design Edu Today podcast and read the session notes and transcripts, visit us on the web at designedu dot today. You can also follow us on twitter at @designeudtoday, like our Facebook page or subscribe to this podcast through the iTunes or Google Play store. Thank you for listening to Design Edu Today.