[request] mark bookmarks read

[microcreators]

... and move them out of sight. archive them, hide them, etc. but keep them available and searchable in case I need to come back to them one day. Just don't show them in a default view.

[michaelx]

This would be a really helpful feature, especially when shiori is used as a read-it-later client.

[thejdev]

I agree that this would be a good feature.

As an interim workaround, I use this url as my default start page:
https://shiori-server/?search=-tag%3A*#home

The link above lists bookmarks with no tag (i.e. unread). Once I have read an article, I give it a tag (e.g. Read), and it disappears from the list.

[8bitgentleman]

@thejdev I like that idea a lot. To remix it if you set this URL is your home it filters out the tag #read and shows all others. This works really well for me because I use tagging for many other things

http:https://YourShioriServer/?search=-tag%3Aread#home

I wish shiori did filtering in real time though. That's the downside I see, you need to refresh the page for any new tagged articles to be filtered out.

[deanishe]

Hi guys. I'm your new Shiori maintainer.

This feature is a high priority for me. Specifically, I want to add support for read, starred and—possibly—archived status.

Right now, I'm thinking of something along the lines that @thejdev suggests: basically just using tags, but treating certain tags (e.g. unread, starred) specially in the UI.

There's some "infrastructural" stuff that needs doing first, though.

[microcreators]

First of all, thanks for reviving the project, appreciate it. If I can suggest something here, start easy with the change. Maybe just one special tag for starters like read? I think I'd be simpler to add this vs. having everything else tagged as unread.

[deanishe]

I think I'd be simpler to add this vs. having everything else tagged as unread.

What makes you say it would be simpler?

I think the main difference is whether you think a "read later" list should be opt-in (add unread) or opt-out (add read).

I'm more inclined to the former (tag as unread to add to "read later" list) because I don't want an update to automatically shunt everybody's entire list of existing bookmarks (and any new ones they add/import) into their new "read later" list (because they aren't tagged as read).

Existing users have probably read most of the articles they're interested in by this point, and they may not even want to use the feature. That's a better fit with the opt-in unread model.

[microcreators]

Honestly - it doesn't matter. 99% of my bookmarks are read and stored "just in case" (it's a knowledge base for me). I think it's a matter of default tagging. If everything is unread by default, there will be (a lot of) manual work to hide what's no longer fresh.

[deanishe]

If everything is unread by default, there will be (a lot of) manual work to hide what's no longer fresh.

Exactly. That's why I prefer "tag unread to add to read-later list".

Of course, it's simple enough to automatically add any tag to items on database migration or when importing/adding.

So, it's really a question of opt-in vs opt-out, and currently I'm quite strongly inclined towards opt-in.

[JoshuaCrewe]

Having another option other than to delete a bookmark would be nice. I don't personally mind deleting them as I rarely come back to bookmarks once they are read. I am using this as a pocket/wallabag replacement so very much a read it later app.

On that point, if a mark as read system is a favourable one, I would like to suggest adding these actions to the readers view. #579 talks about a lack of back button and I feel this is all related.

• Mark as read
• Actions on the readers page
• Better return to list options

[JoshuaCrewe]

Looking at the alternatives (that I have access to), they have an action bar in the readers view.

Wallabag (some custom.css on this one) :

Omnivore :

[fmartingr]

What I'm doing while we figure out what's the best way to move forward is to use two tags: readlater and read. That way my "to read" list can be filtered by that tag, and once I'm done with an article, I can mark it as read with another tag or delete it if I'm not interested or I dind't like it.

Keep in mind that Shiori is on a middle level between a bookmark manager and a read-read application, that's why I want to plan the steps ahead before making drastic changes that would move us in one direction or the other only.

My first thoughts on this (before I started maintaining it) was to:

• Have custom actions that would add/remove tags from a bookmark. "Mark as read" -> "add read tag".
• Have custom sidebar bookmark lists, with predefined searches: "Readling list" -> "Search bookmarks with readlater tags".

[Monirzadeh]

If we follow this method, should we keep some limitation on this specific tag?
For example, bookmark can't have both? Or some other things like this?

[fmartingr]

I still believe that a functional approach here is better for users.

Having an "action system" that allows you to customize Shiori to your liking without moving it directly into the "read later" or "bookmarking" apps. I think we could:

• Have a way to allow users to customize actions to do on bookmarks. To start it would only allow "add tag" and "remove tag".
• Have a way to filter Shiori's home. (Select a default search for the main page, so we could exclude articles with specific tags)
• Have a way to create custom lists (searches) and show them in the sidebar.

An example in my use case:

• Action: "Mark as read later", adds tag: "readlater".
• Action: "Mark as read:, adds tag: "read"
• List: "Pending read", search: tag:readlater
• Home: filter using: -tag:readlater -tag:read

For all this to move forward we need to migrate the APIs. I don't want to start adding new features while we are in between this change or it'll bite us later.