Assessment Lab Plan

What to do

• This is the first and most critical step in the project series. Write a comprehensive proposal for the mobile application you will build throughout the semester. It is the master plan for the UI design, local database, and full-stack assignments that follow.
• The proposal must be clear enough for a non-technical client to understand the vision, yet detailed enough for a developer to see the technical path.
• Application concept and value proposition: who are the target users, what problem does the app solve, in simple non-technical language.
• Core data model: the primary entities (e.g. User, Task, InventoryItem) with their key attributes, purpose and data type.
• User roles and feature breakdown: at least two roles (e.g. Admin and Regular User), with the features unique to each role and the features shared by all.
• Offline strategy and synchronization plan: what is stored on the device, what the user can do offline, and how local changes are synchronized once the connection is restored.
• UI/UX mockups: low-fidelity wireframes for the main list screen and the add/edit screen, made with Figma, Sketch, or drawn neatly.

How to submit

Commit the proposal as README.md (or a single PDF) together with the mockup images to your assignment repository on GitHub before the deadline.

How it is graded

1. Core concept and value proposition 20%

   Excellent 3 points The app idea is described clearly, is feasible for a semester project, and its value to the user is well-defined and easy for a non-technical person to understand.

   Good 2 points The idea is understandable but may be too ambitious, too simple, or its purpose is not clearly articulated.

   Poor 0 points The concept is vague, incomplete, or fundamentally not feasible for a mobile application project.

2. Data modeling and architecture 20%

   Excellent 3 points At least two primary data entities are defined with logical, well-described attributes (at least 5 fields per entity). The model clearly supports the proposed features.

   Good 2 points At least one primary entity is defined with 3+ attributes, but the model is overly simple or doesn't fully align with all the proposed features.

   Poor 0 points Entity definitions are missing, have minimal detail (fewer than 3 fields), or are irrelevant to the application's concept.

3. User roles and feature breakdown 20%

   Excellent 3 points At least two distinct user roles are defined with a thoughtful and logical breakdown of unique features (at least 2 per role) and shared features (at least 2).

   Good 2 points Two roles are defined, but the distinction is weak, with minimal unique or shared features (e.g. only 1 of each).

   Poor 0 points Roles are not defined, are identical, or the feature breakdown is missing or makes no sense.

4. Offline strategy and data synchronization 20%

   Excellent 3 points A clear plan is presented, detailing what data is available offline, what the user can do, and how local changes will be synchronized with the server upon reconnection.

   Good 2 points An offline mode is mentioned, but the details are generic or key scenarios (like resolving conflicts or handling sync failures) are not considered.

   Poor 0 points The offline strategy is missing, or the explanation is illogical and technically unsound.

5. User experience and UI mockups 20%

   Excellent 3 points Clear mockups for at least two key screens (e.g. list and add/edit) are provided. They are consistent with the feature list and illustrate a logical user flow.

   Good 2 points At least one mockup is provided, but it is not detailed, is inconsistent with the proposal, or does not show a clear user journey.

   Poor 0 points No mockups are submitted, or they are unreadable or irrelevant to the project description.

What to do

• Design and implement a high-fidelity, UI-only mobile prototype focused on the complete authentication and onboarding experience. No backend or database logic is required, but the interface must be fully interactive and show all user flows and feedback states.
• A polished login/signup screen with clear input fields, strong visual hierarchy, and a responsive layout.
• UI for multiple authentication methods: Google/Apple, email/password, and anonymous sign-in. Provider buttons follow official branding guidelines.
• Mock UI states for feedback and error handling: real-time input validation, clear error messages for failed logins, loading indicators.
• A biometric login flow (Face ID / fingerprint): a prompt to enable it after the first login, use on later launches, and a password fallback when it fails.
• Consistent and accessible UI following Material Design or the Human Interface Guidelines, with sufficient colour contrast.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

The original rubric had no points per level. The 4/3/2/0 scale and equal weights below are the standard ones used for the other assignments.

1. Login page UI and UX (layout, usability, visual hierarchy) 20%

   Excellent 4 points Clean, visually appealing design with clear input fields, labels, and calls to action; responsive layout; strong visual hierarchy; smooth navigation flow; accessible (contrast, font size).

   Good 3 points Mostly clear layout; some minor inconsistencies in spacing or visual hierarchy; navigation is functional but could be more intuitive.

   Fair 2 points Cluttered or misaligned elements; poor spacing; visual hierarchy is weak; the user may feel confused about what to do.

   Poor 0 points Disorganized, hard to use, or incomplete login UI; elements missing or broken; does not follow basic design principles.

2. Authentication options (Google, Apple, email/password, anonymous) 20%

   Excellent 4 points All providers are clearly visible and easy to select; provider buttons use official branding guidelines; smooth transitions between methods.

   Good 3 points Most providers are implemented and visible; some branding or spacing issues; flow is usable but may feel slightly inconsistent.

   Fair 2 points Only some providers work or are displayed; unclear which login options are available; buttons may not follow provider guidelines.

   Poor 0 points Missing most providers; unclear or broken login options; no consistency with branding or UX expectations.

3. User feedback and error handling (validation, error messages, loading states) 20%

   Excellent 4 points Real-time validation; helpful, clear error messages (e.g. "Invalid email format"); loading indicators for sign-in; friendly microcopy improves UX.

   Good 3 points Validation works but might only show after submission; error messages are understandable but generic; loading indicators are present but minimal.

   Fair 2 points Basic validation with little clarity on what went wrong; some missing loading states; poor UX during error scenarios.

   Poor 0 points No validation or feedback; the user cannot tell what went wrong; the interface feels unresponsive.

4. Biometric login (Face ID / fingerprint) 20%

   Excellent 4 points Fully implemented, clearly offered after first login; smooth UI (icons, prompts); fallback to password if biometric fails; communicates status clearly.

   Good 3 points Biometric option is available but slightly harder to discover; fallback flow works but could be smoother; prompts are basic.

   Fair 2 points Biometric option exists but is unreliable or poorly integrated; fallback flow not obvious; UX feels clunky.

   Poor 0 points No biometric login or completely broken implementation.

5. Consistency and accessibility (visual style, platform guidelines, accessibility) 20%

   Excellent 4 points UI follows platform guidelines; consistent colours, fonts, spacing; accessible (colour contrast, screen reader labels); supports different screen sizes.

   Good 3 points Mostly consistent with some minor deviations from platform guidelines; limited accessibility testing.

   Fair 2 points Style feels inconsistent (e.g. mismatched buttons, font sizes); no consideration for accessibility.

   Poor 0 points Inconsistent and unprofessional look; ignores platform conventions; poor or no accessibility support.

What to do

• Convert the UI-only project into a fully functional application that uses a local database and supports multiple user roles.
• A local database stores credentials, authentication data, and the app data.
• Multiple authentication methods (Google/Apple, email/password, anonymous); a successful login loads the right data from the local database.
• Two distinct roles (e.g. Regular User and Admin), each with at least two unique features and at least two shared features.
• Sensitive data is stored securely, using encryption or platform secure storage. Shared and private data are separated per role or account.
• Biometric login re-authenticates locally, with a password/email fallback.
• Good feedback and error handling: real-time updates on database changes, clear error messages, loading indicators.
• Clean architecture (e.g. MVVM with a repository) separating UI from business logic.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

The original rubric had no points per level. The 4/3/2/0 scale and equal weights below are the standard ones used for the other assignments.

1. Local database integration (persistence, mapping to UI, CRUD operations) 20%

   Excellent 4 points Fully functional local database; all login/authentication data, user roles, and shared data stored and retrieved correctly; efficient CRUD operations; database changes are reflected immediately in the UI.

   Good 3 points Local database is implemented and mostly works; minor sync or refresh issues between UI and DB; CRUD operations are mostly reliable.

   Fair 2 points Database partially implemented or unreliable; frequent refresh issues; some data not saved or retrieved properly.

   Poor 0 points Little or no database integration; data not persistent between sessions; UI disconnected from storage.

2. Role management and feature access (role-based navigation, permissions, feature separation) 20%

   Excellent 4 points Two roles implemented with clear differences; each role has at least 2 unique features and at least 2 shared features; role switching works correctly; users can't access features of the other role without authorization.

   Good 3 points Roles are implemented but feature separation has minor inconsistencies (e.g. shared features duplicated, unclear navigation); unauthorized access is rare but possible.

   Fair 2 points Roles are implemented superficially; features not well differentiated; weak or missing checks allow cross-role access accidentally.

   Poor 0 points Roles not implemented or broken; all users see the same UI regardless of role; no permissions enforced.

3. Authentication and security (secure storage, private/shared data separation, fallback) 20%

   Excellent 4 points Credentials and sensitive data stored securely (e.g. encrypted); clear separation of shared vs private data per user/role; biometric login works with the local DB; fallback authentication works.

   Good 3 points Data stored securely in most cases; biometric works but may have small UX issues; private/shared data separation mostly respected.

   Fair 2 points Weak data storage (plain text); biometric login unreliable; private data sometimes visible to other roles.

   Poor 0 points No secure storage; biometric login missing or broken; data is shared between roles with no separation.

4. Data consistency and user feedback (real-time updates, error handling, loading states) 20%

   Excellent 4 points UI updates instantly after DB changes; proper loading indicators during DB operations; clear, specific error messages when operations fail.

   Good 3 points UI updates correctly in most cases; loading indicators exist but minimal; error messages are generic but functional.

   Fair 2 points UI often out of sync with the DB; missing indicators during slow operations; poor error messages.

   Poor 0 points UI does not reflect DB changes; no feedback during operations; the user is left confused if something fails.

5. Code quality and architecture (separation of concerns, scalability, maintainability) 20%

   Excellent 4 points Clean architecture (e.g. MVVM, repository pattern); clear separation of UI and data logic; easy to extend; code well documented.

   Good 3 points Reasonable architecture; some mixing of UI and data logic but manageable; moderately maintainable.

   Fair 2 points Code organization weak; business logic tightly coupled with UI; adding new features would require major rewrites.

   Poor 0 points Poor or no architecture; unmaintainable code; data and UI logic tangled.

What to do

• Turn the app into a full-stack solution: connect it to a remote backend and use the local database as a cache for a true online/offline experience.
• Connect to a remote backend: a data layer talking to a REST or GraphQL API for all CRUD operations.
• Remote authentication: login and registration go through server endpoints; the app securely stores a token (e.g. JWT) and sends it with authenticated requests.
• Synchronize data: fetch from the server, send user changes to the server, and update the UI automatically.
• Offline support: show cached data read-only when the network is unavailable, refresh when it is restored.
• Handle network states gracefully: loading indicators and user-friendly error messages instead of crashes or freezes.
• Clean architecture: the repository decides between network and cache, hiding that complexity from the UI and view models.

How to submit

Push the complete source code to your assignment repository on GitHub before the deadline. Only sources, no build directories. The last push before the deadline is graded.

How it is graded

1. API integration and server communication 17%

   Excellent 4 points All CRUD operations are correctly mapped to API endpoints. Data is successfully fetched, created, updated, and deleted on the server. Code is clean and reusable (e.g. a centralized API service).

   Good 3 points Most CRUD operations work correctly. Minor issues with one or two endpoints, or the API communication code could be better organized.

   Fair 2 points Only some data operations connect to the server (e.g. only fetching works). The implementation is buggy or incomplete.

   Poor 0 points The app does not successfully communicate with the server, or the implementation is fundamentally broken.

2. Remote authentication and token management 17%

   Excellent 4 points Login/signup works flawlessly against the server. A token is securely stored and attached to all necessary API requests. Logout correctly clears the token.

   Good 3 points Authentication works, but token storage might be insecure (e.g. SharedPreferences without encryption). The token might be missing from some requests.

   Fair 2 points Authentication is unreliable. The token is handled poorly, leading to frequent failures or security vulnerabilities.

   Poor 0 points Authentication is not implemented or is completely non-functional.

3. Data synchronization and UI reactivity 17%

   Excellent 4 points The UI automatically and reliably reflects the state of the data on the server. Local changes are immediately sent to the server, and remote changes are fetched and displayed in real time or upon refresh.

   Good 3 points Data synchronization works, but the UI might not always be perfectly in sync. The user may need to manually refresh to see updates.

   Fair 2 points Synchronization is buggy and unreliable. The UI often shows outdated data, and local changes are sometimes lost or not sent to the server.

   Poor 0 points No data synchronization is implemented. The app only uses hardcoded or local data.

4. Offline support and caching 17%

   Excellent 4 points A robust cache-first or offline-first strategy. Cached data is displayed instantly and the app remains usable read-only when offline. Data is seamlessly refreshed when connectivity is restored.

   Good 3 points The app caches data and can display it while offline. The transition between online and offline states might be clunky, or the app might show errors before loading cached content.

   Fair 2 points Caching is implemented poorly. The app might crash or freeze when offline, or fails to load cached data reliably.

   Poor 0 points No offline support. The app is unusable without an active internet connection.

5. Network feedback and error handling 16%

   Excellent 4 points Clear loading indicators for all network operations. Network errors are caught and presented with helpful, non-technical messages.

   Good 3 points Loading indicators are present but might be inconsistent. Error handling works but messages may be generic or technical (e.g. "Error 500").

   Fair 2 points The app lacks clear loading feedback and feels unresponsive. Error handling is minimal, and the app may crash on network failure.

   Poor 0 points No user feedback for network states. The app freezes during network calls and crashes on errors.

6. Code quality and architecture 16%

   Excellent 4 points The repository pattern fully abstracts the local and remote data sources. The code is clean, modular, and easy to maintain. Networking logic is completely separate from the UI.

   Good 3 points The architecture separates concerns, but the repository's logic for managing data sources could be cleaner. Some networking code might leak into view models.

   Fair 2 points The architectural pattern is not followed correctly. Networking code is mixed with UI logic, making the codebase hard to maintain.

   Poor 0 points No clear architecture. Code is disorganized, with no separation of concerns.