Mobileread
Reorganizing the Viewer Menu
#1  Wingsmith 06-28-2020, 11:22 AM
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
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 Warning below






image »

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
Spoiler Warning below






image »

Spoiler Warning below






image »

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 Warning below






image »

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 Warning below






image »

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 Warning below






image »

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!
Reply 

#2  kovidgoyal 06-28-2020, 12:37 PM
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.
Reply 

#3  georgemk 06-28-2020, 02:50 PM
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.
Reply 

#4  BetterRed 06-28-2020, 06:17 PM
@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

show attachment »

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

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

BR
Reply 

#5  Wingsmith 06-28-2020, 09:58 PM
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.
Reply 

#6  kovidgoyal 06-28-2020, 10:07 PM
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.
Reply 

#7  BetterRed 06-29-2020, 05:55 AM
@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.

Quote 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
Annotation 2020-06-29 195207.jpg 
Reply 

#8  kovidgoyal 06-29-2020, 06:33 AM
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.
Reply 

#9  Wingsmith 06-29-2020, 10:32 AM
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?
Reply 

#10  Wingsmith 06-29-2020, 10:37 AM
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.
Reply 

  Next »  Last »  (1/2)
Today's Posts | Search this Thread | Login | Register