Improve podcast dialog design hierarchy - hard readibility

[bhaskarblur]

Checklist

• I have used the search function for open and closed issues to see if someone else has already submitted the same feature request.
• I will describe the problem with as much detail as possible.
• This request contains only one single feature, not a list of multiple (related) features.

App version

3.1.1

Where did you get the app from

Google Play

Problem you may be having, or feature you want

The postcast dialog delivery hierarchy is not good and text colors and sizes blend each other, it's hard to differentiate different level of labels + this looks so full of text and not content, space optimised.

Suggested solution

The font weight of different texts can be fixed and the design could be more content optimised by showing limited amount of text and increasing the padding and margins. The button can be brought under the description, a cross button can be added to dialog.

Screenshots / Drawings / Technical details

Here's a clean and better hierarchy design.

[SriMani-7]

does anybody working on this issue.

[ByteHamster]

@bhaskarblur Your design looks great! Is this a mock-up in a design software or did you code this?

@SriMani-7 If you want to contribute, please have a look at the issues labelled "good first issue".

[bhaskarblur]

I want to work on this! Please, i designed it in figma and i want to code it as well.
Please assign me so that i can implement it in code! Thanks

[ByteHamster]

I'm really looking forward to your PR! 🎉 I saw that you also redesigned other screens. Please create the PR for only one screen, I think this screen here would be a great start. Redesigning multiple things at once makes the PR larger and therefore harder to get merged. Once the PR is merged, we can then work on the next one.

About the bright green color: We should continue using the Material Design 3 dynamic colors, so I think the color needs to stay less bright.

By the way, do you know Hacktoberfest? If you open the PR in October, you can get a free T-Shirt: https://hacktoberfest.com/

(@keunes Do we want the preview button to be so prominent?)

[bhaskarblur]

Thank you for the same and i'm happy that you liked my work and i will love to contribute more to the project.
I'll follow you and start by creating PR For only Once screen change at a time,
As for green color, for now i'll go with the Material 3 green color that is being used currently.

Please assign me for this task otherwise i'll PR directly if that's fine.

[bhaskarblur]

Please let me know where can i ask small questions, thanks

[bhaskarblur]

@ByteHamster Sorry for tagging, the current color that is being used is blue, in my design i thought to use material 3 green so should i use blue or green?

Also current font is sans-serif, what i've used is Roboto which is also material UI so should i use sans serif or roboto.

Or how about we refract to Roboto for a test check if required?

[ByteHamster]

the current color that is being used is blue, in my design i thought to use material 3 green so should i use blue or green?

The default color is blue. When selecting the "use dynamic colors" option, the color can be different, for example green, depending on user's wallpaper. To use this dynamic color, refer to the Material3 theme attributes like ?attr/colorPrimary. There is a list here: https://developer.android.com/develop/ui/views/theming/dynamic-colors

Also current font is sans-serif, what i've used is Roboto which is also material UI so should i use sans serif or roboto.

I assumed sans-serif to select Roboto. But if it isn't, feel free to change it. I think it should be possible to change the font using a theme attribute, and then reference standard material3 attributes, like here: https://developer.android.com/jetpack/compose/designsystems/material3#typography

[bhaskarblur]

Let's do what is continue with sans-serif and maybe in future we can shift to roboto, otherwise i'll test on my end and see if roboto is looking better then i'll approach you all for your views on the changing the font.

[keunes]

Hello,

Thanks @bhaskarblur for this suggestion and interest in implementing it in code too!

I quite like the proposal.

Do we want the preview button to be so prominent?

Yes, I think that's fine to do. It makes it easier to preview an episode (it currently is hidden because it's not really clear episodes expand if you tap on them).

I do have a couple of questions:

• preview
  • Can we change the text to 'Start preview'? I think it's a bit clearer what it does
  • Can we either remove > sign or replace it with a full triangle indicating a play action? This arrow thing seems to indicate a new screen will open, which is not the case.
  • Does the meta data leverage start/end (instead of left/right)? Because if not the text will be oddly placed in RtL languages.
• read more
  • How is the intro text cut off? In the mock-up it's nicely at the end of a sentence, but I guess that's hard to achieve in all cases (having to search for a period, while keeping to a certain length). Isn't it better to stick to e.g. for lines (height) and place the 'read more' button below?

[ByteHamster]

But do we want to make it easier to preview? The preview button is a bit hidden on purpose to make people subscribe. There is no proper player controls and stuff, so I think hiding it a bit could be a good thing

[bhaskarblur]

Your question is valid and these things totally depend upon your goals from this feature, i have another suggestion you can take in consideration that might sound balanced, if you want to push the subscribe and yet also show them the preview, why not we limit the preview to only 10 seconds or 15sec, and after it finishes, the user has to subscribe to continue.

How does this sound?

Also, i have another design implementation for this preview in mind that i'll share with you in upcoming days.

[keunes]

limit the preview to only 10 seconds or 15sec, and after it finishes, the user has to subscribe to continue.

That could be a solution. Another one that I was just thinking of, but this is more complex:
Show a miniplayer on top, with a modified full-screen player (hiding 'favourite' and 'open podcast' options - seems latter is already hidden in current situation, former displayed but non-functional). This (full/mini) player (and the playback notification, if any) disappears as soon as playback is paused.

Benefits:

• User can more easily get an idea of the podcast content, because they can easily use the full player screen to jump ahead, see chapters (if there are any)
• Users don't see a change in the miniplayer in the background (behind the dialog), making them press back (leaving the podcast preview) to access the miniplayer.
• User can easily stop playback through the UI they know, and we can drop the big 'stop playback' button.
• No chance that the user keeps listening beyond preview, because playback is 'killed' as soon as they leave the podcast preview.
• (depending on implementation) The 'main' miniplayer remains unaffected (currently it loses what you were listening to before). If feasible, though; I can imagine we do keep using the main player and don't get this benefit.

What do you think?

[bhaskarblur]

I didnt understand your solution, can you make it a little simpler to understand.

[ByteHamster]

limit the preview to only 10 seconds or 15sec

That seems quite artificial - users will then feel like this restricts them. It doesn't feel like something a non-commercial open-source app should do, because it is a pattern usually connected to paying for stuff. Making it hard to use but without restricting the user explicitly is somehow a more "soft" way to discourage users from using the app in a way that it is not intended to be used

Show a miniplayer on top

This idea sounds similar to #4710. Way too complex for just a design change, and a thing we need to think about throughoutly before adding.

I would prefer to keep the feature a bit hidden like it currently is before the redesign

[bhaskarblur]

Ok, so in my currently design implementation, do you want me to move the preview down to where it was before?

[bhaskarblur]

I had a thought to change the preview to this dialog instead of playing it in the back and giving a stop preview to the user.
When this dialog is closed, the preview will also be stopped, i've not added fast forward etc. if that's needed.

Just a raw idea :)

[keunes]

This idea sounds similar to #4710.

I see it being quite differently:

• what I propose is really a preview; no episode interaction possible; no history recorded. We're keeping existing behaviour and manipulate only the view (not saying it's easy).
• (IMHO) Add/play single episode without subscribing to podcast #4710 needs implementing recording in history, marking favourite, etc, which requires storing the podcast in the database. This goes much further than manipulating the view.

Way too complex for just a design change

Fair enough. I'll register a separate issue for this preview enhancement.

[bhaskarblur]

Ok, i'll not work on this then and i'll find some better and more solid places that require design change and make a separate issue for them.
Thank you

[ByteHamster]

#4710 needs implementing recording in history, marking favourite, etc, which requires storing the podcast in the database. This goes much further than manipulating the view.

Unless we add a huge number of case distinctions in many places, this suggestion basically requires most of what is needed to implement the full #4710. So I would prefer to not implement only the enhanced preview @keunes suggests without doing the full thing

change the preview to this dialog instead of playing it in the back

"Instead" of playing in the back sounds difficult to implement, but it could be "in addition to" the player in the back. Anyway, this is still a very large change. For the design change, I would rather keep it a design change for now. There is enough to discuss just about the design, without changing any functionality

[keunes]

Unless we add a huge number of case distinctions in many places

This I don't understand. It 80% already works like I proposed. Anyway - I'll create this issue and we can probably best discuss further in a call at some point.

For the design change, I would rather keep it a design change for now

Like I said: I'm happy with this approach 😉

I still think it's fine to 'promote' the preview button to where @bhaskarblur proposed it, even without further changes elsewhere.

Or we keep it hidden in its current place, but then we need to add an indication that the episodes are expandable (this is not clear currently).

[bhaskarblur]

I agree to your point that preview is not being highlight right now + the episodes are not self explanatory that they are expandable, if you still want to keep preview in bottom while indicating that it is expandable, we can add a arrow up/down on the the right side of episodes that will show that this is expandable.

[Matth7878]

I agree with @keunes about preview visibility.
Making it visible don't change much IMHO. It's still cumbersome enough so users eventually would subscribe.
If they don't subscribe that means they have to search each time for their previewed podcast. Beside if they switch to another episode they also have to get back to add a podcast and they would have lost their play position.

[ByteHamster]

Show a miniplayer on top

Another problem with this is that it blurs the lines between preview and normal playback. We should really avoid blurring that line before we have #4710, otherwise users might be confused why it looks the same but does not store the position, does not appear in the queue, etc.

Making it visible don't change much IMHO. It's still cumbersome enough so users eventually would subscribe.

Hmm. Okay, let's do this. I should really do another round of usability tests with new users again. Last time I did a Think-aloud interview (2-3 years ago), the results were pretty devastating. The current design of the page is what then came out of the interview. I hope that changing it to make the preview more prominent doesn't break the usability again.

[bhaskarblur]

Ok, are there any changes to the PR that i need to make? Or you'll merge it soon.
Please let me know, thanks