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."

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.
[amazon]

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.
[amazon]

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.
[amazon]

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.
[amazon]

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.
[amazon]

Should I change my presentation style to be more like other people?

I've spent a lot of time researching how to be a better presenter. The result of all of that is that I've reduced my own internal guidelines to this: don't do the bad things I see other presenters doing.

I don't like it when people read a script - So, I don't use one. (Although I do write several versions of one while preparing.)

I don't like it when people are giving a talk prepared by someone else - So I make mine my own. No-one else would give the presentation in the same way.

I don't like it when people are repeating something they've heard or researched but don't have personal experiences to share - So I only talk about things I know really well.

I don't like presentations that are given multiple times in the same way - So mine are always unique. By this, I mean, they're regularly updated and adjusted for the specific audience.

I don't like it when there's no audience interaction - So I involve the audience.

I don't like it when presenters are unprepared and underrehearsed, so they can't adjust to changes or things going wrong - So I rehearse lots.

I don't like it when people are talking about things they have no passion for--or at least don't appear to care about - So I only talk about things I can get excited about.

I don't like it when presenters take ages covering a single point - So I try and include lots of things. As a downside, this means I have a tendency to rush and may not cover items in as much detail.

I don't like it when there's no benefit to seeing a presentation live and watching a video recording would have been better. - So I encourage questions from the audience.


I know my "style" is not to everyone's taste but it feels right for me.
However, maybe I'd be more effective if I was more like other presenters...


What do you do when presenting? Or think I should do?

SimpleTesting - Get started with coded tests in .NET

tldr: I made a thing. Get the NuGet package and read more on GitHub

I have a theory: Getting started with writing coded tests is harder than it needs to be.

I wanted to make it easier to get started by getting the number of things that need to be installed or learned before it's possible to start writing tests.

The value of writing tests is better appreciated once some have actually been written, so I've made a way to put off the things you can think about later:

• Which test framework to use
• Which Test runners
• What Mocking frameworks
• What Isolation frameworks
• What are Mocks/Stubs/Fakes and when/how should they be used
• How to mark up tests and test classes
• How to indicate success or failure
• What counts as a "unit" test
• How many, and what, different things need to be installed.

That's a lot of things to learn or be a distraction when the aim is to write tests.

My solution requires:

• Only installing a single NuGet package.
• No special markup needed (attributes, naming conventions, etc.)
• Forces tests to be clear about whether they pass or fail.

To use it:

• Have a class that inherits from `SimpleTesting.IContainSimpleTests`.
• Have a parameterless constructor. (One is created by default if you don't add a constructor.)
• Create public methods that return `bool` (or `Task<bool>`)

Those public methods are then "automagically" turned into tests when the code is compiled.

You can see examples of this in action in the GitHub repo.

And it generates tests (in a different namespace to the original class) that Test Explorer picks up and can be run from within Visual Studio.

It doesn't do everything that a full test framework does but you can use one in combination with these "simple tests."


I'd love to hear your thoughts on this?

Make the repository public - no-one cares about your code

Just make the repository public (assuming it contains no Publicly Identifiable Information or embedded secrets.)
If it does, you should remove them anyway.

There are common fears about making code public.

• What if someone takes it and makes something with it that they start selling or otherwise competing with my project?
• What if someone laughs at it?
• What if someone copies something?

So what? No-one is paying attention to what you put on-line. (If they were I doubt you'd have nothing better to do than read my blog.)

• Use an appropriate license to address possible competition concerns.
• Ignore the haters.
• Assume that something will be copied.

I've heard it said many times (sorry, I can't attribute the original source) that "any code on the internet will eventually end up in production."

And if it does, that's ok. I don't feel responsible for someone else's codebase if they copy something I wrote (possibly many years) previously and use it differently without understanding the nuances and possible consequences.

Searching GitHub is now my default for working out how to use an undocumented API.

By searching for uses of the method/class/whatever, I can see how/if someone else has made it work. Not in a contrived example. But, in a real (hopefully) production code-base. If they hadn't made their code public I would have been stuck. I see making as much code as possible public as a way of paying it forward to other developers.

Seeing that an API has been used successfully by someone else (and how) is incredibly valuable and has helped unblock me from many coding challenges in the last year.
If I can make my code public and potentially help others in the future, then I'm all for it. I'm sure that the only reason someone else will look at my code is if they find it as the result of a search.



While I was sitting on the draft version of this post, I received this message.

"You can't just create a blank repo and leave me hanging!"

"Oh, no!" I thought. "This contradicts what I wrote in that (this) blog post."
I'm not sure it does, though.
This was a question about a name. The name of a repository.
(I find creating empty repositories for possible future projects cheaper than buying a domain and never doing anything with it.)

The name of the repository sparked interest, and they wanted to know more of what I intended for something with that name. (Hopefully, this suggests it's a good name.)

However, with more than 100 public repositories in my GitHub account, I can't recall ever having a random email asking about any of the code they contain.

I think my point still stands.