For the Rangers Treasure Map, we had an amazing development focused sprint where we all just dug in and got stuff done. The sprint after that became minor feature work but mostly just work on bug fixes & UX improvements. This meant that for each item we needed to identify the fix and apply it – the problem is that some of those fixes couldn’t easily be applied with our existing “tools”.
Tools in this case, refers not to Visual Studio or TFS – in this case it refers to our design pattern (MVVM) & the Microsoft guidelines. Let’s look at three examples of where we came up against those:
Keyboard support
The first issue was the keyboard support was bad for our app – you would not be able to navigate easily through MANY of the levels because of it. Windows is normally thought of mouse & touch – but there is a lot of keyboard support & 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 do 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 some how – 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 & three. Since we had limited time & other issues, if we did two, we would’ve had to drop other parts or leave other issues unfixed. The choice really was to break the pattern & have the code behind for the View handle the calling the View Model for the navigation.
This isn’t really my a smart idea, it comes from people like Sam Guckenheimer wrote in his book, this is the standard tetrahedon for software development: time, money, features & quality. Since time & money for us are not movable – we have to chose quality or features.
At the end of the day, focusing on what is important, making sure what we ship is awesome for the user, even if the code base has a few ugly spots in it – meant we broke MVVM. You know what is awesome here though? Windows development allows it, because not every scenario is a perfect fit for a pattern every time.
Aside: I do hope in our v3 release we will get a whole sprint, or two, to do refactoring's, which will include moving this to the point two solution & making it better to unit test!
Right click – show appbar
Another example is that if you right clicked a list item, the appbar would not show (because item grabbed the event & the page never got it). Here the solution is once again, to go to the code behind. However, I do not personally feel this breaks MVVM. I acknowledge we could’ve found a 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 do this.
I know a lot of MVVM people believe all code behind is evil, but really, there is no evil here – these are just tools to make our lives easier & 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 and 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 is to not implement this guideline.
The experience of our users MUST triumph all guidelines, even those from Microsoft.