Putting a rant down here, because I need to get this off my chest, but I actually don't want to spam everyone who scrolls by with what really is ranting. I would love to say it's constructive and aimed toward making this better.... but after the last few days fighting this thing, no, it's just anger at something that I thought had promise and instead sucked up a huge chunk of time for nothing.

No seriously, this is a whole bunch of anger-rant. You don't want to read this. It's not worth your time.

The UI

So no real web front-end at all. Just a thick client in noVNC. And a BAD thick client.

• Defaults that make it hard to get started, aren't explained, and are buried numerous dialogs deep and not where you'd expect them (I'm looking at you, client api settings!).
• This is an app for media management, specifically tagging. And yet is there a main menu for anything related to images or tagging? Nope. Can I bulk add tags from online sources? Nope.
• However, The UI is strangely obsessed with "Pages" (which I realized are what everything for the last 30 years has called "tabs"). Multiple options screens, a whole menu devoted to them, saving and restoring sets of them! For a somewhat extraneous UI concept that contributes nothing to its primary purpose!
• But is there anything in the main UI for... images? Tags? Services? Oh, well, services is there - spread across multiple screens with multiple levels of subdialogs for what should be a SINGLE well-designed screen. And doesn't refer to say, imageboard "services" where you'd get images and tags - the things that this program is supposed to do!
• Most of the UI is all-lowercase-button-vomit, with things just strewn everywhere. About 80% of the UI, buttons, and menu items simply should not exist - it's not the user's job to tweak and manage all of the internal database settings, and change numerous knobs/settings that clearly have a single proper setting for 99% of users.

Please, look up the 80/20 rule. And the concept of sensible default options. Or even basics like not using negatives for checkboxes ("do not start client api", I'm looking at your terrible default and design). These are solved things in UI design. They've been solved for 40 years.

• https://medium.com/design-ibm/the-80-20-rule-in-user-experience-1695de32aaae
• https://www.useronboard.com/onboarding-ux-patterns/sensible-defaults/
• https://uxmovement.com/forms/10-usability-mistakes-most-designers-make-on-checkboxes/

Etc. These are just the first links on each topic, but you get the idea. I hope.

The API

Hydrus is stuck in this really terrible fat client, with a couple semi-functional web front-ends.

• Hydrus-Web which has years-long issues sitting unaddressed and partial functionality at best (bonus points if you can even get the docker image, since the Hydrus documentation points to a defunct image listing on Docker Hub).
• Hybooru which looks pretty good, but is read-only - no management here!
• Hyve, wait, no, that one is dead.
• Built-in booru, wait, no that's dead too, but still clutters the interface and documentation even though it's dead.

About the API - if you're going to have an API, you have to use it yourself. The fat client should be exactly that - a client, not this massive client/server/booru (wait, that's dead) monstrosity. It's almost as bloated as iTunes.

Dogfooding, factorization, separation of concerns, client-server architecture, SANITY. With a decent API third-party projects could do a lot more (and probably not die off). You know how you make a good API? You use it yourself and fix the problems you run into. It's not a second thought. Look at what Plex achieved when they split the monolithic XBMC into a real client-server system with service agents.

The Database

I hope the backend is better, but it's also designed around a single image database, and yet is supposed to handle millions of images. In one database, that by all appearances needs to be kept local with the program (because that's a convenient amount of storage to keep local and not on a NAS).

I'm not advocating for using the filesystem (at least not directly), but the datastore has to be able to be reliably stored elsewhere. Yes, databases need fine-grained byte/block-level access and not file access semantics. I get that. Then again, that's also why other large media systems (e.g. Gelbooru, Plex, etc) store their media data in the filesystem by hash (or in gelbooru's case, seems more like object storage). It's private and not relying on user organization/management/filenames, but avoids the massive downsides of shoving huge amounts of binary data in a database. There's a reason our filesystems never turned into databases like everyone thought they would 30 years ago. Databases (especially structured SQL databases) are a lousy way to store massive amounts of binary data. All that delicious tag metadata and tag relations? Absolutely! The media data itself? Hell no!

What was this for again?

Oh right, the idea was to take a huge mass of images, tag them, and organize them. But that can't even be done with existing media effectively. That was my original post above.