Jonathan Snook: Thank you very much.
Jared: And we have Steve Smith, who is very famous from all the work he does at Ordered List. I was just teasing him that he releases a new product every 15-20 minutes from there.
Steve Smith: [laughs]
Jared: He is just world-renowned. They built the cool Harmony. It's a CMS-like thing. CMS? It's CMS. CMS, hosting thing, yes?
Steve: Yeah, yeah. Website management.
Jared: Website management, CMS, Harmony thing. It's really awesome. It's what every designer needs to be building their system on. He's with us today. Hi, Steve.
Steve: Hi there. How's it going?
Jared: Going well. So, you all are in the process of putting together this great workshop, which people are very excited about, the Sidebar Workshops, which you're going to be doing with Dan Rubin and Bryan Veloso. It's this day where people can actually become a master in the art of creating great websites, and learn what it takes to get from being a good website designer to an awesome website designer.
You guys sort of bring the deep-coding parts of it. Bryan and Dan, they're just the froufrou designer types, but the work gets done with the coding. Part of, I know, what we've been talking about with this workshop is sort of the tricks that go into it, and I thought today you might have a trick or two you could share with us that has been entertaining you lately. Jonathan, is there anything that you discovered or been doing lately that you feel is pretty cool?
Jared: You've been working at Yahoo for the last few months now, and you've been really getting to get into the deepness of HTML5 and all that, yes?
Jonathan: Yeah, absolutely. It's been, actually, a really great experience at Yahoo. It's been, actually, just over a year now, so time flies.
So my job is lead prototyper, and, as a result of that, working with designers, working with all the Photoshop mocks that they send us, and then building out these lovely prototypes that we then work with engineering to actually integrate. It's impressive that the approach we've taken, we actually see a lot of our code on the prototype level is not throwaway stuff. This is stuff that we actually get implemented in engineering, and we do all the interaction design.
And it's been fantastic to work in. It's a lot of CSS3, a lot of HTML5. We are really trying to stay ahead of the curve, and we've seen some huge benefits as a result of that. To jump on that bandwagon and see the fact that we were actually able to cut down the size of our front end by 30 percent, that's a huge difference, and we were able to do that because of the aggressive approaches that we were taking.
Jared: I'm interested in this, right? So, you're cutting down on size, and you're speeding up your development. There's got to be a downside to all this, isn't there? Is there a learning curve? Or is this thing like the perfect solution that we've all been waiting for?
Jonathan: It is nirvana.
Jonathan: No, it's not nirvana. We begin to recognize that, yeah, we have all these new tools, but there's always these little edge cases, these little things that pop up. It's been a fantastic learning experience.
I think that, when we work on, certainly when I was freelance, working on a project that tends to be fairly limited in scope--English only, an audience maybe of a few hundred thousand people--is completely different than working on a project where 350 million people are going to use it, that it's being used in 40 different languages, and having to deal with all those different environments. And it's interesting to see where these little edge cases pop up. You see all these cool tricks, like, "Wow, that's a great trick." But then we start actually seeing the responses come back and saying, wow, this actually breaks in this particular case, or it actually breaks in this other case, and having to come up with those techniques to really work around that.
So yeah, sometimes we get to use the new toys, and sometimes we can't. And it's frustrating, but exciting at the same time.
Jared: That's really interesting. You've got all those users, and immediately my mind turns to dealing with all the different browsers, because when you have 350 million users, don't you have people using Netscape 3 and their Amiga OS 9 browser? Are you guys focusing on the older browsers, or are you just basically leaving those users in the dust right now?
Jonathan: We have been lucky to actually be able to leave a lot of those users in the dust, which has been--what's the word I'm looking for? It has been a refreshing experience, the fact that we don't have to worry about IE6 anymore. We've essentially dropped that from our list of supported browsers.
Jared: Wow, OK.
Jonathan: Yeah. That is really helpful in being able to be expressive in what we want to do. But at the same time, a lot of the tricks that we use, things like gradients, we actually use a few IE tricks that people might not be aware of or have been afraid to use. We've actually taken advantage of things like gradients, that we've actually taken advantage of IE filters to use gradients in IE. And as a result, the experience isn't completely different. It's a little bit different. We lose the rounded corners, because we're using a lot of CSS3 border-radius and stuff like that. We lose the roundedness, but we still get the gradients. We still get some drop-shadow effects.
So there's a lot of things that we're trying to take advantage of, these tools that have been available to us. Now, IE6 has had this stuff for 10 years, and we're not going to necessarily shy away from that. As a result of doing this, we do a lot of performance testing, and we try to strike that balance between being on the cutting edge and making sure that this stuff works.
Jared: I'm just curious, Steve, is your experience basically the same? Are you pushing away from IE6 for your stuff, too?
Steve: Yeah. We're trying to do as much of that as possible, if not a little bit more. I think for a lot of our applications, we consider IE7 to be sort of the minimum that we support. And we do deliver a satisfactory experience to IE7, but I think we really want to focus on making the better browsers even better, to deliver a more seamless experience for those people so that as the web gets better over time, these people just sort of get additional features-- [laughs] well, experience features--just simply by upgrading or their browser upgrading somehow.
So I think it's really important to make sure that we don't limit our solutions based on even the minimal browsers that we do support. As long as everything works and they can get to everything and it's functional, I think it's great. And support whatever your audience is going to need. And in our case, fortunately for us, that's shown to be a pretty high level. The majority of our tools that we create are targeted towards developers, so we have that advantage. But I think people have been really receptive to the idea that certain browsers deliver certain experiences and that's OK.
Jared: Yeah. One of the things that you were building I got very excited about. I'm not a developer-type, so Harmony sounds really cool. It's my life goal to never actually implement a website, so I figure I'm about halfway there. [laughs] But, Speaker Deck, now this is something that talks to me, right? Because I'm always giving these talks. My understanding is Speaker Deck, your presentation software, it runs completely in HTML5, yes?
Jared: Do you think HTML5 made your job easier with this? Or did it provide special challenges that you hadn't encountered?
Steve: I think what's really going to help is more features and the transitions and various--if you want to group CSS3 into HTML5, I suppose that's a separate argument.
Jared: Well, the HTML5 logo people already did that.
Steve: Yeah, that's very true. So we might as well, too.
Steve: But I think the CSS3 transitions and animations and various effects that it gives us is going to allow us to sort of replicate a lot of the visual effects that Flash was able to give us, especially in the simple space of slide transitions and things, that will make things really almost seamless for people and an almost indifferent experience than something like Flash would give, while allowing us to have support for pretty much any device that's going to want to access it, regardless of their particular technology biases.
And it'll also allow us to really, with mostly the same code, from the back end, target different types of devices with different types of interactions. And the way you're going to interact with the slides on a desktop is going to be quite a bit different than how you're going to interact with them on, say, your iPad or your Android phone. It's just a different environment and different ways that you use things, and different ways that you would expect to see that data. It really allows us to fine-tune those experiences based on where and what people are using to access it.
Jared: I often wonder about this, because I hear about this, right? Everybody talks about how you can now fine-tune everything for the different platforms. And this is, I guess, a question for both of you. If I'm trying to fine-tune for, let's say, a desktop and an iPad and an Android phone, is that three times as much work if I was just doing one, or is it six times as much work because now I have to manage these completely different experiences, or is it just one-and-a-half times as much work? I have no sense. What have you been finding?
Steve: Oh, go ahead, Jonathan.
Jonathan: On the outside, we actually try to address a lot of this stuff on the design side. We have a lot of different platforms that we're building against. We've got Yahoo Mail, certainly, for the web, but we've also got it on tablets, and we've got it on iPhone and Android and other mobile platforms. And it's like, how do we reconcile all those different approaches? It's a matter of understanding what the interaction is that we're trying to accomplish, and designing for that interaction.
It can be tricky. It's like you have a certain interaction model that is expected on a platform like the iPhone, where the alerts are a certain way, menus are a certain way. So how do you work to support that platform in way that, when your application is in that device, it still feels natural, that it still feels like it's working like it's supposed to, versus working either on the Android or on the desktop or in, let's say, a desktop application like messenger, a messenger client, those interactions are working in a way that feels familiar, that feels natural? Now, if a user is expecting to go step ABC in one place, that they know that they can do the same thing in all different places.
So that really comes down on the design side. Even before we get into actual implementation, it's a matter of thinking about those different platforms and understanding how your interactions should work before you get there.
Jared: Thinking about the amount of effort, if I'm planning to do this, if I want to support three different platforms, do I need to sort of just bite the bullet and say, OK, each platform's going to cost me, in essence, as much time as if I was doing one, so I now have three or four or five time as much work as I did before, and that's OK because I'm going to get this extra value from supporting these platforms this way? Or, because I'm using these tools, is it really that much easier that it's just, in most cases, a tweak here and a tweak there and it's not redesigning again?
Jonathan: In a lot of cases, it is a tweak here and a tweak there. You're not having to duplicate, triplicate, quadruplicate your entire development for each platform that you want to develop to. We've seen that transition to the web as the platform, that we see WebKit as almost the de facto standard on a lot of mobile platforms. We have Opera being developed that we see on the desktop, Chrome and Safari and Firefox, even IE, starting to see this ubiquity across all these different platforms.
So we can build native desktop applications--"native," quote-unquote--with things like Adobe AIR and Titanium, that we're using the web as a familiar platform, and as a result of that, that we really end up building one base and then tweaking for each individual platform. And I think that gives us a lot of power and a lot of flexibility.
Jared: Steve, are you feeling the same way, too? Is it basically a lot of tweaks, for the most part?
Steve: Yeah, I think, for the most part, it is. I think what you'll find is, the first time that you go about it, the most difficult thing to figure out is not "What do I need to change?" but "How do I go about targeting the individual things?" like "How do I get CSS that is only for these particular browsers, or these particular platforms, or this particular screen size?" And there are lots of little tips and tricks out there to be able to handle those things.
And it's important to note, some people start to think about this again and think like, "Oh, you're doing browser detection, and you're just testing for various browsers and you're giving them specific things again, and that sounds really dirty and nasty." But I think the distinction here is that what we're moving towards is not browser detection. It's not asking like, "Well, am I using mobile Safari?" What we're leaning towards now is things like feature detection, where we're looking and saying like, "Well, does this browser handle CSS transitions properly?" And if so, then we can provide them with those adequately enough.
Oftentimes, for things like transitions, we don't even need to detect for them. Sometimes we can just put them in our CSS, and if they happen, they happen; and if they don't, they don't, it's fine, and it doesn't even matter. But when you start talking about things like responsive web design and media queries and basing your style sheet based off the browser space that's there, these are things that are actually really simple and easy to implement, in minutes, to just change various things about your layout depending on the real estate that's available to the user. So they oftentimes can be very, very simple.
Jonathan: To pimp another of Steve's projects, Gauges, I actually use this on my iPad, and it's amazing how fluid the transitions and the interaction still works, even though we're looking at a completely different device. Yeah, I've been really impressed.
Jared: Because people may not know what Gauges is, this is your competitor to Google Analytics, right?
Steve: Yeah. And competitor is a very, I suppose, strong way to put it. [laughs] It's our take on simple web analytics, yes. It's meant to deliver what is to us the very most important information in a really simple, quick way. We've taken very heavy usage of CSS3 transitions and effects, to deliver a really neat experience to browsers that can handle it and a fully functional experience to those that can't. It still works properly, but it's another experience level when your browser does handle it that makes it even better, and that's something that we've been really proud of.
Jared: So one of the things that Sidebar is known for--this is what makes Sidebar really famous--is the fact that you guys are sitting at the leading edge. You guys are taking all these new things that are coming down the pike and pushing the envelope and finding out what works and what doesn't, and most importantly, sort of talking about the tricks. And that's what the workshop, The Master Class Workshop you guys are doing, is basically a day of, in essence, looking over your shoulder and seeing the cool stuff you're doing.
I was actually curious. As we were thinking about putting this recording together, I thought, "How cool would it be if we could sit and just look over your shoulders for a little bit?" But instead of doing that, I'm wondering, maybe, if each of you could share a trick, had we been looking over your shoulder, something that you did lately that was actually pretty cool that maybe even surprised you a little bit as to how neat it was. Jonathan, why don't you share something that you might have?
Jonathan: I should probably have been a little bit more prepared for that answer.
Jared: [laughs] It's OK. You can just make something up.
Jonathan: [laughs] ...
Jared: [laughs] Well, are you a VI or an Emax person because I want to know which key sequence to give you miracle thing?
Jonathan: That's a really good question. I love VIM these days. You know what, that's one of the things I think, just being able to play with certain things and expand your knowledge. Having worked freelance in my home by myself for so long, you don't always have that camaraderie of office people to communicate with and just share those little tidbits with. That's why I think the workshop works out really well.
We've got all of us in one place that, you know, we get to pool all our resources and share all that stuff in one place. We can say hey you know what, here's all the different things we can do with CSS that we want to do these lovely little gradients that work cross-browser. Here's that little technique. But, by the way, here's, you know, the edge cases where you might want to worry about these things. Things that people don't necessarily worry about.
Like I had a blog post about a week ago on hiding content for accessibility and it was interesting to see people responding to the comments like I used this technique and it worked fine and that's great. There are cases where 99 percent of the time that's going to work just great. But, again, you know, when you're working on a project that has to work in 40 different languages, you have to worry about left to right, right to left interfaces, those techniques don't always work 100 percent and as a result here is a technique that works 100 percent.
You know, the amount of research that is involved in doing that kind of stuff, the kind of research that goes into accessibility. I mean, I've learned an incredible amount in the past year on accessibility. And again, being able to take advantage of Yahoo resources where we have an accessibility lab that we have people focused on accessibility and can do testing for us, which is fantastic.
I always kind of recall a story, this is a good 10 years ago, working for this web agencies and one of the things we used to do, we're like you know what, we know people use screen readers, so wouldn't it be really helpful for screen readers if every link said link to contact us, link to help, link to this. As we actually went into testing this, we had somebody with a screen reader and he was blind and he was going through this page and it would say link, link to about us, link, link to help, link, link to this.
I was like wow it's saying link to on every single thing. That's really kind of annoying. Another thing he did is he brought up this list that allowed him to quickly navigate all the links. So normally he would say C, which would bring him down to C, then he would say contact us then he would say click and it would automatically get him through. The problem was that all our links were appended with link to, so he had no ability to navigate anywhere within the list and it was completely frustrating him.
Despite our best intentions, we were doing things in a really harmful way. This is one of those things you learn and having the community of people that you can talk to is fantastic and that's really one of the reasons we like putting on this workshop because we can pull those resources together and be able to just share our experience. There's a lot to gain from that. You know, little tidbits like don't prefix your links with link to. I think that's probably a given at this point, but then you start looking at how do you approach ARIA roles, why do we do things the way we do?
Another tidbit for example, with Yahoo mail, so we've got this list of emails. You would think well you know what that's actually a table, that should be a table. We actually, for performance reasons, don't use a table for that. The reason we don't use a table is because let's say you have 2,000 emails in your inbox. We wouldn't have a table with 2,000 rows.
IE would just slow to a crawl. It's brutal with that much information. Even just trying to download, imagine, 2,000 email headers into a web page, would just take way too long. What we actually do is we just load in a subset. We say OK let's load in 20 messages at a time, or whatever fits on your page. As you scroll we then load in a subset and display that subset. As a result, using a table for a lot of DOM insertion really isn't that practical, so we actually did use a DOM, or a div based layout for this table.
But we wanted the accessibility, we wanted people with screen readers to be able to navigate this and so we did add in ARIA roles. There is an ARIA grid role for specifying how to navigate this. Again, being a list we actually used an unordered list to encapsulate each individual email within this list. We marked it with ARIA roles and then, again, it was kind of this experience of being able to test this and be able to realize you know what, this actually doesn't work.
It turns out the list semantics conflict with the ARIA grid roles and it was just making it difficult to navigate so we ended up removing the unordered list and keeping it straight divs. Again, that comes out of experience and it comes out of testing and being able to share that stuff. It's just another great reason why we love to put on this workshop.
Steve: I love putting on the workshop because I get to learn stuff like this, too, which is awesome.
Jared: Yeah, I'm actually really curious about this. So the divs work fine with the screen reader?
Jonathan: They do. With the list, right, you have certainly list semantics, certain ways of navigating through the lists, but we had marked it up with the ARIA grid roles and, as a result of that, it was making it difficult to navigate with a screen reader.
So by removing the unordered list and just keeping it as a series of divs meant that the screen reader just takes advantage of the ARIA grid roles. So for them to be able to navigate through rows and through columns, they have that capability and there's a lot of keyboard accessibility we've been putting into this application. Just all these different layers of functionality that we feel are important. I mean, for me, it's been a huge learning experience to be able to say, "How should these interactions work?"
The web is a platform designed with a limited interaction method. You have links and you have form elements; and users, for the most part, get accustomed to that as being their only ability to interact with the page. I can single click on stuff, I can click on a form field, I can type in data, and I can click in a submit box. That is my interaction; that's what I'm familiar with.
Then you try to build this application like Yahoo Mail, which has to look and feel like a desktop application. By the way, you can drag and drop stuff. Do people recognize and understand that they can do that? That they can use the keyboard to navigate this in a way that looks and feels like a desktop application? Do they understand that they can do that?
It's a huge process that we've went through to actually talk and learn about this, and it's been fantastic.
Jared: I'm still taking this in here, and so... [laughs] So it's sounds like what you're saying, by just using divs, the simplest of solutions, is the one that worked the best.
Jared: That's really cool. That's not how people typically think of accessibility. Right? Usually, you think of accessibility as all this extra work.
Jonathan: You know, a lot of people do think that accessibility is a lot of extra work, and I've always felt that when it comes to application development, it's about simple progressive enhancement. You start with this base layer and then start to layer stuff on. There are going to be certain assumptions we're going to want to make, and obviously, through the experience of our peers, we learn what works and what doesn't.
To give you another example, a great technique that, again, I got from Steve Smith was within WebKit browsers. Sometimes its rendering of bold was maybe a little too bold. So we do things like WebKit font smoothing, which is a CSS property that allows us to visually tweak the font as it gets displayed on the page, makes it a little bit sexier, a great tip.
One of the things we actually ran into which was a huge frustration for us was that in localized versions of Chrome in Taiwan, so Taiwanese browsers, certain characters - I don't know if it was a certain range - the text just wouldn't render. So you'd actually have buttons that had no text on them, whatsoever. And it was as a result of using the font smoothing, as we do.
We actually have specific style sheets for Asian languages because the font size needs to be a little bit bigger. Twelve pixels might be OK for most Latin languages. Unfortunately, for Asian characters, it's a little too small. So we do target different platforms, different intels, as we call them, or internationalized countries. We target those particular browsers with a specific style sheet to make the font bigger.
We actually had to target those ones, as well, to say, "OK, remove the font smoothing technique because in those particular situations, it doesn't work." Texts will completely disappear from the page. That's a bad experience. For most people, they're not going to run into that. It's just one of those lovely, little learning experiences in developing products.
Jared: So, Steve, what about you? What tricks have you come across? Did you learn any from Snook?
Steve: Oh, I learn from Snook all the time.
Jared: How do you keep track of matching up the code for the event and the code that's firing off the event? Now we're definitely redlining the geek meter here. But it seems to me that debugging all this and sort of maintaining it has got to be a little bit of an extra challenge, isn't it?
Jared: Oh, that's cool.
Steve: So we can pay attention to them really easily and figure out what's getting fired and what's not. It makes it relatively simple because when you're handling data, you have this data model that pays attention to, "Oh I want to change this information." Then at the end of your code that changes that information, you simply fire this event on this object that says data has changed. Sometimes you won't even need to listen to that, that's fine.
If, once you've changed that data, you want to update it in your UI you simply have some UI code over here that says, "Hey, just listen for any time this data changes, and when it does redo this little section of HTML." Then you just use and interact with your data objects as you would normally and your UI just updates itself on the fly without you having to tell it to, because you've told it to listen to when things change. It becomes a really simple pattern for doing this kind of stuff.
Jared: I would think for something like Gauges this would be just mindblowingly awesome.
Steve: Yeah. Especially in the concept of, like we're beginning to sort of tinker with the idea of live updates and like pushing changes when hits come into your site. All I have to do then is increment the numbers properly in the model and say like OK the data has changed and then it sort of redraws my views on the fly as they need to be. Whatever you happen to be looking at just gets redrawn. So implementing the actual live code was almost trivial in a very surprising way. It felt like it should have been much more difficult, but because we used this sort of event pattern it made that just extremely simple.
Jared: Back in the '80s, people don't know this, but I worked on the teams that did some of the early spreadsheets. Updating cells, just refreshing the values when a formula changes so you change a number here and it propagates through the spreadsheet, the code it took to update the visual on that was huge. We constantly optimized because, you know, if you have 20,000 cells in a formula in the early spreadsheet you change a value and then you go off and get lunch and you come back and maybe the spreadsheet will have refreshed itself.
In those early days, users actually turned off refresh because they needed to make a whole bunch of changes and then they turned it on because they knew it was going to take a long time. The fact that you can do this now in a browser with data that is coming through the pipes and have it work, I'm just blown away. It's like the future.
Jared: This is really cool. I'm very excited about the workshop because it's going to be a full day of this stuff. My brain's going to fill up in the first two hours, but I can see that folks who are good at their game but really want to get that much better this is going to be a great, inspiring day to be able to hang out with you guys and just learn this stuff. I think it's going to be a lot of fun.
Jonathan: It will be.
Steve: Yes. I'm very excited about it myself.
Jared: Cool. Well, I want to thank you. We've kind of run ourselves out of time and then some here, but I want to thank you all for talking with me today. Jonathan, thank you for calling in from Vancouver and Steve from the Great Midwest.
Jonathan: Thank you, Jared.
Steve: Well thanks, Jared.
Jared: I want to thank everybody for listening. If you are interested in the sidebar workshop, which I think you should be. If you're still listening to this then you definitely should be interested in this thing. They are coming to Austin, Philadelphia, and Los Angeles. It's a full day course where you get to hear really how to take your craft to the next level for web design and I want to encourage you to participate. You can find out all about it at sidebarworkshops.com. We'll see you there. Thank you everyone for listening and thank you very much for encouraging our behavior. Take care.