Bookmarks / Headings / TOC

[georghendrik]

nobody:

...

georghendrik:

What if we could like, mark handwriting in a notebook so we can quickly jump back to it?

georghendrik also:

You mean like bookmarks?

georghendrik:

Yes, or maybe table-of-contents / TOC, or todo's, depending on how you use it.

georghendrik also:

This needs a video

georghendrik:

bookmarks.mp4

Features:

• Bookmark any handwriting (strokes), by selecting it, then tapping the bookmark icon from the selection menu.
• Open the bookmark list by tapping the bookmark button in the main toolbar.
• Jump to any bookmark by tapping it from the bookmark list.
• Works across notebooks.
• Easy on the page cache: scrolls only if a bookmark is not visible.
• Allows deleting bookmarks.

This is work in progress, and currently:

• Bookmarks are kept in a separate sqlite database, at least until the data model feels okay to merge.
• Bookmarks are modeled as (bookmarkId, top-left strokeId, bitmapUri). Pages, page number, scroll position, and notebooks are derived from the strokeId . This allows moving the stroke around the page without breaking the bookmark. Duplicating and cutting however, modifies the strokeIds and currently breaks the bookmark. Still working on that.
• The bitmaps are stored outside of the database.

@Ethran I'm curious to your thoughts on this approach to bookmarks. If you are open to a pull request for this, let me know, happy to open one!

[Ethran]

Hmm, I was thinking about bookmarks — it would be cool to have them.

My approach would be:

• Bookmarks are notebook-specific, but there should be a list of all bookmarks.
• Bookmarks should be clearly marked in the notebook, maybe with a line near the edge of the screen.
• Bookmarks should have:
  • A human-readable name (by default created using OCR — to be worked on later),
  • The ID of the page they are on,
  • A list of stroke IDs they are connected to,
  • Creation date,
  • Color of the bookmark (to be used to mark them on page, and in the list).
• We should not store a bitmap of bookmarks. It should be generated similarly to notebook previews in the library, using strokes IDs.
• If the list of stroke IDs is empty (i.e. the strokes were removed), the bookmark should be deleted.
• The position of the bookmark should be calculated based on the strokes IDs. It might be stored in a separate field in the structure, but in that case, it should be updated when the list of stroke IDs changes.
• It should also act like a group for strokes — when one is selected to be moved, the other strokes in the group are also selected. However, individual strokes can still be erased.

I did not attempt to code this, those are just my thought on this stuff.

As for your other PR, I hope I will have some time next week for it, or maybe tomorrow.

[georghendrik]

it would be cool to have them.

It is! I have them, they're awesome.

Thanks for the quick reply! I think I can follow most of your reasoning, could you perhaps elaborate on these two points?

We should not store a bitmap of bookmarks. It should be generated similarly to notebook previews in the library, using strokes IDs.

Aren't the notebook previews currently stored and also displayed as bitmaps? Please correct me if I'm wrong. The use of bitmaps there is what makes Notable's page previews so fast compared to Boox's notes app. It also helps make the current bookmarks page fast.

Bookmarks should have a human-readable name

Do you mean an optional name, or do you mean it to be required? Is this intended for exporting to XOPP and PDF's?
Currently, I do like how quick it is to add a bookmark. No dialog, no OK-button required, just select, tap bookmark and you're done.

As for your other PR, I hope I will have some time next week for it, or maybe tomorrow.

No rush! Please take your time, it should not feel like a chore.

[Ethran]

Aren't the notebook previews currently stored and also displayed as bitmaps? Please correct me if I'm wrong. The use of bitmaps there is what makes Notable's page previews so fast compared to Boox's notes app. It also helps make the current bookmarks page fast.

Yes, they use them, but those bitmaps aren't stored permanently. If you clear the app data, they will disappear. I meant that we shouldn't store them in the database in any form.

Do you mean an optional name, or do you mean it to be required? Is this intended for exporting to XOPP and PDF's?
Currently, I do like how quick it is to add a bookmark. No dialog, no OK-button required, just select, tap bookmark and you're done.

It should have a default value, available for modification, but not required to be inputted by the user. Maybe a dialog could pop up when a bookmark is created, allowing the user to choose a name and color, or just confirm the defaults by clicking OK? There could also be a setting to disable this popup, but I think clicking OK to confirm isn't too much of a hassle.

And another important thing:
– In the future, I would want to be able to create references to bookmarks directly on the page — similar to how it's done in LaTeX, using '\label' and '\ref'.

[georghendrik]

I meant that we shouldn't store them in the database in any form.

This makes a lot of sense. Currently, the bookmark-images are stored in a similar way to regular images. So they will not accidentally get removed when the app cache or data are cleared. It does feel cleaner to move them to the cache folder, and then recreate them from the stroke id's if the app cache ever gets cleared. I'll aim for that.

It should have a default value ... clicking OK to confirm isn't too much of a hassle.

This sounds good. We could skip the dialog by long-pressing the bookmark button. I have a Boox 10.3 Go, so a black and white screen — Mostly, I won't have a use for coloring the bookmarks, but I understand how this is different on the 4C. I might look for an alternative / complement to the use of colors. For instance, Supernote supports different types of bookmarks, like headings and "stars" for todo's.

I would want to be able to create references to bookmarks directly on the page

Yes! Like anchors in HTML. Before just going with storing the most-top-left stroke's id, I considered adding a third page item type. Besides Stroke and Image, we would then have Anchor (or Reference, Link, Bookmark, Label). That would be a larger change though, as it would require updating the drawing and selection code too, to handle this third type everywhere.
The current approach is more lightweight in that sense, to help understand what UX works nicely before making larger changes.

[Ethran]

@georghendrik Could you create PR against dev branch with current status of your implementation?

I want to start working on it, and there is no point in duplicating work.