Page bookmarks

[kommunarr]

Page bookmarks

Pull Request Type

• Feature Implementation

Related issue

closes #1505
closes #4040
#312
partial alternative for #4594
provides setup for #1492

Description

• The ability to bookmark routes (not just keyword searches) through a button on the top nav
• Be able to set a named alias for those bookmarks through a modal popup
• When the current route is saved, it shows as starred in the top nav
• Clicking on the top nav for a bookmarked route opens a modal allowing you to edit the name and/or remove the bookmark
• Searching for a substring of a bookmark link or alias in the search bar shows the corresponding bookmarks at the top of the search results, with visual & ARIA identifiers
  • Navigating to a page bookmark clears the input
• Default route name is chosen based off of the document.title, playlist name, or search query depending on route
• Delete all bookmarks setting in Privacy Settings
• Thanks to the full path of routes being stored, including parameters, "Search" bookmarks are restored with the same search filter settings they were made with
• If the current route is bookmarked, that bookmark does not show in the search results while still on that route
• The user is warned with an inline message, but not barred from doing so, when their current page bookmark name open in the modal is a duplicate of an existing page bookmark name
• The search results for a bookmarked result show an icon corresponding to the route type
• The search results are now limited to 15 max results, prioritizing page bookmarks first
• Search results are now each visually constrained to one line/row, due to much longer results being possible now
• Removing a page bookmarked user playlist also removes the page bookmark automatically (note: only applies to the main Playlist page(s) being page bookmarked)

Screenshots

Testing

• Test that bookmarks & bookmark removals are remembered after reloading
• Test that bookmark name updates are remembered and reflected after reloading
• Test that bookmarks are set to reasonable defaults for all types of page routes
• Test bookmark deletion in Privacy Settings
• Test that bookmarks appear when matching at the top of the search results
• Test that navigating bookmark search results with the Up/Down, Right/Left, and Enter keys behaves as expected
• Test that bookmarks appear and function properly even when General Settings > Enable Search Settings is disabled
• Test that bookmark icon enabled/disabled states are discernible with Theme Settings > Match Top Bar with Main Color enabled (secondary color theme is used as fill)
• Test that page bookmarking a user playlist page and deleting that playlist also removes the page bookmark
• Test that page bookmarking multiple user playlists' pages and then removing all playlists in Privacy Settings removes all of the page bookmarks for the now-deleted user playlist pages
• Test that page bookmark with a duplicate name shows a warning

Desktop

• OS: OpenSUSE
• OS Version: TW

Additional context

Future PRs

• Import/export bookmarks (somewhat related to Suggestion for importing Chrome/Firefox bookmarks into FreeTube #1426)
• (Needs refinement / discussion) Hub for viewing and editing all bookmarks
• (Questionable / needs discussion) Truncate search results such that they never wrap to a new line (this is apparent if you want to create exceptionally long playlist names as an edge case, but this wrapping of long search results onto new lines is already existing & encounterable behavior)
• (Questionable / needs discussion) Hide page bookmarks setting (separate from Enable Search Suggestions toggle)
• (Even more questionable / needs discussion) Have the set Search filter parameters update when taking in a saved Search Results page with given search parameters (more confusing than not, in my opinion)
• Search history (Keyword search history #1492): We can easily fit generic search history entries into this paradigm by creating search-history.db entries with isBookmark: false set. Edit: probably should just leverage the existing search cache as the data source & existing access methods, but we can reuse the UI patterns added in this PR. I can revert 392fa75, the commit I added specifically to better accommodate the possibility of a generic permanent search history through the search-history.db, if desired. It depends on whether we want to support a permanent search history and/or one with time-based expiry rules going forward.

Aspects open for discussion

• Related: I keep spellcheck on for the bookmark name insertion ft-input because we do it elsewhere for most of our inputs, even though it's a bit ugly, especially when FreeTube is underlined in red for most users. This one is debatable, but if I change it for this one, I'm also inclined to change it for other instances as well (e.g., User Playlist name insertion, profile name insertion).
• I put the Bookmark icon next to the search bar and filter button because it helps make it visually clear that it's related to them.

[efb4f5ff-1298-471a-8973-3d47447115dc]

This feature differs quite a bit from what I imagine it to be. Lets take the following artistic masterpiece as a starting point (this applies to #1505 and #1492):

ONLY when the user clicks on an empty search bar (imagine the search bar being empty in the pic above):

• The user will see the bookmarked searches listed on top, marked with a colored star.
• The user also sees the recent searches they made right beneath the bookmarked searches and can be removed by hitting the X.

When the user starts to type into the search bar:

• Bookmarked and recent searches will not be listed.
• Only search suggestion will be listed.
• User can only bookmark from the search suggestions list and can be added to the bookmarked list (see picture below)

Debatable:

• Bookmarking searches with filters applied to it. I think the user should stay in control of their bookmarks just with search suggestions. Apply the filter before/after you hit search

I dont see the need for:

• Bookmarking routes
• The popup to give the bookmark an alias

[kommunarr]

ONLY when the user clicks on an empty search bar (imagine the search bar being empty in the pic above):
The user also sees the recent searches they made right beneath the bookmarked searches and can be removed by hitting the X.

Addressing #1492 is out of scope for this PR, IMO, unless we want to make it even bigger.

When the user starts to type into the search bar: Bookmarked and recent searches will not be listed.

I disagree on this one. This sets a hard limit on the number of bookmarks, makes searching bookmarks harder, and is different from most browser (and in the case of YT for search history) behavior that people are most familiar with, where those are put at the top of the results.

User can only bookmark from the search suggestions list and can be added to the bookmarked list (see picture below)

I disagree with this one for the reason that it's a prohibitive UX. You don't often think to save a page before you actually click on it, which is going to lead to a good deal of frustration. You probably want it to be somewhere visually constant so that you can bookmark a page whenever you want to. See my discussion from the OP:

Main routes like /about are bookmarkable, even though they're equally accessible through the side nav. This might seem unnecessary, but having controls on the top nav phase in and out of being active seems like a poor & confusing choice in comparison. Having it be omnipresent like all of our other top nav icons, and communicating that any route works for it, makes the new feature more apparent and easier to understand/use.

I dont see the need for:
Bookmarking routes

See answers to the above on why I disagree. In short, the cognitive model of browser bookmarking is one that users know about and are more effortlessly familiar with, but the model you're proposing is one that users will have to put in some work to learning and understanding the behaviors you've laid out, as it's a novel (at least to my knowledge) system and ruleset.

I dont see the need for:
The popup to give the bookmark an alias

I can see the argument for this one. I would be open to having the modal close action for this one be to save rather than cancel (similar to Firefox), but I do worry that's not as intuitive given that differs from our other modals. Alternatively, we could have bookmarking not open the modal by default, but a toast pops up presenting you the option to edit it (otherwise, you can just click the icon again).

[efb4f5ff-1298-471a-8973-3d47447115dc]

ONLY when the user clicks on an empty search bar (imagine the search bar being empty in the pic above):
The user also sees the recent searches they made right beneath the bookmarked searches and can be removed by hitting the X.

Addressing #1492 is out of scope for this PR, IMO, unless we want to make it even bigger.

Included that one just to make the examples easier to understand

When the user starts to type into the search bar: Bookmarked and recent searches will not be listed.

I disagree on this one. This sets a hard limit on the number of bookmarks, makes searching bookmarks harder, and is different from most browser (and in the case of YT for search history) behavior that people are most familiar with, where those are put at the top of the results.

Ah i didnt know. How does YT search history work? Could you maybe expand some more on the how browsers tackles bookmarks and how we do a similar job of it (i havent used browser bookmarks for a long time)

User can only bookmark from the search suggestions list and can be added to the bookmarked list (see picture below)

I disagree with this one for the reason that it's a prohibitive UX. You don't often think to save a page before you actually click on it, which is going to lead to a good deal of frustration. You probably want it to be somewhere visually constant so that you can bookmark a page whenever you want to. See my discussion from the OP:

Main routes like /about are bookmarkable, even though they're equally accessible through the side nav. This might seem unnecessary, but having controls on the top nav phase in and out of being active seems like a poor & confusing choice in comparison. Having it be omnipresent like all of our other top nav icons, and communicating that any route works for it, makes the new feature more apparent and easier to understand/use.

Ah ok I think I understand

I dont see the need for:
Bookmarking routes

See answers to the above on why I disagree. In short, the cognitive model of browser bookmarking is one that users know about and are more effortlessly familiar with, but the model you're proposing is one that users will have to put in some work to learning and understanding the behaviors you've laid out, as it's a novel (at least to my knowledge) system and ruleset.

👍 im fine with it but please provided some examples of the familiar behaviors like requested above.

I dont see the need for:
The popup to give the bookmark an alias

I can see the argument for this one. I would be open to having the modal close action for this one be to save rather than cancel (similar to Firefox), but I do worry that's not as intuitive given that differs from our other modals. Alternatively, we could have bookmarking not open the modal by default, but a toast pops up presenting you the option to edit it (otherwise, you can just click the icon again).

After testing some more i withdraw this. I think its very valuable to search for something with a filter applied and bookmark it with an alias so you exactly know what it is

[kommunarr]

How does YT search history work?

Incidentally, I'm thinking about us moving the star icon to the left of the label, adding a magnifying glass by regular results, adding a loop icon for history results, and adding remove icon or text button on the right side for history results.

Could you maybe expand some more on the how browsers tackles bookmarks and how we do a similar job of it (i havent used browser bookmarks for a long time)

Some behaviors vary based off of the specific browser and what settings you have enabled, but at least in every major browser, bookmarks and search history are prioritized over regular results by default. See discussion here on Chromium's behavior for example. As to which takes precedence over which, I think it varies. In Firefox, judging from a few minutes of testing, bookmarks and search history are equal, with relevance, closeness of order, and time of search seeming to be the apparent factors of sorting in order of priority descending.

im fine with it but please provided some examples of the familiar behaviors like requested above.

This is grabbed from Firefox:

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[efb4f5ff-1298-471a-8973-3d47447115dc]

Are the testing steps still the same? I dont want to overlook anything

[PikachuEXE]

Pending #5273 then change icon
But I don't know what else's left

[kommunarr]

Looks like the main testing criteria are all accounted for. Arguably you can also test having lots of bookmarks and search results (outcome: search results only reach as far as window size allows, as is the case in v21).

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

This PR is stale because it has been open 28 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[kommunarr]

I can resolve the merge conflicts if we're all on the same page of this feature being implemented. I don't see any public concerns mentioned in this thread, and I have this unchallenged rebuttal to one contributor's former concerns.

[efb4f5ff-1298-471a-8973-3d47447115dc]

I think its safe to resolve conflicts

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[efb4f5ff-1298-471a-8973-3d47447115dc]

closes #312

This does not close this issue. Subscribing to a playlist is like having a copy of it in your playlists page but every time you come back to it, it looks up the main playlists and update if there are changes.

I keep the - FreeTube part in much of the default bookmark names, even though it's a bit ugly, because it helps to further visually (& search-wise) demarcate bookmarks, and is thus a good default.

Related: I keep spellcheck on for the bookmark name insertion ft-input because we do it elsewhere for most of our inputs, even though it's a bit ugly, especially when FreeTube is underlined in red for most users. This one is debatable, but if I change it for this one, I'm also inclined to change it for other instances as well (e.g., User Playlist name insertion, profile name insertion).

I dont see any reason to include the - FreeTube. Could you maybe elaborate some more on this? Users already know they are using FT so why include it in the bookmark name by default?

I put the Bookmark icon next to the search bar and filter button because it helps make it visually clear that it's related to them.

Seems fine to me.

Main routes like /about are bookmarkable, even though they're equally accessible through the side nav. This might seem unnecessary, but having controls on the top nav phase in and out of being active seems like a poor & confusing choice in comparison. Having it be omnipresent like all of our other top nav icons, and communicating that any route works for it, makes the new feature more apparent and easier to understand/use.

Now that i had a closer look at this PR i think that we shouldnt do this. There is no reason for users to bookmark pages like these.

[kommunarr]

closes #312

This does not close this issue. Subscribing to a playlist is like having a copy of it in your playlists page but every time you come back to it, it looks up the main playlists and update if there are changes.

I see, so this feature is defined by its presence on the User Playlists page? I will remove that it closes it, although admittedly not sure if there will be much incentive to prioritize it once this PR is merged to be fair.

I keep the - FreeTube part in much of the default bookmark names, even though it's a bit ugly, because it helps to further visually (& search-wise) demarcate bookmarks, and is thus a good default.

I dont see any reason to include the - FreeTube. Could you maybe elaborate some more on this? Users already know they are using FT so why include it in the bookmark name by default?

My main point was that we don’t have a visual / semantic identifier for “default name” versus “custom name”, and that might be relevant in certain cases (e.g., is “Wildest Video Ever” what I labeled a wild video because I thought it was like that, or is that just the title?) Although looking back at it in retrospect, maybe that’s not an important piece of information most of the time, or if it is important, maybe we can just put quotes around default video titles (we may already doing that, idk, I’m on my phone and just going off memory). So I think I will just remove it.

I put the Bookmark icon next to the search bar and filter button because it helps make it visually clear that it's related to them.

Seems fine to me.

Main routes like /about are bookmarkable, even though they're equally accessible through the side nav. This might seem unnecessary, but having controls on the top nav phase in and out of being active seems like a poor & confusing choice in comparison. Having it be omnipresent like all of our other top nav icons, and communicating that any route works for it, makes the new feature more apparent and easier to understand/use.

Now that i had a closer look at this PR i think that we shouldnt do this. There is no reason for users to bookmark pages like these.

Looking back on it, I’m fine with disabling the button on certain predefined pages that will not ever want to be bookmarked by 90+% of people (as per our judgment). It doesn’t really matter much, but maybe it saves somebody a misclick every now and then, or prevents someone from getting dependent on the feature in an unintentional way that we don’t want to support going forward. My intent when writing this is that I just didn’t want us to arbitrarily make it that, for example, you can’t bookmark playlists because we don’t want you to do that.

[kommunarr]

Implemented the above suggestions. Bookmarks are now only available on routes that would need to be bookmarked. The only remaining item that needs to be changed, as I understand, is to improve the disabled styling and behavior on the button with the changes made possible in #5227. All other aspects of this PR are ready for early review if anyone is interested in doing so.