User Interface Design: Forms, Reports & Dialogues

TAKEAWAYS:

• Forms capture input data interactively, while reports present processed data for decision-making.
• Effective UI design follows consistency, clarity, and user-centric principles.
• Dialogue design ensures smooth user-system interaction through menus, prompts, and feedback.
• Decision tables and reduced decision tables simplify complex business rules (e.g., loan approvals).
• Physical database design translates logical models into storage structures (e.g., tables in MySQL).
• CASE tools automate UI prototyping (e.g., Microsoft Visio, Lucidchart).

1. Forms vs. Reports: Core Differences

Forms and reports are the two primary UI components for data input and output. Their roles differ fundamentally:

Why it matters:

• Forms prevent invalid data (e.g., Daraz’s checkout form rejects empty fields).
• Reports enable audits (e.g., NTC’s traffic violation reports for fines).

2. Designing Forms: Step-by-Step Process

A well-designed form reduces errors and improves usability. Follow these steps:

Step 1: Identify Input Requirements

• What data is needed? (e.g., patient name, test type in an online pathology system).
• Sources: Business rules (e.g., "Age > 18 for music competition").
• Example: For a Khalti loan application, required fields might include:
  • Applicant name, ID, income proof, loan amount, tenure.

Step 2: Structure the Form

Use a logical flow to guide users:

1. Header: Title (e.g., "Loan Application Form").
2. Sections: Group related fields (e.g., "Personal Details," "Loan Terms").
3. Fields: Label clearly (e.g., "Annual Income (NPR)").
4. Buttons: "Submit," "Reset," "Save Draft."

Visual Rule:

flowchart TD
    A["Header: Loan Application"] --> B["Section 1: Personal Info"]
    B --> C["Fields: Name, ID, Contact"]
    C --> D["Section 2: Loan Details"]
    D --> E["Fields: Amount, Tenure, Interest Rate"]
    E --> F["Buttons: Submit / Reset"]

Step 3: Validate Inputs

• Data types: Numbers (e.g., loan amount), dates (e.g., repayment start date).
• Constraints:
  • Range: Age ≥ 18 (music competition).
  • Format: Email must include @.
  • Dependency: If "Tenure" is 5 years, calculate EMI automatically.

Example: For a Pathao driver registration form, validate:

• License number (alphanumeric, 10 characters).
• Vehicle type (select from dropdown: "Bike," "Car," "Auto").

Step 4: Error Handling

• Inline validation: Show errors next to fields (e.g., "Income must be ≥ 50,000 NPR").
• Summary errors: List all issues at submission (e.g., "Fix these 3 errors before submitting").

3. Designing Reports: Key Principles

Reports transform raw data into actionable insights. Key principles:

1. Audience: Who reads it? (e.g., bank manager vs. customer).
2. Purpose: What decision does it support? (e.g., "Approved loans vs. rejected").
3. Structure:
   • Header: Title, date, report name.
   • Body: Tables, charts, or text summaries.
   • Footer: Page numbers, totals.

Example: NEPSE Stock Report

• Header: "NEPSE Daily Trading Summary – 2024-05-20"
• Body:
  • Table: Top 5 Gainers/Losers (symbol, price, % change).
  • Chart: Market trend (line graph).
• Footer: "Source: NEPSE Official Portal"

Visual Rule:

flowchart TD
    A["Header: Report Title"] --> B["Body: Tables/Charts"]
    B --> C["Footer: Source & Date"]

Report Types

4. Dialogue Design: Making Interactions Smooth

Dialogues are conversations between users and systems. Key elements:

1. Menus: Offer options (e.g., eSewa’s "Pay Bill" vs. "Transfer Money").
2. Prompts: Guide users (e.g., "Enter your Ncell number: _____").
3. Feedback: Confirm actions (e.g., "Payment of NPR 500 successful!").
4. Error Messages: Clear and actionable (e.g., "Invalid PIN. Retry.").

Example: WhatsApp Chat Interface

• Menu: "New Chat," "Status," "Calls."
• Prompt: "Type a message..."
• Feedback: "Message sent ✓" or "Failed to send ✗."

Dialogue Design Process:

stateDiagram-v2
    [*] --> User_Input
    User_Input --> System_Validation
    System_Validation --> Valid: Show_Confirmation
    System_Validation --> Invalid: Show_Error
    Show_Confirmation --> [*]
    Show_Error --> [*]

5. Decision Tables: Simplifying Complex Rules

Decision tables map conditions to actions (e.g., loan approval logic). Used in:

• Bank loan systems (interest rates based on credit score).
• Traffic fine calculators (speed vs. fine amount).

Example: Music Competition Registration

Reduced Decision Table (simplified):

How to Build One:

1. List all conditions (e.g., age, nationality).
2. List all actions (e.g., approve/reject).
3. Fill in rules (e.g., "If age >18 AND Nepalese → Approve").

6. Physical Database Design: Turning Logical Models into Tables

Logical design (e.g., ER diagrams) defines what data exists. Physical design defines how it’s stored (e.g., tables in MySQL).

Key Steps:

1. Normalize data (remove redundancy, e.g., store customer details once).
2. Define tables:
   • Primary Key (PK): Unique identifier (e.g., customer_id).
   • Foreign Key (FK): Links tables (e.g., loan_id in loan_payments).
3. Optimize for queries:
   • Indexes on frequently searched fields (e.g., email in users).
   • Data types (e.g., VARCHAR(50) for names, DECIMAL(10,2) for amounts).

Example: Bank Loan System

CREATE TABLE customers (
    customer_id INT PRIMARY KEY,
    name VARCHAR(100),
    email VARCHAR(100) UNIQUE,
    credit_score INT
);

CREATE TABLE loans (
    loan_id INT PRIMARY KEY,
    customer_id INT FOREIGN KEY REFERENCES customers(customer_id),
    amount DECIMAL(12,2),
    tenure_years INT,
    interest_rate DECIMAL(5,2)
);

Why Physical Design Matters:

• Performance: Fast queries (e.g., "Show all loans with interest > 10%").
• Storage: Efficient use of space (e.g., TINYINT for yes/no flags).

7. CASE Tools: Automating UI Design

Computer-Aided Software Engineering (CASE) tools speed up prototyping:

• Microsoft Visio: Draw DFDs, ER diagrams.
• Lucidchart: Collaborative UI wireframing.
• SQL Server Management Studio: Design physical databases.

Example Workflow:

1. Sketch a form layout in Lucidchart.
2. Export to HTML/CSS for developers.
3. Test with users (e.g., Ncell’s app prototype).

In the Real World

1. eSewa’s Bill Payment Form

   • Form Design: Validates bill number, amount, and payment method (cash card, mobile).
   • Report: Generates a "Payment Receipt" with transaction ID, date, and merchant details.
   • Dialogue: Confirms payment with "NPR 500 deducted from your account."

2. Ncell’s Monthly Usage Report

   • Data Source: Customer’s call/SMS/data usage logs.
   • Report Type: Summary (total usage, charges) + exception (overage fees).
   • Physical Design: Stored in a customer_usage table with usage_date and charge_amount.

3. Pathao Driver Registration

   • Decision Table: Approves registration only if:
     • License is valid AND
     • Vehicle inspection passes AND
     • Background check clears.
   • Form Fields: Vehicle details, license scan, selfie for verification.

Exam Tip

1. Compare Forms vs. Reports: Always highlight interactivity (forms) vs. read-only output (reports).
2. Decision Tables: Practice reducing complex rules into tables (e.g., loan approvals).
3. Physical Database Design: Show SQL table creation with PK/FK relationships.
4. Dialogue Design: Describe user flow (e.g., "User clicks ‘Submit’ → System validates → Shows success/error").
5. Real-World Tie: Relate examples to Nepalese systems (e.g., eSewa, Ncell, banks).
6. Diagrams: Draw DFDs for data flows (e.g., "Patient registers → System generates login credentials").