Wednesday, December 04, 2019

Uno talk notes (links)

Today I gave a talk about Uno in London.

Here are the links I mentioned (all in one handy place 😀)

Main website -
GitHub -

All the latest details -

Try it out (Sample apps)
Android app -
iOS app -
Windows app -
In browser -

Other browser-based demos
In browser DB -
SkiaSharp -
Community Toolkit -
Lottie (animations) -

Ask for help -

Tuesday, December 03, 2019

Rapid XAML in the future

Rapid-XAML-Toolkit forked from the Microsoft organization
has become this
Rapid-XAML-Toolkit repo now in my org

Yes, ownership of the repository has transferred to me.


A little under two years ago, I was thinking about how more can be done to help developers building software. I was contributing to Windows Template Studio, which is a great way to get started in creating an app but wondered what could be done after that. I saw that there was a big gap in the tooling for developers working with XAML, and I had several ideas about ways this could be improved.

Skip forward a couple of months, and I had a proof of concept that I showed to some people in Redmond.
I received a positive response.
They asked what I wanted to do with it, and the conclusion we came to was to make it an "official" Microsoft open source project. And so, open-sourcing processes were followed (Yes, Microsoft has such things), a repository was created, and I began working away in my "free" time.

Fast forward to earlier this year.

I reached the point where it became realistic, practical, and necessary to start getting the functionality out to people who could use it.
In a case of bad timing, the primary advocate for the project within Microsoft left for another job.
The person who took over responsibility for the project within Microsoft then faced several months of me asking them questions. Questions like:

  • When can we get this in the marketplace?
  • What do you need from me to help this progress?
  • What progress is happening?
  • What can I do to help this progress?
  • Etc...

To try and encourage things along and provide a way for people to see what I'd been working on, I released a preview via my own publishing account.
I did a small amount of extra work in response to feedback from the preview, but the uncertainty of the project meant progress on the project slowed.

Eventually, I got an answer. This wasn't going to be something Microsoft would publish.

Not totally dejected (or surprised--given how long things had taken), I asked about my continuing the project away from Microsoft. Primarily, this meant transferring the ownership of the repository to me. As there were only minor contributions from other people and I had no plans on changing the licensing, this was agreed to, in principle, subject to approval from legal.

Cue several months of me repeatedly asking, first, "Have you asked legal yet?" and then "Have you heard from legal? Can you follow up with them?"


Yesterday I received an email that the legal department had no objections and so I made the transfer.

I've definitely learned a lot from this process.

What's next?

  • Time for me to get to work.
    While work had stalled concerning development, I've been keeping track of more and more ideas for what could be done to help developers and features to be added to the product. More details to follow...

  • Get a "proper" version released.
    I'm also going to revisit how it's packaged, so developers need only install the bits they want.

  • It will remain free and open source! An original goal was to gain experience in managing such a project, and that's still possible. While the direct Microsoft association would undoubtedly have helped, I still believe this can be a valuable tool for developers working with XAML. While Microsft continues to focus their effort on improving tooling within the visual designer, that leaves a lot of opportunities to offer tools to help within the editor.
    And, free because of not being a name that can sell the tool, I'd instead gain experience and knowledge from having a lot of people use it rather than make a small amount of money from a few users. Having spent the last 7-8 years doing work under NDA, it's getting harder to find work without any portfolio. Hopefully, this will start to show what I'm technically capable of and my knowledge of what developers want and need. This may aid in securing future consulting/contract work. I'm also hopeful the lessons and experience here may allow me to create other, paid, tools in the future.
    In a moment of what's hopefully excellent timing, I've also been approved for the GitHub sponsors program, so you can financially support this project too.

  • A new website - probably.

  • Merch/SWAG - eventually?

exciting times!

Thursday, November 28, 2019

How not to build code when only docs are changed (AppVeyor)

Having documentation and code in separate repositories makes sense for many projects but not for all.

When you make changes to code you want the CI process to build the code to make sure everything is ok with it. Then, once someone (or rather something) other than you have verified it's ok, it can be merged/committed.

That's all good but sometimes it can be very time-consuming.

When making a small change you can easily get frustrated if you haven't changed anything related to code.
I only fixed a typo on the readme. Why is it doing a full build?
In scenarios like this, you shouldn't be building all the code.

There are lots of reasons not to build the code but the most important is that it prevents quick, simple things from being quick and simple. The consequence of this is that if something should be quick and simple isn't people are less likely to do it (again).

I'm less likely to submit a fix for an issue in your docs if it takes hours. And yes, I count the time all the actions on the PR will take.

Fortunately, it's really simple to avoid this issue. Just configure your server to not build the code when only docs have been changed.

For my projects (built on AppVeyor) I use the following configuration to avoid building code when the only things that have changed are images (kept in the 'art directory'), anything related to docs, and/or any markdown files.

Here's the relevant snippet from my `appveyor.yml` file.

    - art/*
    - docs/*
    - '**/*.md'

I'm sure there's a similar way to do this with whatever build system/server/CI/CD process you use too.

None of those things are related to the code and so there's no need to rebuild the code to look for any accidental breaking changes or failing tests.

Log entry showing build being skipped because of the file types changed

The next thing I'd like to do with my current process is to add additional checks for documentation and validate those checks only when the affected docs are changed. But that's a task for another day...

Wednesday, November 27, 2019

Why web wrappers are a great start for Windows 10 desktop apps

As a subject that comes up regularly, I thought I'd post about this.

Remember, not all apps are the same.
They're not all created by people with the same knowledge or skills.
They're not all created with the same goals in mind.

Having a "web wrapper" (an app that is little--if anything--more than a WebView pointing to a website) can be a great option if:

  1. If all you want from the app is a way to put the same content as the website in an enclosed desktop experience.
  2. If it's a sensible business decision based on desired goals and available resources.
  3. If the decision was not made purely based on technical abilities or developer preference.
  4. If it's that or nothing.
  5. If the experience of the packaged web content is appropriately tested.
  6. If it takes advantage of running in that environment and adjusts web-based behaviors that don't make sense when running as an app.
  7. If an installable PWA wouldn't be better.
  8. If not doing it just to be able to say, "we have an app."

Tuesday, November 26, 2019

Recommended Reading: non-code related books for people creating software.

Books are great. Of course, you should read mine.
When you've read that, I recommend the following books to all software developers, even though they're not about code.

Badass: Making Users Awesome – Kathy Sierra (O’Reilly, 2015)

This is a great book about how to focus on what will make your product (app) invaluable to the people who use it. The focus isn’t on apps, but you can easily apply the lessons of this book to apps and games to help make them better. Read this book if you want to create something people will love.

Design for Hackers: Reverse Engineering Beauty – David Kadavy (John Wiley & Sons, 2011)

This is a great book full of useful, practical instructions for creating beautiful, well-designed interfaces. The focus of the book is primarily for web design and development, but it highlights fundamental principles that developers can easily apply to the UI of apps. Read this book if you’re not a designer, but would like to improve your design skills.

Elements of User Experience: User-Centered Design for the Web – Jesse James Garrett (New Riders, 2002)

This book provides an accessible introduction to the world of user experience (UX). Like many of the other books listed here, it focuses on web development but also shows how to apply what it teaches to other areas too. The book provides an overview to UX and has a structure for explaining its key components (elements). Read it if you want to learn more about the formal discipline of UX.

Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems – Steve Krug (New Riders, 2009)

This is the follow-up to Steve’s earlier book, Don’t Make Me Think! The earlier book was an introduction to the importance of usability in websites; this book explains how you can run usability tests yourself. This is another book written for people developing for the web, but it’s also widely applicable to mobile app development. Read this book to learn how to begin performing your own usability testing.

The Design of Everyday Things – Donald A. Norman (MIT Press, 1988)

This book is a classic introduction to design. It’s about more than just how things look and work, as it also considers the importance of understanding how they affect the people who use them and the businesses that create them. Read this to learn more about the principles of design and how they affect everything you use and create.