MS7 - EstebanRojas01/Moviles GitHub Wiki

MS7. Smart/CAS Value Proposition and Native UI/UX Prototype

Enhanced Value Proposition
How Do Smart Features Generate Value?
How Do CAS Features Generate Value?
Applied UI/UX System
Native Prototype and Navigation
Ten Required Views
Traceability Between Views, PAS, and Value

1. Enhanced Value Proposition

UniEat is a daily menu feed for the Universidad de los Andes community. It helps students find, compare, and decide where to have lunch using current information about menus, prices, dietary restrictions, location, and waiting time.

Value for Students

UniEat reduces the cost of searching through scattered information and the risk of walking to a restaurant that no longer has the expected menu. In a single experience, students can:

compare only the options compatible with their budget, available time, and diet;
understand which information is exact, which is estimated, and which still lacks sufficient evidence;
see the approximate distance and location context before traveling;
receive a recommendation when they do not want to review every alternative;
retain useful and clearly dated information when they lose connectivity.

Value for Restaurants

UniEat gives restaurants a direct and lightweight channel for publishing the daily menu, communicating availability, and receiving signals of student interest. Restaurants can:

publish prices, dishes, schedules, and payment methods through a single form;
update the daily menu from the same form without creating it again from scratch;
see how many community reports their publication received;
monitor interaction metrics that are explicitly identified as platform activity rather than confirmed sales.

Differentiation

The value proposition goes beyond listing restaurants. UniEat combines:

Validity: every menu has a date, schedule, and availability status.
Structured information: price, diet, payment, distance, and queue data use a consistent visual language.
Decision support: the system filters, ranks, and recommends options based on explicit constraints.
Transparent estimates: evidence and confidence are displayed, and values are not invented when data is insufficient.
Context: the interface adapts to time, approximate location, connectivity, and user role.
Feedback loop: students report changes while restaurants observe interest and performance.

This formulation complements the value proposition and UI/UX system defined in MS6 and materializes the decisions made in Sprint 1.

2. How Do Smart Features Generate Value?

A Smart feature does more than display data: it processes that data and produces a useful judgment for decision-making. UniEat generates this value as follows:

Smart feature	Data processed	Judgment produced	Concrete value
Compatible, ranked feed	Budget, diet, available time, payment method, distance, and validity	Which options satisfy the constraints and which should appear first	Removes irrelevant options and accelerates the lunch decision
Queue estimate	Recent reports, number of observations, age, and trend	Approximate waiting time and evidence level	Helps students determine whether they can buy lunch and return to class on time
Accuracy indicator	Agreement among the publication, reports, and recent confirmations	Reliability percentage or status	Prevents users from treating all information as equally reliable
Automatic validity	Publication time, service schedule, and reported status	Active, expiring, or expired menu	Prevents decisions based on information from the wrong day or time period
Choose for Me	Active filters and the set of valid options	Explainable recommendation within the user's constraints	Reduces cognitive load without ignoring user preferences
Performance summary	Views, saves, location opens, reports, and selected period	Signals of interest and behavior, not sales	Helps restaurants improve their offerings and schedules without presenting inferences as facts

Smart Transparency Rules

The recommendation keeps the filters that produced it visible.
Every queue estimate shows its age and is not presented as an exact time.
With fewer than three recent reports, the app shows “Insufficient evidence” instead of a number.
Restaurant metrics explain their definition and time period.
A community report remains pending verification and does not silently replace the official publication.

3. How Do CAS Features Generate Value?

CAS (Context-Aware System) means that the app adapts its behavior to available context without requiring users to enter the same information again on every screen.

Detected or retained context	Experience adaptation	Value generated
Current time	Highlights valid menus, calculates remaining time, and disables expired publications	Reduces false positives and late decisions
Approximate campus location	Sorts by proximity and displays walking references	Reduces travel time and effort
Connectivity status	Activates an offline view with saved data and cache time	Preserves utility during unstable connectivity without hiding the age of the information
Recent community activity	Adjusts queue status or requests more evidence	Makes operational information respond to the current situation
Active constraints	Retains budget, diet, time, and payment settings when returning to the feed	Avoids repetitive configuration and preserves user intent
User role	Displays navigation and actions for either a student or a restaurant	Reduces clutter and provides relevant tools for each actor

Smart and CAS functions depend on each other: context provides current signals, while the Smart component combines them to produce an explainable decision. Without CAS, the recommendation would be generic; without Smart processing, context would only be a collection of data with no decision criterion.

4. Applied UI/UX System

4.1 Visual Direction

The prototype uses a Flat Design / Bold Pop style: flat surfaces, high contrast, solid black borders, and sticker-like labels. The visual language is energetic and university-oriented while maintaining hierarchy, readability, and consistency.

4.2 Color Palette

Color	Hex	Use	Rationale
Primary yellow	`#FFE500`	Brand, primary actions, and active navigation	High visibility and an association with energy and speed
Cyan	`#19D3E8`	Information, Smart results, and neutral states	Distinguishes recommendations and contextual information
Green	`#8BE000`	Available, compatible, open, and confirmation states	Communicates success and availability immediately
Coral	`#FF5A36`	Alerts, expiration, and critical actions	Attracts attention without relying on text alone
Charcoal black	`#121212`	Text, icons, and borders	Maximizes contrast and defines the graphic language
Cream	`#F5F0E6`	Main background	Reduces the visual fatigue of pure white and adds warmth
White	`#FFFFFF`	Cards and input fields	Separates content and improves scanning

Color is never the only indicator of a state; it is always paired with text, an icon, or a label.

4.3 Typography

Family: Quicksand, selected for its geometric, readable, and approachable construction.
Headings: weight 700, used for screen and restaurant names.
Body: weight 500, used for descriptions and supporting information.
Labels and buttons: weight 700, with short, high-contrast text.
The hierarchy avoids long blocks and prioritizes price, distance, queue, and availability.

4.4 Iconography, Images, and Illustrations

Consistent outline icons represent location, time, payment, filters, reports, and navigation.
Food photographs serve as menu evidence and recognition aids rather than isolated decoration.
A mini map on the detail view connects the restaurant to the campus context.
Simple illustrations support empty, offline, and insufficient-evidence states.
Critical icons include a text label to prevent ambiguity.

4.5 Components and Accessibility

Android frames and persistent bottom navigation on primary routes.
An 8 dp base grid, 2 dp borders, and corner radii between 12 and 16 dp.
Minimum touch targets of 48 × 48 dp.
Reusable cards for restaurants, dishes, metrics, and states.
High contrast among backgrounds, text, and actions.
Identifiable focus, selected, disabled, success, warning, and error states.
Explicit language distinguishes exact data, estimates, and insufficient evidence.

4.6 Aspects Applied per View

View	Palette	Typography	Icons	Images / Illustrations	Prototype component	Navigation
01 Today	Green/coral queue states, yellow active tab	Price and distance in 700	Pin, clock, filter	Dish photos on cards	Restaurant card	Bottom nav (student)
02 Filters	Yellow selected chips	Group titles in 700	Diet, wallet, clock	—	Chip groups, CTA with count	Returns to feed keeping filters
03 Menu Detail	Cyan accuracy badge	Restaurant name 700	Payment, schedule, report	Mini map, dish photos	Summary header	Forward from card, back to feed
04 Choose for Me	Cyan recommendation	Recommendation title 700	Shuffle, filter	Dish photo	Highlight card	Bottom nav (student)
05 Publish Menu	Yellow primary action	Field labels 700	Price, clock, payment	—	Single-screen form	Bottom nav (restaurant)
06 Report a Change	Coral for critical option	Short option labels	Availability, price, queue	—	Bottom sheet	Contextual, dismissible
07 Offline	Muted cards, coral notice	Cache time in 700	No-signal, retry	Offline illustration	Persistent banner	Navigation preserved
08 No Menu Published	Neutral + green alternatives	Specific message 700	Info	Empty-state illustration	Alternatives list	Back to feed
09 Insufficient Queue Evidence	Neutral, no state color	Same size as estimate	Clock + label	Evidence illustration	Detail layout reused	Opens report sheet
10 Restaurant Performance	Cyan metrics, yellow CTA	Numbers 700	Eye, bookmark, pin, flag	Bar chart	Metric cards	Bottom nav (restaurant)

5. Native Prototype and Navigation

Editable Figma prototype: UniEat — MS7 Mockups
Source project in Stitch: UniEat — MS7

Navigation Patterns

Bottom navigation (by role): students see Today and Choose for Me; restaurants see Publish and Performance. Each role only sees its own tools.
Filters: a dedicated screen that returns to the feed and retains the selected criteria when applied.
Detail: forward navigation from a card with a predictable return to the feed.
Report: a contextual bottom sheet that keeps users within the menu detail.
Feedback: brief confirmation messages after publishing or reporting.
State variants: offline, unpublished, and insufficient-evidence screens retain the same structure to preserve orientation.

flowchart TD
    subgraph Student
        A[01 Today - Menus] --> B[02 Filters]
        B -->|Apply filters| A
        A <-->|Bottom nav| E[04 Choose for Me]
        A --> C[03 Menu detail]
        E --> C
        C -->|Back| A
        C --> D[06 Report a change]
        D -->|Send or dismiss| C
        C --> G[09 Insufficient queue evidence]
        G -->|Report queue| D
        A --> F[08 No menu published]
        F -->|Nearby alternative| C
        A --> H[07 Offline]
        H -->|Retry| A
    end
    subgraph Restaurant
        I[05 Publish menu] <-->|Bottom nav| J[10 Restaurant performance]
    end

6. Ten Required Views

Juan Esteban Rojas Castañeda

View 1 — Today: Menu Feed

Applied aspects: visual hierarchy, visible budget, quick filters, comparable cards, queue states, campus labels, and bottom navigation. Value demonstrated: brings valid alternatives together and allows students to compare them without opening every restaurant.

View 2 — Search Filters

Applied aspects: grouped controls, persistent selection, direct values, a call to action with the result count, and a reset option. Value demonstrated: turns personal constraints into a compatible set of options.

Camilo Andres Molina Plata

View 3 — Menu Detail

Applied aspects: mini map, context summary, price, dishes, schedule, payment methods, accuracy, and report action. Value demonstrated: gathers the evidence needed before traveling or making a purchase.

View 4 — Choose for Me

Applied aspects: prominent recommendation, visible filters, short explanation, access to details, and an option to choose again. Value demonstrated: reduces cognitive load without breaking the student's constraints.

Kevin David Alvarez Romero

View 5 — Publish Menu

Applied aspects: single-screen form, structured fields, clear hierarchy, feedback, and an unambiguous primary action. Value demonstrated: reduces the effort required to keep the daily offering up to date.

View 6 — Report a Change

Applied aspects: contextual bottom sheet, understandable options, optional comment, safe dismissal, and confirmation. Value demonstrated: captures community evidence without automatically replacing the official publication.

Juan Jose Murillo Aristizabal

View 7 — Offline

Applied aspects: persistent notice, cache timestamp, muted cards, retry action, and preserved navigation. Value demonstrated: preserves utility during network failures and honestly communicates the age of the data.

View 8 — No Menu Published

Applied aspects: purposeful illustration, specific message, explanation, nearby alternatives, and a path back to the feed. Value demonstrated: prevents a dead end and distinguishes an open restaurant from an unpublished daily menu.

Samuel David Rozen Mogollon

View 9 — Insufficient Queue Evidence

Rule. We only show a waiting-time estimate when a restaurant has at least 3 queue reports in the last 30 minutes. Below that threshold, the queue card switches to "Insufficient evidence". It shows how many reports exist (e.g., "1 of 3 reports") and how long ago the last one was sent.

Why this design. We considered showing a rough number anyway (e.g., "~10 min"). We discarded it because a student with 30 minutes between classes would read that number as a promise (PAS-06). With one or two reports, the number would say more about who reported than about the actual queue. An explicit unknown state is less convenient, but it keeps the estimate trustworthy on the days when it does appear (PAS-08).

UI/UX aspects applied.

Palette: the queue card uses the neutral white/cream surface instead of green or coral. Green would read as "short queue" and coral as "long queue", and we don't know either. The state is carried by the label and the icon, not by color.
Typography: "Insufficient evidence" uses Quicksand 700 at the same size as a normal estimate, so the card keeps its place in the hierarchy. The explanation uses weight 500.
Icons: the clock icon always appears with its text label, so the state is not ambiguous.
Illustrations: a simple illustration supports the empty state, following the rule in section 4.4.
Prototype: it is the same layout as the menu detail (view 3); only the queue card changes. This keeps the student oriented.
Navigation: "Report queue" opens the same bottom sheet as view 6, with the queue option preselected. After sending, the student returns to the detail and the report counter updates.

Value demonstrated. The app avoids false precision, and it turns the lack of data into a concrete action: the student who is already in line can close the gap.

View 10 — Restaurant Performance

Metric definitions. Every metric counts platform activity, not sales. The definitions are visible in the view itself.

Metric	What it counts
Views	Times students opened this restaurant's menu detail in the selected period
Saves	Students who saved the menu
Location opens	Taps on the map or directions from the menu detail
Reports	Community reports about this restaurant's publication (availability, price, queue)

Why this design. A restaurant could easily read "120 views" as "120 customers". To prevent that, the dashboard avoids the words sales, customers, and revenue, and each metric card includes its definition. The chart uses bars per day instead of a line, because the data is discrete daily counts and a line would suggest continuity between days. The selected period is always visible above the metrics, so numbers are never shown without their time window.