Teoria Hypermedia Application 1o Comp.

Teoria Hypermedia Application 1o Comp.

An application design model should be…

 Easy to learn for designers and other

 stakeholders

 Easy to teach

 Usable

 Lightweight in documentation

 Offering few concepts to master the

 complexity

 Effective for brainstorming ideas

 Directly related to the requirements of the application

IDM Idea

A user‘s web experience is a human/application is a dialogue

Designing a web application means designing the human/application dialogue

Traditional Design Dimensions and the IDM approach

Design Dimensions

Dialogue metaphors IDM submodels

Content Design

Designing what can be said (what is the dialogue about) C-IDM (content or conceptual IDM)

Navigation/

Interaction Design

Designing the actual flow of dialogue (how to move from one topic to another one)

L-IDM (Logical IDM)

Presentation Design

Designing the “form” of the dialogue structures P-IDM (Presentation of Page IDM)

Cardinality

Cardinality = size of a set (mathematical definition) Our definition:

cardinality = expected (minimum and max) number of instances

Why Cardinality?

 To plan the overal size of the application

 To estimate the editorial effort

 Plan the content production resources

 To guide the definition of (multiple) groups of topics

 To guide the definition of navigation patterns in L-IDM

 To set contraints and requirements on lay-out

Dialogue Act

DIALOGUE ACT (from linguistics) = “A dialogue act is a unit in the communicative behaviour in dialogue”

“Dialogue is a flow of dialogue acts between actors – senders and receivers”

In web applications:

DIALOGUE ACT = a unit (i.e., atomic element) of content offered by the application to the user during the dialogue

Dialogue = navigation

Navigation flow = flow of system’s generated dialogue acts Three categories

 Content Dialogue Act: dialogue unit about a topic (of a given kind)

 Transition Act: A dialogue unit about a switch of subject, i.e, a relevant association

 Introductory act: A dialogue unit about a group of Topics (within multiple group of topics) Some fragmentation criteria of dialogue act

 Content size (large amount of content should be split to be more readable, more usable….)

 Content nature

 User profile

 Multiple media

Pages

Page: atomic presentation unit. Visual container of CONTENT (text, images, animation, video, audio) AND LINKS

Categories of pages

 Topic Pages: The place where users consume contents about a given single topic or topic of a given kind (derived from at least one or more content dialogue acts)

 Transition Page: The place where users understand what is related to what, and decide to go on (Derived from a transition act)

 Introductory page: The place where users understand what are a group is about, and what are its members, and decide to go on (Derived from introductory act(s))

Topic Page: Structure

 Title: what the page is about (from a user point of view) as defined in logical design

 Content : as defined in logical design

 Structural Links : links to other dialogue acts of the same topic

 Transition Links: a link for each “outgoing” relation

 Landmarks: as defined from the Home Page or the section the page belongs to

 Orientation Info (often dynamic): where are we?

 Group Links: to move within the current group

 “GO ON” (dynamic): How can I continue what I am doing?

Transition Page: Structure

 Title: “courses taught by Franca Garzotto”

 List of Links: a link to each target of the relation

e.g. (for each course taught by Garzotto) “name, subtitle, starting date “

NOTE: the “order” of the courses should be decided by the designer and made clear to the user

 Landmarks: as defined from the Home Page

 Orientation Info (often dynamic): where am I?

Introductory Page: Structure

 Title: e.g. “OUR BEST COURSES”

 Introductory content (OPTIONAL): something to explain what are we talking about, to attract the user attention, to promote going “in depth”…

 List of items: Each item

o Some descriptive info (e.g. to the identify/characterize the course) o A group link

NOTE: designer should be very conscious into choosing the proper decsriptive info and properly ordering the items

 + Landmarks, Orientation Info, (“GO ON” link)

Navigation Patterns

Compact specifications of some general “typical” navigation strategies

General Topologies of nodes (pages) and arcs (links) that have been proved effective and usable for navigation in large hypermedia structures

 Guided Tour (GT) (Assume that there is no reason to choose one of item)

 Index (I) (The user can choose and select one item)

 All 2 All (A2A)

Stakeholders

Anyone who has an interest in the application to be designed (Client, Project leader, Users, Financing partners, Content providers, Opinion makers, Experts,…)

 Client: Who is officially “signing the contract” (deciding to start off the project)

 Project Leader: Whoever is managing the project on behalf of the client

 Users: The persons „in dialogue“ with the system. Primary target for the design

 Financing Partners: Those who provide financial resources (may or may not coincide with the client) Sponsors, Agencies, Foundations, Institutions, …Somehow need visibility in the design

 Conent Providers: Crucial for content-intensive systems

 Opinion Makers: Those who can in anyway influence the public or local opinion about your system

Goals

What each stakeholder expects from the system

Not what stakeholder “think” that the application should be but their actual needs and goals they actually expect the application should satisfy

Constraint

Those elements that can’t be changed and must be considered

 Financial resources

 Human resources

 Time

 Politics

 Competition

 Technology (availability, devices, …)

 Delivery issues (availability, costs, …)

 Special needs

Requirements

“ What“ the application must offer to meet the goals.

A requirement is a statement that identifies a capability, characteristic, or quality factor of a system in order for it to have value and utility to a stakeholder

Scenarios

A scenario is „a story about use“

An example of how a “typical” user (persona) is going to use the application. Not a list of possibilities but the description of one usage. Story of an interaction with a system, salient and realistic.

Part of a scenario:

 Setting - situation, context

 Persona - characters who use the system (user profile)

 Goals - intentions/motivations

 Actions – detailed tasks, observable behaviour

 (optional) Events - external events of actions of system(s)

 (optional) Outcome – the final result(s) for the user