The User Interface…

[baskerville]

I'm probably not going to surprise you by saying that koreader's UI isn't the greatest UI I've ever used.

Here's the, non-exhaustive, list of problems / suggested improvements:

• Based the average human finger tip area, some icon bars have a correct height, others don't. More generally, the vertical and horizontal padding used around interactive items is often wrong.
• The font used for the dictionary definition needs to be a serif font.
• The top of the file manager should display the menu icons, not File Manager (one useless tap…) and the battery percentage and time should appear at the top right, not at the bottom of menus.

Please checkout this course on user interface design.

[KenMaltby]

A good deal of that is subjective, and referencing a textbook or other academic source, doesn't actually change that. There can be a good deal to improve the existing interface, but there is a lot to be liked with it as it is. While you may feel there shouldn't be a UI that appeals to the more technically literate, I don't believe in such oppression/discrimination. Not everyone thinks the lowest common denominator should rule.

Luck;
Ken

[Frenzie]

Programmers are often affected by a strange disease: they believe that they don't need to know anything about interface design to design an interface.

Who did you ask? :-)

[pazos]

UI isn't the best "feature" of koreader, but I like it 💃

There is room enough to improve Koreader UI, but IMO is better to open specific issues to fix those one by one.

[houqp]

Programmers are often affected by a strange disease: they believe that they don't need to know anything about interface design to design an interface.

I don't think this is the case for us. We do care about UX here. In fact, I interact a lot of with UX designers at work for my projects.

The real problem here is lack of resources. Right now, I am still working on fixing various stability issues of the reader. The UI framework is lagging behind and resulted in horrible callback hell in the code base. It's also not easy to create widgets with the current UI API. Lacking of proper UX design worries me less compared to a shaky foundation of the code base.

I want a good UX for KOReader as much as you do. If you have time to help work on this, that would be awesome.

Based the average human finger tip area, some icon bars have a correct height, others don't. More generally, the vertical and horizontal padding used around interactive items is often wrong.

Everything was nicely calculated back in the days when the new touch UI code was written to support the only one model I had: Kindle Paperwhite. Since then, KOReader has been ported to many more platforms and devices. I don't even use kindle myself anymore ;) And this is where things got real messy. It's not easy to have a common code base that works for different models from different companies. Even harder when the developers only have access to a limited set of devices. For example, I just started using my Aura One a week ago and I noticed the icon at the top of touch menu is too small for me to touch. This has never been a problem in my old Aura HD.

Use better fonts: the sans-serif font used almost everywhere (Noto Sans) isn't great or is badly used. Obviously, the font used for the dictionary definition needs to be a serif. And more generally, there's a perceivable lack of understanding of (good) typography.

I don't think anyone has spent time tuning typography in the UI yet. I can't speak for other developers, but I am not an expert on typography so I actually don't know how to improve this without doing some research on my side. If you can draft a list of actionable items, that would be great. Or even better, send fixes in PRs :)

Is PNG the best icon format known to man? Using non-scalable graphics on a 300 DPI e-ink screen?

Definitely not. The history of this is KOReader is only able to render non-scalable image formats. PNG turned out to be the easiest pick to unblock the development at the time. Remember like I mentioned earlier, the code was written to only target Kindle Paperwhite at the time.

Why is there some gray in the find icon? For the sake of inconsistency?

There's too many menu entries in each top categories. Some of the icons are hard to interpret: what does pokeball mean?

Why is there so many specific (and verbose) menu entries intertwined with useful ones? The category of menu entry is hard to memorize. Why are menu lists as wide as the screen instead of being adjusted to their widest entry?

The (badly drawn) chevron icons are used everywhere (with an incorrect amount of padding): what's wrong with arrows?

The icon for quiting koreader is home: seems like a joke… Also, why is this uncancellable action icon not as far as possible from the other regular menu icons?

I would partially blame this on lack of free and open icons at the time. And partially, it's due to limited time and resource. If I recall correctly, the touch menu was done while I was taking a crazy write your OS from scratch class at CMU where I literally don't even have enough time to sleep and eat :)

If you have good recommendation for icons and reorganizing categories, I will happily merge the changes.

The top of the file manager should display the menu icons, not File Manager (one useless tap…) and the battery percentage and time should appear at the top right, not at the bottom of menus.

I wouldn't even call file manager a UI. It's really just a hack created to let people pick which files to open. @chrox was working on a koreader home project to create a proper home screen for KOReader. But he just graduated from grad school not long ago and is also busy with his new fulltime job. So it's possible that he won't have enough time to finish it.

Battery percentage and time was added long after touch menu was created. The real issue here is we don't have top banner widget so people just looked for whatever empty space they can use. Did I think this is a good UX at the time? Not at all. But I merged it nonetheless because it provides some useful information for those users and I did not have time to design a banner widget.

I think It's good to discuss this as a community and hopefully we can make couple self-contained actionable issues out of it :)

[pazos]

The icon for quiting koreader is home: seems like a joke… Also, why is this uncancellable action icon not as far as possible from the other regular menu icons?

If you have good recommendation for icons and reorganizing categories, I will happily merge the changes.

@houqp , @baskerville .
I have one recommendation. Makes home more home 👍

[hwhw]

I started with the foundations of the UI framework from scratch. Mind you, Koreader started as Kindlepdfviewer, meant for a Kindle 3 (which was the device I had at that time - or was it the short time that I had a Kindle DX?). People reported that it did work on a Kindle 2 - with minor changes. It was .... keyboard only. An event loop, mostly. But it had the Lua foundations laid out.

The Kindle 4 came (which was a problem that I mostly ignored - but Librerator was forked!). The Kindle 5 came. The keyboard was not coming back, that was clear. At some point, I got a KPW. I wanted a reader on there and others wanted that too. Koreader emerged from the Kindlepdfviewer source code - and development happened in the same repository even. You can find it back down the history here.

There was no UI framework done in Lua - at least, not that I could find one. Well back in the day I played with some UI frameworks that were able to work with some very specific restrictions, most prominently (yes, this sounds mundane) 4bpp framebuffers (which are a mess to work with). Those were written in other languages - like C++ (QT, but it felt too heavyweight) or C (MicroWindows, but it felt too esoteric). So it was "roll your own". With all the drawbacks: dirty hacks, lack of documentation, ... - it worked to some extent, though.

I'm not sure if the current code base might be too deeply entangled with the UI framework as it is. Stands to reason. However, MuPDF learned to render SVG in the meantime. So there is a possibility to go for vector graphics in lots of places. Pixel-based coordinates and measurements might be a problem, though.

[houqp]

I think rolling our own UI framework was actually a good decision. One of the biggest advantage is it makes the code highly portable. All you have to do is change the low level drawing bit and input loop for a new platform and koreader is ready to go. And the UI framework we have right now is a huge improvement over what KPV had offered ;)

I am not too worried about code being too deeply entangled with the UI framework API. It shouldn't be hard for us to implement the current API on top of a new framework. This will make it possible for us to incrementally migrate the current code base over to the new framework.

Another thing we can do is to refactor KOReader using a C/S model, where the core logic lives in a headless server and UIs are just clients that talks to the server via RPCs. It will fully decouple the UI from the core logic so people can write the UI in whatever framework/language they want. This will help work around the memory leak issue since UI can spin up one core server for each opened book and have the OS reclaim the memory when the book is closed. It will also unlock the possibility of creating companion apps in phones, tablets or even other eink readers that can talk to the core server and further expand the user interface.

[houqp]

@pazos I have created a separate issue for the reorganizing categories in touch menu. Let's move future discussion over that issue ;)

[baskerville]

Thanks for the feedback and the historical background: I understand now, how things slowly got out of control.

I'll try to help if I find the time.

[baskerville]

Here's my take on the menus:

Please note that the image is meant to be displayed on the KA1.

I've used Noto Sans at 29.6 px, so that the thickness of the font matches the thickness of the menu boundary (3 px), the separators are 2 px thick.

You'll notice how grouping menu items together brings spacial structure and improves recognition.

The sentence below the menus is just a font test of Noto Serif.

Have a look at those menu guidelines.

[Frenzie]

There's no one who said to themselves: "let's not do useful menu grouping such as has been standard everywhere for a long, long time." :-)

Relating this back to my proposal on the more technical side of properly sorting menus, that could look like:

order = {
  ["ota_menu"] = {
    [1] = "ota_check",
    [2] = "ota_settings",
    -- look mom, we're making the GUI better!
    [3] = "KOMenu:separator",
    [4] = "ota_check",
    [5] = "ota_settings",
  },
}

[Edit]Instead of separator it could also be named something like KOMenu:-------------------- or just --------------------[/Edit]

29.6 px

Que? I suppose in CSS pixels that might work 'cause they're actually a relative unit, but physical pixels don't come in .6. :-P

Have a look at those menu guidelines.

They should have an editor look at that document. Channeling @baskerville's negative means of expression (all in good spirits): GUI desigers are often affected by a strange disease: they believe that they don't need to know anything about text editing to write a document. But seriously, they're Apple: unlike the volunteer-based effort here, they can and should afford it.

"In general, avoid creating very long menus." That's way too vague. What's long? Just give a guideline. For example, menus should generally aim to have between 3 and 12 top-level items.[1] Less than 3 and it shouldn't be a separate menu, more than 12 and it should probably be distributed differently. Of course as I always say guidelines are a means to an end, not an end in and of themselves. Note that in KOReader, at least with the current code, menus generally shouldn't have more than 10 items because more than that causes undesirable pagination.

[1] I pulled that from the better-written but worse-looking https://developer.gnome.org/hig/stable/menus.html.en

[houqp]

Nice, I think the mock up is a much better improvement to what we have right now. Thanks @baskerville.

@Frenzie let's use ---------------------------- since that's also what's used in keyvaluepage module ;)

[Frenzie]

@houqp Incidentally I'm working on it right now. I've just got one tiny hangup after plugging the real menu into what I wrote yesterday so I'll have to see if I should adjust either my data structure or menu.lua :-P

[Frenzie]

As I mentioned in #2603 (comment) we're missing the ability to display grayed out menu items. However, other than History and Open last document on first opening I don't see any obvious use cases. Anyway, just putting it here so that not adding it is a conscious decision rather than forgetfulness.

[retrue]

There is an obvious use for grayed out menu items.
There is this old problem of menu entries that only work when WiFi is enabled. In those cases the solution is either asking the user to enable WiFi like #2591, #2581 and #2490. Or graying them out, that has been only done in #2383 to disable network info when WiFi is offline. (The menu is grayed out too in submenus of ZSync and Progress sync)
I think that there are at least two other cases where the gray out option or the asking for enabling WiFi option should be implemented: OPDS catalog and CLoud storage.

[Frenzie]

I think that asking for wifi is definitely the right solution, as opposed to being unable to click unless wifi is activated. But thank you for pointing out the graying out thing. enabled_func already does what I thought I might have to add.

So anyway, there are situations where Open last file should be grayed out, and apparently that's easy to add.

[robert00s]

@Frenzie I will add graying out "Open last file" this weekend.
@retrue I try to implement WiFi asking in OPDS catalog and Cloud storage soon.

[baskerville]

Here's my take on the main view (the image is meant to be displayed on the KA1).

The list of all the supported files is shown. The bar with a gray background is the list of tags. Only the files that match the selected tags are shown.

Tags can be selected, toggled and subtracted with taps.

The title, author and date of a file should be easily changeable.

[KenMaltby]

Really like the overall display and handling of the ebook title and file information. With this approach the dividing line makes much more sense to me.

[houqp]

I like the mock too :) I have created two tickets for the new mockups @baskerville made in this issue, let's move related discussion over there: #2614, #2615

[baskerville]

A dialog:

[baskerville]

The menu / sub-menu system is based on YouTube's menu.

[AlanSP1]

Looking at default button, can it have some rectangle around text, so we now it is default?

On the other hand, as we need to touch element, it may not be needed.

[lightonflux]

I think we should avoid generic "OK" buttons as shown in the title dialogue. A more clear label like "Change title" would be more clear and when questions in dialogues are more complex it makes it easier to understand.

Do we have an UI guideline?

[Frenzie]

Nothing very formal or organized for the most part. You make a good point about the button text. I never even noticed the Thunar rename dialog didn't say "OK", but that way you're not left wondering what you're okay-ing to. The confirmbox already supports ok_text so nothing would need to change in the code for that. In a way the confirmbox docs already suggest what you said but I can make that a little bit more explicit.

(Incidentally, this built-in multi-file rename is a great feature.)

[Frenzie]

Closing since all that wasn't too hard within the current UI framework for the moment has been implemented. Thanks for the mock-ups!