[AdmiralAsshat]

Calibre is one of those rare examples of software where the kitchen-sink approach is absolutely warranted. It's a one-stop shop for pretty much everything related to e-book management, conversion, or creation.

I spend most of my time in Calibre just managing my library or converting ebooks between formats (particularly if I'm pulling ebooks off my Kindle or Kobo to strip their DRM). When I want to test whether the conversion was successful, the built-in ebook viewer is there. It's not great, and I wouldn't use it over some dedicated programs to read an entire book, but it gets the job done.

Then there's that rare occasion in which I might actually need to edit an ebook, because the ToC is broken or I spotted an annoying typo that I feel compelled to fix. And for that, the e-book editor tool is more than capable. Again, maybe it's not ideal (I've never tried producing an e-book start-to-finish through it), but for some quick edits, it just works.

There's alot to be said for UNIX philosophy and fighting bloat, but sometimes having everything you could conceivably need for a given purpose in one well-maintained program is comforting.

[Barrin92]

>one of those rare examples of software where the kitchen-sink approach is absolutely warranted

I actually like this approach in general and I often wonder why there's so much animosity towards it. There's something about platform-like software like Calibre, or Emacs or WeChat where it becomes more than the sum of its parts that you just don't get with just a collection of disjointed, individual tools.

[tomc1985]

It's because it doesn't fit into the modern zeitgeist of extreme testability and pandering to computer illiterates

Every time this kind of UI comes up in discussion, I feel like there is always someone groaning about how much extra effort and cost is involved with giving the user too many options. In fact, you could say that modern software seeks to eliminate all noncritical optionality. Combine this with gobs of pointless whitespace, an inexplicable need to humanize pretty much everything, and smother the user in unnecessary feelgood emotions...

And then people wonder why modern apps suck so much...

[zapzupnz]

That chip on your shoulder against everything post-2007-ish must be pretty heavy.

Modern apps don't suck. Specific design patterns suck. Not all things modern adhere to those design patterns. Not all the patterns you mention suck.

If I were hiring you to design an interface, your aversion to "humanize pretty much everything" would kick me right off the list. It reeks of tech-saavy elitism.

[tomc1985]

I have no desire to design interfaces like the ones I described, so the feeling would be mutual.

I would, however, love to be at the forefront of an anti-design movement that rightfully crushes the monotony/monopoly of modern UX

And what is wrong with tech-savvy elitism? Are you saying I should just forfeit the lifetime I've spent obsessing over this stuff to have an edge up on life? Give in to the tyranny of walled-garden and cloud-hosted nonsense?

[neolog]

> Not all things modern adhere to those design patterns.

Could you give some examples?

[aidenn0]

I think it's because integrated tools parts are often worse than the non-integrated versions and when people are forced to use them, it means removing choice.

A half-dozen well integrated mediocre tools is better than the sum of its parts, but that doesn't mean it's better than a half-dozen not-at-all integrated excellent tools.

A half-dozen pretty good tools that are well integrated is going to be excellent, but you'll still have some greybeards saying "I have to click through 12 menus to frobnicate the widget in this thing, while my old tool I could do it with a single command"

99% of "Integrated tools" fall more into the first category than the second, which makes sense; N non-integrated tools can have N parallel teams working on them, while an integrated tool cannot. This means each tool will get only a fraction of the effort in the integrated tool; it's a special case of Conway's Law.

[tclancy]

I appreciate the thought but I think there's a sort of survivorship bias in this. You remember the apps that worked for you which did this and not the ones that overwhelmed you too, even as a savvy user. The vast majority of users are not Hacker News users (even if we adjust that bar for average).

Even as a developer (not a UX designer), whenever a client suggested, up-front, there should be a "power user mode" I would ask, "Is there such a thing as a power user or just someone with Stockholm Syndrome who hasn't found a better app yet?"

[TeMPOraL]

> there should be a "power user mode"

Well, there obviously shouldn't be. There should be one mode, and that's the power user mode :).

More seriously: power users aren't born, they're made - made through repeated exposure, if the software leaves them the space to grow in.

[ocdtrekkie]

> Calibre is one of those rare examples of software where the kitchen-sink approach is absolutely warranted.

I disagree, and that's why I generally do not use Calibre, despite being an ebook aficionado. ...I already have my own ebook organization management. I'd like a good ebook reader, and I'd appreciate some of the surrounding tools, but Calibre's monolithic design isn't useful in my case.

It seems like even running the plain ebook reader takes a while because it's doing some callbacks to the larger program? Okular is a better fit for "a program that reads ebooks", but unfortunately has some really buggy handling with a number of books I've seen.

[Isthatablackgsd]

I happened to read Kovid justification[0] of this kitchen-sink approach few days ago and I agreed with Kovid. Before I was dead-set against his idea, and now I understand why it is the best for calibre.

It boils down to database and robustness. Filesystem and OS have their particular way of how it manage the files. And sometime when the file are being used and when calibre try to modify/something to the file, it can lead to unpredictable situation such as data corruption. And some OS sandboxed/isolated the app from ever touching outside of it own home directory unless explicitly permitted to do so. Sometime, it can be a permission weirdness. It is less variables for Kovid to worry and putting the software itself in control of the directory.

Also, another variable that Kovid don't have to worry about is between the keyboard and the chair errors. Users does stupid shit with it and those management software are sensitive to sudden changes without the software's awareness. Sure, you can set the path to find it again (it can be a pain for some), it didn't mean everything is jolly good. Some will force itself to rebuild the database to ensure it accounts for every bit of data. Those softwares are THAT particular and I can understand why.

Zotero does the same thing (and they preferred it), but Zotero does allows users to decide where it should be. Shoko Desktop/Server preferred their own but does allows users.

And the biggest advantage of calibre's approach is that its library only exist in single directory. You can move the folder itself without worrying the data corruption.

[0]: https://manual.calibre-ebook.com/faq.html#id33

[cassianoleal]

This is an odd take. You don't use Calibre because it doesn't fit your use-case, not because it's not good for what it's meant.

> I already have my own ebook organization management.

Calibre is an e-book management software with a reader for convenience, it's not geared towards reading.

[justnotworthit]

I hope full support for audiobooks (single file, folder of mp3, ...zip?...) someday goes in that kitchen sink.