Customization options for sight impaired users. I’ve done a bit of poking around but am not sure this is the right place for this discussion and not convinced that there isn’t a solution in the market for the problems I’m trying to solve. Please point me in the right direction so I can learn more. Also, I’m a programmer and if there isn’t already a solution I might be interested in creating one.
Some users have limited vision and would benefit from mainly cosmetic customizations to fit their specific challenges/preferences
Use Cases:
General: User has limited tech/app experience and significant visual limitations - can’t read/operate menus, podcast descriptions etc.
Specific (some examples - not exhaustive) :
Menu “hamburger” too small, menu text too small
Podcast episode descriptions too small
Listen Lists - configurable lists with specific episodes - would be nice to have dynamic population (e.g. Morning news shows with latest episodes from a small number of podcasts etc.)
Suggested solution:
Most of my experience is with Android on Android devices and Amazon Fire devices. My takeaway is that screen font size solutions are inadequate - they are often quite limited in how large. Voice commands are incredibly tedious, not very intuitive and the menu structures are often 2-3 layers deep making even simple operations very taxing - especially for older users with limited tech experience, patience and somewhat impaired cognitive abilities. I’m pretty convinced that a better solution needs to be at the App level. Highly customizable so that different combinations of individual user requirements can be met. Overall the solutions can be butt ugly - but have to be legible and actionable (menu/choice selections need to have large target areas on the screen and clearly separated from other choices).
Possible App Level Solutions:
All menu items and icons configurable - size, image, text
Custom Screens (with menu widgets to customize user flow)
Custom User Flow - combinations of Custom Screens
Pull here in case of emergency button - would be nice to have an App “reset” button that users could hit to “just start all over” when things get too confusing.
One nice feature to have would be a remotely configurable listening list - an “assistant” could create a listening list either directly in the app or remotely (shared lists).
Bumping this. It’d be great if someone who knows antennapod could give a short reply here. I’m fine opening up the code myself but having some input would be great. Thanks.
If you increase the system’s font size and the display scale, the texts get incredibly large. Also there is the accessibility feature “screen magnification” that can make the screen content even larger.
To be honest, I am not convinced that adding a font size setting to AntennaPod is a good idea. A setting like that introduces a tremendous amount of maintenance work (every changed screen needs to respect that setting), while at the same time there are already a lot of tools available to deal with this on a system level.
About custom screens: AntennaPod 3.0 will have a customizable home screen.
I have to admit I would like a way to expand the cover art of episodes and such. Tapping them does nothing and some podcast do special covers that I sometimes want to even download and such
Thanks for taking the time to respond. Since I’m working directly with someone with vision impairment I can say unequivocally that the system accessibility solutions are inadequate. In general, now that I’m directly exposed to someone with sight issues, it is surprisingly clear how much of a gap there is between what people without disabilities perceive as adequate for people with disabilities - not only in this but within the society in general. I guess I’ll take a look at the code - is there a clear separation for the display layer from the functionality (along the lines of MVC?). Thanks for any hints you can provide.
Actually I think that this screenshot describes just how inadequate these solutions are. The screen is a jumble of text and images that are almost impenetrable to someone with significant vision impairment. In addition to the text itself being hard to read there are multiple different fonts and sizes. Another issue is the space between the menu selection - too shallow to provide clear separation so that choices can be made easily. Overall if you add the fact that the user may not be at all familiar with the icons - which they can barely make out at this point - you can probably figure out how frustrating this is.
One of the issues is that not all disabilities are equal. The effect of a disability on a particular person and their interactions with an application are going to be highly divergent - one solution will not work for everyone.
My idea, which may be unattainable, is essentially to be able to script a custom interface that can be adjusted for an individual users needs. From a theoretical perspective this should be doable, what I’m interested in is how practical this might be (as an add-on or fork) of Attenapod.
Have you tried using Android Auto (using the Android Auto app on the phone)? The UI that is intended to be shown on cars is usually reduced to the bare minimum.
From my experience, forks don’t last long. People put a lot of work in and then realize that the app needs continuous maintenance to keep working. Then the forks get abandoned and not updated anymore. But you are welcome to try (as long as you follow the terms of the GPL).
I might be a bit late to the conversation, but I hope not too late.
This is an interesting and welcomed topic, and a hard one. To summarize what has already been covered; As noticed, AntennaPod isn’t built with accessibility in mind and with the current development team it is unfortunately not realistic to change that. A fork has been suggested, as well as the very attractive idea of making its user interface customizable thought some kind of plugin system.
Would you say there are some example(s) of such scriptable/customizable interfaces for any other software of which you are aware?
Either forking AntennaPod or creating a completely new app from scratch would be a huge amount of work, but it seems you are aware of that. Would you be able to to achieve what’s needed? In that case, would you aim for complete feature parity, or would a subset of the functionality be sufficient? What would you say the chances for a long term maintenance commitment are?
Did you get anywhere with a technical investigation? How closely coupled would you say the visual components are with the actions they are controlling?
I haven’t had as much time as I thought I would to get into this. For me the next step is opening up the code and seeing what is going on. It is impossible to say right now what the right approach (for me) might be - but in general I would think about forking as a last resort and of course only if I was prepared to make a significant investment of time. In terms of scriptable interfaces I don’t have anything specific in mind but there are plenty of examples of page description languages and parsers which is what I’m generally thinking. Again it really depends on how AtennaPod currently describes its UI and what that relationship is to the functional code. Hopefully I’ll make some progress on this in the coming weeks.
Thanks for starting a thread on this very important topic. While a whole new, dedicated UI would be great to have, I feel there’s also room for improvement in the current UI. You mentioned some things that I think we should turn into tickets, so that someone has clear indications and can pick them up.
For example:
@ByteHamster, would it be possible to change UI based on font size? E.g., specifically,
on the Home screen, move number & Screen link to next line if the whole headline e.g. “See what’s new” doesn’t fit
in the side menu, increase with the font size:
the error icon size
the spacing between items
the cover image (or do we not care, or should we even hide it, given that the Subscriptions screen is better suited for this?)
in the side menu
allow for two lines if font size ≥ x
make sure that icons and numbers don’t overlap
in the mini-player, increase the font size with the system, and allow for two lines if font size ≥ x
We should probably also check if the updated Subscriptions screen works as expected.
I, a pretty average user, have this in other apps sometimes as well. So even in this case it would be helpful to be supported. I’m thinking:
Long-pressing an icon should always reveal its purpose
Maybe, instead of having a web-based documentation page, we can have an in-app screen which gives an overview of all icons & what they mean? (Though not sure that’d help users with limited cognitive abilities.)
Indeed both would be a lot of work. Maybe an intermediary solution could be to introduce a switch like “Enable Simplified Interface”. If active, many not strictly necessary elements could be hidden, such as the file size (before download), numbers displayed in the side menu, (icons to access) podcast-specific settings, etc. Such list of elements to be hidden could of course be discussed.
)