Can we remove "Lists" and just use Tags to group/organise and view similar items?

[nelsonic]

As part of taking a look at this MVP with fresh eyes (following the update to /product-roadmap ...)
I took a look at the ERD that includes lists and list-items:

Can we simulate the idea of "lists" in the UI without having/needing the lists and list-items schema? i.e. show the person their Tags with the count next to it and when they tap/click on the tags they will see all the items with that tag grouped nicely.

The only downside I can think of would be if the person wanted to share a list with a colleague/spouse and for the permissions to be applied to all the items ... 🤔
Again, I think this is achievable without needing a lists schema, because the permissions/sharing would simply be applied to the individual items.

I think I'm going to remove lists and list-items for now and if we end up needing them, we can always add them back. The UX of a "list" can still be achieved easily in the UI simply by displaying the Tags in a menu.

Thoughts?

[iteles]

@nelsonic I believe tags are absolutely the best way to organise items in general and using them in the way you're proposing does eliminate the need to have the additional concept of 'lists'.

However, these are two very different things in my mind.

I have used both applications and paper solutions to get organised for the last 12 or so years and am in the process of writing up my research but all of the applications I have managed to use successfully have included both tags and 'lists'.

Here is a list of the tags I had set up in 'Things' which I used to use when working at Accenture (for 3 different bosses - Ian, Simon and Lionel):

And here's an extract of the Projects I created whilst I was figuring out how best to use it:

I stopped using this because I moved to Github and wasn't interested in using more than one tool as it meant I just couldn't trust that I wouldn't forget something if it was across multiple places.

From a technical perspective, it may not make much difference in terms of the schema but from a UX perspective, losing the additional layer of organisation (by eliminating 'lists' or projects) could make the application more complex for a number of reasons:

• Mixing usage of a feature: Using tags for context, time estimation, status or as a trigger for integrations and then still mixing this with categorisation into lists or projects will convolute the usage of the feature in the minds of users ("You can use it for anything!" is less helpful than some imposed limitations or suggestions)
• Size of the list: Using tags for everything is going to create quite a long list of tags for most people which can contribute to overwhelm easily
• Complicates at-a-glance utility: When I look at a to-do list item in the 'tag' view (i.e. all of the items with a '1 pomodoro' or 'priority-2' tag on them at once, being able to see which 'project' they belong to gives me a whole lot of context and helps me to decide which of 2 things of the same priority I will work on next. If there is no 'list' or 'project' then we cannot easily display one key piece of information in the UI that will help with context - tags can and should be displayed but often there are too many of them for a clean UI and they can quickly become unhelpful
  e.g. where 'dwyl app' is the project:
• Familiarity - It could be that this is a question of habit, but given that the major to-do applications all have the concept of 'projects' and 'tags', people looking to see whether they should switch over to the dwyl app will likely see this as an 'omission' rather than a feature
• Adding project/list-wide information? - Whilst each item can have a deadline or scheduled date, there are a number of things that are much 'simpler' to do at a project level (such as adding a deadline and start date or, as you mentioned @nelsonic, sharing a list or providing write access to a team to a certain list). This can also be done at tag level but again on familiarity, may be less intuitive and mesh the various utilisations of the tags feature in people's minds

In fact, a lot of the big applications out there (such as todoist and Things) have now introduced a second layer of categorisation (Things has 'areas' as well as project and tags and Todoist has just completed a 2 year complete rewrite of their application where they introduce sections within project. Totally unnecessary for now.

In short, from a UX perspective, I would hypothesise that lists/projects are a necessary feature to keep things intuitively separated in one's mind and in the app. In the schema, the only point to really make here is that there might end up having to be different types of tags in case we want to display them differently or add more information to specific ones.

[nelsonic]

@iteles it's great to see you sharing your thoughts and expertise on this topic! 😍
This is the kind of "user feedback" / "UX research" that we need to collect ASAP!
I opened this issue (_to explore removing lists for the MVP to reduce the scope of what we are building in the short-term. In a basic "Capture, Categorise & Complete" cycle, I didn't see the need for the list schema because by default, we would show the user everything.
The MVP would be a single view with all items not unlike a super basic Todo List:
https://todomvc-app.herokuapp.com/

The idea being to have something that we can start testing ...
And then based on the "user feedback" we would build the features that we need.

When building Apps from scratch there is always a dilemma when it comes to adding features pre-launch: is this a feature we 100% know we (the people using the App) are definitely going to need.
E.g: Authentication is unquestionably a "hygiene factor" because people's data needs to be protected.
Not having Auth means anyone can add any item they want or edit/delete other people's items.
https://dwylapp.herokuapp.com/items

So the question I was hoping to raise by opening this issue is:
are lists of items necessary in an MVP where there is a single view for all items?

I have no doubt that people will want the functionality of Lists or Projects (to group/organise items) in the future. But do we need to have Lists in the MVP? https://github.com/dwyl/app-mvp-phoenix ...?
I think it's worth having a separate issue where the idea of Lists / Projects is explored in more detail from first principals. In that issue we would discuss the UX for interacting with / managing those lists.

[iteles]

In short, no. They're not necessary for MVP.

I'll open a separate issue with the above ☺️

[nelsonic]

On further consideration/reflection, and related to discussion in #234 (Capture)
we need a way of grouping the items that are created as part of a "Brain Dump"
so that we do not lose the context in which they were created. To group related items that were created as part of a Capture session, the most logical construct to do this transparently (without the user even being aware of the concept of "lists") is to use a list (under-the-hood).

[nelsonic]

@iteles when you have time - ahead of sprint 2 - can you please open an issue describing how you would expect lists to work? (preferably with some sample UI/UX)
Link this issue to the new issue.
At which point this issue can be closed.
Thanks!