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:

1. Leave in bad keyboard support.
2. 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.
3. 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.

References

• ALM Readiness Treasure Map (Table of Content) TOC Post
• ALM Readiness Treasure Map Windows Store App

Today I got to present to the ever amazing audience at JSinSA (it is one of my favourite conferences, so I may be biased). The talk I gave was very simple: Visual Studio, it is THE BEST tool for web developers, regardless of what technology you use. So if you use ASP.NET, PHP, Ruby, CoffeeScript etc... it does not matter – Visual Studio is right for you!

If you attended and are looking for the slides, demo bits, or a script of the demo – have a look below! For those who couldn’t be there, I have since done a recording of it to YouTube, which is also below!

YouTube

Slides

In the short video below I cover how you can configure Nuget package sources to either local copy, which is great for backups when doing a presentation which relies on Nuget, or the the cache, which can provide an emergency store for recent packages if you have no Internet access.

If you are logging into TFS Service with your normal account and are suddenly seeing a prompt to “Create a Visual Studio account”, where is nothing to fear. It is just a Terms & Conditions update that is BADLY labelled.

Click create and go on with your day

Seriously your mobile strategy can exclude iPhone, you don’t need to support that platform – it isn’t really that important. 

Before you move to the comment to call me a Microsoft kool-aid guzzling fanboy, let me explain. I see three reasons that fuel the myth that iPhone is an important platform and they are:

• Lies, Damned Lies & Statistics
• The FNB Effect
• Development is hard for these other platforms

Lies, Damned Lies & Statistics

I have been totally guilty of helping this cause of the myth prevail by standing in front of thousands of Windows Phone 7 developers & showing how Gartner & IDC both predicted that Windows Phone would grow to 2nd place behind Android by 2015, pushing ahead of iPhone – which at the time the stats said was the number two smart phone OS.

The truth is, Windows Phone is ALREADY ahead of iPhone. It also leads Android. Really, it does – maybe not world wide or even in your country, but in South Africa it does.

In South Africa the picture is very different, Symbian leads by a massive margin (44%) followed by BlackBerry (15%), then Windows Phone (9%), forth place is Android (8%) and last is iPhone (4%).

The problem is we look at these analysts and international reports and assume they apply to us – they do not and should not influence our understanding of our market.

The FNB Effect

First National Bank, the bank that launched the first transactional smart phone app in South Africa & changed how we look at banking and did a lot to jump start app developed from companies. What platform did they launch on? iPhone & much (much) later an Android app was launched too – still no Windows Phone, Symbian or Blackberry app (or as I see it 68% of the market). Since there the number of times I have heard competing banks & companies in other industries start their mobile strategy with “FNB has iPhone – our customers expect iPhone”.

Those people are idiots. Their customers do not expect iPhone because FNB had an iPhone app, they expect an app for THEIR phone.

There are two sub-points to also consider with this factor which are vitally important in understanding why FNB’s choice of iPhone worked for them & why it may be right or wrong for your mobile strategy.

Know you customers

This is as much about the FNB effect as it is about statistics – looking at the statistics even for a country is almost completely flawed too. You need to look at what your customers have. To help explain this, let’s compare two companies who both produced an iPhone app:

• SABC
• Discovery

For Discovery it totally makes sense to have an iPhone. Private health care & life insurance are expensive and really only the top portions of the country can afford it. That is the same market who buys iPhone. You market has iPhone, you build iPhone.

SABC, like so much at the national broadcaster, needs to appeal to the broad population. So they should be looking at the total market share and building based on that. The issue makes less sense when you think that DSTV’s news channels & eTV’s news appeal to the upper LM groups more – so in reality SABC SHOULD be targeting the lower income groups who buy cheap Symbian & Blackberry phones. They didn’t & it is just stupid of them.

In fact they should have a mobi site since that would allow even broader reach – but of course that doesn’t quiet work either…

FNB app isn’t special – their marketing dept. is

The FNB app isn’t special. At best the app idea was a just smart business seeing what the rest of the world is doing & getting on the band wagon first. So why do we care? Because FNB’s marketing dept. is so damn amazing, they made it an important point in many of their adverts. They used it to highlight how far ahead they were & how slow & old their competitors are. They also used it in an aspirational way to appeal to lower income groups: One day I will be rich & own an iPhone. Then I want to be at a bank with an app.

All four of the major banks in South Africa have apps for iPhone now & still we only ever talk about FNB. This isn’t because theirs is the best – but because they sold their app the best. They own the mind share.

A second aspect to this story is FNB have made it ridiculously easy to get an iPhone with them – which firstly pushes up their stats of which platforms are important and secondly re-enforces the marketing stories: Wish your bank had an app? Wish you had a phone that could run an app? Come to FNB, we make it easy to have both.

Development is hard for these other platforms

The final contributing factor to myth that iPhone is the first port of call, is from the prima donna’s involved in these strategies. You may know them as software developers. These folks will tell you that development for Symbian is tougher than milking a rattlesnake & development for Blackberry is tougher than getting a date with Megan Fox. iPhone, Android & Windows Phone development is easy by comparison and so you can get it a lot cheaper/quicker/better.

That is, naturally, complete bull shit. It is easier because these are sexier platforms and because of that

• they don’t want to feel like an idiot when sharing what they do with their friends – who knows? Megan Fox maybe there and who will she date the iPhone dev or the Symbian dev? (I call this embarrassment tax – you pay extra for a developer to be embarrassed)
• they likely have the devices today and understand the platforms already because they played with it in their free time. I am talking about platform & not development. Understanding why something works on a platform is just as important as learning to code for it.
• they like the fact they do not need to learn new languages/tools. Android & Windows Phone developers are especially bad here since it is the top most common development platforms .NET & Java.

In reality Symbian is a marvellously stable & well developed platform with many tools. In fact, if you don’t need a transactional app, they have tools that are completely code-less (i.e. everything is done visually). I haven’t ever worked with Blackberry myself, so I can’t comment on their tools but I have been on projects where someone else did BlackBerry work & I did Windows Phone.  In those scenarios we were mostly matched for development performance and any difference was not because of the tooling.

Lastly, with tools like PhoneGap & Worklight getting better all the time, the need to native apps is getting REALLY small – you can easily use web development skills with those tools to create hybrid apps for BlackBerry & Symbian. There seems to be this belief though that if you go hybrid you go all in – which is totally bullshit too. I can totally see a native app built for your premier clients & then using hybrid, which may be a second rate experience, to clean up the rest of the market share platforms have in your customers.

Summary

In reality iPhone maybe the right choice to go for. The issue is there are so many people who do not apply their minds to what they really need. Rather these lazy people who make the decisions or feed information into the decision makers just regurgitate the bullshit that is out their. What I have hoped to highlight is there is no one right strategy but with a bit of thought & investigation you can find the one that is right for you and more importantly, your customers.

In my sabbatical to Redmond I learnt there are two departments at Microsoft who you never want to hear from because it is never good, one being HR and the second being Legal. On the 13th May I got an email from Microsoft’s legal dept., and it wasn’t good.

Microsoft after 60 000+ downloads, almost 6 months & even getting some mail from members of the Bing team, decided that my application, Bing my lockscreen, violated their copyright (It did, I am not disputing that) and so it was to be suspended until it was fixed.

So in the last two updates I have done the process to rename a Windows Store App and I am proud to notify you that the application is now called Amazing Lock Screen & is available in the store again!

In addition to the rename, I have made two UI changes in the latest release:

• Hero Image: The latest image is shown double the size of the previous ones & shows the image copyright text on it (similar to the Bing web site does).
• AppBar: The AppBar (the bit at the bottom of the Window) is now hidden by default, like most other Windows Store apps. The reason for the changes is I think the users are getting used to the Windows Style so I do not need to prompt as much as when Windows 8 was launched.

For more posts in this series, see the series index.

The above video shows the great XAMLSPY tool which is a massively helpful tool when working with any XAML based application, like a Windows Store app. XAMLSpy allows you to get insights such as performance & memory usage but for me the real value is when you add it to the application you get a set of small tools to use in the app to help identify and navigate the XAML.

Once you have found the piece of XAML that is causing issues, you can test out your ideas in real time using the real time editor functions which really speeds up development. This is a must have tool for those who really have pride in their craft!

For more posts in this series, see the series index.

This post is both a development snack, i.e. something I think you should know to build better Windows Store apps, as well as being part of the Treasure Map transparency, which are meant to show you how we built a real Windows Store app.

Size Matters

Lab Rat

In web development, there is often a concern to get the download size of the page down & there are plenty of tools to help with this (Visual Studio has a lot for CSS & JavaScript) but when we get to app development, size isn’t always as big a concern.

Windows Phone development made 20Mb an important limit, since that meant the download could go over 3G rather than requiring WiFi – this is why my Lab Rat comic book for Windows Phone is 17Mb in size. I made a very conscience choice to ensure it would fit under 20Mb.

Windows Store apps don’t have a similar limit to Windows Phone – so when I was recreating Lab Rat for Windows 8, I just went with the highest resolution images I could so it would look great. This resulted in the download being 225Mb!

Treasure Map

With version 1 of the treasure map, no one really thought of file size either rather focusing on making it look and feel great. Which resulted in it containing a lot of high resolution images and many of them in the JPEG format. When we shipped version 1, we shipped a 57Mb install!

Small is better

For version 2 of the treasure map, one piece of feedback we got (I believe the awesome Mike Fourie raised it) was that it was a big download. So I spent some time looking through our assets and doing some sneaky clean-up and in the process learnt a bit.

JPEG

It’s crap – use PNG. PNG is better quality and for most scenarios is smaller in file size. So in both Lab Rat & Treasure Map the first step was to replace all the JPEG images (including assets like store logo) with PNG.

If you want more info on the differences between JPEG and PNG see this amazing StackOverflow answer.

PNG 32, 24, 16, 8… oh my

A PNG isn’t PNG – in fact PNG’s can specify the bit depth of each of the channels they support which directly impacts how distinct colours they support. They can also allocate a specific bit in the colours to indicate transparency. However if you do not need transparency, which in the case for the bulk of Lab Rat & Treasure Map is true, you can save bit for a colour.

Very few images will have all 16 million colours that are needed, so if you identify how many unique colours there are, then you can shrink the bit depth which results in a smaller file. I did some work on this and found two pretty interesting tools:

• TinyPNG – a free website to do this. Only downside, one file at a time.
• PNGoo – a free Windows tool that can do bulk changes. Not as easy as the website to use though.

So I ran both Lab Rat & Treasure Map through that and we got a MASSIVE saving in disk.

• Treasure Map went from 57Mb to (approx.) 11Mb – so a saving of 80%. The 11Mb is just a test on my machine and also includes a lot of new resources, so it may change by release.
• Lab Rat went from 225Mb to 89Mb! So a saving of 60%!

Summary

So in summary, use PNG not JPG & make sure you compress your images before you release!

I ♥ JSinSA – it is easily on the best conferences in South Africa and every year I learn a lot at the event! The importance of JavaScript development has never been so high – this is the time to attend this event! So to help you get to the event, I am giving away one free ticket to the event!

All you need to do to enter, is simply tweet about this: Tweet

Details:

• The tweet must include my Twitter name (@rmaclean) and the hash tag #jsinsa – to be valid
• The competition closes at midnight on 17th May 2013.
• I will contact the winner after the competition closes to arrange the delivery of the ticket.
• This is one free ticket – you have to get to the event yourself.
• This is a standard ticket – so you get everything a normal attendee to the event gets.
• I am using Beeliked to run this so any issues about draw or technical stuff, see their website.
• If I completely get this tech wrong, then I will pick a winner at random.
• Judges (aka me) decision is final.
• If you are making your own tweet, make sure the hashtag (#jsinsa) & the mention do not have characters following them, like a comma or full stop or the system seems not pick them up correctly. Easier - just hit the button above.

Introduction

This is the second post in the behind the scenes look at what it is like to build and ship a product as an ALM Ranger. The product is the ALM treasure map & this video on channel 9 gives a good insight into what is going on.

It should also be noted that these posts are meant as a more brain dump than an actual learning reference.

What to do with a drunken sailor (with capacity)

In our last sprint, I got all my work done quickly (no walking the plank here) – but I still had capacity and since the crew all did their work quickly too I couldn’t steal work items to keep me out of trouble… so what to do?

• Step one: create some work items for myself.
• Step two: do said work items
• Step three: ?
• Step four: profit!

Hopefully these changes put us in a better starting position for v2 dev which really kicks off in the sprint starting today!

What did those work items contain?

To create some work items I started by just swabbing the deck, so to speak – just cleaning up the solution, removing old folders & code.

Tiles

Starting with the tiles, I went through the assets we have and removed icons we do not used & renamed the existing ones so the right tiles load at the right resolutions. This is much easier to get right thanks to the improved manifest designer in Update 1 of VS 2012. This also helped me find a bunch of missing resolutions which have been sent to Anisha to create the artwork for.

Async

Our DB load method used async but didn’t implement the conventions properly, so that has been changed to return a Task (I didn’t do that, but I am glad it was done) & renamed to have the async suffix on the name.

Category

For some reason we had an old category.cs file in our view models, so in v1 we named our view model categoryviewmodel.cs which bugged me. So removed old file, renamed & fixed class name. Hopefully makes it easier to navigate & also helps with another tasks I did below.

ViewModel Injection

One of the aspects in our MVVM implementation was that the view was responsible to load the correct view model it needed. So every view either had code in it’s OnNavigate event or in the XAML, which was not bad. The performance issue here was that if you moved from full to snapped views, for example, the view would change & thus we would recreate the view model too! So performance could be better there. We haven’t hit state issues yet, but it could’ve lead to that (think typing in text box, switch to snapped & the stuff you typed is gone since we have a new view model instance).

The solution here was to have the navigation system control this, so using conventions again, it looks for the matching view model for the view we want and if we already have that view model available we use that, if not we create a new instance. The navigation system then injects the view model into the views data context property automatically cleaning up the code in the views too!

This added about sixty lines of code to the navigation code, but means the views & view models are simpler to work with!

Code Analysis

VS has a great code analysis feature and it is part of our quality gate to ship the release so I took the time to bump it up to full rules (we normally use recommended) and see what that could find. It found a lot and I went through those and did cleanup to the parts that made sense such as removing unused code & cleaning up the AssemblyInfo.cs file.

I have also switched on code analysis (with recommended rules) as part of the VS debug build options so that while we are developing we are also thinking of our quality gates, so hopefully our final sprint is quickly done!