UI summary representation without a treeview?

I tried to start this discussion on Twitter & Fosstodon but didn't do a good job of describing things with limited words.

I'm trying to find examples of the summary representation of a UI (could be a web page or a native app) which don't use a treeview.

For instance, assuming you're reading this in a browser, open the developer tools (F12), and you'll see something like this in the Elements tab. All the triangles are expandable and collapse nodes. You can expand an entry to see its children. It's a basic "tree view" layout. 

Or, for an app, here's the Live Visual Tree from Visual Studio

and the Document Outline

Or this from Figma:

They're all tree views.

I'm looking for examples of alternative UI for representing all (or part) of a UI "tree".

Got any examples?

I'm most interested in examples intended for developers that are clear and easy to understand. Or, at least, explained. Not different for the sake of it, but that are trying to communicate something different or in a different way.

My thought process was triggered when someone told me this is the only way this can (and has) to be done but couldn't tell me why.  I'm also suspicious that this might be leaking the abstraction of the underlying data model when this might not always be the best or most suitable thing for the person viewing it.

The only real variation I can find is like this (from http://bioub.github.io/dom-visualizer/), but all that really does is flip the axis.

Before I spend time exploring different options, I'd like to know why "everyone" does it the same way or if others have tried doing different things and what they learned from the process.

Know of anything?

Code therapy (AKA: Lessons from a "mental health" Hack Day)

I'm halfway through my drive to the event and have stopped at a well-known coffee chain. While I wait for my drink, I see a poster on the "community noticeboard" advertising an art therapy course. It strikes me that there's a similarity between such events and how I'm planning to spend my day.

It starts a few months earlier when lamenting how depressing it can feel when work isn't satisfying.

Part of the reason I'm a software developer is that I like the job. I like the aspects that are creative problem-solving. 

I get pleasure from creating something that makes other people's lives better or easier. Even if only in a small way.

The satisfaction I get from shipping something new (even if only an update) energizes me.

But sometimes work is tough.

Sometimes it feels like days or weeks go by without real progress.

Sometimes a task that can bring joy and energy can suck!

Sometimes, the bad parts of the day can be offset by doing personal, fun projects in the evening.

But then there can be extended periods when life, family, and other responsibilities take priority.

So, we hatched a plan. What if we set aside a day to focus only on fun personal side projects? It doesn't matter what you work on as long as it makes you happy.

And for a few people, in certain circumstances, it can be a lifesaver.

Sitting on a bus heading into Cambridge, I'm excited about what today may bring.

I have a whole day (the room booking is for 8 hours) and can do whatever I want.

I've got quite an extensive list.

I know I won't even get halfway through it, but the prospect of completing any of these things that have been in the back of my mind, waiting for the right opportunity to get started, excites me.

This is going to be a great day.

It doesn't matter that only half a dozen people are expected.

Selfishly, this is all about me. It's my chance to do the things I want to do.

That I don't need to worry about the logistics of managing lots of other people is a blessing.

We booked a bigger room than we need and invited lots of other people in the hope it might benefit them too, but if no one else turns up, it's better for me as I'll have more time to focus on my projects.

The reason for booking a room somewhere is that it helps avoid the distractions of home. There's no Xbox or TV here to tempt my attention. There are no family members to knock on the door.

That this is weeks in coming means, I've primed myself to think that today is special. Days like this don't come around often, so I want to make the most of it.

That others have thought the same and turned up is an additional encouragement to make the most of this opportunity. Plus, we have the time and space to have niche, technical conversations that we don't get the chance to have elsewhere.

I knew my list was unrealistic. I knew that as I added more items to it, I will end up crossing off fewer things than I initially hoped.

But I also knew that doesn't matter.

Because, as time goes by, I am getting things done. The project that's been niggling away in the back of my mind for the last few months is slowly creaking out of my fingers, through the keyboard, and into my laptop.

And it works. In my mind, I always knew it would, but now I can prove it. I can see it running in front of me. 

It's far from finished. Far from something other people could use. Yet. But it's slowly taking shape.

I'm well beyond proving this concept. This is going to be a "real" project.

Can't stop for lunch.

No time.

Don't want to stop. 

Making this progress feels too good to interrupt.

That list I started writing last night (and added to this morning) no longer matters.

I know I'm not going to cross anything off it.

But the sub-list for the first thing I chose to work on has more items completed than not. And I know that more ticks are coming soon.

It's not a "proper" hackathon, but I start to get into a hackathon mindset.

As we start to think about when we'll have to leave, I decide I need to treat these last two hours as if I was preparing for an end-of-hack presentation.

How much can I get done before time runs out?

How can I best get this in a position to demonstrate it to others?

There's no competition. There are no prizes.

But I know that feedback from others will encourage me to keep working on this in the weeks ahead. (Whenever I get the opportunity.) The encouragement of others is likely to help me strive to make some opportunities.

The entry in my calendar for today says "destress hack." This is the placeholder I put in when we first booked the venue.

Officially we called it a "mental health hack." I assumed that "mental health" was more appropriate for communicating the idea as it's such a widely used term and--in my mind at least--more socially acceptable and supported.

Regardless of the name, this was unlike other hackathons. No theme or topic. No competition. Simply a challenge to myself.

But really, it was like the activity on the poster I saw this morning.

This was therapy.

It might not be art, but I feel better for it.

This has made me feel better about life. And work. And myself.

MAUI App Accelerator version 1.3 is now available!

TLDR: Go here and download it. In addition to bug fixes, it adds a new page and 6 new features you can add to the generated app. 

Yes, this list is getting very big!

I'll be honest; this release has taken longer than I expected and isn't as planned. If you're following the activity on GitHub, you'll have noticed that most of what was originally planned for the 1.3 release is now scheduled for v1.4.

That's probably not what you're here for though. Here's what's included in this release.

A new page: MediaElement

A simple page that includes the MediaElement control. This is for you if you want to play videos in your app.

New Features:

BenchmarkDotNet

Add an additional project to the generated solution that is set up to run performance benchmarks on your code with BenchmarkDotNet.

EFCore.Sqlite

Add a reference to the Entity Framework SQLite library so you can work with SQLite databases with Entity Framework.

Akka.Hosting.Maui

Use Akka.NET actors in your .NET MAUI app.

AlohaKit

Add a reference to the AlohaKit control library to use their controls in your app.

SimpleToolkit

Add a reference to the SimpleToolkit control library to use their controls in your app.

Uranium UI

Add a reference to the Uranium UI library to use their controls in your app.

If you've made it this far and haven't already, install the extension or update it if you already have it installed.

https://marketplace.visualstudio.com/items?itemName=MattLaceyLtd.MauiAppAccelerator

Suggestions for what else to add is appreciated, as are reviews, and sponsorship.

Three years with GitHub Sponsors

I'm trying to be a bit more intentional about my career, money, and where I spend my time/effort. As part of this, I thought it might be interesting to look at my sponsorships via GitHub Sponsors.

I know many people publish full income reports. I don't feel confident enough to do that, but I hope that some of this analysis will still interest others without monetary sums.

Here's the key graph. It's the total amounts received each month.

While not a smooth graph, it's definitely trending up!

Public vs private sponsorships

There are two broad ways of grouping sponsors. Those that are public or private; and those that are one-off or recurring.

Let's look at the public vs private distinction first.

It's easy to see who the public ones are. Their avatars are shown on my sponsor page.

To save you from having to count, that's 35 public and 12 private.

The only difference to me is that I don't publicly thank the private ones by name.

But are there any differences between the different types of sponsors?

Different amounts from different types of sponsor

The figures in blue (on the left) of each group are the averages from all sponsors. However, as the very spikey graph above might suggest, there have been a few sponsors choosing larger amounts which skew things slightly.
The orange bar excludes the largest and smallest value from each group when calculating the mean.

Recurring sponsors typically pay less each month than a one-off sponsor. This isn't surprising and is almost encouraged.

I found it pleasantly surprising that amongst one-off sponsors, private sponsors pay about 17% more. I'm unsure why or how to use this information, but it intrigues me.

I didn't separate the public and private recurring sponsors, as only one is private.

But averages don't tell the whole story.

Total amounts from recurring vs one-time sponsorships

Unsurprisingly, while I have many fewer recurring sponsors, and the monthly average from each one is less than a one-off sponsor, the total amount from them is nearly three times the amount from one-off sponsorships.

I'm not sure this graph needs a legend, but the blue wedge is the total from one-off sponsors, and the green section is from recurring sponsors.

Who I sponsor

I currently only sponsor 1 person through GitHub Sponsors, but I sponsor 6 people through Patreon. Again, without using actual figures, it's only in the last couple of months that the amount I receive through sponsorships is more than the amount I give via Patreon. It's the circle of creative people supporting each other.

Other "interesting" things I noticed during the analysis

One person has made multiple one-off sponsorships.

One person started out by making a one-off sponsorship and, a few months later, came back as a recurring sponsor.

Recurring sponsor durations vary greatly. From 2 months to 3 years (and going). I see no discernable pattern to this.

In summary

While I'm not giving actual figures, I will say that the total for the whole period is about half of what I'd earn in a typical month of paid work. However, over the last three years, this has still been really helpful. As in the last 3.5 years, I've only had paid work for 8 months. (Yay, COVID!)

The most crucial point was when sponsorships helped pay the balance of an unexpected tax bill when I hadn't worked in nearly 2 years!

Now I'm nearly debt free again, and this makes me think about how I can (and should?) give more back to other creators who I want to support.

I also need to think about how, if at all, I can use the above analysis to help encourage more people (or organizations) to become sponsors. (Either of myself or others.)

Do you really need MVVM?

MVVM is a popular design pattern, but I think it is often misunderstood, and I frequently encounter people with strong opinions about how/when/where it should be used.

It's a powerful and useful pattern, but I meet people who use it that have never questioned if they should. It's just "what everyone does" and has become a default for many people.

It being a default isn't necessarily a bad thing, but never questioning decisions can be.

The MVVM pattern allows for separation between the UI/presentation layer and application or business logic.
It is commonly understood to provide 3 potential benefits:

1. Increased testability (for business/application logic).
2. Reuse of business/application logic in different projects/solutions/apps.
3. More easily allow different people to work on the UI and other layers simultaneously.

And yet, I see people who are the sole developers on a project, don't write any tests, and don't need to (re)use any of the code elsewhere being dogmatic about using a pattern for which they get none of the intended benefits.

I admit that there can still be other benefits to using the pattern, but it's always worth questioning whether you should use something if you're not getting (or don't need) the benefits it was designed to provide.

Are you strictly sticking to "rules" of "how things are supposed to be done" when you're not getting or using any of the benefits the pattern was designed to enable and encourage?