The Frontside Podcast

Balint Erdi: @baaz | balinterdi.com | Rock and Roll with Ember.js

Show Notes:

Resources:

Transcript:

CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 65. My name is Charles Lowell. I'm a developer here at The Frontside. With me, also from The Frontside is Elrick Ryan. Thank you for being with us, Elrick. I know this is your first podcast.

ELRICK: This is my first podcast. It's great to be here.

CHARLES: All right. Fantastic. Yes, we hired Elrick a little bit ago and it's been fantastic. I'm glad to get you on. With us today is a really awesome guest. His name is Balint Erdi. I actually like to tell a little bit of a story when I have an anecdote and I do have one about you that I think you might like, although you might not even remember it. But it was shortly after EmberConf. Last year you and I got on a pairing session remotely and I don't even remember what we were working on but I was struggling with this way to decorate objects without changing them, without touching them or mutating them in any way and you showed me this technique of actually decorating it by creating a new object with the old object as the prototype. Do you remember that?

BALINT: Yes. I totally knew. How could I forget?

CHARLES: Yeah. That one hot tip changed my life. It is one of the best techniques that I have discovered in the last five years of working with JavaScript. It really was great and I use it all the time.

BALINT: Wow. Amazing.

CHARLES: Thank you. I don't know if I ever said, "Thank you," but thank you, thank you, thank you.

BALINT: Yeah, no problem. I also learned a lot from this pairing session actually. I didn't know that my small contribution made such an impact. I'm glad to hear that.

CHARLES: Yeah, that was fantastic. We need to actually make that happen again. I don't know why we only did that once.

BALINT: Yeah, we should.

CHARLES: Anyway, we're here to talk about data loading, it’s something that is absolutely critical to building good frontend and building UI and yet, it's something that the users never really see. Sometimes, it feels like it's 90% of the problem.

BALINT: Exactly, yeah.

ELRICK: Yeah, that's so true.

CHARLES: We're going to talk about techniques that we use and you use and, in particular JSON API, what it is and what's so great about it. So, what is JSON API for folks who've never heard of it?

BALINT: JSON API is a standard way to build APIs. I think the specification has reached 1.0, I would say two years ago or three years ago. I remember it was in June, I'm not sure which year. It basically lays down everything that's usually consider when you build an API: how do fetch relationships, how to paginate data, how to sort, all of these things that I think developers tend to invent again and again.

I think probably the biggest advantage of JSON API is that it just declare a standard way to do that. It basically reduces the byte sharing going on at the start of the project. Well, not just at the start, later on too. In my talk at EmberConf, I coined a JSON API the conventional over configuration for APIs.

CHARLES: I see. Pagination is something that everybody does. Why need to byte share over the syntax, like the actual data from it?

BALINT: All of these things are things that everybody does. It's just that everybody does it differently. There's a lot of discussion going on which the best ways, for example when there's a team, at least every team that I was involved with had several discussions going on about what data formats to send data in and how to paginate and all these, I think details where it's more important to get to an agreement just to agree on something and move on than to get it perfectly, if at all there is a perfect way to do it.

CHARLES: I guess my question is if you have the standard way of doing of everything, what kind of tooling can you build, that can you kind of inherit for free? At what level, both from the low level and then up to the top level? When I say top level, I mean what the user is seeing.

BALINT: By low level, I guess you mean the actual libraries that implement JSON API in different frameworks, right?

CHARLES: Exactly. Are there now a lot of libraries out there so whatever I'm using, if I'm using JSON API, is it available in a lot of different ecosystems now?

BALINT: Yes. It definitely is. There is a full page on the JSONAPI.org, on the official JSON API page that just list all of the different libraries that are now implementing all these languages. I have experience with Rails, probably at Ruby too and there are three libraries and I think all of them are pretty good just for implementing JSON API.

The one I use is called JSON API resources and it's very telling. Well, it's a rather simple application but I basically didn't have to write a single line of code. I've only had to write very little code in the server to implement a JSON API specific feature. Most of the relationships could be implemented with just declaring JSON API resources and then the name of the resource in the Rails application. For all the other things, I really didn't have to do that much so in every time, it was just adding one or two lines or changing a configuration value, then it was just there.

CHARLES: Now, how do you choose then what relationship you want to load and which order? Is that controlled by JSON API?

BALINT: It's controlled by the frontend. It is a frontend application that's going to send these requests to the backend so that's where you should consciously think about what relationships you are fetching and how.

CHARLES: Right so part of the specification is a way of specifying which relationships you want to load. In my understanding, part of JSON API is an interface along with say, the user, "I want to load all of the posts that this user has made."

BALINT: Yes. JSON API indeed has a keyword called 'included', which you can implement on your backend which does this. If you specify 'include' and then the name of the relationship or relationships for several ones, the backend must comply with that request and also send back those related resources. That is called compound document in JSON API parlance.

ELRICK: Is that the reverse of what they doing in GraphQL because at GraphQL, I think you have to request the relationships you want on the frontend and then it kicks it off to the backend and it gives you the information back. Is it like JSON API that includes that same thing but in reverse?

BALINT: I'm not sure because I'm very familiar with GraphQL but all the things it does is that you are normally fetching a resource and then if you specify 'include' then you are telling the backend, "Please also include these related resources with a primary source."

CHARLES: I think it occupies a very similar concept that you want to have control on the frontend about which resources or what data gets fetched in addition.

ELRICK: Yeah, it sounds very similar.

CHARLES: Well, I'd love actually to do a comparison because I know there's a lot of overlap between GraphQL and this. Maybe we can get into that a little bit later. One of the things that you said back there is having this, gives you kind of fine-grain control over when and how you load your data because that always seems a pretty difficult problem to attack on your frontend because as you're rendering your application, you have to incrementally fetch little pieces of data here and there and make sure that it's already, at the time that you actually need to render something like a component and then it's got the right data at the right time.

It seems like it's this constant dance of whack-a-mole and like, "I'm loading too much here. It's taking too long," versus, "I've got too many loads happening. I've got 20 requests to run the single page." How can I back those up into a single thing? How do you go about thinking and designing that data loading strategy, as you're ready to render pages?

BALINT: That’s a really good question. I think the short answer is how you load data has to be part of the design process. You really have to spend time thinking about how you're doing that based on the needs of the UI. I think the way you need to render the UI will suggest the way to do data loading. Especially in Ember, I think do I really need ways to, for example block the page from rendering too early so anything that you want to render first, you can fetch in this non-blocking way into model hook of Ember. Then anything else, if you're okay with rendering later, you can fetch in other ways like to set up controller hook or from the templates or from controllers or whatever way but not in the model hook.

CHARLES: But if you are doing something outside of the model hook -- because this is something I feel like a pattern that comes up a lot -- and regardless of where you're operating, if you're using Ember, if you're using another framework, you have kind of this top level data loading. But then you have your nested components might need more data, how do you go about loading that data. I guess you have to think about that also. Upfront it's like, "I’ve got this component that might want to request more data," how do I actually design that and think about that of I've got this data that's going to come, who knows, maybe minutes after the initial route is rendered?

BALINT: That would be different but I think that you can apply the same principle. You can fetch some data in the model hook in this blocking way and pass it all it down to your component if you don't want to render the component before the page renderers or you can just even fetch it from the component while the component is rendered.

CHARLES: You're thinking maybe, in terms of streamlining, the rendering process so that you can begin rendering while your data is loading. Is that the use case?

BALINT: Yes. If you, for example fetch the data from your component, then it's just going to fetch the data as needed. You have the whole page load as render and then when the component is render and it fetches the data, then you're going to see other requests go out to the backend. The data comes back and then the component is going to be rerendered with the new data.

I think in most cases, that's totally fine but you might have a use case when you don't want to render the page before the component is all over the data that it needs. In that case, what you can do is once again, if the fetched data is needed in the model hook, it will just pass it all down to the component.

ELRICK: What are some of the pitfalls that you would run into by not thinking about your data loading strategy beforehand that you can pull out and explain?

BALINT: I think the classic one is what was known name in Rails and other framework is 'N + 1 problem' and it's when you fetch many related resources, then you might end up with doing end requests for a number of resources. In the case of Ember, you have for example a blog post as your model and then in your templates you write model.comments, then what's going to happen -- depending on actual library that you use on the backend but I ran into this myself -- is by default, if you are going to make those end requests. Ember solution is really, they just works. I mean, the default solution just works and you might not even run into this because you might not have the scenario. You might just have a few records. But if you have a great number of them, then it's going to be a bad experience.

ELRICK: So someone that just dealing with Ember and then they go and make a request and then see all these requests come back, that would be something that they would then have to turn around and asked or fix within the backend to say like, "Only give me a certain set of this."

BALINT: Yes, exactly.

ELRICK: Or is there something on the Ember side with Ember data that you can say, "Only fetch X amount."

BALINT: Right. I think both. I can speak about using Ember data and JSON API resources so what you can do to mitigate this case is to use links or cause relationship links instead of fetching the comments one by one, the backend can actually drive Ember data to fetch all the comments in one request from the link that it sends the frontend. You first ask for the blog post itself and then a JSON API compliant backend will send back the blog post resource but it's going to have a relationship link inside. An Ember data automatically records this so when it needs the comments for the blog post then it's going to fetch down from that provided URL. Actually, I haven't really talk about it in a lot of detail at EmberConf.

CHARLES: Yeah, I see. I'm going to go off on a little bit of a tangent because I feel like this is a pattern that's coming up more and more. To give a little bit of context, I feel like the way that our data loading strategies have evolved is we're used to the page loads, then we kind of analyze the URL, we decide what data needs to be loaded to render our components and then we pull that data from the server based on a decision and then we do our render. But it seems increasingly more prevalent than we are having a combination of both pulling the data from the server and having the server push data onto us. One is what are the strategies for dealing with that? Given kind of certainly, at least in the Ember world, routes aren't reactive. Then does JSON API actually help with that at all?

BALINT: Yeah, a good question. I don't think that JSON API specifies how [inaudible]. You are thinking about something like web sockets like pushing data from the server sockets. I don't think JSON API covers this summary.

CHARLES: Yeah. It definitely seems like beyond the scope but I'm wondering if there are any thoughts about general strategies, about how to handle this model state that sitting at the top of your render tree. In Ember for example, in your route and how do you handle the fact that the route requests data and how do you handle data coming in after the initial render?

BALINT: If you use Ember data, then you can push data coming in from a web socket, for example to the store. You probably do some massaging on the data that comes in and then you push it to the store and then depending on how you fetch the data, you might have a live collection. For example, if you do a store, find all notifications and then notification is coming in that is going to get displayed right away on your page because then your template is bound to a live collection. But not all of things in Ember data are live collections.

CHARLES: Okay, it's mostly library dependent but if you're using Ember data, then you just push those directly into the store, those live collections. It kind of like a real time query.

BALINT: Yeah, exactly. But what I'm saying is that not all Ember data query that you do are live collections. For example, relationships are probably not, depending on what method you use to fetch that data. You might have to do some additional footwork.

CHARLES: Okay. Now, getting back into the area in which JSON API really does shine at things that can really shave off a lot of time and consequently money from your work, let's talk about those a little bit. For example, you mentioned pagination. How is JSON API going to help me if I want to have paginated data? What are the scenarios on the client where I would need paginated data? Then maybe we can walk back from here's this user interaction that I need paginated data for and how is JSON API going to help me with that?

BALINT: Sure. I guess the typical scenario on the frontend is there is a long list of items and you don't want to overwhelm the user by showing them what it wants. You need to just show them page by page so JSON API recommends to use so it's agnostic about the exact paging strategy that you use. You can use the classic page-based approach or cursor-based one or start of pagination technique. It doesn't really force you to choose the way you want to do that.

It also mentions that, I think the way it frames it, you might want to use the page for your parameter. I think that the libraries, at least at JSON API resources for sure, you use that page parameter to send back paginated data. You have a page and a square brackets number and then page size. The request variables are page number and page size. Then the server knows that I just have to send back the second page if the page size is 25 and they just set that [inaudible].

CHARLES: Then if you're using a library on the server side, then you don't have to do any extra work.

BALINT: Yeah, exactly, depending on the library I guess. JSON API resources made this one really simple.

CHARLES: I see. Then in terms of library support on the client, I assume that there are libraries, like Ember data that automatically will support this so when you're creating these live queries, you can include information about the page.

BALINT: Yes. I'm very in to Ember so I'm not sure about the frameworks but I suppose that there are some ways that make this very easy for the developer in many of these frameworks like Angular and React.

CHARLES: Right. Something that has just bit me on the butt so many times is when I have paginated sorted data. Imagine you've got some infinite scrolling table or not infinite scrolling but you've got some a bunch of table rows that are maybe 300 of them or 3000 of them so you don't want to load them all at the same time. But at the same time, you've got complex sorting that's happening on each column. You might have seven layers of sort. You want to sort by name, followed by ID, followed by date. One of the biggest problems I've encountered is trying to reconcile and sort on the client versus trying to sort on the server. Are there any facilities to help you deal with that?

BALINT: Yes. I think the approach I usually take is if you do it on the server, then do it on the server. Do not mix the two things. In this case for example, if you are sorting and then you change just sort field, I would just send a request to the server to have the items returned according to the new sort criteria. I think that's the simplest approach because as you said, I've probably experienced things can get really messy, if you want to do that on the client.

CHARLES: Then you've got the third page but when you do the sort, the contents of the third page could be anything.

BALINT: Yeah, that's the other thing. I think if you change the sorting criteria, you'd probably want to go to the first page. I haven't thought through all of the scenarios but I think it's really rare that you want to stay on the fourth page while you change the sorting criteria to be created at descending. You probably want to see the first item the way it was created.

CHARLES: Someone should seriously write a book about sorting and pagination and loading these data sets because seriously, I feel there's this tribal knowledge of things that people have learned from screwing it up. There's not a written down way of this is how you build the data loading layer for an infinite dataset so that you can sort, you can paginate and here are the problems that you'll encounter.

BALINT: There's actually a book written by Adolfo Builes.

CHARLES: He wrote a book on Ember CLI, too, right?

BALINT: Exactly, Ember CLI 101. He’s the same guy and he wrote JSON API By Example. I have it on my mental to-do-list to buy that book. I'm not sure if it covers these exact scenarios but he must cover several in that book.

CHARLES: Well, I'll be sure to reach out from because certainly there are a couple of scenarios that have bit me too. The other one is where you have some collection that's paginated and sorted, then someone adds on the client side a thing to that collection. Say, you want to create a new row in that table, well then what do you do with that new row? chances are it's not going to be anywhere on the screen because who knows what the sort order is and the terms of the total sort, which is only the server knows and who knows what page it's going to be on? You get all these problems that compound and it would be great to have one place where people could reference them or have a little cookbook.

BALINT: Sure, absolutely. I think in that scenario, the simplest thing, which I think probably works best like 99% of the cases is again, just to reset the sorting and the pagination. If I create a new record, I really want to see that new record.

CHARLES: Yeah, maybe you put the new record up in a box up, at the top in a special new record place.

BALINT: Sure you can go fancy and do that. That would be a good solution too. But probably you can just reset the page number and show the first page with the new record.

CHARLES: Ah, yeah. I see.

BALINT: It's tricky. It's going to get more complicated than this.

CHARLES: You might have a problem where you don't want to lose that context to the records that you were looking at.

BALINT: That's right. Somebody should write the book in this. I know somebody who wrote a book

CHARLES: It could be you. You haven't written a book in over a year, right?

[Laughter]

BALINT: It's been two years already.

CHARLES: It's been two years.

BALINT: Exactly.

CHARLES: I'm never going to write a book again. I don't know. Do you think you might?

BALINT: I think I might. I actually have this urge.

CHARLES: If I recall correctly, you're one of the few people I've talked to who was like, "Yeah, you know, writing a book, it wasn't that bad. It was kind of an amazing experience." And literally, everyone else I talked to have been like, "Urgh!"

ELRICK: That's really interesting too because his book keeps up with the releases of Ember so that makes it even harder. That's surprising to hear that like, "Oh, it wasn't that bad."

BALINT: Exactly. Well, I kind of put off writing the second book for a while because if I just wrote a book, then I could just be done with it, I would be happy to start writing the second book. But if I have to maintain it for years, I don't have to do that but it's just so much extra work that I'd have to take this into consideration.

CHARLES: Yeah. Essentially, what you've done is you've rewritten the book. In terms of absolute content, given how much everything has changed, you probably flipped over the content of the book in the same way that people flip over the atoms in their body. I think there was something like you don't have a single atom in your body three years from now that you have today. It takes about three years and you have all the matters completely and totally exchanged. It's kind of like that.

BALINT: Yes, it's kind of like that. Well, I think maybe half of the book is still relatively as it was when I released it because since Ember 2 came out, Ember didn't change that much so in the 1.X series it did change a lot and I think my book originally came out when Ember was 1.10, I would say. There's a lot less work that require now to maintain that it was back then. But it had changed a lot for sure.

ELRICK: Yeah, I think I bought the book on its first release. It was 1.10. I guess you automatically get assigned to the GitHub repo so you just see a constant barrage of updates, updates, updates and I'm like, "Wow, Balint is really killing it in updating this book."

BALINT: Yeah.

CHARLES: It is a good book and everybody should go buy it. The other thing that I want to cover to, as long as we're talking about scenarios that come up again and again, we talked about pagination, we talked about sorting, what about things like search? Is there a uniform mechanism to help you out there?

BALINT: You can implement searches by using filters. It's a JSON API concept of using filters. You can pass a parameter called filter to your query and then a square bracket. You have the name of the field that you want to search and then just pass the value, the search term basically and then backend should return the items that matched according to some criteria. That’s the simple case.

CHARLES: It's a simple case but clearly, it's up to the backend to implement that API.

BALINT: Yes.

CHARLES: So I'm wondering what libraries are available if I'm doing something in Elixir or I'm doing something in Sinatra or I'm doing something using Express, how seamless is it because I feel like a lot of times you can run into problems where these leaky abstractions about the fact that one thing is a Mongo backend, then one is based on Postgres. Maybe that's a better example than a different server technology but more of sticking with a single server technology -- let's use Ruby -- but one is I'm using a Postgres backend and when I'm using, say MongoDB or some other key value store. In your experience, if you’ve seen this, how much does the backing store leak into the frontend? Is JSON API a good protection and the ecosystem around it from those leaks?

BALINT: Yeah, that's a good question. I was about the say that the backend needs to be the abstraction that's use you from having to know what kind of persistence layer you use. The frontend shouldn't care about -- or any client of that backend -- whether you use MongoDB or Postgres. That's a responsibility of the API. You can still send, in this case for example, a filter query. However, the backend translates this to database queries. That's his job. I think the answer to your question is that JSON API does protect you from having to know the intricate details of the database.

CHARLES: You might have some work to do but it's possible.

BALINT: Sure. You might have a lot of work to do on the backend but it's possible. But it's not just JSON API that protects you. Any kind of API should protect you from this kind of knowledge.

CHARLES: Right, unless you're using GraphQL.

BALINT: Could be. I don't know exactly how GraphQL works.

CHARLES: Yeah. I think there would be actually nice to read something from somebody who's got a lot of good experience with all of these, like different technologies to make a comparison. I feel kind of in the dark. Unfortunately, the problem with any technology, I feel like most of the comparisons out there, if you're going to compare, most people have a huge implicit bias for one tool and a little bit of experience with the other, maybe dangerous of like, "I don't definitely want to render opinions on my GraphQL and certainly not versus the API that I'm used to because I feel like I can't make a good comparison."

BALINT: Yeah, absolutely. That's a good one.

CHARLES: But it is something that I'm so intrigued because I feel like there's a lot of overlap there but who knows.

BALINT: Yeah.

ELRICK: They need that to do API like how they had to do MVC, they need to do API comparison.

CHARLES: Yeah. One thing we could do, we could implement JSON API over GraphQL and kind of just move your backend on to the frontend.

BALINT: I think you could but you just said that with GraphQL, you have to know the client on the frontend, like feels the database.

CHARLES: Right. You could technically have a JSON API on top of your GraphQL backend because I think the thing that kind of freaks me out -- this is a crazy idea that no one should ever do it but I hope someone does -- about GraphQL is being as old as I am, I saw so many projects ruined by the visual basic kind of mantra of just like, "Just query your database right inside your components," and that was literally the rope that hung ten thousand projects and just made people despise visual basic development because there was no shield and then literally every button was coupled to your database. But you could theoretically have the best of both worlds where you're sitting on an abstraction that's also on your client but just moving your query language from your server over to your client or something like that.

BALINT: Yes something like that could work, in theory.

CHARLES: In theory. Like I said, no one should ever do that unless they really want to.

BALINT: Yes.

CHARLES: Fantastic. The other thing I want to ask you is kind of what do you have cookin’. You got your book, you wrote but you keep updated, you recently have been evangelizing data loading patterns most recently at Ember Conf. What's next? What’s now? Or you're just kind of taking a break?

BALINT: I already have published book a mini-book about these data loading scenarios. Actually, I just cover the things I told them out at EmberConf then add some more but I might make this into a full-fledged book, providing I don't have to update it.

[Laughter]

CHARLES: I'm going to write this book --

BALINT: But just once.

CHARLES: -- But just once.

BALINT: Yeah, I still have to find a way of doing that.

CHARLES: All right. We will look for all of those things. One thing that just occurred to me is just how much of actually building UI and building frontend really is about thinking about the structure and flow of how you load your data and how much the user doesn't see that but how important that is to provide a good experience to that user. That's one of the things that sometimes we, as UI engineers don't like to think about but I think it is absolutely true and crucial and foundational. Thank you so much, Balint for coming by and talking with us about these important topics. We will see everybody next week with that. I will bid everybody to do. Good bye, Elrick. Good bye, Balint.

BALINT: Yeah, thank you very much for having me. Goodbye.

Ginger Whalen: @gingerwhalen

Show Notes:

Resources:

Transcript:

CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 64. My name is Charles Lowell. I'm a developer here at The Frontside. I'm here with Jeffrey Cherewaty. Hello, Jeffery.

JEFFREY: Hey, there.

CHARLES: With us today is someone also at The Frontside but not one of our developers. Her name is Ginger Whalen. Just to give you a little bit of backstory on her and why I'm so excited to have her on the podcast is we, about the middle of last year, began a search to bring someone on to help manage and grow and just have their eye on our business pipeline because that's something that's really, really critical, it turns out, to a software agency is making sure that we have clients. We put together a pretty extensive search plan and then we executed it and it was, I think about six months but in the end, we ended up hiring her.

The reason we did was because she had a very unique take on what we would typically deemed the sales process so we learned a lot about it and I wanted to have her on the show so that we could just kind of share with our, I would say, mostly skewed on the technical side audience about what a healthy sales process might look like. Welcome, Ginger. Thank you for coming.

GINGER: Thank you. My pleasure. It's so funny when people talk about sales and they say to me, "Oh, you're a sales person," I think that's so funny because I've never viewed people to be in sales and people not to be in sales. To me, everybody is in sales because all sales is to me is somebody just exploring somebody's problems with them and then when the time's right, you educate them and then you help them see the value of acting on some solution. Who doesn't do that? We all do that.

CHARLES: We all do that. We do it in our day-to-day when we're proposing and discussing and talking about technical solutions, the same principle may be applied in a different level.

GINGER: Yes, some people are just on the hook for it, that their professional goals are tied to that end game.

CHARLES: Yeah. One of the things that struck me as kind of setting you apart when we were doing the interview process is the way in which, I want to say the focus of building those relationships and kind of the focus on understanding and understanding who exactly potential customers are and trying to categorize them and tailor our message so that we can actually maybe help them. Maybe you could explain a little bit about that. What's the front half of that process looks like?

GINGER: That's kind of the bigger subject. I guess sales is the exchange, the educating and helping somebody solve a problem, get what they want to solve that problem. But if you're not speaking in their language and sometimes you hear the term 'knocked around personas' -- the persona you're talking to or the person you're talking to -- if you're not speaking in their language or addressing their pain, talking about their problems, it just so boring to them. It doesn't really seemed like it's going to solve their problem and you just don't hit the target right. You're probably not going make a sale in the end.

That’s what we talked about when we first start talking with Charles and The Frontside team. We talked about personas, who are you approaching, what are their pains -- their business pains, their pains with their engineering team? What do they come to the table with and what would they like you to help them solve? The subject today, we're going to get into this a little bit later about empathy and then is really what it's all about is that gift of really understanding somebody else's experiences, somebody else's problems, their emotions and how we use that in sales as we're going to talk about a little bit more today.

CHARLES: Yeah, I really like that because the drive there is to maybe not always shoot for a sale, to really try and understand like you said, someone's problems and just go out there and talk with interview, listen to a lot of different people and realized you're not going to be a good match for most of those people out there. If that's the case, not trying to view that as a potential opportunity that you want to just kind of force through but rather say, "How can I help this person even when it's not through my services and developing that and having this sales process?" because I think we tend to have a stereotype of what it is as being like I have a goal. When I want to interact with this person, what my agenda is actually to make a sale to them. It's clearly not like that. I think it varies from business to business but that's kind of the stereotype that I had in my head before this process began.

JEFFREY: It feels easier as an engineer to be able to say what I'm trying to do is solve your problem versus what I'm trying to do is a self-centered like, "I want to have your business." That's very different approach to the problem.

GINGER: That's so funny because I view it as exactly the same as what you guys do. You're solving problems, you know the end game is you're going to write this code to figure this out to do this thing and this thing is your end goal. That's the same thing I'm doing as I'm trying to fit my solution with this person but the means to get there, I just have to let it unfold.

Sometimes, it's really hard and sometimes it's really complicated and takes a lot of code and lot of trying and then trying something different, then that broke and then trying something different again. In sales, it's the same thing. Especially at this level, when you're with a consultancy, you have multiple buyers or multiple personas out there. You're selling up into an organization that can get pretty complex and you can have some fits and starts, just like you do when you guys are coding and trying to solve a problem.

CHARLES: Now these personas, this was actually something that was really interesting to me, the kind of introduction is this as you understand the problems and pain points, you're trying to collect them into related that this person has these general challenges and problems that need to be solved. How do you go about developing those personas? What is a persona and how do you go about developing them?

GINGER: First, you have to know who your decision maker is in an organization. From that, you develop your different personas. Now, some of these personas are the absolute decision maker at the end so the guys can assign. Then some of those personas are influencers throughout an organization. For example, in this field, we talk often to a lead developer. We talk to VP Engineering. We talk to CTOs. We talk to presidents and CEOs of organizations. They probably have different organizational goals, different things they're on the hook for.

They have a common vision, absolutely that they're all working toward so maybe a business growth goal that they're working towards. But the VP Engineering might care more about the cohesiveness and the development of his team. He’s going to be really looking for an engineering team that fits well with his team. He wants to make sure that their productivity doesn't go down. He wants to make sure that this team merges well with his so he's thinking about lowering his risk through this experience, keeping everything smooth.

Where somebody at a different level, a CEO is maybe looking at something a little bit different. Are we going to hit this deadline so we can get this product out, so we can get our first customer, so we can get some revenue in? Maybe he's just looking at bottom line numbers. If they come to the table and they have all these different problems or different pains, you really have to speak to each one of them about their pain and make sure you're addressing that. That takes some empathy. Not sympathy, not saying, "Oh, my gosh. I feel so sorry for you having all these problems." That's sympathy. That's pity.

But empathy is not about telling your story, "Oh, yeah. That happened to me." No. It's about understanding their story. It really does take some listening in the beginning to develop your personas and to really get, not coming to the table and saying, "I think this is what his problem should be because he's this guy, this level, in this organization," but really listening to them and letting them tell you what their concerns might be. Don’t be afraid to ask for those because that is how you develop those personas.

CHARLES: Right. You really just have to walk in a lot of different shoes and then write down those stories. That's what a persona is, it's writing down the narrative based on trying to discover people's actual experiences.

GINGER: In the old days, they say personas are about demographics like this guy is about this age, eats this for breakfast and lives here and has this sort of family life. It's a lot more developed than that now and it really again focuses on their pain because you're the consultant in there. That's what they want. They want somebody that's going to be able to educate them on their services or something in the industry, teach them something about their business would be great. But what they're really looking for is someone to help them solve these problems, "Help me solve these problems. Can you do that?" and I would choose that person to work with if they can help me solve my problems.

JEFFREY: So much of this process feels like it's a lot of listening. It's a lot of deducing what the problems are based on what you're being told. At what point in the process do we present a solution?

GINGER: Yeah, a good question. Just like the timing of a joke. That's really important: the pauses and when to do what in the joke or just the flat. During the process, when you're gathering information, you're also qualifying them. As you're asking these questions and getting them to reveal their problems and pains, you have some questions. You really need to get answer to. This isn't just, "Let's go have coffee together and talk about your pains." It's really you're qualifying them. You have some strict qualifying questions that you know about an ideal client for your company.

Some of those qualifiers might be how many employees do they have, what size company are they, what stage of growth are they in? Are they hypergrowth? Are they scaling? Are they a startup? Are they in a certain silo of business? Do you do especially well in education or energy? Then triggers: what's going on with their business? Did they have a lot of recent personnel changes? Is that a trigger that usually helps you segment your ideal client profile? They just have an acquisition. Is that a good trigger or signal that they're qualified prospects for you?

While you're asking these questions and again, identifying your personas going through their pains, you're also qualifying them. I'd say when do you go to the part where you're selling -- Charles has been on sales calls with me and he's probably already noticed -- that you're always selling the value of your organization. You're always selling but as far as giving them a solution to their problem, you wait for that. You don't give that away, right away and you can miss your chance or miss the punchline if you give that away too soon.

I'd say, once you truly understand their problem and then you get agreement from them that this is a problem, this is really important to solve and there's some urgency tied to that, when you have those things, then you can begin your presentation and show them the solution to that problem. But there's two parts: one is identifying the problem, two really find out that they agree. Play it back to them that this is a problem, how does it affect them and if there's the urgency tied to it. That's what you need to know before you propose a solution, I'd say.

JEFFREY: It's interesting that you mentioned how much empathetic sales process also requires introspection and besides understanding the customer's pain points and what problems they need to solve, you also have to recognize what problems we are able to solve and what problems we enjoy solving and that I think is counterintuitive that empathy requires introspection.

GINGER: I agree. You have to intellectually and emotionally identify with somebody and to the point where you can really experience what their attitude or their emotion or their feelings is. That's definitely an introspective thing. Yeah, you're right. Not the typical old school salesperson that just blabbering all over the place, being an extrovert telling their story. It really is more of an introspective. I'll even say introvert way of selling and that can be very powerful.

CHARLES: As you do that, listening and do that introspection and then develop this understanding of your clientele via these personas, once these personas are developed, how do you integrate them back into the business development process?

GINGER: That's a good test to say, "Can I really put myself in this person's shoes? Do I understand them? Do I have a better bond with them now because there's a mutual respect because we understand each other's experiences and thoughts and attitudes, pains and problems about something? Can I put myself in this person's shoes?"

CHARLES: You spend time listening and talking and introspecting and developing these personas of your clientele so then how do you actually, with that information in hand, use that to build your business development process? Now that you have this information, how do you actually leverage it on a macroscopic scale? Like I'm kind of out there in the world now, I've got these personas in my tool box, how do I go out there and interact with people based on that?

GINGER: I view that as an overlay over a sales process. That's the umbrella over the whole sales process. In a sales process, we do our first calls or connect calls or exploratory calls, again where we're learning about the company and their products, getting to know our personas. Then as you understand that persona, when you get into their goals and their plans and their challenges, when you're in the discovery part of your sales process, that's the part where you can transfer those points of pain and their challenges into your solutions.

Again, that's just a part of the conversation where you're speaking about value of the company, you're letting them know you understand their pains. When you get to the presentation, this isn't really explicit. It's not explicit in saying, "I know this is a pain. This is a problem you have," you turn it on its head and you take those challenges that they've told you about and weave those into your solutions. It's kind of where the rubber hits the road there because if your solutions don't solve their problem, it's absolutely where you're going to figure that out when you're presenting or when you get ready for that presentation. Would it help if we talked about, maybe one of those personas and wove that through the sales process?

CHARLES: Yeah, I think that's a good idea.

GINGER: Okay, a popular one with our type of business -- the VP Engineering. The VP Engineering, when we're talking to him, we're really trying to understand what he values, what's important to him in his work, what problems need to get solved. This person is really caring about quality, the quality of the work and the value that they're getting for their money. We talked about their team developing, learning as they work with us.

If that's important, we're probably going to really stress the quality of our service. How do we do that? We’re going to talk about the way we code, the way we test, the way build software. We're going to give them supporting evidence and case studies of how this is played out. We're going to talk about the value in this. We're going to talk about, maybe how we've reduce some time, for example [inaudible]. We've done that recently with a client where he's getting better value for his money because we're talking about his [inaudible] in reducing some of the time to build.

If we're talking about the development of his team, that something he's really concerned about. Is my team going to continue learning? Maybe we can present a story or a case study about a team that when we arrived, it looked this way and when we left, it looked this way. They had these additional skills... I don't know... Maybe you can jump in here but there's a client we worked in where their skills were totally transformed with us pair programming or working alongside them. Something like that are really important to VP Engineering.

CHARLES: Yeah. One of the things that this process has taught me and made me see and try to cast for wherever I can find it is actually trying to really quantify and measure that value. I know that's really hard because what we do is development. That's a really long process. If the product you're developing is successful, that thing that you put in there is worth a lot of money. If, 'thanks,' then it's worth nothing at all and the thing that you did was negative value because it was just sunk cost.

Those are two huge extremes and it feels like how do you get a little bit more fine grained in that and say, "Here's this activity that we're proposing and it's going to save this much money." You hear a lot of this people saying that you should try and do this this but how do you actually go about it? One of the things that kind of working in this way has taught me is really to try and wherever possible, it's not always possible but attach monetary value to the tradeoffs that you're proposing and the solutions like saying, "What is the impact of the work that we're going to be proposing?"

"We think it will save you $30,000." When someone actually takes a look at that and says, "That is a lot of money." That is, "We think that this could save you 50 developer hours per month." They say, "That is a lot of time," which again equates into a lot of money.

GINGER: That would be huge. I'm sure that would make him smile.

CHARLES: Right, exactly. You always hear that but it's trying to be more deliberate about it and really you have to think a lot about it to try and get to that level.

GINGER: Yeah and you just help me thinking about it all the way to the bottom line like that is terrific because in this situation, a VP Engineering, that person might have to sell it up the organization and maybe he has to sell it to the CEO and maybe the CEO is not going to spend as much time with us, may not even meet us directly. Those bottom line numbers might be really important for this persona to internally sell to the person that's actually going to give the nod and about their concern about we're going to get it right the first time, how do we help them get comfortable with that? That’s one of those risk issues that a VP Engineering might have.

Knowing these thing about your persona, knowing the pain that your persona has, all these things can be woven into your presentation. This is where, again the empathy comes in because you are speaking to their pains, their problems. This is an emotional sale. I don't care how technical something is, it is always in the end is going to be an emotional decision. It really is. Who's that author we're talking about that? Daniel Kahneman? His book out there: Thinking, Fast and Slow.

He did this study where he analyzed super, super wicked, smart people and then the rest of us, smart people but normal people. He gave them different decision making challenges and they watched the brain patterns. In the end, the part of the brain that lit up was the emotional part lit up and not the rational side. Even though they may have weighed all the evidence and maybe had a much more complex rational decision making process with their data, in the end, the part of the brain that lit up was emotional side. No matter who it was.

CHARLES: Yeah.

GINGER: Good to know, right?

CHARLES: It’s an adaptation that our brains work so that we actually think that we're acting rationally so we fool ourselves into that. But most of the time, people are making decision with their guts.

GINGER: That's how smart we are. We fool ourselves that way.

CHARLES: It's the ultimate trick. I'm curious. When you have this process in place, you're developing, leaning on these personas, weaving them in to your solutions and the story that you going to be presenting to your clients, how do you iterate on that? Just like we iterate on software, how do you make those incremental improvements and take what you're learning and then feed that back into the rest of the process?

GINGER: First, I'd like to answer that on a human level. I think the way we all learn this is we just practice it. As we put ourselves in another person's shoes, here's the part about it is when we're really dialed into empathy, we're dialed into that feeling of that emotion that somebody has, we're sharing in that feeling. To do that effectively and even when you're presenting a solution to your persona sale situation, talking to your husband or wife, talking to your daughter, words matter. You're really do have to choose wisely and your tone of voice matters. If you're in person with them, your body language and the volume you're using. Those are some of the things that, I think will help when you're presenting or really in any situation to express that you're with them and you're with among the emotion.

Let's say that it's something you have an experienced, this VP Engineering, maybe he just had a huge failure. They did not get it right the first time. Their software broke. The money once spend on it proving that it was great, he had to spend on fixing it and starting over. Maybe that never happened to you, hopefully it hasn't but you feel the heaviness of it and you know sadness.

He’s sad, he's desperate, he's scared, he's going to lose his job, you've had those emotions. That's what you can join him in that emotion. Not pity, you poor thing. More like, "Oh, that sounds really tough. Wow, that doesn't sound like fun." That's empathy so you're there with them and weaving that into your presentation, again not just blowing it off, "Let's not have that happen again because it won't happen that way with us. Here’s our solution." That is blowing your chance to have some empathy and sit with them in that emotion for a bit before you get onto your solution. That would be one way to weave it into the presentation.

But that takes something for him to share something like that with you too because he knows you're going to counter it and say, "That's not us," but does he know you're going to share in that emotion? Like, "Hey, that didn't sound like fun. Wow. Heavy."

CHARLES: Yeah. I'm curious and this is maybe a little bit of a curve ball for you but as you come into, every business is unique. I think doing UI consulting is one unique business out of many. What has been the biggest challenge of coming into this space and trying to develop a clientele inside of it?

GINGER: The trick for me since I don't have a heavy technical background is to get away from the technical conversations. Since that's not my strength, I can bring in you guys, bring in a team when it's right, when that person is qualified. But the challenge with me is to find the business people that really want to talk about, "We had this great idea but we don't have enough of bandwidth to execute on it." I can get the idea sold internally and it was just too complicated for us to achieve.

I can get those conversations going where really, we're talking about pains, we're talking about business problems that you can approach in any business you go into. It doesn't matter what the end game is and what we're selling. It really doesn't. Everybody has these business problems. To get people to talk about these business problems is the key to make those context to get them to open up about those business problems, business pains then you can qualify and see if it's a fit for your solution.

The challenge is to initiate those conversations with people because people do want to get technical quickly and to back them up and to talk about the business first because in the end, it probably does have to get approved by somebody that really is thinking about the business pains and business problems, maybe differently than this person's thinking about it so you want to do the work in the beginning to let all the surface before getting into the technical stuff. That's been always a challenge, whether it's web design development, marketing technology or an engineering UI company like us.

CHARLES: Yeah, it's always a challenge. I think you said this at the very beginning of the podcast is you need to be speaking the language of the person that you're speaking with. It seemed so obvious but the reality is though, everybody might be speaking English or one of several human languages within each one of those human languages is literally a million different actual languages, which is carrying on the context of what those people experience in their daily lives. Sounds like what I'm hearing is that there's a specific language within this business and part of it is learning to speak parts of that language, then also be like, "I need an interpreter. I need to bring in someone to speak to this person in their language."

On the flipside, I think it's also great too. I'm not a native speaker of some of these higher level concepts and I think that our strength here is in speaking that strong technical language that other technical people can bond with immediately but when you start backing up and just talking about those higher level business concerns, it's really great also to have someone who speaks that natively. Also, that language of even higher than that of, "Let's understand each other's problems here," which is something that you're very fluent in. It is interesting to see that there really is many, many different languages within one language.

JEFFREY: I think even within the technical conversations, there are multiple languages. There are different levels of, I don't want to say understanding but different levels of comfort and familiarity with different technologies, with different stacks. A lot of the conversations we have with companies that ours is comfortable in the stack that we're comfortable in and we're presenting that to them and that's where they're coming to us in the first place is because we have that expertise and we have to translate it into, I think that they understand and that fits their needs.

GINGER: And that's something, I think you guys are really good at. I don't know if you're giving yourself enough credit there but I think you do ask really good questions about, "Tell me about the experience you want to build? What type of goals are attached to this project?" You guys asked about timeline. That’s a goal when you get launched by then. You guys asked what would you say the strengths to your team are. I've heard these questions when you're talking about requirements so you can start to assess, how complex, how much we're connected, pair program with them, help them. I think you guys do ask about goals and plans and challenges. It’s just kind of packaged up a different way.

CHARLES: Yeah, part of that is just having borne the battle scars of not asking those questions upfront, rather than gravitating through intuition.

GINGER: I think we all unfortunately or fortunately learned that way, right? "Don’t step in the puddle. Don’t step in the puddle. Oh! Did it again."

[Laughter]

CHARLES: Is there any way to learn that doesn't involve stepping in the puddle or stepping on the tack or falling out of your chair?

GINGER: I guess, if you're a baby and you don't know anything yet, you're maybe 50/50. You’ll get some of them right.

CHARLES: Yeah, it is funny. But just a brief diversion, I just remember there was a period in her life where my daughter would just randomly fall out of chair. It was out of nowhere. It wasn't like she was sitting precariously or whatever. She would just fall out. It happened a lot and I was like, "Wow, sitting in a chair is a learned skill." Anyway, it just made me think about that is that there was actually this pain-based learning process there.

GINGER: I wonder what the response was. Did the room laugh? Did the room say, "Oh, let me help you?" Maybe she was ahead of the game.

[Laughter]

CHARLES: A lot of times it involved tears, which made the laughing worse. I mean, you can't help but laugh. You can also hide it.

GINGER: Yeah. Maybe we do need to fall a few times to learn stuff.

CHARLES: Ginger, if you could summarize what your business development process looks like in a few sentences before we head out.

GINGER: I would say, take your time when you're talking to new people. Get to know them. Get to know who the person is. Get to know what their pains are before you tell them how you can help them. On the empathy side of it, I think the key to empathy is really to remember that it's really not about telling your story: matching them at every step, it's really about understanding their story.

CHARLES: All right. I really like that and I really like the process that you're building here. There you have it folks. With that, I'm Charles Lowell from The Frontside. I hope you enjoyed this episode. Thank you, Jeffrey. Thank you, Ginger and we will see you all next week.

Saron Yitbarek: @saronyitbarek | CodeNewbie | Codeland Conference

Show Notes:

Resources:

Transcript:

JEFFREY: Hello everyone. This is Episode 63 of The Frontside Podcast. I'm Jeffrey Cherewaty, developer here at The Frontside. With me is Robert De Luca, also a developer at The Frontside.

ROBERT: Hello, hello.

JEFFREY: Our guest today is Saron Yitbarek. She's the founder of CodeNewbies and host of The CodeNewbies Podcast. Hi, Saron.

SARON: Hey, how is it going?

JEFFREY: Great.

ROBERT: Pretty good.

JEFFREY: You have a big event coming up, the Codeland Conference. Why don't you tell us a little bit about what's going on there?

SARON: Yeah, I'm so excited for Codeland. It is our first CodeNewbie conference. I've done a good amount of speaking at different tech conferences all over the world for a few years now. Ever since the first one I went to, I thought, "We really need one for junior people, for folks who are just getting started," so I kept a running list of everything I hate about conferences and the things that I like about conferences. This is my chance to put it all to the test.

It’s a two-day conference, single-track and the idea is really to get people excited about all the things they can do with code, especially for our community. The two types of jobs we generally hear about are working in a really, really small startup or working in a really big tech company like a Microsoft or a Google. But we don't hear about working at the hospital or working at the library or the many nonprofits who need technical help. The idea is to bring in people from all different backgrounds, walks of life, solving different problems and showing how code can be a really, really great tool for that

JEFFREY: What are some of the things from previous conferences that you really like that you're bringing in Codeland?

SARON: I like that you started positive. That's a good start.

JEFFREY: We'll go for negative later.

SARON: Yeah. [Laughs] Save the best for last. The stuff that I really like about conferences is the community part. It's being able to see a bunch of Twitter avatars come to life for the first time and being able to sit and talk. I feel like conferences are the only place where I can network without feeling gross and without feeling like I'm networking. I feel like I'm genuinely having real relationships and conversations. I think it's because we are going through this experience together and I can say, "Oh, did you hear that talk on this and that? It was so cool." It's a very organic way to start a relationship. That's probably one of my favorite things about conferences.

ROBERT: There's a lot of ability in there for small talk about anything because there's so much going on. You could pick anything that you want and you're all experiencing the same thing and you're all kind of vulnerable. I love conferences for that reason.

SARON: Yes, exactly and a lot of times, you're in a new city for the first time, you're staying in the same hotel, you're eating the same food. There's so many created and forced points of connection there for you so you can pick anything and start a conversation.

ROBERT: Yeah, I really like that. I'm looking at the website right now and I see inspiring talks and it doesn't look like they're all exactly technology specific so I like to see the city life and health. That's super interesting. I want to hear a little bit more about that.

SARON: Sure. I wanted to pick topics that are generally not covered as much in tech. Also, I didn't want to start from the technology. I think that a lot of people our community are very excited about the possibilities of tech and what they can do with it. We hear a lot of stories of people who say, "You know, I see this problem in my neighborhood. I see this problem in my community. I see this problem at work and I think that code is a really great way to solve it and to put together these solutions that I have in my head."

The way that we're working -- and that's another thing -- you are working very, very closely with all of our speakers and we're starting from the problem space. We're starting from the users and then we end up in a place where the technology becomes the solution. I think that when you start at that more common, human, empathetic element, I think you are much more likely to bring people in, who may not feel as comfortable with the tech because the way we've kind of organized and thought through stuff is focusing on the problems that all humans and all of us can relate to and then saying, "One way we can solve that and address that is through JavaScript or leaf letter," whatever that tool is.

ROBERT: That sounds really cool. Is there going to be conference talks that are centered around like how to have proper work-life balance, for example to filling to that health or how I've configured my editor to help with... I don't know, like ergonomics for my hand because I was getting carpal tunnel on my left hand because I was using control too much, that kind of stuff. That sounds really cool.

SARON: Yeah, that's actually a really good idea. That would make a really great talk but that's what Day 2 is for. The one thing that I've seen a lot in my own conference experience is I'll watch a talk, I'll listen to a talk and it'll be so inspiring and exciting. But then I go home and it's over and I'm back to my daily grind and all of that energy and positivity just kind of goes away.

What we wanted to do was have that first day be focused on all these ideas and projects and the second day transition into what do we do about them. We have a block of workshops from things like crafting your portfolio, to doing really well on a technical interview so really getting your hands dirty and trying out some of those skills. Then we have handouts for people who come in and talk about how they contribute to open source.

We do have one actually on work-life balance and learning to code and how you do that so making sure that we leave people with really practical advice and action items and next steps so they feel empowered to go out and be awesome developers.

ROBERT: This is awesome. The conference is kind of structured almost like a workshop in a way to where like Day 1, you're going to come in and hear a bunch of things that are going to get you all riled up and inspired and then Day 2, it's like, "This is how we go and implement that."

SARON: Yeah. I want to credit Duane O'Brien from PayPal who forced me to think very, very hard about the conference experience. When I first pitched him on this I said, "Hey, I want to do a conference for CodeNewbies," and I have kind of a disconnected list of topics that I wanted to talk about and do address and he said, "You really need to sit down and to think through what is the UX or the experience," like what's the user story.

I go to CodeNewbie as a new developer so that I can structure it so it feels like one really cohesive experience. I sat down for many hours and really thought through, "How do I want people to feel? Where do I want them to get excited, to get to work, to be interactive and really participate?" Putting a lot of time into that has really shaped this conference.

ROBERT: That is really cool. To be clear this conference is happening in April.

SARON: Yep. April 21 and 22 in New York City.

ROBERT: Awesome. I think this is really cool. Conferences are awesome but when it was my first conference ever, I just felt overwhelmed because you walk past the cliques of people -- I don't want to say cliques but you see the groups of people that have been there and done it and you're like, "How do I break into that?" If the conference is kind of filled with everybody like that, giving your first conference talk could be a lot easier, just like breaking into the community and talking to people could be a lot easier so I think this whole idea of running a conference for newbies is A+, honestly.

SARON: Thank you.

ROBERT: I wish this was around whenever I was within the very beginnings of my career. That's really cool. Is there anything, anybody on the outside can do to get involved and help like volunteer?

SARON: We have a bunch of volunteer’s spots to help out at the day of the conference. I'm really excited because a lot of people who've stepped up are people who aren't necessarily the right attendees. There are folks who have years of experience who just want to wait to join in and do something and help out. We have volunteer spots and I'm happy to include that in the show notes. I can send a link to that.

Then we also have a section during our workshop. We have like an optional community coding session where if you don't want to do any specific workshops, you can just bring your laptop and just socialize and code and work on your own stuff. If anyone is interested in the New York City area in participating or just being like a floating, technical mentor of sorts, those are the two ways to get involve.

ROBERT: That's really cool.

JEFFREY: New Yorkers, get on that.

ROBERT: One of the things that I hear you like to talk about and it kind of fits in perfectly with this is this Impostor Syndrome. I think this'll really help with Impostor Syndrome. One of the foundational goals for this is to help people come to grips with that and deal with it better, I guess or peel the onion back on what Impostor Syndrome is.

JEFFREY: Let's start there, let's start with what is Impostor Syndrome. Why don't you give your best definition of it?

SARON: Sure. I was really excited the very first time I heard about Impostor Syndrome, I think it was maybe four or five years ago and I said, "Oh, my God. That explains so much of my life," and when I really dug into it though, it was slightly different than the way that I initially understood it. The official academic definition of Impostor Syndrome is a way to describe the phenomenon where I have a lot of accomplishments, I'm ten years into my career, I have all these accolades, I'm the CTO senior or whatever of this and that, and even though I have all these very tangible, very real accomplishments and proof of how awesome I am, I have trouble internalizing that.

I can't look at that and go, "Oh, I am awesome." I look at that and go, "Ah, that's cute but I'm still not quite there yet." I think that in our community, when we talk about Impostor Syndrome, that's not really what we mean. I think we are describing what happens to everyone when they're learning something for the first time where they say, "Oh, I'm not getting this as fast as I think I should. I know a little bit but I won't know nearly enough to belong." It's really the sense of belonging that we have classified as Impostor Syndrome.

We actually had a guest, Alicia Liu on our podcast, I think it was about a year ago, talk about it and it was interesting because the first time that she blogged about it a few years ago, it went viral. Everyone’s like, "Yeah, it's totally how I feel," and then she wrote another blog post a couple years later that said, "No, no, no, everybody. That's not what Impostor Syndrome is. You're not impostor. You're actually just a beginner, you're just new, you feel like you don't know what you're doing because you probably don't, which is fine." It's totally fine to not know what you're doing. But the definition of Impostor Syndrome for me has definitely shifted a little bit over the years.

ROBERT: It's interesting that the textbook definition and what we kind of experience in the industry are at odds, in a way because the textbook words like you have this well-accomplished person that has done a lot and they don't feel like they're good enough for what they're doing. Then what we have is just like, everybody in the programming community is trying to fit in and they're always trying to learn new things and always feeling like they're not getting it fast enough. I think that's an industry-wide problem.

JEFFREY: I kind of always feel like a beginner because everything's changing in our industry so fast, all the time so there's always this disconnect between, "Well, I may have done some things and I may have accomplished some things along the way but I'm still beginner whatever this new tech is," Actually, everyone else is too. It's nice to be reminded of the fact that to be around other engineers who are experiencing that too that we're all in this together and we're all new at this. Nobody is quite expert level at this particular tech stack or this particular way of thinking it. We're all figuring it out as a community.

SARON: Yeah. One of my favorite talks that Scott Hanselman does is this really awesome talk about a little bit about his background in JavaScript and the evolution of JavaScript frameworks and he has this whole section where he goes through a list of this really impressive resume and all the stuff that he knows how to do and he deeply understands. But at the end of it he goes, "All of that is completely irrelevant because of Heroku."

[Laughter]

SARON: None of that matters.

ROBERT: "Now, I need to go learn something else."

SARON: Yeah, exactly. For me sitting in the audience I was like, "Yes! Heroku," because I'm thinking, "If that's how this guy feels, he's been doing it for so much longer than I have, I have a chance at this."

ROBERT: I feel like I send the 'I don't know what I'm doing dog' meme to someone, at least once a week. At least.

[Laughter]

ROBERT: I feel this often. I think it can be interpreted to the world is changing so much. But I think it's a little different for people that are experienced in the industry versus people that feel who are brand new because, I think when you're brand new, it feels so new and I don't know... uninviting maybe for the Impostor Syndrome? Whereas you get older -- not older -- you get more experience and you become one with the Impostor Syndrome like somebody asked you to do something that you don't know and you're like, "Urgh! Yeah, sure. I'll do it. I'll figure it out somehow," and then go on your way but you still feel that feeling.

But when you're a newbie, it's overwhelming almost. Do you know any tactics that kind of help that? I actually have no clue besides like pairing and trying to bring this new person into the programming world and telling them like, "This is kind of how it is."

SARON: I think that community is a great way to solve that. When I first learned to code, I taught myself for a few months. I did all the free and relatively cheap online resources and it was so frustrating because it was my first time being in a world where I was in a semi-permanent state of failure until something finally worked and then I got to celebrate that for two seconds. Then we moved on to the next feature, the next bug, the next whatever.

Being in this cycle, this vicious cycle of constant failure and having so little time spent, actually enjoying the wins was so different. It was really hard not to internalize that. Especially in my world where my family has no idea what coding is. They still don't really get what I do. I said, "It has something to do with computers and podcasting." My mom is actually going to come up for Codeland and I'm so excited because she can finally see what it is that I'm doing all day.

ROBERT: That is awesome.

SARON: Yeah. She texted me and she's like, "Yeah, let's bring your family and your friends and your dad can come," and I'm like, "Mom, that's not what this is."

[Laughter]

SARON: But yeah, your family doesn't really get what you're doing, your friends. If you're not coming from the tech world, if you're transitioning, they have no idea what you're doing so it's super, super lonely and it's really hard to explain. When I transitioned from that into enrolling in a boot camp and doing that for three months, all of a sudden, I had 40, 45 people who were with me every single day for eight to twelve hours at times, who knew exactly what I was going through and who understood everything that sucked about it and everything that was awesome about it.

Just knowing that it wasn't me -- I was not the problem, the code was the problem and the journey is the problem -- just changed everything and that's really why I started CodeNewbie to say coding boot camps can be an awesome experience but for a lot of people, they're not accessible. It's three months at least without a job, it's between $12,000 and $17,000 and because there's not always a credit programs, you can't necessarily get like a student loan the way you can for a college.

For a lot of reasons, there are really high barriers. I wanted to make it a little bit easier for people to find a support system who are going on that journey. That's what really started CodeNewbie and we did that through the CodeNewbie Twitter chats that we do every Wednesday at 9PM Eastern Time and we do that every single week for an hour, really as an excuse to say, "We're all going to hang out at this place." As long as you have an internet connection, you can join and find friends and find people who know exactly where you're going through and that's really been, for me a huge, huge help.

JEFFREY: What kinds of positive experiences and stories have come out of that community? Have you seen actual great change happened through that?

SARON: Yeah, definitely. We've had people get internships, we've had people get jobs, we've had people just find out that other people in their neighborhood are also learning to code. I've seen a lot of like, "I see you're in Portland. I'm in Portland too. Oh, my God." A lot of that and then they meet up in person and they pair. We've seen a lot of mentors and mentees pair up through CodeNewbie so it's just been a really great jumping off point for a lot of folks to find those connections and opportunities that run with it.

JEFFREY: Through Codeland and through CodeNewbie, one of the goals is to connect junior engineers into their community. What kinds of roles and ways to connect do junior engineers have through the opportunities like this?

SARON: A lot of folks are finding internships and apprenticeships and some junior roles. I think what I'm really excited for with our community is the growing number of junior positions that are popping up. If you see the list of the companies, GitHub is the one, I think of top of mine who have started creating like a hybrid coding and community roles for junior people to get their foot in the door, to start to get some real experience under their belt before going for something a little bit more coding, have a little more full time.

I think at GitHub they're calling it like a... Oh, I'm going to mess it up. It's not a community manager but it's something around like a community manager position. What I really like about these hybrid roles is the fact that a lot of folks in our community who are transitioning into code have very, very valid, very awesome real world job experience. It's just not technical experience. They've done a lot of sales, they've done some design, they've done marketing, they've done a lot of community building, they've done a lot of customer service, really empathy-centric jobs and roles. With these hybrid positions, they're able to leverage that background a lot for those really awesome communication skills, while also getting a little bit more comfortable in transitioning into a more code-heavy, tech-related position.

One thing that I hope happens and frankly, I think just needs to happen, given the high demand for developers is more of these hybrid roles, more of these entry-level junior developer roles. I know that there are apprenticeships and internships that have always existed for computer science degree students that are now transitioning and being a little bit more open to career transitioners as well as people who are students. I'm definitely seeing a lot of shifts in the industry and I hope to see more of that. I hope that more of these awesome people who are really just so excited and so passionate and eyes wide open and very teachable. I think it's one of the things that senior people are really excited about working with our community is knowing that we are very open to being taught, we don't have best practices, we don't have bad habits yet so we're really moldable in that way so I'm really hoping to see that trend to continue where there are more learning positions and also more full time entry-level positions in software.

JEFFREY: That's excellent. I hadn't heard of many examples of the kind of hybrid role but I'm thinking back to previous job I had where there was a very large customer service department and several members of that team are like, "We want to start developing." Like they're playing around with code and there definitely could have been an opportunity for them to maybe 75% of their job is the customer service work and what they've been trained to do. Then the other part of their job is like, "Let's start leveling you up and let's start teaching you some things and giving you an opportunity to play and learn." That's an awesome opportunity.

SARON: Yeah and that's the thing too is a lot of this is already happening on informal basis. I've heard definitely my fair share of stories and we've actually interviewed people in the podcast who said, "I started in customer service. I started in accounting. I started in this totally unrelated part of my company and then I raise my hand and I said, 'I want this coding stuff.' I started shadowing developers and just going to hang around the engineering team enough that they eventually let me do some documentation work or look at some bugs. Then I slowly transition into a developer position."

A lot of this has been happening very organically but I think the more we can systematize it, the more we can formalize that process, the more accessible it becomes for people who just didn't know that they could raise their hand and create those opportunities for themselves. I think the more people do it and the more we can really put rules and structure around programs like that, the more we can bring more people in.

ROBERT: That sounds really cool. I have a question. We know what the good situation would be for a newbie to get into. Are there any things that you could advise people that might be looking for the first dev job like anything that are red flags to avoid?

SARON: There are so many red flags. That's a good one --

ROBERT: Because I wish I had this when I was starting out.

SARON: Yeah. I think one of the hardest parts about being a junior person is just not knowing what it means to be a good developer. It's one of those things when senior people tweet and write blog posts and things about how incompetent they feel a lot of the times and how they feel like they just don't know enough. On the one side, it's really comforting and it's validating but on the other side, for me at least, it makes me panic a little bit because I'm thinking, "Holy crap. If you don't feel like you're good, then how would I ever be good? How would I even know what good is if I'm working towards that?"

I think one of the things to look out for is a company that actually has put some thought into what it means to be a good developer? What are best practices? I know this is super subjective and a lot of times it's just based on the product of the company and the values of that space but I think for a junior developer, if you walk into a place where people are so busy running and trying to catch up or trying to keep up that they aren't able to look back and go, "Oh, you're on the right path," or "You're making progress," it's going to be, at the very least frustrating for you and worst case scenario, it'll be impossible for you to grow and really develop and progress in a way that's going to make you happy and fulfilled for your career.

I think one of the red flags is -- not so much of a red flag, it's more of one of things to look out for are companies that have tech blogs, that have a podcast, that have really good documentation, that have style guides, that have a mentorship programs, that do brown bag lunches, things like that really show that the companies put a lot of thought into what they value on their engineering team and are much more likely to help you grow in your career.

JEFFREY: So that it's more likely that they will have room for you to grow instead of, "Hey, we need some cheap labor."

ROBERT: Yeah, exactly and that's the thing. As career transitioners, people who are not used to tech salaries, it's super easy to undervalue yourself. It's very, very easy to say, "I'm just coming from a job that paid $25,000 or $30,000 a year. Yeah, I'll take a $40,000 dev job. That's so much better than what I'm doing." It's like a 50% increase. It's really easy to sell yourself short. I think when you look at a company and see the structure and the thought they put into growth, I think they're much more likely to really invest in you, as opposed to taking advantage of the fact that you're just more than happy to be there.

ROBERT: Yeah, I love that. One of the things that Brandon told me when I first started here and I was worried about failing was we didn't invest in Rob the developer, we invested in Rob the person. That was something that really stuck with me that helped like it harkens back to the Impostor Syndrome, it definitely helped with me except being that failures will happen and if I do fail, it's okay because I'm in a space that allows that.

Maybe something that a newbie would look out for is software teams that have good process, not shipping broken tests to production or things like that. But also managers that are there to help you and to be there for you and take you on one-on-ones and give you good feedback. I guess, it really just boils down to having a good support structure.

SARON: That's the kind of thing that can be hard to evaluate until you're actually there on the team. When you're in the interview, it's like dating. You put on your best outfit, you put on some lipstick, you get your hair done and who knows what you really look like on Wednesday night at midnight, right?

[Laughter]

JEFFREY: That's when I made my best. I don't know about you.

[Laughter]

SARON: Some questions that have really helped me out or asking how do you support more junior people. You specifically asking like, "Do you have an education stipend? Do you have a conference stipend? Do you have books? What are the perks?" A lot of times, it can be really straightforward to evaluate. How much they care about your development as a person, if you just look at the perks that they offer? I really love when there is an education thing, when there is a book thing, when they pay for you to go to conferences because that really tells me that you care, not just about getting the most out of my time with you but you really care about my development as a person, as a developer. Those are really good signs.

Then I think there are things like when you brought up testing -- that was one of my basic requirements when I was interviewing a few years ago -- and was saying like, "Do you have tests? Why don't you have tests, if you don't?" I've had a lot of answers and they were like, "We didn't really see the point," or, "We just don't do that here." Those are not good reasons to not have test.

ROBERT: No. Those are very bad. If you could see the faces we just made, we're like, "Ahhh! No!" Especially for a newbie jumping in, that is your safety net because you read the assertions and you can understand what the code is supposed to do.

SARON: Yeah. Same thing with documentation like how much time they spend on documentation? If the answer is, "We don't do that," then the whys are what really become important. If the why is simply, "We're stretched too thin. We're trying to fix that by hiring people like you where we can now focus on documentation," that's a much better answer than, "Ahh! We just don't really need it. We don't see the point."

I think when we can ask the people who are looking for jobs, when we can ask the companies more why questions and really get a sense of the way they make their decisions, I think that can be very telling in what type of environment you're getting into.

JEFFREY: I add in there. One more thing for junior engineers to look for is vulnerability from future employers that they're willing to own up to their mistakes and talk about their failures. You know that you as a junior person, I also have the ability to do that. You're going to fail. It's going to happen. But if it's an accepted thing and a thing that the company knows how to deal with and talk about and embrace and turn around into successes, then that's a very good thing.

All right, thanks for joining us, Saron. Everyone check out CodelandConf.com. That's coming up in April. That's all for The Frontside Podcast. Thanks for joining us.

Show Notes:

Resources:

Linguistic Intelligence

Transcript:

CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode 62. My name is Charles Lowell. I'm a developer here at The Frontside and I'm here today with Jeffrey Cherewaty and Robert De Luca, also developers here at The Frontside. We're going to do a little bit of navel gazing today. We're just going to talk about how we roll and who we are and because we've there's been a lot of conversations about that, as we had a couple of different projects come in that use different tool sets so what is it about us that is constant and what is it about us that changes? I just wanted to talk a little bit about that. The core idea is about UI. The shop has always been about UI and I'm curious for you guys, what does UI mean to you all?

ROBERT: The frontend to the frontend?

JEFFREY: That's a loaded question.

CHARLES: Okay, let's step back a little bit from that because we've been in business for a long time and right now, we're doing mostly Ember, a little React. Before that, we were doing all Ember. Before that we were doing mostly Rails. Before that we were actually doing a little bit of wxWindows stuff and before that we were actually doing stuff in Java. But all of it fell under the rubric of UI -- user interface. What is constant? I mean, there's some radically different tools. When you look back and you think, "My goodness." What could possibly connect those things that I just listed? But I think there is a common thread so I wanted to explore that a little bit.

JEFFREY: The common thread, I guess at the simplest level is always that in a lot of programming, you're dealing with the interface to the end-user of your code is simply text. It's a call-in response or they're consuming a library of yours that's where the code is the end product. What we focus on instead is the the end product of what we build is the interface as the graphic representation instead of a code or a text-based interface.

CHARLES: I'm curious. In terms of all the software that gets written, how much do you think- because I think that's a key distinction. There are certain software that interfaces with other software. The connections to other software, there's a very unique set of problems when dealing with that. But there is also a different class of software where it's interfacing on one side with other software but on the other, it's interfacing with human beings. What proportion of software they get? How much of it is actually interfacing with human beings? How much is actually interfacing with other software?

JEFFREY: I think the most software developers underestimate how much other human beings are interfacing with other software. Even if it is a simple HTTP protocol Rust type interface, it's still being used by human beings even if it's human beings writing code.

CHARLES: That's true. There's definitely like a whole metalevel and that's like --

ROBERT: Like the developer experience versus user experience?

CHARLES: Yeah but it's true. There's probably very few pieces of software where the ergonomics aren't important to actual people. That's true. There's definitely like a [inaudible].

JEFFREY: What you're getting at is that there's typically much more code underneath the surface than there is that actually is visible to a human.

ROBERT: That makes it all work.

JEFFREY: Exactly.

CHARLES: Yeah. The part that's lying just beneath the surface is an ocean in of itself, I would say. It certainly seems like because that's the ocean we swim in it, seems vast at times.

JEFFREY: Where does that UI stop? At what point does it stop becoming UI engineering and becomes more like API side of your server side? Obviously, you can say like, "Right when you start talking to an API. That's the end of it." But all of the code that goes on the frontend, the people refer to this as the frontend of the backend. All that code that is just there to get data and then massage that data so then somebody can go and present it to the user is at all UI at development. It's gotten a lot murkier in the last three years.

CHARLES: Yeah it's a lot murkier because the thing is the way we structure our server technologies are changing so that they can support various interactions. For example, one thing that springs to mind is treating the data that we have inside of our client and I'm thinking of a browser tab, for example. Just one browser tab, one browsing session, you load data from the server and you write data back to the server but what we're seeing is that degrades the UI experience if you treat it just like that.

I feel like the general trend is to treat the data that's housed in that browser tab is merely one partial replica of some distributed data set that's being replicated across a whole bunch of nodes where your storage nodes are one of those things, the node that other people are might be using in participating as application or other nodes and then that one browser tab in itself is a node in this distributed database. But that's crazy because that's what you would consider a classical server work. But to get around the fact that application state is updating and changing rapidly and trying to keep up with it in a non-buggy fashion can be really, really difficult.

I know the waters are getting a lot murkier but I think that example does touch on something that I would say is kind of classical UI problem. You have some sort of stateful something. You have some sort of long running process that's just sitting there that's kind of moving with the user because the users holding a lot of state in their head as they're interacting with your application. A lot of the context is stored in their head so the UI needs to be able to dance with them and be in lock step with them and kind of mirror the context and their understanding of where they are in the system so it's usually very stateful. At least the ones that we've been working on over the past years.

JEFFREY: I think another core principle of UI engineering is responding to events in a way that just doesn't happen as much in classical server engineering. You have to respond to a message or some kind of request every once in a while but the level of responding to changes in state and changes in how the human is interacting with the interface is a whole another level in UI engineering.

CHARLES: It is really is a dance, in the sense that as the human moves their virtual hand throughout your application, you have to be tracking that state at all times.

JEFFREY: It's like it really shines itself there. If you compare a state machine for the server side and then a state machine for the client side because we've built both and the client side is way more complex because there's just way more that's going on, impossible things that can happen. With an API, it's like almost crud in a way with an API and then on the UI side, we have to take a lot of user interaction and boil it down in order to persist that on the API side. There's more for us to take care of, on the UI side in track and it just more complex.

CHARLES: That's true. I think there might be some people who work primarily on the server. They're being like, "Wait a minute."

[Laughter]

JEFFREY: At least on the server side, you have one runtime that you can deal with and for frontend developer, there's just so much to contain.

CHARLES: Yeah so in terms of tracking that state, certainly one of the things that I think is also unique problem for user interface is that you have to constantly be taking in those events, that you're talking about, like you're constantly having to update your state so that you keep in lockstep with where the users at. That can also be part of that information that you'd be reacting to where other users are at, besides just that user so that they can absorb that context. Yes, so reacting to where they are but then also radiating information constantly to the user so that they're both inputting at extremely high rate but they're also receiving information. Like you said, it got to be extraordinarily high bandwidth so that state that you're tracking has to be represented accurately at any given time.

I think, basically the core driving principle of NBC is you have this model and that represents your state and you have these events which then update that state and then you somehow managed to instantaneously reflect that state change to the user in that tight loop. I feel like that pattern, despite people tried to bastardize it, or maybe not bastardize it but adapt it for their particular use case but it has been persistent. It's like a cockroach, man. Always live and never die. I feel people are trying to assign new acronyms and new names for it but the fundamental pattern has proven to be effective over and over again.

I would say that if you're using NBC, if you're building like a system with React or you're building a system with Java Swing, like we did back in the day, you're using the same basic pattern even though the mechanics and the tools are completely different but you have this abstract representation, this model of either your state or your interactions. You can model a swipe or you can model a mouse move then you're basically reflecting that to the user and then taking updates to the model.

JEFFREY: What's changed about the tooling, say back when Frontside was primarily on Java? We're like, "That was the tool." It kind of a blunt instrument for some of the UI challenges we have now. What was working well in that arena and where we come [inaudible]?

CHARLES: I think there's just so many exciting things that have happened since then. Especially in the past, like three years because Swing which was the Java UI framework which was fabulous, just absolutely magnificent, was at its core an observation-based system. You had a lot of observers. You can basically have these models and your view was a separate object but then you had your model. This was definitely a watershed moment. At least for me, from inside your code, you never actually updated the view. You never said I want to paint this thing. You never said I want to change this componentry.

Only thing you did in reaction to events was set properties on your model. It was a mutable model so you basically had your state which is like a chalkboard but your code, the key thing there was you could paint things in Swing, you could render things but you never actually did. You had your components that always render off of a model and you never call those imperative like draw this line here, draw this line there. You always update your model and the view reacted to it. That's fundamental and that's something that we still see today but we were using mutable models. The models themselves just got overwritten every single time.

The other thing is they were observer-based so you would observe this model, you observe properties on this model and when those properties changed, you're view would rerender essentially but I guess the paradigm was the view pulled data off the models and I feel like in the last three years, really with the advent of React, I think really popularized this pattern now and everybody else is adopting this.

ROBERT: The flow architecture?

CHARLES: Well, yeah. It's like a push model. Instead of having the view pull from the model but via observation, you have your controller essentially push a new model onto the view. But I still think the basic components were there, where there's two things that I think have change. One is this push model -- the pull view observation versus push from an event like event generates a new model and pushes on it and then the second thing which is probably coupled to it which is the idea of having your model be immutable.

The magic of that is that you essentially unbraiding time from your model so that you the programmer are managing time instead of the CPU clock, which sounds weird to say. See, you guys are like, "What the hell are you talking about?" But that's fundamentally when you have something that's mutable, you're saying this is one object. It's the same identity.

ROBERT: That you've changed over time.

CHARLES: That you change over time but you're writing it to it where is when you use a different model each time, you the programmer is essentially saying, "This is the same object. You are managing identity of the objects not the computer. Does that make sense? You’re saying here are a bunch of states but the identity of this thing is like an abstract concept and I'm saying all the states represent the same object or same entity just over time. What you're doing is you're essentially decoupling time from your model and that's I think a key innovation because then it gives you control over time so you can actually represent time, however you want to and that allows you to do things like history and what's the time travel debugging, which I think is very different than undo/redo. I think people conflate those unnecessarily but it allows you to do undo/redo history type stuff because the timeline is totally orthogonal now.

Whereas, if you have immutable state, it's like, "What this looks like if that time is absolutely coupled to right now?" I think those are key innovations but I think that the fundamental pattern is still there. You have models, you have views and you have control code that manipulates. I think the key thing that's happened over the last three years that have switch between having the views pull the model versus having the controller push on there.

For example, using essentially what amounts to an observable interface. I think observables as in ES7 observables are one of the coolest innovations to come around because it gives you that convenience of having a single reference point but access to all of the states that then you can react to it.

Anyway, that's a long winded thing of saying that I feel those core entities are still there, where you have this and then everybody who listens to me long enough will probably get tired of me saying this but I think that the primary one is the model, like understanding that.

ROBERT: Because your UI should be eventually derived from the data that you get?

CHARLES: Right.

ROBERT: And it should be because it is a source of truth.

CHARLES: Right and everything else can flow from that. Understanding how you're going to represent it, whether we are representing it as speech, whether you're representing it as touch, whether you're representing visually, whether you're representing it with your ears, to understanding what is it. There's still one thing that can be projected into a bunch of different media so getting at that thing is the thing.

ROBERT: That was a long, winded way of saying of what is UI engineering and what is unique about it but why would you want to plant your business in UI engineering?

CHARLES: Right. That's a great question. Why is it a good business to be in and why is it a good feel to study? I think I'll quote one of my favorite video games from my youth, which was Mortal Kombat 2. At the very beginning, they would say, "There is no knowledge that is not power." That was the big quote in Mortal Kombat 2 and I'm pretty sure that the knowledge of Kung Lao, I think, being able to throw his hat by hitting some key sequence of joystick and buttons, I don't think that's knowledge that's going to give me power. Sure enough that I don't think that knowing those key sequences really had much power in them but I still think it's a good saying.

[Laughter]

CHARLES: I was always wondering what that particular quote at the Mortal Kombat programmers really like. But anyway I think that it's good to understand it as a discipline, either here or in your organization because it gives you staying power, because you understand that deep structure. For example, if the winds change and the tools get updated --

JEFFREY: As they inevitably will.

CHARLES: As they inevitably will, right. We mentioned Java, we mentioned C, we mentioned Rails, Ember, React like back down knock out, all those things, those are transitory and they're ephemeral. But that knowledge isn't and it's a rock that you can cling onto as the change of storm over the landscape of the development community. If you understand that, your transition to the next thing will be a lot easier. I think that's the business value, at least from my perspective, the ability to [inaudible] those storms and be like, "Oh, this is the same thing. It's got different clothes. It's got some nice updated patterns but I understand fundamentally what's going on. I can work with it. I can find out what the things are."

They talk about their linguistic intelligence so your second language that you learn is very hard, your third one is a little bit easier but then you have these people who speak nine languages. Once they learn and go through language four or five, it's actually a lot easier for them to pick up language and you're like, "How can they do that?" And the answer is that they understand the deep structure of language that's basically baked into our DNA. Every human being is born with it --

ROBERT: There are patterns.

CHARLES: Yeah, there are patterns and they know them and they understand them and they just absolutely have intimate knowledge of them so the stuff that gets put on the window dressing, they can see beneath that like X-ray vision and they can pick that up and work with it and run with it and it becomes mostly just an exercise in learning vocabulary.

ROBERT: And for as long as users will be interacting with the things that we build, there will always be UI engineering. There will always be somebody out there needing work.

CHARLES: Exactly. Do you want people who are fatigued by the JavaScript churn, so to speak? There are a lot of different strategies to dealing with JavaScript fatigue but a great one that I know of is to understand the core principles that are going on beneath the tools and realize that the tools really are the icing on the cake, the tip of iceberg, so to speak.

JEFFREY: This kind of brings us back around full circle to what originally started this conversation on our office is how The Frontside brands itself. We have, for the past few years, been doing almost exclusively Ember work. We love Ember as a tool and a framework that's done really good things for us and we've enjoyed working with. But we want to not marry ourselves so tightly to a tool like that because we believe in the problems and the concepts more than the tools themselves.

CHARLES: Exactly. We want to be married to the problems not the tools because what we're really looking for is for when someone has a special interaction that they want to see made real when they have a special product that they've maybe spent a lot of time and energy and thought and maybe money on crafting the user experience. We want those people to think of us because they're saying, "Now it's time to build the UI."

Before there is even an inkling of what the toolset will be, what the implementation strategy will be, we want to be at the first and foremost at people's minds. Regardless of how it's going to pan out, we know that these folks can get it done. They are going to implement this thing that is going to be as good or not even as better than the way that we envisioned it. I think that's important so we've been trying to transition towards that type of message.

ROBERT: We talked about how UI has these things that are long-lived. One of the really long-lived things and I think is going to be here for a long time is JavaScript. We do JavaScript very well. Everything we've been doing since, I would say what? Mid-2015?

CHARLES: Yeah.

ROBERT: -- Has been to abstract away from the UI framework and just base JavaScript libraries because that can be portable to anywhere. That can go from the server, on Node, all the way to any UI framework that you want and even native now with native script in Angular or React Native.

CHARLES: It's true. It's amazing how portable JavaScript is.

ROBERT: We are betting on JavaScript UI and I have gotten a couple of tweets from people because they know that we're an Ember shop really and when we talk about React, they're like, "Are you just a React shop?" I was like, "No. That's a big distinction when [inaudible]."

JEFFREY: -- UI shop?

ROBERT: Yeah. We want to be able to pick the framework or library that we see fit for your project and it doesn't matter if it's an Ember or Angular or Vue or insert next year's framework because it's going to be written in JavaScript or a superset of JavaScript like TypeScript.

CHARLES: Exactly. We love all of those frameworks and we think that they have their individual tradeoffs but we have to think about what those tradeoffs are. Also, think about how can we share as for example, this Ember app. What can be shared between an Ember app and React Native app and you might think, it's not much. But my guess is probably a lot, like most of it could be. That's kind of a radical idea but at the same time, it's a very simple one and seeing that pan out, I feel we've actually been accomplishing that and this isn't just something that's like smoke and mirrors, this is what we've been doing and the strategy has been working and it's been paying off.

ROBERT: We do UI well and it doesn't matter what way we write the code, at the end of the day we're still producing this interface that users interact with and that's our bread and butter. That's what we do really well. The framework is just the thing that we're using as the flavor of the month, year or whatever it might be, to get the job done but we are betting on UI and we do it well.

CHARLES: I think, it's actually a testament to a framework as how well it can adapt to plain JavaScript. The way that we model these interactions really is with simple immutable POJOs with well-known transitions to new states. That's it. It's like secret magic sauce that is so, so simple.

ROBERT: Remember earlier when I mentioned the state machines between the server side and the client side?

CHARLES: Yeah.

ROBERT: We modeled these as immutable state machines,

CHARLES: Yeah and they're so incredibly portable. I think, Ember back in mid-2015 wasn't so great at hosting these simple objects. Now in the early part of 2017, it actually is. It's very easy to write those things. If you're using Redux or React, we're kind of more friendly to POJOs from the get-go but I would say this. I think there's clear value in not putting logic inside your reducers. Like what is a reducer for?

I actually think that you are better decoupling your JavaScript from a framework like Redux, in the same way that we reap huge benefits from decoupling all of our state transition logic from any framework artifact inside of Ember. It meant that we were ready to drop in those interaction models into React. It was like boom! There was very low friction. It was extremely low friction.

ROBERT: Because these interactions are in a base JavaScript library and the UI library is what's driving those interactions. You're actually talking to this underlying JavaScript library that we wrote and abstracted away from the UI framework. But we still need that UI framework that whatever you inserted into to play those actions.

CHARLES: Yeah, exactly. You need Redux to manage the current state to basically manage your concept of time but maybe think twice about coupling your actual interaction model to a framework because it's going to be portable. This is a lot of pain that people had surrounding like active record. I remember for people in the Ruby, there was kind of 'aha' moment in the Rails communities like, "Wait, we literally don't have to dump everything into active records.

There was this, I think mass awakening, followed by this mass sign of relief. Once kind of people realized that everything you do doesn't have actually have to fit into a one of these kind of framework archetype objects, whether it'd be a reducer or a component or a route or whatever. If you have something that's truly separate, that's portable like make it portable. Once people kind of started treating active record as just, "I want to persist on something. This is what use," and things became a lot easier.

ROBERT: Because you're separating yourself from Rails and using Ruby, the language.

CHARLES: Right. I think, you said it perfect, Rob. It's not to disparage any tools. The tools are absolutely critical. In fact, the tools are most of the code. The amount of code, for example an Ember application provides to you is just massive and it's all very high value. Some people would debate that but the point is either all things that you're going to need to do but they're not things that are unique to the interactions that you're trying to provide.

I would actually like to see a version of Ember Data that doesn't depend on the Ember object model. I think being able to really separate that. It's pretty amazing library and if it saves an enormous amount of time, it would be fantastic.

ROBERT: But only Ember can ever use it.

CHARLES: But only Ember can ever use it but it is definitely a common problem and something that we miss like the 90% use cases that it covers. It's something that we miss when we're working in other frameworks. I actually think there is one more thing to touch on and this is really what separates, I think what we do from a lot of maybe agencies that are heavy on the design side but not super heavy on the UI side. I think is a major differentiator between the UX and the UI. Obviously, UI is very implementation-centric as opposed to vision-centric. I think, a good comparison is architect making blueprints versus the builder that actually has to construct the skyscraper.

CHARLES: Make it real?

ROBERT: Yeah, it has to make it real and that's what we do is make it real and There is an engineering component to it. While we have a very heavy focus on design and beauty and elegance and smooth interaction with the user and we study a lot of key user experience principles, there is a component to UI engineering which supersedes framework, supersedes design -- sorry, not supersedes but it's present, it's ubiquitous and that is bringing to bear all of the industry best practices around making quality, robust software. I think that's an important thing to point out.

It kind of goes without saying but I think it's important to mention is if you want to have all those good things and if you want to have good models, in views, in your controller, you want to work with a bunch of different frameworks. It's all for not. If you're not using all of those things that keep quality software quality, if that makes sense -- having continuous integration, having test suites, having continuous deployment and thinking about all the operations surrounding the software.

Ultimately, the UI is software just like any other system and something that we could go off and talk about for ages is how to test UI software because they are. When you've got these big stateful applications, they have their own unique testing.

ROBERT: But there's a lot of engineering problems here that are to be solved.

CHARLES: Right and I think it's important to be every bit as that. Anyway, I think that's about it on these subjects. It's just been kind of bouncing around the walls here and we're kind of think like, "Who are we? What is it that we do? What would you say that you do here?"

JEFFREY: We have access [inaudible].

[Laughter]

JEFFREY: That's what we do here.

CHARLES: Right. UI engineering, man. It's taking those UX dreams, right? And it's bringing them to life. It's making sure that they're scalable, that they're maintainable, that they're testable, that all of those things can become real, regardless of the tool.

ROBERT: And live long.

CHARLES: And live long.

ROBERT: That's the hard part. We can throw something together and match the conf.

CHARLES: Right.

ROBERT: But, "Will it continue to match the conf in three months?" is the question.

CHARLES: Hopefully so, we think so. I think we hit that mark.

ROBERT: Absolutely. It's the engineering, that's the tough part. That's the hardest part. Making it happen and making it sustainable.

CHARLES: All right. Thanks everybody for listening. We are going to be back next week. We've got some pretty neat folks stopping by so be sure to check it out.

Marcy Sutton: @marcysutton | marcysutton.com | Deque Systems

Show Notes:

Resources:

Transcript:

CHARLES: Hello everybody. Welcome to The Frontside Podcast Episode 61. My name is Charles Lowell. I'm a developer here at The Frontside. With me also is Mr Robert De Luca, a developer at The Frontside and today we have with us, Marcy Sutton who is going to be talking with us a little bit about accessibility, both in the large and the small. Welcome, Marcy.

MARCY: Good morning, everyone. Happy to be here.

CHARLES: I know, I understand you're actually calling us from the parking lot of a ski area.

MARCY: I am at the legendary Mount Baker ski area outside of Bellingham, Washington where we have the winter that is just going on and on and on and getting after it on the last few days of my birthday vacation.

ROBERT: Oh, wait. Happy birthday.

CHARLES: Yeah, happy birthday.

ROBERT: Happy belated or happy birthday.

MARCY: Yeah, it was Sunday so still on that shiny birthday week.

CHARLES: Well, thank you for getting with us on your vacation and on your birthday but doing a little bit of work, you actually work at Deque Labs. What is it that you guys do over there and what's your particular area of interest and work there?

MARCY: Deque is an accessibility company. We have people who work on products and services for accessibility. We help people avoid lawsuits and make their websites and mobile apps more accessible to people with disabilities. My slice of that work is on the product team, where I work on browser extensions, APIs for developers. Basically to make it so you don't have to write every single accessibility tool or test yourself.

You can pull in these APIs and get some of that experience that Deque has built up for years and years and years, which was part of the reason I went to work there was to learn from them. We make tools that make it easy for you to make use of that knowledge in your applications.

ROBERT: That's awesome. It’s like a base JavaScript library that can be ported anywhere, like to browser extensions. I know we use it in Ember accessibility testing. That’s really cool. That’s where I've gone for the way I write JavaScript. It's in a base library so everybody can use it and it's even more awesome that it's testing and like wrapping tooling around accessibility because I know a lot of developer-minded people want to see like a failed built.

CHARLES: Yes, what does that experience look like? I mean, coming from someone who's never even heard of these tools, how would I integrate them into my project and what would change about my workflow? What information would it surface?

MARCY: The best place and the reason I work on these products is that I saw projects go out the door broken a lot of times, when working in agencies or maybe testing isn't part of your methodology. Personally in my career, I just knew there had to be a better way. I got into software testing and the more I learned about it, the more I thought that it was sustainable, you could pull in other APIs to help you write better tests.

I went to work on axe-core, which is the JavaScript library that we've talked about a second ago. That really is bottling up all of these accessibility tests that you can automate some of the accessibility checks for things like if your HTML markup is in a good state and you're using attributes correctly. Basically, saving you from having to write all of those little microtests, some of which can be sort of complicated. It's all about getting test coverage for the automated things that we can actually test for.

CHARLES: You described a pretty wide-ranging coverage. How do you go about actually implementing that into your CI process? Do you just install the axe-core? Do you have to load up your browser and then pointed it out? What does that look like?

MARCY: Ideally, you would already have a test suite and you could just pull in the test harness. There's all different versions of aXe. There's versions in JavaScript and in Node. The core thing that you need to test is get your app running in a browser, whether it's a headless browser or could be a mounted browser but we need those actual DOM browser APIs to check things like color contrast. We need to be sort of coupled to the DOMs so that we can run our full set of tests, which is a distinction from, say some shallow rendering that you might be doing in React testing or something like that.

For accessibility tests, we need an actual DOM so you could get axe-core on npm and then pull it into your project and then you basically either require or import it, depending on what your stack looks like in JavaScript. Then you have access to all of these tests. It's pretty useful since our ecosystem has evolved to cover things like npm. I've found that it works pretty well.

ROBERT: That is pretty neat. You require it into your test and then you visit a page that's fully rendered and then you do aXe check, like you call a method that runs all these checks?

MARCY: Exactly. You would call axe.run and then you configure it to run, either specific tests or just one test. One of the tricks that has been helpful to know is that if you disable the color contrast rule, you don't need quite as many of the DOM APIs so it will run faster in things like JSDOM, which doesn't implement the entire browser APIs. But you could call axe.run, either in your unit tests or more likely it would be in your integration tests because you'd already have a browser instance, either through Selenium-WebDriver or karma-chrome-launcher or something like that. Then you basically call axe.run, passing a callback function and then it will return to you at set of JSON results and then you can do things with those.

ROBERT: When you call run, can you pass options of what you want to check? Can you filter out things that you know might -- because I imagine like if you put this into an existing app that's been going for a while, I imagine you're going to get a bunch of fails and it might be overwhelming. Is there a way to peel a back like an onion and start working at it that way?

MARCY: Yes. You can get pretty specific with our API. The GitHub for axe-core has our entire API configuration. You can get pretty specific. You can filter by tags. I imagined we're going to talk a little bit more about what WCAG is but there's a set of standards that you can break accessibility down into things that you can actually assert that they are either accessible or not. There's all different kinds of what we call success criteria.

All of our rules are mapped to these actual guidelines and standards because that means that our tests are helping you solve things that are actually helpful so you could filter by the different levels. Maybe you want to configure it with custom rules. We have some additional products for that. You can get pretty specific with what you want it to run.

ROBERT: It's extensible too so you can add your own stuff.

MARCY: You can and we do a lot of work with some of our clients to actually help them write custom roles so that's a service that we offer. But the API is pretty configurable on the JavaScript side so you can do quite a bit of configuring on your own as well, which is cool.

ROBERT: That is pretty awesome. You alluded to WCAG, I guess now we know how you can integrate a testing library into your JavaScript apps, let's take a step back a little bit and what exactly is accessibility and then you can start explaining WCAG because WCAG is a very big document that tells you how to go and be accessible.

CHARLES: I assume WCAG is some acronym?

MARCY: It is. Peeling that back a little bit to what is accessibility. I'm more on the digital side. There is physical accessibility as well for spaces. But when we're talking about digital accessibility, we're talking about making apps and websites that work for people with a broad range of abilities. Say, you had color blindness or a low vision or you're fully blind, you would need to be able to zoom in, you need high-contrast colors, you might use a screen reader if you're blind.

But then there's other categories. People might actually fall into more than one category including motor disabilities, where maybe you can't use a mouse and you have to use a keyboard only or a keyboard with one button, which is how we think about a switch control --that's another device. You might be deaf or hard of hearing and need transcripts or close captions so any audio or video content needs an alternative of some kind.

Then there's cognitive disabilities where people have learning disabilities. Maybe the language used on a website is too vague or too marketing copy speak and we need to simplify, people with traumatic brain injury like Stephen Hawking has ALS. I discovered at some point in my career that I could actually make the web a better place by supporting all different kinds of people. That's really what it's about for me is doing good craftsmanship and making sure that you're actually making things as accessible as you can.

The WCAG thing that we mentioned, it stands for Web Content Accessibility Guidelines. It's just that. It's a set of guidelines, sort of a map to help you get there. You have to actually interpret those guidelines and put in the work to do it. The guideline is just a guideline but it gives us a really good roadmap of how to implement all of these different areas of accessibility.

CHARLES: I actually had a question and this is a little bit harkening back to the discussion about the axe-core but also kind of straddling. How do you spur adoption, both the technology and the value inside of your development team? You know, we definitely make our web apps as accessible as we can because we have Rob on the team. But for teams that don't have Rob, how do you spurred option? How do you pitch it to your team and to your management structure? Like testing. Testing used to be controversial. I think in some pockets, it still is but it was something that you had to pitch or agile methodologies was something that you had to pitch. Now it's kind of accepted. It's a core-value of development, I think. I hope.

MARCY: Definitely more so. I agree.

CHARLES: Do you see a future where making applications accessible is just a tenet of development in the modern era and how do we get to that point? How do we pitch our teams to adopt that value?

MARCY: Part of what I'm trying to do is meet developers where they're at and make tools that make it really easy and free to integrate things so it doesn't cost you anything to npm install a library and pull it in your project or to use a free browser extension. What we're trying to do is really help developers get there by lowering the barriers, just kind of a funny way to put it because that's what we're doing with accessibility is removing barriers for people that get access to things.

I'm pretty optimistic about it. We talked a lot in the accessibility world about education is really needed because often, it's just that people don't know about it. I've made it my mission to spread the word as much as possible by doing talks and blog posts and just trying to get as many people on board as possible, instead of making them feel bad about it like, "Oh, you don't know about this? You’re terrible."

ROBERT: Oh man, you're speaking to me.

MARCY: "-- You can do this." I try to bring people along and make them feel welcome because it's not really a fun experience to be like, "Oh you're bad because you didn't do this. You don't think about this thing." That's what I try to do.

ROBERT: One of my first experiences in accessibility was like somebody giving me that moral argument like, "You're ruining people's lives. They can't do things on their computer." I just remember the response I had and it wasn't that, "Oh, you're right. I should go make this accessible. It was more of like I had a flight or fight response. I start to justify the reasons I didn't do and that wasn't a good experience so the way you put it, like meet the developers where they're at, I love that because that's how I've been operating too.

I think accessibility is just another engineering problem and it can be an engineering problem that would be fun to solve. The accessibility matrix gets really hard and hairy as you get into it like --

CHARLES: Oops! Jargon alert! What is the accessibility matrix? Does the accessibility matrix has Neo?

ROBERT: The different AT combos and since my experience stems from screen readers --

MARCY: Assistive technologies?

ROBERT: Yeah, assistive technologies -- I'm doing a poor job here -- Basically, you have three levels that you work with here. It's the operating system, the type of assistive technology and if we're talking about the web, it's the browser. You could have like the matrix, the beaten path is MacOS, VoiceOver and Safari. That's going to be your matrix. Then on Windows, it could be Windows JAWS and Internet Explorer or Windows NVDA, which is another screen reader on Windows. JAWS is also a screen reader. The browser for NVDA would be Firefox.

Then it can just fork in any of those different combinations that you could possibly imagine that makes it hard to debug for. But that's why I think this is a cool programming problem is because we can build awesome tools to help us do this and test for it like aXe.

MARCY: Yeah. I would also argue that it's almost even more of a design problem. It's part of the additional challenges that we have to get our design friends and colleagues on board as well because the more that they are thinking about it before they handed off to us, the less we're going to be caught in these situations where we have to make it work in one browser and assistive technology but then it's broken somewhere else because we're trying to use really experimental APIs or we're just trying to do things differently for the mouse versus the keyboard. I can tell you that could be really difficult.

The more we're thinking about making things straightforward and intuitive from the design side, not to say the easier job is going to be but the more successful, I think we can be as a team because it's more than just developments responsibility. There's good resources for designers as well, like a web accessibility for designers. If you just Google that, there's a great checklist from WebAIM. I think it's helpful to make it inclusive to people that we work with, not just in the development side because we really want them to set us up for success or else were really just fixing problems that not at their core. You know what I mean?

ROBERT: Yeah, as they come down the pipe, we're kind of dealing with them instead of getting ahead of it.

CHARLES: That reminds me actually of an experience that I had, a pair programming with Rob, probably about a year ago as we were making an interaction model for a select box. This was for a custom client. We actually stripped it away and we're like, "Let's just focus on what is the state machine behind this thing," so we drew it out on the board and it turned out that we were really just capturing the interaction apart from any rendering so we had a very strong model.

With each state's transition, we were able to basically radiate that information with a screen reader in this case. But it was actually very trivial to do because we've actually forgotten about the DOM, forgotten about the fact that we were actually chasing a visual interaction and like I said, what is the actual user interaction? What is the information coming in and coming out? It turned out once we kind of flush that out and have developed that, hanging the interface on that skeleton was very easy and we could do it in multiple media. It feels like a similar concept where if your designers are very upfront about really exploring the information architecture of an application then being able to represent that information architecture in multiple forms becomes much easier because the joints and beams are very, very clear and they aren't bound to a particular form of representation.

MARCY: Yeah, I think it a way that's definitely true. One challenge I would issue for this part of prototyping would be to consider all of the user inputs. Make sure that you're considering a keyboard user hitting an escape key to close that select or maybe they're using a screen reader on a touch device and like the single finger swipe, it's already allocated when that screen reader is running so if you have an interface that was only swipe left or right and there were no other affordances like buttons that you could actually activate, that would be an unusable interface to a mobile screen reader user.

What really helps to make that information architecture stand up or hold out when you're developing it, like stay true to your vision through the process is making sure that you're considering all of those user inputs. Sometimes, developers aren't thinking about keyboard user so they're not thinking about focus styles, really trying to activate it another way. I do think that's a helpful exercise.

ROBERT: Yeah, and to be fair at Frontend developers, we already have a lot to think about. It's just a lot to juggle so I can understand that's why we have tools like aXe. But what Charles is talking about, I think is actually kind of neat is we were experimenting with accessibility-first development so the people do TDD -- test driven development -- and I was trying to see if we could build something. I wanted to see if what we're writing would yield better software if we did it with an accessibility in mind from the outset.

I think that's true. It was a more accessible typeahead. It was better, more well-defined user experience around the typeahead and it was because we thought about accessibility and all of the different edge cases. We really boil it down to the core problem.

CHARLES: Right. We were driving it first with keys and nonstandard interaction methods. It meant that we actually got more clear interaction model lying underneath. It was decoupled from the actions that drove it completely because we had to support too from the get go.

ROBERT: I thought that was neat.

CHARLES: Yeah that was a fun exercise. You know, we should have blog about that because I think that actually results in better software.

ROBERT: Yeah, I had a conference talk brewing in there somewhere. Just never got around to it. Talking about the web accessibility guidelines. There's different levels to it. Now, you have an A, AA, and AAA. What do those mean and where does that play into ARIA roles and stuff?

MARCY: There's WCAG 2.0 and actually 2.1 is an update that they're working on right now but WCAG 2.0 is --

ROBERT: Oh, yeah. I saw that.

MARCY: Yeah, there's some new stuff coming out. It's mainly for low-vision users and mobile touch things. But the WCAG 2.0 is the blessed standard that we're working with right now and the levels are different conformance levels. There's different things that you can achieve with A, AA, or AAA. Most people go for AA. AAA is pretty restrictive in what you can do and if you make it support WCAG 2.0 AA, it doesn't necessarily mean it's going to be intuitive to use. You could make it technically conformant but it won't necessarily be that beautiful or accessible. There's a bit of a dance that we have to do around that to meet these guidelines but do them in an intentional way so that we're actually making something usable.

I think that goes back to that idea of craftsmanship and caring about your user to know if this actually going to work for them. There's a number of success criteria in WCAG that are broken up into different categories. There's perceivable, operable, understandable and robust. Within each of those, there's all kinds of different checkpoints that you can look at to inform how do I make this keyboard accessible. There's all kinds of really helpful documentation. That's the WCAG guidelines and within each of those, there are a number of different ways that you can code something.

As I'm sure you know, there are infinite ways to code the same thing, pretty much and part of what that cover is techniques for making things accessible. They'll tell you all about Native HTML and what tools you can use within that standard. Then there's this other standard called WAI-ARIA and that's the Web Accessibility Initiative – Accessible Rich Internet Applications. That was originally created back in the day when we didn't have as many browser APIs and we didn't have great ways to expose accessibility information to screen readers. They made this API in browsers that implemented that you can actually bolt on some of the same information that you get from HTML.

It’s helpful if you're writing as VG or XML, where you just don't have those built in semantics so we have things ARIA role states and properties. You may have seen things like 'role="button"' or 'role="main"' or 'role="search"'. You might see that somewhere and that is just exposing programmatically bolting on a role to any element. You could put on 'div role="button"' and there's a little more that goes into that to make it an accessible button. Anytime we mentioned --

ROBERT: The tab index.

MARCY: Yeah, the tab index. You have to make sure you have a keyboard event but that would be a programmatic way to create a button element. You should always start with the native button element because you get all that stuff for free but ARIA gives us an API to actually implement accessibility information. You'll see those techniques come up a lot in WCAG of how you can accomplish the same thing multiple ways. Those are some of the things that we test for in our animated tests in aXe. We check to make sure that you've only use roles that are actual roles because there is a set standard of them.

We check to make sure that all of the ARIA values that you might use are actually allowed for that. Sometimes, if you're using 'role="list"' for whatever reason, you can't use a real list. It is possible to create a list with ARIA but if you had the wrong child role or something, that's a pretty easy thing that we can flag with aXe so we're sort of saving you from yourself. It helps me sometimes when I get a role wrong because we're human and we do make mistakes. There's a lot of things to remember so that's pretty key technique that aXe will help you with. That's making sure that your ARIAs used correctly because it is pretty easy --

ROBERT: That's really nice.

MARCY: -- to get it wrong, to be honest.

ROBERT: Yes. I've definitely done that. Being through the spec document is not the most fun. Trying to read the standards language is a little bit complicated so having a tool like aXe is really helpful for me to pick my way through it like, "aXe will tell me that this is wrong," so it narrows the problem set down for me where I can go and look at the standard and kind of tunnel vision in on that one, rather than get overwhelmed looking at that whole standard documents like there's so much here.

MARCY: Yes, there is. One thing that might help with the is the initiative that people are working on called the ARIA Practices Guide, the ARIA Authoring Practices and it sort of breaks down these techniques into what is the keyboard navigation model for that component or it will break it into known patterns. This is really helpful also for designers to know what are some known patterns and how can I implement accessibly. They can really help you jumpstart to using those patterns with this more easily digestible information to tell you how to do it correctly. That has come up in the last few years that I found really useful.

ROBERT: That's awesome. I think I've seen this. Is it where they tell you like, "If you're going to reimplement a checkbox, here's how you would do with ARIA?"

MARCY: Exactly. I've dropped a link in the chat so we'll expose that in the show notes, I'm sure. There's more resources out there now that are really helpful. There's another one called ARIA in HTML and that one is also from the W3C and it's a note on using ARIA and HTML. That one I found to be very useful as well because they tell you this first, second, third, fourth, and fifth rules of ARIA use.

The first rule of ARIA use is if you can use a Native HTML element or attribute, you should absolutely use the built-in one first. That's a big --

ROBERT: Yeah, let's stop reinventing.

MARCY: Yeah, you know it's tempting because you can create these custom elements and try to bolt on ARIA but the reality is that if you're trying to make it really backwards compatible, it's just so much easier to support the native things. There is an assisted technology called Dragon NaturallySpeaking, that's a dictation method and they didn't support ARIA until 2014 so you can easily imagine some of your user base with an older assistive technology. That might be completely broken for them so that's why we really push using the native things first just because of the better support on every platform.

CHARLES: I have a question about the test automation. We've been talking a lot about aXe in the way that you can do this. Did I get it right? Are my roles correct? And all these things. What's an example of something that you just can't test for in an automated fashion? It just requires human interaction just to perceive it. I mean, this would be right now, kind of in the visual sphere, the state of automation for testing like did I break the layout still requires a human. What are examples of that in terms of accessible interface where you just do the things that you have to be on the lookout for that you can't cover with automation right now?

MARCY: I think context and content are some of the most difficult like writing good all text. That can be really challenging just because what makes a good alt for an image and that supposed to be a text alternative to say, "This is something useful," and Facebook has solved that by using artificial intelligence to dynamically guess what's in an image.

A blind colleague of mine that works there has written about and he said he always felt left out when he would read his news feed and someone would be talking about their first love or some kind of vague status update. With this new feature, it could say, "Oh, this image that they're talking about their love is a pepperoni pizza," or something where --

[Laughter]

MARCY: It's really missing the context so they've started to do automatic all text. For us doing accessibility checks, we try to keep our solution as light weight as possible and without false positives. We can check whether you have an all attribute missing like you don't even have the alt attribute at all which means that the file name would be read in the screen reader which is often terrible, depending on what your filenames are so we can check if that's missing but we can't really tell you what would make a better alt attribute, if you already have one. That's one is a bit difficult.

There’s another one that we're working on right now with color contrast where we can't really tell if you have a background image that's behind some text. If it has multiple pixel color values in it, even if we could read those colors, it gets really hard for us to say whether text meets color contrast when it's over an image for multiple reasons. That one's a bit tricky. I think there are some other examples throughout WCAG that we can only automate. Depending on which rule set you're using, we estimate between 30% to 40% of issues, we can actually catch with automated tests so there is quite a bit that we still need humans for.

But however, I think some of these really basic ones that we can check to help you do those easy wins so that you're not getting messed up by using the attribute Aria-role when it's just role. Those kind of things. It's like we're helping you so you can save that time for those more complex task that might require a human. There's definitely no substitute for trying to use the keyboard to make sure that your app is usable from the keyboard. Test it with a screen reader, you can find people in the web accessibility Slack that might be willing to help you test it, if you're extra nice or maybe you can give them a gift card or something.

There is an organization called Knowbility and they have this thing called Access Works where if you need to find a user with a disability to deduce a user testing for you because that's a great thing to do. It's very important. They can help you, as a business think up with someone who can test your app. I would definitely check out Access Works. That's really what's the missing piece. As a developer, I'm okay using a screen reader after doing accessibility for a few years but it's not my primary way of navigating so it's really helpful to have real users to test your app and that's a good way to find someone to actually test it. That sort of makes up the rest so you can get that really valuable feedback.

ROBERT: I'm a firm believer in testing but also, I really do think a lot of accessibility work is just kind of empathy building and the way you do that is just sit down and actually use this assistive tech that these people will be using. In that way, you can understand as you're building it, how somebody might move their screen or cursor over the top of this and you can start to think about what the screen will read off and stuff like that. I think using a screen reader as a developer is powerful. But I agree, it will never reach the level like my mom that has been using a screen reader for seven years now. I'll never be able to use it as well as she does. It actually putting in the hands of people that do this day-to-day and live this. A far better idea and that goes beyond accessibility too. You want to user test all your apps anyway.

MARCY: Yeah, exactly. I think that should be a big thing that we demand just from our organizations like how you were saying it was kind of controversial. I feel like user testing is another flavor of that where we have a bit of emotional tide of these things that we create and we want them to be perfect in the way that we have envisioned but not everyone interacts with things the same and it's really humbling to watch someone use something that you made and have it completely not get it at all. I think that's a really valuable experience. I've watched my mom or my dad or people try to use something that we assume is really intuitive and it's just not. We look at the web all day -- day-in and day-out being professionals and it's really helpful to show it to people who maybe aren't as fluent, aren't digital natives like that.

CHARLES: We talked about actual user testing. We talked about the checking where you render your application and you run a set of checks. Do you have any experience with actually -- this is kind of an idea that just occurred to me, although we did a little bit of it when we were doing native applications -- using the accessible interfaces to actually drive your acceptance tests? Is that anything that you have experience with? Because it seems like on the face of it, you've got this assistive technology that surfaces the key levers of your application so is it a good idea to grab those levers from within your test case? Within your acceptance test to manipulate your application and thereby kind of front load your accessibility because in order to verify it, you must have those levers in place.

MARCY: Yeah, from understanding your question correctly, you're wanting to just run your tests using accessibility features?

CHARLES: Yes. For example, when we write our acceptance tests in our application, what we do is as part of setting them up, say we want to click here and I want to enter this text into this text box and I want to move this over here and that implies actually dispatching mouse events, keyboard events and then also being able to find the elements in the DOM that I want to dispatch those events on so we're kind of doing it in, I think we use CSS selectors to find them and then we use the jQuery event interface to actually create the events and send them to those elements. But it seems that part of ARIA roles or something else is like identifying the role that this element has in your application and basically saying, "For my test cases, I'm going to use these roles and I'm going to use these things and I'm going to use different access methods, keyboard mouse or whatever to manipulate my interface." Does that makes sense?

MARCY: Yeah.

ROBERT: I think this makes sense in the native world where in order to get the label, I think you have to use the accessibility label.

CHARLES: They do that when you're functionally testing iOS apps so why not --

ROBERT: Does it port to the web, basically.

CHARLES: Yeah, does that port to the web?

MARCY: It does --

CHARLES: It's really long, way of saying that, I guess. Sorry you all.

[Laughter]

MARCY: No, and I wanted to clarify because I was wondering if you're talking about driving it with actual assistive technology, which we can't quite yet. We don't have any tools for that. But yes, you should --

ROBERT: We should explore that in Ember.

MARCY: Yeah, we just don't have the hooks for that. Maybe Python and NVDAs, since it's open source, maybe AppleScripts.

CHARLES: What would that look like to drive it with assistive technologies?

ROBERT: We talked to some people at Apple with Ember accessibility team and if I remember correctly, we could only drive VoiceOver on MacOS with AppleScripts but there was no way to do it in any other way so you only could do it with VoiceOver on MacOS and that was still kind of murky.

MARCY: Yeah, exactly. The idea would be, rather than just testing the browser, we would actually be able to run a simulator programmatically, to know is the screen reader actually exposing this information. Because a lot of it is there are things that get lost in translation, sometimes where we're following best practices and standards because we have this agreement that people who implement browsers and screen readers are going to follow those standards. It's definitely is not always smooth sailing with that. But there's sort of this disconnect between the browser testing and then actually firing it up in the screen reader and make sure it worked. We take that on faith a lot of time, which is getting back to your original question, why it's so valuable to have tests that use these interaction methods.

Absolutely, either in your unit tests or even in your integration test, they can live in either place to have tests that assert and closes with the escape key or it operates with the enter key or whatever the user interaction should be, that we have tests that assert that because that way, if you leave your team or heaven forbid, you got hit by a bus or something, you have a test coverage that makes a contract of how this component should work and you have accessibility support, actually built into your test infrastructure. That is super valuable.

At least we know that that part of it is there. We know we can drive it from the keyboard, which is how a lot of screen readers work. They operate on top of the keyboard so we can get really far just by having basic keyboard support. Then, if you pull in an API like axe-core, you can have it tell you if you were using ARIA wrong or something. It's sort of a combination of both where those feature tests in your actual project where you're writing something that it works with the escape key, those are custom tests for your application. I find that they're really valuable just to have in there, especially if you work on a component library or something reusable so that everybody who is contributing knows how this thing is supposed to work. I think that is really valuable.

ROBERT: Absolutely. I want to talk about accessibility in single-page apps. The problem with accessibility in single-page apps is while using a screen reader, you click a link and to the screen reader user, all it says is the link was pressed. They don't actually know that the content has changed. But in Ember, we kind of solve this by focusing the outlet that has changed but in other frameworks, in your experience everywhere else, how do you combat this? What are the best ways of attacking this?

CHARLES: Yeah, what are the problems that you encounter in single-page applications?

MARCY: I've done quite a bit of research and blogging and conference talks on this. I'm working on the Angular team for a while. The issue with the single-page app is the page isn't being refreshed when you make a raving change or something happens dynamically. The user's focus is never refresh to the top of the page so they don't hear a title change or things like that.

There’s different techniques that you can employ to make that experience more accessible. The first and foremost tool to have in your toolbox is focus management so that you're programmatically sending the user's focus to this new content. Say, I have a sidebar with links in it and I click one of them, I can send focus to content wherever it loaded on the page. That way, they are both alerted to the new content because depending on where you send it. There's different techniques for this but often, we will send focus to the wrapping element so that everything will be read aloud and you can accomplish that by using tab index of -1 in your HTML. That will make this wrapper catch the focus, essentially but it won't add it to the tab order of the entire page. That's a technique that we used to shuffle focus around.

I've also seen people use what's called an ARIA Live Region where you have this element somewhere on your page that's not visible. It has to be rendered so you can't use 'display: none' but you can basically pipe messages to these live regions to announce what's happening on the screen. I've just saw a React example where they put an ARIA Live attribute just on that wrapping element, instead of the focus management so anytime new content went into that element, it would just be announced.

The challenge with that is that you can't always control everything on the page. That works if you control everything and you know that only this one element is getting updated at the time. But often, we work in this big ecosystem where there's a bunch of things happening. Depending on how complex your app is, you might need some sort of a focus manager, some sort of a utility that will keep track of what's focused and routed around at a correct place. That's the biggest tool for creating accessible single-page apps, that's focused management.

I mean, not only for the reading content purpose but also to have their focus in the more accurate place so if they hit tab or they try to start interacting with something that they're in the right part of the page. A good example, if you think about like a modal window -- a modal window may open as a new layer over something -- that requires focus management on open so that your focus is sent into it, either to the first focusable element or to the wrapper. Then when you hit escape or close the modal, it just send your focus back.

ROBERT: To the previously focused element, right?

MARCY: Exactly, so that if you are using a keyboard and you can't actually use a trackpad or a mouse to get back then you're in the right place or if you're screen reader user and you can't even see the screen, then you're always in the right spot. That's actually, I think really cool. Something that's become more common place with dynamic JavaScript apps is that we can do these really cool focus management techniques. I think they're really cool, they can be challenging but that is something that we definitely need to think about as developers of single-page apps.

ROBERT: Absolutely, especially since none of the single-page app frameworks out there were libraries. Actually maybe with the exception of your work on Angular, they don't come with a router focused-library built in so this is something that you have to actually think about and then pull in and do yourself. Does Angular have it, by default?

MARCY: No, we never added a focus manager utility. There were some things to try and clean up that HTML, which ended up being, honestly worse than the original problem. But I've written a blog post about focus management techniques. I just dropped that in the chat. There's a smashing magazine article I wrote and it really is framework-agnostic so it sort of covers all of the things that you need to think about if you're writing a client-rendered application using Ember, React or Angular.

It is something that we have to think about as developers because from the framework level, it's impossible to know what the right situation would be in your app in a given moment so we can only get so far with magic at the framework level. It's something I would like to see more of. Maybe if there is some sort of a layer manager, I think that is a tool that someone could write that would be super useful -- to make sort of an intelligent layer managing system for focus management.

I've heard the Facebook team talked about how they do it internally but it's not open source so I have yet to see an open source solution for this. We have to tackle it in our own apps but once you know that that's the thing, you can really make sure that you're covering it. If you have someone with a visual disability or impairment that try and use your app, they'll probably uncover that problem pretty quickly. That's the value of user testing in case you forget. Maybe there's a few views --

ROBERT: Need to sell it.

MARCY: Yeah, or maybe with your application, if you don't have visible focus styles turned on, you might not see that the focus isn't being sent. That is one trick, I will tell you in development. If you're working with focus management, turn the focus outlines on and then if you were trying to send focus before it got fully rendered or something because it has to actually be rendered to catch the focus. That is good debug flag, if you can all agree on the focus styles, for all users. I found that to be really useful in our app. You just to have those turned on so you can debug it.

ROBERT: And make it really loud like this is a giant red outline.

MARCY: Yeah, then you'll know, if you forgot to add tab index of -1, to make it catch the focus or like I said, maybe there's a rendering thing where you need to wait a tick by using a set time out or something. That is a good technique that I've used recently.

ROBERT: Awesome. Basically, what it boils down to in single-page apps is manage your focus and enhance your focus, some might say.

MARCY: Yeah, let's think about keyboard ergonomics, like if you are doing things dynamically on the screen and then you want to start typing, I think the most common example I see is autofocus. The developers, even if they aren't thinking about accessibility, they'll ask for autofocus. That in a way is focus management. The difference with autofocus is that you can only use it once and it will send your focus there automatically. But in a similar way, that's the idea of what we want is to get the user's focus point into the right spot so that they can do the right activity on the screen and they know what content they're looking at.

ROBERT: Right. Sometimes, it's like navigating around a website with your keyboard, that's like power users who have Vim or Emacs or anybody that's a power user of computer that doesn't like to leave the home row, you can make your application awesome for you to use and also lay the groundwork for accessibility, if you can navigate your website with just a keyboard.

MARCY: Exactly.

ROBERT: Let's try to pitch it to people in that way. It's still a developer problem.

CHARLES: I like that because it really highlights the fact that there is this kind of deep interaction model. The user actually is focused on one thing at a time in the application and if you track that, then it's going to be a benefit for all of your users. If you are deliberate about thinking like this is the subject of interest at this moment. You're just going to reap a lot of benefit for everybody.

ROBERT: Keep coming back to it, building accessible applications yields a better application for everybody.

MARCY: Absolutely. It might enable you to support some futuristic device that you haven't even thought of yet. If you have your actions decoupled from the actual input and you can do everything declaratively, that really makes it easier to try and support of use cases you haven't thought of like we need to borrow up that other keyboard combination or some touch device. It just really helps to not have everything buried in a jQuery event.

ROBERT: Yes.

[Laughter]

MARCY: Like, "Oh, man I need to call that same functionality for multiple events. Crap." You need to decouple that real quick.

ROBERT: "Let's obstruct this."

CHARLES: Right. I think we're about the time. I know you've got a hard stop. You got some skiing to do.

MARCY: I do.

CHARLES: So we will let you get up on the mountain but thank you so much for coming by. This is been a great conversation.

ROBERT: Yes, thank you for dropping all the knowledge.

CHARLES: Yeah, I'm feeling lots of knowledge right on top of my head --

MARCY: Awesome.

CHARLES: -- That I got to go and process. But for everybody else out there, I would say go experiment with aXe. The idea is going to be easy for developers. I know I'm going to experiment with it and then you said, there was a browser extension as well to help you out and probably call out every website that you ever use, right?

MARCY: I'm dropping some links for you, just now.

CHARLES: There's some links to go along with the knowledge so go check them out and you are @MarcySutton on Twitter?

MARCY: That is correct.

CHARLES: All right. Fantastic. Thank you so much for coming by.

MARCY: Yeah, no problem. Thanks so much for having me.