Reorganizing the Viewer Menu

[Wingsmith]

I've been reading a lot of books using the Calibre Viewer lately, and while there's a lot I love about the viewer, I often find myself wishing the UI were a little more streamlined. In the spirit of open source, I'm prepared to try updating the UI myself. However, before I attempt such a thing I'd like to get some feedback from the community here to make sure such changes would actually be welcome.

I'm hoping that in posting this here I can

• get a sense of whether I should go ahead and try to implement these designs
• get feedback the particulars of the proposed design
• get tips from more experienced developers on how to get started, and
• maybe see if there's anyone who'd be interested in working together to get this work done.

What It Looks Like Now

For reference, here's what the viewer menu looks like in the current desktop app version of the viewer:

Spoiler:

The web version is similar, though a bit simpler and with additional "Sync" and "Delete" options.

Design Proposal

I'd like to propose some changes to the current design with the aim of

• grouping related controls
• reducing clutter by moving some of the more obscure options into a menu
• creating a design that works equally well on desktop and mobile devices, and
• retaining all existing functionality

Spoiler:

Spoiler:

Note: I've used Google's material design icons in the mockup above for convenience, but would probably want to stick with existing icons, at least initially.

Information Architecture

I've tried to group related functions together, like so:

Spoiler:

Less frequently used options would go in the More menu at the bottom-left. The exact options available in the More menu would depend on context.

For example:

Spoiler:

Visual Design

I've tried to make the visual design distinctive and modern, while harmonizing with Calibre's existing built-in color schemes.

The color of the UI is inspired by the viewer's warm, parchment-colored background option. I've used a bright red-orange for the progress indicator and hover states, to contrast with the UI's more muted beiges and browns, while keeping a warm, cozy feel overall.

Spoiler:

Next Steps

So, yes. Before I take any further action, I'd like to hear from the group here. If you have specific concerns or ideas for improvement, please let me know! I'm used to critique and will not be at all put off by disagreement over particulars of the design. I'm happy to further explain the thinking behind the above design choices if your interested (just thought this post was already long enough!)

If the design doesn't resonate, I'm happy to leave things as they are and just consider this a fun design exercise.

If these are changes you'd like to see implemented, I'll give it a shot. I'm a bit of an amateur when it comes to actual development, so any advice or help you might be able to offer would be very much appreciated.

Thanks and, please, let me know what you think!

[kovidgoyal]

I like your goals, however I think your biggest problem will be deciding what are the obscure options, because I suspect every user will have a different set of options they consider unnecessary. Let's see what feedabck you get from users.

[georgemk]

Looks very nice.
I'm not a fan of the current viewer pop up menu as it doesn't look like menu but a block of buttons.
And I have no view on popularity of menu options. As long as they can all be access by clicking on 1 icon to show a list of options, I don't think it matters too much which icon triggers it.

[BetterRed]

@Wingsmith - I'd prefer a 'normal' context menu, as I have in other computer application software, including the calibre library manager, the calibre editor, browsers, WP, spreadsheets etc. One that I can navigate with the keyboard, configurable would be nice, but not essential.

Why? Because of disability I find point and click interfaces awkward and inaccurate. Whilst my keyboard shortcut memory capacity is pretty good, it isn't infinite

By way of illustration, this is my calibre library manager setup



The Preferences menu item (top left) is there because… Ψ³

Coherent Fluent ribbons are OK too, I can drive them with one finger

BR

[Wingsmith]

Thanks very much for the feedback. Sounds like there may be more design work to do, but this gives me confidence to at least start poking around the code base, trying to figure out how the menu UI is constructed.

@BetterRed - Keyboard accessibility is definitely important! Would it be sufficient to ensure that all buttons in the menu are logically ordered tab-stops? If not, are there other keyboard-based interactions you'd hope for or expect? I'm not familiar with Coherent Fluent ribbons, but I'd be interested to learn more.

[kovidgoyal]

The existing menu is created in overlay.pyj in the class MainOverlay. Be aware that calibre 5 is just around the corner and it dds annotations functions to that menu (relevant code is in the annodb branch). Instructions for setting up a calibre development environment are here: https://manual.calibre-ebook.com/develop.html

If you wish add icons for the viewer interface, you add them under imgsrc/srv

In your mockups you have overlooked the back/forward buttons, and what is particularly dear to my heart personally, the clock, as I tend to get absorbed in reading and lose track of the time.

[BetterRed]

@Kovid - I've never understood why a desktop (or laptop) program (ebook-viewer) that is based on the HTML layout engine used by Google's Chrome Browser doesn't have a common or garden context menu like every other desktop app - including the Chrome browser

Care to explain.

Originally Posted by Wingsmith

@BetterRed - Keyboard accessibility is definitely important! Would it be sufficient to ensure that all buttons in the menu are logically ordered tab-stops? If not, are there other keyboard-based interactions you'd hope for or expect? I'm not familiar with Coherent Fluent ribbons, but I'd be interested to learn more.

Yeah - I guess tabbing would be OK, I don't want to be proscriptive, I can live or workaround most things

My coherent Fluent ribbon remark wasn't serious, inside joke with no one in particular

Fluent Ribbons are a feature of MS Office that most people say they don't like. Many developers take there old menu and button bar user interface and convert 1:1 to a ribbon interface - and end up with a jumbled mess - i.e. incoherent. If you read the MS guidelines they state pretty emphatically that that approach is unlikely to work.

What OS do you use, all the Fluent applications I can think of are Windows. If you have access to a recent Windows 10 system, the File Explorer program has a Ribbon interface.

BR

[kovidgoyal]

because context menus are not usable on touch screens. And I cant be arsed to maintain two UIs. Not to mention that there are way too meany controls for a single menu.

[Wingsmith]

Thank you, Kovid! Knowing where to start will save me an enormous amount of frustration and confusion.

The design has back/forward buttons floating at the left-middle and right-middle. They're a little easy to miss in the static mockups, but should be more apparent when they appear and disappear with them rest of the menu -- that kind of transition makes it much easier to spot the elements being added to the screen.

I definitely relate to losing track of time while reading! I removed the clock because I thought that in most cases it would be more natural just to check the system clock, however I can see how in some contexts it could be useful. Would I be right to think that the clock is mostly meant for use in full screen mode? Are there any other circumstances where it's important to have a clock in the viewer itself?

[Wingsmith]

I'm excited for the addition of annotation functionality! Sounds powerful and useful -- at some point I'll try putting together some mock-ups that include that capability as well.

[kovidgoyal]

Yes, the clock comes in handy in full screen mode, quitting full screen mode is fairly painful as the window size changes, causing you to lose track of where you were. In windowed mode on both desktops and mobile devices it is of course possible to just check the system clock with a glance.

[BetterRed]

Originally Posted by kovidgoyal

because context menus are not usable on touch screens.

Touch screams - a blight on humankind

Originally Posted by kovidgoyal

And I cant be arsed to maintain two UIs.

That's a better reason than the one I feared - qtwebengine doesn't allow context menus

Originally Posted by kovidgoyal

Not to mention that there are way too meany controls for a single menu.

Wingsmith's is proposing to group related controls. In a context menu that would be flyout submenus. He also mentions moving obscure options to a menu - question for him - why not another group of controls labelled Miscellaneous?

He also wrote "creating a design that works equally well on desktop and mobile devices". Most desktops, and laptops, don't have touchscreens.

Aaaaand… on reflection, the 'touchable' Preferences panels are a much bigger issue than the 'touchable' context menu… for me at least.

FTR: I have a 'thing' that resembles a stick of chalk attached to my phone, and I sometimes use an MS Pen on my Surface Go - MS sell a Slim Pen, what I want is a Fat Pen

BR

[kovidgoyal]

Yeah my major concern with this redesign is the significant decrease in discoverability. While the current design certainly does come across as a "big blob of controls", if you can get yourself to read the labels you at least know what is possible. With the redesign you have to click through and/or hover over controls to even learn what can be done.

Of course this is a fundamental tension, you cannot both have a highly discoverable and a simple looking interface at the same time.

[Wingsmith]

Update: Got my development environment all set up and started exploring the code. I'll probably be a little slow to make progress, just because my schedule's a bit erratic at the moment, but I'll keep working on it when I can and posting updates here to let you all know how it's going.

@kovidgoyal -- I agree that the big advantage of the current UI is that nothing is hidden. If you read all the button labels you know exactly what's available. The downside of that, though, is that reading all those button labels is slow and kind of overwhelming. In addition, because the buttons are all in one big blob it's hard to build muscle memory for different actions. At the very least, I think it's safe to move the developer-focused options into a sub-menu, as most users probably won't ever want to reload or reset the interface or open the inspector.

[kovidgoyal]

Take your time, no rush, I am not going to be able to be involved until calibre 5 is released.

And yes, there is definitely some compromise to be had between ease of discovery and simplicity.