Open blackforestboi opened 6 years ago
I would like to work on this issue. Can you give more information regarding it? Thanks
I'm also interested in working on this. Would like to discuss further.
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?
@oliversauter yes, I found the project through GSoC and I'm interested in working on it for it.
@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.
@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.
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.
@oliversauter I would like to work on this, I have decent experience in React, React Native and Redux. Please help me get started.
@oliversauter I'm relatively new to React. I understand your concern, so thanks for the heads up.
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
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?
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. :/
@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.
Yes, I will send a [WIP] PR the moment I complete filtering of laterlist in the overview component :D
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
@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.
@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 .
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.
This is a rough user flow mockup and some queries regarding this issue
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
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 can have the following functions
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?
I talked to @oliversauter about it and he pointed me to the freeze dry repository for this part.(https://github.com/WebMemex/freeze-dry)
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?
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.
@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.
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
@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.
@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.
Related links:
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.
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:
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.
Goals V2: Read it later - Offline variant
Goals V3: Read it later - Full HTML
Optimisations: