UI SOFTWARE ARCHITECTURE docx

Model – View –Controller Pattern Separation of responsibilities  Model: application state  Maintains application state data fields  Implements state-changing behavior  Notifies depe

UI SOFTWARE ARCHITECTURE

 Directs the eye

 Provides balance through its use

 Strengthens impact of message

 Allows eye to rest between elements of activity

 Increases legibility, clarifies hierarchy

 Used to promote simplicity and “elegance”

4

 Economy of Visual Elements

 Minimize borders, heavy outlining, section boundaries

 Use white space instead

 Reduce clutter

 Minimize the number of controls

5

Clarity via White Space

 White space

6

Principle: Consistency

 Be c o ns is te nt in e ve ry as pe c t:

 In layout, color, images, icons,

typography, text

 Within screen, across screens

 Stay within metaphor everywhere

 Platform may have a style guide – follow it!

7

 Result when local and global

designs aren’t balanced

 Color Palette conflict

 Conflict between local and global design

8

 What are the relative “levels” of importance?

10

Typographical Hierarchy

11

Typographical Hierarchy plus Indentation

12

Principle: Grids

 Western world

 Start from top left

 Allows eye to parse display more easily

13

 (Hidden) horizontal and vertical lines to help locate window

components

 Align related things

 Group items logically

14

Grids: Examples

15

Grid Alignment

 Grid: the invisible, underlying structure of a site

 Grid: essential – you must use one

16

Grid Aligment

17

Grid Alignment

 Grids

 Help locate window components

 Align related things

 Group items logically

 Minimize number of controls, reduce clutter

18

Grid Example

19

 Can be used to set off most important item

 Allow it to dominate

 Ask yourself what is the most

important item in the interface,

highlight it

 Use geometry to help sequencing

21

Contrast Techniques

 Blinking

 Good for grabbing attention, but use

very sparingly

 Reverse video, bold

 Good for making something stand out

 Again, use sparingly

22

Contrast Example

23

Important

element

Poor Graphic Design

 Inconsistent tone

 Marble conflicts with icons

 Varied hue, saturation and brightness

 Unbalanced – heavy on left.

Evaluating Screen Organizations

Bad Example

26

Disorganized

Bad Example

27

Visual noise

Bad Example

28

Overuse of 3D effects

Model – View –Controller Pattern

 Separation of responsibilities

 Model: application state

 Maintains application state (data fields)

 Implements state-changing behavior

 Notifies dependent views/controllers when changes occur (observer pattern)

 View: output

 Occupies screen extent (position, size)

 Draws on the screen

 Listens for changes to the model

 Queries the model to draw it

 Controller: input

 Listens for keyboard & mouse events

 Tells the model or the view to change accordingly

 Decoupling

 Can have multiple views/controllers for same model

 Can reuse views/controllers for other models

29

MVC diagram

30

Example: Text field

31

Example: Web browser

32

Example: Database-backed web server

33

Example: Traffic Visualizer

34

Hard to separate Controller and

View

 Controller often needs output

 View must provide affordances for controller (e.g scrollbar thumb)

 View must also provide feedback about controller state (e.g., depressed button)

 State shared between controller and view: Who manages the selection?

 Must be displayed by the view (as blinking text cursor or highlight)

 Must be updated and used by the controller

 Should selection be in model?

Reality: Tightly Coupled View and Controller

 MVC has largely been superseded by MV

(Model-View)

 A reusable view manages both output and

input

 Also called widget or component

 Examples: scrollbar, button, menubar

36

 Canvas, button, label, textbox

 Containers are also components

 Every GUI system has a view hierarchy, and the hierarchy is used in lots of ways

 Output

 Input

 Layout

37

View hierarchy: Output

 Children are (usually) drawn on top of parents

 Child order dictates drawing order between siblings

View hierarchy: Input

 Event dispatch and propagation

 Raw input events (key presses, mouse movements, mouse clicks) are sent to lowest component

 Event propagates up the hierarchy until some component handles it

 Keyboard focus

 One component in the hierarchy has the focus (implicitly, its ancestors do too)

39

View hierarchy: Layout

 Automatic layout: children are positioned and sized within parent

 Allows window resizing

 Smoothly deals with internationalization and platform differences (e.g fonts or widget sizes)

 Lifts burden of maintaining sizes and positions from the programmer

 Although actually just raises the level of abstraction, because you still want to get the graphic design

(alignment & spacing) right

40

Observer Pattern

 Observer pattern is used to decouple model from views

41

Basic Interaction

42

Model must be consistent before update

43

Registration changes during update

44

Update triggers a modify

45

Out-of-order Update

46

Android UI design pattern

 Android: State of the UI

 Application UI design patterns

 Making Android apps look good

47

Android: State of the UI

“Mere knowledge of the truth

will not give you the art of

persuasion.” – Socrates

48

UI design pattern

 Like a software design pattern, a UI design pattern

describes a general solution to a recurring problem

 Patterns emerge as a natural by-product of the design process

 For each pattern:

51

 DO highlight what’s new

 DO focus on 3-6 most important choices

 DO be flavorful

52

Action Bar

53

Action Bar

 Dedicated real estate at top of the screen to support navigation and frequently used operations

 Replaces title bar

 Best for actions common across your app

 DO use to bring key actions onscreen

 DO help to convey a sense of place

 DO use consistently within your app

 DON’T use for contextual actions

54

Quick Actions

55

Quick Actions

 Action popup triggered from distinct visual target

 Minimally disruptive to screen context

 Actions are straightforward

 Fast & fun

 Recommendation

 DO use when items have competing internal targets

 DO present only the for most important and obvious actions

 DO use when the item doesn’t have a meaningful detail view

 DON’T use in contexts which support multiple selection

56

Search Bar

57

 DO use for simple searches

 DO present rich suggestions

 DO use the same behavior

58

Companion Widget

59

A blueprint for building a great Android app

61

Making Android app good look

 A More choices for users

 B Some new screen sizes to consider

62

Multiple screen sizes

63

64

New Android Icons

65

How to make an Android app icon

http://developer.android.com/guide/practices/ui_guidelines/icon_design.html

66

Summary of finished icon dimensions for each of the three generalized screen densities, by icon type.

Icon Type Standard Asset Sizes (in Pixels), for Generalized Screen Densities

Low density

screen (ldpi) Medium density screen (mdpi) High density screen (hdpi)

Launcher 36 x 36 px 48 x 48 px 72 x 72 px

Menu 36 x 36 px 48 x 48 px 72 x 72 px

Status Bar (Android

2.3 and later) 12w x 19h px(preferred, width

may vary)

16w x 25h px(preferred, width may vary)

24w x 38h px(preferred, width may vary)

Status Bar (Android