DEV Community: MURAL

Incorporating Accessibility Into Web Applications

Lauren Conrad — Thu, 20 May 2021 18:15:47 +0000

On May 20th, we're celebrating Global Accessibility Awareness Day (GAAD). This significant day is here to remind us all that even though the journey toward accessibility can take years, we’re still committed to making our websites and apps accessible to all people and to continue advocating for accessibility in every aspect of our lives. The Design Systems & Accessibility team at MURAL has been working on incorporating accessibility (also known as a11y) into our product. Along this journey to make MURAL’s product accessible, we’ve learned quite a few tips and tricks. Today, we're sharing what we've learned with you about incorporating accessibility into designs and products.

What is accessibility?

Accessibility is the practice of ensuring that any person, particularly people with disabilities, can use a website or web application. When someone considers accessibility, they might think only about a set of disabilities that they are familiar with, but the people who are impacted have a broad range of disabilities, which can be permanent, temporary, or even situational. For instance, if a person is holding a baby in one arm, how easily can they write an email? If a person is blind, how easily can they navigate your website?

Now that we’ve defined accessibility, you might be wondering, why is accessibility important? How do I convince others that it’s important? Who on my team should be working on accessibility? Some key points the Design Systems & Accessibility team kept top of mind while thinking about these questions include:

“Opt-in” by default: Accessibility needs to be the default standard, not something that would be nice to have. Everyone uses the web differently. Making products accessible ensures that more users can access your product. In other words, enabling more people to use your product, grants you access to a bigger market place. Working on implementing accessibility from the start also costs exponentially less than retrofitting a production-facing application/site, or worse yet, a lawsuit.
Teamwork, Dreamwork: Creating an accessible app is a huge project, and having only one person responsible for accessibility can create bottlenecks and burnout. By collectively assuming accessibility goals, everyone can focus on how their own roles contribute to accessibility. For instance, UX designers specifically are focused on developing the usability and interactions of an application/site. They also do things like user research, testing, feedback etc. These skill sets are not ones that developers typically have, so bringing designers into the discussion early on can make accessibility-focused development less overwhelming and difficult to achieve. Ultimately, to incorporate accessibility practices into the development lifecycle long term, the entire organization needs to actively prioritize accessibility, from development and design all the way to QA, management, and customer support. This is why the Design Systems & Accessibility team codified a universal pledge to encourage commitment to accessibility and inclusion. As of today, every MURAL employee has been asked to sign this pledge.
Shift Left: Think about accessibility at the start of the product development process, not after. Implementing accessibility into an existing app can be especially challenging for organizations that have been around for a long time. It’s easier to incorporate accessible elements while developing a product than to create a potentially inaccessible product and try to fix it afterward. So whenever possible, start early.

How to get started

In case you’re wondering how to begin, here are some ways to start incorporating accessibility into your app:

Use a plugin or a linter to scan your code for accessibility issues. For example, for React applications, you can use eslint-plugin-jsx-a11y to catch approximately 30% of issues that make an app inaccessible, like missing alt text on images. What a quick win! However, it’s important to also run a full accessibility audit including manual processes, to help identify usability issues. See the bottom of this section for details.
Run an automated testing audit using an accessibility browser extension. Free extensions like aXe and Wave can scan your app for accessibility issues that the linter may have missed, like low contrast color schemes. While this can be a great way to check for automatically detectible issues, it’s no replacement for usability testing, so be sure to still do a full manual audit.
Familiarize yourself with the Web Content Accessibility Guidelines (WCAG). WCAG is the go-to standard reference for implementing accessibility features and is maintained by the W3C, and is guided by four principles to ensure a broad range of accessibility: Perceivability, Operability, Understandability, and Robustness. Although they can also be overwhelming due to their thoroughness, they are the official resource on accessibility.
Create a checklist based on your product’s existing or planned features and make strategies to adapt those features to be more accessible. Here’s a sample checklist from the Design Systems & Accessibility team that you can take inspiration from:
- Ensure that users can fully navigate your app with a keyboard.
- Test your software using common assistive technologies, such as a screen reader.
- Ensure users can zoom in to 200% (the zoom percentage that the WCAG recommends) and that all content is still easily readable.
- Check that images and text meet color contrast levels of 4.5:1 to help ensure they’re still readable. Here is a color contrast checker you can use to test your designs.
- Make sure that language is clear and understandable. Check out the Plain Language Guidelines.
- Ensure you have no images that flash more than three times per second, because quick-moving graphics could be an issue for users with epilepsy or attention deficit disorder.
- Write alt text for functional images. These are descriptions of non-decorative graphics that a screen reader can read aloud to users with visual impairments.
- Add captions for videos and audio.
- Ensure that videos and sounds do not play automatically. Autoplay can cause a number of issues for users, and even prevent them from being able to navigate your site.
If you want to learn more about accessibility and the above recommendations, check out the Web Content Accessibility Quick Reference Guide that summarizes the Web Content Accessibility Guidelines. The guidelines contain extensive lists of standards to enable a variety of users to access web products more easily. For more digestible checklists and write ups on the topic, check out IBM’s breakdown of the WCAG checklist by role and this article on making images and other media incorporated into a website or app accessible.
Do a full manual audit of your product to ensure it is usable in real life situations. This is the biggest and most important step, because automated programs can’t test apps for the ways users will navigate them. Teach yourself how to navigate your website or application using only your keyboard, and then only a screen reader, and then show the rest of the team how it’s done. Bake in time for local testing using these approaches on even small product changes. If possible, include testing and feedback from users with disabilities, or hire an accessibility expert to augment your routine manual audits For more info, check out this Smashing Magazine article on the importance of manual testing.

Now that we’ve defined accessibility and reviewed key guidelines, we hope you’ve got a lot more ideas on how to make apps accessible to everyone and, as a result, how to create a more inclusive world.

Moving Towards an Accessibility-First Approach

tessa — Wed, 05 May 2021 19:27:39 +0000

Accessibility, or the consideration of the wide range of disabilities throughout the design and creation process, can be tough to integrate throughout the product development process. This is a challenge MURAL is also facing, and its Design Systems & Accessibility (DSA) team is working to shift the company to an accessibility-first mindset. In this post we’ll explore one facet of their approach, an education platform, in depth, and discuss what worked well and what could be improved.

A Trip to A11yland

The DSA team started with an ambitious project known as “A11yland.”¹ A11yland is a sprawling board game–like map linking to various video lectures, references, and practice exercises, and has multiple paths for various disciplines including design, development, testing, and marketing. The DSA team leads announced the program to the company at an All Hands meeting in November, closely followed by a strongly recommended voluntary “Power Hour”: a session with the DSA team that included a brief introduction to accessibility and empathy-building exercises like navigating the MURAL app using only a keyboard and watching a recording of a blind user traversing mural.co with a screen reader.

A11yland used this initial live workshop as a springboard into its first practical learning module: Assistive Technology. The DSA team tested this first chunk on five sponsor teams of about fifteen people each. These users were tasked with watching videos on people using assistive technology to navigate the web, explanations of different types of assistive technology including eye trackers and screen magnifiers, and practice exercises using the technologies demonstrated. The team also included additional recordings, written articles, and hands-on exercises that could be referenced if desired.

Of the roughly 75 people asked to test the training, six people participated, including two from the DSA team, and none had filled out the feedback request form nor asked for individualized help, which was also made available. The DSA team had been careful to start from a base of empathy and break lessons into thoughtful, digestible chunks that they called “bite-size,” so what was going on here? Why was no one “biting”?

More Than They Could Chew

To gain some insight, the DSA team surveyed their sponsor teams, asking testers what they thought of the training. Respondents said they felt overwhelmed by the amount of information and confused by what to do with it. They also had trouble seeing how the lessons related to work, and wanted to know the minimum requirements for their specific roles. In other words, they wanted a stronger focus on practical ways to implement accessibility and to spend less time on the “why.” The DSA team also noted that a majority of responses were from designers, while a couple were from managers, and only one from a developer.

The team then ran their own analysis, revisiting their initial thesis: a one hour workshop is not enough training to develop an accessibility-focused team. Did they still believe this was true?

Self Reflection

A11yland was never intended to be completed in a single day, but a resource to be visited time and time again while developing products at MURAL. If the team focused only on implementation and removed the extra resources, could they cram everything into one hour?

Educational feasibility aside, at a remote-first company it can be extremely difficult to find even fifteen minutes where everyone is free, so schedule-wise it seemed like an impossible feat. The team reexamined the feedback they collected, most of which asked for reduced focus on empathy. Could they afford to excise those sections?

In the team’s experience, empathy was the most effective way to engender “champions,” or people who actively promote accessibility practices within their team and/or outside the company; and was critical for developing products that are just not technically compliant to static rules, but also actually usable in practice. Thus, the team decided it wasn’t possible to significantly reduce the scope of their lesson plans. But before moving on to developing a new approach, the team discussed their own thoughts on what did and didn’t work for them in A11yland’s first iteration.

A11yland had been built with MURAL — a digital, visual, collaborative workspace — with the intention of dogfooding the company’s product while iterating on it. However, it was tough to track progress, which depended on an honor system approach where testers marked lessons taken on a table using screenshots. Seeing as this was difficult to keep an eye on for the six existing participants, the team concluded it would be impossible to scale to a company of 500 employees. In addition, because of the “sprawling canvas” nature of murals, it was tough for A11yland’s participants and facilitators to keep track of the overall scope of the lessons. Finally, the team realized they could have saved time and energy by starting to solicit feedback as early as possible.

A Sprinkle of Accessibility

With newfound focus on practical exercises and smaller lesson chunks, the DSA team decided to downsize each step of A11yland to just its hands-on practice sections, dubbing these “sprinkle-size” training. Because the empathy-building exercises are still key to motivating colleagues to take an accessibility-first approach, the team delegated these to a live workshop integrated into the required onboarding program all new hires go through. And to disseminate and track sprinkles across the company, the team decided to leverage KnowBe4, a training platform which already hosts MURAL’s wildly popular (really!) cybersecurity training program, which would allow them to automatically add new hires to the lessons as part of the onboarding process.

Before starting development on this new approach, however, the DSA team decided to roll out an RFC to get input from across the company, having learned their lesson from the A11yland rollout. This stage of the process is currently in progress, and we look forward to sharing how it goes!

Farewell to A11yland?

So with a new sprinkle-sized program in sight, is this the end for A11yland? Well... no. While A11yland was deemed to be an overwhelming first-time experience to the world of accessibility, it remains a great learning roadmap and resource for those excited to learn more about the practice, and the team plans to open it up to “a11y champions.” Identified by the speed at which they complete the sprinkle-size training, champions will be the primary advocates for accessibility on their respective teams at MURAL, acting as an embedded DSA team member to help educate and ensure accessibility practices are followed. The DSA team is also brainstorming incentives for champions, including swag and a possible budget for attending accessibility conferences.

Lessons Learned

While their trip through A11yland didn’t go exactly as planned, the DSA team remains excited to roll out both training programs across the company. The team learned a lot throughout the iteration of the education platform, and their biggest takeaway was to get feedback before building out the actual courses. While A11yland is still a valuable part of the platform and here to stay, the program is going to be assigned across MURAL slightly later than planned due to changes based on the feedback. Though a bit frustrating, the team doesn’t see this as a failure but as a necessary part of the development process; every organization is different and will require different approaches and research to challenge assumptions. Despite the change in approach, the team was able to maintain the same empathy-based foundation across both programs, the efficacy of which was recently validated by presentations at the 2021 CSUN Assistive Technology Conference.

Final Thoughts

Implementing and building excitement for accessibility can be extremely challenging, especially when working solo. The DSA team at MURAL feels lucky that this drive started with the executive team, responding to requests and requirements from academic and non-profit clients. They also face a relatively unique challenge to make accessible a visual application built on inherently inaccessible technology.

Reflecting on their situation, the DSA team leads feel both well placed and well supported to effect cultural change thanks to their broad experience in the field, the trust and support from leadership, and most importantly, the openness to collaborate and learn within their team; and they look forward to spreading that enthusiasm and knowledge across MURAL because “it’s the right thing to do.”

"A11y" is a numeronym often used as an abbreviation for accessibility. ↩

Scaling an Engineering Organization Quickly

MURAL Engineering — Wed, 21 Apr 2021 16:02:09 +0000

Kirby Frugia, our VP of Engineering, recently spoke on the Dev Interrupted podcast. On the show, he discusses how MURAL has rapidly scaled its engineering department, the pitfalls of growing fast, and how to keep lines of communication open.

Dev Interrupted: Lessons When Scaling From 0 - 130 w/ Kirby Frugia of MURAL

Episode

Transcript

Open transcript

Dan Lines, Host 0:01
Hey, you're listening to Dev Interrupted, the only podcast made for dev team leaders who want to continuously improve. Today's guest is Kirby Frugia, the VP of Engineering at MURAL. MURAL has gone through enormous growth in the past two years and Kirby came on to discuss the ins and outs of rapidly scaling engineering organizations. We go through the entire zero to 100+ developer scale up journey, dig into how he keeps the flow of information stable across teams, as well as the open source methods he uses to help onboard new employees.

Narrator 0:39
This episode is sponsored by LinearB. Give your dev team the power to improve with team based metrics, high risk code alerts, and the world's first project board based on real time git activity. Sign up for free at LinearB.io

Dan Lines, Host 0:54
Kirby, thanks for joining us today.

Kirby Frugia 0:57
Hey, Dan, thanks for having me. I'm super excited to chat with you.

Dan Lines, Host 1:00
Yeah, really excited to be talking about scaling engineering organizations, actually. LinearB, my company just announced our Series A round of funding, so we have doubling and tripling our engineering organization on the mind right now. So it's kind of perfect timing.

Kirby Frugia 1:20
Congratulations.

Dan Lines, Host 1:21
Thank you very much. To jump into it here, when you start with that smaller engineering team, you might have 10 to 20 engineers, things are a little more straightforward, especially as an engineering leader. You probably know everything that's going on, who is working on what, maybe where the dependencies are. Whatever, right. But as you get that next round of funding, you start looking at, we're getting 30 engineers, maybe we're getting up to 50, 60, or 80 engineers, things start changing, right. From your perspective, what happens to the team structure as we start scaling rapidly there?

Kirby Frugia 2:12
Yeah, when you're at 0 to 30 people, things are a lot simpler. You can rely on people knowing everything, knowing everybody. They know the product, they know the customer. As you start to grow to 20 to 30 people, it gets a lot more complicated really, really quickly. The number of lines of communication that you have starts to grow exponentially. You don't get some of those things I mentioned earlier for free, like knowing the product, knowing the customer, all of that. You have to start to put structure in place for teams to get to know the customers. You may start to split your team up. What a lot of companies do is split into smaller teams to split responsibilities of product up into different groups. You're probably still a monolith at this point, but you're able to make pretty good progress and still deliver on time, yet things are getting more complex. You're still pretty nimble at that small stage, you can move relatively quickly. At that stage, you're just starting to grow and you're probably starting to feel a little bit of the growing pains of a company.

Dan Lines, Host 3:14
Yeah, that's exactly right. Everyone can still talk to everyone if there is a problem. Everybody knows the code, you can work things out. You probably have just one manager at that point, or zero managers, so there's not as many people related problems. But once you start scaling now to the 50 or 60 point, are there a few things that happen to the team structure? Or maybe some things you should do?

Kirby Frugia 3:51
Yeah, absolutely. When you're getting that big, things definitely start to get more complex. You're probably in a monolith and starting to feel some of the impacts of that. You're probably accruing some tech debt and maybe you don't have enough tests. You probably do have that situation, where you have some people that know everything, but not everybody knows everything at that point. You start to have to figure out how to onboard people, how to get them to understand the complexity that other people know for free. One of the methods we're experimenting with here at MURAL is what we're calling internal open source, which is really leveraging some of the cool things that work out there in the world. Every developer works with open source technology, whether they're building it themselves, or whether they're using something. You might have a lot of dependencies too where you need something on one team that another team needs to do work for so that you can get your work done. How do you deal with that dependency? That becomes a real problem when you start to get to that 50 engineer size where you have a lot of teams with a lot of different areas of focus, but they start to depend on each other. We've been using data as a technique to allow teams to move fairly independently without a hard dependency on other teams. We do that through putting a set of maintainers on a specific area that's either a specific repo or a specific logical area of your code and anybody can contribute to those areas. If I need something from you and you're on another team, I don't go ask you and I don't wait for you to deliver and put it on your roadmap because when you have to wait on other teams, that's when things really start to slow down. You really don't want that to happen, especially at the 50 engineer level. We've been experimenting with that as a way to say, I need something from you, but I'm not going to wait on you, I'm just going to submit a pull request into your repo, and allow us to move at our own speed through that. We are starting to see some good success with that. That's one thing we've been trying.

Dan Lines, Host 5:49
That's really, really cool because dependencies do become a problem as your teams get bigger and bigger. Let's continue down our journey of scaling up. We have been talking about the 40 to, let’s call it 65 developer area. Now we're gonna head onto 80 developers or even 130 devs, maybe in that range. How does the organization change at this point? And what are some of the pitfalls engineering leaders could fall into here?

Kirby Frugia 6:33
That's a great question. It starts to look fairly different at about that size. We started off the conversation looking at 0 to 30 engineers, where you have a small team mentality, which is great because you're very productive. You move very fast. At the 80 developer mark, you've started to split teams but things start to get harder and harder as you get up there. The number of lines of communication have exploded at this point. You've got lots of different teams, you maybe even start to add directors at this stage. You're starting to group people not because you want a hierarchy but because you have more jobs to do. The amount of communication that needs to happen, the amount of independent teams who are moving that need to stay aligned and moving in a similar direction, that gets more and more difficult to manage. Things get messier. One of the biggest pitfalls is not communicating. Things get messy. You start to lose visibility into what's going on in the teams. People may start to lose sight of the vision — where everybody knows the customer, they know what's important, you can ask anybody, and they can tell you — that starts to get lost, unless you're deliberate about communicating it. You're probably undergoing a fair amount of change. If you're a resilient company and you're agile, you're figuring out what's working and what's not working — you're making some changes. People might lose sight of things, you have to invest a lot more in visibility. Things like OKRs, cascading goals, leading through measuring things, metrics becomes super important. You got to get really good at clean, clear, concise statusing, because you need to know what's going on. You want teams to be moving independently, without getting into a micromanaged, centrally controlled kind of environment. You want teams making decisions, because they're close to the customers, but you don't have a way to always know what's going on with those teams unless you build good information flow into the organization. At that size, investing in information flow is extremely important to avoid that pitfall of not communicating. It keeps people from feeling lost if you provide a lot of clarity, and it keeps the managers from feeling like they're accountable for stuff but don't know what's going on. Information in every direction — that information flow becomes really important.

Dan Lines, Host 9:03
Yeah, I was in this situation myself when I was at 60 developers going on to that 70 to 75 range. That was the last time I was a VP of Engineering. Unfortunately, there's a few things that I didn't do right, that are hitting home for me here. At a certain point, I was adding on more teams. We were getting that pressure from the executive team, where we needed to grow because we needed to deliver more features. That became the mindset of new teams that were forming up. What was really happening is they weren't able to get the code out. We didn't invest enough early on into that infrastructure or measure the right things like deployment frequency. That is actually the number one metric for a new team, because you want to ensure you can get the new code out, or new value out to production. Instead, what we did was say we need to build features fast and that really hurt us. It could be obvious, but is there anything for someone who might be in that situation, what they should do?

Kirby Frugia 10:28
Yeah, that is constantly a challenge. Especially in a high growth unicorn company, there's money available, you know you need more, you can envision this big organization, and every single person in that big organization has value to offer. Since you have so much good stuff out there to go after and do, it's hard to say how fast do we want to get there? That becomes a question. I'm in these kinds of conversations all the time. I ask myself, at what rate can we bring on people and have them be productive and feel like they're part of a team? You get into the mythical man month thing. I'm sure most people are familiar with that. At the same time, the reason you need to invest in all of those people is you have so much that you need to do and if everything was working perfectly, you would be able to add those people and they'd be able to get great work done. We're investing a lot in onboarding. That is a heavy, heavy emphasis that we have. How can we get new people in without disrupting the people already here, and get them to a point where they feel productive and can make changes without risking things or slowing other people down? You need to balance those two things. How do we get the team that's here super productive, while getting the new people on board and getting ready for them to deliver awesome stuff. You also need to understand in your organization, to what degree you can add people like what speed you can add people without it breaking down. You mentioned deployment frequency. It's one of my favorite metrics. We should talk about the four key metrics. I know that's something you're super excited about. But that's an important one, right? If you're adding people and you're not seeing more value get out to the customer faster, you have some important things to figure out on your team on how to get there. You don't want to be in a situation where suddenly you have that 130 developers we talked about earlier, but none of them can get anything done. That's not good for customers, that's not good for the developer, either to feel like they can't be productive. There's a lot of onboarding focus, training focus. You need to think about as you split up your teams, how big each of those teams should be, and how much each of them can absorb. We think in terms of, per month, how much could a team absorb? How mature are they? Do they have experienced developers on their team? You could add somebody to the team relatively easily without making a huge negative impact to them. Do they have time to adequately onboard people, when they bring people on? Is their productivity going out? Are they deploying more frequently than they were before? You do need a lot of insight to know what's going on.

Dan Lines, Host 13:19
Right and for me, that's part of the visibility as a leader, which I lacked at that time. The visibility. You said the four key metrics, well, what are they? You have your cycle time, your deployment frequency, your mean time to restore, and your change failure rate. If I have that visibility as I'm scaling, I can ask myself or my teams the right questions. Am I improving or at least maintaining in these areas? In my story, we were not, even though it wasn't visible. It's harder to see. Then you can kind of adapt from there. The other item I want to touch on is around not centralizing or being more decentralized. When we started to scale, we started to have more issues in production. That's that change failure rate metric, even though we weren't measuring that as well as we should have been. I had the instinct, that things aren't going well. Let's centralize, let's form an SRE team. They did great, actually, but the downside was the new teams being bought on were relying on the SRE team. They weren't getting that full authority or that end-to-end ownership because we went to a centralized model in that area. If I am a leader, and I'm getting that urge to centralize in an area, do you have any advice for when that feeling comes on?

Kirby Frugia 15:00
Yeah, absolutely. I think there's a good combination of centralizing some things and decentralizing others. SRE stuff specifically. I love that stuff. I spent time in that space in my career. What I like to think about in terms of the things to centralize are things that enable teams to own stuff, not owning stuff yourself. And, like, an SRE team can own infrastructure and like all of that stuff, and they should be accountable and responsible for those kinds of things. But in terms of a team's code, and owning that in production, you want that ownership on the team. And so what can you centralize your CI/CD, pipeline, centralize how you deploy things, maybe even centralize some test frameworks, some observability frameworks, like we have a developer velocity team here at mural. And their goal is to enable our engineering teams to have full ownership and to be productive and feel like they can actually get their stuff out the door easier and know how it's working in production. The things you don't want to centralize are quality, reliability, all of those things that, you know, are part of the process that often get shoved on other people. Because what you see happen, if you decentralize those is exactly what you were talking about. teams don't feel that full ownership, it's easy to throw things over the wall and feel like somebody else is going to catch the problem. It's not a mal intent kind of thing. But it's just a natural thing to be like, I'm gonna focus on the code. And and, you know, I don't necessarily even build those skills, or if I had those skills, they atrophy because somebody else is using them, I'm not using them. And so I'm a big fan of full accountability of the teams from beginning to end, they know the customer really well. And they care about the customer, when they're work has been deployed. And they have things like observability, they have their own metrics. So when we talk about the four key metrics, it's great for me to see it at the high level across all teams, it's great for the teams to see it themselves for themselves for the work that they do. And so they can, they can work to improve it, like, developers care a lot about this stuff. They're not often set up that way in a company, though. And so I've worked with a number of developers who've never been in that kind of environment, and it's a change every single time, I've helped move from that traditional mindset into full ownership, you end up happier at the end of that process, because they feel like actually, their work is valuable to people, because they can actually see it more directly.

Dan Lines, Host 17:24
Well, I can tell you, especially with the metrics, because we're doing this all the time, when I'm interacting with the LinearB community, if you just put top down metrics, even those four metrics that we talked about those the door four which are great, if you just go top down, doesn't work, you have to have the teams are the ones that own their team related metrics. And that's where, okay, now we're starting to see, at the end of the day, more value, getting the customers faster, hitting iteration deliveries on time, all that good stuff has to come from bottom up.

Kirby Frugia 18:01
100% agree with that, like, and the people care about that, like developers really care, like, oftentimes they get this image of they just want to write code, and they don't want to think about all this. That's not true. Like developers love to build stuff. And they love to do things that make people happy. And so if you can move more and more towards them, and have them kind of creatively own things and feel like their work is valuable. And they can see that and they can see that in the metrics and they can they can own their own, like the four the four key Yeah, absolutely. But they probably have their own metrics to like, how do they feel that they're doing and they should be able to have their own metrics and report on those. And so as you're building that scaling organization, you're thinking about providing clarity of what's important and then relinquishing control to the teams to figure out how to get there. And one of the best ways to do that is through metrics, and through them, self reporting, what actually matters, and then taking full ownership of that.

Dan Lines, Host 19:03
I want to talk a little bit about mindset changes. If you are a VP of engineering or a CTO, and you do have the responsibility to grow your engineering organization, from 35 to 50, this 65 to 80 to 100+, how should your mindset as a leader change as you're scaling up rapidly?

Kirby Frugia 19:34
A lot is the short answer to that, like, you need to change how you operate if you don't already operate a certain way. So like, you have to be comfortable. A lot of people get into leadership positions, through personal accomplishment, through team accomplishment, through like getting good stuff done with other people and all of that, but in a lot of ways when you're smaller, you have a lot of control over things like it's either in your own hands or you're just working closely with The people who do stuff, when you're leading a big organization like that, that's not even possible. Nor is it a good idea in general, and you don't want to be micromanaging, you don't want to be in a situation where you were the one that's in the middle of everything, you want to enable others to do that. And so the most important mindset you have to have is, you have to be really good at providing clarity. So people know what's important, and being really good at communicating that, as a leader in a big organization, your words matter a lot, your tone matters a lot, getting people aligned towards a vision and super clear on what's important to the team. That's, that's almost your number one job above all others is making sure that that's super clear to people because you want that accountability and responsibility. And you want those teams to be able to move without having to go seek permission for things, you just want them to move forward with intent to make decisions to move everything in the direction that the customer needs it without having to seek your permission, seek your approval or any of that. So how do you do that? Make things super clear. And you get really good information and visibility coming up from the teams. And so you have to lead through providing clarity, like allowing, not allowing just almost like, the teams have to be accountable for stuff, there's no other way around it, like they need that autonomy, they need that accountability, and they need to get super good at information flow. And, so, that's where frameworks like OKRs, and all of those come in is because it's a method defined to align people so that you can say, here's what's important. Now you go figure out how to achieve that. But I need to know how that's going. I need to know, like, are we getting towards achieving our goals? How are we doing with our metrics? Are we achieve— are we delivering things to customers every day, every week, you know, whatever your goal is. And so you have to get really good at communicating vision, communicating plans, not having your hands and everything that's going on trusting other people to do that, but having good information to make sure that the teams are moving in there in the right direction.

Dan Lines, Host 21:57
You brought up so many good points here. You know, when I was in this situation, I always kind of thought, what I say matters, number one, because I don't get to say that many things now to every single person. So when I am talking, what I talk about the metrics that I talk about matters a lot. And then the second thing is, where can I make the biggest impact possible with my time. And in order to understand those two aspects, you have to have the visibility, the right visibility and the metrics. For example, and I'm going to ask you, you know what, what you're using today, but for, for example, you know, if you're a VP of engineering, and you are having that one on one with a director, or you're having that one on one with a team leader, because you might be doing some of those skip levels, you want to know what's going on. Very constructively if you saw that deployment frequency dip for that team leader. This is a very positive conversation. “Hey, I'm seeing, you know, I'm seeing that the deployment frequency came down here. You know, that's what's important, you know, from me, like, how can I help you hear that we get into some tected? Are you getting too much pressure on the features?” Like, wow, that's an amazing conversation to be able to have with a team leader, you can only have it with visibility, though.

Kirby Frugia 23:25
Yeah, 100%, it becomes about visible output, not output, but outcomes and results. Right? Like, like, that's the thing that you want to talk about. And, you know, you trust that you're hiring good people, like you need that. And you need to, you know, have mechanisms to make sure you are and all that all that stuff. But like, if you make it about the metrics, and you make it about those things, then yeah, absolutely. It's great conversations to have with managers. And it's great to walk into those saying, like, here's some data, like, you know, help me help you what's, what's going on? How can I be supportive? You know, tell them tell me, you know, and even better is if you build the mechanisms that they report on that. So you don't even have to ask that question. Right. So if that deployment frequency is one of the things that you want, as a key metric for your organization, every team should be reporting on that. And if we see it dip, you should be able to read what that dip is, rather than go knock on somebody's door and ask them about it. And so that's, that's where some of that information flow is so so valuable, because it's not only the change in that number from week to week, but it's what is the reason for that change? Did we have an incident? And everybody was jumping on that. And so we didn't have time to write code? Well, you should just know that that's-

Dan Lines, Host 24:38
Is our WIP too high? Too much work in progress?

Kirby Frugia 24:42
Yeah. Yeah. And if that metric is visible, and people are reporting on that metric, they'll see the dip themselves. And I'll explain the dip themselves. Like it's just it becomes almost like a cultural thing, that those metrics are so important that people are reporting on them and they're self diagnosing When there's an issue, and that's what you hired really good managers for is to trust them to figure stuff out. And if something's not working, they're clear about it not working. And they're doing something about it. Like when I think about what a good manager is, it's not that they hit it out of the ballpark all the time like that. Sure if that would be awesome. If everything they did was perfect. Yeah, fantastic. But it's not. And realistically, it can't be in the world that we're in. And so we're what builds trust in me, for with managers, is they tell me how things are going. And they're completely transparent and truthful about that. And if something's not going, right, they're telling me what they're doing about it. And if I hear that, like, this metric went down, here's a reason why. And here's what we're doing about it. I've just now have a super positive opinion of that person. And that's awesome. Like, they got it. And I can trust that they got it. And I don't I don't have to worry about how they're doing because it's like clear to me that they do.

Dan Lines, Host 25:53
Awesome. Kirby, thank you so much for sharing all of that information. This has been an amazing conversation. Thank you so much for coming on the show today.

Kirby Frugia 26:04
Yeah, absolutely. I had a great time. Thanks for having me.

Dan Lines, Host 26:07
If listeners want to connect with you, or for example I know at MURAL you’re hiring a bit. Can you talk about that and where they can go?

Kirby Frugia 26:17
Yeah, absolutely. We are looking for great people, engineers, managers, product managers. I mean, everybody we're hiring like crazy. And so yeah, I'm on LinkedIn, under “kfrugia”, you can also just go to mural.co and look for open positions there. We have lots. If you're a great developer, I guarantee you there's a position for you on our team We're really trying to grow thoughtfully is I hope people realize through this conversation that we're we want to bring great people on board and we want them to have an awesome experience kind of onboarding and feeling like they're part of the team. We're investing a lot in that we're investing a lot in people as part of this. So if you're somebody who wants to work on an awesome product, wants to have a big impact at a growing company, wants to do good work every day in an environment where you can love that love to have you.

Dan Lines, Host 27:09
Awesome. Well, everyone, definitely check out the open hires on Kirby's team and also be sure to join the Dev Interrupted Discord community. That's where we keep this type of conversation going all week long. You can find all of the information in the links below and have a great week everyone!

A Week in the Life of a MURAL Tech Writer

Ben — Wed, 31 Mar 2021 16:51:54 +0000

In this post, we introduce you to two MURAL technical writers on the Developer Experience team. Developer Experience creates informative and inspiring content geared toward developers.

Lauren and Ben shared some of their stories from a week in early March, 2021.

Lauren: Hello! I’m Lauren. This is Ben.

Ben: Ahoy hoy!

Lauren: We’re the technical writers here at MURAL. When I tell someone at a developer-focused tech conference that I’m a tech writer, I invariably get asked, “What’s a tech writer?” Good question. What is a tech writer? Our day-to-day responsibilities include creating how-to guides for using products, video tutorials for navigating a user interface, API documentation for developers, and more. In short, we teach people how to use a product effectively.

Ben and I were the first tech writers at MURAL. Many of us know what it's like being the first (or only) tech writers at a company. We tend to be hired later in a company's development, once the need for a writer becomes apparent. Once engineers start engineering and get closer to releasing a product, they often realize that they need a dedicated wordsmith.

At the Write the Docs conference several years ago, someone asked which tech writers had "fallen into" the job. I was one of the few people in the room who didn’t raise my hand. I’d specifically sought out the position, diving deep into the job. It wasn’t an easy position to dive into since entry level jobs can be hard to find, but finally I got my foot in the door through an internship with Mozilla and the Outreachy program. Ben, how did you get started?

Ben: I had a few years of technical troubleshooting under my belt, but wanted to move into a career that was less about reacting to incoming software and hardware problems and more about creating useful content. As you mentioned, Lauren, being the sole tech writer is a common situation. At my first tech writing job, there was one other tech writer, but he gave his notice a week after I got hired. Then, well ... it was basically just me for 7 years. It's not easy being the only tech writer, but there are some benefits. The only team you have to manage is yourself. And you can get a little more sympathy for content timelines, as everything has to funnel through one person: you.

Lauren: So, what did you work on this week?

Ben: This week, my main focus was our first blog post (for this blog!). And being our first post, we naturally wanted extra focus on research and rewriting.

Our director Jacob suggested that we cover the story of how MURAL completely rewrote its engine using different technology and provided us with a first draft. This story would be a good showcase of how MURAL grew and performed under the pressure of COVID traffic, while sharing the technical details involved in rebuilding our main product engine from scratch. It was a great idea (plus, our director suggested it). We had our work cut out for us.

Taking Jacob’s piece as a starting point, we interviewed some of the developers at MURAL who were involved in the engine rewrite. We asked questions, took notes, asked more questions. We broke down the existing story and rethought it as a longer form technical piece, really homing in on the dev language and reasoning behind key decisions. Within a week, we rebuilt the story from the ground up (like the engine itself) as a much deeper dive. How about you, Lauren?

Lauren: Cool. I worked on the API documentation. This is content that shows developers what our APIs do and how those developers can use them. When consulting API documentation, developers need to see what endpoints are available and how they can be integrated into their own apps, so conveying this information to developers quickly and efficiently is important. That way, they can get started on using the APIs as soon as possible.

Also this week, I worked on writing documentation for integrating Single Sign-On (SSO) into a customer’s MURAL account. SSO integration is such a complex process that most IT admins often work quite a bit with the Customer Success team to get it working. Breaking the setup process into basic, step-by-step instructions can give the reader clarity. It helps them figure out the next step faster so they can get SSO integrated into their MURAL account faster. Again, it’s all about providing efficiency.

Ben: That's the thing I love most about being a tech writer: Helping people to learn and solve problems through clear instructions. Speaking of which, I have to start diving into the next set of API articles. Catch you soon.

Lauren: Ciao!

Photo by Dominika Roseclay from Pexels

Performant Paintings: Building a Canvas Render Engine

Jacob Schatz — Wed, 17 Mar 2021 18:53:29 +0000

Introduction

We founded MURAL in 2011 with one goal in mind: create a feature-rich digital whiteboard, called a “mural,” for real-time online collaboration. As the company grew, our engineering team focused increasingly on streamlining performance. Then the COVID-19 pandemic hit, forcing companies around the world to rapidly adapt to working remotely. MURAL’s popularity surged, and with it came an influx of new and concurrent users. Increasingly large teams were suddenly coworking in MURAL to create ever more complex and varied content, which was slowing our app down. Performance was now our top priority, and we needed to address it as soon as possible.

The Problem

Initially, we developed MURAL to leverage the DOM; as the base programming interface underlying the HTML, it’s familiar to web developers, making it a practical starting point for our application. However, the DOM was not designed to support dynamically changing interfaces comprising a massive number of graphical components — and MURAL users were creating new elements by the thousands. Each sticky note, image, and text box added to a mural further slowed the app’s performance, eventually leading to a bogged down and frustrating experience.

A collaborative design thinking tool that freezes or lags is a collaborative design thinking tool that won’t be used; we needed to update our approach. To address the limitations of the DOM, we decided to go around it and migrate our application to HTML5 canvas. There was just one problem: we’d designed our entire codebase around the DOM.

A Custom Solution for a Custom Problem

Overnight, MURAL had become massively multiplayer, with concurrency and latency issues. In other words, large teams were working together in MURAL and slowing each other down. We needed to enable many users to collaborate simultaneously within a single mural without affecting the app’s performance, a challenge well traversed by the video game industry. Who better to solve game developer problems than a game developer?

Why performance in game development is important

Performance is often highly prioritized in game development; because games are a time-based medium, developers need to make sure their code doesn't slow down the frame rate.

Enter Fede

Fede, a former game developer, was familiar with building products using existing engines but had never built an engine for an existing product. Excited by the challenge, he began researching and planning his approach, starting with “low-level JavaScript.”

What is an engine?

The definition of an engine can get a bit nebulous. For both the purposes of this piece and game development, an engine can be thought of as a set of code libraries that handles low-level code. This code includes rendering, object management, audio, and user input.

Low-level programming isn’t generally associated with web development. When it is, it often means WebAssembly (WASM) is involved. However, Fede ruled out WASM at the time because of its more limited browser support in comparison to JavaScript. So what did he mean by low-level?

Reminiscent of programming requirements in the financial tech sector, low-level JavaScript describes code in which performance informs every choice. For example, Fede pruned out unnecessary prototypal methods like map and reduce, using for loops instead, and structured the code to avoid using first-class functions while still keeping it readable and maintainable. While taking such an ascetic approach isn’t always necessary in general web development, it’s crucial in the case of a massively concurrently used app like MURAL.

What is "C-like" JavaScript?
JavaScript automatically handles garbage collection. Therefore, web developers typically aren't concerned about memory allocation and the speed of method calls. However, when speed is the highest priority, techniques borrowed from low-level languages can powerfully boost performance. Some of these techniques include removing prototypal methods, avoiding passing functions as arguments, and ruthlessly managing memory (e.g., mutating an array in place rather than creating a new one).

Here's an example. Compare the following two programs, which both identify the first character of every animal type that is exactly three letters long:

     // Common JavaScript approach
     const animals = ['fish', 'dog', 'cat', 'giraffe'];
     const firstCharOfThreeLetterNames = animals
       .filter(animal => animal.length === 3)
       .map(animal => animal[0]);


     // C-like JavaScript approach
     const animals = ['fish', 'dog', 'cat', 'giraffe'];
     const threeLetterAnimalTypes = [];
     for (let i = 0; i < animals.length; i++) {
       if (names[i].length === 3) {
         threeLetterAnimalTypes.push(names[i][0]);
       }
     }

Benchmarking these programs against each other shows the second solution runs roughly 50% faster.

The Engines

Our existing solution started as an experiment to transform user input into graphics and render them to the DOM. While this DOM-based approach served us well until now, it was eventually rendered obsolete by new needs. The existing code was also a monolith designed around painting to the DOM, and the complexity of the existing logic to translate MURAL concepts into renderable content made updating and testing the app a fiddly affair. So, in order to migrate MURAL to canvas in a maintainable way, Fede decided to start anew with a custom system consisting of two engines: one to handle rendering graphical primitives like triangles and circles, and one to translate MURAL objects, like sticky notes and gifs, into those primitives.

The Rendering Engine

The rendering engine has one responsibility: send visuals to a target. Unlike the other engine, this one has no handlers for MURAL-specific concepts.

The rendering engine expects the graphical primitives output by the MURAL engine and renders them to the specified “surface” — anywhere murals are visible to users.

Potential surfaces include:

Canvas: used in the MURAL application
PDF or SVG: used when exporting to these file formats
WebGL: not yet implemented, but presents interesting potential three-dimensional applications

The MURAL Engine

The MURAL engine translates user-facing concepts into graphical primitives, by reducing them down to their most basic characteristics, represented by ASTs.

For example, the aforementioned sticky note could be broken down into a colored rectangle, a border, and a text box.

What is an AST?
An Abstract Syntax Tree, or AST, is a structure that describes how data relates semantically to itself, or in other words, where each datum fits in a hierarchy with the rest. For example, an AST of a sentence might be broken down into verbs, adjectives, and nouns. Read more.

Originally, the dual responsibilities of translating MURAL logic into graphical primitives and sending those primitives to render targets were handled by a single engine. So why did we now divide them into two?

Separating the concerns into two distinct engines enabled us to maintain, update, and build additional support infrastructure around each engine with less overhead going forward. This new design enabled Fede to build a test automation system, a key part of the new approach, alongside the rendering engine to ensure it worked as expected and that future changes didn’t slow down performance.

Challenges

Of course, being the best solution for the job doesn’t mean canvas was simple to integrate. In order to encourage iteration and experimentation, A/B test, and because such a significant change could result in huge merge conflicts, new developments were incrementally merged to production, meaning both the old and new approaches had to work side by side until work was completed.

Additional complications with our use case included canvas' complete lack of built-in accessibility support, which we as a company have committed to addressing; and its suboptimal support for rendering text at the subpixel level across devices and resolutions. Text handling also happens to be under-described in the CSS specification, meaning, for example, that each browser is free to decide when and how line breaks occur. While we could have built workarounds, they would have tacked on significant overhead for testing and maintenance, especially in today’s evergreen browser landscape, and our users create murals on a cornucopia of browsers.

Fede chose to track his development progress with Chrome, because it represents 80% of our user base and leverages the GPU to accelerate canvas renders. To ensure all users had a smooth user experience, he also regularly tested and built across other browsers and devices. These manual tests included devices running Linux, Windows, macOS, Android, and iOS at a variety of hardware specifications, as our latency problem was a hardware issue, not a network one.

By doing so, he discovered and addressed additional browser-specific restrictions, such as Safari’s variable hardware limitation for renderable assets — Fede addressed this by offloading some of the rendering responsibilities to an off-screen canvas whenever the full mural is visible, which slows down scrolling at that zoom level in exchange for enabling the application to continue running smoothly.

Outcomes

After migrating from a monolithic DOM-focused architecture to our custom canvas rendering engine, we improved performance (as measured by the percentage of frames at 30fps or higher) by 80%. When Fede ran into a character painting issue in Chrome during the course of development, he contributed to its resolution by submitting a detailed report with solid reproduction cases.

Because we separated the rendering process from the application-specific logic, they were no longer intertwined. The codebase became more maintainable and testable with automated end-to-end and visual tests, and by creating a system that can render to multiple targets, we opened up new opportunities for both internal and external developers to leverage MURAL features in a variety of exciting ways.