Autocognita - Literacy Android App UI Build 1

Challenge Objectives
The purpose of this challenge is to build the UI for a native Android app:

• Android app development (UI only) using Java
• 14 unique screens but 4 of them has a few variations
• The app is similar to Duolingo but focuses on literacy (English only for this challenge)

 
Project Background

• This is a mobile Android app that aims to help millions of low-literacy adults acquire basic reading skills needed to lead a fulfilling life.
• Users will learn anytime, anywhere with this mobile app.
• The app is similar to Duolingo in nature, but with a focus on literacy.

 
Workflow
Below is a high level workflow of the app, make sure you read the more detailed screen logic document which contains screenshots to better understand the details.

• Step 1: The user launches the mobile app and Signs Up / Login
• Step 2: For first time login, show video instruction, and let user complete placement test and show placement result
• Step 3: User sees the home screen (menu). User can click the current Unit to see Unit Intro, and choose to either test out or continue lesson.
  • For test out: user may fail or pass. In case of failure the user will see a list of lessons, and the user can choose an available lesson to continue (this is the same as continue lesson) . In case of success user will be taken back to home screen with the next unit unlocked.
  • For continue lesson: the user will see a list of lessons, and the user can choose an available lesson to continue.
• Step 4: User enters a lesson and sees a series of different questions, presented one at a time. For example: questions may be image+text, text only, image only, or audio based. Answers may be image, text or audio.

Users Roles
This Android app only contains one user role.
 
Screens / Features
The following screens are in scope of this challenge:

• 1. Welcome: The welcome / landing page will shown on app loading, and user will press the -> button to continue
• 2. Sign Up: This screen currently says SIGN UP, but it’s actually the same screen for both LOGIN and SIGN UP, user just needs to enter their phone number and hit next. Do not allow the user to go next until all 9 digits are entered.
• 3. Verification: This screen is missing from the design right now, but just use the same design as SIGN UP, except that this time user will need to enter a 4-digit verification code and hit next. Notes:
  • Please simulate both verification success and failure scenarios.
  • User should be able to go back to previous screen using Android’s Back button.
• 4. Sign Up - Done: This screen is only shown after successful verification. From this screen the user can only go next. Please simulate two scenarios here:
  • New user (first time login): user will go to screen 5
  • Existing user: user will go to screen 6
• 5. Video InstructionApp shows recorded video instructions, user may press the button at the bottom to skip video. You can just put in a sample short video for now and we’ll replace it later.
• 6. Menu / Home Screen: Menu is organized by levels, each level contains multiple units, with indicators for whether the unit is completed, available or locked. Available units show lesson completion status, users clicks on a unit to start learning.
  • Note: please make sure data comes from json and is not hardcoded on UI.
• 7. Unit Intro: In each Unit there are 1 - 5 lessons to be taken sequentially, to be taken sequentially, each lesson shows whether it is available or locked. User can choose to test out of unit. But in this challenge, TEST OUT button will be disabled for now.
  • In your data, make sure there are both available and locked lessons.
  • In each lesson, there should be one question for each of the types described in 8 - 11 below.
• 8. Choose screen: This type of screen will have a few variations:
  • 1. Image + Text Question / Text Answer
  • 2. Text Question / Text Answer
  • 3. Image Question / Text Answer
  • 4. Audio Question / Text Answer
  • 5. Text Question / Audio Answer
  • 6. Text Question / Image Answer
  • For audio based questions / answers, you’ll need to use both Text To Speech API and pre-recorded audio, this applies to all screen types.  The audio for some types of text (e.g. alphabet, word) will be generated using Text To Speech API, whereas for other types of text (e.g. phonics, word part), a specific pre-recorded audio file needs to be played.
  • The UI layout for all these variables is generally the same, and UI should decide what to show based on data from JSON.
  • Also note there can be one single answer or multiple answers for each question, which should be decided based on the data in JSON.
  • Ignore the question icon and remove it from the UI, that’s no longer in scope. Make sure this is done for all similar screens.
  • Please carefully check the screen logic document to see how this type of screen works on the go and indicates success / failure cases.
• 9. Fill Screen: This type of screen has a few variations:
  • 1. Fill in Phonic Sound
  • 2. Fill in Alphabet Letters
  • 3. Fill in Word Part (To be more general, this should be referred to a "word part", which could be either a syllable when teaching syllables within a word, or could be one of prefix/root/suffix when teaching compound words. These prefix/root/suffix may consist of more than one syllable, therefore, we cannot just call these syllables. Sometimes, a word part could itself be a valid word. The reason we need to differentiate word part vs word is that word parts may not be generated using text to speech, since these are not supported, and must be pre-recorded as audio files.)
  • 4. Fill in Word
  • The layout is still generally similar to choose screen, so if you can reuse the same code component, that’s fine and recommended.
  • UI needs to be dynamic based on data from JSON, but it’s always single answer.
  • Please carefully check the screen logic document to see how this type of screen works on the go and indicates success / failure cases.
• 10. Match Screen: There are several variations of Match screens. User is asked to match:
  • 1. Text with text
  • 2. Text with audio
  • 3. Text with image
  • Text may refer to phonic sounds, alphabet letters, word parts and words.
  • A match screen can be used to present multiple topics at once. And make sure UI is dynamic based on data from JSON.
  • Please carefully check the screen logic document to see how this type of screen works on the go and indicates success / failure cases.
• 11. Type Screen: Type screen is similar to choose screen, except that the user is asked to type the answer using a built-in keyboard. Questions may be text, image or audio, answers are always text and only a single word.
  • Please carefully check the screen logic document to see how this type of screen works on the go and indicates success / failure cases.
• 12. Lesson CompletedShow lesson completed screen at the end of a lesson randomly: https://marvelapp.com/1a38bc4g/screen/49249177
• 13. Unit CompletedShow Unit completed screen at the end of a unit randomly: https://marvelapp.com/1a38bc4g/screen/49249180
• 14. Level CompletedShow Level completed screen at the end of a level randomly: https://marvelapp.com/1a38bc4g/screen/49249179

Important Notes
Please make sure your submission supports these form factors:

1. The app needs to built using Android Studio and Java
2. Please follow the Android best practices - reviewers must verify submissions carefully
3. Submission should be tested on different versions of Android OS and devices (emulators), reviewers are expected to verify the app works on the mentioned Android OS versions
4. Code must be properly documented, including all variables and methods
5. The app must be implemented as a native app, native controls must be used wherever possible
6. All code must be written in Java and the project must use latest Android Studio.
7. Use gradle for dependency management
8. Please ask in the forums if you wish to use any open-source third-party libs to ensure there are no license violation.

 
Form Factors
Please make sure your submission supports these form factors:

• In-scope
  • Mobile portrait
• Out of scope
  • Tablet portrait and landscape
  • Mobile landscape

 
Development Assets

• Screen Logic Document
• Detailed Design
• Data Structure (FYI)

 
Technology Stack
The following technology stack will be used as part of this challenge:

• Java
• Android 4.4 and above
• Android Studio
• TextToSpeech
• JSON

 
Future Integration Points
The following integrations are not in scope -- but are being provided as an FYI of future work to come:

• API: Rest API to interact with the backend (to be developed), required

 
Review
Your submission will be reviewed on these requirements:

• Challenge Spec Requirements
  • Requirements Coverage
• Coding Standards
  • Best Practices
  • Code Quality
  • Good Code Documentation
• No hardcoded data on UI, data should come from json files for now
• How close the user Interface matches the design
• Screen Flow and Transition Performance (must be smooth and fast)

Final Submission Guidelines

• All original source code.
• Apk built from your code.
• A readme in markdown format explaining how to build, configure and verify your code.