Small Details, Big Impact

Talks

Yehuda Katz

#software-development

#open-source

#ruby-on-rails

#product-development

Small Details, Big Impact

by Yehuda Katz and Liz Baillie

The video titled "Small Details, Big Impact" by Yehuda Katz and Liz Baillie at RailsConf 2016 focuses on the significance of small user experience details that contribute to a product's success. The presenters explore how meticulous attention to minor components can enhance user engagement and satisfaction.

Key points discussed include:

- User Experience as a Narrative: They describe user experience as a story, emphasizing the need to guide users smoothly through applications, preventing unexpected and confusing journeys.

- Vignettes Illustrating User Experience Challenges: Katz and Baillie present four vignettes highlighting challenges faced while improving Skylight, such as visibility of data metrics and user authentication paths.

- Case Study on Agony Index: They share how they improved the display of the Agony index in Skylight, transitioning from invisible to visible metrics by changing terminology from RPM to ‘popularity’ and refining the visual representation, demonstrating the profound impact of clear communication on user understanding.

- OAuth User Pathways: They discuss the intricacies of integrating OAuth for GitHub authentication and the importance of providing seamless user experiences, even with edge cases, such as existing accounts linked to GitHub. Baillie highlights strategies to ensure that users are informed and guided throughout the process without confusion.

- Rust Utilization: The presenters talk about adopting Rust for performance-critical parts of their application to enhance data collection without slowing down the user experience, showcasing Rust’s advantages in terms of reliability and safety.

- Importance of Names: The video also emphasizes the significance of correctly addressing users by their preferred names to foster respect and connection, explaining how Skylight transitioned from using first and last names to incorporating nicknames in user communications.

The overarching conclusion of the presentation is that while it may be easy to overlook details during development, these components are crucial in crafting an engaging and user-centered experience. Their commitment at Skylight to focus on these small details leads to significant positive impacts on user satisfaction. The emphasis on continuous improvement and thoughtful design processes is a vital takeaway for developers aiming to elevate their applications’ user experience.

Katz and Baillie encourage their audience to remain mindful of these details in their own applications, as successful products reflect careful attention to the experiences of their users.

00:00:11.160 Okay, so today we're going to talk about small details and their big impact.

00:00:16.320 The general topic area here is that it takes a lot of little details to get a product to work well. It's actually pretty hard to give a talk on any of those details because, on their own, they're pretty boring.

00:00:29.679 So, we decided to put together a talk that includes a few vignettes that hopefully motivate you to think about the small stuff in your own applications, and also give you a sense of what we think about while working on our product.

00:00:42.239 First of all, I am Yehuda Katz, often known as ycats. I work on a lot of open source projects, perhaps too many, but I absolutely enjoy it.

00:00:54.079 And you probably know me from some of those projects. My name is Liz, and I'm known as infinite math on Twitter. I used to be a cartoonist for about ten years before getting into engineering.

00:01:06.400 I have published about five graphic novels and just started getting into programming a year and a half ago, and I've been working at Tilda on Skylight for about three months.

00:01:18.040 Let’s talk about the concept: Death by a Thousand Cuts or that big things come in small packages. Every day you make a choice—sure, your app works and it does its job, so your users are technically getting what they paid for—but you can do better. We can all do better.

00:01:36.520 User experience is a story, like a movie; you know exactly how you want it to go from beginning to end. The user signs up, logs in, and interacts with your landing page. But what if they click on something unexpected? What if they take a wrong turn?

00:01:51.680 They can easily end up in a 'Choose Your Own Adventure' style scenario that you never planned for. Suddenly, they might find themselves on the Vampire Express to Terror Island. Weird things happen, and users end up in unexpected places. It's your job to ensure they're guided through seamlessly without them realizing it was a weird place to begin with.

00:02:25.000 You don’t want your user experience to resemble that scene from Dune, where Patrick Stewart carries a pug into a laser battle for some reason. You want it to feel more like Gandalf riding in on a bunch of eagles to save Frodo and Sam at the peak of Mount Doom.

00:02:48.920 Sure, it may not make a lot of sense if you think hard about it, but while you're in the moment, you think, 'Yeah, of course, this is what happens.' That’s a good user experience.

00:03:13.440 Today, we’re going to talk about four different vignettes, and the first one involves what seems like a very small problem.

00:03:20.280 But before diving into that, I want to take a moment to explain what Skylight is, to give you context.

00:03:27.680 This is Skylight; a few months ago, when you logged in, you would see a list of your endpoints sorted by something we call Agony.

00:03:38.840 Agony basically indicates things we think are probably good for you to work on. If you have an endpoint that doesn't get hit often, we don't care as much if it's slow, but if you have an endpoint that gets hit a lot, any slowness matters.

00:03:51.680 So we try to combine those into an intuitive experience. We also have these little red icons that mean there are some database or memory problems, with further details provided. This is the experience you should definitely check out at our booth.

00:04:05.360 On this page, you can see a bunch of numbers, but the Agony index used to be invisible; it just formed the way the default list was sorted. This was frustrating for users, as they could understand Agony but had no way to click and sort by it.

00:04:18.320 We realized we needed to make that more visible. In the column labeled RPM, for example, users were confused by what it meant. RPM stands for Requests Per Minute, something learned quickly, but those unfamiliar with the term often found it unclear.

00:04:36.480 People kept saying that there were too many values like 0.01 or 0.03, which seemed to have the same significance. Initially, we determined that if users didn’t care about the difference, we might as well display everything as 'less than one' instead.

00:04:49.680 However, that only created a slew of 'less than one' values. This problem took a long time to figure out, which I want to discuss further.

00:05:06.479 Our great designer recognized that saying 'RPM' was the core issue. He suggested we change it to 'popularity.' That's great, but when we looked at how to visualize it, he proposed using a filled bar to represent the popularity of each endpoint, where not very popular ones would have an empty bar.

00:05:24.120 We looked at this design and felt it encapsulated what we wanted to convey, so we decided to ship it. Skylight uses feature flags to gradually roll out changes; we tested this on our app, and while 'popularity' was indeed better, it wasn’t what we truly desired.

00:05:36.760 Now, let’s explore why that happened. Initially, we assumed we were dealing with a normal distribution—a bell curve pattern. In essence, most data points cluster around the mean, with fewer points falling at the extremes. For instance, a ten-foot tall person is as rare as a zero-foot tall person.

00:05:54.760 While that distribution clears up a lot of issues in the physical world, many things actually conform to a log-normal distribution, which doesn’t mimic the bell curve taught in school and can be counter-intuitive.

00:06:10.840 This distribution appears in various contexts, such as income distribution, survival rates, city population sizes, and commute distances, all exhibiting this surprising similarity. If you look at your Skylight endpoints, you might notice these patterns.

00:06:26.640 It’s common enough that a performance company literally named itself log-normal to highlight the discrepancy between this and the traditional bell curve. Our designer had the wrong intuition, thinking we were analyzing a bell curve when we were really working with something else.

00:06:38.880 The first solution that comes to mind when encountering this issue is to rescale the numbers using a logarithmic scale. However, this poses an issue because users tend to think that if a bar is twice as big, it signifies twice as much popularity.

00:06:51.360 The concept of pre-attentive visual processing explains how people instinctively react to visual stimuli, making it important for the designers to consider how users perceive size while processing information quickly.

00:07:08.839 Our designer, for instance, initially used a bar on the left that was filled red. It was easy to identify because the visual element was strong, while the right side took longer to recognize; it lacked a distinct feature like a filled versus empty variable.

00:07:22.760 The keywords are visible, weakness versus strength. Users had the expectation that doubling the size of the ink would correspond to double the popularity, leading to confusion and inaccurate interpretations.

00:07:36.120 Additionally, when employing a slippery metric like popularity, it’s important to consider if that truly conveys much meaning. This icon provides general-aspect meaning, which is flexible and difficult to misinterpret.

00:07:56.760 For Skylight, as a Rails profiler primarily targeted at developers, we gave our users the option to log in using GitHub, allowing for a quick and simpler sign-in process.

00:08:10.760 The users would click 'Sign in with GitHub,' which leads them to a page where they authorize the app, after which they are seamlessly returned to the platform.

00:08:28.880 While most users enjoy this seamless experience, we still wanted to address the less-than-happy paths.

00:08:41.959 What is the happy path? It’s when the user connects their existing Skylight account to GitHub by first signing in with their email and password, heading to the settings page, and clicking 'Connect to GitHub.'

00:08:54.239 They would then see the connected account information, including their GitHub username, and could sign in with GitHub moving forward.

00:09:05.840 A common issue identified is that users often forget whether they originally signed up with an email/password combination or GitHub. To reduce confusion, we now display the connection information on the account settings page.

00:09:30.480 If the GitHub account they authenticate with is already linked to a different Skylight account, we will notify them with a message at the top of the screen.

00:09:45.039 What happens in edge cases, specifically for users who have an existing Skylight account that isn’t yet connected to GitHub yet? When they click 'Sign in with GitHub,' we redirect them to an interstitial page.

00:10:01.759 That page contains a pre-populated email form with the email from their GitHub account, guiding them to enter their password upon signing in.

00:10:18.320 Once signed in, we automatically connect their account to GitHub, allowing them to sign in with GitHub easily.

00:10:35.160 As for users who already have a Skylight account when clicking 'Sign up with GitHub,' we don't want to treat them as new users.

00:10:52.840 Even if they clicked sign-up, we still log them in as if they signed in, but we make sure to confirm their identity. After all, it's conceivable that they intend to sign up, but their coworker might be logged into GitHub on their computer.

00:11:12.560 If that's the case, we casually inform them who they're signed in as, with a helpful welcome message at the top of the screen. If they aren't that user, they can sign out and sign in with their own GitHub account.

00:11:36.520 For cases where a Skylight account is linked to a GitHub email, clicking 'Sign up with GitHub' leads to an interstitial page with an error message stating that the email is already taken.

00:11:53.720 In this scenario, they would need to sign out of GitHub and sign in with their account.

00:12:05.680 Implementing OAuth was a challenge. GitHub's configuration allows a single redirect URL, and it doesn’t differentiate between a user signing up or signing in.

00:12:20.040 We had to find ways to support all these different user pathways while still maintaining clarity.

00:12:34.160 Interstitials are generally viewed as detrimental; we all hate those pop-ups enticing us to download an app when we're on our phones.

00:12:50.440 Thus, we made a decision to include them upon realizing we were choosing between an awful experience for a few users or a slightly awkward one for many.

00:13:11.600 It's essential we don't divert users intending to sign up into someone else's account—nobody wants that.

00:13:26.799 Meanwhile, we aimed to minimize the typical frustrating experience of interstitial pages. Anything to ease the burden on users was our guiding principle.

00:13:41.760 If GitHub provides an email address, we want to expedite logging into their existing account by auto-filling that field. If they need to enter their password, then focusing on that field should be a priority.

00:13:55.519 Let’s transition and talk about Rust. At Skylight, we utilize Rust, often mistaken for a trendy choice.

00:14:06.720 When we began using Rust, it wasn’t the hyped technology, and many had apprehensions about it being a new and scary language.

00:14:23.680 However, we had solid reasoning behind using it. The primary challenge was collecting data efficiently from your application for analysis.

00:14:39.920 The key was instrumenting the application without impacting its performance.

00:15:01.720 If an agent slows down the application it's supposed to analyze, we have already failed.

00:15:14.720 Thus, it’s vital for everyone creating these tools to prioritize maintaining performance.

00:15:28.799 The natural inclination is to simply write the agent in Ruby, given it's safe and included in the Rails environment by default.

00:15:47.520 Ruby is useful for collecting baseline information, such as rendering times; however, it tends to slow down when grabbing fine-grained information.

00:16:05.920 In particular, we needed to capture detailed data on memory allocations within your application, requiring connection to every allocation.

00:16:21.360 Just as valid an option would be coding in C. However, placing performance-critical code into your application raises concerns.

00:16:36.280 The risk of errors causing application crashes is high. Even seasoned C programmers can struggle with reliability and security.

00:16:53.480 C++ poses a similar issue, raising fears about long-term maintenance and unexpected crashes losing users.

00:17:10.000 We suspected executing many components in C or C++ could create potential user anger and damage our relationships.

00:17:21.520 Around this time, Patrick Walton from the Rust team published a blog post indicating that garbage collection isn’t necessary, as Rust’s ownership model suffices.

00:17:39.720 I discovered this in October and initiated the task of rewriting the critical sections of our application, focusing on serialization of traces and sending to the server.

00:17:58.480 After a couple of weeks, I saw good progress and ended up shipping a functional segment written in Rust.

00:18:14.520 We didn’t undertake a complete rewrite of the agent. Most functionality should remain in the Ruby layer, but transitioning performance-critical aspects to Rust has proven beneficial.

00:18:30.480 Since implementing Rust, there have been no crashes in the agent attributable to our code, showcasing the stability and safety that Rust provides.

00:18:42.769 This stable nature is a remarkable feature of Rust, where a compilation event confirms that the code is sound, mirroring the security risks present in Ruby and C.

00:19:02.240 The Rust 1.0 blog post underscored stability through various factors: memory safety without garbage collection, concurrency without data races, and abstraction without overhead.

00:19:15.760 Each of these attributes feels like contradictions, yet work within straightforward primitives.

00:19:30.720 Ultimately, Rust empowered us to develop code that's efficient without the dread of crashing, a crucial value during our operations.

00:19:46.160 We could ship our allocation tracing feature confidently when many thought it unfeasible.

00:20:03.520 Now, Godfrey is delivering a talk on Helix, a binding layer between Rust and Ruby, which is indeed exciting, so be sure to check it out.

00:20:19.679 Next, let's talk about names—names hold profound significance.

00:20:31.920 Correctly addressing someone by name fosters respect, and when someone introduces themselves, people usually attempt to pronounce it right.

00:20:52.720 But names can vary; individuals might prefer names that differ from their government IDs. Nonetheless, official documents must reflect their legal names.

00:21:06.840 Changing names may stem from innocuous reasons or serious circumstances where addressing someone by their legal name poses safety risks.

00:21:18.480 Thus, beyond just respect, valuing your customers should drive you to address them by their chosen name.

00:21:36.840 For me, being called Elizabeth instantly signals a sales pitch, prompting me to hang up. Services that automatically use full names can feel disconnected.

00:21:52.240 When emails awkwardly address me as 'Greetings, Elizabeth Bailey,' I feel the same disconnect, making the service appear robotic.

00:22:09.360 No one wants faceless communications from a corporation, especially when your team cares deeply about the product.

00:22:26.720 Thus, how do we address names at Skylight? Initially, we collected first and last names and addressed emails using only their first names.

00:22:43.520 This worked sufficiently in many situations but didn't accommodate those with alternative names, as over half of our company utilizes names not on their IDs.

00:23:04.240 Many of our Skylight email subscribers rely on these updates about our projects and conference participation. We cannot risk alienating customers by using incorrect names.

00:23:20.640 Thus, we transitioned from first and last names to full names and nicknames; all email communications will now utilize the nickname while still keeping full names secure for billing.

00:23:43.680 For existing customers, we concatenated their first and last names for their full name in database records and assigned their first name as the nickname.

00:24:04.520 To track and confirm chosen nicknames, we added a Boolean field called 'nickname confirmed,' marking existing users as false until verified.

00:24:21.840 This improvement is critical, but also lies in how we manage these names in the user interface.

00:24:35.920 Upon signing up, we ask what name users prefer, asking permission to call them so.

00:24:50.360 If they accept, we confirm their nickname. Otherwise, they can input a different one they'd like to be addressed by.

00:25:11.480 If someone doesn’t initially input a nickname or refuses to enter one, we keep track and make it clear later that they can opt for a new nickname.

00:25:33.520 After saving and confirming a nickname, another minor wording change is that we say 'we will call you' versus 'can we call you?' for a subtle but thoughtful distinction.

00:25:51.560 If a user hasn't confirmed yet, we show them the nickname and ask if they're alright with that name, allowing input during the signup process.

00:26:10.240 This feature benefits users who create accounts via GitHub as well. If they don’t confirm initially, an additional layer through the settings page exists to remedy that oversight.

00:26:27.920 Developing this user interface introduced challenges, as portions of it are built with Rails views while most run on Ember.

00:26:44.640 The signup page is currently a Rails view. When I first began programming, I primarily learned Ruby on Rails before diving into Ember.

00:27:08.240 At the time, I found myself paired up with Rocky, with both of us new to Skylight.

00:27:21.520 Neither of us had built anything in plain JavaScript, but our perspectives complemented one another in navigating this challenge.

00:27:42.760 We needed to implement functionality to debounce typing, giving users time while entering their name to avoid showing inputs until completion.

00:27:59.840 Without debounce, the user would see each character as they typed, leading to an unpleasant experience.

00:28:18.080 Debounce seemed straightforward but, surprisingly, is not native to JavaScript. We ended up creating our own jQuery debounce plugin.

00:28:36.560 On top of that, certain methods like trim are not universally accessible across all browsers, prompting us to polyfill JavaScript's string.trim.

00:28:56.520 It's critical to remove surrounding whitespace for accurate input presentation. Many applications neglect this, leading to frustrating experiences.

00:29:13.440 Overall, we prioritize getting users the correct name upfront, allowing for easy adjustments whenever needed.

00:29:34.360 In closing, while developing applications, little details truly matter.

00:29:46.320 Focused attention on the small components can fade in the busyness of technical work, like selecting libraries, structuring migrations, or other components.

00:30:07.679 You're ultimately crafting an experience for your users.

00:30:24.720 As Liz mentioned, creating an app resembles constructing a movie—it's essential to focus on creating an enjoyable user experience.

00:30:45.440 Making an amazing movie requires fastidious attention to every detail. Pixar's animators will dedicate days to perfecting a single second.

00:31:02.560 There's a marked difference between applications developed with care and those where the intricate details haven't been considered.

00:31:20.480 You can easily downplay aspects like choosing names, but these elements significantly affect the overall experience.

00:31:37.440 Take time to determine what happens when a user presses 'Sign up' with GitHub—indeed, the user experience should differ based on context, and such nuances matter.

00:31:55.440 As users, we notice these distinctions between applications—those that are attentive to detail inevitably succeed.

00:32:09.760 We are grateful to provide this glimpse into our daily routines at Skylight—spending time on the little things results in positive impacts.

00:32:23.440 Our periodic development journal shares insights created by our engineers, highlighting their experiences working on Skylight.

00:32:38.080 If you’re interested, please sign up for our emails, as they provide valuable insights—just remember, you can do so for free.

00:32:54.880 We initially anticipated only a few sign-ups but were happily surprised to see hundreds engaged in our journals.

00:33:10.080 Sharing work experiences enhances the community atmosphere. Don't underestimate the impact that discussing these insights can have.

00:33:25.840 Thank you all!

RailsConf 2016