WebDev Chat: Lessons for Marketers & Complex Web Elements

One of my favorite "perks" of working at IMPACT is that I am privileged to work alongside some of the smartest people -- who are genuinely experts in what they do -- every single day.

But how often do I go out of my way to learn more about what others do? Not very often.

That's why I've set a challenge myself to learn more about the area of expertise under the IMPACT roof that is the most foreign to me -- web development. To achieve this goal, I'm going to sit down with IMPACT Senior Front-end Developer Tim Ostheimer once a month to talk to him about what he does and why, and what us marketers can learn from his background and experience. 

Because, for two groups of people that need to work together a lot -- marketers and developers -- I think we could do a much better job bridging the divide between us. 

Enjoy!

Can you tell me about your background and how you got into web development as a career?

Tim: I have a bachelor's degree in Interactive Digital Design from Quinnipiac -- that's what they called it -- which was mostly digital graphic design using Photoshop, Illustrator, InDesign -- pretty much all of the Adobe tools. We studied typography. We did some animation and 3-D modeling. We did print design, and we did some web development.

I enjoyed all of the classes I took at Quinnipiac, but within the first few semesters it quickly became clear that there wasn't a specific medium or direction that the major focused on. Instead, it was more of an opportunity for students to experiment and come to their own conclusion of what they wanted to gain from it.

This was the perfect environment for me to learn in.

I started experimenting with image editing and HTML when I was young, but it wasn't until around 9th grade that I started challenging myself to learn more and take the hobby seriously. I spent a lot of time building websites about video games I was obsessed with and I wouldn't stop working on them until I was satisfied with the way they looked and functioned, even if the only person who would ever use them was myself.

We had a few elective classes in high school so I made sure that I took every class that had anything to do with computer science, photography, graphic design, and web design. These were very introductory classes, but it was a time in my life when I was starting to think about college and further education and these helped reassure me that some kind of digitally-focused career would be appropriate for me to pursue.

At that time, I was too inexperienced to know what kind of options there were. I knew that I enjoyed working with websites and code but I also had a lot of interest in everything related to design and I didn't want to pick a major that focused too heavily on one thing.

While looking at colleges and majors, I had a lot of trouble finding one I was confident about. I ended up specifically ruling out art schools because I still needed time to explore my options and wanted a more well-rounded experience. Quinnipiac's program was appealing to me because it had just that -- a little bit of everything.

I started with what I thought I wanted. I chose Quinnipiac and began my first semester with a predeclared minor in Computer Science. Unfortunately, I didn't really know what I was getting into. The course focused heavily on object-oriented programming which was different from anything I was familiar with and I struggled with every assignment and learning the material. So, I decided to drop the minor after completing the second course in the curriculum.

Instead of choosing a new minor, I decided that I was going approach my education in the same way that had gotten me to that point.

I filled my elective courses entirely with classes in related subjects that I'd be able to use to support my major. That way I'd have a better understanding of the processes and would be able to apply that knowledge regardless of the industry I ended up in.

I took classes with the film students and learned a lot about something I knew nothing about. In addition to filming, each of the courses focused on video editing, motion graphics, special effects, and/or sound design, and all of it was interesting and exciting to me.

So, I didn't stop there. I took classes in game design and development, and learned about mechanics and all of the different roles that are involved in the industry -- from the world-building aspect of the storytelling to the specific code that's written for the interface to ensure the experience is immersive.

Sometimes there might be an entire company that's focusing on just one piece, and that realization helped me to understand that it was okay to not be talented in every area of the design process.

Each of these courses gave me a different perspective on visual design and enabled me to apply what I had learned in everything I created from that point on.

During my third year of college, while I was taking courses in game design and animation, I ended up revisiting object-oriented programming. I had decided that I wanted to create a functioning game as a combined final project for these two classes but I couldn't do it without learning some new code. I spent countless hours outside of class and on weekends to learn the very thing that I struggled with the most.

But this time, it didn't feel overwhelming. Instead, there was a point where suddenly everything made sense and I became passionate about it in the same way I was about everything else I had learned.

The code now had a purpose, and it encouraged me to spend time learning what I wasn't able to understand the first time. I ended up spending more than 50 hours on this one assignment and combined all of the knowledge I had learned from my classes in different majors.

I wrote an elaborate story on which my game was based, drew every frame of every character's animation and the world around them, designed an interface which supported my theme, and coded all of the functions that were needed to make it all work.

The result was an amateur game and my favorite portfolio piece from college that I will forever be proud of. I still occasionally dig through my folder of creative work every few months just to play it for a few minutes to appreciate and remind myself of how much I learned from it.

In case you're curious, this is what it looked like:

Because I had so much fun building that one, I ended up taking part in a challenge called Global Game Jam that same year. The task was to design and build a game using any medium within the span of a two-day period based on the theme "heartbeat."

Before Quinnipiac I didn't realize there was a development side to design. I didn't think much about that fact that most people specialize in one part of the process and the designer of something like a website or a game is usually different from its developer.

What interested me the most was how each of these roles overlap and contribute to combine their work into a single unified experience. Rather than being concerned with the fact that I may not be pursuing the same career path as other students, I challenged myself to learn from every major that had anything to do with design and the various forms of digital media -- and it was the best decision I've ever made.

In the end, I decided that web development was the most appropriate career for me and that choice ended up leading me to work at IMPACT building great experiences for our clients and the users of their websites, but I can confidently say that working with students with entirely different career goals ended up teaching some of the most useful lessons I've ever learned.

Are there challenges to people not understanding what it is you do as a web developer or your processes -- how they're built or why they're structured a certain way?

Tim: Yes, we see a lot of confusion regarding development concepts or specific functionality, just because it's so technical.

With design, a marketer who's not a trained designer can still talk about specific elements of a design and understand their purpose. There may be things that they may not know are best practice -- like some of the principles of typography or user accessibility. But, for the most part, they can look at something like a Photoshop mockup and envision that as a page.

When it comes to the intricate parts of functionality, determining how difficult something might be to build, potential drawbacks of an adjustment to a design, or the technical side of how their website gets built, however, those are things that marketers have a lot of trouble talking about.

This matters a lot when scoping a website redesign project for a client because it's difficult to try estimate something like timelines or effort involved for a particular task without knowing the full context. Without having a design available where we can specifically reference an exact example, it's hard for us to estimate how long something might take, because it usually comes down to understanding all of the individual parts that are combined to build it.

If I look at a design, I can tell you about how long it might take me to build it. But it's really hard for me to provide general guidelines that always apply for scoping because even a minor change to a design could drastically change the way it has to be built. 

Moving something over just a couple pixels could sometimes require an entirely different code structure, and adding in one small feature might mean that the rest of a page has to be built so it doesn't interfere with it. Sometimes a small request can end up being a lot of work, and it can be hard to identify those even if you are a developer.

What would you say are some of the most common tasks or website elements that, may seem to someone like me that would take a short amount of time but, actually take a lot time?

Tim: In certain situations, one would be changing things on mobile.

Developers don't determine what content is written on a page, so we have to balance flexibility with structure. Depending on the way the page needs to adapt for different screen sizes, it can be very difficult to ensure the layout is indestructible without infringing on the marketer's freedom.

Usually, for a responsive site, you want to adjust the layout at different screen sizes to ensure the page always looks great.

If it's a very important page -- like a homepage or pricing page -- it's worth spending as much time as you need on mobile because it's a very important user experience. Even if that means the template can't be structured in an intuitive way because the marketer managing the content will be using the page less than their end users will.

But, for other pages, completely changing something on mobile just for a minor adjustment could end up taking a lot of time if it doesn't share the same content structure as it does on desktop.

Sometimes it can also result in a poorer experience for the marketer if the template can't be structured in an intuitive way. Keep in mind, developers are building templates for both the users who view the page, as well as the marketer managing the content.

I would say the other thing is sliders and things that move.

An example of a website slider built by Tim.

It's rare that any two are the same. We have a couple that are somewhat standardized and we'll use those in situations where a custom one isn't required because we're able to make some adjustments to their design.

But, often, a custom slider is needed to achieve a desired layout or functionality. The content organization may be different, or the slider controls may be in a different spot, or it's full-width instead of within the grid. Maybe the amount of slides per active state changes at various screen sizes.

Maybe on desktop it's not a slider at all.

Maybe you have three columns but on mobile it becomes a slider, where there are three slides that you have to swipe across. That actually takes a lot of work because we tend to avoid using unnecessary code when possible, even if prewritten code or a plugin has the options we need.

Another example would be sliders that look like they're on an infinite loop -- where it appears that you can just keep swiping forever. Even if looks like there are only three slides, there's usually not just three slides.

For this kind of design, usually what has to be done is duplicate the first two and last two slides and then put them on the ends of the slider. Then, when a user gets to the point where the slider would loop, we actually just move them all the way back to the clone of the last slide and then transition forward. This all happens in a single frame.

So, what's specifically happening is we're temporarily disabling the animation, moving the slider to the clone of the last slide, enabling the animation, and then moving you forward to the first slide in the group. The result is that it looks like you have transitioned seamlessly and the slider never ends.

Because we want them to be perfect, sliders can take a lot of time to build just because there are so many moving parts and we'll often have to code them by hand. 

If you could give marketers and business leaders one piece of advice that would transform any conversation they have with a web developer going forward, so they're more productive and positive, what would it be and why?

Tim: This isn't a simple response, but the answer is learning basic HTML and CSS.

You have to understand what a website is and how it works. If you can even just right-click on your page and click on "inspect element" and understand mostly what it is that you're looking at, or at least be able to identify what it is that you don't understand, that can help a lot with any conversations with a developer. It will also help give you the foundation you need to learn more over time, even if you aren't building anything yourself.

It'll start to make sense how pages are structured and how that structure is determined by a design. If you at least understand that part, you can begin to predict what might be involved in changing a page to fit a certain type of content or allow for a more flexible layout.

Well, even if someone like me doesn't take the time to learn HTML deeply, just looking at the complexity of it and understanding that something that seems very simple on the surface has thousands of moving pieces, and pieces of code that you have never seen before.

It sounds like that's, at the very least, a first step toward bridging the divide and being able to acknowledge -- as a marketer -- "I don't know what I don't know, and my web developer isn't trying to ruin my life when he's telling me that something's going to take longer than I originally anticipated." 

Tim: Yes, absolutely, and another benefit of it is that you then also start to understand the technical SEO part of your site. 

Because, for the most part, it's not the developer actually doing the technical SEO implementation -- it's most likely going to be the marketer. There are certain best practices that the developer definitely needs to adhere to. But when it comes to the marketing side of SEO -- meta descriptions, titles, headings, proper formatting, etc. -- there's only so much that a developer can ensure is done properly if they aren't the ones entering in the content themselves.

If you know some HTML, it will help a lot when you're trying to either troubleshoot or fill in that information and that you're not breaking your site -- or you at least you'll know what to look for if something goes wrong or seems wrong.

Just knowing a little basic HTML will help a lot, even if you never have to write it yourself. It will help give you a better perspective of what your webpage is doing. You'll start to understand the behavior of your templates, what the robots from search engines are seeing, what technical SEO is, and how to use the page to its full potential.

And, most importantly, you'll be able to have better conversations and continuously learn from the people around you.