3 reasons I'm learning about CSS

1. To get ideas for things that can be improved in XAML. Seeing some of the cool things that can be done in CSS makes me wish we had equivalents when working with XAML. (No more details here yet, but I have a list of ideas...😉) 
2. So I'm better able to make the switch to "web developer". I know some people effortlessly switch between XAML and web technologies--but that's not me. I, of course, also know that it's possible to create websites using XAML. It's many years since I did any serious web development and I know a lot has changed in that time. I'm also aware that there are a lot more employment opportunities in "regular" web development and I can't live on my savings forever and XAML work is hard to come by. I'm hedging my bets by learning something that may help me now or in the future.
3. So I can learn from smart people. Regardless of the technologies, there is often much that can be learned by watching smart people doing their work and solving problems. Watching how experts in another language think about and solve problems can be insightful and help me think about things in new ways too.

updated Feb 3rd, 2022

Windows Template Studio - reborn!

It was only a few weeks ago that I publicly announced that I'd given up on Microsoft taking the Windows Template Studio forward and so I was going to do it myself.

Now, things are changing again.

• The official Microsoft project has been reborn as just Template Studio. (Yes, that's the name I was going to use too.)
• I'll be bringing the work I've done on my own back to Microsoft's repository and the Windows-related apps that can be generated with it will all come from Microsoft.
• I'll continue contributing as a "community member".
• The extensions I've already released as previews (for UWP, & WPF) will stay as previews and be removed once official Microsoft equivalent versions become available.
• I'm reserving the right to build my own extensions that can be used for things other than Windows apps.
• There's more on the official roadmap.

As expected, the most common question right now is about the timeline.

The answer is that it's likely to take a few more weeks.

This is because:

• I can't take my work "as is" and copy it all over. There are things I can't, don't want to, and shouldn't share from my code.
• What's required in the official repo is different from my personal requirements.
• There's functionality my version has removed that I need to find ways to reinstate for the official/public version.
• There are still [regression] issues in my version (the previews) that I need to fix.

How can you help?

• Try out the preview versions I've released. (There are some things that behave differently in the release builds and so need testing widely--which I can't do in testing.)
• Raise any bugs or issues for things you find. (Are there things I've missed? If no one reports the things that I think are regressions, maybe they don't need fixing...)
• Consider becoming a sponsor. You'll be credited in the previews and elsewhere, but I obviously can't include such images in the official Microsoft version. :(

Any other questions? You know where I am. ;) 

Reasons to ask a question

I've been thinking a lot about communication (I know--fun, right?!) and especially about questions. This is because asking and responding to questions (not just answering them) is a large part of communication.

So, 12(+) reasons to ask a question:

1. To get an answer.
2. To force others to think about the question's topic.
3. To encourage someone to think about how they'd answer (even if they don't.)
4. To get attention. 
5. To get a response (that isn't a direct answer.)
6. To show (admit?) that you don't know (everything.)
7. To show a willingness to learn.
8. To show that asking questions is good/ok/acceptable/encouraged.
9. To show an example of questions that can be asked.
10. To show that you've thought about (or researched) the subject enough to be able to ask smart, informed, appropriate questions.
11. So others can hear the/their answer.
12. Never for no reason. 
13. Other?

I know the above is a generalization, and it won't apply to all scenarios but is a helpful summary of the things to consider.

Template Studio for WPF

Following on from UWP, I've now released a preview of Template Studio for WPF.

Why WPF? - Because it has a similar position within WinTS as UWP. That is, it is (I suspect) less likely to have a future in WinTS which is likely to (again--I suspect) continue to be increasingly focused on WinUI.

WPF also has an opportunity for a longer life than UWP. Because of this, I plan to extend the provided options and add the ability to create WPF apps that are based on .NET 6.

More importantly, to do this I've got the codebase to a place where it can produce multiple different extensions that build for different platforms and happily work side-by-side. This opens the door for lots of exciting new things going forward. (hint hint)

Anyway, give it a try and let me know any feedback.

I've found a bug in your open source library but I'm not going to raise an issue to log it. Sorry.

I suspect many people think this but never say it. 

It comes down to one simple fact: I haven't got the time.

I know many people will be upset with me for saying this. I also know that I've been disappointed by others who have expressed or displayed this attitude themselves.

So, why aren't I going to report the bug/issue/problem I've found?

These aren't always the case but usually:

• I assume that what I've found is an edge case. (If it wasn't someone else would have logged this previously---I recognize that if everyone thought this nothing would ever get reported.)
• I don't expect it to get fixed. (This is often tied to it being an edge case.)
• I've already spent lots more time on this than I wanted to (can really afford to) so another unplanned task related to this doesn't feel like a good use of my time. 

Expanding on that last point, a good bug report takes time to create. It depends on the project and the issue but for something non-trivial, I've found this can often take me several hours.

If what I've found is trivial to explain and recreate then creating a bug report or issue is simple and I'll always try to create one.

BUT

If it's not simple to explain and recreate, creating a bug will likely be a waste of my time and effort. 

Creating a bug/issue doesn't help me with the project I'm working on. I've just created a workaround that works with the code I have now. 

If the issue is fixed in the project I'll need to spend more time verifying the fix and (possibly) removing the workaround I've had to use.

Having found a workaround that meant spending more time than originally planned, I'll have to spend more time creating a bug (& repro), and then possibly spend even more time verifying a fix and making any necessary changes. Stopping once a workaround is found is often very appealing.

But what about other people who may encounter this issue?

Yes, creating an issue for them to find may help them. If I can share a workaround then even better.

If not an issue, maybe a blog post explaining the workaround would be something faster to create. That way at least there's a document somewhere on the internet for others to find. Sadly, very few scenarios (or projects) warrant (or allow) a brief description of a problem and a workaround.

If my aim is to make the best use of my time to help others, documenting a workaround for an obscure edge case doesn't feel like a good use of my time. Surely there are things I could do that would help more people...

This situation isn't good for anyone.

I don't want it to be like this.

I wish quick, simple bug reports were acceptable. - Even just a brief description that could be expanded upon over time. However, a description without a simple reproduction is likely to get closed rather than left open waiting for more details.

If it was an open-source project, I'd be happy to create an issue that has a description of the problem and a workaround (or link to one if documented elsewhere).

Having detailed instructions on how to report issues including having requirements on creating/including minimal ways to reproduce an issue are appealing from the perspective of a maintainer but are offputting for a person who just wants to use the library/tool and doesn't have the time to create a detailed report. 

Or could there be something better?......

I don't have any answers. 😢

I just wanted to start documenting my thoughts on this subject. I expect to have a follow-up post to this, eventually.

As a project maintainer, I'd rather know about any problem, no matter how vague or seemingly lacking in details. Knowing that something's wrong is preferable to not knowing.

At best it might indicate a gap in the documentation.
At worst it means a vague issue remains open. Possibly indefinitely.

Admittedly, if I had millions of users and loads of vague issues being created I may think differently.

Let me try and be clear (although being very aware the people I've most upset will probably not make it this far before saying something rude about me):

• I want the tools I use to get better, add features, fix bugs, etc.
• If I can and if you make it easy, I will raise issues.
• If you make raising issues hard I'm much less likely to do it.
• I know you're busy and your time is valuable. So is mine.
• If you want to report an issue with one of my open-source projects, I'll happily take as much (or as little) detail as you can provide. The more detail you provide the more likely I am to be able to do something about it. But, I'd rather know there was a problem, even if it can't easily be recreated (yet!)
• I'm aware this approach may not apply to very large projects. (If only this was my problem.)

Thoughts? tweet at me