Recap on how to share items

[SimonLab]

Sorry to create a new issue linked to sharing items as we have already a few open (see below).
I need to recap and clarify the features to make sure I'm not going on the wrong direction and that we have the same understanding on what to create.

However please feel free to transfer this issue or split it into comments to other issues. We might want to write down some of this content in Readme or buildit file to make it easy to find the answers later on.

The existing issues we have linked to lists and groups. I found these issues by searching list and group in the app, mvp and auth repos. I might have missed some, please let me know if there are other that I need to have a look at:

• Groups UI/UX auth#232 Create groups in auth
• EPIC: groups: how to collaborate with one or more people auth#220: describe the group and group_member tables in the auth app
• Reordering items #145: Reorder items.Linked to the next issue:
• EPIC: How to Prioritise Our Most Important, Urgent or Valuable Tasks? app#283: mention organizing items in lists and sharing lists. Otherwise the issue is more UI focused and a collection of feedback and possible features on how to prioritize items. It also mention drag and drop with Alpine
• EPIC: Lists app#271: Issue created to discuss how to manage lists
• Can we remove "Lists" and just use Tags to group/organise and view similar items? app#233: Discuss the necessity of having lists
• EPIC: Team Mode app#219: An issue to collect features, articles, videos... linked to collaborative work

So to recap:

• We have the notion of lists to organise and prioritise items. The list structure/schema/table is defined in the MVP
• We have the notion of groups where people belonging to a group can see list of items shared in this group. The groups are defined in the auth application
• By default every users of the mvp will have a personal/private list which is linked to a personal/private group.

Default private list and group for users

When a user login in the mvp app using auth:

• Check if a private group exists for this user. Create the group if it doesn't exist yet.

  • We need to find a way to define a group as private or personal, can we do this using the kind field: EPIC: groups: how to collaborate with one or more people auth#220 (comment) or do we need to create a special personal boolean field?
  • It can only exist one personal group per user.
  • Other People can't be added to personal group
  • The auth application can be used for other application. Do we want the groups to be the same for all the application or do we also need to have a join table between group, person and application?

• Once the private group is verify, we now need to check the personal list exists on the mvp for the user and create it if it doesn't

  • similar to group, how do we know a list is marked as personal?
  • There can be only one personal (default) list?

• When creating a new item, this item is added to the personal list

  • How do we want to display the lists the item belongs to, similar to tags?:
    

  • Do we want to display the groups an item is linked to via lists?

Manage lists

How to add items to lists?
Similar to tags we could have a simple input text where list names are separated by commas:

Manage groups

[nelsonic]

@SimonLab thank you for opening this issue to highlight the lack of clarity surrounding sharing items. 👍
Perhaps the best way forward on sharing is to take a step back and ask ourselves:

As a person using the App to managing their life/family/work/company/etc.
How do I want to be able to share item and lists?
So that I can collaborate on getting it done.

And then from that we can determine what the most intuitive UI/UX is.

[iteles]

Sharing a list at the MVP level could be as 'simple' as sharing with the email address of another user and at this stage you have to know the email address linked to the github account of the user (or whatever they are using to log in).

On lists UI

I would like to move this section of my reply to another issue (maybe dwyl/app#271 ?) but it follows directly from the UI drawings above, even though it has nothing to do with sharing which is the subject of this issue?
Where should I move it to?

I personally feel that from a UI perspective, adding the lists as an extra layer of 'tags' is going to be problematic even at the MVP stage because it will hinder us from properly testing the usage of this feature in the ensuing chaos.
In short: it will create UI clutter (increasing usage lag for tired minds 🙋‍♀️ ), aggravate existing issues around not being able to find tasks or things getting bumped off the bottom of the list and also convolute the functionality itself, meaning it'll be difficult to test.

There is also another open question here: Do we want an item to be part of more than one list?
I'm trying to think of use cases for this and can't even really think of edge cases here. Unless we can come up with good use cases here I would say we go for a one-to-one relationship here. Tags are the way to go for many-to-many.
This is at least what my view on the necessity for the existence of lists is based on: dwyl/app#233 (comment)

[nelsonic]

@iteles having the same item on multiple lists is a use-case I want for sure.
You might not be envisioning it right now. But in a corporate team setting being able to have an item on both the manager's mega list (think "Scrum of Scrums") and the "direct report's" todo list is essential for decluttering/focus. Yes, the manager could just share their list with the team, but if it has 100's of items on in, it's suuuuper distracting to the person that only needs to see 3-5 items at a time. We could just apply filters e.g. "show only items assigned to me" ... But that's exactly what this achieves but with fewer "clicks" ... one of my biggest bug-bears and common frustration with JIRA for Engineers (the people getting the actual work done...) is that JIRA is designed for the bosses not for the people doing the day-to-day work. It's a huge UI/UX fail widely documented on HN:
news.ycombinator.com/item?id=18642336 --> techcrunch.com/2018/12/09/jira-is-an-antipattern

Please give me a chance to spell this out, because there is clearly a lack of clarity ....
I have an order of magnitude more time-spent thinking about this problem, both from the deeply frustrated "user" perspective and the technical implementation side. And what I really want is the most intuitive UX possible for all of this while still preserving the separation of concerns, security and easy of Developers onboarding onto the project.
If this was easy Atlassian [who have basically infinite cash!] would have solved it for JIRA instead of buying Trello for $425 million; yes, it's not "rocket science" ... but if we get this "wrong" we are a footnote in the history of failed attempts.

[iteles]

@nelsonic I was thinking about having items on just one list per user. This is why I had it in the UI section of my comment exclusively.
Completely agree that it needs to be on different lists for different people 👍

Please do spell it out when you have a chance. There are hundreds of other things we need to get on with. This is not the be all and end all blocker!