Podcasts about list apart

My guests today are Colin Eagan and Jeffrey MacIntyre. Although they work for different companies, Colin and Jeffrey share a common focus: how information technologies might offer more personalized experiences. They co-authored an article on the subject for A List Apart and Jeffrey gave an excellent presentation based on that material at this year's IA Conference, which led to this interview.See full show notes at:https://theinformed.life/2024/07/14/episode-144-colin-eagan-jeffrey-macintyre/

Justin is an internationally-renowned design leader, author and speaker from Chicago. You'll often find him at AIGA's speaking events, he's been interviewed in Forbes magazine and Medium's "Forge" publication, and he writes articles for Aquent, CEO World Magazine, and A List Apart. He speaks internationally on culture and design, and today on the show, we talk about values, aligned design, nurturing teams, and design leadership. Listen to learn about:>> Discovering and leveraging our core values >> Why humility is the most important trait for a designer>> Building and nurturing teams >> Justin's latest book, In Fulfillment: The Designer's Journey Our Guest Justin is an internationally renowned design leader, author, and speaker from Chicago. You'll find him often engaging with the AIGA's speaking events, interviewed in Forbes magazine and Medium's "Forge" publication, and penning articles for Aquent, CEO World Magazine, and A List Apart. He speaks internationally on culture and design, including keynotes at the UXPA International conference, Midwest UX, and St. Louis Design Week. Justin is also the writer of the celebrated book "Creative Culture," a former VP of Design at bswift (a CVS Health company), and the founder of design leadership consultancy Anomali. Show Highlights[02:11] Justin's design “Eureka!” moment in high school. [03:12] The Art Institute of Chicago and teaching himself how to code. [05:24] The most important part of being a designer. [05:50] From Me to We. [07:10] Justin talks about the writing of his latest book, In Fulfillment. [08:02] Transitioning from hands-on fulfillment toward mentorship and leadership. [09:46] Identifying the core set of values that lead us to feeling fulfilled. [10:29] Humility and design. [11:39] How Justin helps people find their core set of values. [12:03] Using the Make Meaningful Work platform. [12:55] What drives us to do what we want to be doing? [14:04] Knowing our core values helps create a healthier work environment. [14:55] Our core values are portable, no matter where we may work throughout our career and in any field. [15:50] Why humility is the most important trait for a designer. [17:25] Our energy pool is a finite resource. [19:06] How an organization's website implicitly shines a light on what they value. [23:11] The best teams are diverse, inclusive teams. [23:52] Dawan talks about empathy theater and taking the next steps beyond empathy. [26:15] A Miro Moment. [27:44] Justin talks about nurturing teams. [28:15] Allowing for time to pause and connect within the workspace. [29:06] Dawan talks about the benefits of not being 100% occupied 100% of the time. [30:43] Supporting “real life” in our work environments. [33:26] We need to adjust how we work and our expectations about the “right” way to work. [34:57] Justin offers thoughts on how to make the hiring and onboarding process better. [40:05] How to design and nurture a better work culture. [42:22] Justine talks about some of the work being done by his company, Anomali by Design.[46:43] Justin offers some last words of advice for all of us about taking time to pause with intent. LinksJustin on Twitter Justin on LinkedIn Justin on Medium Justin on Instagram Anomali By Design Anomali on Twitter Practical Design Leadership podcast The Essential Fusion of Culture & Design with Justin Dauer Make Meaningful Work   Book Recommendations In Fulfillment: The Designer's Journey, by Justin Dauer Cultivating a Creative Culture, by Justin Dauer   Other Design Thinking 101 Episodes You Might Like Employee Experience by Design: How to Create an Effective EX for Competitive Advantage with Belinda Gannaway — DT101 E75 Designing Your Team + Teams in Design Education + Coaching Design Teams with Mary Sherwin and David Sherwin — DT101 E49 Healthcare Design Teams + Wellness + ScienceXDesign with Chris McCarthy — DT101 E24

Justin is an internationally-renowned design leader, author and speaker from Chicago. You'll often find him at AIGA's speaking events, he's been interviewed in Forbes magazine and Medium's "Forge" publication, and he writes articles for Aquent, CEO World Magazine, and A List Apart. He speaks internationally on culture and design, and today on the show, we talk about values, aligned design, nurturing teams, and design leadership. Listen to learn about:>> Discovering and leveraging our core values >> Why humility is the most important trait for a designer>> Building and nurturing teams >> Justin's latest book, In Fulfillment: The Designer's Journey Our Guest Justin is an internationally renowned design leader, author, and speaker from Chicago. You'll find him often engaging with the AIGA's speaking events, interviewed in Forbes magazine and Medium's "Forge" publication, and penning articles for Aquent, CEO World Magazine, and A List Apart. He speaks internationally on culture and design, including keynotes at the UXPA International conference, Midwest UX, and St. Louis Design Week. Justin is also the writer of the celebrated book "Creative Culture," a former VP of Design at bswift (a CVS Health company), and the founder of design leadership consultancy Anomali. Show Highlights[02:11] Justin's design “Eureka!” moment in high school. [03:12] The Art Institute of Chicago and teaching himself how to code. [05:24] The most important part of being a designer. [05:50] From Me to We. [07:10] Justin talks about the writing of his latest book, In Fulfillment. [08:02] Transitioning from hands-on fulfillment toward mentorship and leadership. [09:46] Identifying the core set of values that lead us to feeling fulfilled. [10:29] Humility and design. [11:39] How Justin helps people find their core set of values. [12:03] Using the Make Meaningful Work platform. [12:55] What drives us to do what we want to be doing? [14:04] Knowing our core values helps create a healthier work environment. [14:55] Our core values are portable, no matter where we may work throughout our career and in any field. [15:50] Why humility is the most important trait for a designer. [17:25] Our energy pool is a finite resource. [19:06] How an organization's website implicitly shines a light on what they value. [23:11] The best teams are diverse, inclusive teams. [23:52] Dawan talks about empathy theater and taking the next steps beyond empathy. [26:15] A Miro Moment. [27:44] Justin talks about nurturing teams. [28:15] Allowing for time to pause and connect within the workspace. [29:06] Dawan talks about the benefits of not being 100% occupied 100% of the time. [30:43] Supporting “real life” in our work environments. [33:26] We need to adjust how we work and our expectations about the “right” way to work. [34:57] Justin offers thoughts on how to make the hiring and onboarding process better. [40:05] How to design and nurture a better work culture. [42:22] Justine talks about some of the work being done by his company, Anomali by Design.[46:43] Justin offers some last words of advice for all of us about taking time to pause with intent. LinksJustin on Twitter Justin on LinkedIn Justin on Medium Justin on Instagram Anomali By Design Anomali on Twitter Practical Design Leadership podcast The Essential Fusion of Culture & Design with Justin Dauer Make Meaningful Work   Book Recommendations In Fulfillment: The Designer's Journey, by Justin Dauer Cultivating a Creative Culture, by Justin Dauer   Other Design Thinking 101 Episodes You Might Like Employee Experience by Design: How to Create an Effective EX for Competitive Advantage with Belinda Gannaway — DT101 E75 Designing Your Team + Teams in Design Education + Coaching Design Teams with Mary Sherwin and David Sherwin — DT101 E49 Healthcare Design Teams + Wellness + ScienceXDesign with Chris McCarthy — DT101 E24

Power of Ten is a podcast hosted by Andy Polaine about design operating at many levels, zooming out from thoughtful detail through to organisational transformation and on to changes in society and the world. My guest in this episode is Alex Schmidt, author of Deliberate Intervention: Using Policy and Design to Blunt the Harms of New Technology. Alex has pursued interests in public service and design through different avenues over her career. As an award-winning reporter and producer for NPR and others, she covered arts, business, technology, and urban development. Alex has published work in The New Yorker and The Los Angeles Times , among other outlets. Her writing about UX, privacy, and other design topics has appeared in A List Apart and The Columbia Journalism Review. As a researcher, strategist, and UX designer, Alex has worked both for agencies and in the public sector. Her greatest interest lies in the wicked problems inherent in enterprise design and the mysterious ways of large systems. Show Links This show's web page Alex Alex on LinkedIn Alex on Twitter Alex's personal website Deliberate Intervention book Andy Subscribe to Power of Ten Subscribe to Andy's newsletter Doctor's Note Andy's online courses Andy on Mastodon Andy on LinkedIn Polaine.com Suggestions? Feedback? Get in touch!

In this episode, I'm joined by Preston So, he's the senior director of product strategy at Oracle, the editor in chief of Tag1 Consulting, the Editor of A List Apart, a regular columnist at CMSWire, and the founder of Decoupled Days. Preston is also an author with two newly released books; Voice Content and Usability and Gatsby: The Definitive Guide. Preston has had a long and storied career working on the bleeding edge of digital and has in recent times been focusing his attention on the opportunities of voice in customer experiences. We talk about the need to rethink how we understand what customer experience is online, preparing brands for the emergence of new technologies that will usher in new ways for people to interact with products and services, and how content strategy is transforming as the way we use the internet is becoming more diversified. --- Subscribe to The Martech Weekly newsletter here: www.themartechweekly.com Go here for show notes, links, and resources. Follow Juan on LinkedIn and Twitter. You can find Preston So on LinkedIn and Twitter and on preston.so.

Many content professionals were first introduced to the practice of content modeling by Rachel Lovinger's 2012 A List Apart article on the subject. Content modeling gives teams of authors, managers, designers, and programmers a shared understanding of a content ecosystem. Before they write a single sentence or line of code, teams align on a common language that keeps their work in sync. Content modeling accounts for everything from the authoring experience to metadata strategy to the end-user experience. It helps team visualize the content landscapes they are creating, and it serves as a conversation starter for any number of important stakeholder interactions. https://ellessmedia.com/csi/rachel-lovinger/

Rachel Lovinger Many content professionals were first introduced to the practice of content modeling by Rachel Lovinger's 2012 A List Apart article on the subject. Content modeling gives teams of authors, managers, designers, and programmers a shared understanding of a content ecosystem. Before they write a single sentence or line of code, teams align on a common language that keeps their work in sync. Content modeling accounts for everything from the authoring experience to metadata strategy to the end-user experience. It helps team visualize the content landscapes they are creating, and it serves as a conversation starter for any number of important stakeholder interactions. We talked about: her content strategy and content modeling work at Publicis Sapient the content-modeling lessons she learned working on the content and CMS for Entertainment Weekly at Time, Inc. her identification at one point as "a content manager of content management systems" her discovery when she interviewed for her first content strategy job that she was already doing everything in the job description her shift from content strategy to more of a focus on content modeling one of the big benefits of content modeling: its ability to help you visualize the landscape of the content you want to create the importance of accounting for the CMS authors' experience into your content model her work more than 20 years ago with a headless CMS her early work around organizing keywords and other metadata into controlled vocabularies her push for training and guidelines in many of her system implementations how a content model can help streamline documentation creation and author training how content models can serve as a conversation starter for important stakeholder interactions Rachel's bio Rachel Lovinger is a Group Director of Content Strategy at Publicis Sapient in New York City. With over 20 years' experience in online publishing, website development and content management, she's an internationally recognized thought leader in the discipline of Content Strategy. She regularly works on public-facing and enterprise projects, developing content models, metadata strategies, and overall content strategies for clients in a wide range of industries, including automotive, publishing, medical, financial services, travel, and entertainment. Rachel is dedicated to exploring a future in which information is well-structured and well-described, and connections are more easily discovered. Links mentioned in the interview Rachel's Twitter profile The Nimble Report, 2010 First Principle: Disambiguation, March 2012 Content Modelling: A Master Skill, April 2012 Video Here's the video version of our conversation: https://youtu.be/num6SZwnRmM Podcast intro transcript This is the Content Strategy Insights podcast, episode number 109. To build a good system of any kind, like a modern content system, it's important to give everyone involved a clear picture of the system - before you start designing and engineering it. A content model gives authors, managers, designers, and programmers a shared visual understanding of a content ecosystem, before a single word or line of code is written. Rachel Lovinger was one of the first content professionals to develop and teach this important content practice. Interview transcript Larry: Hi, everyone. Welcome to episode number 109 of the content strategy insights podcast. I'm really happy today to have with us Rachel Lovinger. Rachel works now at Publicis Sapient, and welcome Rachel, tell the folks a little bit more about what you do there at Publicis Sapient and how you got into content modeling. Rachel: Hi, Larry. Thanks for having me and sure. So I'm a Group Director of Dontent Strategy at Publicis Sapient, and I've been there, I guess 16 years. Worked on a number of different projects. The company has gone through several name changes since I've been the...

Aaron Gustafson is a Principal Program Manager on the Microsoft Edge team, focused on their work on Progressive Web Apps and developer UX. He's also a spec editor at the W3C and Editor-in-chief of A List Apart. Aaron joins Luke and Jonathan to talk about the Open Web and share his perspective (and some guidance) with the WordPress community.

Aaron Gustafson is a Principal Program Manager on the Microsoft Edge team, focused on their work on Progressive Web Apps and developer UX. He’s also a spec editor at the W3C and Editor-in-chief of A List Apart. Aaron joins Luke and Jonathan to talk about the Open Web and share his perspective (and some guidance) […]

This week's episode is sponsored by Cloudflare Pages (https://enjoythevue.io/cloudflare-pages)! Laurie Barth, or Laurie on Tech as she is well-known in the dev industry, is a software engineer who started as a mathematician, currently working as a Senior Software Engineer at Netflix. Additionally, Laurie is a content creator and technical educator across various mediums. She is also a frequent conference speaker, speaking at events across the globe, and a technical blogger contributing to publications such as CSS Tricks, Smashing Magazine, and A List Apart, as well as an active member of the TC39 Educator's committee and a Google Developer Expert. In today's episode, we share some of our more memorable job interview experiences, both good and bad, but mostly terrible, and we dive into how those experiences could be improved upon, starting with the company setting realistic expectations for potential candidates from the beginning. We also touch on unnecessary and unfair technical demonstrations, the value of affording candidates the option to show themselves in their best light, and the inherent biases that exist when interview panels aren't diverse, and Laurie highlights the power that candidates actually have given the shortage of engineers making this appeal to listeners: take some of that power back! Tune in today for all this and so much more, including, of course, our weekly picks. Key Points From This Episode: Laurie shares a terrible technical interview that stands out from her experience. Why a generic interview format very rarely makes sense for any company. Why companies need to set their expectations at the beginning of the interview. The importance of recognizing how much time it takes to develop a technical interview. Why you can't steal an interview from elsewhere rather than writing one yourself. The value of judging what is important based on the signal a company is looking for. Alex talks about one of the more memorable (read: terrible) interviews he has been through. Ari reflects on a pair programming interview that she describes as ‘interesting'. The pressure that is put onto incoming developers to demonstrate their technical skills when it isn't necessary for the role they will fill. Laurie emphasizes why companies should be looking for someone to augment their team. Why it's not about working with people ‘smarter' than you, but people you can learn from. Laurie's frustration with the use of trivia questions and the benefits of offering candidates options to present themselves in their best light. Tessa's turn to share her experience with a terrible interview that featured live UI coding. The disconnect that exists between hiring managers, recruiters, and candidates. Laurie highlights the power that candidates hold given the shortage of engineers and urges listeners to take that power back. What Ari calls ‘douchebag alert' questions, how people answer, and what it says about them. The gender bias that typically exists when interview panels aren't gender diverse. Why it's important for team members to meet potential candidates and vice versa. Tessa shares the acronym, REACTO: repeat, example, approach, code, test, optimize. How interviews tend to cater towards those who are extroverted, outgoing, and talkative. Laurie highlights some positive interview experiences and what companies can do better. Alex shares a tip about asking the same question of everybody, such as “what is the focus of your company?” Tweetables: “People can't read your mind. You need to preface, you need to set your expectations at the beginning [of the interview].” — @laurieontech (https://twitter.com/laurieontech) [0:07:45] “I want to work with people who are smarter than I am, but here's the trip: everyone is smarter than I am. It depends what the measuring stick is and what category we're talking about.” — @laurieontech (https://twitter.com/laurieontech) [0:26:51] “The goal of an interview, in my mind, should be for people to show you what they know instead of what they don't know. If you're giving people options, you are giving them the opportunity to present themselves in their absolute [best light].” — @laurieontech (https://twitter.com/laurieontech) [0:29:59] “Right now, in this moment in time, unless you are an entry level candidate, the candidates have all the power. There's such a shortage of engineers. I would like to see people taking that power back a little bit.” — @laurieontech (https://twitter.com/laurieontech) [0:38:41] “Interviews, pretty much no matter what you do, will always somewhat cater to people who are extroverted and outgoing and talkative. The only way I challenge that is I think people who can't communicate about their code at all are probably not great engineers.” — @laurieontech (https://twitter.com/laurieontech) [0:48:47] Links Mentioned in Today's Episode: laurieontech.com (https://laurieontech.com) @laurieontech on Twitter (twitter.com/laurieontech) Fortnite (Windows, macOS, Nintendo Switch, PlayStation 4, PlayStation 5, Xbox One, Xbox Series X/S, iOS, Android) (https://www.epicgames.com/fortnite/en-US/home) LEGO (https://www.lego.com/) Wingspan (https://stonemaiergames.com/games/wingspan/) (Boardgame) Heal & Glow Facial Serum (https://www.shopplantbasedbeauty.com/shop-our-store/organic-heal-and-glow-facial-serum) How Not to Be Wrong (https://bookshop.org/books/how-not-to-be-wrong-the-power-of-mathematical-thinking/9780143127536), Jordan Ellenberg Special Guest: Laurie Barth.

This week Jeff Clark, former Research Director at SiriusDecisions/Forrester and Rockstar CMO Advisor, returns to discuss brand purpose. The topic for the interview this week is voice marketing, and we are joined by Preston So, a product architect and strategist, a digital experience futurist, a developer advocate, and a three-time SXSW speaker. Preston is also an editor at A List Apart, a columnist for CMSWire, a contributor to Smashing Magazine. He is the author of three books, including Voice Content and Usability, which we discuss, based on his experience working with voice design since 2016. This week, our visit to the Rockstar CMO virtual bar finds Robert Rose, Chief Trouble Maker at The Content Advisory, encouraging us to embrace our flaws and not to fall in love with our content.Hope you enjoy this episode, here are all the links:The people:Ian Truscott on LinkedIn and Twitter Jeff Clark on LinkedIn and TwitterPreston So on his website,  LinkedIn and TwitterRobert Rose on Twitter,  LinkedIn, and The Content Advisory Mentioned in this weeks episode:Preston's book: Voice Content and UsabilityPreston's writing on CMSWireMore from Preston on A List ApartJoe Pulizzi and Robert Rose: This Old Marketing podcastRockstar CMO:The Beat Newsletter Rockstar CMO on the web, Twitter, and LinkedInPrevious episodes and all show notes: Rockstar CMO FMRockstar CMO AdvisorsThe wonderful Piano Music is by Johnny Easton,shared under a creative commons license.

Mathieu chats with Brian, Co-CEO of Fluree, an open-source platform for data ecosystems. The conversation covers data-centric architecture designs, and why organizations should look to move away from application-centric designs. If you don't consider doing so, macro trends around data privacy laws are driving us towards data centric models anyways. May as well get ahead of the curve and gain competitive advantages from data-centricity today! About Episode In this conversation, Brian and I discuss: What is data centricity and why do organizations need to shift away from application-centricity to data centricity? How to think about data centric architecture designs. The macro drivers for data centricity (regulatory privacy laws and cost / risk benefits). Why organizations don't need to own all of the data they consume. About Fluree's Semantic Graph technology. How Verifiable Credentials enable better data-centric use cases. Business use cases of Semantic Graph technology. The benefits of being a Public Benefit Corp. About Guest Brian is the Co-CEO and Co-Chairman of Fluree, an open-source platform for data ecosystems. Brian serves on the board of directors for Fuel 50, one of the highest growth HR technology startups. He is also the co-founder of A List Apart, a web publication, 22 book series, and global conference for the web development community to expand their knowledge. Follow Brian Platz Twitter: https://twitter.com/bplatz LinkedIn: https://www.linkedin.com/in/brianplatz/ Follow Mathieu Glaude Twitter: https://twitter.com/mathieu_glaude LinkedIn: https://www.linkedin.com/in/mathieuglaude/

Sophia Prater is a UX design consultant and chief evangelist of object oriented UX, a methodology that helps teams tackle complex design challenges. In this conversation, we discuss OOUX and how it differs from other methodologies. Download episode 63 Show notes @sophiaux on Twitter Rewired (Sophia's consultancy) Ooux.com The Object Oriented UX Podcast Object-Oriented UX, by Sophia Prater (A List Apart article) Double Diamond Object Oriented UX Podcast, episode 10: Information Archaeology with Ren Pope Entity Relationship Diagram (ERD) The Elements of User Experience, by Jesse James Garrett (pdf) Conceptual Models: Core to Good Design, by Austin Henderson and Jeff Johnson Some show notes may include Amazon affiliate links. I get a small commission for purchases made through these links. Read the transcript Jorge: Sophia, welcome to the show. Sophia: Well, thank you for having me. I'm excited to be here! Jorge: Well, I'm excited that you're joining us as well. For folks who might not know you, would you mind please introducing yourself? About Sophia Sophia: Yeah, sure. I'm a user experience designer. I was based out of Atlanta, Georgia, but I recently did a COVID move up to the north Georgia mountains. I am here in the beautiful... the bottom of the Appalachian Mountains. Kind of where the Appalachian trail starts. I'm very close to that. I got into UX in 2009, which was a great time to be entering the field and really kind of what I'm known for is Object-Oriented UX. I wrote an article back in 2015 in "A List Apart." I had about, I guess, 15 minutes of fame on the internet where that article was one of the top articles for "A List Apart" for the year. It got retweeted and tweeted thousands of times. I was very nervous to publish that article, because I did feel like I was turning the UX process — at least, what I considered the traditional UX process — I was sort of turning it on its head or turning it inside out. And I was really worried that people were going to throw tomatoes at me. But it really resonated with people, which was very encouraging to me. I continued, pounding on this process that I had just started to use in my work and slowly over the years, it came to be that people would come to me as a consultant. I started my own... I finally left the corporate world. I had been at cnn.com as a UX designer. That was my only internal role, but I've been at a whole lot of agencies. And I started my own consultancy in 2014 and within a few years, that became what I was known for. So, companies would come to me to specifically get this type of UX design, Object-Oriented UX. And then I started teaching it, and I started teaching it at workshops. First at conferences, and then I started teaching workshops within companies. So, companies would bring me in. I recently had Facebook bring me in. I've had MasterCard, Credit Karma... a lot of big, exciting companies bring me in to train their team on Object-Oriented UX. So, really that's 100% of my world now, is Object-Oriented UX. It is teaching it, delivering it to my clients, teaching it within the context of teams. Coming into a company... doing that online now. Used to do that in person; doing that all online. Spending a lot of time in Mural, moving sticky notes around there. And now I also teach individuals through a certification program that I was just getting off the ground right before COVID hit in March of last year. So now we're about a little over a year and we're in the middle of the fourth cohort of the OOUX certification program. Object-Oriented UX Jorge: Well, that's great. And we'll get into what Object-Oriented UX is in a moment, but I'm wondering why you think that the idea resonated so much with folks. Sophia: Well, I think it resonated so much, the same reason it still resonates today. Is because this is a way to break down complexity. And I think traditionally, we break down complexity by verb, traditionally. By the actions we think about. What are all the things that a user needs to do in the system? And we can get into more of the why around this, but it's a much cleaner way to break down complexity by the noun as opposed to the verb. And I think a lot of user experience designers are thrown in — especially new user experience designers — are thrown into incredibly complex situations, domains. My first project is a user experience designer, I still remember. It was with Blue Cross Blue Shield. And I was going to be designing a system for people that would design insurance packages. It was within insurance. It was a business tool within insurance, and I knew nothing about insurance. And I came on and I was expected to have wireframes by Friday. And I think that that is such a common struggle for user experience designers: they come in and wireframes are immediately expected of them. If they're working in an Agile environment, they're kind of like a wireframe factory or a feature factory. Just churn out those wireframes without a whole lot of time to gain understanding of the structure of the system. Really get an idea of the business rules and get into those business rules in a way that is collaborative and visual. I think that that's what resonated so hard for people is they saw a way out of that. They saw a way out of that rat race or that struggle of constantly having to deliver wireframes and then having these conversations around the structure. You have stakeholders and engineers. You have the engineer reverse engineering, the wireframe to get the data model out of it, and then you have your stakeholders reverse engineering, the wireframe to try to get the business rules out of it. And then what you end up with is you end up with a whole lot of re-work because the wireframe is usually going to be wrong. And so, then you do the, what I call the "Bring me a rock game," where you're like, "Oh, okay, that rock is too big or too bumpy." Like, "Let me go get you a smaller, smoother rock!" And you go and say like, "Oh, is this the type of rock you're looking for?" So, a lot of times information architecture, which is so important, but as you know, often in our industry and the user experience design industry, we don't do enough of that information architecture. And I think that this is a way to do information architecture in a visual way and in a collaborative way. So, you can bring your engineers and you can bring your stakeholders in and you can all sort of explore the complexity together and break down the complexity together and get out of that surface-level design work, where you're just moving wireframes around. And if you don't have that deep understanding of the system, you're just going to be moving the deck chairs around. You're going to be moving UI around. You're not going to be making systemic change. And at the end of the day, UX designers are incredibly idealistic people. We want to make big change. We want to solve big problems, but if we can't figure out how to get out of that moving the deck chairs around on the sinking Titanic, then work isn't very much fun and we don't have a lot of meaning from it either; you can't draw a lot of meaning from it. Jorge: I'm going to try and articulate it back to you to see if I'm getting it correctly, but the idea that there is a way for designers to work at a higher level of abstraction than how these things manifest in more tangible ways. How then does Object-Oriented UX fill that gap? Or asked another way, how do you introduce folks to what Object-Oriented UX is? Sophia: Yeah, okay. So, what Object-Oriented UX is — And I want to differentiate Object-Oriented UX versus what I call the ORCA process — so, Object-Oriented UX is a philosophy; a philosophy that is based in the fact that people think in objects. And there is a lot of interesting research on that, that we can get into, if you want to ask about that, on cognition and how people think and how people understand the world. And a lot of that is based in objects. So, for the philosophy part of it for Object-Oriented UX, if we say, "this is a philosophy that respects and acknowledges the fact that people think in objects. And to gain an understanding of an environment, you really need to understand what that environment is made up of. What are the objects that make up that environment? And thus, we need to make that clear in our digital environments, just like they're clear in our physical environments." So, Object-Oriented UX is all about defining what your objects are, figuring out what those are, what are the objects in the user's mental model, in the business model, those really valuable things. Objects And I need to kind of take a step back, I think, and define what is an object. I'm very specific when I talk about what an object is. An object is a thing that has value to the user. So, when I say objects, I'm not talking about your navbar or your calendar picker or your dropdown. All those things are valuable, but they are a means to an end. And I often say no user is coming to your site for your calendar picker. It could be the best calendar picker in the whole world, but that's not what they're coming for. They're coming for the event, or they're coming for the people that they can invite to the event. So, an object is going to have... I use the acronym SIP. It's going to have structure, it's going to have instances, and it's going to have purpose. So OOUX is all about saying, "okay. If we know that our users think in objects and just human beings think in objects — not just our developers — human beings think in objects, and to be able to gain understanding, you need to understand what the objects are in that system. And to understand what the objects are we need a certain level of consistency and recognizability to our objects." As the designers of these environments, if we don't get super clear on what our objects are, there's no way — there's just absolutely no way in hell that we're going to be able to translate that to our end users. We're just not! If we can't get it straight on our team and we can't get it straight among ourselves, then that's going to create a lot of communication problems internally, which is a problem that I hear all the time. We've got everybody on the team coming together. And some people, depending on what department you're in or what your role is, you've got the same object, the same thing being called two or three different things and different objects being called the same thing. And you're trying to design complex software. So just getting on the same page internally is going to be absolutely intrinsic to making sure that it's clear to your end users. So, one kind of, I guess... not metaphor, but like journey that I could take you on, Jorge, and the listeners, is: imagine going into a coffee shop. And it's a coffee shop you've never been to. You walk into this coffee shop, but this is like, this is a funky coffee shop. Maybe it's a coffee shop in Amsterdam or something. And you walk into this coffee shop, and you can't tell the difference between the tables and the chairs, and the people. Like you know that there are tables and chairs and people there, you can see the things, but you can't tell the difference between them. And you can't actually tell the relationships between them either. You can maybe like, with intense concentration, you identify a chair, but you can't tell what table goes with what chair, right? Or you can identify a chair, but you can't understand the status of that chair. Is that chair occupied or unoccupied? That would be a very difficult environment to navigate and to function in, yet we create digital environments like that all the time where it's difficult for users to understand, what are the valuable things to me here? What can I do to these things? How do these things relate? What are these things in context of this place? And what is the structure of these things? What is the status of these things? What are the attributes of these things? And that kind of gets into the ORCA process, which stands for: objects, relationships, CTA's, which is calls-to-action, and attributes. And that's the process that I use in my work, and I teach to design really awesome object-oriented user experiences. Jorge: This analogy of the coffee shop is an interesting one, because I can contemplate it in the abstract, but in my real world experience, I've never been in a coffee shop where I can't tell the chairs from the tables or what have you. So, it does feel like a discussion that can get abstract quickly. And I'm wondering how do you draw the bounds around an object? Like how do you determine that something is a table in your systems so to speak. Sophia: Right. and that is actually, I mean, saying, "Oh, we need to figure out what the things are." That's so much easier said than done. And that is a huge part of the ORCA process. We actually iterate on it, to say, "all right, how do we figure out what these things are?" And that is all going to come from research. So, the ORCA process is definitely a "garbage in, garbage out" process. You've got to have good research coming into it. I often say that this is a good process for synthesizing your research before you get into design. If you think about the double diamond, you can literally see the weak link between the double diamond, right? Like, what happens after you get through research and then you just start sketching stuff — you just start designing. There needs to be something that happens between research and design, where you are synthesizing that research into structure and into information architecture. And the ORCA process is just this really kind of like... it's like a meat grinder. Like you just throw the research in and... so when I was interviewing Ren Pope, he used the term "information archeology." And I love that. I feel like that's a lot of what this process helps you do is that information archeology, where you're taking all that research and you're analyzing that research to figure out what are your objects, what are the relationships between the objects, what can users do to the objects, and what are their attributes? And specifically with objects, like knowing, is a table a thing in this particular system that we're designing and in this environment that we're designing? One of the first activities that we do is called "noun foraging." It's really fun. You take all that research, user interviews, interviews with your stakeholders, competitive analysis, analytics as well, of course current site audit, content audit as well is great to have if you have access to that. So, you're taking in all this research and you're looking for the nouns, and you're looking for the nouns that get used over and over and over again. And you're looking for synonyms like, "Oh! Are these the same thing or are these not the same things?" And then that turns into conversations to have with your stakeholders. For example, I was working with a company called Blood Relay and basically what they do is they take blood samples... they're software, but they help facilitate blood samples being taken from the hospital to the lab and then getting the analysis back to the hospital. So, it's pretty complex business software with all the complexity that you get in healthcare and the healthcare industry. And when I was doing my noun foraging, I kept hearing the words "sample" and "product." Sample and product. Sample — product. And they were being used interchangeably. They were being used interchangeably by the business. They were being used interchangeably on the marketing site. They were being used interchangeably on the actual software in places. And one of my big jobs in the beginning was to figure out, are these actually the same thing or are these two different things? Is there actually a relationship between these things and that came with conversations with the experts, right? So how do you define a product? How do you define a sample? Are these... and it turns out they are two separate things, and many products can be taken from a sample. So, you have that one-to-many relationship there. And that's so important to define. If I'm going to be designing software for this, I need to understand the difference between those and reinforce the truth of the world through that user interface. Visualizing systems Jorge: What I'm getting from your description of Object-Oriented UX is that it's not just articulating the domain as a series of nouns and relationships between them, but also expressing it in a sort of visual way, right? That allows people to get a shared understanding of that domain. Is that right? Sophia: Right. Yeah, and that gets into some of the artifacts that we produce in the ORCA process. So, you know, Object-Oriented UX, you could use any methodology to say that eah, we need to define what the objects are, and we need to make them super clear within the interface. So, we don't get into that coffee shop scenario." Where, you know, if I'm designing software for a teacher, which, I did a lot of work in EdTech. If I'm designing software for a teacher and the important things for that particular problem domain that we're trying to solve for, are students' lessons, standards and parents, let's say. I want that teacher to open up that application and to immediately recognize those things. To immediately recognize the relationships and say like, "oh, okay. Yeah, this is just... this is how my world is." And then be able to do really amazing things. Have x-ray vision into those things. Have connections in a way that's super meaningful, and then to be able to do things to those objects that are more difficult in the real world without that tool, or that you know, it's just absolutely impossible to do without that tool. Jorge: That step of articulating the understanding of the domain visually is not to be underestimated. It's a huge part of it. I'm certainly always on the lookout for new ways of doing it because it's so hard to do. I find that a lot of folks have a hard time thinking at that more abstract level. Sophia: Yeah. And when you get into something like a system model or domain model, conceptual model. Basically, when you have lots of bubbles and arrows going? Entity relationship diagram, right? Which we do that work. That's part of the process. We build... I call it a system model, but it's basically an ERD. It often turns into a bowl of spaghetti, and it gets a little bit difficult to track, especially when there's multiple types of relationships between two objects. Then what do you do? Do you have multiple arrows, or do you have multiple labels on the same arrow? I mean, God forbid your system has 17 objects in it, which if you're working in electronic healthcare records, if you're working in insurance... I have worked with tools before, or these, you know, these digital systems that we've had double digits of objects and that entity relationship diagram kind of breaks down. What also breaks down is if you try to start putting attributes in there. Which I've seen done before, where you actually blow out that ERD so it's not just your objects. You actually put your operations and your attributes into that document. That gets really crazy. If you have an object that has 60 attributes, again, just the visualization of being able to show: what are the things, what are the relationships, what are the things made of. I don't necessarily think that diagram is the best way to visualize that and to do it in a collaborative way where everybody can be involved, your engineers can be involved, and especially your business folks. Getting those people involved early is gold. It's magic. Because that's when they're going to be the most useful. So, I hear this all the time: One of my main problems... this is just a recurring theme when I've asked people, like, "What is the most annoying thing about practicing UX design?" Managing stakeholders. I hear that over and over again, and even that word, "managing" stakeholders. We should be leveraging our stakeholders. Our stakeholders and our subject matter experts... usually our stakeholders hopefully are some sort of breed of subject matter expert, at least from the business side. We want to be extracting all that knowledge from their minds, and we need to be doing that early on. But what happens is we try to show them wireframes, or we present diagrams to them instead of getting them to co-create diagrams with us and to really feel heard early on in the process. And the thing is, is, your stakeholders are not trained and they're not good at giving you feedback on your wireframe. And it's very easy. You're conflating presentation and content basically, which we know not to do. We've known that for a long time, not to do that. And yet we still do that, and we still expect quality feedback from our stakeholders when they're looking at structure and design all at once. Design collaborations Jorge: I'm glad you dropped the word co-create in there because as you were talking, I was thinking that the way that I approach the relationship with stakeholders is — or I try to at least — is as a collaboration, right? Where you engage their mind, expertise, their drivers, in the process of designing the thing. And to your point, for a complex system, that needs to start way before you're ready to put things down at the screen level. But there's this dilemma that it's hard to understand the implications of decisions until you see them reflected in something more tangible. Sophia: Yeah, and I think that it's an uphill battle. Let's just say, I mean, they want, often, "they," stakeholders, business folks... they want to see the pictures. They want to see what does it actually going to look like? And I think we've trained them to want to see that. Just because we haven't figured out a really good way to involve stakeholders early doesn't mean it's not possible. I've seen success across so many of my students in bringing stakeholders in early by using the object mapping methodology and going through this process of figuring out... it's just it's color-coded sticky notes! That's really all it is. So, in really nicely organized columns. And it's scalable too. If you have 20 objects, that's okay. If you have 60 attributes on an object, that's okay, too. It really does scale nicely and gives you that sort of bird's eye view of the system. I mean, the other thing that's just so important and not just for feedback, but it's so important to get your stakeholders involved early and your product owners — whoever those people, those decision makers are — on determining scope and timeline and budget. Because when you have a subject matter expert/stakeholder — I'll use those terms interchangeably, even though they're not always — I know they're not always, but if they're this close, if they've been working in the industry for 15 years or something and they say, "Oh, we're gonna create this new feature, we're gonna redesign this part of the product," it's difficult for them to really see the complexity and to understand the complexity. And if we can bring them on board with the complexity and also help elucidate assumptions, help them realize where are we making assumptions about our users… So, I was mentioning before that the input of this process is research, right? And we start with the noun foraging and going through all that research, figuring out the nouns, and we're also looking for attributes at the same time. The ORCA process is a really great gauntlet too, to realize, you need to get kicked back to research. You're not ready to start designing yet because you're designing on too many assumptions. It pulls all those questions from the future where you might be figuring them out when you're in high-fidelity wireframes or something like that. Or God forbid, you're in production where you're figuring out some of these really sticky pieces of business rules. So, this is a tool to help bring all those questions from the future, and make sure that your stakeholders potentially are coming up with those questions too through the process. They're right there with you. They're in the weeds, hands dirty, figuring out some of those questions, and this is going to be able to help you sell more research. Because selling research by saying, "We need to find out more about the user" — that is a really hard sell right there. That's super vague. "Oh, we need to get to know our user." "Great. Okay. Can we just design this product?" But if your stakeholder herself or himself says, "Oh, we don't really understand if... does a doctor work at multiple locations or does a doctor only work at one location? What's the relationship between a doctor and a location? We're assuming that the doctor only has one location, but we're actually not sure how much our doctors are moving around from location to location. Put that in a parking lot." That goes in your user interview transcript, okay? And so, it's the actual stakeholder or the businessperson that has gotten invested in those questions. This is how you sell additional research by getting really specific about what are those questions that need to be asked. OOUX and information architecture Jorge: What you're describing seems very familiar to me, as an information architect, and I'm wondering... I revisited the A List Apart article in preparation for our conversation today, and I got the sense from that article that one of the distinctions between this methodology and something like information architecture is perhaps that... I'm going to use air quotes now, like "traditional information architecture" is more oriented towards content-heavy systems. And I'm thinking of like Jesse James Garrett's elements diagram, right? That is split into what he called information-oriented systems versus task-oriented systems. Would it be fair to say that this is more applicable to the task-oriented systems in that duality? Sophia: So, yeah. I see where you're coming from. The naming around this is coming from… my background is in industrial design. I actually started as a product designer, designing refrigerators for Electrolux. Didn't last long in that career, but that's my background. And then I, again, like going back to the timing, so my very first job as a UX designer was in 2009. This is where Jesse James Garrett would have been like, "We're all UX designers." Right? So, that had already happened. I didn't find out about information architecture until years later. Okay, because just thinking about the timing of when I'm coming into this, I'm coming into it from a user experience perspective and also working on, yes, task-heavy products. So, if you think about, you could even — and I often tell people — you can think about an object... The way I define an object, you can think about it as a content type. Now, I don't like the word "content type." I know this is going to be like controversial, but I prefer the term object, because if I'm working on a system — let's say for used car salesmen to manage their sales and their inventory — a vehicle is not a content type. A vehicle is a thing in a parking lot that is connected to customers, that is connected to sales events, that is potentially connected to other salespeople. Which salesperson sold this car? A salesperson isn't a content type. These are all actual things manifested in the real world and that we are using metaphor to reflect in our user interface. That said, I have used Object-Oriented UX for 100% content sites. So, if we think back to the elections in 2012, when... that's how this all started, I was doing my very first responsive design for CNN election results. That was a lot of data viz, but that was all content. There was no user interaction there; it was all content. And that is actually... I guess the crucible for how I started thinking this way. OOUX and conceptual models Jorge: I'm familiar with another approach to this that I think is similar in at least in intent not in the form it takes, which is the one that I often refer to folks when talking about this stuff and it comes from Jeff Johnson and Austin Henderson's book, Conceptual Models. There you go; you've got it! Not fit for radio, but you're holding up the book cover to the camera. And I'm just wondering if you could speak to the differences between those approaches. Sophia: Yeah, I think they kind of feed each other. I looked back over my notes on Conceptual Models, and most of it I'm underlining and I'm happy faces and check marks in the margins here. There were a couple of places where I like vehemently scribbled question marks. And like, "No, no, no!" But it's little things. I mean, if you think about a concept, the difference between a concept and an object. So, a concept can be... it just feels too... I don't know, the work that we do can often feel very ephemeral, very like it's… You just don't have something good and solid to hold onto. And the objects are these like anchors of understanding and getting super clear on what those objects are and making sure that you have really good lines around them. And actually, like one of the best things that we do in the process is make a glossary, like actually define these things. Concepts though can like be a little squishy. Like financial literacy could be a concept, not an object though, right? The object might be like financial literacy quiz or something like that, you know? Or privacy can be a concept. Also, how Johnson and Henderson described building a conceptual model and what a conceptual model is versus the information that is captured in an object map. The conceptual model they describe it... it's kind of this chicken and egg thing. So, they look at task analysis first and build a conceptual model from the task analysis. I'm kind of the opposite: I tend to like to figure out what are the objects in this environment, in this domain, and hone in on the problem domain, sure. Get those big picture goals on what we are actually trying to do here. But then figure out, "Okay, what are the things in this environment?" And then think about the tasks. What is it? What does a user need to do to those things? And we that's the "C" of ORCA: the calls-to-action. So, what actions — what are the affordances? — what actions does that object offer users? And that's how you get into the task. It's splitting hairs a little bit, but Johnson and Henderson do start off with that task analysis. Sometimes from research, if there's already user stories, we are analyzing user stories coming in. But if those aren't there, there's actually a point in the process that you can get user stories out of the ORCA process. So really just how concept is defined. Also, do you start with a task and then get the objects? I prefer to get the objects and then get the tasks. Start with the nouns. Start with those things and get really solid and clear on those and then figure out what the users want to do with them. Jorge: I'm hearing two things there. One is that the idea of an object is easier to relate to then the idea of a concept, because concepts can be much more vague and more abstract. And the other, which — and by the way, I find both of these ideas really intriguing — the other is that, in some ways, starting with the objects might be a bit more open-ended than starting with the tasks. Because with a collection of objects, you're not necessarily enabling any one particular task; you could enable a myriad tasks, right? There's a collection of objects, and people can do things when they have several objects at their disposal — as opposed to thinking, "What do people want to do?" and then, "What objects do we need, or concepts do we need to enable that?" Sophia: There's just so many fewer assumptions on figuring out what the objects are. Because you can go... I mean, if you can do ethnographic research, great. But going and doing your research again, going back to the teacher example, it doesn't matter what software I'm designing. Like, a teacher's world is made up of students, lessons, classes, standards, parents, other teachers — that's just the truth. And that's another thing Johnson and Henderson talk about the conceptual model being how the user thinks about the system and the task. And I am kind of a broken record when I'm talking about... I'm trying to find the truth of the system. I am trying to find — no pun intended — but like, the objective truth. If I go back to the CNN elections example, if I'm going to build a conceptual model of how people think about elections that's going to be very different than what I would call a system model, which is going to be just the truth of the system. I went in in 2012, I built a system model and I use the exact same system model in 2016 because our electoral college had not changed. We still had candidates. We had states. We had races. And we had results. And we had ballot measures. Those things did not change. And the relationships between those things actually wasn't even up to the user. That's just the truth of the world. It's just our job to communicate what are these things and how do these things relate — versus, I think that the conceptual model is a valid thing to do, and that it would've behooved us to make a conceptual model of how people think about elections. But that's going to be different than what I would call the system model. Jorge: I'm hating the fact that we're running out of time here, because this conversation is getting really meaty. When you brought up the phrase "objective truth," again, you can see this on the podcast, but I think my eyebrows shot up. Well, what you're describing there as a conceptual model is what I usually understand as a mental model. And we might have mental models that map to greater or lesser degree to what I understand of as the conceptual model, which is this set of relationships that you're describing, that I understand as standing together — regardless of what different people might think of them or how different people might understand them. Sophia: In some systems... I mean, there's not just that objective truth, you have to go and figure out, like, what are the users actually want. So, if I had to think about a doctor, is a doctor related to one location in this particular context, or is a doctor related to zero to many locations. Maybe some doctors don't have a location at all associated with them. Some doctors are going to have three locations associated with them. So that's going to come from the users and like, what is the truth of the user? You know, again, it comes back to that objective truth and sort of balancing the objective truth of the business and the objective truth of what is happening with those users and what those users actually want and need. And then there's also the back and forth of like how much do we need to create an idea in the user's head? If this is a completely new thing, how do we reinforce that business model and how the business works so it's very, very clear to the users how these things work together. And then do we kind of go back the other way and really understand then the user's mental model of these things and reflecting it back in the system. So it is that kind of... it's a balancing act, for sure. Closing Jorge: Well, thank you. That helps clarify it quite a bit. And I still feel like we have more to talk about and I'm hoping that we'll be able to do so again at some point. For now, where can folks follow up with you? Sophia: Probably the best, easiest place is ooux.com. So, if you go to ooux.com, and there's a green button, says something like, "Join the fam," or "Get involved," or something like that. I forgot what it says. All the good stuff is there. There's an Object-Oriented UX happy hour, so that would be a meetup — an online meetup. There is a podcast, the Object-Oriented UX podcast, newsletter, and of course the certification course as well. But just go to ooux.com and you'll find it. Also, @sophiavux is my Twitter. Jorge: Well, fantastic. I'll link all those from the show notes. Thank you so much, Sophia, for being on the show. Sophia: Thank you so much for having me.

This week we’re joined by long-time web developer Matt Patterson. Earlier this year Matt wrote an evocative article for A List Apart called The Future of Web Software Is HTML-over-WebSockets. In this episode Matt sits down with Jerod to discuss, in-detail, why he believes the future of the web is server-rendered (again) and how Ruby on Rails is well positioned to bring that future to us today.

This week we’re joined by long-time web developer Matt Patterson. Earlier this year Matt wrote an evocative article for A List Apart called The Future of Web Software Is HTML-over-WebSockets. In this episode Matt sits down with Jerod to discuss, in-detail, why he believes the future of the web is server-rendered (again) and how Ruby on Rails is well positioned to bring that future to us today.

For the inaugural episode of the Front End Nerdery Podcast, I interviewed Jeffrey Zeldman. We talked about the web of yesterday, web standards, An Event Apart, A Book Apart, and much, much more that had to be done in two parts. Enjoy the first half of this very special two-part episode! Intro/Outro music graciously given permission to use called, "Settle In" by Homer Gaines. Transcripts can be found at https://toddl.dev/podcast/transcripts/zeldman1/ Shownotes https://zeldman.com - Jeffrey Zeldman Personal Site https://www.amazon.com/Designing-Web-Standards-Jeffrey-Zeldman/dp/0321616952 - Designing with Web Standards 3rd Edition https://www.nytimes.com/2012/04/21/technology/hillman-curtis-a-pioneer-in-web-design-dies-at-51.html - Hillman Curtis https://www.zeldman.com/2019/12/01/bluebeanieday2019/ - Blue Beanie Day article https://aneventapart.com - An Event Apart conference https://abookapart.com - Books for designers and developers https://alistapart.com - A List Apart resources and articles https://en.wikipedia.org/wiki/A_List_Apart - A List Apart wiki --- Support this podcast: https://podcasters.spotify.com/pod/show/frontendnerdery/support

We're back to finish the inaugural episode of the Front End Nerdery Podcast with Jeffrey Zeldman. We talked about the web of yesterday, web standards, A Book Apart, what makes a good writer and conference speaker, and much more. Enjoy the second half of this very special two-part episode! Intro/Outro music graciously given permission to use called, "Settle In" by Homer Gaines. Transcripts can be found at https://toddl.dev/podcast/transcripts/zeldman2/ Shownotes https://zeldman.com - Jeffrey Zeldman Personal Site https://www.amazon.com/Designing-Web-Standards-Jeffrey-Zeldman/dp/0321616952 - Designing with Web Standards 3rd Edition https://www.nytimes.com/2012/04/21/technology/hillman-curtis-a-pioneer-in-web-design-dies-at-51.html - Hillman Curtis https://www.zeldman.com/2019/12/01/bluebeanieday2019/ - Blue Beanie Day article https://aneventapart.com - An Event Apart conference https://abookapart.com - Books for designers and developers https://alistapart.com - A List Apart resources and articles https://en.wikipedia.org/wiki/A_List_Apart - A List Apart wiki --- Support this podcast: https://podcasters.spotify.com/pod/show/frontendnerdery/support

First thing’s first: listeners to the podcast can get 15% of tickets to Button! Use the code “UXWC” at checkout to get 15% off: www.buttonconf.com. Kristina Halvorson is the CEO and founder of Brain Traffic, the coauthor of Content Strategy for the Web, the founder of Confab Events, and the host of The Content Strategy Podcast. Her seminal article, The Discipline of Content Strategy, was published in 2008 by A List Apart, the world’s most popular online magazine for web professionals. Needless to say, she knows her stuff. This month Kristina will launch Button - Brain Traffic’s first conference dedicated to product content strategy. In this chat, we talk about Button, why UX writers should be excited about it…but also, we pick up on something Scott Kubie and I discussed: what is the future of UX writing? Kristina makes the point that UX writers shouldn’t necessarily stay UX writers forever. They need to embrace content strategy if they want to move forward in their careers. And we talk about how to do just that. I hope you enjoy our talk! Check out: Button (Get 15% off with UXWC15!) Kristina on Twitter Contentstrategy.com Writers of Silicon Valley is on: LinkedIn Twitter If you like this podcast, please leave a review!  

October 20, 2015 was when Sophia's article on OOUX debuted on A List Apart. In this episode of the podcast, Sophia shows you how her philosophy and process have changed since then, how OOUX was forged in the crucible of CNN Election Night 2012, how OOUX can help you speak the same language as your back-end developers, and how noun foraging fits into her ORCA (Objects, Relationships, Calls-to-action, and Attributes) process. Enjoy! LINKS: Read the A List Apart article: https://alistapart.com/article/object-oriented-ux/ Subscribe to Sophia's YouTube channel: https://www.youtube.com/c/SophiaPrater Read Content Everywhere by Sara Wachter-Boettcher: https://amzn.to/2DRWO3w --- Support this podcast: https://anchor.fm/ooux/support

Welcome to the 446:th edition of Done!, about how to separate your to-do list from your calendar.

Eric Chen is an engineer on Heroku's Ecosystem team. With him are Justin Abrams and Michael Rispoli, who run Cause of a Kind. Cause of a Kind helps organizations with their SEO; Justin engages with the brands on a marketing level, and Michael looks after their frontend development. The goal for SEO has evolved beyond just having the right metadata appear in search results. It's also about understanding how to make better business decisions, both through marketing strategies as well as organizational and technical planning to create products that serves consumer's needs. From the Internet's beginnings, SEO has been about helping search bots crawl sites through keywords. The thinking went that the better your metadata, the more likely your website was going to appear higher in search results. But these days, SEO is more about how users navigate sites. Justin and Michael explain how if you create a site with a user's experience in mind, the search bots and algorithms will rank you more favorably. You can use proper semantic HTML, provide accessibility through labels and aria tags, or define consistent URL routes; but you can also minimize frontend JavaScript dependencies to ensure that your page loads quickly. Organizations are investing more in frontend experiences more than ever before, from SPAs to even providing virtual and augmented reality experiences. Michael believes that developing sites with an SEO-first mindset almost inherently leads to a better product, because your performance and accessibility improvements will be noticeable to your users, even if you're trying to get better search ranks. In the end, both marketing needs--getting people to visit your site--and frontend development concerns--making sure people can use your site--are no longer two distinct issues. Links from this episode Lighthouse is an open-source, automated tool for improving the quality of web pages Cause of a Kind provides web marketing services to organizations Smashing Magazine and A List Apart are only magazines on frontend development BrightEdge gives marketers real-time research, recommendations, and rankings

Note: We apologize for the audio quality. There was an issue with the microphone.Justin is a multi-faceted, multi-pierced, multi-tattooed designer, author, and speaker. He wrote the book "Cultivating a Creative Culture", is the Vice President of Human-Centered Design and Development at bswift, the founder of The Dead Pixel Society, and a contributor to A List Apart. Justin had some really intuitive viewpoints on culture that were awesome to dig into and it was a pleasure having him on the show. We cover:Working in the healthcare systemWhy he gravitates to roles that aren't tee'd up and ready to goCreative culture and the golden ruleCreative Inspiration WednesdaysHow designers have an advantage in creating a good cultureTransitioning from getting fulfillment from design to getting fulfillment from others' evolutionLeading with actionThe challenges of remote working 

Ben Simmonds is a senior UX practitioner with 20 years of experience making technology better in London, Sydney, and now in Bristol as an independent consultant. As a compliment to UX Design, Ben is also a certified Performance, Stress, and Productivity coach. He runs "UX Without The Stress" workshops to help teams and individuals navigate complex, demanding projects. In this episode of the podcast, Sophia and Ben discuss teaching what you want to learn, the information architecture of stress, and how Object-Oriented UX deconstructs complexity to enable better design. Enjoy! Sign up for Ben's next online "UX Without The Stress" workshop, scheduled for May 23, at the link below. LINKS: Keep up with Ben on his Website: http://www.bensimmonds.co/ Follow Ben on Twitter: @bensimmonds Connect with Ben on LinkedIn: https://www.linkedin.com/in/ben-simmonds-0312922/ Sign up for Ben's "UX Without The Stress" workshop! https://www.uxwithoutthestress.eventbrite.com Read Sophia's A List Apart article on OOUX: https://alistapart.com/article/object-oriented-ux/ --- Support this podcast: https://anchor.fm/uxhustle/support

Agency culture has its own unique traits. The trials and tribulations of some of the more negative dynamics led Justin to write "Resetting Agency Culture" for A List Apart, which ultimately became the impetus for the book. That said, some agencies do get it right: people-first, humble leadership, and a culture that supports and propels not only incredible work, but acts as organic marketing for new business. Wendy Nyx (creative partner at agency Primitive Spark) and Brooke Coe (former Primitive Spark teammate) articulate how establishing and thriving within a creative culture—particularly in one that's largely comprised of remote employees—is achievable and sustainable.

Desiree Garcia is a senior designer at Automattic, the company behind WordPress.com and most recently, Tumblr. Their goal is to democratize publishing so that anyone with a story can tell it, regardless of income, gender, politics, language, or where they live in the world. She's also an editor at A List Apart, a webzine that explores the design, development, and meaning of web content, with a special focus on web standards and best practices.In this episode, we discuss:How a psychology degree can influence design and teamworkWhat we miss about the old webStar Trek's Kobayashi Maru and how it applies to designHow to respond to situations that can't be wonThe challenges of talking about your workDesigning things that "aren't real"Visit the Funsize websiteSubscribe to The Funsize Digest

Sponsors: Netlify Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Special Guest: Aaron Gustafson Episode Summary  This episode of Views on Vue comes to you live from Microsoft Ignite. Charles Max Wood talks to Aaron Gustafson who has been a Web Developer for more than 20 years and is also the Editor in Chief at “A List Apart”. Aaron gives a brief background on his work in the web community, explains to listeners how web standardization has evolved over time, where Progressive Web Apps (PWAs) come from, where and how can they be installed, differences between them and regular websites and their advantages. They then delve into more technical details about service workers, factors affecting the boot up time of JavaScript apps, best practices and features that are available with PWAs. Aaron mentions some resources people can use to learn about PWAs, talks about how every website can benefit from being a PWA, new features being introduced and the PWA vs Electron comparison. In the end, they also talk about life in general, that understanding what people have gone through and empathizing with them is important, as well as not making judgements based on people’s background, gender, race, health issues and so on. Links Creating & Enhancing Netscape Web Pages A List Apart A Progressive Roadmap for your Progressive Web App Windows Dev Center – Progressive Web Apps MDN web docs PWA Stats PWA Stats Twitter Aaron’s website Aaron’s Twitter https://www.facebook.com/ViewsonVue https://twitter.com/viewsonvue Picks Aaron Gustafson: Homegoing Zeitoun Charles Max Wood: Armada  

本期节目，我们请到了来自 Graphiq 的设计主管 Samantha 同学。她先后毕业于复旦大学传播学系、西北大学整合营销传播硕士项目。她所在的公司坐落于拥有「全美最美日落」的 Santa Barbara——她竟从这美丽的日落中找到了设计灵感。 她是一位「全栈设计师」，还经营着自己的设计博客。最近，她在著名的设计网络杂志 A List Apart 上发表了文章: Learning from Lego: A Step Forward in Modular Web Design. 节目大纲 00:01:39 12岁开始在学校用「记事本」写网页 00:08:12 人生的转折点——美国西北大学「24小时编程马拉松」第一名 00:10:24 「我是这门课里最好的设计师，你要不要和我组队？」 00:19:49 Graphiq 的前世今生 00:25:30 公司单日营收暴跌60%后的战略转型 00:30:50 我是130人公司里唯一的设计师——这有利有弊 00:34:33 聊聊设计师写代码这件事——最大化「设计效率」 00:37:55 对我来说最大的挑战是——招聘！ 00:40:23 为什么我要练习硬技能 00:42:16 怎么学习编程技能 00:44:35 怎么在工作之余提高设计技能 00:52:14 设计师是否应该发展不同的技能？如何看待「全栈焦虑症」？ 00:58:54 聊聊数据可视化中的配色问题 01:05:38 如何挑选图表中的数字字体 01:07:47 一场为期一年的社会实验告诉我们什么 嘉宾联系方式 Twitter： @moyicat Medium： https://medium.com/@moyicat 工作邮箱：szhang@graphiq.com 参考链接 Finding the Right Color Palettes for Data Visualizations Finding the Best Free Fonts for Numbers The One Side Project per Year Challenge

Mat Marquis is Chair of the Responsive Issues Community Group, technical editor at A List Apart, a former member of the jQuery Mobile team, and editor of the W3C HTML5 specification. His book, JavaScript for Web Designers, was recently published by A Book Apart.

Victor Yocco recently released his first book Design For The Mind! Victor Yocco is an author, speaker, and Research Director at a Philadelphia based digital design and development firm. He regularly writes and speaks on the application of psychology to design, as well as addressing the culture of alcohol use and abuse in design and technology. Victor has written for A List Apart, Smashing Magazine, UX Booth, User Experience Magazine (UXPA) and many more. He is the author of Design for the Mind, a book from Manning Publications on the application of principles of psychology to design. Use code: smayocco at checkout to get 39% off the cover price of my book from the publisher's website. The link to the book is: https://www.manning.com/books/design-for-the-mind I talk about a ton of topics that have been burning on my mind this past week! MovyMail.com Ally the accepting alligator Adam Brick Guy Thank you Card Something old is the foundation for something new. HTC VIVE Ask your friends for sales leads. Be confident in the experience that you do have, and don't shy away when someone questions if you are worthy. United Nations Talk Shoot me your questions to Joe@SuperJoePardo.com Watch the entire Dreamers Podcast pre-show https://youtu.be/R5SK4CAzBBg Episode 238

Victor Yocco recently released his first book Design For The Mind! Victor Yocco is an author, speaker, and Research Director at a Philadelphia based digital design and development firm. He regularly writes and speaks on the application of psychology to design, as well as addressing the culture of alcohol use and abuse in design and technology. Victor has written for A List Apart, Smashing Magazine, UX Booth, User Experience Magazine (UXPA) and many more. He is the author of Design for the Mind, a book from Manning Publications on the application of principles of psychology to design. Use code: smayocco at checkout to get 39% off the cover price of my book from the publisher's website. The link to the book is: https://www.manning.com/books/design-for-the-mind I talk about a ton of topics that have been burning on my mind this past week! MovyMail.com Ally the accepting alligator Adam Brick Guy Thank you Card Something old is the foundation for something new. HTC VIVE Ask your friends for sales leads. Be confident in the experience that you do have, and don't shy away when someone questions if you are worthy. United Nations Talk Shoot me your questions to Joe@SuperJoePardo.com Watch the entire Dreamers Podcast pre-show https://youtu.be/R5SK4CAzBBg Episode 238

Victor Yocco recently released his first book Design For The Mind! Victor Yocco is an author, speaker, and Research Director at a Philadelphia based digital design and development firm. He regularly writes and speaks on the application of psychology to design, as well as addressing the culture of alcohol use and abuse in design and technology. Victor has written for A List Apart, Smashing Magazine, UX Booth, User Experience Magazine (UXPA) and many more. He is the author of Design for the Mind, a book from Manning Publications on the application of principles of psychology to design. Use code: smayocco at checkout to get 39% off the cover price of my book from the publisher's website. The link to the book is: https://www.manning.com/books/design-for-the-mind I talk about a ton of topics that have been burning on my mind this past week! MovyMail.com Ally the accepting alligator Adam Brick Guy Thank you Card Something old is the foundation for something new. HTC VIVE Ask your friends for sales leads. Be confident in the experience that you do have, and don't shy away when someone questions if you are worthy. United Nations Talk Shoot me your questions to Joe@SuperJoePardo.com Watch the entire Dreamers Podcast pre-show https://youtu.be/R5SK4CAzBBg Episode 238

User Experience designer and recovering alcoholic Victor Yocco speaks about habit formation–good and bad. You'll Learn:1. Victor's personal story and implications for forming effective habits and breaking ineffective ones2. The power of teaming up with others to achieve your ambitions3. How to use a design approach to construct and reach your career goalsAbout VictorVictor is a Philadelphia-based research director, author, and speaker. He received his PhD from The Ohio State University, where he studied communication and psychology. Victor regularly writes and speaks on the application of psychology to design and addressing the design and tech culture of promoting alcohol use. He has written for A List Apart, Smashing Magazine, UX Booth, User Experience Magazine (UXPA) and many more. He is the author of Design for the Mind, a book from Manning Publications on the application of principles of psychology to design.Items mentioned in the show:Victor's book, Design for the Mind – enter the discount code yoccopcycp for 39% off. Thanks Victor!Online publication A List ApartSmashing magazineOnline publication UX BoothUser Experience magazineDaniel Kahneman and Amos Tversky's study on Prospect TheoryOutliers by Malcolm GladwellThe Slack messaging appVictor's Twitter feedVictor's LinkedIn pageVictor's emailView transcript, show notes, and links at https://awesomeatyourjob.com/ep33See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

Based in Pittsburgh, Matt Griffin is a designer and founder of the web design consultancy Bearded. He's a speaker, writer, educator, and an avid advocate for collaboration in design. His writing has been published by net magazine and A List Apart, where he writes the regular column on “How We Work.” Matt is the director of the upcoming documentary film What Comes Next Is the Future, the definitive documentary about the web as told by the people who build it each day. The film premiers August 2016.

Dr. Leslie Jensen-Inman is a designer, speaker, author, educator, and co-founder of Center Center, a user experience design school based in Chattanooga, Tennessee. Leslie shares her research and thoughts on design, learning, leadership, and community through writing and speaking. Leslie is creative director and co-author of the book, InterACT with Web Standards: A Holistic Approach to Web Design. She writes articles for publications such as A List Apart, The Pastry Box, Ladies in Tech, and .net Magazine. She speaks at events such as Build, Converge, SXSWi, Madison+, Blend, UXCamp DC, In Control, Fronteers, A Web Afternoon, and Web Directions South.

Longtime web developer, lecturer, and web standards evangelist Aaron Gustafson and host Jeffrey Zeldman discuss the newly published update to Aaron's best-selling industry classic “love letter to the web,” Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd Edition (New Riders, 2015). Topics covered include: Aaron's superhero origin story as a creator of progressively enhanced websites and applications; "we're not building things we haven't built on the web before;" "creating opportunities for people outside your comfort zone;" development in the world of Node.js; "every interface is a conversation;" "visual design is an enhancement;" "interaction is an enhancement;" nerding out over early web terminal interfaces; Microsoft, Opera, and more. Save 35% off Aaron Gustafson's Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd Edition when you enter discount code AARON35 at checkout. Links for this episode:About Aaron GustafsonAdaptive Web Design Second Edition (“95% new material”)Read the first chapter free (PDF)First Edition, May 2011 (read the entire first edition free) Web Standards SherpaNotebook: Aaron's blogEngagements: Aaron's speaking page, using Quantity Queries"Quantity Queries for CSS" by Heydon Pickering in A List ApartA List Apart: articles by Aaron GustafsonEric Meyer's "CSS Design: Going to Print" in A List ApartWhatsAppBrought to you by: Braintree (To learn more, and for your first $50,000 in transactions fee-free, go to BraintreePayments.com/BigWebShow) DreamHost (Visit the link to sign up and make sure to use the code THEBIGWEBSHOW395 at checkout and you'll get top rated web hosting for just $3.95/month and a free domain name). Thinkful (Learn to build websites & apps in 3 months and get 20% off when you visit Thinkful.com/bigwebshow)

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

Offline access for applications is becoming more and more necessary for web development today due to increasing client usability demands. The HTML AppCache are a partial solution but is very sticky, often provides stale data and is not dynamic or adaptable. Developers can easily find themselves doing hacks with the deprecated Web SQL API, IndexedDB, & localStorage or a framework like Hood.ie to achieve a fully supported offline application.   Jake Archibald (@jaffathecake), Google software engineer, wrote an infamous article on A List Apart about the inadequacies of AppCache. This turned into the beginnings of ServiceWorker, an API for offline access that provides “scriptable primitives that make it possible for application developers to build URL-friendly, always-available applications in a sane and layered way.” ServiceWorkers allow developers to to make sites work faster and/or offline and also use network intercepting as a basis for other 'background' features such as push messaging and background sync Jake, along with Google Engineer, Alex Russell (@slightlylate) & Mozilla engineers Anne Van Kesteren (@annevk) & Ben Kelly (@wanderview) talk about ServiceWorker's current state and how we will use it in our applications. Resources The spec - https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html How to build with ServiceWorkers - https://github.com/slightlyoff/ServiceWorker/blob/master/explainer.md The Offline Cookbook - http://jakearchibald.com/2014/offline-cookbook/ ServiceWorker Cache Polyfill - https://github.com/coonsta/cache-polyfill ServiceWorker Github - https://github.com/slightlyoff/ServiceWorker The article that started it all - http://alistapart.com/article/application-cache-is-a-douchebag Offline First Organization - http://offlinefirst.org/ Potential Resource Implications -  https://hacks.mozilla.org/2014/12/mozilla-and-web-components/   Understanding ServiceWorker Cache in Firefox - http://blog.wanderview.com/blog/2014/12/08/implementing-the-serviceworker-cache-api-in-gecko/ Intro to Service Worker - http://www.html5rocks.com/en/tutorials/service-worker/introduction/ Using Service Workers - https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers Web Spec Framework - https://github.com/slightlyoff/web-spec-framework Brendan Eich Quote - https://annevankesteren.nl/2014/09/tc39-api-design The early state of ServiceWorker - http://devchat.tv/js-jabber/069-jsj-the-application-cache-with-jake-archibald Support in browsers - https://jakearchibald.github.io/isserviceworkerready/

Anna Debenham on Code For America, starting a web career at age 14, checking websites in game console browsers, producing 24 Ways, what comes after winning young developer of the year, and the delights of Spotted Dick and Victoria Sponge. Anna is the author of Front-end Style Guides, creator of the Game Console Browsers website for developers, co-producer of 24 Ways, technical editor for A List Apart, and was Netmag's Young Developer of the Year 2013.

Type nerds, unite! Nick Sherman (The Font Bureau, Webtype, Fonts In Use, A List Apart) and Jeffrey Zeldman geek out on responsive type, 21st century hinting, typefaces designed from scratch for onscreen reading at small sizes, things you still can't do on the web, EDID and other standards, type used in blaxploitation posters, punk rock, pizza, and more.

Ryan and Tina Essmaker are Jeffrey Zeldman's guests for Episode No. 91 of The Big Web Show ("everything web that matters"). Ryan is a designer and the co-founder of The Great Discontent. By day he works with Crush + Lovely as head of products, and manages No Little Plans, The Great Discontent's parent company. Tina is an illustrator, essayist, photographer, blogger, and the co-founder of The Great Discontent, an online journal of interviews focusing on creativity and risk, and No Little Plans, The Great Discontent's parent company. By day she manages community for Crush + Lovely and works as a freelance writer. This episode of The Big Web Show is sponsored by A List Apart, the design magazine for people who make websites.

Dan is an award-winning designer from Philadelphia, an enthralled husband and dad. He's the founder & Design Director at SuperFriendly, co-founder of Typedia, and co-host of The Businessology Show – a podcast about the business of design and the design of business. Dan was formerly the Design Director at Big Spaceship, Interactive Director at Happy Cog, and a technical editor for A List Apart. He writes about design and other issues on Twitter and danielmall.com.

Jeffrey Zeldman interviews Monkey Do studio co-founders Michael Pick and Tim Murtaugh, the design and development team behind the A List Apart and An Event Apart redesigns, HTML5 Reset, Edible City, and client projects including Scientific American, World Science Festival, and EconoMonitor. Mike, Tim, and Jeffrey discuss the A List Apart redesign, responsive images and type, CSS Zen Garden, organic design processes, the future of CMS systems, designing a food truck app, and more. Links for this episode:http://monkeydo.bizhttps://twitter.com/mikepickhttps://twitter.com/murtaughhttp://html5reset.orghttps://github.com/murtaugh/HTML5-Resethttp://alistapart.comhttp://aneventapart.comThis episode is sponsored by Shutterstock.com. Get 30% off any package with discount code “BIGWEBSHOW3.”

Matt is a designer and one of the founders of Bearded. He has a great love for letterpress printing, and is an advocate for collaboration in design, and has been published in A List Apart and .net magazine. Matt's one of the creators of Wood Type Revival, a successfully Kickstarter-funded project which seeks out lost historic wood type and converts it into digital fonts for modern designers.

Mat works at The Filament Group in Boston, a company that designs engaging sites and apps for mobile, tablet, and desktop platforms. He is a designer and a developer who occasionally works independently with big-time clients like The Boston Globe. Mat also regularly writes articles for the A List Apart blog. He is a member of the jQuery Mobile team, and also an active member of the open space community at movethewebforward. In addition, Mat chairs the Responsive Images Community Group.

Marissa Christina joins Jeffrey Zeldman and Dan Benjamin to discuss her path as a web designer diagnosed with a debilitating vestibular disorder, and her blog Abledis.com, documenting living with a hidden disability. Links for this episode:westciv - tools & resources for web professionalsDownload A Game of Thrones | George R. R. Martin | A Game of Thrones Audio Book UNABRIDGED | Audible Audiobooks | Audible Audio Edition |Audible.comDownload The Wonderful Wizard of Oz | L. Frank Baum | The Wonderful Wizard of Oz Audio Book UNABRIDGED | Audible Audiobooks | Audible Audio Edition |Audible.comA List ApartSponsored by Field Notes, Audible, and thoughtbot.

Mandy Brown joins Jeffrey Zeldman and Dan Benjamin to discuss the value of support, the future of type on the web, font choice on reader platforms, what print publishers can learn from web publishers, why you've got to write, and why the future belongs to editors. Links for this episode:this is a working libraryMandy Brown (aworkinglibrary) on TwitterTypekitA List ApartA Book Apart, WelcomeTypedia: A Shared Encyclopedia of TypefacesType rendering: review, and fonts that render well « The Typekit BlogSponsored by MailChimp.

Jeffrey Zeldman and Dan Benjamin are joined by Jason Santa Maria and discuss mitigating the isolation of working in your underwear by reaching out to the community, avenues for creativity, struggling with the line between good enough and perfection, focus, why speaking and teaching are important, and why sometimes the distraction of working with other people is worth it. Links for this episode:Jason Santa MariaJason Santa Maria (jasonsantamaria) on TwitterDribbble - Jason Santa MariaMighty, a Design StudioTypekitTypedia: A Shared Encyclopedia of TypefacesAIGA/NYA List ApartHappy CogWhat deux yeux have teux deux teuxday?Sponsored by An Event Apart.

We're mixing it up for today's episode of The Big Web Show. Instead of interviewing one or more amazing web innovators per our standard practice, Dan Benjamin and Jeffrey Zeldman interview each other. Links for this episode:HivelogicDan Benjamin (danbenjamin) on TwitterHappy CogHappy Cog Studios (happycog) on TwitterJeffrey Zeldman (zeldman) on TwitterA List ApartA List Apart (alistapart) on Twitter5 by 5 Studios (5by5studios) on TwitterA Book Apart, WelcomeA Book Apart (abookapart) on TwitterAn Event Apart: The Design Conference For People Who Make Web SitesAn Event Apart (aneventapart) on TwitterstopdesignDoug Bowman (stop) on TwitterJason Santa MariaJason Santa Maria (jasonsantamaria) on Twittermeyerweb.comEric A. Meyer (meyerweb) on TwitterAdactio: Jeremy KeithJeremy Keith (adactio) on Twitter