Everything in software development is a TOOL & NOTHING is a rule or a religion
For the Rangers Treasure Map, we had an amazing development-focused sprint where we all dug in and got stuff done. The sprint after that became minor feature work but mostly focused on bug fixes and UX improvements. This meant that for each item, we needed to identify the fix and apply it—the problem was that some of those fixes couldn’t easily be applied with our existing “tools.”
In this case, tools refers not to Visual Studio or TFS, but rather to our design pattern (MVVM) and the Microsoft guidelines. Let’s look at three examples where we came up against those:
Keyboard support
The first issue was that keyboard support was bad for our app—you wouldn’t be able to navigate easily through many of the levels because of it. Windows is normally thought of as mouse and touch, but there’s a lot of keyboard support and keyboard guidance, so for us, it was vital to give an amazing experience with this too.
The core problem was our way of using SelectedItem on our lists for navigation, which works great for mouse/touch but doesn’t work for keyboard. So, with the very limited time left, what could we do? We had three options:
- Leave in bad keyboard support.
- Develop a ton of additional code to allow the view to work with this model or change the view somehow—basically allowing us to keep pure MVVM.
- Break the MVVM pattern to solve this.
Option one wasn’t even an option for us, so that left options two and three. Since we had limited time and other issues, if we went with option two, we would’ve had to drop other parts or leave other issues unfixed. The choice really was to break the pattern and have the code-behind for the view handle calling the view model for the navigation.
This isn’t really a smart idea, but it comes from people like Sam Guckenheimer—he wrote in his book that this is the standard tetrahedron for software development: time, money, features, and quality. Since time and money for us were not movable, we had to choose between quality and features.
At the end of the day, focusing on what’s important and ensuring what we ship is awesome for the user—even if the codebase has a few ugly spots—meant we broke MVVM. You know what’s awesome here, though? Windows development allows it because not every scenario is a perfect fit for a pattern every time.
Aside: I do hope that in our v3 release, we’ll get a whole sprint, or two, to do refactoring—which will include moving this to the option-two solution and making it better for unit testing!
Right-click—show app bar
Another example: if you right-clicked a list item, the app bar would not show (because the item grabbed the event, and the page never got it). Here, the solution was once again to go to the code-behind. However, I don’t personally feel this breaks MVVM. I acknowledge we could have found an MVVM way to do it, but this sort of experience is purely view-related, so the code-behind for the view is the right place to handle it.
I know a lot of MVVM proponents believe all code-behind is evil, but really, there’s no evil here—these are just tools to make our lives easier and ship better software. We should use them, but not believe in them.
Alt+Left
The final example is a bug with pressing Alt+Left, which the Windows guidelines state should take you back a page. However, it breaks if you use Alt+Tab to get to the app (the Alt key is seen as stuck then, and just pressing Left will make it go back). For us, the solution here was to not implement this guideline.
The experience of our users must triumph over all guidelines, even those from Microsoft.