Don't show this message again - avoid vague options

You've probably seen options like the one above used throughout the software you use.

It might be clickable text like that shown above or as an option with a CheckBox for you to check to indicate an answer you want to always be used in the future.

In theory, this is a good option to have.

As a general rule, you don't want to repeatedly prompt the person using a piece of software to give you the same information over and over again.

Similarly, you don't want to be telling the person using the software the same thing over and over again. They might not need to be told every time and you're likely to annoy or frustrate them if you do.

They might also start(?) ignoring any messages like this and inadvertently miss/ignore something new and important as it looks like something they've seen before.

[Aside: information, warning, and error messages should always be easy to distinguish between. Don't for example, make all of them the same color so the only way to differentiate them is to read the text.]

However, displaying a message like this raises questions for the person using the software.

• What is it that won't be shown again? 
• Is it the exact, specific scenario, or all ones like it? (If the message is about one account/file/project/etc. will selecting this option stop it from being shown again for all accounts/files/projects/etc. or just this one?)
• Does my answer apply to all variations of the displayed message/scenario?
• Does it include displaying the message only in the same circumstances that caused it to be shown? (What if other circumstances or scenarios also warrant showing that message? I might want to see the prompt then.)
• Could the same (or very similar) message be shown for a different scenario?
• What if I want messages or prompts like this to be shown again? (at some point in the future.) How do I (re)enable that?

Yes, I'm someone who can often look at prompts with the "don't show this again option" and think about the possible future scenarios where it might be useful to get that message again. It's often easier for me to just ignore that prompt than try and figure out exactly what selecting the option might do.

When showing such an option, I can see that you're trying to be helpful but now you're adding complications and asking me to make a decision where I don't know the consequences of each answer.

Ideally, the software a person is using should give that person confidence and not raise doubts or questions about the thing you're doing to try and help them. Admittedly, for very large and complicated software that won't always be easy.

I'm not trying to argue that you should never use a prompt like that shown and described above. They can be very useful.

I'm saying that you need to consider the use of these messages and test they are understood by the people using the software. You want your improvements to actually improve things for the people using the software. Adding more prompts and options isn't always the best answer.

Why I wrote (and you should buy) a book about Uno Platform when there are free resources available

The Uno Platform team recently published a list of resources for anyone wanting to learn about the Uno Platform.

Of course, the book I wrote with Marcel is on the list, 

But why pay for a book when there are free alternatives?

The immediate (and obvious) answer is that our book includes information that isn't in the other available resources. There are lots of blog posts, ebooks, and online talks (including some by me) that provide an introduction to the Uno Platform. We intentionally wanted our book to go beyond this. The first chapter is an abridged version of the contents of that other content as that is just the starting point for the real content.

Our book was written for people who wanted to know more than just the basics and build "real" software with Uno Platform.

Want to see how to do some of the things you're likely to do in a typical app? We'll show you.

Are you evaluating Uno Platform as a way to build apps? If so the book will show you how to build more than a "Hello World!" app. This will allow you to make an evaluation based on something closer to what you want to build but without having to do as much work yourself.

The book represents many months of effort. We believe the effort we put into writing the book has financial value. The time you'd take trying to learn and/or figure out the things we show in the book would cost you much more than the cover price of the book. 

The book also isn't for everyone. If all you want is a high-level overview, quick introduction, or a random collection of tips, tricks, and examples of things that are possible the internet has you covered. If it was just about numbers I'd have written a series of blog posts. The daily readership of this blog is higher than the number of copies I expect the book to sell. (Of course, I'd be happy to be wrong about this--and not because of a drop in blog readers 😉) If you want to see how to go beyond the basics and see what's involved in developing more complex app scenarios then the book will be of value to you.

Buy it: Amazon UK or US

Imposter syndrome - a coin with 2 sides?

Lots have been written about Imposter Syndrome, especially with how it relates to the world of software development. I wouldn't normally write about such things here but I've recently been struck by a new, related idea and it felt too long for Twitter.

Talking about complex issues can be hard as it's natural to assume that other people have similar thoughts and experiences as yourself. But that's not always the case.

But what if all imposter syndrome is not the same?

I think there are two kinds (there may be more but two is enough for me, now.)

• I don't deserve to be here.
• I don't deserve to be allowed in there.

The order doesn't matter.

It's easy to think they are the same but there are some subtle differences.

One is about loss and one is about gain.

But, both are about self-doubt, fear, a lack of appreciation for own value, and neither are necessarily rational.

In that "people in tech" often think of themselves as logical and want everything to be logical this can make it difficult to talk about.

It's also possible to have both thoughts about yourself. Not about the same thing but about different or even similar topics at the same time or in quick succession.

It sometimes feels like everybody has imposter syndrome at least some of the time.

Not everything is imposter syndrome though. Sometimes you can be in positions you don't deserve to be in. Sometimes you'd like something, to be, or do something that you're not qualified for or yet capable of.

But what can we take from this? It doesn't sound like I've made any great insight.

Well, here's the thing that struck me. 
It's important not to assume that the imposter syndrome another person is currently feeling the same kind of imposter syndrome as you.

For example:

If you're someone with a job and your imposter syndrome makes you state you don't feel like you should be there, it can be really disheartening for the people who would love to be there but their imposter syndrome tells them that they don't deserve to get a job there. 

Or people with good jobs they clearly deserve saying they have imposter syndrome can be really disheartening for those without a job and have struggled to get one, for years and so feel their own sense of imposter syndrome about being worth employing.

It works the other way too. If you have imposter syndrome about not being recognized or accepted for something, it's tough to hear people who are recognized say they have imposter syndrome about being acknowledged that way.

Beware of dismissing other people's imposter syndrome. Especially when it's different from the type you experience.

Both types of imposter syndrome offer an opportunity for self-improvement. As a prompt to increase technical skills and as an opportunity to acknowledge your own value and worth, regardless of 

Some quick thoughts about writing a first book

A few times in the last couple of months, I've been asked about the writing process from people who are thinking about or planning to write their first technical book.

Here are some of the things that I'm telling those people. I'm putting it here because others might be interested and because it will make it easy for me to find (and refine?) in future, if necessary.

• It's LOTS of hard work. It is very unlikely to earn you much (any?) money. (Especially if you're used to being well paid for your time as a developer.) Are you sure you REALLY want to do it? 
• Be prepared to spend (you should be spending) more time planning and re-writing that writing.
• Interview the publisher. Assess if you want to work with them like you would (should) any employer. Do you get on with these people? Do you want to spend lots of time talking with them? Can you trust them?
• Speak to authors who have worked with the publisher before. Find ones with good and bad experiences. Find out who at the publisher the author worked with. It's the people that matter more than the publisher as a whole.
• Understand why the publisher wants a book on the subject, and why they think you'd be good to write it.
• Technical reviewers are at least as important as the editor. Get lots of feedback from the technical reviewer on your detailed outline for the book. They'll help avoid any big issues not being identified until it's too late (there's not enough time) to fix them.
• Write ALL the code before estimating the wordcount for a chapter. If your book is mostly going to be explaining code or APIs. Yes, this means you have to have a really detailed plan and have done a lot of the work to be able to write the outline and before you sign a contract and start "writing" the book. For reference, I think four lines of text to every one line of code is a good guideline as it's explaining, not just showing the code that's important. You'll also discover that code is actually a lot more lines of code than you imagine in advance.
• Have a backup plan for what to do with your planning work even if you don't finish the book. (A series of blog posts is an obvious answer.)
• Avoid working with a publisher that has very strict structure and expectations for a "type" of book if that's not what you want to write. You probably won't get as much support as you'll want/need and it's harder for them to help you.
• Triple check everything. If it's your name on the cover people will attribute any mistakes or issues to you. (Don't always rely on other people using the change tracking functionality of software or documents correctly.--Guess how I learned this.)
• Ask the publisher for the guidance they give to new authors after they sign the contract, but before you sign a contract. These guidelines often include lots of useful information that will help you write the outline--that will lead to the contract. Consider it a red flag if they won't share it. Speaking of which...
• Trust your gut. I've not (yet) met any authors who had doubts about a publisher at the start but they turned out to be unfounded. I have met many who wish they'd paid more attention to the things the red flags they saw early in the process.

I hope this helps.

XAML is not a Turing-Complete language - but treating it like one can be helpful

What is a "Turing Complete language"?

Good question. You can see Wikipedia for more information, but I think of it this way. It's one capable of taking input and producing output based on some form of logical decision-making or processing. 

Basically, it's a clever-sounding name for a general programming language. (Not to be confused with a general-purpose language with no specific focus and distinguished from languages designed explicitly for a particular problem-space or type of usage.)

I think of it as a shorthand for a language you might use when you could (theoretically) use another language and still get the same result.

So, XAML is not "Turing complete" or a "general purpose" language.

It was never meant to be. It was created to represent a user interface (in whole or part) and, to a lesser extent, as a way of describing (or storing) data. [And this data can also be used to store steps in a process or workflow 😉.]

That you can use XAML in combination with a general (or Turing complete) language is irrelevant. That a compiler may take a XAML file and use it to create a C# (or VB.Net, or F#, or anything else) that is used instead of or in partnership with the written XAML doesn't change the XAML file or how you should think about writing it.

Treating XAML like any other "proper" language can be really helpful.

Taking the attitude of "it's only XAML" or "it's just text" doesn't help. It's an attitude that leads to inconsistencies that can make maintaining the code harder and the introduction of actual bugs more likely. It also makes it less likely that you'll look for tools to help write good XAML and ways of writing XAML code that is easy to read and understand. In turn, this will lead to the potential for more accidental bugs and code that is harder for other developers (including future you) to establish the original intention behind the written code.

As XAML files are part of a shipping application, it's essential to treat them the same way you do any development-related asset.

There are many good practices for working with many (most?) programming languages. Not all of these are relevant to working with XAML, but some are.

More posts on this topic will follow...

Don't give up on XAML yet.

Some people aren't fans of XAML. That's ok.

Some people use it because they have to.

A very small number of people think deeply about XAML. 

I include myself in the third group.

There's a popular trend at the moment to dismiss XAML because of its limitations. 

The argument goes that you should use C# (or equivalent--hello VB fans) to define the whole of the application, rather than use a separate tool (XAML) to define the user interface. This is seen as a way to simplify a codebase and avoid some of the limitations of XAML.

C# is a general-purpose language. You can use it for everything but that doesn't mean you should. XAML, while not a full programming language is designed specifically for defining user interfaces and has appropriate tooling available.

XAML is not a "proper" (Turing-complete) language but it doesn't need to be. It can still do useful and powerful things.

Most of the arguments I'm hearing for just using C# come down to the idea that the tooling for defining UI's in C# should be made better so that people can use that instead of having to use XAML.

I have concerns about this approach:

• It ignores the possibility of improving the XAML experience, which is the ultimate source of the issue.
• It means the need for more work in supporting (developing & maintaining) the ability to create UIs with XAML and C#.
• It indicates that there is no plan, desire, or intention to improve the XAML tooling and experience. Should people, therefore, infer that XAML is in a fixed state and will never be touched again. The consequence of such an idea is that people should stop using XAML. What then for all the existing XAML code that exists? There's an implication that this should probably end up being rewritten in C#. This means that we don't have to jump very far to get from some people being disappointed with XAML to everyone having to rewrite their code so they don't use it.
• It can be harder to visualize a UI from just the C# code. (I recognize that this is just my current opinion though.)
• Separation of concern boundaries are much more easily broken when everything is in one language.
• Just because XAML isn't a "proper" or full (turning-complete) language is not a reason not to use it. Making changes to a general-purpose language (C#) to make it easier to use for a specific scenario seems equally flawed. In fact, when XAML is treated like a "proper" language it becomes much easier to write, read, and maintain that code. (More on this in a future post.)

I will, of course, admit that creating UIs in C# can (& does) make some things easier to read and understand. However, I don't think that should automatically mean we do away with everything that isn't C#. Also, I'm yet to see very complex UIs defined in C# but have seen many complex scenarios implemented in XAML. 

This isn't to say that complex UIs can't be created in C# as well as XAML, it's more to highlight that the situation is complex. It's very easy to reduce this discussion based on personal experiences but the reality is that XAML and C# are used by a very large number of people to build massively varied types of software with vastly differing specifications, requirements, and uses. There are a minuscule number of absolutes that can be relied upon when discussing the options and what's "best" for everyone.

Where we're at now, things are improving for UIs defined in C#.

But, why not also improve them for XAML too?

Yes, XAML has been stagnant for many years and the plans for a XAML Standard ultimately came to very little. 

Rather than complain about the limitations of XAML (& current tooling) instead let's look at how things could be better.

As you might expect I'm doing some tinkering myself with regards to Visual Studio extensions that can be useful, but the XAML-related capabilities are almost entirely without the ability to customize or extend them.

I know it's not reasonable to expect big changes to be made quickly but I don't think it's unreasonable to ask Microsoft to consider improving the tooling that's currently available. So, I'm starting with a very basic suggestion: Add support for compiler directives in XAML. VS/WPF request, WinUI request, .NET MAUI request. (Yes it's sad that there isn't a single place to do this.)

It'd be great to see some more people add thoughts to those proposals. <hint /> 😉