The Path to Performance

On today's episode we sit down with Marcy Sutton—a senior front end engineer at Deque Systems, where she works on accessibility. We talk about the intersection and differentiations in performance and accessibility. Marcy explains that there's a huge audience that's being missed by not making your website accessible. Unfortunately, if it's not something you have a personal connection to, it may not occur to you to think about. We talk about how most companies become interested in accessibility after they suffer a lawsuit, and how Marcy's teaching us ways we can be proactive instead of reactive. We look at tools on how to make our sites more accessible and who to make them accessible for. We also talk about the metrics to use to measure success and usability. Show Links: Marcy Sutton Deque Systems Web Components and the Three Unsexy Pillars WCAG What forces layout/reflow Knowbility #A11Y Accessibility Wins AXE Air Carrier Access Act Section 508 Section 504 Lainey Fieingold Structured Negotiations CSUN MarcySutton.com Accessibility and Performance Start Building Accessible Web Applications Today

On today's episode we sit down with Steve Souders and Mark Zeman of SpeedCurve. We talk about the benefits that come from Developers and Designers working side by side, and how the users are often a key component in uniting these (and other) disciplines. Mark discusses “perceived performance”, and we talk more about flowing the user experience over time, and some techniques on how to do that. We also talk about the difficulty in determining which metrics you should be measuring for your website. We are sponsored this week by Catchpoint Systems. Sign up for a free trial at catchpoint.com/freetrial. Show Links: Steve Souders Mark Zeman SpeedCurve Vox Media Declaring Performance Bankruptcy The Mobile Web Sucks Episode 10 of Path to Performance with Tammy Everts Tammy Everts Time is Money Perf.email Newsletter #perfmatters t-shirt #perfmatters poster WebPageTest YSlow 14 Rules for Faster-Loading Web Sites Jason Grigsby Lara Hogan Designing for Performance Path to Performance presentation Design Decisions Through The Lens Of A Performance Budget presentation The Space Between presentation Ilya Grigorik

Our guest this week is Tammy Everts. Tammy is a Senior Researcher and Evangelist at SOASTA. In this episode, we discuss getting started with performance budgets, why you should focus on article and product page load times instead of homepage load times, how to build a case for improved web performance to your company or team, the real impact of performance on the bottom line, and more! Show Links: Tammy Everts SOASTA Facebook 2G Tuesdays Throttled Thursdays Velocity Conf Amsterdam WebPageTest using real mobile networks Designing for Performance Radware Shop.org Summit Perf Map Google Plugin SpeedCurve WebPageTest Mobile Web Stress Conversion Impact Score Scott Jehl on Twitter Waterfalls 101 Yesenia Perez-Cruz on Twitter The Performance Beacon Back-to-school ecommerce report card Time is Money Book Time is Money eBook Preview The Path to Performance Episode 04 with Jeff Veen PEW Internet Report Akamai Quarterly Internet Report

Why are Apple's product pages so heavy? When is the right time to choose aesthetic wins over performance wins? We explore these questions in today's preshow. We're also joined this week by web animation expert Val Head. We're taking a deep dive into web animations; how Val got started with animation, the benefits of animations in UI, why you should focus on the problem to be solved and not the tools, how to effectively communicate your animation ideas with your co-workers, and so much more. Links: Val Head Val on Twitter Designing Interface Animations Motion & Meaning Podcast 12 Classic Principles of Animation The Animator's Survival Guide by Richard Williams CSS4 Media Queries Cennydd on Twitter

This week, we have a brief discussion about how third party ad networks affect performance on news sites before talking with Sophie Shepherd. Sophie is a Senior Designer at Ushahidi, a non-profit software company that develops free and open-source products for information collection, visualization, and interactive mapping. We discussed the challenges of designing for international users with minimal data speed, how Ushahidi brings data and information to regions with nearly no connection, designing with task completion in mind, and more. ##Show Links: Sophie Shepherd Follow Sophie on Twitter Ushahidi Lara Hogan - A List Apart - Showing Performance Global Mobile Book Eric Meyer Crisis Design Rust Belt Refresh ##Transcript Katie: Welcome. You're listening to Episode 8 of The Path to Performance, the podcast dedicated to everyone to make the web faster. I am your host, Katie Kovalcin. Tim: And I'm your other host, Tim Kadlec and yeah, you nailed it; this is Episode 8. Well done! Katie: I was like, oh yeah, I totally know which episode it is. Wait: no, I don't. This is Episode 8. Tim: I mean, it's understandable; the numbers are getting higher, it's getting harder and harder. Katie: Totally out of control it's on more than one hand now! Tim: Yeah, once you've thrown that second hand, things get really complicated. It gets worse when you have to start taking off the socks and using your toes as well! That's where I always get hung up! Katie: You can wear flip-flops and then you don't have to worry about it. Tim: True, true. Katie: How are you, Tim? Tim: I'm doing OK; I'm actually wearing flip-flops right now! Yeah, I am! Katie: It's warm in Wisconsin? Tim: It is warm, for once. Yeah, I'm doing good; enjoying my day. And you? Katie: I'm good as well. The sun is shining here, which is a very rare thing in Ohio this summer and I feel like I have been whining about it for so long but today, I'm not whining. Tim: That's good! That's good! I'm guessing, we could maybe one of these times maybe we'll have an episode where we just kind of whine all the way through, but otherwise I think people probably enjoy the non-whining better. Katie: We can just have a bummer episode! Tim: Yeah, just a downer of an episode where we just air all our grievances about everything… Katie: We just talk in emo voice, just like…mwww…yeah, the web does actually kinda suuuuck… Tim: Yeah, exactly! I think this goes over well, I think this is maybe like a special Christmas edition. Katie: That is a really good idea. Tim: Right in time for the holidays. Katie: Christmas Bummer Episode! Tim: This is brilliant. That has to happen; I'm writing this down. Anyway, but glad to hear you're doing good now on this totally not Christmas at all episode. That's good. Katie: Yeah, on this summer-sunshine flip-flop fun-time episode! Tim: Yay! Katie: So, on the note of cool things, there's this episode from the Washington Post where in kind of a similar fashion, I know we talked a couple of months ago about Vox sort of declaring performance bankruptcy, Washington Post kinda did the same thing and talked about in an article the other day and that was pretty cool. They mentioned it sort of being in response to the instant articles and talking about just ads on news sites generally kind of sucky for performance, but I really liked this quite that it ended on that we have very little control over ads that load late or slowly but we wanted to make the core use experience as solid as possible because that is what we have control over and that's kind of a cool way to think about performance, just focusing on making good the core part that you do have control over. Tim: Yeah, and I think that's just generally awesome advice for anybody, because the ad work stuff comes up a lot and you have very little control over those third party ad networks and unfortunately a lot of them are super-slow right now but also essential for business but I like that they made the clear distinction between their core experience and understanding that the ads is just something you're going to have to tack on afterwards but mitigate the issues as much as possible. I think that's just really solid advice for any publisher. Katie: Yeah, absolutely. It's a nice article, it's a quick read; I recommend giving that a little skim or browse. Tim: Definitely. And then of course, Lara Hogan, who has made a habit out of writing good things over and over and over again or providing good performance advice in general, she wrote a post for A List Apart about showing performance; basically getting into some of the things she talked about way back in Episode 1 with us and also in her book about the importance of making performance visual: going into the dashboards and things like that, that they have up at Etsy and making sure that people can actually see the difference in performance. Katie: Yeah, she tweeted a little quick video a while ago and it might actually be in that article, I haven't had a chance to read it yet; it's on my to-do list but she posted a video of their video systems and it's really cool, it's really awesome to see that. Did I tell you that Lara, she talks about donuts all the time and donuts being her reward for good performance, achievements, good things like that, and when I saw Lara in New York a couple weeks ago, she took me to The Donut Spot that's in her neighborhood and I was so excited! Tim: Yeah, you told me. She's never taken me to The Donut Spot. I'm a little disappointed. I'm excited for you though: that sounds really cool. That's kind of… Katie: You know what? It was a really good donut because she says she's not a fan of the hipster donuts with a bunch of stupid toppings like cereal and candy bars and crap. Tim: Like the voodoo donuts thing in Portland? Katie: Yeah. These are just some straight-up home-town donuts in Brooklyn; I guess not really home-town but they were good! Tim: That's good. This is just like plain glazed? I want to know how far down the rabbit hole you went. Katie: We got banana…no, not banana: they were like custard-filled ones with the chocolate icing. I'm not a donut expert but those good ones! Tim: Gotcha, OK. That's a safe choice. Katie: Not the white sugary whipped cream-filled, the kind of yellowy-custard cream-filled ones; those are good ones. I don't know the distinction: is one cream and one custard? Is one icing and one cream? I don't know. Tim: I think it's usually like an icing and cream thing. Depending on where you go, it's almost like pure frosting is what it tastes like you're eating… Katie: Yeah, like you bite in and you're just like, oh my… Tim: Yeah, it's like there's frosting on the outside of the donut and frosting shoved down the inside as well and you just feel the cavities forming as you're eating them. It's great. It's a really good experience. But that's good. No, I did not…you did tell me this and that's very awesome, very cool. It's kinda like… Katie: Sorry; I'm obviously still thinking about that. Tim: I don't blame you. Katie: It was an experience. But, back to today's episode! We are talking to Sophie Shepherd and the big reason we wanted to get Sophie on here is not only because she's an awesome designer but because she has experience with working on products that are primarily used in developing countries that typically have the less than ideal device scenarios that we kind of always talk about in theory but she has some really great insight on talking a bout it in practice and actually designing for those devices and scenarios so it's going to be really interesting. Tim: Yeah, it'll be a nice fresh take, a different perspective than we usually get. Very cool. Katie: Cool. Well, let's go hear from Sophie. Katie: And we're back with Sophie Shepherd from Ushahidi. Sophie; can you tell us a little bit about Ushahidi and what exactly that is? Sophie: Sure. So, the what exactly it is, it's a Swahili word that means "Testimony". A lot of people are like, "Usha-what?" so it's not English so don't feel bad if you can't say it. And the company was founded in 2008 in Kenya so in 2008 what was happening in Kenya. there was an election that was fairly corrupt and there was quite a bit of violence broke out and some bloggers who were in Kenya and living in Kenya realized that they needed to do something to help out as well as just writing about what was happening, so they made a product in which people could submit reports of different places where the election was happening, different polling stations and this way they could say, there's been violence here, someone was killed here or this is a safe place where you can go to vote, or there's fraud happening. And what Ushahidi does is it takes all of these different reports and collects them into one place and provides a list and a map for them. So that's how it was founded; it's now a number of products but the name of our main platform is still Ushahidi and the purpose of it is still too collect data, crowd-source data. It's oftentimes gets mapped but isn't necessarily, we're re-doing the platform right now so that it's not only map data; it can really be anything that users submit. Katie: Awesome. So, spoiler alert, I know Sophie really well so I know the details of what she does and what really struck me and why I wanted to get her on the podcast so bad is because you deal a lot with users that are in places that have really poor connectivity and the products that you're designing are really crucial information that they need to get to. Can you talk a little bit about all of that and the challenges that you face when designing for that? Sophie: Sure. So, I think something that's really interesting is that it's not only poor connectivity but the kind of contexts in which people are using our products are unique. Not exclusively, but oftentimes they're used in crisis situations, so people don't have a whole lot of time. A lot of the time, the power could be down or internet could be down, so it's not only we have to think about connectivity but also ways that people are submitting information. This has been the first project I've worked on where it's not just, when we talk about performance, it's not just people needing to load something fast but it's about access and accessibility so, built into our product is people can anonymously text stuff in and that'll become a part of our system so it's really thinking about this whole ecosystem of access and ways of submitting information rather than just a website. Katie: Can you talk a little bit about what that means exactly, more than just a website? How else are you working around those connectivity and accessibility issues? Sophie: Yes, well, Ushahidi as a whole, not only with our platform but we have a lot of other companies that have spun out from the product itself, so there's a company Brick which is really, really awesome. It was founded by someone who was also a founder in Ushahidi and they make wifi devices that are super-rugged; they work off 3G connections so you can take those anywhere. We were in Kenya and they have all these attachments so it can be solar-powered wifi, so we had a group meeting in Kenya and we were all accessing the internet in the middle of nowhere on a beach from this device we had. So, it's thinking more about getting people information. Similarly we do a lot with SMS so if someone only has a phone they can text in a report or receive a response saying, OK, this has been confirmed, through their phone. Tim: This is fascinating stuff. I always think it's very interesting to hear the perspective outside of what we're used to in the little bubble that we get to live in here in the United States tech industry. This is taking everything in terms of the importance of building something that is going to work on different devices and the importance of building something that's going to perform well and this is really scaling up the importance of doing that, the vitality of doing that from just business metrics to, like you're saying, people's lives at stake in some of these cases. I'm curious; you mentioned being in Kenya and using those devices to get access. You can't obviously develop all the time in Kenya, so how are you finding ways to get that experience here, when you're building stuff from the United States so that you're feeling what it's going to be like on those, a 2G or a 3G connection or whatever it happens to be? Sophie: It's definitely a challenge for me because not only am I working every day on a really good connection but I've never really not had that; maybe five years ago my connection was not as good as it was now but I think I've always been as far as connection speeds in the one per cent, but we have a really great user advocacy team at Ushahidi so this is not only thinking about performance and website metrics, but we have a whole team that is dedicated to making sure that our users are satisfied, listening to what their needs are and responding in that way and also helping them, because this is a product that then gets extended and they can download it and set up their own deployments to use the product so we have a team that works really closely with people who are actually using it, which is terrific because we get a lot of feedback through that. Tim: I was going to say, are some of the team members in Kenya? Sophie: Uh-huh. Yeah, we have one person in Kenya, one person in Canada and then we have as part of, we have a specific user testing wing that's in Kenya but what they do is, since they are so in touch with people who use this stuff all over the world, they're good at being able to not only test it in Kenya but test it elsewhere and talk to…we have a large group using this stuff in Nepal right now because of the earthquake so they're in touch with them, checking that everything's working OK, getting any feedback from them. Katie: Do you tend to look at what specific devices the majority of users in these areas are using and start building and testing there or how does that work out? What's the size of an iPhone, that tends to be our default? What devices are you really thinking about in those areas? Sophie: It's interesting because right now, we are in the midst of re-building this product and so a lot of the people out there who are using it right now are using Version 2 which is the older version and at this point I don't even know how many years old it is but it's fairly outdated. It still works really well but it's not responsive; it's hard, we've noticed that quite a lot of people are using it on a desktop but that's only because it doesn't work very well on a phone so it'll be really interesting, we're launching the new one which is fully responsive and a lot more modern in this way to see how people end up using it. But it's tough because we can't say, iPhone users use this because it's used really everywhere in the world so maybe if it's used in the US it is going to be on an iPhone more, whereas elsewhere, it's Android but we try to cast a really wide net so there's an Android app that will be used for collecting information, you can submit by SMS. The new version's going to be totally responsive so what we try to do is not really focus on one but make sure that everyone can use it. Katie: So, you've been working on a responsive re-design and everything we've talked about has been the poor connectivity and all of that. How has performance played into those decisions when building this site or the product again for this new version? Sophie: It's a continuous consideration and process of checks and balances. One thing is that, thinking about images: part of this new system is we're able to have people submit images as part of their reports so that's something that we still have not quite figured out how we should work with how to then deliver those back to people and also thinking about different JavaScript libraries that we're using. It's a constant balance, so I think we're still figuring it out. We've done quite a bit of user-testing but more UX user-testing but the application itself is not totally done, it hasn't been built yet, so I think that's to come in terms of optimizing how it's going to work exactly. But from the design and front-end, we've definitely been keeping things really light and really the only question that we have is how we're going to treat images. Tim: Is it primarily a matter of using them or not using them or is it a degree of compression in terms of getting them to a point where maybe they're a little pixilated and ugly but they're balanced: the trade-off is that they're going to perform well on those types of networks? What are you battling with, with the images? Sophie: Well, I think basically every single image that is ever going to be on the site is going to be submitted by a user, so we don't know exactly the sizes of images that are going to come in and then at what point we are then going to compress them or shrink them and how we're going to do that and then how they're going to then be delivered back out. Yeah. Tim: So it's getting a system in place for all the user-generated content? Sophie: Exactly, yes. Tim: Gotcha. OK. Katie: So, you talk a lot about style guides and patter libraries and Sophie I know that's how you like to design and work. What is that process looking like? Do you do testing as you go on designs and see how performing it is or how fast it's loading under those different circumstances? Can you just talk a little bit about your design thinking? Sophie: Yeah. What we have been doing is we did all the UX fairly separately, thinking about just user flows and how things were going to be laid out and how things should work and then we did some visual design and then we started combining these by building the pattern library, so we took out patterns from visual design and eventually we've just started building templates and designing in the browser because we have enough of these patterns to build upon and it's been really great; this is the first time that I've worked in this way and what I really love about it is that each of our patterns and components basically stand on their own so it's really easy to look at them and understand exactly where certain weights are coming from. By designing modularly, we can pull those out rather than seeing a page as a whole and not really understand what's causing what. Tim: In a prior episode, we were talking to Jeff Lembeck of Filament Group and he mentioned what he called the "Jank Tank" which is this big box of basically ugly, horrible, slow devices. Considering how wide the net you're spreading, do you have anything similar? Is there a Ushahidi Jank Tank that you guys go to? Sophie: There isn't, but I love that idea. Tim: Yeah, I think we were fans of that too. Sophie: Is it like…what does he mean exactly? Tim: The idea was having… Sophie; …lowest common denominator kind of devices? Time: Yeah, basically grabbing cheap devices or old devices and firing those up: things that are going to be maybe a few years old and are probably going to be a huge challenge to make things feel fluid and work well on those and you have those handy to test them out and see what honestly might be a more typical user would experience than the high end stuff. Sophie: Yeah, we don't have that here in the States; I feel bad calling it a Jank Tank because that's negative-sounding, but in the office in Kenya, they have…they all work in a building and there's quite a few tech companies that work in there and they have something like a Mobile Device Lab and I think it was sponsored by a mobile company there but I was there earlier in the year and it kind of blew my mind; I put a picture of it on Twitter that we can refer to in the Speaker Notes. But that was all of these phones that were phones that I hadn't even necessarily seen, that they don't sell in the States, and they're all used for testing so at some point probably now that I'm talking about it, I'm realizing we should do it sooner rather than later, they have a whole testing lab there that we can test this product on. Tim: Nice. A mobile device lab does admittedly sound a little bit more ??? serious. Katie: Everything that you're saying sounds like, just tying in that accessibility and performance are going hand in hand and it sounds like you've just learned a great deal of empathy in your time there. Is that true and has that influenced your design? Sophie: Yeah, definitely. I think something that has really changed in my mind is thinking about when doing the design, what actions are people going to want to take, so I think that goes with performance too: if we can only load this one button that says "submit a report" and skip all of the images then that's the most important thing, so, really thinking about where to guide people and what the most important and crucial actions are before loading and everything else, so as a designer that's been definitely something that, previously I was doing client work and it was like we had this long list of requirements that we had to fit in and now it's kind of re-assessing and re-prioritizing what requirements actually are and having different levels of this is the one thing they need to really use this app and then here's all of this other helpful stuff that could be called crucial but isn't actually life or death crucial. Katie: That's really interesting. Do you think that there's any way that, for those of us still working on client projects, to have those conversations with the client to try to be like, "no, really, but the marketing video isn't truly required"; exercises in priority and stuff: do you have any tips for paring down those requirements? Sophie: I think it's tough if your talking to a marketing person because they'd be like, "no, literally I'm going to die if I don't get this on there." Katie: And you're like, "no, literally, people are on our products like…" Sophie: Yeah. I think any time it's easier to say, "does this go above this in the priority list" people are willing to answer that question rather than either or. So, in general, communicating and deciding things I would recommend ordering rather than choosing people to sacrifice things. Tim: And it seems like that's clarified too in, I would guess one of the reasons why it works so well where you are is because that task, if you're looking at what the most important thing for the user to do is, it's so very clear and so very critical whereas on maybe on a more traditional thing where you're working with marketers or whatever, they may not have as clear a sense of, what is the ultimate purpose of this site? And then it becomes a lot harder to do the prioritization without that. Sophie: Yeah; it's funny because we're in the process right now of re-designing the company site as well as re-designing the product itself and it shouldn't be, because there's no life or death, but it's so much more complicated to prioritize stuff on the company site because there's so many different types of audiences and services that it needs to provide whereas on the app itself, it's pretty clear to say, what's the most important action for someone to take. Tim: Within the new site, do you still have to take into consideration a lot of the same sort of constraints in terms of the different devices and connectivity because that's who your audience is that you're marketing to, or are you marketing to a different group through the site? Sophie: Yeah, the site will be, well that's up for debate; that's I think what we're still trying to figure out. I think by default it's a good idea to not ever say, "oh well only people in the States with nice phones are going to look at this" just because that's a dangerous attitude to have, but it's possibly less of priority for the site itself. Tim: So, going back to prioritizing performance within the actual apps and stuff that you're doing: did you have set targets that you were looking at when you were working V3 of this? Were there hard-set goals; we are not going to go over this amount of weight or we are not going to take longer than this for the map of data to appear or anything like that? Sophie: Yeah, so we set a performance budget and we've set a few of them; we set one for the front-end so what we've done is build this pattern library and we have all of our, we're calling them "weight-outs" which are basically our different views within the app itself. So we had an initial goal for that, that we've met and then we set a separate one for the build itself and that's still in process, so hopefully we can get around that target. I like this too because instead of having one end-goal we can really check as we go. Tim: Yeah, it's nice to have it broken down like that. Can we ask what the targets are, just out of curiosity? Sophie: I can look them up but I don't know them right now. Tim: That's fine. Just curious. Was it in terms of the weight or is it a different sort of, more like an experience-focused metric or anything like that, that you're targeting? Sophie: Yeah, we did a weight and a load time. Tim: Gotcha. OK. Katie: It sounds like you've worked in some of the perceived performance thinking too when you're saying, what's the critical information to load first. Sophie: Yeah, for me as a designer, that's definitely something that I can relate to more and I think in some ways it's possibly more important. I think they work as a team but… Tim: I think it is. And I think that's…I think or I hope that that's what, within the performance community, the people who really that's what they do focus on, I think that that's where everything is starting to, we're starting to wake up to that and certainly to shift towards understanding that it really is about the experience and making sure that the critical things are coming in, whatever the top task, whatever the most important features are on the page or coming in and measuring those sorts of things, instead of this blind race to the finish that we've kind of had in the past. Sophie: Yeah. I'm curious to see how that thinking changes because I love the idea of a performance budget but I think sometimes it can be a little limiting and you wouldn't want to sacrifice certain things just to fit into the performance budget. Not limiting, but I think it's very concrete whereas it should be a fairly fluid depending on context of the site itself. Tim: Sure, yeah, it doesn't dictate what goes on; it's another consideration or it's part of another piece in the puzzle. Sophie: Right. At the same time, it's the easiest way to communicate goals. Tim: True. It's hard to without it having a hard set thing, it's very hard, yeah. Sophie: Yeah, until you have the design done, you can't say, OK, our goal is that this is going to load and then this is going to load this much later. It helps to have a number that everyone can refer back to. Katie: So, when you say for everyone to communicate, who is that? Is that between you and the developers? Is this something that your leadership is really that's close to their heart as well? Sophie: Yeah, I think when I said that it was more coming from my experience with client work, where you're using this number as a kind of tactic to force a client to decide on certain things. For us, since we're all working internally, I think definitely any…basically, everyone wants to see it be as fast as it possibly can, so we're all working towards the same thing. Katie: Is there ever a push-back to even like, "OK, now that we've hit that, let's try another goal that's even faster"? Sophie: Not yet, because we haven't launched it, but I wouldn't be surprised if we launch it and get certain feedback that it wasn't loading or it wasn't working quite right on something. I'm really curious to see once it's out there and people are using it, how people respond. Katie: Yeah, I'm really curious to see what metrics you find out from that. Tim: Did you make a distinction…there's the cutting the mustard approach that the BBC popularized which is the core experience goes to maybe older, less capable browsers/devices and the enhanced experience goes to everybody else. One of the things that that fails at, or that doesn't take into consideration which seems like it would be really important for Ushahidi is the situation where you have somebody is on a very nice device but the connectivity is really awful. Did you have to make any distinction between different experiences or do you just have one experience and that experience itself is extremely lightweight, no matter what the scenario is? Was that enough for you to accomplish or you needed to do? Sophie: Yeah, that's funny; we had our company retreat in Kenya so it was I think maybe about half, maybe a little less of our company is in the US so we all went there with our snazzy iPhones and still couldn't connect to anything and it really, I think in terms of empathy, made us realize: oh, wait a second. But in terms of yeah, I think we're just going to try to make it fast for everyone. We don't have a whole lot of enhancements for people on quicker systems yet. Katie: When you were in Kenya, were there any things that were especially awful to try to load, like you're used to just being part of your everyday life? I'm just curious. Sophie: I remember reading Twitter, on the Twitter app and everything loaded except for the pictures and it made you realize just how often people supplement their tweets with pictures; I remember getting really frustrated about it. Katie: That's interesting. Sophie: But I didn't even really try to do a lot of stuff because it really didn't look very well. Same thing on Instagram; it's like sometimes this progressive loading thing; I would rather it not load at all than, oh, I see all of these people posted great pictures that I can't look at. I'd rather not know than… Katie: Or like the tweets having fomo, oh, you had a joke and I can't see the punch-line! Sophie: Exactly! Katie: That's really interesting because when we're just designing here in a bubble it's like, "well I think that would be fine for you to just know that it's there but not see it" but then when you're actually using it, you're like: no, this sucks. Sophie: Yeah, it's like actively frustrating. Tim: How often do you get to Kenya? Sophie: I'm new to the company; I've only been here since the beginning of the year but I think they do a retreat every year but not necessarily always in Kenya; I think every other year it's in Kenya. And I think other people on the team, it depends, we'll do these what we call Hit Team Meetings because everyone is remote and then mini-teams will get together and all work together for a week so those have been all over the place since people live on opposite ends of the world, depending on who's meeting they usually choose a place that is fairly central for everyone to get to. Katie: We'll start to have a list of sites, Sophie, how much is this really crappy, wherever you end up going… Sophie: How long does this take? Katie: Look it up and tell me how much it sucks. Sophie: It is cool to have people on the team everywhere for that reason. Tim: Sure, I bet that gives you a really nice overall picture of a whole bunch of different landscapes from a technical perspective. Sophie: Yeah. Katie: I know, I didn't prepare a list of questions like I should have! Tim: It's all right, I'm actually having a lot of fun just going off the cuff on this, knowing almost nothing. I did a little bit of research and I had heard of Ushahidi from this big fat book about mobile on a global scale that was put out a couple of years ago. Sophie: That's cool. What was that book? Tim: It's called Global Mobile. It's six hundred pages and each chapter is written by a different author on a different topic and I think Ushahidi came up twice… Sophie: Oh, that's awesome. Tim: …in the book. Sophie: Do you know what they referenced or what it was…. Tim: One was just talking about how…I don't remember one of the references in much detail. The other one I know that they were talking about a variety of different mobile technological solutions that were out there; I think they were focused primarily on Africa in that chapter or similar areas and they were talking about the different services that are making use of technologies that we might consider a little bit more simple, but they're doing really powerful things with it and so I think that they were focused on the SMS aspect, if I remember right. Sophie: Yeah, it's been definitely challenging, but also interesting that designing a product that is not used for one specific thing; it's very much user-focused and people will download it and decide how they use it, so it's been a challenge to design for that and to keep it well designed but also really, really flexible. Tim: Which is why I guess it's so important I guess that you are getting a chance to experience at least a little bit every once in a while because everybody talks about front-end design perspective, from a development perspective, how important it is to put yourself in your user's shoes and when you're talking about what Ushahidi is dealing with, and it's not just the devices or the browser or the connections: it's the situations; it's just so hard. It's so hard to put yourself in those sorts of shoes and understand what it must feel like to use the application or the site in those sorts of scenarios; that's such a huge challenge. Sophie: Yeah, there's no way that, well it sounds selfish saying it, but hopefully there's no way I would ever actually be able to experience that but I think that is why we have such a strong and valuable user advocacy team so that they can really communicate with them when people are in those situations and as they're using it in those situations. Tim: Do you get feedback from the users that are pertaining directly to things like how quickly they're able to report something or how quickly they're able to get access to the data that's been reported, in terms of it takes too long sort of a thing, not just a usability thing but from a performance perspective? Sophie: We haven't. Or not that I know of. Tim: Well, maybe that means you're doing an awesome job! Sophie: We'll see. It's also tough because the new version is yet to be used on a wide…by a lot of people, so we'll see, but it is great because we have the product is also open source, so we have a lot of community submissions and ideas so this is again the first time I've worked on something like that where I'll just be in my normal task list that we use internally as a team and I will get one from…I'm in Katmandu and this thing is not working; can you add this? So it is really cool to see that people care about improving the product. Tim: That's awesome. Katie: Is there anything that you've learned from going through this process and being hit with all of these pretty heavy design constraints that are just, oh man, there's no way I can ignore that. Has that changed your view on design, even outside of this product in particular? Sophie: I think that this has, compared to how I used to design, I'm keeping things a lot more simple, not even necessarily visually; visually as well but also just in how they work and not trying to dictate how something should work. Oftentimes we'll, with other people in my design team or sometimes with our developers, we'll discuss how something, spend hours doing flows and then just realizing, why don't we just let people do what they want to do and take a step back and not define so much how this should be used, so I think just the fact that so many different people are using it for different ways, I've found that it's often best to leave things open and then to not over-complicate them. Katie: Is that kind of freeing? Sophie: Errr….it's been difficult because I'm so used to not being like that. But yeah, kind of. For me as a designer it's been kind of hard to let go of control. Katie: Yeah, that's usually I think our downfall as designers is wanting to control everything and that's kind of a big part about embracing performance too: it just sounds boring to design for performance, even though it's not and it's just like anything else. Sophie: Yeah, I think that I talked to ??? about this a long, long time ago and I remember it's stuck with me in terms of performance but also it's kind of user advocacy side of design, which is that it's not in conflict with the design; you shouldn't think of performance as taking away from visual design but it's just a piece of design so it's just another aspect of UX and if it loads faster, then that'll make the design better. Katie; It means you did your job well! Sophie. Yeah, exactly. Tim: At the end of the day it's about, especially in your case, but at the end of the day it's really about how quickly can the people using the site or the application get the task done that they came to the site to do and so that makes performance comes right up front and center along with any other bit of the process really, information architecture, clear content structure and good visual design; it all contributes. Sophie: That's what design is, right? Getting people to be able to do what they want as easily as possible. Katie: Is this something that you were thinking about before having these experiences in these other parts of the world, or was that the eye-opener of, oh-whoa, my designs should encapsulate this? Sophie: Yeah, I think it's always something theoretically that I could be like, your designs have to load really fast, of course, but selfishly I've always wanted them to look really cool or try out some latest thing that's trending on the web. So I think it's helped me step out and realize I'm not designing this for me. If I want to try something, I can just do it on my own site. Katie: So, I'm wondering if that's maybe the first step for designers that are not wanting to think about it… Sophie: Make them design something for someone in crisis. Katie: Yeah! Sophie: At an agency, every junior designer has to design for… Tim: Oh man! Sophie: …life or death situations. Katie: It's part of the interview process, you need to whiteboard a crisis design. Sophie: Yeah! Tim: Talk about no pressure right off the gate, that's what you're dealing with! Sophie: Have either of you seen Eric Meyer's presentation? Tim: I have not, but I've heard it's excellent. Sophie: I really want to. Katie: I want to see it as well. Sophie: It sounds really… Katie: Everything you are talking about is making we think of that. Sophie: I would really, really love to hear, I don't know if he would…he could be a good guest on the podcast just to talk about his experience. Tim: Yeah, I'd love to talk to Eric. I've heard the presentation is just fantastic but I haven't had a chance to catch it live. I don't know if it's recorded or not anywhere but if so, I haven't seen it. Katie; I think if any of you want come hang out in Ohio, I believe I would have to double-check, but I think he's giving that Rustbelt Refresh in Cleveland in September. Tim: I do like that conference. I did that last year, it's a lot of fun. Katie: So, you want to come hang out in Ohio and see it? Tim: Sunny Cleveland! Katie: Where the lake caught on fire! Sophie: Oh my God! Tim: I don't think I heard this. Katie; I think it was before I ever lived in Ohio, ten or so years ago. It may have been the river, it may have been the lake, I can't remember. One of them was so polluted that it caught on fire at some point. (45:11) Tim: That sounds a lovely! Sophie: That's terrifying! Tim: My only knowledge of Cleveland, which I think is probably upsetting and insulting to all people who live in Cleveland… Katie: Drew Carey Tim: Yep. So, I apologize for that! Sophie: I've been to Cleveland; I spent two weeks in Cleveland. Katie: What? Sophie: I was going through, you know, being young and wanting to work for Obama during the election but even then, I don't know what's in Cleveland, even after spending time there. Katie: I have been to Cleveland twice and I don't know. I live two hours from it; I couldn't tell you what's in Cleveland. Sophie: Really cheap houses if I remember; lots of empty, cheap houses! Katie: One time I tried out to be on The Price is Right this is when Drew Carey was the host and because I am really bad at being like, wooow, cookie-crazy person to be on The Price is Right, they interview every person that goes through the process and like, "why should we pick you?" and my only response was just like, "I'm from Ohio. Just like Drew. Cleveland Rocks, right?" Sophie: Certainly good for TV. Katie: Yeah, well, we'll talk about Ohio. Obviously I did not make it! Tim: That's sad! Sophie: There's still hope; you could try again. Tim: Don't give up on that. Katie: No, that was actually…. Sophie: Don't give up on your dreams. Tim: No, you've got to follow through. Katie: That was horrific; you're just like cattle being herded for six hours through this line as they interview every single person that goes in the thing, so if you're ever in LA and thinking, it would be fun to go on The Price is Right: it's not. Sophie: Think again! Katie: Sophie, you never did that when you lived there? Sophie: A lot of people I knew did. Katie: Did anyone ever get picked? Sophie: They did it…I grew up in LA and they filmed Jeopardy I think right next to my High School and they would do it as a fundraising thing where you would…they'd get a group things of tickets to Jeopardy and then the cheerleading squad or whoever would try to sell them individually. Katie: Whoa! Sophie: That's the closest I've gotten. Katie: Growing up in LA sounds wildly different from anywhere else! Was it? Sophie: We didn't have any lakes that lit on fire! Katie: Wasn't your High School the one from Grease? Sophie: Yep! Katie: Oh man. Sophie: And Party of Five. Is that what that show was called? Katie: Yeah. Tim: That's kinda cool. Katie: I'm more interested in Rydell High though. Sophie: I think they filmed it in partially different schools but the stadium was our stadium. Katie: The track where Danny's trying to be a jock and running around? Sophie: Yeah, yeah. Katie: Aw man, that's the worst part when Danny's trying to be a jock! Sophie: Wonder Years. Wonder Years, that's the block I grew up on. Katie: Really? Sophie: Yep. Katie: Dang, you have Wonder Years, Alison has Dawson's Creek. Sophie: Dawson's Creek. Way before my time. Katie: I want to grow up on a teen drama! Sophie: The Yellow Brick Road was also the street, from the Wizard of Oz. Tim: Where was the Yellow Brick Road? Sophie: Before the houses were built, they filmed it on the street that my house was on. Tim: What? Sophie: And then years later, they had a reunion for all of the oompa-loompas that I accidentally walked on and I was sort of….what? Katie: Were they dressed up? Sophie: No. Tim: Wait, wait, wait…you just said oompa-loompas, but isn't that…that's Charlie and the Chocolate Factory, right? Sophie: Not oompa-loompas. Munchkins! The Munchkins! Tim: I was like, wait a minute… Katie: Glad you got that 'cos I didn't! Sophie: I didn't either, I was like, this sounds right. Tim: Yeah, OK, I just wanted to clarify which movie it was. Sophie: Can we cut this out? We're going to get complaints from Little People of America organization. Tim: Yeah, that's fine. Actually we could use a few complaints. We haven't got many or any yet. Katie: Thanks for bringing it up. Now we're going to….well, if you're looking for feedback, let me tell you...you can lay off the chit-chat. Tim: We've gotten plenty, plenty of negative feedback and complaints so please don't bother sending those emails or letters. There, that should… Katie: I'm going to write you a strongly worded letter about your podcast! Tim: It happens. Sophie: This really went off the rails! Tim: It did, but you know what? That's cool. That's all right. I feel like… (50:03) Katie: It was getting really heavy, so you know we to lighten it up. Tim: It was, we had to lighten it up and I feel like it's kind of weird that we had gone this far without talking about Drew Carey so, you know, however many episodes we're into this and Drew Carey had never come up; seems wrong. Katie: Really? Sophie: Give us some Drew Carey facts, Katie! Katie: Actually, well I don't know any Drew Carey facts but I'm sure Tim has lots because that seems like that's your era of TV. Tim: I'm not that old, all right? Katie: Yeah, but Everybody Loves Raymond, you'll never… Tim: Yeah, I actually had…. Sophie: Are you Everybody? Tim: No, no. Am I? Sophie: Do you love Raymond? Tim: I do love Raymond; I do. It was a good show, all right? It was a good show. Under-appreciated by the current generation! Sophie: It was the most popular show ever at the time. Tim: It was really popular; really popular. Sophie: Did you just watch it on multiple TVs over and over again to up the ratings? Tim: Errr…. Katie: He had it going on every TV in the house, the whole day and night! Sophie: The syndication too so they're getting those checks, all from Tim! Katie: Tim loves Raymond! Sophie: New TV show! Tim: All right, all right; neither one of you are ever invited back on this podcast; even you, Katie. That's it, that's the end of it. I'm going to go start my own podcast where we're going to talk about Everybody Loves Raymond and The Drew Carey Show and things like that. Katie: Indiana Jones Tim: Indiana Jones, yep. This really did get off the rails. My gosh! Sophie: Yeah, feel weird going back to talking about crisis. Tim: So, well, you know, maybe we don't, there was a lot of really good, like Katie said, it was getting really serious and really awesome discussion, I think, around performance and it was really cool to hear somebody who is coming at it from that global perspective which, it's just not something that we commonly think about a lot, for most of us aren't dealing with on a day to day basis, so it's really interesting to have somebody come in and burst the bubble a little bit and give us a broader perspective. Katie: Yeah, it's great because I think like you said, Sophie, earlier: in theory everybody's like, it's nice and stuff and obviously we talk a lot about performance and everything and it's one of those things that I think everybody is like, yeah, yeah, in theory yeah, we want it to be fast because we don't want to be shamed by Twitter, but… Sophie: Other web designers! Katie: Yeah, basically. So it's great for you to come in here and give us the perspective of what that actually means and hopefully shed some light on that empathy. Sophie: Yeah, thank you for having me. Katie: Yeah, thank you so much for joining us. Tim: Going forward, it anybody wants to follow along and hear more about what Ushahidi's doing or about what you're doing, how do they do that? Sophie: For Ushahidi, I would recommend following Ushahidi on Twitter, ushahidi.com for a lot of information about all their different products and blogposts and then for me, my website is sophieshepherd.com Tim: Very cool. Katie: What about any social media that you may have because, I might be biased, but I think Sophie you have a pretty good account that's pretty funny! Sophie: My Twitter unfortunately is sophshepherd, because there's a British teenager named Sophie Shepherd who took that from me. So, don't follow her unless you want to hear a lot of complaining about tests and boyfriends. Katie: Do you follow her? Sophie: Occasionally! Then I get too mad about it and then I think, what if they think it's me? Katie: Is she also blonde and kind of looks like you? Sophie: Yeah, I've sent her a message; she does kind of. I sent her a message on Facebook once and she went, what are you freak? And then that was it. Katie; Really? Sophie: Yep. Katie: She called you a freak? Sophie: Yeah. I'll put a screenshot in our speaker notes! Katie: OK, well follow the real Sophie Shepherd then. Sophie: Yep. Tim: Well, thank you and we'll definitely have to have you on again to discuss because I feel like there's a lot more we could get into in terms of Drew Carey and Ray Romano, so in a future episode. Katie: You can do that on your separate…Everyone Loves Ray. Tim: And Tim Loves Raymond. Yeah, that's good. It'll be the initial episode. Sophie:: Tim and Ray. All right. Thanks. Bye. Tim: Thanks; bye. Katie: Thanks. Bye. Tim: Thank you for listening to this episode of The Path to Performance podcast. You can subscribe to the podcast through iTunes or on our site pathtoperf.com; you can also follow along on Twitter @pathtoperf. We'd love to hear what you thought so feel free to drop us a note on Twitter or leave a raving and overly kind review on iTunes. We like to read those. And if you'd like to talk about being a guest or sponsoring a future episode, feel free to email us at hello@pathtoperf.com

Our guest this week is Brenna Heaps. Brenna currently works at GitHub, but previously was a project manager at Happy Cog. She managed several projects that Katie was a part of, so we asked her to join us on the show today to share her tips and advice on managing projects and teams, selling clients on performance, sticking to performance budgets, and more. Show Links: Val Head on Twitter Cennydd Bowles on Twitter Motion and Meaning Podcast Death to Icon Fonts Seren Davies Path to Performance Slack Group Paul Irish - Reddit Mobile Site Review Brenna Heaps Happy Cog

Our guest this week is Matt Shull. Matt works at Aristotle Interactive where he manages projects and helps shape performance best practices. He also teaches others about web design/development through Thinkful in his spare time. In this episode, we talk about Matt's experience with making sites fast for big clients, the tools they use at Aristotle Interactive to monitor performance metrics for their clients, the WebP image format, and a few performance pitfalls and how you can avoid them. Show Links: Matt Shull Aristotle Interactive Resource Timing in Practice Mark Zeman on Twitter Perfmap SOASTA Andy Davies on Twitter What Does My Site Cost Jake Archibald: Service Workers are Coming Jake Archibald: Supercharging Page Load Lara Hogan: Designing for Performance WebPageTest.Org Tableau WebP Images & Performance - David Walsh Path to Performance Slack Group

This week we talk with Brian Greene and John Hoyt, both both members of the user experience team at Nationwide Insurance. We discuss the challenges of working with such a big team, how they promote performance across departments, managing user expectations and improving perception of speed by designing feedback mechanisms, and more. Show Links: Velocity Conf Zach Leatherman slides for The Performance and Usability of Font Loading Steve Souders - Design+Performance Nationwide Episode 1 Conversation with Lara Hogan of Etsy Bryan Green John Hoyt

This week we're joined by special guest Jeff Veen. Jeff founded Typekit, which was acquired by Adobe in 2011. He recently stepped down from his position at Adobe to join True Ventures as a Design Partner. In this episode, Jeff shares what he's learned about the importance of design and performance, we talk about why slow page load speeds are a big problem for content providers, what Facebook is trying to accomplish with Instant Articles, and so much more. We are sponsored this week by Velocity Conference. Learn from web performance and DevOps experts, and network with developers and operations engineers in beautiful Santa Clara, CA, May 27-29, 2015. Use coupon code “20path” for 20% off your ticket! Show Links: Facebook Instant Articles Jason Grigsby's tweet about Instant Articles Jeff Veen Follow Jeff on Twitter Typekit True Ventures The Art and Science of Web Design

This week, Katie and Tim talk to Jeff Lembeck of the Filament Group about how they conduct performance analysis, how they sell performance, why everyone needs a "Jank Tank", and the importance of perceived performance. Our sponsor this week is SpeedCurve. SpeedCurve is built on top of the WebPageTest API and allows you to get continuous feedback on how your front-end code affects a user's web experience Show Links: Udacity: Browser Rendering Optimization State of the Union for ecommerce page speed from Radware Web Performance Today More Weight Doesn't Mean More Wait Jeff Lembeck Filament Group Designing with Progressive Enhancement Responsible Responsive Design by Scott Jehl Critical CSS WebPageTest API Steve Souders Network Link Conditioner Accessibility and Low-Powered Devices Jeff Lembeck on A List Apart We'd love to hear from you! If you have feedback or you'd like to be on the show, email us at hello@pathtoperf.com!

This week, Tim talks about performance budgets, and shares how he sets up a performance budget for the sites he works on. We also speak with Mark Dorrison about how he focuses on performance at a technical level, how to talk performance with your clients, how to sell performance to clients that aren't familiar with how important it really is, how they test performance at Chromatic, and more. Show Links: Chromatic Chromatic on Twitter Mark Dorison on Twitter Web Performance Slack Group Paul Irish's comment on "Fast Enough" Performance Budget Metrics Andy Davies on Twitter WebPageTest Bulk Tester WebPageTest API Grunt*Perfbudget SpeedCurve We'd love to hear from you! If you have feedback or you'd like to be on the show, email us at hello@pathtoperf.com!

Welcome to the Path to Performance, a podcast for everyone dedicated to making websites faster. In this episode, we discuss Tim's latest project, What Does My Site Cost, HTTP2, and a new site for performance audits (perfaudits.com). For our interview this week, we're joined by Lara Hogan. Lara is the Senior Engineering Manager of Performance at Etsy and the author of Designing for Performance. She shares how she uses video to show website performance, how she motivates her Etsy team to care about performance, how to get your clients excited about performance, and more. Our sponsor this week is Build Right: Workshops for a better web. Build Right's workshops will help bring you up to speed on the most advanced tools and techniques for crafting the web—and get you excited to build right. Show Links: Lara Hogan Lara Hogan on Twitter What Does My Site Cost? WebPageTest PerfAudit.com Advanced Performance Audits with DevTools HTTP2 for front-end web developers With HTTP/2, Akamai Introduces Next Gen Web Seth Walker on Twitter Code As Craft Etsy's Performance Wall Monitor Recent Etsy Performance Hero Designing for Performance CatchPoint Nagios Native app performance metrics Colt McAnlis on Twitter Etsy on GitHub We'd love to hear from you! If you have feedback or you'd like to be on the show, email us at hello@pathtoperf.com!