Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Grouping channels #31

Open
sebsel opened this issue Oct 24, 2018 · 4 comments
Open

Grouping channels #31

sebsel opened this issue Oct 24, 2018 · 4 comments

Comments

@sebsel
Copy link
Member

sebsel commented Oct 24, 2018

This one might be complicated to combine with the sorting algorithm, but as the list of channels grows, it would be nice to be able to put them in groups / folders.

That makes it easy to at once collapse all your IndieWeb related channels, or channels about other general topics and group algorithmic filled channels together.

But I guess most needs can be fixed by just reordering them and playing with emoji.

@EdwardHinkle
Copy link

I have started to wonder about this recently as my channel lists continue to grow. One way I've worked around that is by having a "view unread channels only" mode in Indigenous, but there are times where I wish I could quickly and easily make a whole section of channels disappear temporarily so I don't even see if there are new posts in those channels.

This makes me think groups would be useful, however I would recommend groups strictly being containers for channels. Unlike traditional RSS feeds, I feel the following items should NOT be made available as we think about Channel Groups:

  • You should NOT be able to "view" the channel as a combined list of all the posts from the channels underneath it (I know RSS feeds in the past have allowed you to view a folder and see all the posts contained within the folder).
  • You should NOT be able to see how many unread posts are contained within a group.

I think groups should be strictly for categorizing large lists of channels and showing/hiding those lists of channels to provide an easier way to focus on what you want and ignoring the excess noise.

I think those specifics help make Channel Groups beneficial without some of (what I consider) bad side effects of RSS Reader's versions of Folders.

@sebsel
Copy link
Member Author

sebsel commented Oct 24, 2018

This is exactly what I was thinking about, thanks for clarifying. Making the group a summary of the feeds would defeat some purposes of the feeds. I only intended the part of organizing them in the channel list.

You should NOT be able to see how many unread posts are contained within a group.

I thought about something like you may show combined unread counts for groups, but if one of the feeds of a group has a boolean, then the whole group has to be a boolean. But not allowing any grouped unread-counts also works.

@EdwardHinkle
Copy link

Makes sense. If unread were allowed within groups I definitely think there should be some type of option where the server doesn't return any unread counts. Because I can understand how some people might want them, but I definitely would want to use groups to hide unread counts :)

@sebsel
Copy link
Member Author

sebsel commented May 23, 2019

On a recent IWC I talked with someone about this briefly, and we came to the conclusion that it could also be achieved today by creating an empty channel, and starting the name with, say, an emoji or another indicator of sorts.

Your menu would then look like:

🕸 Indieweb
IndieWeb people
IndieWeb public
🙃 Friends
Highschool
Summercamp 2019
Other

Of course some people are already using emoji in their channel-names. You can also do the reverse: use empty channels without emoji in the name. If the spec where to do something, I would say it would be enough to just indicate "this channel is actually a header". Then you can use sorting to decide what is in the headers and what not, and we remain somewhat backwards compatible. These headers could be examples of read only channels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants