Made by Many: On Collaborative Design

6th phpDay – May 15th/16th 2009 Verona - Italy Memi Beltrame: Made by Many – On Collaborative Design

Memi Beltrame

Made by ManyOn Collaborative Design

phpday, may 15th 2009Verona


Who I am: Memi Beltrame

• Developping websites since 1997• Using php since 2000• 2003-2007 Study of cinematography• 2007 to present: specialising in frontend and interaction design

• Since 2008 for Liip Agile Web Development

• Movie enthusiast• 1st feature film in preparation... some day...


Why am I here?

To raise awareness and to show the dynamics of collaborative design


Argh! Design! Go away, I am a Developer!

Design is not only pushing pixels

Designing means arranging stuff:Pixels, Databases, Code, Processes


Collaborative Design takes place whenever an artefact is planned

and/or implemented by two or more participants.


Typical Collaborative Design Areas

ArchitectureSoftwareMovies!


The Internet is (probably) the biggest single instance of

Collaborative Design


Collaborative Design is a reality.

It is the inevitable process that emerges when you build something

as a team.


Unlike UCD or TDD it is nothing you choose, it just happens,

nolens volens.

UCD: User centered designTDD: Test driven development


It just happens, ok.

Understand it.Control it.

Embrace it.


Even the simplest Customer < > Contractor Relationship

involves Collaborative Design


It involves is a network of participants


The goal is a common product with a high overall utility


Every participant can propose solutions for design issues


In theory a Design should move towards an optimum of utility

Utility

Time


In theory. Not in reality.

Utility

Time


Why does collaboration not automatically mean

improvement?


Participants are inter-dependent.


Participants are inter-dependent.Inter-dependency means

„I need something“


Every participant has a self-interest

Customer:Affordable yet magic

Designer:beautiful and usable

Developer:solid, stable and performing


Fulfilling self-interest meansReaching a local optimum of utility


Are participants willing to compromise their self interest for

the sake of a global optimum?


A B C D global Utility


The system can become very complex

Webserver admin

DB Admin

php-Developer

Proxy guy

Mobile Services admin

Grafics

Usability guy

DB SpecialistProject Lead

Management


It's hard to keep track of the interactions and design decisions

Webserver admin

DB Admin

php-Developer

Proxy guy


Grafics

Usability guy


Management


Subsytems can emerge

Webserver admin

DB Admin

php-Developer

Proxy guy


Grafics

Usability guy


Management


Subsytems also have a local optimum utility plus they are loyal!

Webserver admin

DB Admin

php-Developer

Proxy guy


Grafics

Usability guy


Management


Every new participant brings a shift in the oveall utility.


Every old participant must be aware of this and accept it. Otherwise the team is possibly ripped apart.


Successful Collaborative Design is based on the commitment of each

participants to achieve an optimum of overall utility.


How is that achieved?


● Raising awareness● Remove barriers between you and the customer to form a team● High iteration in the workflow● Elaboration of interdisciplinary patterns● Talk, talk, talk, talk!


An example of interdisciplinary patterns:

The Undo Dilemma


A list of users to be administered

Edit DeleteEdit Delete


The Undo dilemma

Edit DeleteEdit Delete


What happens if you hit Delete?


What happens if you hit Delete?

Usually: a pop up!


Pop ups are Bad! Avoid them!


Use Undo!


Because:UNDO• is the rescuer of users in distress.• encourages exploration.• eliminates sensless confirmation-dialogs

Don‘t ask, do and UNDO ! !


Pop Ups are easy to implement,Undo is not.

It requires a well planned process


Frontend and backend people must decide on a pattern of implementation.

This is a collaborative design decision.


Possible patterns of implementation of undo in the database:

1) Through a Flag2) Through a history table


Implementation of Undo

VIEW view_users------------------------| ID | name | surname |------------------------| 1 | Pio | Polli |------------------------| 3 | Toni | Marroni |------------------------

SELECT * From `users` WHERE is_deleted = 0

TABLE users-------------------------------------| ID | name | surname | is_deleted |-------------------------------------| 1 | Pio | Polli | 0 |-------------------------------------| 2 | Enzo | Enzi | 1 |-------------------------------------| 3 | Toni | Marroni | 0 |-------------------------------------

1) Through a FLAG

• simple• Ideal to undo deletions• Downside: data may be materialized twice


Implementations of undo

TABLE users_history----------------------------------| ID | ID_users | name | surname | ----------------------------------| 1 | 1 | Pio | Polli |----------------------------------| 2 | 2 | Enzo | Enzi |----------------------------------| 3 | 3 | Toni | Marroni | ----------------------------------| 4 | 2 | Enio | Enzi |----------------------------------

TABLE users------------------------| ID | name | surname |------------------------| 1 | Pio | Polli |------------------------| 2 | Enio | Enzi |------------------------| 3 | Toni | Marroni |------------------------

2) Through a history table

Table users_history: every change also executes an INSERT

Table users: every change is an UPDATE


Implementations of undo

2) Through a history table

Pros• Allows endless undo• Works as a history• Is not limited to a single data entry• allows „edit in place“ on a high level

Cons• Needs a more complex system• Executes more SQL queries and creates more traffic and data


Thank you!

Slides: http://slides.liip.ch

Made by Many: On Collaborative Design

Design

Transcript of Made by Many: On Collaborative Design