Fix the basics instead of feature war, my opinion, not a criticism

[xXRoxXeRXx]

I like Yuvomi, and I've even contributed a thing or two myself. But what bothers me is that they keep adding feature after feature instead of really focusing on the essentials.

I updated it again today, and what can I say? At first glance, I see yet another bunch of UI glitches. The UI is still inconsistent across some screens, etc.....

Why don’t we focus first on the user experience and the interface instead of constantly adding what I see as mostly pointless features?

Once that’s done, we’ll have a solid foundation on which to integrate new features in a consistent way.

[ulsklyc]

Thanks a lot for taking the time to write this out - and even more so for having contributed to Yuvomi yourself. Feedback like this is exactly what keeps the project honest, so I genuinely appreciate it.

Just to give some context on the direction: what you're seeing as a "feature war" is mostly me trying to integrate community wishes so the app becomes complete in its core functions. The only genuinely new modules recently are Health and Rewards - every other change was an extension of an existing module, and almost all of those came directly from user requests. So the goal isn't feature-piling for its own sake; it's rounding out the foundations people have asked for.

That said, your core point stands and I take it seriously: stability comes before features, and UX/UI consistency matters. If you look through the release changelogs, you'll actually see that consistency and polish passes are among the most frequent kind of release - it's an ongoing effort, not an afterthought.

Where you can help me the most: I'd be grateful for concrete examples of the inconsistencies you're running into - which screens, which glitches. The more specific, the better, because that lets me prioritize the fixes instead of guessing. If you want, drop them here or open focused issues and I'll work through them.

Thanks again for caring enough to push on this. 🙏

[xXRoxXeRXx]

To bring the product management perspective into this: The goal, of course, is to build a tool that’s as useful as possible. However, good product management often also means deciding what not to build. If we try to address absolutely every request and every edge case right away, we quickly run the risk of overloading the product, the feature creep... This usually leads to a cluttered UI, increased complexity in maintenance, and, in the worst case, a loss of focus on the core features.

My focus is therefore currently a bit more on preserving the project’s core philosophy. Stability, a streamlined, intuitive user experience, and a focus on the essential use cases, rather than maximizing the feature list.

Of course, that doesn’t mean good ideas are off the table! Rather, it means we have to carefully weigh which features will have the greatest impact for the broad user base and how they can be seamlessly integrated into the existing concept.

Sure, I can create issues. I'll see when I have some time :)

[ulsklyc]

Honestly, this is exactly the mindset I want to build the project with, so thank you for putting it in product-management terms rather than just a wishlist. Deciding what not to build is the hard part, and you're right that it's where the core philosophy actually gets protected.

And to put money where my mouth is rather than just nod along: the release I pushed today, v1.20.0, has zero new features. It's entirely stability and UX/UI consistency work - one shared, labeled search field across Notes, Contacts, Documents and Birthdays; the Budget tabs moved onto the same tab component and keyboard behavior as the rest of the app; the Document filters brought in line with the pattern already used in Contacts; plus a genuine bug fix where the active tab highlight could drift out of sync with the content shown. Nothing added, a lot tightened.

That's the kind of release I want more of, not fewer - and feedback like yours is a big part of what keeps pushing it that way.

No rush at all on the issues, whenever you find the time. Even two or three concrete screens would already help me prioritize. 🙏

[raninehme]

First of all, thanks for all the work you're putting into Yuvomi. I've been testing it quite a lot recently, and I really like what the project is trying to become. Having so many useful things together in one self-hosted app is a big part of why I'm trying to move more of our household into it.

I also agree with the general point here about slowing things down a little and focusing more on polish and consistency.

From the perspective of someone actively testing it, releases are coming very quickly and often contain enough changes that it can be difficult to properly keep track of what changed before the next update arrives. My partner is also trying to move over to Yuvomi, and for someone who is still learning the app this is even more noticeable. Things can change again while she is still getting used to how a feature works.

I've also come across a few smaller UX/UI things while testing that I'd be happy to share. Most are just little usability details or places where the flow could perhaps be made a bit clearer.

I can start opening those as focused discussions or issues so they're easier to look at individually and don't get lost in a broader conversation like this.

For me, Yuvomi already has a really strong feature set. I would personally rather see some time spent making those existing features feel really solid and consistent before adding too much more.

Thanks again for being so open to feedback and for actively engaging with the community @ulsklyc * Yuvomi contributors

[ulsklyc]

Coming back to this with something concrete rather than another promise.

v2.38.0 is a release with nothing new in it for the household. It went looking for exactly what you both described - inconsistency across screens - and measured it instead of guessing. What it found in the empty and error states, the parts of the app you only see when something is missing or broken:

• 52 empty states were assembled by hand across 15 pages instead of going through the shared renderer that four other pages already used. Not one of them carried an ARIA role, so a search that found nothing was never announced to a screen reader and an error was not recognisable as one. 48 used a plain <div> where the title should be a heading, which on an otherwise blank page means the first screen of a module had no heading at all.
• Four error states were dead ends with no action at all, so the only way forward was reloading the browser. One of them printed the raw English server message into an otherwise translated interface; another used the module's own name as the error title, which made a failure read like an empty page.
• Worst of the lot: three modules reported a failed load through a toast that faded after seconds and left their empty state standing. On a server error the tasks page said "No tasks - all done?" and offered "Create task" as the only button. Budget said there were no entries this month. The data was still there in every case.

That last one is the clearest example of what you meant, @raninehme, about polish being more than looks: it is not a visual glitch, it tells you your data is gone and then offers you a writing action as the only way out.

What keeps it from coming back. The shared renderer is now the only place allowed to produce that markup, and the guard for it is a rule over the whole frontend instead of a list of files. That distinction is the actual lesson here: the old guard covered the four pages that were already correct and said nothing about the other fifteen, so the backlog sat there green for four weeks. Same for the toast rule - it existed, it worked, and it only ever looked at four pages.

On release pace, @raninehme - that is fair and I have no clean answer yet. Releases are frequent because most of them are small and I would rather ship a fix than batch it. But you are right that "small for me" and "small for someone still learning the app" are not the same thing, and your partner's experience is the better measure. I am not going to promise a fixed cadence I would then break; what I can do is keep the release notes written for the person updating rather than for me, which is what the store notes and the changelog entries are for.

Keeping this open. It is not a ticket to close - it is the standing argument for the next time I am tempted to add a module instead of finishing one. Concrete examples remain the most useful thing either of you can send; every finding above came from actually running the app against a broken server, not from reading the code.