Welcome to the twelfth edition of The Catch Block!
Judicious Defaults and the Two-Finger Swipe
On my machine, a two-finger swipe on the mouse pad causes the current window to scroll. Two fingers sliding upward scrolls the page downward, and vice-versa, similarly to how it works on a mobile device. It's supposed to represent, I think, physically moving or "dragging" the page relative to your field of vision.
Which is why it came as a bit of a surprise that my kids' Chromebooks behave in the opposite manner: a two-finger swipe upward scrolls the page upward, and a two-finger swipe downward scrolls the page downward. This is more like saying "go that way" using two fingers.
This came as quite a bit of a surprise to me, and I still don't have the hang of it. But the kids are used to it by now, and in fact, using my machine has become a source of frustration for them. It's more natural for them to think the motion means "go that way" because that's all they've ever seen.
I'm sure there's a setting on the Chromebooks that makes their mousepads behave in the same way as my machine's, but the fact that I'm even thinking that says a lot about what I expect and what my kids expect. I expect it to work like every other machine I've used, to conform to what my past experience says it should do, and so do they. We just don't agree on what the default behavior should be.
One of the trickiest things we deal with as software developers is the judicious and insightful use of defaults. The default on my Windows device is that a two-finger scroll behaves in the "drag the page" manner. This probably resulted from thousands of hours of testing, prior experience, and knowledge of audience expectations. Or, possibly, they flipped a coin. What's interesting is that the Chromebooks, with presumably a similar amount of information, arrived at the opposite conclusion (the "go that way" behavior).
Defaults are, if you think about it, powerful. The way something works, as described to a person with no prior experience with that thing, thereby becomes the way it should work for that person; it creates their preconceptions. This is why determining what the defaults are for systems you design is so important, and should be dealt with carefully: you are crafting expectations for your users, expectations you will need to fulfill.
Spend some time on your defaults. Consider why you think they should be the defaults, and attempt to determine if your users agree with your assumptions. Examine your own biases, expectations, and experience, and see if your users share them. Defaults are powerful, and dangerous if set incorrectly; treat them as such.
Previews and Announcements
- Introducing YARP Preview 1 (Sam Spencer) - YARP is a project to create a reverse proxy in .NET.
- Introducing Project Tye (Amiee Lo) - This project aims to make microservice development, as well as automated deployment of such systems to Kubernetes, more easy.
- Using Visual Studio Codespaces with .NET Core (Tim Heuer)
- Tackle Big-O Notation in .NET Core (Camilo Reyes)
- How easy is it to build a Marvel search engine with Blazor? (Jon Hilton) - This is very similar to the post I released earlier this week. More Blazor goodness!
- BackgroundService Gotcha: Startup (Stephen Cleary)
- The Art of Gathering Remotely (Pam Selle)
- .NET async/await in a single picture (Konrad Kokosa) - I personally think this concept is way too complicated to explain in a single picture, but it is interesting to see.
- Unit Testing in ASP .NET Core 3.1 (Shahed Chowdhuri)
- Understand Searched Locations For The Razor View Engine And ASP.NET (Khalid Abuhakmeh)
- Fixing Adsense Injecting 'height: auto !important' into scrolled Containers (Rick Strahl) - I see someone else is getting pretty annoyed with Adsense lately.
- Remembering Why Agile was a Big Deal (Jeremy Miller)
- Life, part 11 and Life, part 12 (Eric Lippert)
Catch Up with the Previous Issue!
Thanks for reading, and we'll see you next week!