App User Profile Recommendations
Overview: In many cases, there is overlap, as all 3 people face similar conditions, not only visually/mentally, but as they are all pilots/co-pilots, and so have limited time/focus for such an app, as they must focus on flying the plane/its controls; also, any app developed/sold will only have one main version, perhaps with manageable preferences, when launched, so overlap is needed):
- Mary:
- Voice activated (say: “zoom map” ) commands for font scaling for maps and all other app information (landing times, contact info, weather, directions etc…) if possible, so no need for user to swipe the screen to enlarge (as much hands-free as possible). Multiple input/output methods.
- Voice to switch features/screens would be good too and audio info over a speaker. This could include a screen reader option.
- Potential size is 24pts, which is quite large and viewable from the cockpit seat without reading glasses. Accommodate zoom to 200% min. This is key for Mary.
- Avoid use of sub/superscript – too small.
- Avoid homonyms and heteronyms – confusing for audio/understanding.
- Use standard display fonts, most readable ones possible. Arial is preferred (as sans serif often used for screen and this is common font and easy to read) but allow for use choice, perhaps for a serif one like Times New Roman as well.
- Have large margins and lots of “white space”, (for paragraphs, lines etc…) but use off white to reduce glare for the actual background colour.
- Where possible, use images/designs/audio in place of text.
- Avoid animation/blinking features – distracting.
- No justified text.
- Avoid need to scroll – keep info on separate, distinct screens, with clear/simple nav.
- Have high contrast (min. 4.5:1), no glare.
- Use consistent colour palette and symbols. Use tonal contrast and have a grayscale option so as not to distract from the many plane controls.
- Don’t restrict to one screen orientation.
- Test with Mary and similar and apply feedback as changes in version 2.
- Louise:
- Voice activated (say: “zoom map” ) commands for font scaling for maps and all other app information (landing times, contact info, weather, directions etc…) if possible, so no need for user to swipe the screen to enlarge (as much hands-free as possible). Multiple input/output methods.
- Voice to switch features/screens would be good too and audio info over a speaker. This must include a screen reader option for Louise.
- Potential size is 24pts, which is quite large and viewable from the cockpit seat without reading glasses. Accommodate zoom to 200% min.
- Avoid use of sub/superscript.
- Avoid homonyms and heteronyms – confusing for audio/understanding.
- No justified text.
- Use standard display fonts, most readable ones possible. Arial is preferred (as sans serif often used for screen and this is common font and easy to read) but allow for use choice, perhaps for a serif one like Times New Roman as well.
- Have large margins and lots of “white space”, (for paragraphs, lines etc…) but use off white to reduce glare for the actual background colour.
- Where possible, use images/designs/audio in place of text.
- Have high contrast (min. 4.5:1), no glare.
- Have feature to increase screen brightness.
- Avoid need to scroll – keep info on separate, distinct screens, with clear/simple nav.
- Use consistent colour palette and symbols. Use tonal contrast and have a grayscale option so as not to distract from the many plane controls.
- Don’t restrict to one screen orientation.
- Test with Louise and similar and apply feedback as changes in version 2.
- Timothy:
- Voice activated (say: “zoom map” ) commands for font scaling for maps and all other app information (landing times, contact info, weather, directions etc…) if possible, so no need for user to swipe the screen to enlarge (as much hands-free as possible). Multiple input/output methods.
- Avoid need to scroll – keep info on separate, distinct screens, with clear/simple nav. This is key for Timothy.
- Voice to switch features/screens would be good too and audio info over a speaker. This could include a screen reader option.
- Potential size is 24pts, which is quite large and viewable from the cockpit seat without reading glasses. Accommodate zoom to 200% min.
- No justified text.
- Avoid use of sub/superscript.
- Avoid homonyms and heteronyms – confusing for audio/understanding.
- Use consistent colour palette and symbols. Use tonal contrast and have a grayscale option so as not to distract from the many plane controls.
- Have high contrast (min. 4.5:1), no glare.
- Keep info simple per screen. This is key for Timothy.
- Use headings and screen numbers. This is key for Timothy. Use grouping and hierarchy for clarity. Robust semantic structure. Machine readable text. Keep language simple.
- Avoid animation/blinking features – distracting.
- Don’t restrict to one screen orientation.
- Use standard display fonts, most readable ones possible. Arial is preferred (as sans serif often used for screen and this is common font and easy to read) but allow for use choice, perhaps for a serif one like Times New Roman as well.
- Have large margins and lots of “white space”, (for paragraphs, lines etc…) but use off white to reduce glare for the actual background colour.
- Where possible, use images/designs/audio in place of text.
- Test with Timothy and similar and apply feedback as changes in version
mwilson
You’ve done a good job of finding relevant recommendations from the handbook. You could have combined them rather than split into separate recommendations for each user (think that your team is using this list as a guideline for design and development considerations so they want everything in one place).
Missed the printed map recommendations.