Taking Responsive Web Design Beyond the Visual

Share this article

Taking Responsive Web Design Beyond the Visual

Taking Responsive Web Design Beyond the Visual

In this episode of the Versioning Show, David and Tim are joined by Chris Ward, a technical writer, blogger and web developer. They discuss a wider interpretation of responsive web design that includes user context, push notifications, future devices and accessibility. They also discuss mobile first and progressive enhancement, tech journalism, the art of documentation, working with Drupal, PHP (and whether it will ever be cool again), and using Wikipedia to learn how to perform an appendectomy.


Show Notes

Conversation Highlights

I would say [responsive web design is] more relevant and becoming more relevant again. I think some of the problems that it initially set out to solve have maybe, sort of, been fixed, in very large, inverted commons. And actually, it’s going to be useful in the future and in the present for solving other new problems. Like different sorts of device capabilities, not just screen size and things like that. But other capabilities of devices too, and responding to user context and location and time of day and all sorts of things like that.


[Jump Start Responsive Web Design] covers the building blocks of a page and the page elements. It then talks about obvious things like media queries and viewports. We cover text, we cover images, and then media and then kind of a bit at the end about some of the stuff we’d just been talking about, sort of new responsive.


Actually, the kind of applications of screens is quite widespread now. And some of them are more standard than others, so it might just be an Android browser, like Samsung, I think. Their fridges have basically an Android browser in them. That’s going to be used by a lot of people, even if we want to get crazy out there.


things like voice interfaces … Just even thinking about how to repurpose your designs and content in as many of these new cases as possible, in my mind, would also be kind of responsive, or the new responsive or adaptive, or whatever you want to call it.


There may need to be rethought functionality, because you have less screen real estate. People are using fingers. They don’t have a full proper keyboard, et cetera, et cetera. But it doesn’t necessarily mean they should get a worse experience. Just a more suitable experience, I suppose, would be mobile first.


With things like iOS and Android, you have the concept of a share extension which enables you to easily share links or files or whatever between other applications in the operating system. And macOS and Windows have that to a certain extent, but often developers don’t bother implementing it. Whereas, on mobile, it’s generally there. So sometimes, actually, you can get a better experience.


take advantage of documentation being online. It doesn’t have to just be text. You can add interaction. You can add interactive consoles, videos, CodePen examples, et cetera, et cetera. That stuff helps a lot.

Taking Responsive Web Design Beyond the Visual, with Chris Ward

Transcript

Tim:

Hey, what’s up everybody. This is Tim Evko …

David:

… and this is M. David Green …

Tim:

… and you’re listening to episode number 32 of the Versioning podcast.

David:

This is a place where we get together to discuss the industry of the web, from development to design, with some of the people making it happen today and planning where it’s headed in the next version.

Tim:

So today we’re going to be speaking with Chris Ward, who is a technical writer, blogger, and web developer. And we’re going to be talking with him amongst some things, his latest book, and web development, of course. So let’s go ahead and get this version started.


David:

Hey Chris, good to see you.

Chris:

Hey, how are you doing?

David:

I’m really pleased you were able to join us on the show today. This is the Versioning Show, and one of the things we like to do is ask our guests a philosophical question to get the ball rolling. And your philosophical question for today is: in your current career, what version are you, and why?

Chris:

You know what? As someone who is easily bored and constantly trying new things, I think I’m going to be a rolling release.

David:

[Laughs] Very nice, very nice. You do say you’ve been trying a lot of different things. How do you introduce yourself? How do you summarize your career for people when you’re letting people know who you are and what you do?

Chris:

Nowadays I say I do technical writing and tech journalism, and there’s a little bit of tech blogging in the middle, but I think there’s enough crossover between all three — like concentric circles meeting in the middle there somewhere. But depending on the audience, if I’m saying that to developers, I will mention that I used to be a developer, full time. If I’m not in an audience of developers, then maybe I won’t mention that.

David:

What kind of development were you doing when you were doing development?

Chris:

So I actually spent most of my time prior to about 2009, 10, maybe 11, so 10/11, predominantly actually doing Drupal development and contributing to Drupal as well. I have a couple of commits in Drupal core. So mostly PHP and content management systems and things like that. And then I took a bit of a turning to other domains after that.

David:

Oh, that’s interesting, because Drupal … it’s got a lot of back end, and it’s got a lot of front end. Where were you focusing your attention?

Chris:

Well, the Drupal community has a lot of what are kind of termed site builders, or people who do a bit of everything. Because, at the time anyway, it tended to be quite popular in smaller agencies. And especially, this is when I was in Australia, where most agencies are quite small. Even a big agency is maybe only 30, 40 people, so you still had a lot of generalists. I was doing a lot of generalist tasks, but also some kind of dev lead, even helping with a bit of technical sales and stuff. I’ve always been a bit of a generalist really. [Laughs]

David:

So for the folks who might not be familiar, can you explain Drupal? I mean, it’s got a context, and it’s got a whole ecosystem around it.

Chris:

Well, I’ve been out of it for a little while. I would say the context has changed a bit, but it is a PHP-based content management system, sort of a much steeper learning curve than something like WordPress, which is another very popular PHP content management system. But you can generally accomplish more complex things with it. The catch phrase use to always be that WordPress powers 20% of the internet, or something crazy, but Drupal powers the top 10% of websites on the internet. It was always better suited at building more powerful things. I would say that it’s changed a bit now, to be honest with you. I’ve been out of it for a while, and the community has changed, and the community around it has changed. I witness it from afar these days, but I would say the whole dialogue around the community has changed a bit too. I’m not an expert anymore.

David:

I’ve always heard that with WordPress you can build a website and with Drupal you can build WordPress. That was always my favorite saying.

Chris:

I’ve never heard that, but that’s not bad. [Laughs]

David:

So how did you initially get into the world of web development?

Chris [3:56]:

I did a computer science degree. Suiting my personality, it was actually quite a broad degree. It was a multimedia computing degree/science degree, in London. I lived in London, but then moved to Australia mid-2000s. But then I just sort of fell into PHP jobs. My first web agency job was actually in a ColdFusion agency. I just sort of fell into PHP and just never really left it, until I got more into mobile work and things like that. Yeah, I don’t know. There was just more work, and it just popped up, and then I just kept doing it for a few years. No real considered effort. [Laughs]

David:

These days, the cool kids don’t even know what PHP is.

Chris:

No, it’s very true. It’ll be cool again. [Laughs]

David:

I think so. I think so.

Recently, you just published a book on responsive design. I think this is the second edition, right?

Chris:

Yeah, but I didn’t write the first edition. So when you say my latest book, this is my first book. [Laughs]

David:

Fair enough.

Like PHP, responsive design is one of those terms. I think it’s kind of got a ring of the antique about it, because so many people are already familiar with it, and we’ve moved on to different terminology. But responsive design itself still is very relevant today.

Chris:

I would say it’s more relevant and becoming more relevant again. I think some of the problems that it initially set out to solve have maybe, sort of, been fixed, in very large, inverted commons. And actually, it’s going to be useful in the future and in the present for solving other new problems. Like different sorts of device capabilities, not just screen size and things like that. But other capabilities of devices too, and responding to user context and location and time of day and all sorts of things like that. I know some people have different words for that, but I would kind of argue that if it’s about responding to device capabilities, then I think we could use the same word.

David:

That’s an important distinction, because responsive design, to a lot of people — myself sometimes included — means everything gets squishy, but that’s not what responsive means at all.

Chris:

Yeah, and it’s me maybe, not necessarily being controversial, but just saying that it could be broader than that. We have frameworks in place now with new inventions in CSS that help with the squishiness a lot more, so we can start to experiment with some other things too. A lot of the APIs you have available in HTML and modern JavaScript are helping us test and respond to all sorts of other things.

It’s such in flux at the moment. It is almost like a few years back. There are some APIs that I remember writing about, that when I was writing the book, I discovered a lot of them had changed or even been removed. They’re all sort of in flux a lot.

David:

So, in the second edition of Jump Start Responsive Web Design, what was the main sort of concept that you spoke about related to responsive web design?

Chris:

The point of the Jump Start books is kind of aimed at someone who knows a little bit about a particular subject, or maybe knows next to nothing and just knows a little bit of prerequisite knowledge — i.e. HTML, or something like that — and wants to learn a concept in a weekend. That’s basically the premise of the book series. I was tasked with bringing the first edition up to date, and in all honestly, I think I ended up probably re-writing more than I initially said I would. I mostly used the first edition as kind of a framework to talk about. But the actual content changed a reasonable amount. It covers the building blocks of a page and the page elements. It then talks about obvious things like media queries and viewports. We cover text, we cover images, and then media and then kind of a bit at the end about some of the stuff we’d just been talking about, sort of new responsive.

David:

Now that’s kind of a thing I’d like to dig into a little bit more. Because as I said, the term responsive design has been around for a while, but what are the things that are making it new these days? You brought up a few different contexts in which responsive … the definition is expanding beyond the visual.

Chris [8:00]:

Yeah. I guess firstly, different sorts of devices. That we thought we had it hard with having to adapt to new mobile devices. And actually, to a certain extent, adapting to mobile devices has got a little bit easier again, because those devices have got better. But we also now have games consoles, TVs, cars — probably in the near future screens in cars. Maybe advertising boards. Actually, the kind of applications of screens is quite widespread now. And some of them are more standard than others, so it might just be an Android browser, like Samsung, I think. Their fridges have basically an Android browser in them. That’s going to be used by a lot of people, even if we want to get crazy out there.

I didn’t cover this in the book — but it just popped into my head — things like voice interfaces. I mean, people don’t necessarily browse a website with a voice interface, but they will browse data from a web service, or something like that. Just even thinking about how to repurpose your designs and content in as many of these new cases as possible, in my mind, would also be kind of responsive, or the new responsive or adaptive, or whatever you want to call it.

David:

That makes me think a lot about the concept of UI-less design, and how you might need to respond to that in terms of push notifications. Right? A user could interact with your application without ever actually going to the URL, maybe once or twice to sign up for push notifications. But after that, you can interact with quite a bit of things just by tapping buttons on push notifications that come up to you. And that’s it.

Chris:

Exactly. I mean, you get very limited design capabilities in a push notification, but still, it’s design to think about.

David:

It’s interesting, because it starts to get to the point where everything becomes part of responsive design, all the way down to accessibility issues. So, if you’re thinking about it that way, how do you focus people in terms of what you would consider to be the limits of what people need to learn today in terms of responsive design?

Chris:

Okay, well now you’ve got me all excited by saying it could be everything. You’re telling me to reign it in a bit. I don’t know.

[Laughter]

David:

Where would you put people’s focus first, I suppose? Like for the developer who’s out there, and he’s inherited the homepage for a company that developed it in 2008. It’s this thing that only works on 980px-wide browsers. Where do you put your attention first when you want to consider the context for what that needs to be turned into for a responsive design?

Chris:

First, I will give the broad, pragmatic response. And then I’ll give the more helpful response.

The broad, pragmatic response would be, try to find out what your users are using, and if they’re all using old machines and old resolutions, then maybe you don’t need to worry so much. Who knows? I mean, it depends, kind of, on your audience. But then, once you have that information, if it does, of course, present the fact that there’s a multitude of different devices, then you focus on the major desktop browsers. You focus on the major mobile operating systems at reasonable devices. Especially with Android, you can’t cover everything. And you don’t really need to, to be fair anyway. And that’s to be honest with you, probably, mostly enough. Test on some 13-inch laptops. Test on some 27-inch screens if you can. Or use simulators to do that if you can’t. And that’s probably enough for most cases. What we’re talking about with the other subjects is a bit more out there. And if you’ve got the budget to be doing that kind of stuff, you’re sort of okay anyways.

David:

I like that you start with an audience-driven focus, because you’re really thinking about what’s going to be practical. And one of the things I noticed you were talking about — a lot of people think about — HTML5 immediately introduced all of these things that allow you to be more responsive, and then CSS is used to style it. But you also get into the JavaScript side of things as well.

Chris [11:50]:

I think, firstly, because some of the less visual tests are JavaScript-based, but also, the ability to react dynamically to certain things is a JavaScript functionality, of course. I tried to stick to pure JavaScript. Again, I think that’s more possible than it use to be. In fact, my JavaScript knowledge was fairly out of date and in the past year or so, I’ve sort of dived back into it for various reasons and discovered how much it’s changed — for the positive. It’s mostly for little bits of dynamic changing, testing for functionality, things like that really. Not a massive amount.

David:

One of the other things that you talk about in your book, that really caught my attention, was all of these different paradigms for what responsive means. Whether it’s progressive enhancement, or graceful degradation, or mobile first. Can you tell people who might be entering this some of the distinctions that you found among those different perspectives?

Chris:

Okay. I’ll start with mobile first, and then I’ll have to wake myself up to remember the way around for the other two.

[Laughter]

So, mobile first is basically designing first for mobile. The name kind of gives it away. And, building from there. So you take the premise that the majority of users these days — which isn’t strictly true, but it’s generally at least 50/50 — will be using a mobile device. You build a fantastic design that suits these cases that you need and they need on a mobile device and then you build up from there. And you can add more functionality as you go up the device tree, if you like. Or across the device tree, however you like to look at it. But, first and foremost, it should be a good, positive, strong experience on a mobile device, basically.

And then kind of the other way around for that is the other perspective of picking your device that is the optimal for you. And again, this depends on use case. If you’re designing an office application, then you might be able to take a big assumption that a lot of people would generally be at a desktop computer, so you have a certain screen real estate and things like that. And you then sort of strip away design elements and functionality as you go down the device tree to make it just usable or just bearable or whatever your agreement may be, for those users. I mean, it’s basically just two different perspectives on the same … One is starting with the smallest device and working up, and one is starting with your big device and working down, I suppose. Yeah, it depends on your use case.

David:

I think the hidden assumption in that is that for a smaller device, it’s assumed that you’re going to be having reduced functionality.

Chris:

Yeah, I suppose that has generally been the assumption. And I guess the new thinking these days is that shouldn’t necessarily be the case. There may need to be rethought functionality, because you have less screen real estate. People are using fingers. They don’t have a full proper keyboard, et cetera, et cetera. But it doesn’t necessarily mean they should get a worse experience. Just a more suitable experience, I suppose, would be mobile first. Yeah, I guess that’s probably a much better way of saying it.

David:

Mobile also gives you access to a number of things that a desktop may not, such as location, or integrated cameras, or all sorts of things that might be appropriate, depending on the application.

Chris:

Exactly. Exactly. Yep. And sometimes, I’ve found, not necessarily as much with websites, more with mobile applications, but sometimes the experience can be better. With things like iOS and Android, you have the concept of a share extension which enables you to easily share links or files or whatever between other applications in the operating system. And macOS and Windows have that to a certain extent, but often developers don’t bother implementing it. Whereas, on mobile, it’s generally there. So sometimes, actually, you can get a better experience.

David:

So you mentioned tech journalism earlier. Can you define what the scope of that is?

Chris [15:48]:

The scope. Okay, well, to go back a step … So, the reason I sort of got into doing this book in the first place, is I actually use to edit the mobile channel for SitePoint. And that came from coming out of the CMS days I discovered way back when — I don’t know, 2009 or something — PhoneGap. Nitobi PhoneGap, as it was then, before Adobe bought it. And I actually found it amazing, just because it gave the ability for web designers to turn HTML and JavaScript and CSS into mobile-like applications. These days, now, it’s less needed. But in those days it was actually pretty ground breaking. That’s kind of where I started getting more into mobile and then into doing more native stuff, and things like that.

By the by, I was editing the channel for SitePoint and sort of broadened from there. I don’t write for SitePoint article-wise much anymore. I just don’t have the time, but I guess I cover maybe three main topics. One would be still a lot of mobile. One is a lot of actual things like distributed and microservice-based systems, like Docker and Kubernetes and things like that. And also, I’m quite into things like Blockchain and decentralized systems and stuff. But, again, as a journalist and kind of blogging about introducing people to a project, as I said already, I’m a generalist. So I tend to have lots of little bits of knowledge about lots of things, as opposed to being an expert in any one of them. But, it also involves going to some events, interviewing people, et cetera, et cetera. And it’s fun. It’s nice to meet people and hear their ideas, and if I can find a way of writing about it for somebody, then I will, basically.

David:

So does the journalism ever influence stuff you work on as a developer?

Chris:

To a certain extent. Sometimes in that, through those activities, I find out about something cool and useful that is worth bringing back to a project or to a team. But also, I mean, I tend to write for developers anyway, so I will always build example applications and things like that. But mostly in terms of just getting exposure to more ideas. And I guess, through the journalism, you don’t always just get introduced to technical concepts. You get introduced to the business as well. So hearing about a project and what they’re going to do in the future and not just the cool bit of code, but something actually that someone’s excited about because it’s got a good customer base and it’s stable and it’s got a future and, you know, just being able to make a few extra decisions about a project as well. If that makes sort of sense, I don’t know.

David:

Oh, absolutely. And it’s great to be in a position to help people find out about those things.

Chris:

Yeah.

David:

And you’ve also been doing a lot of public speaking, haven’t you?

Chris:

I guess, I did a little bit in Australia, but when I came back to Europe, for the next couple of years, it’s easier to travel to places, so I suppose just taking advantage of it as much as possible. I like to make an idiot of myself.

I mostly, these days, do a lot of talks on documentation and helping people understand how to document projects better, because most developers don’t like documenting their projects. But a few other things here and there. I’ve been doing quite a few talks on Atom recently, the text editor, because I kind of like it a lot. But mostly documentation talks these days. I’m kind of pretty happy in the documentation world.

David:

You get a lot of respect from me for that. I don’t think documentation gets enough attention.

Chris:

This is kind of why it’s fun doing as well, because there’s a much smaller sector, and you generally get that response.

[Laughter]

David:

So what are your bullet points on documentation? Just so the people out here can hear it. Pun intended.

Chris:

Again, it’s use case … and sort of user story — which, if you’re working on a bigger project, is generally being done at some point anyway. So, feed back into that. The project planning. The user story planning. And get an idea of who the audience are and what they want to accomplish. Not just write what you want to tell someone.

One tip that I’ve been giving to people a lot recently, that feeds nicely into SitePoint too — because ad-supported media tends to do it quite well — is good structure. Because people don’t read from end to end. In fact, certain cultures do, but the vast majority don’t. They just glance around and scroll backwards and forwards. And they look for certain things. So, if you have good heading structure, you have code examples, images, videos, whatever, they’re things that grab people’s attention. And then they read the text around it. And the reason, of course, ad-supported sites do this better, is because they need people to read it. So, they’re better at it. So you could learn a lot from them.

And then actually, I would say, take advantage of documentation being online. It doesn’t have to just be text. You can add interaction. You can add interactive consoles, videos, CodePen examples, et cetera, et cetera. That stuff helps a lot.

That’s not a complete list by any means, but they’re just the three that came to mind immediately.

David [20:32]:

It sounds like it’s the sort of thing that can also play into the work that you do when you publish articles out and basically build up your own audience too.

Chris:

You learn a lot from each of the fields, so yep.

David:

That’s fantastic.

So, how can our listeners find you online and find out more about the things that you’ve been working on?

Chris:

My website, where I kind of aggregate everything I do, is GregariousMammal.com. I have a nickname of Chris Chinchilla, and gregarious mammal was — somewhere I read — the dictionary definition of a chinchilla, so it just kind of stuck. You can find most of my articles and podcasts and talks aggregated there. And, you can also probably hear me talk, way too much, on Twitter @ChrisChinch as well.

They’re probably the two main places to find me.

David:

Fantastic. Well we’ll definitely put all of that into the show notes. And thank you so much for joining us today on the Versioning Show.

Chris:

No worries. Thanks for having me.

[Musical interlude]

David:

So one thing that came out of a little chat that Chris had with us afterwards was that he and his wife actually have a podcast.

Tim:

Yeah, they do, and it sounds interesting. They both talk about tech journalism — which, well, I’m not entirely familiar with. So, I do write for SitePoint every once in a while, but outside of that, I know there’s Wired and TechCrunch. I don’t really pay too much attention to those sorts of things. Kind of just get all of my information from emails and Twitter.

David:

I know what you mean. And I tend to keep most of my writing pretty evergreen, but there’s a lot to be said for writing about the cutting edge of what’s happening in tech, because something is changing constantly and there’s always something new to write about.

Tim:

Yeah, there really is. There’s at least ten articles every time Chrome publishes a new version.

David:

One of the things that I liked about the way he approaches his writing, is that he seems to go and write about the things that he’s interested in, even if they’re not the latest thing, or the coolest thing. For example, he’s talking about the Atom text editor. And Atom’s been around for while, but he feels like writing about it now because it’s something that he’s into, and he finds an audience for it.

Tim:

Yeah, and things like that, there are always tips and tricks you can share to just help people out. I mean, your text editor is a thing that you use every single day. I’m probably, hopefully, if I’m doing my job, using my text editor more than I’m using my browser. And, every single time someone shares a tip on, Hey, you can do this in Sublime or VS Code or Atom, it transforms my productivity in such a way that I get ten times more work done, because now I know how to use multiple cursors or there’s things like that.

David:

And it’s an example of how you can take whatever you happen to be working with — PHP, Atom, responsive design … There’s relevance to what he’s talking about. And, the relevance continues, even if the technology isn’t the latest thing making headlines these days.

Tim:

Speaking of responsive design, I’m really glad that he took the time to properly define it. Because, I have to remind myself every once in a while as well, responsive doesn’t mean squishy. Responsive means that it literally responds to every device that is trying to use it. That’s a really big concept. And it’s so much more than CSS media queries.

David:

And, well, I mean you, I believe, have done some work on responsive images as well.

Tim [23:46]:

Yes, back in the day. No, maybe two or three years ago. But, yes. When you think about how you want to, I mean, there … Perfect example. Perfect use case for a responsive design. The image in a squishy sort of frame of mind, it doesn’t matter. It takes the width of the device that’s trying to use it. But, it also takes all the bandwidth of the device that’s trying to use it. And, so, from a responsive point of mind, you don’t want to load the same size image for every single device. Some devices only have basic DPI screens wherein they can only load up a simple resolution. And then others have crazy, four times the resolution that another device its same size would. And you have to know, all right, I want to load in a different image for that, but also, I’m a little bit worried about bandwidth because this image is huge. What do I do here? There are a ton of things just to think about in terms of responsive design for images.

David:

One of the things that, when I was reading his book, that really caught my attention, was how many different media query options there are. How many things you can query on. Like, it never even occurred to me to think about bit depth. Is this a monochromatic device that I happen to be sending information to? There will be situations where somebody might be reading on a Kindle, for example. Or it might be greyscale, or whatever. And you want to be able to present an experience that’s appropriate to that device. Or you might even be targeting that as your primary device. In which case, other browsers might be the secondary. But the primary would be whatever one has that particular attribute.

It’s amazing how many different things you can query on.

Tim:

Yeah, there’s orientation, ambient light. Those are two that I’ve almost never used. But, in different applications they make a lot of sense. For example, if you are displaying a map that someone is going to need to use while they’re biking or walking somewhere, right? You want to pay attention to, is it dark outside? Because then I might want to change the visual properties of this thing so it’s easier to look at and then look back at your surroundings, in the dark versus in the daytime.

David:

Sure. When you said a bike, I’m just imagining an environment where the acceleration of the user might be something that you would want to change how you present things. That could be in a VR environment, for example.

Tim:

Yeah, there’s just so much to think about there.

And then, we also touched a little bit on mobile first design. Which, I’m going to posit … I keep posit. I don’t actually know if that’s a real word. I’m going to present a question. Tell me what you think.

I’m wondering if mobile first shouldn’t be a term that’s used anymore. Because, it’s not just mobile, right? In terms of actual design for a product, you essentially want to design least capability first, right? Because, from a mobile first perspective, mobile could really mean anything. I would think what you would really want to design for is least capabilities to greatest capabilities, right? If I am trying to look at something from a smart watch, if people are still into that, I’m only going to want to interact with an application through notifications. I’m not going to want to have to traverse using three inch screen, the size of my wrist, through a complex application. I’m just going to want to say yes, no, send to my email, tap, tap, tap. That’s all I really want to do.

But if I’m on that same application on my — what is it? — three foot wide monitor, I have all the room in the world, and there’s so much that I can do there.

David:

It’s true. Well, it sounds like it’s the distinction between progressive enhancement and graceful degradation. That’s the progressive enhancement argument. Where you want to take the least capable device and then add on features depending on the context in which the user happens to be. As opposed to the graceful degradation, where you start with all the features you might want, and then strip them away appropriately, depending on the context. And I think either one works. It’s kind of about how the designer thinks about the situation.

Tim [27:46]:

I would say I prefer, very much, the progressive enhancement approach. Because, I’ve seen a lot, wherein product managers tend to think of mobile as being, as meaning that you don’t need the same amount of features as desktop. And I don’t necessarily like that idea because, for example, there’s quite often, my wife and I are sitting on the couch and watching TV and I’m doing something stupid on my phone, like looking at some bank statement or something, right, that I could obviously just grab my laptop and do, but at that point in time, I have my phone in my hands. I just remembered I needed to do something, and then I find out that I can’t do what I wanted to because someone decided, Hey, this feature doesn’t need to exist if you’re looking through it on a phone. And that doesn’t always apply.

David:

That’s absolutely true. But I wonder, if that’s more of an engineer’s perspective versus the designer’s perspective? Because, I think now about the conversation that happens between the designers and the engineers around development of a product. And the designers are thinking, by default, I suppose, about all of the possibilities that a user might want to use to interact with an application. Whereas the engineer is thinking about how to build these things. Maybe it’s something we should have asked Chris about while he was with us, how you coordinate that conversation, because when you talk about responsive design, the designer is a critical element of that conversation. And, where’s the designer’s perspective? Are they thinking the big picture about every possible feature? Or should they be thinking first about the very minimum, viable product?

Tim:

That’s true. And to start, I always give my designers a simple rule that I try to keep followed as much as possible. And that is, features should not depend on the size of a user’s screen. Because, if we are speaking in terms of capability, at this point, the phone to my right has almost all of the capabilities that the device that I’m using for this podcast right now has. Almost. Aside from, you know, a full keyboard, that I can type with two hands, right? In that case, if I am working on an application that’s suppose to work on both of those devices, I should be able to do everything, within reason, on either device, right? If that’s uploading photos. Well, that’s a thing I can do. You know, location API, that works. HTLM5 thing. There, right? But if you say, all right, we should remove this button because we’re out of screen real estate, well, then I would say we haven’t accurately solved the challenges for designing this specific product. Because the only reason we’re dropping the thing is the screen size is too small.

I tend to see that as a bad option. A perfect example for this at my job: recently, we were looking at how to size a ledger for an activity history, right?, on a mobile device. Because it’s tabular data, but on a mobile device, it’s tables. That gets really weird. How do you display that? And several times, the option came up, We just shouldn’t let the user see this because the screen size is too small. And I would always say no, we cannot do that. We can’t do that because screen size should not limit a user’s ability to view this important tabular data. We should present the table in a different way. Because we don’t get to decide what device our user gets to use in order to interact with this feature. That’s not really a fair thing.

David:

No, certainly it’s not fair to the user, and it depends on the marketing goals of the product. I mean, this kind of gets back to the dark patterns, where it’s a question of whether or not we want to encourage users to use one device over another by making the experience on one device handicapped. Making it more difficult.

Tim:

I never think that’s a fair thing to try. Specifically because, what if I can only afford a mobile phone and I can’t afford a second computer? Or, I’m living in an area where the infrastructure for, I guess, cables — is that how the internet works? I should probably know! — isn’t there.

David:

It’s tubes, Tim. It’s tubes.

Tim:

Right, right. But the 3G infrastructure is, and so, everybody uses mobile phones. Making that sort of call, sitting in a nice office in New York or San Francisco or wherever you happen to be, when you have access to both of those things — I don’t think that’s a fair assumption to make.

David [32:00]:

Dare I say that you might be able to sell your advertisers on the fact that our users tend to be people that have higher-end devices and live in places with higher bandwidth. So your ads aren’t going to be clicked on by people who can’t afford your product. That’s just evil.

Tim:

That is pretty evil.

But, I mean, if you think of a product like Wikipedia, for example, you can learn how to perform an appendectomy on Wikipedia, which in some cases, might be life saving information, right? If Wikipedia decided that you have to download the Wikipedia app to view appendectomy information on your phone, that would really suck. For some people. There’s probably someone out there who has performed an appendectomy based off Wikipedia information.

David:

Probably.

Tim:

I mean, I hope not. That situation had to have arisen.

David:

Yep, and to shout out to Hampton Catlin, one of the guys we interviewed a while back, who was the person who designed Wikipedia mobile.

Tim:

Yeah, and thank goodness he did it correctly. Because I would think that’s the perfect use case for why you shouldn’t take away core functionality based on the size of the device.

David:

Mm-hmm ([affirmative]), and a perfect example of responsive design.


Tim:

Well, thank you so much for listening, everybody. We always getting to talk technology with all of you.

David:

We would also like to thank SitePoint.com, and our producers, Adam Roberts and Ophelie Lechat, with production help from Ralph Mason. Please feel free to send us your comments on Twitter — @versioningshow — and give us a rating on iTunes to let us know how we’re doing.

Tim:

We’ll see you next time, and we hope you enjoyed this version.

M. David GreenM. David Green
View Author

I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

Tim EvkoTim Evko
View Author

Tim Evko is a front end web developer from New York, with a passion for responsive web development, Sass, and JavaScript. He lives on coffee, CodePen demos and flannel shirts.

PodcastRalphMsitepointversioningVersioning Show Episodesweb
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week