Read it later list

[blackforestboi]

A feature that needs almost no introduction :grinning: The ability for users to get a pocket/safari-style (offline) read it later functionality for articles and websites.

Preparation:

• [ ] Create Mockups (done by @oliversauter)
• [ ] Understanding relevant code base and ask @poltak on ideas how to integrate lists into the index & query. (please keep discussions in this issue as much as possible)
• [ ] Coordinate with whoever takes on #272

Goals V1: Read it later - online variant

Has some overlap to #272, as the read-later list could be a fixed list that is always there - and is not deletable.

• [ ] Ability to add current page to reading list (via popup)
• [ ] Display list of urls that are on reading list

Goals V2: Read it later - Offline variant

• [ ] Automatically Store cleaned version like pocket or readability or safari
• [ ] Add ability to change settings for this behaviour
• [ ] Enable access of stored version via result list element

Goals V3: Read it later - Full HTML

• [ ] Add ability to optionally store FULL HTML versions of pages

Optimisations:

• [ ] Special parsers for video sites
• [ ] somehow include videos that are embedded in articles

[paras7735]

I would like to work on this issue. Can you give more information regarding it? Thanks

[akbarbmirza]

I'm also interested in working on this. Would like to discuss further.

[blackforestboi]

Hey @paras7735 & @akbarbmirza

Thanks for offering your help here. :) What questions do you have with which I can help you?

@akbarbmirza Are you also coming via Google Summer of Code?

[akbarbmirza]

@oliversauter yes, I found the project through GSoC and I'm interested in working on it for it.

[blackforestboi]

@akbarbmirza Do I understand correctly that you are a beginner with React? Unfortunately, we currently don’t have the (wo)manpower to help you learn React, and our project is fully built on it. I am sure, you'd have the drive to learn it by yourself, but in order to produce usable code, that means our team still has to give you a lot more guidance. (and many do it voluntarily) If that is the case, I think our project is not the right one to apply for, at least this year.

[paras7735]

@oliversauter I have started working on this issue and will coordinate with @vaibhavchellani who has started working on #272.I take it that its UI is similar to #272.We can also add the ability to view lists from the memex button in the address bar itself like a submenu.

[blackforestboi]

I take it that its UI is similar to #272

Actually the reading list is just like one of the lists, but one that is not deletable. It works the same way though in terms of filtering behaviour.

I will provide updated mockups for both the popup and the lists overview. If #272 works, its easy to make V1 possible. Whats essentially needed is just a way to add pages from the popup.

[naman03malhotra]

@oliversauter I would like to work on this, I have decent experience in React, React Native and Redux. Please help me get started.

[akbarbmirza]

@oliversauter I'm relatively new to React. I understand your concern, so thanks for the heads up.

[paras7735]

Hi @oliversauter I have completed a UI MockUp for the Read It Later Button in the Popup:-

Currently, I am trying to save the List in a similar way Bookmarks are Being saved using a 'LaterList/' Key in the DB. This will enable this component to function as a separate list which cannot be Deleted. And it will also lead to simple integration into the list container sidebar. Do tell me if there is anything wrong with the approach. Also, I have Uploaded the code to my forked Repository https://github.com/paras7735/Memex/tree/LaterList PS I am having some unintended syntax reformating due to the usage of 'prettier' during git commit. Does anyone know a workaround? Thanks, Cheers :D

[blackforestboi]

Awesome job, will give it a test tomorrow! Does filtering by laterlist also already work? If yes, could you implement a simple button somewhere in the overview to let me test that?

@poltak and/or @ShishKabab. If you find the time, could you have a look over this?

[paras7735]

It does show laterlist: true for pages which are saved in LaterList. I will implement it as soon as possible. But I was getting hit by a bug which was stopping webpages from getting indexed. It happened 2-3 times but its now working fine when I reinstalled the Extension. I have to make certain that it is not due to the laterlists. I will continue testing it and see if it pops up again. :/

[poltak]

@paras7735 looks like you're making great progress :) feel free to open a PR from your branch to our master and it'll make it easier for us to review and discuss implementation further.

RE unintended reformatting due to prettier: that's the point of prettier 😛 it forces an opinionated code style on all contributions to keep things (mostly) consistent. Just write code and feel free to completely forget about how it looks.

[paras7735]

Yes, I will send a [WIP] PR the moment I complete filtering of laterlist in the overview component :D

[paras7735]

I have completed the filtering of search results by Later list and the Mockup Popup UI. I have created a PR regarding the same. https://github.com/WorldBrain/Memex/pull/319

[ShishKabab]

@poltak I've talked with @paras7735 today, and I saw PouchDB is currently being used as the back-end. Also, his branch currently integrates with the old search index, and we hope to have the new search index implemented by the time this feature goes to production. What do you @poltak recommend as the backend for storing new data instead of PouchDB?

Also @paras7735, @oliversauter pointed out to me that this feature is very closely related to #272 being handled by @vaibhavchellani. In fact, read later could just be a list with a special flag / reserved ID in the backend. So please @paras7735 and @vaibhavchellani, please coordinate on the implementation of the backend for these features.

[vaibhavchellani]

@oliversauter @ShishKabab yes i plan to co-ordinate with @paras7735 regarding this issue , unfortunately i am unable to work till 2 march because of my univ exams . We will get the prototype ready asap after that as i have planned on how to implement #272 .

[poltak]

What do you @poltak recommend as the backend for storing new data instead of PouchDB?

Yes at the moment we're in a bit of a flux with data, so any data storage now is bound to change. I would recommend abstracting away the parts of your code that interact with data sources in separate functions where the interaction can take place. As long as there is no interaction outside of these scopes, they should be the only places needed to be updated later.

[paras7735]

This is a rough user flow mockup and some queries regarding this issue

Popup-

The user is given the ability to add and remove a web page from the popup This will require the use of the new Dexie-based search index It will also require being stored in the Database. It can be done in two ways

1. Add a LaterList:true attribute to a list and treat it as a special List which cannot be deleted.
2. Add a LaterList Data model and mould it after the Bookmarks model - This approach will result in a totally separate component which will be different from the Lists component and can be added very easily and separately in the List sidebar. This will also stop the user from deleting this list as it will not be connected to the normal list deletion code. This can also make the search times faster as the code will not look at all the list and see if they have a LaterList:true option or not. I would propose that the second option is better in terms of benefits.

Sidebar-

The user will also be able to remove or add an item to the list through the list sidebar but will not be allowed to remove it.

The reader view-

The reader view can have the following functions

1. Ability to add/remove the bookmark for the given URL
2. Ability to add/remove tags for the given URL
3. Ability to remove the URL from the read it later list
4. Ability to change the font size
5. Ability to change font-serif
6. Ability to change the theme

Result List in the Overview component-

Query 1:

Here I am confused about what all options should be there will there be 2 options ?(excluding the ones already in the result list item like tags bookmark etc) One for reader view and other for the original HTML redirect?

Read it later-Full Html-

I talked to @oliversauter about it and he pointed me to the freeze dry repository for this part.(https://github.com/WebMemex/freeze-dry)

Query 2:

Here i am uncertain about the placement and flow of freeze dry initiator. Will it also be in the popup? where else will the user get the option for freeze dry?

[blackforestboi]

Thanks for putting in thoughts on how we can make the UX of this feature.

This will require the use of the new Dexie-based search index

We don't need to specifically (re)index the page a person wants to have for "read-it later". This step should already happen before they decide to store it.

Sidebar- The user will also be able to remove or add an item to the list through the list sidebar but will not be allowed to remove it.

Yeah, still need to mock that. The feature of removing/adding pages (in bulk) to lists is the same here, as it is for #272

Query 1: Here I am confused about what all options should be there will there be 2 options ?(excluding the ones already in the result list item like tags bookmark etc) One for reader view and other for the original HTML redirect?

likewise, a bit confused :) Can you rephrase this, not sure if I understand.

Query 2: Here i am uncertain about the placement and flow of freeze dry initiator.

Will also provide you with mockups for this.

[paras7735]

@oliversauter By Query 1 I meant to understand the UI/UX Flow for the Result Items List generated when the list is generated from the Laterlist Storage.

I also wanted to know if the Reader is better off being an overview component or a different module. 1.If it is an overview component the whole system will act as a Single Webpage Application and will share props. 2.If it is a different module then it will have its own store where the data is synced using Enhancers from the DB.

The first will be helpful for sending the primary key which tells the Reader which corresponding url's data to show. While the 2nd option will have some trouble in routing and telling the reader which url's data to render.

[paras7735]

Hey @oliversauter I have made a first draft of the proposal for Read it later list. Please Review it. https://docs.google.com/document/d/1CIjjeZl6FpE9xbGlI7z96CgEDKydpQPDLFgrKSkUkfE/edit?usp=sharing

[daviddias]

@paras7735 Hi 👋🏽 Did you managed to make more progress on this feature? Either during GSoC or externally?

Having a Read Later list combined with the future soon to be shared collections will enable Researchers to create a great platform for researchers collaboratively review and share piles of notes through ever growing lists of articles.

[blackforestboi]

@daviddias we have not yet progressed on that as we had to prioritise mobile/multi-device sync and collaboration features.

But we are VERY much looking forward to do the archiving features, which could be also an ideal use case for IPFS actually. However we lack the funding and (autonomous) (wo)manpower to get it done right now. It's a feature that can be integrated relatively independently though if there is someone skilled enough doing it.

[Victor239]

Related links:

• Feature request for Read-it Later / Page Archiving
  • Summary: Being able to make a snapshot of a page to:
    • Read it later when offline
    • Access the original page when site goes down
    • Have Annotations still being anchored, even if site changes
• WIP PR for Reader View (currently on hold)

I'd also like to add my 2 cents that the page archiving of a readable version is what would get me to start using Memex more. Currently I don't feel it's reliable to store my annotations in it since the underlying webpage can be removed, edited, redirected etc and it would make reviewing my annotations far more difficult. I hope to see this feature back on the roadmap again soon.