Display feed tag selector on top of subscriptions screen #5374

peakvalleytech · 2021-08-30T04:18:35Z

Fixes #5318

ByteHamster

There is now a "#root" tag in the navigation drawer
The "more" button is too prominent. It makes the screen feel like some kind of "editor", not like a normal main screen
Does not work together with multi-select
Why are there two lists of tags? I would just make it a single list where tags can be selected
The "All" chip has a nice checkbox when selected. The others have colorful, overlayed icons. Please make all look like the "All" one.
After playing around with it, I think it is okay to not filter the tags when changing the feed filter. That reduces the complexity and could even be easier to understand for users
When changing the sort order while all subscriptions are displayed, it sometimes starts filtering by tag
When removing the tag of a subscription, RecyclerView displays a nice animation. When changing the filter on top, it doesn't. Why?
When there are no tags stored, there should be no tag bar

Screenshot:

app/src/main/java/de/danoeh/antennapod/adapter/FeedTagAdapter.java

app/src/main/java/de/danoeh/antennapod/adapter/SubscriptionsRecyclerAdapter.java

ByteHamster · 2021-09-03T20:30:41Z

app/src/main/java/de/danoeh/antennapod/fragment/SubscriptionFragment.java

+                            Chip rootChip = null;
+                            folderChipGroup.removeAllViews();
+                            for (NavDrawerData.FolderDrawerItem folderItem : feedFolders) {
+                                Chip folderChip = new Chip(getActivity());


Don't you already have an adapter for this? Also, this is too much code in the RxJava handler. Please extract to a method.

No this is not a RecyclerView. It is ChipGroup, used for the second tag list. I don't think RecyclerView would work, since it doesn't provide wrapping (LinearLayout) or varying sizes for items (GridLayout)

app/src/main/java/de/danoeh/antennapod/fragment/SubscriptionFragment.java

ByteHamster · 2021-09-03T20:38:58Z

core/src/main/java/de/danoeh/antennapod/core/preferences/UserPreferences.java

+    }
+
+    public static void addTagFilterId(long tagFilterId) {
+        Set<String> tagFilterIds = prefs.getStringSet(PREF_TAG_FILTER, new HashSet<>());


This stores which tags are selected on the subscriptions screen, right? So this would only be needed on the subscriptions screen. The UserPreferences class is already monstrous, so please move the code directly to the subscriptions screen.

But this allows the the selected tags to be persisted. If removed, the user would have to re select tags. I think it is a useful feature to have.

For instance, imagine a scenario where you have many podcasts but a few ones that you actively care about. It would be annoying to have to reselect that tag every time. Instead, if persisted you could just open the app and have the tags with the primary podcasts already shown.

Besides, it's already implemented, and a user(s) will probably ask for it in the feature. Just seems like one those little 'it would be nice' request that users are bound to bring up.

If the User preferences is too large, I wouldn't mind helping to refactor it.

My idea was not to not store it. It was to move the storage code to the only fragment that uses it - just like how the number of columns is stored directly in the subscription fragment. This also decouples the different components of the app from each other.

core/src/main/java/de/danoeh/antennapod/core/storage/DBReader.java

ByteHamster · 2021-09-03T20:42:34Z

core/src/main/java/de/danoeh/antennapod/core/storage/DBReader.java

-                    items.add(drawerItem);
-                    continue;
-                }
+                        feedCounters.get(feed.getId()), playedCounters.get(feed.getId(), -1), recentPubDate);


This means that AntennaPod always needs to do 2 additional SQL queries that could potentially affect all episodes. Seems like it could cause performance problems. The app is rather sluggish with >150 subscriptions already.

I was trying to extract the sorting logic to a sepearate class, but it was coupled with the adapter. I noticed that you had members in the NavDrawerData class to hold them. So I thought maybe will could store them in those, which does work. But didn't realize the performance overhead. The queries are rather complex.

I guess I could pass in the adapter into the sorter class instead. Would that work for you?

I guess I could pass in the adapter into the sorter class instead. Would that work for you?

Hmm, not really happy with that either, to be honest. The database stuff shouldn't be passed over to the UI. How about introducing a getFilteredSubscriptions method to DbReader (that is also used internally by getNavDrawerData) that takes a SubscriptionsFilter as a parameter? That filter could then contain information about tags. Then the fragment does not need to do any filtering.

ByteHamster · 2021-09-03T20:42:53Z

core/src/test/java/de/danoeh/antennapod/core/storage/DbReaderTest.java

@@ -31,6 +38,7 @@
 */
 @SuppressWarnings("ConstantConditions")
 @RunWith(RobolectricTestRunner.class)
+@Config(sdk = {Build.VERSION_CODES.O_MR1})


Why? Looks like you need to update your local Java install instead (I think API30 is only supported on Java 9+)

ByteHamster · 2021-09-03T20:44:51Z

model/src/main/java/de/danoeh/antennapod/model/feed/FeedPreferences.java

+
+    public void setTags(Set<String> tags) {
+        Set<String> newTags = new HashSet<>();
+        newTags.addAll(this.tags);


This adds tags, it doesn't set them

Yeah, i know. Is this not okay?

I think it is only used for testing.

peakvalleytech · 2021-09-04T00:35:12Z

There is now a "#root" tag in the navigation drawer

I'll remove it

The "more" button is too prominent. It makes the screen feel like some kind of "editor", not like a normal main screen

Yeah, I know. Mostly doing this as a mock up. I hope to replace it with an rotating arrow button as discussed in #5318

Does not work together with multi-select

Yes, i left this out as well. Will implement now

Why are there two lists of tags? I would just make it a single list where tags can be selected

This was suggested by one of the users and favored by @keunes. I also like this design too. I think if we improve the design of it, it can work. The purpose for two is the first shows the selected tags and the second shows all the tags. The second one is shown when user clicks the more button. From the second, the user can update the selected tags.

The "All" chip has a nice checkbox when selected. The others have colorful, overlayed icons. Please make all look like the "All" one.

Yeah, we still need to work on the design. I was hoping to have it resemble the mock up shown in #5318.

After playing around with it, I think it is okay to not filter the tags when changing the feed filter. That reduces the complexity and could even be easier to understand for users

Do you mean reset the tag filter to 'All' when the filter is changed?

When changing the sort order while all subscriptions are displayed, it sometimes starts filtering by tag

Must be a bug. Thanks for finding it.

When removing the tag of a subscription, RecyclerView displays a nice animation. When changing the filter on top, it doesn't. Why?

Filtering requesting reloading all the feeds from the db, so the whole fragment and recyclerview is recreated. Removing and adding tags doesn't only requires updating the recyclerview which provides an update animation.

When there are no tags stored, there should be no tag bar

But i think it helps with discoverability. Maybe when the user clicks on more, if not tags are stored, instead of showing the second tag list a message telling them how to add tags can be displayed. For example, 'There are currently no tags. To add tags go to podcast settings, and can click on tag settings.

ByteHamster · 2021-09-04T09:09:14Z

This was suggested by one of the users and favored by @keunes

As I understood it, the idea was to have one expanding list when having more tags than what fits on the screen - not two lists. This "duplicate" tag bar basically eliminates the advantage of the tag bars: When you want to change the tags, you always have to do two taps.

Filtering requesting reloading all the feeds from the db, so the whole fragment and recyclerview is recreated.

When just loading the new list contents into the RecyclerView, it should animate. Maybe the IDs are somehow not persistent.

But i think it helps with discoverability.

The most important thing for new users is to subscribe and listen to podcasts. Tags only become relevant when you have dozens of subscriptions - before that, they are just additional visual clutter that people need to deal with. Discoverability is already achieved by having a pretty prominent long-press menu item.

I wonder if it should be possible to select multiple tags. Only selecting one tag at a time is just as powerful and saves one click.

peakvalleytech · 2021-09-05T23:51:54Z

As I understood it, the idea was to have one expanding list when having more tags than what fits on the screen - not two lists. This "duplicate" tag bar basically eliminates the advantage of the tag bars: When you want to change the tags, you always have to do two taps.

I don't think it eliminates the advantage: sure, it might require an extra click. But if we used a dialog or somewhere similar, it would still require more clicks. And it is a lot cleaner and less decluttered to display only the selected tags and display all of them when needed.

This is quoted from the OP of #5318:

I like it overall, though I am not a great friend of horizontal scrolling. In the the mock up it looks like you need to do that as the tags are only within one line and fade out.
The touch area like it's drawn there is already small in height, it requires more action and may interfere with gestures and thus and thus could be uncomfortable.

How about the following:

show a toggle button tags ^ which, when clicked on, reveals all available tags + a toggle tag Show all

when clicked on again, the list of all tags vanish except for those, which are selected. So, you know what you are looking at.

the list of tags displayed don't fade out but wrap around into the next line(s)
It would be rather similar to what you have now.

The only detail that differs is that the top tags do not wrap when tags span more than the visible area.

The most important thing for new users is to subscribe and listen to podcasts. Tags only become relevant when you have dozens of subscriptions - before that, they are just additional visual clutter that people need to deal with. Discoverability is already achieved by having a pretty prominent long-press menu item.

Yeah, that is a good point. I'll add this suggestion.

I wonder if it should be possible to select multiple tags. Only selecting one tag at a time is just as powerful and saves one click.

Selecting one tag is powerful, but not as powerful or flexible as selecting multiple tags. To be honest, i don't know why, but I completely neglecting if thinking about only selecting one tag, when I implemented it I just assumed that users should be able to select multiple tags. The former probably would have been easier ;). After thinking over again, I really do think we should let users be able to select multiple tags. I mean, it is already built into the implementation. And selecting one tag is already a subfeature of being able to include multiple tags. It is only a plus. Also, consider this use case. Let's say you have a set of podcasts in different groups that you actively listen to, and you have one or a few others you don't. For the groups you actively listen to you can select them and have the app always show those. This would be nearly impossible by only being able to select one tag at a time. Maybe if you only had 2 groups, but that would defeat the purpose of having groups. Maybe it's probably easier to think of selecting multiple tags as a filter where you can add and modify the feeds shown based on which tags are selected, not just selecting one at a time as if they were separate lists.

…x other PR issues.

ByteHamster · 2021-09-11T15:33:33Z

show a toggle button tags ^ which, when clicked on, reveals all available tags + a toggle tag Show all when clicked on again, the list of all tags vanish except for those, which are selected.

The only detail that differs is that the top tags do not wrap when tags span more than the visible area.

I understood this to be a single list that shows/hides the non-selected tags. I think having a single list would already help to no longer make it feel like an editor screen. Also, showing two lists makes you see the selected tags twice.

Thinking about this more, I am no longer really a fan of having an expanding list. My original idea why I suggested a tag bar was the following:

#1711 (comment)
How about displaying the tags directly above the subscriptions list? Clicking could then filter (with a nice animation) in place. That makes it faster to switch and (at least in my opinion) easier to discover.

The tag bar is supposed to be a quick way to switch between tags. If the tag bar is not quick and needs something like 4 taps to change to another tag (expand, de-select one, select the other, collapse), we can just make it a dialog and have more screen space for the actual subscriptions. I will copy this to the issue for discussion.

peakvalleytech · 2021-09-13T00:26:01Z

@ByteHamster So do we just have one single bar that fades the tags that don't fit?

ByteHamster · 2021-09-21T17:38:31Z

So do we just have one single bar that fades the tags that don't fit?

I would say a single bar that can be expanded if it is too long. Selected items are moved to the front. Still, I am not 100% sure about the fact that selecting multi-selects - this makes selecting a lot more clicks.

peakvalleytech · 2021-09-22T19:41:31Z

So do we just have one single bar that fades the tags that don't fit?

I would say a single bar that can be expanded if it is too long. Selected items are moved to the front. Still, I am not 100% sure about the fact that selecting multi-selects - this makes selecting a lot more clicks.

I say we just let the user scroll if it is too long. Many apps including Youtube do the same. The expanding bar idea was brought up by a user who disliked horizontal scrolling. I don't think we should always try to accommodate the request of a single user especially when there are no user studies to support it.

Well, i am the sole developer implementing it, so I think I my opinion counts ;) I say we keep multi select for tags. Yes, UX should limit the number of actions needed to accomplish a task, but it alos depends on how often that task is done. For common tasks, it matters. However, the user will not always be using the tag bar everytime they open the app. In fact, the only users would probably be power users with many subscribed podcasts. And I think power users will appreciate the added ability to multi select. Also, it only increases the clicks by at most one. Users can just click on 'All' to reset the selected tags. So it only requires at most one more click.

@keunes what do you think?

ByteHamster · 2021-09-24T08:44:13Z

Yes, UX should limit the number of actions needed to accomplish a task, but it alos depends on how often that task is done. For common tasks, it matters. However, the user will not always be using the tag bar everytime they open the app.

This would be an argument for not using a tag bar but a tag dialog, leaving more space for the actual subscriptions.

peakvalleytech · 2021-09-24T09:19:28Z

Yes, UX should limit the number of actions needed to accomplish a task, but it alos depends on how often that task is done. For common tasks, it matters. However, the user will not always be using the tag bar everytime they open the app.

This would be an argument for not using a tag bar but a tag dialog, leaving more space for the actual subscriptions.

Well, we already decided on using a tag bar based on previous discussions and have already started working on the tag bar. If you ask me, pretty unwise to turn around and decide to do a dialog. Let's just do the tag bar with horizontal scrolling and multiselect. Your main objection to multiselect was that it requires more clicks, but that isn't true as I stated above.

ByteHamster · 2022-01-06T14:10:35Z

Are you still interested in working on this, @peakvalleytech?

peakvalleytech · 2022-01-07T21:01:54Z

Are you still interested in working on this, @peakvalleytech?

Sure, how would you like to proceed? It's been a while

keunes · 2022-01-07T22:08:58Z

I would argue for going for a list, as proposed before and already largely implemented (from what I gather from the conversation - I haven't tried a debug build):
https://design.penpot.app/#/view/e357a320-7535-11eb-8a88-eb0147e048f5?page-id=7accff30-fa1e-11eb-a745-7b5f72f6725e&index=0&share-id=e321ee60-7002-11ec-8da6-c2b142838c8b

I can also imagine this without horizontal scrolling, and instead take as much space as necessary vertically (full screen with vertical scrolling if more than 1/3 of the screen would be occupied). This may indeed be easier if you have a lot of tags.

From what I read in earlier feedback, there are two main points that @ByteHamster mentioned that I think would need to be addressed to get the original proposal:

The "more" button is too prominent. It makes the screen feel like some kind of "editor", not like a normal main screen

Why are there two lists of tags? I would just make it a single list where tags can be selected

In my mock-up, I didn't have a text-based but icon-based button. Implementing that would address the first point.

I am not 100% sure about the fact that selecting multi-selects - this makes selecting a lot more clicks.

Is it that if you tap two tags, both get selected, rather than switching from tag A to B? If that's what you meant, @ByteHamster: I agree with @peakvalleytech that it would be nice to be able to have the option of multi-select.
Proposal for a middle ground that is easy for most users but also allows for more advanced use:

By default (if there is one or no tag is selected), a tap switches the selected tag. Long-pressing makes the second tag selected, and activates the multi-tag mode (next point).
If there are two or more tags selected, tapping another tag makes it selected as well. In this multi-select mode, a single tap selects or deselects the tag.
A) If there are two tags selected, as is normal in the multi-tag behaviour, tapping one of the two selected tags, deselects the tag. As then only one tag is selected, the single-tag mode (point 1) gets active.

Curious what you both think of this proposal

Are there any other major points under discussion?

ByteHamster · 2022-01-08T11:21:00Z

Sure

Awesome!

I would argue for going for a list, as proposed before and already largely implemented

Yeah, I would do that too. That's also what YouTube does:

Maybe we could just show all in a horizontal list like YouTube but with the additional button to expand them to the bottom. So you can still scroll through all tags without expanding if you want. That could even make the implementation easier because we only need to have one single list.

In my mock-up, I didn't have a text-based but icon-based button. Implementing that would address the first point.

👍 In your penplot, you have an icon with the tag icon and a downward arrow. I think a simple downward arrow would be enough, especially when it fades out the tag list to the right. That should already make it clear what the button does.

By default (if there is one or no tag is selected), a tap switches the selected tag. Long-pressing makes the second tag selected, and activates the multi-tag mode

Sounds good to me 👍

Are there any other major points under discussion?

I would maybe talk a bit about the design (the blue background in your penplot feels a bit too strong to me) but that should be pretty easy to change once the functional things above are implemented. So no other major points under discussion :)

keunes · 2022-01-08T23:14:50Z

Maybe we could just show all in a horizontal list like YouTube but with the additional button to expand them to the bottom. So you can still scroll through all tags without expanding if you want. That could even make the implementation easier because we only need to have one single list.

I like that!

In your penplot, you have an icon with the tag icon and a downward arrow. I think a simple downward arrow would be enough, especially when it fades out the tag list to the right. That should already make it clear what the button does.

Yeah, it was partly also because I envisioned two lines - the single downward arrow for two lines looked odd. But if we go for a single line as you proposed above, then indeed just the arrow will work nice.

So no other major points under discussion :)

Great!

ByteHamster · 2022-01-16T21:58:22Z

I wonder if we should continue displaying the tags in the grid when no tag (from the selector on top) is selected. It could be helpful to see them all at once when starting the app. Also, it would mean that users can still keep using the app like it is without having to change their muscle memory.

keunes · 2022-01-18T12:17:13Z

I wonder if we should continue displaying the tags in the grid when no tag (from the selector on top) is selected. It could be helpful to see them all at once when starting the app.

To me that sounds like duplicating navigation.

Also, it would mean that users can still keep using the app like it is without having to change their muscle memory.

Tags have been there so short that I think very few users will have developed muscle memory.

ByteHamster · 2022-01-19T07:14:40Z

What do we then show when no tag is selected and a user un-checked "show in main list" from all subscriptions? An empty screen?

I just noticed that long-press-to-select conflicts with long-press-to-rename. So maybe we cannot actually do long-press-to-select.

antennapod-bot · 2022-02-02T06:17:27Z

This pull request has been mentioned on AntennaPod Forum. There might be relevant details there:

https://forum.antennapod.org/t/folder-logo-as-collage-of-subscriptions/1682/2

keunes · 2022-02-02T06:33:31Z

What do we then show when no tag is selected and a user un-checked "show in main list" from all subscriptions? An empty screen?

The default state should be to have an overview of all podcasts, without having to multi-select each of the tags (which would be bad UX IMHO). I would go for either of these options:

This setting affects only the side menu (space is more limited in the menu so there's more rationale for it; in the subscriptions screen the chips function more as a filter)
If no tags are selected for the filter, and all subscriptions have been 'removed from main list', instead of showing an empty screen, show all podcasts.

(I would go for the first. I think it'd be a better UX if 'show in main list' would be made redundant, by a) adding an automatic section 'not tagged' and b) allowing users to switch on & off the main & tag list separately. The first option is easier to implement for now and does not lead to unexpected behaviour changes, e.g. when the user removes the last 'show in main list'.)

I just noticed that long-press-to-select conflicts with long-press-to-rename. So maybe we cannot actually do long-press-to-select.

The action that is available through long-press should be the one that is used second-most. That would be multi-select. Changing tag names can be accessible from the settings (where it should also be possible to delete them).

@ByteHamster @peakvalleytech What d'you think?

peakvalleytech · 2022-02-25T07:50:17Z

Hello, sorry, i'm late.

I've changed my stance on how it should be designed.

I think we should have something like YouTube's.
No multi-select
Also agree with @keunes last points as well
Not expanded view, just a single horizontal bar

ByteHamster · 2022-03-20T10:09:53Z

The default state should be to have an overview of all podcasts, without having to multi-select each of the tags (which would be bad UX IMHO). I would go for either of these options:

This setting affects only the side menu (space is more limited in the menu so there's more rationale for it; in the subscriptions screen the chips function more as a filter)

If no tags are selected for the filter, and all subscriptions have been 'removed from main list', instead of showing an empty screen, show all podcasts.

I would go with the second suggestion. I am using an "Archive" folder and remove the "show in main list" from these subscriptions. Simply showing all, even when the "show in main list" box is unchecked, basically makes the use-case of an archive folder impossible.

Changing tag names can be accessible from the settings (where it should also be possible to delete them).

Hmm, not completely happy about that. I like the fact that AntennaPod currently separates between app content and (behavior-like) app preferences.

I've changed my stance on how it should be designed.

No multi-select

I agree. That's the easiest option and users are already used to that pattern from sites like YouTube.

Not expanded view, just a single horizontal bar

I think the expanded view can be added relatively easy later when needed. It just needs another layout manager for the RecyclerView.

@peakvalleytech would you be up for adapting your PR accordingly (and rebasing it)?

ByteHamster · 2022-06-06T16:58:15Z

Are you still interested in this PR, @peakvalleytech?

github-actions · 2022-06-24T02:16:24Z

This PR will be closed when we don't get a reply within 15 days.

github-actions · 2022-07-10T02:16:06Z

This PR was closed because we didn't get a reply for 30 days.

peakvalleytech added 4 commits August 29, 2021 21:16

Imlement basic tag bar features.

1be884d

Refine tag-bar prototype.

bc08a62

Fix bug related to storing tags.

72bfc08

Refactor tagbar. Update ui.

221cad7

ByteHamster changed the title ~~Feed tagbar~~ Display feed tag selector on top of subscriptions screen Sep 3, 2021

ByteHamster reviewed Sep 3, 2021

View reviewed changes

peakvalleytech added 2 commits September 3, 2021 18:24

Update FeedTagAdapter. Clean up code in RXHandler.

91755f4

Fix issues with tagbar PR.

30bad8d

peakvalleytech added 5 commits September 5, 2021 17:32

Move tag preferences storage from userpreferences to feeds screen. Fi…

13431f0

…x other PR issues.

Update feed multi select to integrate with tagbar.

f5ce9f1

Clear tag filter id preferences when all chip is clicked.

c4267da

CI issues.

9e3faf5

CI issues.

b8c117d

peakvalleytech requested a review from ByteHamster September 18, 2021 00:41

peakvalleytech mentioned this pull request Sep 19, 2021

Rename folder to tag #5381

Merged

ByteHamster added the Needs: Reply Issue or PR is awaiting follow-up, as requested by project maintainers. label Jun 8, 2022

github-actions bot added the Needs: Reply still label Jun 24, 2022

github-actions bot added the Close reason: No reply label Jul 10, 2022

github-actions bot closed this Jul 10, 2022

ByteHamster mentioned this pull request Oct 2, 2022

Feed drag drop #5386

Closed

Display feed tag selector on top of subscriptions screen #5374

Display feed tag selector on top of subscriptions screen #5374

Conversation

peakvalleytech commented Aug 30, 2021 • edited by ByteHamster Loading

ByteHamster left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peakvalleytech Sep 4, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

peakvalleytech commented Sep 4, 2021 • edited Loading

ByteHamster commented Sep 4, 2021

peakvalleytech commented Sep 5, 2021 • edited Loading

ByteHamster commented Sep 11, 2021

peakvalleytech commented Sep 13, 2021

ByteHamster commented Sep 21, 2021

peakvalleytech commented Sep 22, 2021

ByteHamster commented Sep 24, 2021

peakvalleytech commented Sep 24, 2021 • edited Loading

ByteHamster commented Jan 6, 2022

peakvalleytech commented Jan 7, 2022

keunes commented Jan 7, 2022 • edited Loading

ByteHamster commented Jan 8, 2022

keunes commented Jan 8, 2022 • edited Loading

ByteHamster commented Jan 16, 2022

keunes commented Jan 18, 2022

ByteHamster commented Jan 19, 2022

antennapod-bot commented Feb 2, 2022

keunes commented Feb 2, 2022 • edited Loading

peakvalleytech commented Feb 25, 2022

ByteHamster commented Mar 20, 2022

ByteHamster commented Jun 6, 2022

github-actions bot commented Jun 24, 2022

github-actions bot commented Jul 10, 2022

peakvalleytech commented Aug 30, 2021 •

edited by ByteHamster

Loading

peakvalleytech Sep 4, 2021 •

edited

Loading

peakvalleytech commented Sep 4, 2021 •

edited

Loading

peakvalleytech commented Sep 5, 2021 •

edited

Loading

peakvalleytech commented Sep 24, 2021 •

edited

Loading

keunes commented Jan 7, 2022 •

edited

Loading

keunes commented Jan 8, 2022 •

edited

Loading

keunes commented Feb 2, 2022 •

edited

Loading