Core roles

Communication

Slack Channels:

• #mobile-design-sync for design related conversations

• #mobile-engage-sync for Engage squad and Mobile squad crossover collaboration

• #mobile-team for product delivery team happenings, internal chatter only

• #mobile for broader communications

Aliases

• @ edx-mobile for the whole mobile squad

• @ mobile-ios for the iOS team

• @ mobile-android for Android team

Key Mobile App Design Decisions

821e27a3-b9ec-4e13-9059-ff3c4953e1293bbda947-8f27-435b-942b-ffbc231914cdDECIDEDWe will add mobile components and styles to the Low Fi figma library as we go.1d32bc50-8f3b-4cd7-b5e4-aede3d7b6820DECIDEDWhoever is working in hifi will identify component to add to the common library and publish them.0099e248-2208-45a9-bce3-92dcbbd48a80DECIDEDWe are not careful about what is published in this common library since only one team depends on it. There is no requirement to review patterns at the Paragon Working Group meeting.2902dc76-317b-4b69-9324-bbe20b8f7c9cDECIDEDThe mobile library will have its own type styles, but will inherit colors from the web Paragon libraryb2e99031-8957-42dd-ba38-96efbd58347aDECIDEDWe’ll maintain a Figma library “Supplemental Mobile Components”, named specifically to indicate our preference for native controls.

• We will add mobile components and styles to the Low Fi figma library as we go.
• Whoever is working in hifi will identify component to add to the common library and publish them.
• We are not careful about what is published in this common library since only one team depends on it. There is no requirement to review patterns at the Paragon Working Group meeting.
• The mobile library will have its own type styles, but will inherit colors from the web Paragon library
• We’ll maintain a Figma library “Supplemental Mobile Components”, named specifically to indicate our preference for native controls.

Mobile App Accessibility

Relevant High-Level Guidelines

• Support platform accessibility tools

  • Screen readers (VoiceOver on iOS and iPadOS, TalkBack on Android)

  • OS Magnifier

  • External keyboards

  • Voice Input

• Touchzones - anything clickable should be a minimum of 24px wide and 24px tall (white space counts, and can overlap for different targets)

• Minimum font sizes - Don’t go smaller than 10pt, we have x-small at 11pt right now

• Interactive items: text should be able to grow by 50% (via text size settings in the OS) without colliding with container borders. Non-interactive items: heading and paragraph text should be able to grow by 200% with orderly reflow.

• Don’t make the user rotate the screen.

• Headings should be marked as such, and the apps should maintain a consistent visual hierarchy

• Don’t use hover behaviors on mobile since they don’t exist! Use tap instead.

More Details

WebViews

• Check the Mozilla Mobile Accessibility Checklist

• Funka’s Guidelines for the development of accessible mobile interfaces

Android

• Designing for accessibility

  - published by Android developers and covers apps

iOS

• Understanding accessibility for iOS

   – Apple’s guidance on making iOS apps accessible

Process

• When the design is almost final/final, check with Jeff Witt (Deactivated) either via a quick meeting or asynchronously via Slack/email

  • This should generally line up with when the design is getting reviewed with the PM partner

• Continue to reinforce accessibility check during development process as well before launch

Mobile Design Guiding Principles

How do we determine what parts of the app should be native components or custom, designed components?

• Consider native:

  • “When it makes no, difference use the native control in design”, in other words, bias towards native unless there’s a good reason not to

  • If the interaction is the same and color is the only difference, and the difference is small we should use native. For example: we will not implement a custom design for the switch control on android.

• Consider custom if:

  • Interactions are heavily branded and specific to edX

  • We want a consistent experienced for our learners across both platforms

How do we determine what parts of the app should be native or web views?

• On a case by case basis, we’ll evaluate the needs of the experience and determine how to move forward

• The key benefit of a web view is that we inherit the enhancements that is implemented on the web

• The key benefit of a native experience is that we can leverage native functionality for the device, which enables deeper and more bespoke interactions

Resources

Native iOS and Android resources and pattern libraries

• https://material.io/components?platform=android for Android

  • Official Figma: https://www.figma.com/@materialdesign

• Human Interface Guidelines for iOS

  • Related Figma: https://www.figma.com/file/8qDstNrg1toPyCJF0Gfxii/Variants-iOS-and-iPadOS-14-UI-Kit-for-Figma-Community?node-id=0%3A1

edX specific

• Mobile supplemental components Figma library - hi fi components for mobile use

Best practices and good reading

• We can do better on mobile

• Designing for the Mobile Environment – Some Simple Guidelines

• 8 rules of mobile design