Talk:User Interaction Consultation/Bookmarks/read later

I'm not clear what would be wanted in bookmarks that isn't already available in watchlists. But if there is something extra required then why not expand the watchlist system? There are many many ancient requests for improvements to the watchlist system such as being able to create sub lists or to just watch threads or sections. That should solve the rare occasion where an existing editor with thousands of articles on their watchlist wants to create some bookmarks.OK that requires people to register and have an account, but accounts are free. Though we would need to change some policies such as the usurpation of inactive accounts if there were some active reader accounts that didn't edit.

Thanks for bringing this up. The reading team has discussed this quite a bit. I think the conclusion arrived at is that both use cases rely on the same underlying data structures (groups of entities: articles, sections, revs or otherwise). However, 'group of things' is a very generic notion in CS and the purpose, features and experience of both are quite different. If I am watching an article for revisions, that is very different from saving an article for later reading or offline usage--an optimal layout and set of features are quite different. So, the team I think broadly discussed that while some core architecture might be re-used, the development paths of both are likely different.

Another factor we considered was purely logistical. As we planned to develop a feature for saved articles to be saved in groups on Android (this feature is almost finished), the Android team discussed collaborating with the community tech team, as they were planning watchlist work. After the team's discussed, it became clear that opening up watchlists to perform separate surgeries at the same time would be a real issue, so the Android team backed off... This doesn't mean that core architecture couldn't be re-used in the future.

Happy to discuss further.

I agree needs are very different. Being able to track updates in reader-friendly way (considering more the information units than the modified characters) could help people to rely more on Wikipedia when checking live events and news (without having to refresh the browser).

Support. This is hugely popular on our apps and was also a feature requested in the community tech survey. Further improvements (multiple lists) is currently being worked on in the Android tool. The need was a key driver for Gather, but the public option for those lists was problematic.

The "list of articles" concept is pretty important and universal. I think a bookmarking tool would also be a very good hub/coatrack for some more daring user interaction features in the future:

• Recommendation engines (If you like The Godfather and Scarface, you may also like Goodfellas. Think the late Hunch.com)
• Print-on-demand mini-Wikipedias
• Social citation management (CiteULike, Medeley) with data flowing back into Wikidata
• Social collection management (Goodreads, LibraryThing), again with the possibility of data flowing back into Wikidata
• Social bookmarking
• Gather "done right"
• Multiple/shared watchlists

These features will all be a lot more controversial than a plain bookmarking tool, of course.

Fwiw Gather was done right for private lists but sadly tried to do to much and this good work got clouded by the public view which wasn't so good. There are discussions about updating core in progress to do pretty much what Gather did.

I'm still grumpy that the RFC closed the way it did as this feature keeps getting asked for and we were about 70% of the way there :/