FR: (improvement) Skim document in overlay window

[Commodore64user]

FR: (improvement) Skim document in overlay window

[offset-torque]

If you know more or less precisely where you want to be it's better because it requires only three actions: open, go to page, dismiss.

That's exactly what I am thinking. To clarify what I am describing:

1. Make an alternative (current one is not touched) Page Browser with 1x1 page view and whole book visible on the bottom and call it something like QuickJump, Teleport etc.
2. Make it launchable with a gesture (or even a long-tap on progress bar so user can choose to launch the classic SW or this PB)
3. Touch bottom strip to navigate, tap on page itself to dismiss

Now we have SW on steroids with the same UX, same number of taps/steps but with:

• Whole unobscured view of the page
• Bottom strip spans the whole width of the screen so it is a higher resolution tap target
• More information dense bottom strip allowing more informed jumping

[poire-z]

I'm a bit perplexed by this. Isn't it already coalescing/merging on the current Book map? How else can I adjust the slot size so granularly, e.g. here:

Oh, right :) I forgot I was once young and went the extra mile :) We indeed allow for non-integer pixels, and distribute the extra to every nth-other page slot.

koreader/frontend/ui/widget/bookmapwidget.lua

Lines 123 to 124 in 3e7ab19

	self.page_slot_width = math.floor(self.pages_frame_inner_width / self.pages_per_row)
	self.page_slot_extra = self.pages_frame_inner_width - self.page_slot_width * self.pages_per_row -- will be distributed

But there is indeed a cap to min 1px.

[poire-z]

Maybe the solution would be to simply rework the current skim widget, as far as I am concerned the bottom row, with the (-10, -1, +1, +10) is not really needed, the rest of the box can be shrunk in size considerably and put at the bottom.

I had a try - having an option to trigger an alternative layout of the SkimWidget.
Not super happy with the result, so not sure I'd want that shipped, so I moved my hack into a user patch:
2-LittleTimmySkimmyWidget.lua.txt

It's a bit on the smallish side, but it may be ok for Little Timmy's little fingers :)

Just seeing now this uneeded thicker border at bottom... It may need a few refinements here and there.

Had a little idea to limit how this would mask the bottom of the page: with CRE/EPUB documents in page mode, we have some top margins, that we can remove (virtually, by just shifting up what's to be painted). It might not be enough though. Some alternative would be to size that widget/buttons according to that available extra margin, so it would be even smaller if top/bottom margins are small.

Btw, why/how/when/how often are you using that Amazon Skim widget ?
(I find this little hack a bit frustrating: our current SkimWidget is fat enough that I would use it just to hit that +10 button to scan through the book without any aim - otherwise, it's of no real benefit: there's many context missing, that we get with Page Browser. Also, with this hack at the bottom, everything looks like it's a normal page, but highlighting and tap don't work as expected - so it's more bothering/confusing than having it as an additional layer on top of the page.)

[Frenzie]

I am not saying make it harder to use, just to be able to see the whole page as you skim through the book.

I disagree with the premise that closing it should take me back where I came from, because that isn't what I want. I disagree with having to perform yet another action to activate the page. I disagree with showing a thumbnail of a page because the page is already there, perfect as it is. And I even disagree with putting the dialog at the very bottom of the screen, making it harder to reach. So no, I'm afraid I don't think copying Amazon would be an improvement, and that it would make it harder to use.

[poire-z]

I see now yes. It is easy for us end-users to generate ideas

(And that's perfectly fine and welcome - that's how, from my initial crappy ideas, with your Windows Defragmenter screenshots, we ended up with BookMap :))

[poire-z]

As you can see, you can actually look at the whole page, and skim through the file without affecting your original position on the book, and if you want to jump to particular spot, a tap on the pop-up will take you there, otherwise you exit back to where you were originally.

You're describing how you just described Page Browser :):

book maps (of which there is no kindle equivalent) is awesome, page browser is more advanced as it intertwines with book map

Note that you can make PageBrowser displays 1x1 page, and you get nearly your screenshot (without the uneeded original page as the background, but without a full slider on the full book range (but you can reach BookMap which is much more than this unuseful slider).
(So, I guess you'll FR could become: to be able to get/switch (via a gesture) between your prefered 2x3 view and this 1x1.)

The only one one I find lags behind is: "skim document". The KOReader approach is clunky and old looking, worse yet, it messes with the actual flow of the book, the box also blocks a third of the page, in short, it is not to 2024 KOReader standards.

SkimTo was there 5+ years before PageBrowser.
I agree (and so does @offset-torque) that it's just better and can be considered a replacement of SkimTo.
So, we could just get rid of SkimTo.
But SkimTo as some minor advantage: it blocks 1/3 of the page, but it can be made translucent, so you can anchor it at the bottom, and tap and see 2/3 of the page in clear, and 1/3 in clouds :)
I sometimes use it for quick jumping and checking random page renderings.
So, sad to throw away something that works and may have some little purpose. If you don't like it, just don't use it :)

[Frenzie]

I agree (and so does @offset-torque) that it's just better and can be considered a replacement of SkimTo.

Hm? Hold on, can you quickly get to somewhere completely different like one third of the book while you're at 4 / 5th?

[poire-z]

Launch "Book map (overview)", and if you have "Page browser on tap" disabled, just tap on the 1/3 first rows, and you get there.
(Otherwise, Page browser, long-press in bottom ribbon to launch Book map, tap on some area, back in Page browser, tap on a page... A few more taps, but in the journey, you may get to some more targeted area than what you thought would be at 1/3, ie the start of that 2nd big chapter which starts at 35%.)

[Frenzie]

The skim widget is very simple to use. The book map is very laborious for a purpose like that imho (many, many clicks), though it does show you the chapter names, but if you're going for that I think the toc is faster.

By which I mean to say in so many words that I vehemently disagree with the OP. ^_^

[poire-z]

OK :) (I'm nowhere proposing to remove it.)

[Commodore64user]

Note that you can make PageBrowser displays 1x1 page, and you get nearly your screenshot (without the uneeded original page as the background, but without a full slider on the full book range (but you can reach BookMap which is much more than this unuseful slider).

I hadn't thought of that, I just tried and still think, that the 1x1 view but with the skim box at the bottom (instead on the page browser) would make it killer. no need to do away with the skim feature.

how do you make the box translucent? I tried to do so but could not figure it out.

[Commodore64user]

The skim widget is very simple to use. The book map is very laborious for a purpose like that imho (many, many clicks), though it does show you the chapter names, but if you're going for that I think the toc is faster.

I agree with that but disagree with your conclusion. To me at least, 'page browser' and 'skim' are two different tools, much like you've described here.

but to say that you "vehemently disagree" with improving it is beyond my comprehension. I am not saying make it harder to use, just to be able to see the whole page as you skim through the book.

[poire-z]

I just tried and still think, that the 1x1 view but with the skim box at the bottom (instead on the page browser) would make it killer

We're already killer enough ! Let's not be too hard on Amazon and get them go bankrupt - let them have something we don't have :)

(But if we wanted to, I'd probably not bother with yet another widget to maintain, I would build on the existing Page Browser, and have 2-fingers spread/pinch in the bottom ribbon switch it to something that span the full book, so probably without page bars.)

how do you make the box translucent? I tried to do so but could not figure it out.

Long-press on it when it's still in the middle (before you move it away - after that, long-press put it back in its original position. I explained why this behaviour, that may feel strange, is actually quite useful, elsewhere - just can't find it).

[Commodore64user]

Here, I made a little mock-up

that looks a lot better already, of course, a few more changes wouldn't hurt but, that is basically my proposal.
That does not need to be the background, it is for demonstration purposes only.

[offset-torque]

"Page browser 1x1 with the whole book visible in the bottom filmstrip" is what OP is describing. Just look at the last screenshot. This modification directly launched like Skim Widget can easily replace and surpass SW.

[offset-torque]

Here is "PB 1x1" currently. Just make the bottom strip show the whole book (as a separate mode) and it is even better than that Kindle solution because in PB you can see the page much bigger than a small overlay. That is double the area nearly. In PB jump strip we also have much more information like read status, bookmarks, chapter boundaries to make a better jump.

[Frenzie]

In PB jump strip we also have much more information like read status, bookmarks, chapter boundaries to make a better jump.

That's why you have to go book map → focus on area → adjust a bit → go to page. The skim widget is better and worse. If you know more or less precisely where you want to be it's better because it requires only three actions: open, go to page, dismiss. If you don't know exactly (too many chapter divisions, the end of the book isn't quite the end of the book, etc.) the book map is superior.

There is something missing a little bit somewhere; I just don't think it's quite that the skim widget isn't the page browser. I do think page flipping mode has become obsolete due to the book map and page browser.

[Frenzie]

Sounds decent enough.

[jonnyl2]

I like the idea. I would recommend to include the page bars, however. And just the top chapter level (or make it adjustable). Although the page bars will usually be too small to pinpoint an exact page, they effectively show where the 'action' is and helps to seek/exclude already read sections. Here are a few examples of one-line Book map bars of various lengths on my 6.8" 265ppi device:

Same book without chapters, for comparison:

This one I couldn't compress any smaller. I guess there is a cap of 1000 bars per line, perhaps?

[poire-z]

I guess there is a cap of 1000 bars per line, perhaps?

Not really, it's caped to 1px per page slot/bar (so, your screen must be around 1000 pixels wide for you to witness that limit).
Page slots/bars are always all and each the same integer number of px. I don't want to have to "coalesce/merge" multiple ones in 1px, and leaving others be 2px.
So, if we ever go at allowing "zoom out/max" the bottom ribbon, this will be a hard limit, and it will be truncated/scrollable for books with > ~1000 pages (depending on device native screen px).
(And books with 700 pages, as page bars can't be 2px as it would need 1400px, would get a 7/10 wide bottom ribbon...)

[offset-torque]

Attractiveness of this "zoomed out ribbon" is that, user doesn't need to scroll. So it can replace SW without retraining and mentally much less overhead of using the widget:

Instead of "this is the whole book so I touch where I want to go" simplicity, it will be like this after opening the widget:

• Is this the whole book (search for signifiers)
• No it is not the whole so how much I am seeing (try to determine and mentally map to whole book)
• Is the chapter I am trying to jump visible (so I can scroll)
• Scroll and check again to determine and remap the remaining part to screen space again

You got the idea. This overhead is the friction between Page Browser and Skim Widget.
This doesn't mean PB is bad, but PB needs more mental preparation if that's the correct concept. SW is touch and go.

---

Just brainstorming here, can the ribbon be autoscaled according to book length so we can see the book fully all the time.

For example:
My Libra has 1264 horizontal pixels.
I will assume all of them can be used for the sake of simplicity.

This means my ribbon can show:

• 1264 pages at 1 pixel per page
• 632 pages at 2 pixels per page
• 421 pages at 3 pixels per page
• 316 pages at 4 pixels per page
• 252 pages at 5 pixels per page
• and so on...

So if my book is 380 pages long, this widget will switch to "3 pixels per page" so it will always try to use the maximum width it can get. Otherwise, if there is a hard limit like 1 pixel page, a 200 page book will only cover 1/6 of the screen. Less functional and looks weird(er than this option).

[jonnyl2]

Page slots/bars are always all and each the same integer number of px. I don't want to have to "coalesce/merge" multiple ones in 1px, and leaving others be 2px.

I'm a bit perplexed by this. Isn't it already coalescing/merging on the current Book map? How else can I adjust the slot size so granularly, e.g. here:

from 919 slots on the first line

to 909 slots?

[Commodore64user]

The reason why i think PB does NOT replace Skim (as @poire-z claims) is because it lets you quickly actually skim through ALL the pages in one single swipe. I wholeheartedly disagree with it needing page markers or the ribbon from the PB. My suggestion would be somewhere between Amazon’s simplistic progress bar (see very first picture, flat line) and KOReader’s skim [existing] progress bar (thick boy, see my mock-up). Genuinely it does not need more info, for that we already have the PB and BM. I think you guys are over complicating it a bit.

[offset-torque]

I agree with Commodore64user, chapter marks should be enough for jumping around. Maybe bookmark locations as simple dots (but not necessary). Chapter names and page read times will clutter there very much.

I mocked up their mockup :) to show my ideal widget:
Basically a stretched Skim Widget docked to the bottom
(And this is very close to PB 1x1 if you noticed)

[Commodore64user]

I agree with Commodore64user, chapter marks should be enough for jumping around. Maybe bookmark locations as simple dots (but not necessary). Chapter names and page read times will clutter there very much.

I mocked up their mockup :) to show my ideal widget: Basically a stretched Skim Widget docked to the bottom (And this is very close to PB 1x1 if you noticed)

i see we are mocking each other now 🤣. I would personally reduce the thickness of that progress bar by about three quarters and add back the buttons for next/previous chapter and page.

[poire-z]

I think you guys are over complicating it a bit.

You think fresh (but perverted by the Amazon experience :), so what you want and sketched would be over-complicated to implement, as it would be something new :)
We (at least I) are thinking about what exists and could be tweaked to make you happy - so we don't have to invent and maintain and document yet another widget (after Goto, Skim, ToC, Bookmap, PageBrowser, now QuickJump & Teleport... :))

My idea watching your earlier thoughts above would be that a "zoom out/max" bottom ribbon could be an added useful feature to PageBrowser - but I thought, contrary to your enthusiams, it would be unusable in 1x1 mode - and it would be more valuable in a 4x4 mode (as an alternative to the 2x2 I use all the time):
With a whole book bottom ribbon, the ribbon would indeed be quite crowded, and the chapter and their boundaries quite unnoticable and no precise jump possible. Your 1x1 mode would be super painful with that to adjust and get you to the page you want (while a 4x4 or 5x5 would allow to pick the correct page among these 16 or 25).

And given that a whole book bottom ribbon is quite unusable, the only alternative is to split it in another full screen widget, which Book map is. So, I think the combo BookMap + PageBrowser and the ability to switch between them is still the best and most practical solution.

Anyway, glad we're moving from that idea :)

Basically a stretched Skim Widget docked to the bottom
(And this is very close to PB 1x1 if you noticed)

Your mockup still shows the page "shrunk". Anything like that (like the Amazon screenshot in the first post) will feel slower than our current Skim widget, because 1) the page has to be generated in a subprocess (to not mess the book current position) 2) data exchanged inter-processes 3) the image rescaled to be 95% of its original size. You'll get the same feeling of slowness than when using PageBrowser (where your brain is a bit distracted by the animations to really notice it :)).

Unlike with the current Skim widget, where the page is drawn native by crengine, so any jump is as fast as a page turn.
So, the downscaling to get the aesthetics of the Kindle screenshot is not worth it.

So, ok, it could end up as our current Skim widget, made smaller, with some buttons removed, anchored at the bottom.

The KOReader approach is clunky and old looking, worse yet, it messes with the actual flow of the book,

A single swipe to the right will take you back to the page you launched Skim from. And nothing will let you on the page you reached.

We (at least I) are thinking about what exists and could be tweaked to make you happy

And I'd be happy too if this would work :)
(May be one could just user-patch SkimToWidget:init() to remove/re-order the buttons that were build.)

[offset-torque]

poire-z - Your mockup still shows the page "shrunk". Anything like that (like the Amazon screenshot in the first post) will feel slower than our current Skim widget...

I see now yes. It is easy for us end-users to generate ideas but probably because we don't do the effort of coding and maintaining the features :) Respect.

I want to add that I have no problem with the Skim Widget. Its usage can't be optimized more: One touch to open/jump/close, probably lots of people like it for this. For quick jumps that's what I reach for first. For precise jumps, there is Book Map and Page Browser. Nice teamwork of widgets.

poire-z - But SkimTo as some minor advantage: it blocks 1/3 of the page, but it can be made translucent, so you can anchor it at the bottom, and tap and see 2/3 of the page in clear, and 1/3 in clouds :)

Maybe this is the solution, opening SW at the bottom (by default or optional) and a bit more compact/translucent...

[Commodore64user]

I concur with the fact that we don't know the boundaries of possibility until you guys maintaining this monster tell us where they are. Having heard what @poire-z had to say, and btw, you can't quote yourself in the same comment

you can't quote yourself in the same comment

I agree with this.

Maybe the solution would be to simply rework the current skim widget, as far as I am concerned the bottom row, with the (-10, -1, +1, +10) is not really needed, the rest of the box can be shrunk in size considerably and put at the bottom. Hell I wouol be even willing to let the whole thing re-render to get it at 90-95% if necessary. If navigation needs to happen in the actual flow due to crengine, then be it (I am happy to concede there) we (I say we, but really mean you guys doing the actual work) could change the bookmark button to be fixed at the initial location. so once you are done skimming, press there and you are back where you started. That is one idea, I know @Frenzie is not a fan, but maybe we could have both, the old and new and the user chooses which one they prefer.

You think fresh (but perverted by the Amazon experience :)

I agree with this too, but it is only because Amazon got that one right. There is a lot of space for improvement in Amazon's reader, but their skimming tool is not one of them, is by far the best one I've encounter.

[Frenzie]

Amazon offers many of the best examples of things to avoid, yes. :-)

[Commodore64user]

Amazon offers many of the best examples of things to avoid, yes. :-)

this is correct, but don't make the mistake of assuming that you can ever learn anything from someone constantly making the wrong move. as the saying goes: "A broken watch is certain to be right twice a day"

Credit where is due, Amazon got the skimming right. It is so good, they didn't even bother changing it with the new UI (thankfully)

[Commodore64user]

I see now yes. It is easy for us end-users to generate ideas

(And that's perfectly fine and welcome - that's how, from my initial crappy ideas, with your Windows Defragmenter screenshots, we ended up with BookMap :))

This was a great idea, congrats on that one, I would just add a shortcut to activate "hidden flows" from the BM and it would be 100% perfect 😅

[Frenzie]

this is correct, but don't make the mistake of assuming that you can ever learn anything from someone constantly making the wrong move. as the saying goes: "A broken watch is certain to be right twice a day"

As stated I disagree with every single difference, and I didn't even mention the ugly fat borders.

[jonnyl2]

Thank you for your work! I was going to yield to the requester for initial comments but since there have been no responses yet, here I go :)

I like it a lot, and for me it's a great improvement over the current Skim widget. However, it's true that it's quite narrow. Even for my skinny fingers the navigation bar and buttons are a bit too small. But the beauty of user patches is that they can easily be adapted to individual users' tastes/needs without the need for a separate patch. For me, I doubled the navigation bar height to 40 on line 86, and increased the button font size to 16 on line 33, to get the following look:

I personally would prefer if the widget would just appear over and cover parts of the page on EPUBs as well, as it does for PDFs (i.e., none of the margin cropping etc.). That way, when I close the widget I can just continue reading without being irritated by moving lines and screen refreshes :). But I may be alone in this assessment and that's another thing that I'm sure could easily be adapted in the personal patch file (I haven't looked into that part of the code yet).

Personally, I would also change the ordering of the buttons so that page navigation buttons are in the right hand cluster, and bookmark/chapter skip buttons are in the left-hand cluster. (Return and Bookmark toggle unchanged.) Then, when jumping a page too far, the page back button would be right next to it to go back. Equally for chapters, bookmarks, etc. (E.g., like this: |< >| <* *> R ... * -10 +10 -1 +1). But again, this is just personal preference and could easily be changed on my patch alone. Just giving feedback here.

I was wondering if the page could be updated immediately upon touch on the progress bar (not upon release), and continuously be updated when sliding along the bar? I believe this would offer a much more satisfying and user-friendly 'page flipping' experience than the one currently available (for fixed-layout docs only), and for some users this new Skim widget could potentially replace the old Page flipping mode as well.

[poire-z]

I personally would prefer if the widget would just appear over and cover parts of the page on EPUBs as well, as it does for PDFs

Just comment out the 2 functions replacements at bottom, SkimToWidget.onCloseWidget and SkimToWidget.onShow (or rename, ie. SkimToWidget.onCloseWidget_NOT_NEEDED = function...

E.g., like this: |< >| <* *> R ... * -10 +10 -1 +1

Sounds more practical indeed. You can reorder the items in the local single_buttons_row = HorizontalGroup:new{ list in lines 290-313.

I was wondering if the page could be updated immediately upon touch on the progress bar (not upon release), and continuously be updated when sliding along the bar?

Would probably need more work to support the "pan" event - I remember I once looked at that for immediate live update of something else, I don't remember what - and it wasn't that obvious... We don't even support that for the frontlight level when swiping on the left edge.)

[jonnyl2]

Thanks, I'll check out those tweaks.

The live updates are supported in Page flipping mode for PDFs (pan north/south), and it works amazingly well on light PDFs. Unfortunately the UX is otherwise a bit clunky, the progress bar (or at least status bar) needs to be enabled to get an idea where one is in the book, and text selection can get in the way of flipping through the pages. As CRE docs generally load faster than PDF, I could only imagine it getting even better. But it would just be a nice to have.

[poire-z]

If you'd have that on the progress bar, panning on it would need to reflect the progress bar position, so on a 1000 pages books, the minimum distance for triggering pan would already move you 50 pages :)
I guess you'd just want some kind of page flipping mode anywhere on screen to act like this PDF page flipping, or some kind of "page mode turbo scrolling" left/right - which would feel a bit independant on this skim widget (ie. you'd already have the footer to show you a progress bar, and the current page number).
But how often would you use that? And how practical ? You quickly pass over some page with pictures or a table you want to get back to, you'd have a hard time going back to it with this "page flipping", and you might resort to Page Browser.
(I never used Page Flipping, I may have witnessed it, by accident :))

[jonnyl2]

If you'd have that on the progress bar, panning on it would need to reflect the progress bar position, so on a 1000 pages books, the minimum distance for triggering pan would already move you 50 pages :)

It's the same thing in Page flipping mode. Even on a 400 page book it's almost impossible to flip to a specific page. But that's not its purpose. It's just to aimlessly browse through vast sections of a book to see what one could expect from this book, pick up some random pieces of text here and there, maybe look at some pictures... It's more of a playful gimmick, granted. But quite a satisfying one :). I know I could achieve similar aims with the Page browser, but it requires more taps, I have to lift my lazy finger, and the pages are not full screen :).

[Commodore64user]

Thank you for your work! I was going to yield to the requester for initial comments but since there have been no responses yet, here I go :)

I'm sorry @poire-z , I downloaded the patch but haven't had time to try it out. I promise I will get back to you soon. Not just here, on the other threads too.

[offset-torque]

+1 for usability remarks of @jonnyl2 (size, overlay, button ordering)

[Commodore64user]

@poire-z, I am really sorry it has taken me this long to reply but better late than never.

Btw, why/how/when/how often are you using that Amazon Skim widget ?

quite a lot actually, but not necessarily for the reasons you might think. Due to the inferior book navigation features on the stock reader and the lack of things like, pages left in chapter, etc. i find myself using both the skim widget and the ‘page browser’, which is quite similar to koreader’s bar the book map integration to satisfy those needs. Also, if a book references an image, it is a lot faster to go back using the skim widget: for example, on kindle that is.

with koreader however, I don’t use it the same way. Mainly i use it to check that i am happy with the current render and to make adjustments accordingly, i also don’t use it as much because I currently don’t find it that useful. Which is the reason for this FR.

anyway, i tried your solution here and well, i agree with you is not so great. Buttons way too small, even little Timmy is struggling , albeit, his is an ironic nickname (inspired by Tiny Tim), little Timmy is actually a 6’7 bearded man called Clive. Nevertheless, i am starting to think that maybe your approach, 1x1 page browser with the skim widget might work best (and showing the status bar), even if some speed needs to be sacrificed.