Transcript: Images in a Responsive Project

by Tim Wright

This is the transcript for The Dirt episode: Images in a Responsive Project

Tim: Hello, and welcome to Episode 1 of “The Dirt.” I am your host,
Tim Wright. And I’m with my coworker/fellow developer/designer – what else?

Steve: Renaissance man.

Tim: Renaissance man, Steve Hickey. And on Episode 1, we wanted to kick off
by getting into some responsive design. It’s a pretty hot topic right now.
We don’t want to tackle the entire thing, but we want to tackle different
pieces of it. And today, I think we’re going to talk about… What are we
talking about? Images?

Steve: Preparing images for responsive projects.

Tim: When we’re getting ready for a responsive project, there’s a lot of things to check off the list. You have to set up your environments, think
about your break points in the design. I don’t know if you design each
individual break point or if you do it naturally, but there’s a lot of
stuff to setup, and images is one of the things that you need to think
about.

The normal stuff we do when we’re setting up a website, whether it’s
responsive or not – we want to cut down on the HTTP request, and that’s
obviously a really big deal. And sprites have been a great way to do that.
They’re very difficult to manage, I think, but there’s some tools to help
you create them and whatnot. I know I have some thoughts about sprites,
but, Steve, what do you think?

Steve: When I start off a project, and things are still a bit more fluid, I
tend to work without sprites, as I’m starting to get used to how
everything’s going to come together, whether or not icons are going to
change frequently or not. As I get towards the end of developing a project,
when things are more certain, when I know what icons I want, when I know
what sizes I’m targeting, I’ll tend to move those all into their own sprite
and then readjust my styles to compensate for it. It might be a little more
work overall, but it allows me to work faster during the beginning of
development.

Tim: Great. Yeah, I agree. A lot of times, though, I’ll leave them all
completely separate. And then at the end, I’ll load them up into Sprite Cow
or some tool that helps out, as it’s super irritating to have to update a
sprite. There’s different ways to space out the images in the sprite,
depending on the style development, but it’s just always a pain, I find.

But anyways, in a responsive project, dealing with images, there’s always
obviously the background images and the icons that we’re loading into
sprites, but there’s also the content images that are always an issue,
because right now, the normal way to do something like that is we load in
the largest image that we have for a large screen. And then we’ll just set
a max of 100 on it, and then shrink it down. I think that’s pretty much
standard.

Steve: Yeah, that’s the method I’ve used before. It’s great as far as
simplicity goes. It’s pretty bulletproof. But the real problem comes in
when you have mobile devices. If we go with a mobile-first methodology for
dealing with our development, we’re really feeding the largest file size
item possible to the device with the lowest bandwidth, it doesn’t make a
lot of sense. But there also aren’t a lot of good ways around that right
now.

Tim: Right. There’s a few things that are up-and-coming, but I think by and
large, unless you want to rely on JavaScript really heavily for those
images, that’s pretty much where we are. And there’s some traction with the
picture element, I think. I like it. I like parts of it. Parts of it I
don’t like. For those of you who are not familiar, picture element is a
polyfill for dealing with different image sizes. And based on the screen or
the window size, it’ll load in a different image. I think Steve is a little
more familiar with picture element than I am.

Steve: Yeah. Picture fill would be the polyfill. And picture element itself
is now a proposal that may actually become an HTML element that we can use
in the near future, the idea being that the picture element behaves very
similar to audio and video in the HTML5 spec. You’re defining multiple
sources within the picture element, and the last source is just a standard
image tag, so anything that doesn’t understand the rest of the elements
that have been called will just default to the image tag. Within it, you
can call different sizes, and then you can also specify the circumstances
under which those sizes are used, and it’s based on the same syntax for
media inquiries, so you don’t have to relearn anything to make it work
properly.

Tim: So, I was actually researching picture element a little bit last night
in preparation so we could not sound like a moron when I was talking about
it. And something struck me as not negative, but something I didn’t really
care for. So, you have audio, video, and now picture, really. So, we’re
trying to get that element in there, and they’re all media types. So, I was
thinking, why wouldn’t we just use a media element and a type attribute?
Thoughts, comments?

Steve: That’s an interesting approach.

Tim: I mean, you’d have to rewrite everything that’s been done, basically,
to do something like that, but it makes sense. I mean, they’re all really
media, right? Some of them are more awesome than others. We’re in audio
currently, as you’re listening to this, but it just made sense.

Steve: Maybe it’s time for you to make a community group, as if you didn’t
have enough on your hands already.

Tim: And you’d piss everybody off. We want more stuff thrown into the spec.
We want just terrible browser support for everything we do. Also something
I dislike about picture, but it has a nice fallback. Have you ever used it
in production?

Steve: I have not used it yet, I regret to say. It’s one of those things
I’ve been meaning to try for about three or four months now. I haven’t been
able to find the time to apply it to my personal website, but in the near
future I will be. I’ve read articles from a few people who’ve tried to
implement it so far, and they say it’s actually very simple and very
intuitive, so that gives me some hope for it.

Tim: Yeah, I think it’s pretty decent. Another thing that I’m not super
pumped about is that it’s using screen size to determine the pictures that
are loading in. And it sort of makes sense. We’re thinking about responsive
design when we want to resize the browser, and then it pops in a new image.
But with a large image versus a small image, the problem isn’t really the
screen size, it’s the available bandwidth, really. And we’re just assuming
that if you’re coming on a small screen that the bandwidth is also going to
be constrained. That’s not always the case. Some people just browse with
smaller windows. I know when I have two sites up next to each other, I’m
not on a constrained bandwidth, but I am on a small screen. When I’m on my
phone in the office, it’s on Wi-Fi, and I’m not on constrained bandwidth.
When I’m at home on my iPad, I’m not constrained. It’s really when I’m on
different networks.

Steve: Well, I think there’s three factors at play here. We’re trying to
find a balance between optimizing for a device screen size, the actual
pixel density, and then bandwidth. Right now, we’re making an approximate
guess based on the screen size and just assuming that smaller screen sizes
equal lower bandwidth, but that’s not always a safe assumption, as you’re
pointing out. The problem is, how do you write a syntax that balances all
three of those that doesn’t take a PhD to understand?

Tim: Right. What I wanted to get into after that was the WC3 specification
for network information. And it’s something that I think is super cool, but
has almost no support. I feel like it fills in the gaps, where picture
element sort of falls to the wayside. And what it is is it’s a way to check
connection type, so you can check against EDGE. It’s not called EDGE, but
they have numerical values associated with these connection speeds. It’s
one to four right now. It’s basically EDGE, 3G, 4G, Wi-Fi. And I guess
undefined would be the other one.

And I think that’s really great, and it could pick up some speed if it got
better support. You load in the smallest image by default, so if there’s no
support for it or it’s unknown, you just load in the smallest one. And then
if the connection speed comes back on Wi-Fi, you load in the bigger ones.

So, you can couple small screen with the picture element with this
bandwidth detection. So, you could load in a really high quality small
image and really take advantage of some of the pixel densities, like the
Retina.

I know when we’re dealing with Retina a lot, if you’re loading in a smaller
image, it’ll get all pixelated. Or if you’re loading in an icon super
small, it gets really pixelated. And that’s a problem. These interfaces
look like crap, and I completely blame Apple for it.

Steve: Yeah. They’ve created these amazing high pixel density devices.
They’ve completely opened our eyes to being able to view the web in a new
way. It’s wonderful for typography. I just got a Retina MacBook Pro
recently, and looking at typography on those devices, it’s insane. I don’t
ever want to go back to the lower resolution devices. But the images on the
web just look terrible right now, because people aren’t optimizing for it.
And there are so many factors at play that it’s really hard to figure out
how to do that.

So, if we ignore photographic quality images for the moment, and we talk
about things like just plain old icons, for example – things that are
rendered as mathematical vectors in many programs – there are some good
ways to solve that problem. We’re looking at things like SPG and icon
fonts. There’s ways of handling that problem, as opposed to being
restricted to pixels.

And I think the advantage there is that we’re talking about using a single
source for those images as opposed to specifying multiple sources, and then
specifying rules for selecting among those multiple sources. So, it does
make it a bit easier from a development perspective to keep track of your
resources and to call your resources. And from a user perspective – and
they should never know what’s going on – but if you’re on a really crisp,
high resolution display, you’re going to see a nice, crisp icon. If you’re
on a low resolution display, you’re going to see an icon that fits your
device.

Tim: And I would like to say that that was an awesome segue into SVG and
vector. And just the other day – it was actually yesterday, I think – we
were dealing with a vector logo. I forget the company. I probably shouldn’t
even say the company, but we were dealing with a vector logo, and it was
working great on local host when we were developing it, but when we pushed
it up to the server, it wouldn’t render. And after a little bit of
research, we found out that you do need to turn on the SVG MIME type in
Apache. We were dealing with an Apache server. And it won’t just render. It
will render all code. And that can be a problem. It’s most definitely a
problem, because it won’t render in the browser.

Well, the quick fix – we used an [HT] Axis file, added the MIME type, and
it rendered fine. We had some problems with rendering the gradients, which
we really didn’t solve. We ended up using a PNG. But I think that was
interesting, that Apache out of the box didn’t have SVG support. And you
don’t really think about that. You think of browser support as frontend
folks. Like, oh, this isn’t going to work in – is it IE8 or IE7 that SVGs
don’t render?

Steve: I think it’s IE7.

Tim: It’s one of them. it’s either one of them or both of them, I guess.
But yeah, you don’t think that the server actually comes into play on that.
So we sat down for an hour trying to figure out what was going on, and we
figured out that it was Apache, but it was a pretty quick fix. This was
linked in the style sheet, so we’re using it as a background image. And
there’s the differences between using SVG as an embedded image and using it
as a linked. And there’s actually an export setting in Illustrator that we
were using. I’m not sure what the actual code difference is, and I’m sure
you people can’t see my hand gestures, but they were super helpful right
there.

Steve: From my perspective, I’ve only fiddled with this a little bit so
far, but I really prefer using the linked SVGs, even though it’s an extra
resource load, because putting that markup into your HTML files, it really
clutters things up. It gets really messy really quickly, and it becomes a
lot harder for me to read things quickly to go into another person’s code
and make edits. So, even though you are loading an extra resource, there
are some really significant advantages to separating that out into its own
file.

Tim: It’s an extra resource compared to an embedded SVG, but normally, if
you’re using just a PNG, then it’s the same.

Steve: Yeah. It should be we’re already going to use an external resource,
anyways, so then you’re not limiting yourself in any way.

Tim: So, then you have the weight of the HTTP request, which is normal, and
then the download of the actual image. And I’m not sure what the wait
difference is, but it’s probably negligible.

Steve: Yeah. SVG works great for things – really complex pieces of linear,
like logos, but then, if you’ve got something simple like icons, SVG also
works great, but there’s a better solution, I think, which would be icon
fonts.

Tim: I love icon fonts.

Steve: I’m not in love with them yet. I’m in love with their potential.

Tim: I’m in love with them. I want to marry whatever icon font. Yes. We
have someone in here signaling that I’m going to knock up an icon font.
It’s probably going to happen.

Steve: That got weird really quickly. But I love the potential of icon
fonts. And I say potential, because right now, I think one of the problems
is that the people making icon fonts aren’t necessarily the same people who
are good at making fonts. They don’t know all the little tricks, like how
to make sure things are hinted probably from the beginning, how to actually
go out and create the extra files required to do detailed hinting at
different sizes.

And so, you load up an icon font on a Retina display, it’s beautiful,
because you don’t have to worry about pixel density there. You load it up
on a plain old 72 DPI display, and if somebody didn’t do their hinting
correctly, you have attempts by the screen to render half pixels, which
cause fuzzy edges and things like that. And those really bother me as
somebody whose background is primarily visual design before getting into
the development side of things.

So, once people start hinting these properly, I’m going to be really
excited about it. And some people have started this already. I’ve seen a
couple examples where if you use the font at 16 pixels or any multiple of
16 pixels, it looks really good. But I think we need to get a little
further down that road of optimizing fonts for various sizes before they’re
going to be very, very useful.

Tim: My only hang-ups with the icon fonts – and I do like them a lot – is
when they’re actually embedded into the document. Chartwell is the example
that’s fresh in my head. It’s an icon font that renders charts – pie charts
and line graphs and whatnot. It’s actually really cool. But the way it’s
implemented is you’ll do a string of numbers that add up to a chart. And
it’s not super accessible. It’s better than using SVG out of the box to
render a graph, but that string of text doesn’t mean a whole lot.

And then you can add on an “S” or something to make a donut. And there’s
little things like that that don’t totally make sense. It’s super
lightweight. But I do like it overall. And there’s using icon fonts when
you’re embedding them and just wrapping a span around the item, like just
the letter “A” to render a home icon, a house icon. Stuff like that doesn’t
really make sense when a screen reader’s going through it. What we’re
falling back to is pseudo-elements and then loading the Unicode value into
the pseudo-element and that renders the icon pretty well, and it doesn’t
show up in a screen reader. So, I think we’re going in the right direction
with these fonts.

Steve: I’ve actually seen a really interesting example lately. I can’t
remember the name of it off the top of my head, but I’ll look it up after
this, and we’ll post the link along with this audio. And what you do is you
type out the word for the picture icon that you’re trying to call. Like,
say you want a home icon. You would type out “home” and wrap it in a span
and apply the font to it, and it recognizes the sequence of letters,
“home,” as something it wants to apply ligature to. And that ligature is
the icon for “home.” So, that has the potential to be pretty accessible.

Tim: I like that. It’s pretty cool. That would be really neat, actually. As
long as it’s just flat out the icon, I think that would be great. If we
have that normal “icon, word, icon, word” thing, it would be a little
clunky, because when you were reading through it, it would be “home, home,
about, about, contact, contact.” But that seemed pretty cool. I don’t know
why you haven’t told me about that, actually. I’m a little put off.

Steve: You’ll live.

Tim: So, I think that was pretty good. That’s how we prepare images. That
was pretty smooth, I thought. Right? We’re pretty good at this.

Steve: Yeah.

Tim: Pretty good for the Episode 1 of The Dirt. We also had some questions
that we wanted to get into, some listener questions. I’m going to call them
listener questions, even though this is Episode 1.

Steve: Solicited questions. We’ll call them solicited questions.

Tim: Yeah. So we got some questions. The first question we have is actually
I think something that Steve could probably tackle better than I could.
He’s primarily design, and I’m primarily development, but the question
comes in from Tim (another Tim, not me): “Steve, once you have a basic
wireframe design for a new design, how do you approach designing individual
sections like the main body or the content area or a particular box for the
homepage? Do you start with a 10,000-foot view?”

Steve: What is that?

Tim: General look and feel first. Like, what do you use – fonts, colors?
“What’s his process?”

Steve: Well, I don’t generally jump from a wireframe straight into design.
There’s a couple of intermediary steps that I go through first. The initial
thing I like to do is collect some inspiration. I’ll call to websites like
Dribble or siteInspire and take a look at what other people are doing and
see if there are useful design patterns that I can apply to what I’m doing.
And this research sort of defines what visual approach I want to take to
the project.

I’ll usually collect these images, and then take the ones that are similar
to each other and associate them all together. And then I can talk to the
client about those images, get a feeling for what look and feel they’re
interested in. And at that point, I’ll probably start sketching, doing a
couple little composition exercises in Photoshop or playing with some type
to see how it’s going to look on the page. Everything sort of loosely
coalesces into the final design.

Tim: “Coalesces?” That is a heck of a word.

Steve: It’s a good one, though. And it all sort of comes together slowly
and gradually. I generally move from wireframes to inspiration to sketching
to working with the basic layout and starting the filter and design
patterns in Photoshop. And I always start in black and white. I don’t work
in color until I’ve got a decent idea of whether or not the page layout and
composition is working. Because if a design doesn’t work in black and
white, I don’t think it’s ever going to work in color, no matter how hard
you try. So, I don’t really have a defined process. I more have exercises
and pieces that come in at the appropriate time, and hopefully, the result
is a really nice, sharp design at the end.

Tim: So, when you’re working with a client, doing a lot of iterations, when
do you find that it’s easier to just jump into the browser and change stuff
in code?

Steve: I guess the point where it becomes easier to start working in the
browser is when I find myself duplicating a lot of things over and over in
my Photoshop file. I tend to try to get on the browser as soon as possible.
Photoshop isn’t really a place where I do high definition compositions. I
usually just get the basics down, move into code, and work from there.

And the really nice thing about that is that if I decide I want to change
all of the H1s across my entire site, it’s as simple as changing the style
sheet, as opposed to going into every layer or folder or Photoshop file
that I’ve created thus far and changing each style individually one at a
time. And to be fair, Photoshop CS6 has actually made this a little bit
easier. You can actually use type styles now, but it’s not anywhere near as
powerful as a plain old style sheet at this point.

Tim: Love it. Absolutely. I love it. That was a good one.

Steve: How about a question for you, Tim?

Tim: Question for me. Okay. Let’s find one for me.

Steve: Simple one: Sass or Less?

Tim: Sass or Less? I use Sass. I have used Less. They’re so similar that it
really comes down to a syntax preference at this point, I think.

The reason I picked Sass was I was speaking in New York at Future of Web
Design. It must have been a year ago. What’s this, 2012? I think it was
2011, November 2011. And I was having dinner with one of the core
developers of Compass, and he just completely sold me on Sass. I wasn’t
really working in preprocessors at that point. So, I was working on just
kind of miscellaneous, small projects. I was working for Boston University.
I just sat down with him, and he completely sold me on using Sass. Not so
much on Compass, but he did sell me on using Sass.

I liked the syntax. I liked the way they were using mixins. I think there
was a problem with the way mixins were handled in Less at the time, and I
made a mental note to myself that I was sold on this technology, and I’ve
been using it ever since. And I really haven’t revisited it. Recently, I
used Less, and it’s fine. I mean, you get used to it. They’re so similar at
this point, and I think Less actually has a little bit more market share
than Sass.

Steve: Yeah. I mean, I have tried them both. They’re very similar. I prefer
Sass, as well, mostly because one of the tools I use that’s available for
it is a tool called Bourbon by a company that’s local, nearby to us, called
thoughtbot. And it allows you to use mixins to take care of the vendor
prefix problems with CSS3 properties.

What I like about Bourbon is that it’s very vanilla. It’s as close as
possible to writing the actual CSS3 syntax. That’s not available in Less.
If you look at something like Twitter Bootstrap, which is built on Less,
there are a lot of mixins built-in that allow you to do things like define
CSS gradients and whatnot, but they have very, very bad limitations, like
you have to specifically choose a mixin for a horizontal gradient or a
radial gradient versus just being able to type in the gradient syntax and
have it generate things properly. So, that’s one of the reasons I prefer
Sass. It just keeps my workflow closer to not having to rely on external
tools as the spec develops.

Tim: I think the mic may have caught my stomach growling. I’m not sure. But
we’re doing this around lunchtime.

Steve: Yeah, it might be time to call it quits and take care of that
problem.

Tim: We have – how much time do we have left? We’re on 24. So, let’s just
do one more question. Oh, here’s a good one. Photoshop or Fireworks?

Steve: This is going to be a little bit of a debate between Tim and I, I
think.

Tim: I am Fireworks, and I’ve been Fireworks for six or seven years. But
maybe eight years now I’ve been Fireworks. Since it was back in Macromedia.
But I’ll defer. Have at it.

Steve: I prefer Photoshop, and most of our industry, as far as I’ve been
able to determine, prefers Photoshop. And many people actually think that’s
wrong. Photoshop is software specifically for editing photographs.
Fireworks is software specifically for editing and preparing images for the
web. And so it seems natural to use Fireworks.

Now, I’ll admit that Fireworks has a lot of really impressive features that
I prefer over Photoshop’s features. You can change vectors really easily
without destroying them. You can apply styling to elements and typography
in a way that’s much closer to actual CSS. The most recent version of
Fireworks will allow you to export those styles in prewritten CSS, which is
really impressive.

Photoshop, however, recently has incorporated some features that are very
important to web design. And I think this is because Adobe has been
realizing that many of its customers are using it for web design as opposed
to just plain photography. And I think the other important thing for Adobe
is that Photoshop costs twice as much, so it makes sense to support that
and make that the preferred editor.

Fireworks tends to be buggy, in my opinion, and I don’t like having to
shift my workflow to deal with bugs. I prefer to use something that’s a bit
more stable. It’s also pretty clear to me that Adobe intends to put a lot
more development effort and time behind making Photoshop a solid program
than Fireworks, so I want to stick with the software that I know is more
likely to be around in 10 years. I’m sure Fireworks will still be around in
some form, too, but who knows what kind of effort’s going to be put into
it. So, I’m basically just sticking with what I know.

Tim: So, here are the top 150 reasons that I like Fireworks. Number one,
way cooler name. Anyway…

Steve: So, that’s all you’ve got? I guess I win.

Tim: I have one reason. No. Way back when I first started, it was what I
learned on, actually. When I very first started web design, I was in
Macromedia Dreamweaver. I think Dreamweaver MX, I think, at that point.

Steve: I’m so sorry.

Tim: And Fireworks. Because where I learned it, that’s the package they
had. So, I learned through that. This is a little bit of a tangent, but
Dreamweaver was actually a great way to learn all the CSS properties. And
if you’re hand coding in it, I mean, it doesn’t really matter what you hand
code in, but they keep the code completion very up-to-date. Now, there’s a
couple people in the office that still use it, too. And I try not to look
down on them. I try very hard.

Steve: I make no effort to hide my disdain.

Tim: But I’m in Coda now, but this is totally a tangent. Anyways, I was
using Macromedia Fireworks, and I took a course in Photoshop, a complete
course in Photoshop. I got an A in it. I’m very smart. Well, that was a
funny story, actually. I was the only student in the class, and the teacher
was one of my coworkers at the time. I was taking classes part-time and
working, and the teacher was my coworker. So, I got an A in it. But I did
know the software very well, also.

Steve: Favoritism.

Tim: But I thought that the interface for Photoshop was really clunky, and
it was a lot easier to navigate in Fireworks. And there was a lot of
features in Photoshop that I just wasn’t using as a web person. The
Fireworks stuff was way more geared to the web, so I tended to lean towards
that. And I’ve just kind of stuck with it. And it’s gotten better over the
years. Since Adobe acquired Macromedia they’ve been slowly syncing up the
softwares. And it’s at a point now, where if you’re in CS6 in Photoshop and
you build out a comp, you can open up that in Fireworks, and it’s rare that
there’s something that got messed up.

Steve: I think there’s still some compatibility issues. And I don’t
necessarily disagree with anything you said. I do think Fireworks has a
much better interface for designing the way we ought to be designing for
the web. I just feel like the support for Photoshop is better. And
recently, they’ve been showing a commitment to moving web-centered features
into their program, so I’m sticking with what I know because I feel like
their patterns of current behavior indicate that that choice isn’t going to
be a problem. If I thought it was going to be a problem, I’d switch to
Fireworks. But I guess we’ll have to disagree to disagree.

Tim: What about moving towards designing in the browser?

Steve: I mean, I’ve always tried to do that. Honestly, what I really like
is new third-party software that completely rethinks the flow of how we
design things for the web. I would love to use something that’s not
Photoshop or not Fireworks that is really geared towards how we work. But
maybe that’ll happen in the next couple of years.

Tim: I hope so. That would be great. I mean, I like designing in the
browser when I can, but sometimes it’s nice to break out and to not have to
worry about how you’re building something when you’re designing it and you
find it a little bit constricting.

So, I think that’s all the questions we have. I don’t want to keep
everybody forever.

Steve: Thanks for bearing with us.

Tim: Thank you if you stuck through the whole time. That was great. I do
feel like I’m a little more credible because I’m wearing a tie today to the
podcast.

Steve: Can any of you tell he’s wearing a tie?

Tim: I’m wearing a tie. I will Tweet out a photo of myself wearing a tie.

Steve: The tie is a lie.

Tim: It’s a great one. All right. I think we’re going to actually take the
picture while we’re recording this while I’m wearing the tie.

Steve: Timestamps can’t be traced to it.

Tim: All right. We got it.

Steve: All right. I think we’re going to have to wrap this up.

Tim: Yeah. I think that’s about it. So, next week, we’ll do something else.
We’re not sure yet. We want to keep the topics pretty fresh, but tune in
next week for Episode 2 of “The Dirt.” Thank you for listening.

About Fresh Tilled Soil

Fresh Tilled Soil is a Boston-based user interface and experience design firm focused on human centered digital design