“Just build websites”

Trying to learn as much as possible about the fundamentals of product design and front-end development, I talked with Dave Rupert about his thoughts on how web development fits into product design, and web development as a discipline in general.

How did you get started, and how did you get to where you are now?

Dave: I was making webpages when I was 15, so I’ve been making webpages for over 20 years now. I did that as a hobby as a kid, and didn’t think I could do what I was doing as a profession. In college, there was a dotcom bubble, but it burst. Then I was living in Japan and ran spare websites there. When I came back, I started Paravel about 10 years ago. We started with mom and pop websites and then grew and grew with bigger and bigger projects. We built a name for ourselves as “pixel perfect” in web design. And that’s when responsive web design kind of happened and kicked in, which changed the way we did everything. We’re very committed to pixel perfect perfection, and multi-device strategy ruined us completely. On the other hand, we figured it out, and were early adopters in figuring it out. So for example, we used RWD for Microsoft’s Build Conference in 2012. It’s sort of the big thing. Since then, we’ve worked with Starbucks, Wired, RetailMeNot, etc. We’ve done a couple of other really great projects too – Etsy was another client of ours. It’s been cool but also weird too because we started out 10 years ago in a nook in my closet and now we work with big clients, which is neat.

What are your thoughts on how front-end development fits into product design?

Dave: Product design is just a new name for an old thing – caring about how the user interacts with a product. I think there’s web design, and people switch to apps, and then it was app design, and then it was product design with a little bit of UX design. I kind of consider it all to be digital product design, and consider it all to be the same thing. I consider things to be more appy, like a chat app. Some things are more static like a blog. It’s all the same thing, but just a little bit of difference and nuance and activity. In terms of just code, you’d be surprised, how much code affects the overall look, feel and performance of a website. The quality of the underlying code, the consistency as its translated out to multiple pages… it affects the overall design of a product. I’ve been getting into video games, and there’s a term that Nintendo’s Shigeru Miyamoto uses – tegotae (手応え) – which means “hand response.” It’s how things feel as a video game. Anyone can make pixels move across a screen, but how does it feel? That’s how I feel about code.

Front-end code is a valuable discipline because… 80% of the time a user is waiting – let’s say the page loads in five seconds – four of those seconds are because of front-end coding. On a mobile phone, you have to load your website under three seconds or the user is gone, and an interactive widget under five seconds. It’s the job of the developer to render the page under three seconds, or at least lazy load some components so that the user doesn’t notice. In terms of performance, that’s huge numbers on the bottom line of a company. There’s a site call wpostats.com, which is a blog about web performance. If a website is taking a long time to load and is poorly coded, that’s half of your business falling out the window. So in terms of front-end in product design, I think it’s hugely important. The accessibility happens on that end too, and it’s a huge business impact – lawsuits for some people, even. It’s a very important thing that happens there. If you consider performance stuff, these things affect design decisions that happened earlier down the waterfall. Product people and business people hand something to design, and design hands what they have to development. There’s never a conversation of how it is going to work for the user. These are some of the reasons why front-end is a very valuable discipline. You get into style guides, which have gone into rebirth. Companies will have really good print style guides, and marketing agencies will prescribe web techniques in digital briefs, and they don’t fit the web at all. The style guide adds consistency – a designer will design one page, and then will design another set of pages. With a whole system of content, you can’t think from a page by page basis – a system of content.

What are some of your best experiences working with designers? What are some of your worst experience? 

Dave: It’s tough because I mostly work with Trent and Reagan. It’s good but we’re used to each other – we’re like old married folks. Some of the best things are when we work on things together. When we’re working and sketching ideas together, we can share ideas quickly and validate them between us and start building something together. It’s way better than when we’re handing things over the fence – when we’re building and sharing, that’s by far the best experience, and that’s what I live for. Sharing your work – I think that’s very important to both designers and developers so there’s feedback. The worst situations… there are dozens, but mostly it’s just that I’ve had designers treat design as gospel, and that “Here, code this,” attitude is very off-putting. This is a terrible phrase, but kind of being a code monkey for people – being responsible for someone else’s design problems – is the worst. You didn’t hand me any solutions. That’s probably the worst part.

What are some things that will help a developer grow? What are some things that will hold a developer back?

Dave: It’s interesting – I think keeping up with front-end development historically is tough. It changes every six months, there’s always something brand new and sometimes you can get caught totally off-guard. Sometimes it can be hard to keep on track for something that’s so high velocity. I spend a lot of mental time and effort to keep on top of things. I have a phrase on ShopTalk (my podcast) – “just build websites.” If you want to learn something, start solving a problem, and the things you’ll need to learn will start showing themselves to you. Maybe bite off more than you can chew, but you need to start somewhere and start something. That’s kind of the time-honored way of learning stuff. Genki Hagata did 30 days of “Hello World,” where he did 30 examples of a language or what not – something he was interested in – and would take  a couple of hours to learn something and get it off the ground. I’ve only read half of his documentation, but I think that’s a really great way to learn. Identify what you don’t know, and learn a little bit about it.

What are some trends to key an eye on for 2017?

Dave: The CSS grid specification. CSS has never had a great layout module. There have been tables and floats where you can send things left and right, there’s display inline and flexbox, which will take 100% of width and divide it up and flow content the best it knows how. It’s kind of a weird math engine that sometimes works and sometimes doesn’t. The CSS grid spec is really truly kind of a grid – there’s a grid cell and a gutter, and you can control not only the x-axis, but also the y-axis. Most engines only control one direction, but this can control 2D x and y directions happening in CSS. It lands in all major browsers in March of 2017.  I’ll let it blow up in other people’s faces first, and then I’ll do it. It’s interesting that we’ll have these advanced layouts. So there’s one thing. There are languages like JavaScript frameworks and things like that – they’re bad for performance but create a neat real-time experience. I think those are going to have their major problems fixed, as there should be a performant way to make interactive webpages. It’s available now, it’s good and fun and great but not the most amazing technology in my opinion. There are web VR specifications happening where you can make VR experiences using web pages. It’s interesting to think about, but maybe not practical yet. Those are my three things. Some ways it’s plateaued, and there are chunks of new tech that’s coming out to enable.

Thanks Dave!!

You can read all of Dave’s fantastic blog posts at his website, listen to his podcast, and see what the team at Paravel has worked on.

Hacking the Facebook Hackathon

After my first hackathon, I’ve come to realize that aside from being free to make whatever your heart desires just with some code (though lots of it), hackathons create a perfect environment to GSD or “get shit done.”

I went to the Facebook SoCal Regional Hackathon on Friday with a friend, but we both had our own agendas. While he was planning to finish up a little bit of CS homework before diving into his personal project, I planned to work with some cool jQuery plugins I’ve been meaning to try out, since I haven’t had the time to experiment with web development tools in a while.

After signing in and finding that most of the seats were taken, we sat down near the back next to two UCLA students. We chatted for a little bit and found that none of us had prepared an actual hack for the event just yet, which was slightly reassuring. Though the returning champions from last year were just a couple of tables away from us, it was nice to know that people of all levels are getting involved with hackathons.

The hackathon was probably 99% dudes, but that wasn't going to stop this girl.
The one time we could use Facebook without feeling guilty about ourselves.

Soon enough, the two students next to us had formed a team with two other Bruins, while I continued to work with plugins and my friend hurried to get his CS homework done. From time to time, I listened in and chimed in on the UCLA team’s project, and found myself a little miffed since I decided to opt out of joining a team this time around.

But instead of throwing the towel in and going home, I decided to learn something completely new. Sure, I wasn’t creating a project from the ground up, but I was going to take advantage of this space and wanted to ride the productivity momentum that this environment was generating.

So no, I didn’t exactly “hack” the Facebook Hackathon, but I hacked it for my own benefit. Because, for the next couple of hours, using what I knew about HTML, CSS, APIs and Php, I worked through Tuts+’s Facebook Graph API tutorial, and managed to finish the whole project. Did I make something completely original? No, but in the time I was at the hackathon, I made my first *unofficial* Facebook app and learned how to integrate Facebook logins into just about any web app — not something I would’ve accomplished had I been by myself at my apartment.

Used colors from here
Perfect Facebook color palette brought to you by Design Pieces

I even won a pair of Facebook sweatpants during one of their hourly raffles.

fb2
If you squint just enough, you can make out my name.
fb3
Comfortable and Zuck-approved!

What I’m trying to say is that just because you might not be a whiz programmer doesn’t mean you shouldn’t attend hackathons. You might not be able to attend every hackathon out there — PennApps, for example, requires that you apply formally — but for hackathons that only ask that you RSVP, such as this one and the upcoming LA Hacks (I’ll see you there, if you’re going!), I absolutely encourage you to attend. The truth is that at most hackathons, there are always at least a couple of people who come to hackathons without a team, so don’t worry about not finding one.

And if you feel like you still need to hone in on some skills — just do it, but try to stay at the hackathon, so you get a feel for the environment and structure of a full-fledged hackathon. You’ll be better prepared for the next one.

What’s also amazing about hackathons is that for whatever reason, even if there is loud music playing and people chatting, everyone tends to get a lot done. One friend showed me his RescueTime log after HackTech, which calculated his productivity to be about 90% over a span of 16+ hours. Sure enough, when I opened up RescueTime on my computer, it said that I was being about 92% productive.

If you haven’t been to a hackathon yet, it’s definitely not too late. I might sound a little sappy when I say this, but a certain, unspoken camraderie is fostered among attendees through late nights, tired fingers and eyes, debugging frustration and not ever having enough snacks. It’s an irreplaceable experience that you can’t find anywhere else.