Can't make Lists public and permissions behavior inconsistent with Maps

[betsydupuis]

#The issue
I do not have access to make a list public. Lists are private by default. It could be a permissions issue for my access level.

This behavior is inconsistent with maps. Maps are public by default, but lists are private by default.

Why change?
These kinds of inconsistencies can lead to user confusion and frustration.

How to fix
To be consistent, both features should have permissions to be private or public by default, but which one? Here are some relevant issues:

1. Most document editing systems use private by default.
2. LittleSis is an organization focused on sharing information which lends it's self to public by default.
3. Because the permissions settings for maps and lists are so different there's a large amount of work to make permissions consistent.
4. The permissions settings for maps is obscured, so switching to private by default would hide the feature for most people.
5. Depending on how the database is set up, it could require some kind of cleanup to ensure that the permissions remain the same.

Requiring the user to chose permissions up front with a nudge towards public, and seems like one option that could prevent confusion without overhauling the existing design.

Github itself is a good example.

[aepyornis]

Thanks!

Regarding the issue you are correct regarding permissions. I just changed your account's role and you should now see the permissions option for lists:

I agree it's confusing, but we are trying to balance giving users freedom to do their own private research on the site, while preventing bots (and ill-will people) from causing havoc.

In the past, we have made a philosophical distinction between Lists and Maps. Lists are like our Profile Pages. Collaborative and backed up by with sources like the data on Entity and Relationship pages.

Maps, on the other hand, are the creation of individuals. We have a different disclaimer for those. Hence, we don't allow all users to create public lists, but we do for maps. Lists, unlike maps, have 3 types of permissions, Open (public), Closed (Public), and Private (Private).

Lists as a feature predate both Tags and Maps, so it could be worth reviewing these concepts and perhaps rethink permissions in connection to all 3.

[betsydupuis]

In the past, we have made a philosophical distinction between Lists and Maps. Lists are like our Profile Pages. Collaborative and backed up by with sources like the data on Entity and Relationship pages.

That makes more sense now.

Yes, it can be tricky sometimes to decide whether to create an organization or a list. Conceptually they are very similar.

I tend to think of entities as being for fact checking, and lists and maps as more narrative focused. I'm interested to hear more about the vision of the core team so I can assist with UX. @josephlacey and I have been chatting for a while about how I can lend my experience.

Documenting the current state of the app is part of my process with legacy software, so that's why I'm creating a lot of tickets.

Lists as a feature predate both Tags and Maps, so it could be worth reviewing these concepts and perhaps rethink permissions in connection to all 3.

This is all good context to have.

It is very easy it is to pollute the public ecosystem with maps, so I can see how easy access would be a problem for lists. It's a lot easier to trace connections through maps than lists, so I use maps much more frequently.

It took me a while to realize there was a "private permission."

Something that might make sense in the future would be to enhance the public profile to allow users to share their own maps and lists on their profile, but only allow admins to post to the Explore page. Or to create a filter on the Explore page of curated maps and lists by admins.

[betsydupuis]

Lists as a feature predate both Tags and Maps, so it could be worth reviewing these concepts and perhaps rethink permissions in connection to all 3.

Another note on tags and lists. Aren't they in theory the same feature?

Tags in are basically lists with a shortname, but no source url?

I also found another layer of permissions hell 😂 I can add tags to entities, but not lists.

[aepyornis]

Another note on tags and lists. Aren't they in theory the same feature?

Tags and Lists are indeed very similar, so it can be fuzzy as to when a tag or list should be used. Tags are intended to be broad categories that could potentially be attached to many thousands of entities, while lists are more suitable for narrowly defined and smaller groups of entities.

For instance, we have a tag fracking for anything related or involved with fracking. A example fracking List is NYS Common Retirement Fund Fracking Investments, a more specific grouping of fracking entities. There are no private tags (while there are private lists).

Also note that only Entities can be put on a list. Entities, Relationships, and Lists can all be tagged. We have a page of lists that are tagged fracking.

I also found another layer of permissions hell 😂 I can add tags to entities, but not lists.

That sounds like a bug :) This is where user roles are defined. You are a collaborator, the highest level besides admin!

[betsydupuis]

That sounds like a bug :) This is where user roles are defined. You are a collaborator, the highest level besides admin!

Ok, so I can split the bug into a smaller ticket – in the current state, editors can add tags to entities, but can't add entities to lists (this could just be an issue of closed + public lists showing up in search that are not accessible).

Should a editor be allowed to add entities to open/public lists and tags to entities?

I might want to create another account with the different permissions to keep testing. Can you add that account as a collaborator if I do that?

[aepyornis]

Ok, so I can split the bug into a smaller ticket – in the current state, editors can add tags to entities, but can't add entities to lists (this could just be an issue of closed + public lists showing up in search that are not accessible).

You should be able to add entities to lists from the list page

but correct, at the moment you cannot add to private lists from the entity page sidebar. I was always curious how often people use that sidebar instead of main list interface. We could add this as a new feature. Many features on the site assume the target is the public dataset and will ignore private data. It's easier to implement since we can skip private access checks.

Should a editor be allowed to add entities to open/public lists and tags to entities?

Certainly up for debate! We should also encourage more active editors to become collaborators to have access to more editing features.

I might want to create another account with the different permissions to keep testing. Can you add that account as a collaborator if I do that?

sure

[betsydupuis]

All good inform!
If you're interested, I'm working on an audit in this google sheet: LittleSis UX Audit

The idea is to document the current state, then this will make it easier to see how to add use cases in the future.