This is a request from OTRS 9970047:
allow the use to create a list in the list..
like this the lists are more organized..
For example : I like to add a "list" called cinema.. inside it sublists (another lists) that I like to separate (Cinema History, Cinema Directors etc)..In short : It would be awesome to allow creating lists inside the lists. ..
We were looking at this, but seems to be an edge case… I could be convinced otherwise depending on the complexity of implementing AND if there was product/design buy in for actually implementing this in the clients.
@Dbrant @JMinor @RHo @cmadeo Any need for this?
@Tgr how much would this complicate implementation?
The survey that Rita conducted will shed some additional light on the usage of reading lists, and may help inform the subject of this task, too. However, I'm guessing that we can easily live without nested reading lists for the foreseeable future. The backend is welcome to implement nested lists, as long as the API for working with regular (non-nested) lists is not impacted.
In the simplest version, where you have two levels (lists of items and meta-lists of lists) it's just an extra table and another set of APIs for CRUD/syncing/sorting - pretty straightforward although more code to write and maintain (for a pretty dubious use case IMO). If it needs to be recursive (ie. a list of lists can contain another list of lists) that seems like more trouble, with the kind of problems Wikipedia's category system has (circularity, performance problems with deep search).
I would agree with @Dbrant. We'll see what the design research says, but I don't think "lists of lists" is a must have priority for the feature as currently planned, but building for the future is also fine.
I definitely think ruling out recursive lists makes sense. The only related story I could see is a sublist belonging to multiple parent (ie. List 1 contains sublist A and B and List 2 contains sublists B and C?). Would that be problematic?
I don't think doing lists of lists in a many-to-many manner would be significantly more complicated. An extra join table would have to be managed, but otherwise no difference.
Two ways that might accommodate having lists of lists that pop to mind which shouldn't be difficult to implement on neither side:
This is pretty straightforward: the idea is to have lists be represented as labels. One creates a list and then instead of actually naming the list (but perhaps they might to do so as well), they label it with different labels. That would require an additional table on the back-end (for labels) and a foreign key from the table of lists to the table of labels. The search capability then should be also adapted on the front-end, so that a user can search for multiple labels in conjunction and narrow down the number of lists appearing in the interface.
Here the idea is to use a delimiter of sorts in the list name which acts as a path separator. Let's say that the delimiter is /, then if a user creates a list named listA inside listB, the back-end would actually create the list named listB/listA. This would require virtually no change to the back-end, while on the front-end it's a matter of parsing the list names and displaying them hierarchically accordingly.
I'm a big fan of the label approach. There's some discussion how it might be used as a general annotation system in the Reading List technical plan comments as well.
I like how simple "fake list of lists" is but I dislike that it will force a hierarchy on users. For example, I can't have a list called "Animals" appear in two other lists, "Favorites" and "Nature". The tag approach is far more useful.
There were a handful of comments in the survey results from Android users who wanted 'lists of lists' or basically another sub-level of categorization beyond the current multi-list functionality. However, this was somewhat offset by similar number of comments from users who wanted lists to be a more simplified structure (one list or at least just one default list).
In short, based on the survey responses I would agree with @Dbrant that this quite low priority for users, but would be good to have built for the future.
FWIW I prefer the label approach as the mental model seems to align better with the current ability on Android for the same article to appear on multiple lists.
Thanks all for the feedback, I think for the initial RFC and implementation we will forgo complicating the service since there isn't a huge need from users.
While it isn't terribly complicated, we want to try to get the initial implementation to serve the immediate needs of the Android users.
Also it seems like this won't be very hard to add in the future if we find that we want to add the feature in v2.
Fake lists of lists seems troublesome in an environment where clients cannot easily update themselves. Lists of lists (or tags/labels if you prefer) as a separate entity with a many-to-many connection to plain lists should be easy to add in a later step if desired.