Thursday, November 17, 2016

Did Microsoft just make Tizen more important than Windows Mobile?

Well, probably not.

Let me back up for a minute.
This week, at their Connect event, Microsoft announced the Visual Studio Tools for Tizen.
If you're not familiar with Tizen that might not mean anything to you. I know there are a lot of Windows fan[boy]s who read my blog and so for you: Tizen is an operating system created by Samsung. It's had a varied history being used on some phones as well as in watches, TVs, and more. It's generally assumed to have been created as a response to Android with a view to allowing Samsung to control the whole experience on their phones but has had limited success on phones. (Launching an entire mobile ecosystem--apps, services, etc.--is hard.)
I seem to recall claims of it having been killed off at least a couple of times but it's still going strong. It's going so strong it claims to be installed on 50 million devices!

Microsoft providing tools to develop apps for this OS makes sense given Satya's (and Microsoft's) aim to provide tooling for:
any app, any OS, any dev
At the event where this was launched, there was no talk of Windows 10 Mobile. Can we read anything into this? Of course, people will read all sorts of things into this but there's no real news about this.

Just because Windows 10 Mobile wasn't mentioned doesn't mean it's gone/going away. It means there's nothing to announce right now.

This announcement enables those already building with C# to more easily create apps for Tizen devices. Or anyone already with a separate codebase for Tizen apps to combine/aggregate their code.

Think of the mobile version of Windows 10 being in a holding pattern right now.
It's just waiting for great things in the future. I suspect that the speed of hardware development is a big (but not the only) issue holding things back in terms of being able to differentiate mobile devices. I saw some early research about the aims of continuum and what it will enable but current hardware costs and capabilities still don't make this possible.
Let's see what (else?) the future brings...

Thursday, November 10, 2016

Using a Surface Dial to scroll through a playing track

So, I'm very impressed with the new Surface Dial. It's smaller than I was expecting but feels really nice to use. Plus it's easy to program!

Official links are here. Or see the sample I put together below.
Instructions on pairing:
Coding instructions:
Official sample:

Yes, it's an ugly app but I wanted to see how easy it would be to use it to skip back and forwards through a playing track. I'll often be listening to podcasts and skip back a little bit to have something repeated. I thought this would be a suitable tool for such a task.

It's a simple app.

  • Pick a track and it starts playing.
  • Tap the dial to toggle pause and playback.
  • Scroll the dial to move forwards and backward through the track.
  • There's also a button to toggle playback and a visualization of how far through the track it is.
Point of note:

  • It's possible to automatically select the (radial) menu item but I couldn't get it to set in the page constructor, OnNavigatedTo event, or the Loaded event. Because it's tied to the window (so different apps can have different menu items selected) I can understand why it needs a window available but I would have thought this possible in the Loaded event. Instead, I set this when a track is picked in my code.

There's lots more that can be done with the dial. Including:

  • Handling velocity of scrolling
  • Haptic feedback
  • Placement on screen (but I'll need a Surface Studio for that)

Code embedded below and at

Other SurfaceDial projects to check out:

Tuesday, November 08, 2016

Defining DEBUG only content in XAML

For a number of applications I've worked on, I've had content in the UI that should only be included in specific builds. Usually, I do this for the debug build but I've also done this for specific test builds too.
I've added text to make it clear that it's a specific build and I've also used this for accessing test specific content such as secret menus for impacting connectivity or for enabling test datasets.
Previously I've done this by adding named controls in the UI and then using the code-behind on the page to hide or show the content as appropriate. It's not been ideal but it's worked.
I've wanted something that was XAML only but never come up with anything appropriate. I'd looked at adding scripts at build time to control what was included based on properties or extensions in the markup but that wasn't great either.
In looking at how Xamarin.Forms works I came up with another idea.

It lets me have an app that looks like this in release mode
and like this in debug

Amazingly it's all configured in XAML
and changing the build config in VS causes the designer preview to update too.

And it only took a tiny amount of code.

But what about performance?

I don't think I use this enough to be concerned about the cost of having a simple extra control in the visual tree, but it's worth a little thought.
It turns out there's a simple way to achieve the same result with less code and without leaving invisible controls on the tree.
It's still not a perfect solution as this still leaves an empty content presenter lying around and does mean a line of code is executed in release builds but I think this is the best that's possible with a single code file.

Sunday, November 06, 2016

Context defined in vowels

Just heard a great way of thinking about apps from a high level that is similar to my idea of context.
Consider these terms for each vowel (A, E, I, O, & U).


Very similar to:

  • Who is using the app? (and why?)
  • Where and when is the app used?
  • What device is the app running on?

Wednesday, October 19, 2016

Twitter style launch animation in XAML

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

Ok, so this isn't strictly tied to what's new in UWP but it's been a while since I did some animations and copying the launch animation of the Twitter app (on iOS)

The idea is simple.
An image is shown. It decreases in size briefly before growing to fill the whole screen and eventually being replaced by content.
Like this:

The face image is four paths in a canvas (not shown) and the storyboard acting on it looks like this:

<Storyboard x:Name="Storyboard" Completed="StoryboardCompleted">
    <DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.RenderTransform).(CompositeTransform.ScaleX)" Storyboard.TargetName="canvas">
        <EasingDoubleKeyFrame KeyTime="0:0:0.4" Value="0.8"/>
        <EasingDoubleKeyFrame KeyTime="0:0:1.2" Value="20">
                <CubicEase EasingMode="EaseIn"/>
    <DoubleAnimationUsingKeyFrames Storyboard.TargetProperty="(UIElement.RenderTransform).(CompositeTransform.ScaleY)" Storyboard.TargetName="canvas">
        <EasingDoubleKeyFrame KeyTime="0:0:0.4" Value="0.8"/>
        <EasingDoubleKeyFrame KeyTime="0:0:1.2" Value="20">
                <CubicEase EasingMode="EaseIn"/>

Quite simple really.

Tuesday, October 18, 2016

App URI handlers in UWP apps - open your website with your app

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

If you have a website and an app you might want people navigating to your website on a device with the app installed to instead go straight to the app.

If that's what you want it's easy to do.

You just need to tell your app which website. It's just a little addition to the manifest:

Ignore the colored wiggly lines indicate that you need to declare the uap3 namespace alias:


Also add it to the IgnorableNamespaces list.

Then you tell the website about the app. Add a file named 'windows-app-web-link' to the root of the site that returns JSON like the following.

  "paths": [ "*" ],
  "excludePaths" : [ "/about*" ]

When the app is Activated you can detect being launched this way by checking for activation of the kind ActivationKind.Protocol and then query the Uri to get the path that would have been viewed on the website.

You'll find more on this and another example at

Monday, October 17, 2016

TreeView control for UWP apps

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

Many people have a good reason to require a treeview control but there isn't one included with the standard controls for the platform.
There are a few 3rd party ones but not everyone wants to use such controls.

Wouldn't it be good if Microsoft released such a control? After all, they have such a thing in their own apps.

Well, good news, such a control is coming.
There's a preview among the samples on GitHub. You'll find it at:

If you want to use it you'll need to get the whole repository because of the way some of the project files are shared amongst various samples.

It's not a simple control and it's written in C++ so that may be an issue for you but it seems pretty robust to me.
It provides customization over indentation (staggering) and whether folders can be collapsed and expanded. IT also supports the dragging of items between folders. As shown in the image here.

It can also be easily styled. And not just the icons, as below.

Thursday, October 13, 2016

Shared folders #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

This feature has been around as long as Windows 10. I've just never used it.
You can define a folder (or folders) in an app that can also be used by other apps from the same publisher and which also know about that folder.

Be careful of copying from the docs on this topic as they contain two errors in the sample XML.
The element name is PublisherCacheFolders (with an 's')  and the Folder elements must be closed.
Like this:

    <Extension Category="windows.publisherCacheFolders">
        <Folder Name="Config" />

Just add the above to Package.AppxManifest for each project.

You can then access this folder from all projects with:

StorageFolder configFolder = ApplicationData.Current.GetPublisherCacheFolder("Config");

Simples. :)

Wednesday, October 12, 2016

Single process background tasks are great - now I want a time machine #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

On many occasions in the past, I've made lots of apps that required a level of background processing.
These were typically done by having a second project in a solution that contained a class which implemented an interface to operate as a background task.
Having the task in a separate library often led to architectural issues around how the code was divided up for sharing between the different projects for the app and the task. The juggling of code structuring and dependency issues was also further complicated when functionality necessitating a background task is added to an existing project (or one nearing the end of original development.)
It's not just the division of code that was an issue. Having the app and background task (or tasks!) communicate or share information was also an issue. Managing MutExs, locking and shared files wasn't the hardest thing in the world but it always felt like more work than should have been necessary.

All that should be a thing of the past now though as the Anniversary Update introduced single process background tasks.

A few observations that may help you:

  • The docs on MSDN seem incomplete but it really is VERY simple.
  • See the background audio sample for the best guidance.
  • You don't need to make a declaration in the package manifest to use this.
  • A network state change trigger is easy to repeatedly invoke during testing (even when not under debug) - just toggle flight mode
  • The `LeavingBackground` event is also fired when the app starts.
  • The `EnteringBackground` event is also fired when the app closes.

As the title suggests, I wish this was around years ago. It would have saved me a lot of time and effort.

Tuesday, October 11, 2016

Using the web server built into every Windows 10 device #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

Just a few weeks ago I was thinking to myself - If Windows 10 has a built-in web server for hosting the remotely accessible device portal, can I also use it for my own functionality?
I was curious about the possibility of using any Windows10 device as my own web server.
While that's not possible, something related was announced last week and that's the Windows Device Portal Wrapper project.

This works if you enable the portal after enabling developer settings.

The idea is that it makes it an easy way for you to write an app that can interrogate the status of the device or perform some actions. The most interesting actions are probably installing or uninstalling other apps. It might provide an interesting tool for managing a small number of devices where more formal MDM solutions are too expensive or overly complex.

I'd originally wondered if this might be a route to eventually adding additional functionality to the portal but upon reflection, that's unnecessary and not the best way of doing things.

Originally I was thinking about the portal as a way to make any device a web server. But not every device needs to be a web server. If you do need a web server then forcing an arbitrary device to act as one is unlikely to lead to you getting the best results. Use tools/devices appropriate to the task.

I also wondered if the portal could become a generic way of accessing extension functionality for an installed app. I was thinking about this as a way for doing things like extracting log files from an app on a remote device. Now I'm wondering if that's too niche a task. For apps where this is appropriate, this could, I think, be achieved with a remote messaging of connected apps. (Which is something I hope to look at later this week.)

Maybe more will become possible with the portal (and the wrapper project) in the future but right now I don't see it being a part of my app dev plans.

Monday, October 10, 2016

When UWP apps targeting old or temporary SDKs can't be loaded #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

In reviewing some UWP functionality I tried to open an old test project from earlier this year. It was a project to test some of the functionality announced at build this year. The functionality was made available at the time via a special SDK (version 14295) that wasn't an official/formal release.

When trying to open that project on my recently rebuilt PC, solution explorer shows that an update is required to load the project. Trying to download the update presents a dialog like this.

There's a problem with the install link though. It doesn't go to an SDK to download as there isn't one.
The solution was to manually modify the csproj file.

Above you can see that I've changed the TargetPlatformVersion to be the latest (AU) version and now the project can be loaded.

Ok, so this isn't something everyone will need but if you ever find yourself with an old project you can't open or get something someone has shared online and it won't open then this may help you out.

Friday, October 07, 2016

Get feedback for your app via the Feedback Hub app #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

Apps that don't make it easy to provide feedback can be very frustrating for the people using them.
Windows 10 includes the Feedback Hub as a way of providing feedback and information about the OS and the apps that come with it. Additionally, you can also use it to capture feedback about your app.

I looked at this when it was first announced but it's changed since then. (Most notably the 'Feedback' class is now called 'Engagement'.) Here's how to do it now.

Firstly you need to install the Microsoft Store Services SDK.
This will let you add the appropriate reference to your project.

It's recommended that you use the standard icon to indicate the ability for you to send feedback. There's a glyph for this in the MDL2 Assets font file.
Here's how to use it in a TextBlock, but you could put it in a button too.

  <TextBlock Text="&#xE939;" FontFamily="Segoe MDL2 Assets" />

The Feedback Hub doesn't run on as many devices as your UWP app could so you should really test fro support before trying to use it

Fortunately, there's a static method which will tell you.


To launch the feedback hub it's a simple call:

    var feedback = StoreServicesFeedbackLauncher.GetDefault();
    await feedback.LaunchAsync();

or if you want to send some information with ti, that's possible too.

    var optionalFeedbackInfo = new Dictionary<string, string>();
    optionalFeedbackInfo.Add("key", "value");

    await feedback.LaunchAsync(optionalFeedbackInfo);

This will launch the app

And you'll see the feedback in the store.

If you want more details on setting this up see the instructions at

TechRewards is closing but don't ignore it yet!

Many years ago, well about 4, Nokia (remember them?) launched a program called DVLUP which offered incentives for developing and enhancing Windows Phone apps.
After the Microsoft acquisition, it was renamed as TechRewards and extended to also offer rewards for other areas (Azure) too.

But now it's time is done.
All the challenges have ended and you have until January to use any points balance to claim rewards.

Interest in the program had waned in recent months and the rewards that were available aren't as great as they used to be, but don't turn away just yet.

If you have an account that still has points don't ignore it.

You can make charitable donations from just 45pts. Don't waste your points - let others benefit from your past app development activities.

Thursday, October 06, 2016

Is Windows Mobile (Phone) still relevant?

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

With Microsoft doing less and less in terms of manufacturing and promoting phones running Windows 10 Mobile, many have been asking if it's a dead platform.

Obviously, it's something I think about.

Today I was at Microsoft's Transform conference. Satya Nadella (Microsoft CEO) gave the closing talk. During this he described Windows 10 as an operating system for a person across all the devices they use.

Phones are the most used and most personal devices people interact with. For Windows10 to not be a part of that would be ridiculous and I still believe that Microsoft can't abandon phones entirely.
No, they'll never be the market leader.
Yes, your mobile (phone) app strategy will need to consider building for Android and iOS. (Xamarin is, of course, a great way to do this.)
No, I don't know anything about any upcoming announcements. (And if I did I couldn't tell you.)

If you've developed for UWP or Windows Phone in the past, much of what you've learnt is hopefully still relevant regardless of the platform you're building for and UWP apps still run on desktop, Xbox, IoT, SurfaceHub, and HoloLens too.

Just keep doing as my new T-shirt says:

Wednesday, October 05, 2016

Converters are bad, so it's good that the AU means fewer are needed #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

On the surface, converters (implementations of IValueConverter) are powerful tools but I think they're massively overused and encourage doing some things which are actually bad.

The MVVM pattern is great. It's biggest benefits are to enable code reuse and improve the ease of testing. At some point in time, many people confused the pattern and the goals as being based on not writing "code behind". Specifically, they see this as meaning there should be as little as possible code written in the XAML.cs files (ideally none.) Instead, they write more behaviors, converters, or XAML. Here's my issue. Each of these are all code (yes, even XAML) that exists in the UI layer of the app. Just like anything in the code behind file. So my first objection is that there's an artificial distinction between the file or language (XAML vs C#) that UI related code is written in.

But it goes deeper.

If I have a VM that surfaces some data that must be converted before being displayed, I've now got two classes that must be used together. This coupling makes reuse harder. I can't just move one thing around, I need to know that I need another thing with it. Unfortunately, there's no standard way of indicating the VMs dependency. (And I doubt there'd be any benefit in creating such a thing anyway.) Not only do we have two separate but related classes, the business logic for how something should be displayed has been split. This makes testing harder. There's no single item under test in this instance so tests become more complicated. That the logic is in a behavior or a converter also makes it harder to test as it can't be as easily instantiated. It's normally necessary to end up running tests on such objects via the UI. Not only are such tests harder to write they're also slower to run. (UI tests are slower to run than pure code.) Tests that are hard to write or slow to run end up being run less often and eventually abandoned, bringing less benefit and eventually none.

The overuse of something as potentially helpful as a converter can actually undo some of the benefits of the MVVM pattern.

In the past, I've hit issues with performance related to the use of converters. This should no longer be an issue unless they're doing something very complicated or you're using a very large number of them. However, it's made me wary of using them. They also run on the UI thread so can impact performance there.
Generally, I try and avoid the use of converters. Instead I move the logic into the VM itself. All nice and cozy and contained. (Don't worry, I can still encapsulate logic and avoid duplication with this.)
The biggest exception to this is for Visibility. For lots, and lots, of circumstances, it's necessary to make things visible, or not, based on specific (normally boolean) criteria. I have a converter which can take a large number of different inputs (bools, numbers, lists, strings, etc.) and turn them into a Visibility value. It's generally very useful and I use it a lot.

That may not be the case going forward though as in the Anniversary Update, compiled bindings support implicit visibility conversion for booleans.

That means you can put this in the code behind (or associated VM).

 public bool ShowMe { get; set; } = true;
 public bool DontShowMe { get; set; } = false;

And use them to control visibility like this:

 <TextBlock Text="Now you see me" Visibility="{x:Bind ShowMe}" />
 <TextBlock Text="Now you don't" Visibility="{x:Bind DontShowMe}" />

which would only display the first TextBlock.

A couple of points of note.

This only works if the minimum version of the project is the AU.
The implicit conversion only works if the app is running on a machine running the update. The above targeting means that the app will only run on such. In theory, you could include it in code that targets earlier versions and selectively include it if you can detect you're running on a machine with the update but you'd still need to support explicit conversion for when running on older machines and so would require extra code.
The other downside is that you have to bind to booleans for the code to even compile as that's all that's supported. I'll need to keep my own converter around for a bit longer to enable me to do more interesting things like hiding zero length strings or empty lists. Either that or add extra properties to the VM for binding.

Tuesday, October 04, 2016

Displaying GIFs in a UWP app #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

Displaying GIFs in XAML apps has been notoriously tricky in the past. A mix of licensing issues and a lack of native support meant that complicated workarounds were often needed. The most common solution involved the use of an embedded webbrowser control but it was a far from ideal solution.

With the anniversary update that's changed. GIFs and even animated GIFs are now supported.

Simply drop this in a blank app.

<Image Source="" />

and get something that looks like this (minus the animation)

Going a bit further I wanted something that would show a few more animated GIFs at once so I created an app that's pointed at the giphy trending API.

It was just a case of grabbing the API response and serializing it as something suitable

    var json = await new HttpClient().GetStringAsync(new Uri("", UriKind.Absolute));

    this.DataContext = JsonConvert.DeserializeObject<ApiResponse>(json);

and then displaying it on the view:

        <GridView ItemsSource="{Binding data}" >
                    <Image Source="{Binding images.original.url}"
                           MaxWidth="200" />
                    <ItemsWrapGrid Orientation="Horizontal" />

And voila, a lovely app showing lots of animated gifs:

Apps requiring the display of gifs are no longer an issue. :)

Monday, October 03, 2016

Trying out the new Windows App Development Virtual Machines #UWPLunch

All this month, I'm taking some time each day to explore (and document) things that are related to UWP development that I haven't fully investigated or used before. While doing it over lunch each day I'm calling it #UWPLunch.

At the end of last week, Microsoft (Hi Clint) announced the release of some updated virtual machine images for doing Windows App Development. While I always like having real hardware to run on (it's just faster) I appreciate the need for having a consistent development machine image and it's always good to have a backup. Recently, while preparing to move house and with all other machines packed in boxes my dev machine had a disk failure and I needed to get another dev environment set up quick to create a new release build of an app for a client who needed it ASAP. Using these VMs then might have saved me a lot of faffing around and unpacking.

Knowing these are available is great, but how easy are they to actually use?
Follow along as I see.

I started by going to the Azure portal and searching for a virtual machine that included "Windows SDK".

There's a few there so I selected the first on the list and hit create.

Then it was a case of specifying some details and selecting a machine size and specifying some network settings (which I left as all default values).

Then I just pressed OK and a VM was created for me.

Deployment took a few minutes (8 minutes and 40 seconds to be precise) and then I was able to remotely connect to it via RDP by clicking on the 'connect' link at the top of the screen.

I then entered the credential specified when creating the machine and trusted the certificate when prompted.
And then I had a virtual machine up and running and capable of use as a development environment.

All my favourite project templates are there

and I can create and run new UWP apps.


Based on this experience I'll definitely keep a VM around and fully set up for my next UWP project. I never know when I won't have a dev machine handy but need to make a change.I'll also keep an eye out for how updates to the installed tools are handled.

Friday, September 16, 2016

99 developer events

Last month I organised my 99th developer event.
(I've attended and spoken at many more but that was the 99th I'd been primarily, if not solely, responsible for organising.)

These have been as part of DevEvening and then as the 'Window Phone User Group' which was later renamed 'Windows Apps London'. (27 for the first and then 72 for the latter.)

These have mostly been presentation based events on a mid-week evening but have also included:

  • one-day barcamps and mini conferences
  • all-day hackathons
  • workshops
  • coding competitions
  • collaborative coding challenges
  • show-and-tell sessions
  • social events

Through these events, I've met some amazing people and been granted some great opportunities (both in terms of work and personally.)
It's not been just about me . Through these events:
  • friendships have been made
  • businesses have been formed
  • people have found work (and whole new careers)
  • many people have learnt a great deal
  • many apps/products/services/tools have been created and improved
  • attendees have been motivated
  • lessons have been shared and learned
  • people have been encouraged to share what they've learned
  • some of the people who spoke at these meetings for the first time have gone on to become international conference speakers
  • at least five other groups have been started prompted by attendance at one or more meetings
  • lots of people got free phones and tablets
  • I've given away a lot of software, conference passes, t-shirts, badges, stickers, books, pens, cups, and other assorted SWAG (huge thanks to all who donated these.)
  • a lot of burgers and pizza have been eaten. (For events held in pubs this usually meant people buying burgers. For other events this meant ordering pizza--and I'm now very good at ordering large quantities of pizza!)
  • and, of course, much drink has been drunk. (Possibly surprisingly more soft drinks than alcohol and I've also learnt that people really appreciate a variety of drink options.)

It's been an incredible time. 
I started organising these meetings because I wanted to go to them. To meet people with similar interests and learn from their experiences. I've certainly done this and more, even though I'd often miss some of the talks I was keen to hear as I was busy doing organisation related things.

The highlight of eight years of organising events is hearing from people who come to and look forward to these events because they would have had little option to socialise otherwise or at least to meet with other people who share their interests.
It can be tempting to joke about or dismiss a group of geeks or nerds meeting together to talk about technical subjects. (There are even lots of technologies and acronyms discussed that I don't know anything about but others care about passionately--and that's ok.)

While the freebies and trips have been great, the biggest highlight for me and which makes all the organisational effort worth it is one story which almost had me in tears.
Someone who had been coming to meetings on and off for a few years stopped coming for a while. He turned up at one meeting a few months later and after the meeting spoke to me. He said that he was sorry he hadn't been there for a few months. His father had died, his wife had left him and taken their three kids, he'd had to find a new place to live, and get a new job. That night was the first time he'd been out in three months and he was really appreciative of the opportunity to see some friendly faces and spend a few hours doing something for him and enjoy focusing on something pleasant that he like doing. I felt it an honour to be able to help create something and a place that would allow him to feel like that.
In a world where people are increasingly being isolated, it's important to meet with other people with similar interests. Even if it is just to talk about "techy geeky stuff".

What comes next? (Some people have told me that I have to get to 100 events, but 99 seems like just as good a number.)
Right now I honestly don't know what'll be next. Personal circumstances mean it's highly unlikely that I'll be doing any more evening events in the next few months.
Maybe something online - but I've always really valued the difference people meeting in person brings to an event. (see above)
Maybe something during the day....

To all who've attended or otherwise been a part of those 99 events, Thank you. I hope you enjoyed and valued them as much as I did.

Saturday, August 20, 2016

The Starbucks app update—an analysis

Reposted here although originally posted on medium

Shh. Here’s a secret. I think there’s a part of me that wants to be a hipster. It must be true because I sometimes work in coffee shops — just like the cool kids.

This morning I went to town to do some writing in Starbucks. I go there quite a lot. Enough that many of the staff know my name and my usual order. Also, for the sake of this story, enough that I have a Starbucks card to make payments and collect stars (for rewards including free drinks.) Because I’m me and because they have one I also have the app version of the card on my phone.

Here’s what happened today:

  • I entered the store.
  • There was no queue — yay!
  • Went to the counter and gave my order. (It was someone I didn’t recognize serving.)
  • I launched the app on my phone and was presented with a screen that showed I wasn’t signed in. :(

  • I quickly tried to sign in after giving them my order (Venti, vanilla, Latte if you’re interested)
  • Sign in failed.

Side note: notice the mixed use of “sign in” and “sign-in”. Don’t do that. Be consistent.

  • I go to re-enter the password but see my email address has been deleted. (It’s hard to check something that’s been deleted.)
  • I mutter something under my breath.
  • The barista at the till looks at me waiting for payment.
  • In frustration, I put down my phone and take out my wallet.
  • I hand them my card while mentioning that “the app logged me out.”
  • They say that “that’s happened to a lot of people this morning”.

I wonder how many people, at this store and across the country, have been affected.

That’s people who’ve been frustrated by the fact that what should have been a quick, simple process wasn’t.

I wonder how much it delayed people during busier periods earlier this morning. That’s individuals affected by the delay to them as they have to log in again. Also, people kept in queues longer while those in front of them struggle with the app. Was it enough for anyone to miss a bus or train? Was it enough that people left the queue early because it was moving too slowly?

Because I’m me, I wonder what had happened in the app and decided to take a few moments to investigate and see what lessons can be drawn from this.

As the people using an app are the most important factor in the UX of an app, let’s start there.
It’s not good. The experience created negative emotions towards the brand. I was made to feel frustrated and disappointed that:

  • paying for my coffee which is supposed to be simple and frictionless wasn’t.
  • I had to enter my email address more than once for no good reason. (They obviously don’t care about unnecessarily wasting my time.)

Ok, so what about the app?

My initial assumption that as the phone hadn’t been updated or rebooted since I last used the app the app must have been automatically updated.

A quick check and a helpful app store notification shows that’s the case.

I have automatic updates turned on because I want to get the latest versions of apps as they become available.

Having auto-updates turned on is good for the publishers of apps too. When they release updates they want people using them as quickly as possible so they don’t encounter bugs that are fixed and can take advantage of new functionality. You don’t want to spend time creating an updated version of your app only to have no one use it. (This is why, in my book, I claim that update notification is the most important feature that every app should have.)

Ok, so there was a new version that was installed.

Now let’s see about that sign in experience.

It looks like a regular sign in screen but let me poke at it a little.

“Username or Email Address” they appear regularly together on registration and sign in forms but they’re not always both needed. Well, email addresses are normally needed. But usernames? Not so much. As a credential for identifying myself to the service, an email address has the dual benefit of being unique and a token for contacting me outside of the app/service. I can’t think of any good reason for needing a username for my Starbucks account. If Starbucks want to address me they should use my actual name (which I told them when registering.) If this was an app that would allow me to connect with other people who use the app then a username would be a good, simple way of identify different people. For instance, on Twitter I have the username@mrlacey. You can use this to find, mention, or message me. It’s much easier than trying to differentiate me from all the other Matt Lacey’s in the world and it doesn’t make anything potentially private about me public. But I don’t communicate with other people who are using the Starbucks app. So, why do I need a username?

Maybe I can create a username to make it easier to sign in.

But (I think) this is only the second time I’ve logged into the app. Why add something I need to remember to perform a task I rarely have to do? I don’t know what my username is. I can probably guess but don’t want to have to. I know what my email address is so why wouldn’t I always use that?

If I’ve forgotten my Username there’s an option for that.

If I’ve forgotten my username I can use my email address to recover it. This is redundant!

The flow for recovering a forgotten username is:

  1. Select ‘Forgot Username’ option
  2. Enter email address
  3. Go to email client and (when the email arrives) retrieve the username
  4. Return to the app and enter Username and password to sign in

Or you could just ignore the username all together and log in with email address and password. The above flow requires entering them both anyway. It just adds a lot of extra, unnecessary steps too.

“Fun” side note: While writing this I went through the ‘Forgot Username’ flow as I was curious what my username was. It turns out it’s the same as my email address. There’s an acronym for this which starts with ‘W’ and ends with ‘F’.

What’s my username good for? I’m not sure.

While I’m here, let’s look at the forgotten password flow.

What the what!?
I need to enter my email address and my “Username or Email Address” to recover my password. So, can I enter my email address twice? Or is the label on the second text entry wrong? Either way, I’m starting to have serious questions about how or if this was tested. And the process that led to this situation.

Maybe the username exists as a way to try and prevent the malicious validation of email addresses registered with the system by deterring the automated, brute force entry of values in the password recovery process. If that’s what’s happening, it’s trying to solve the problem in the wrong way and is undermined by the username recovery option.

Despite what you might be imagining based on the above I manage to correctly sign in with my second guess at my password.

Now I’m logged in and using the app again, what’s new in this version?

A quick scan of the different parts of the app and I don’t see anything obvious.

I wonder if there’s any details listed in the app? ‘Settings’ is where I’d normally expect to find this (if it exists.)

Sadly, there’s just a version number. I don’t know what version I had before so this doesn’t tell me much but it looks like a small update (based on the number) so I wouldn’t expect much to have changed.

Let’s see if the store listing can tell me any more about what’s changed?

It can tell me something, but it seems little has changed. Just small changes relating to store selection and the displaying of maps. These are not features I use. This means I went through all this and got nothing from it apart from something to write about in this post.

Oh, they say “Thank you for all your feedback.”

Give all the above, what can be learned from this experience:

  1. Don’t force a person to re-authenticate with an app after it has updated.
  2. Don’t let an update cause saved data (including access tokens or cached credentials) to be lost.
  3. There is no functional or security related reason to delete an email address after a failed login attempt. It only ever creates more for the person using the app to do.
  4. Only require people to create a username for your service if they’re going to use it to communicate with other users of your service.
  5. Be sure that the labels for what people can or need to enter are correct.
  6. Use terms and labels consistently. (e.g. Don’t mix use of “sign in” and “sign-in”.)
  7. Don’t add arbitrary complexity on the assumption that it will help improve security.
  8. Test your registration, sign in, and credential recovery options thoroughly.(If you’re not confident in doing this then you could ask or hire me to help.)
  9. When an app is used for the first time after it has been updated, acknowledge the update and provide access to details of what’s changed.
  10. Make it easy (and obvious) for the people using the app to submit feedback.
  11. Bonus: I can tear apart and find issues with any app. ;)

The reason I write posts like this is because I don’t want to have experiences or use apps like what’s detailed above. I don’t just want to complain but help people learn how to identify and fix such issues. If you can see other people making mistakes and learn from them it will, hopefully, help you avoid similar issues in future.

Monday, August 15, 2016

Another reason your custom font may not display in a Windows app

Here's something that took me hours to uncover. I document it here to hopefully save someone else some time in the future.

Using custom fonts in apps is great. It can add some visual interest, draw attention to some specific text, serve as a way of handling multiple images or icons, and it can enable the consistent representation of brand identity.

There are a few gotchas for getting the font to display correctly in a Windows app, such as having the wrong build action, or trying to use a file which does not support embedding and these are quite well documented in various blog posts around the web.
After much head scratching, I finally found the cause of another reason a font may not display properly.

Here's the issue summed up in one image.

Here's what's going on.
When a custom FontFamily is specified it is done in two parts. The first is the name of the file and the second is the name of the font family. It should be quite simple and if you add the font to your project you can use Visual Studio (or Blend) to select the font from the dropdown list and it will set this for you.

Here's the gotcha.
On Windows, there is a way to specify multiple font families in a single file and a way to specify which is preferred. It seems the VS/Blend font selector does not handle preferred families correctly. Specifically, it appears to use the family name regardless of whether a preferred family is defined. I was using (as in the screenshot above) a corporate font that contained a single family but had a different value specified for the preferred family name. For the font to be correctly displayed it's necessary to use the preferred family value but this is not what was set by the tool. It's simple enough to change this in the XAML if you know what's up.

Identifying this was a challenge.
I normally use TTFEdit to explore the internals of font files but this doesn't have the clearest of interfaces. While investigating I discovered dp4 Font Viewer and this did help make it easier to see some of the less obvious properties of the file.

There's probably a little more subtlety to the actual issue and I'm not interested enough to read the TTF spec to see the full extent of what could be going on but hopefully, this is enough to help you if your font is not being used and you can't see why not.

Friday, August 05, 2016

What's next for apps? [361Podcast S13E07]

In writing my book and with some other writing I've been doing, I've been thinking a lot about what comes next in the world of apps.

To broaden my thoughts and opinions on the subject I reached out to Ben, Rafe, & Ewan of the 361Podcast with some questions to get their thoughts. They took a whole episode to respond to my questions and it was published last night.
Go and have a listen at

While, or before, you do here are a few notes I made while listening.

This is what the future looks like:

The norm will be for there to be a variety of interactions with a company/product/service across different devices.

The challenge will be to combine micro-interactions in a way that doesn’t feel fragmented, even though it’s disparate.

The way we think about apps will change.
There will be a move from the idea of siloed or contained experiences.
Apps can become the container and distribution process for functionality. They are likely to become less about the direct visual presentation of the interaction.

The current options for integrating with a mobile OS are a start but deeper integration with virtual assistants (Siri, Cortana, Alexa, etc.) are likely to be more important in the future.

There are lots of uncertainties about future virtual assistant (VA) interaction:
  • How will service integrations be configured? Will it need some custom UI?
  • How will service integrations be discovered? Not everyone can rely on being recommended by a VA.
  • What does this mean for the relationship between consumer and service provider when there’s another party sitting in the middle of all interactions?
  • If this becomes the standard way for consumers to interact with other services are there potential regulatory or anti-competitive issues to control what a dominant VA can or can’t do?
  • How transparent can or should such interactions be? Let’s consider wanting to buy some toothpaste.

“Siri, order me some more toothpaste.”
It seems a simple request but it’s a highly loaded task and full of uncertainty and possible variation.
  • What make and size of toothpaste?
  • What if that’s not available?
  • Where from?
  • What if they don’t have it?
  • Does it matter how much it costs? Even if it’s gone up since you last ordered it?
  • How will you pay? What if you have credit with one store but it costs more than
  • Does it matter if it comes from a retailer you’ve not used before?
  • Rules about what you should get from where based on cost and availability can soon get complicated. Do you really want to preconfigure all this for something as basic as toothpaste? Not everyone can afford to ignore things like price
  • How much information will be given to the company that fulfills the order? Does it matter if one retailer wants more than another? How will this be managed and controlled?

If you’re Amazon/Alexa a lot of the complexity is avoided. If you’re another retailer (even if really big) but don’t own the infrastructure of the VA there’s a lot more to think about.

Thinking about discovery, and commission on sales, maybe the VA or OS will monitor what you do on the device and make suggestions for things that might be of interest to you.

Data privacy is a big potential issue here. How much information will be shared with an “app”? And how much information will the companies behind the OS and VAs now have and what can they do with it?

The biggest issues for VAs and apps that will provide functionality is that of context.

Quick side note. I know context is important. I spend 82 pages on it at the start of my book ;)

As we ask more of the services behind apps they need to know more to be able to make the right choices and suggestions.

Creating great, refined apps will be the key to success and differentiation. As experiences won’t be able to rely on a strong visual identity to reflect their brand they will have to focus more on the quality of the user experience to maintain brand loyalty.

There will be a greater need to avoid assumptions about the people who will use the app and create something that is genuinely “consumer-centric” and tested with and by the real people who will actually use the app.
It’s not just the people using the app that it’s going to be increasingly important to understand. A deep knowledge of the devices, operating systems, and platforms that people use and directly interact with will become increasingly important for creating great, intuitive experiences.