3. Does this sound familiar..?
• Acting as advisor on web applications to a
design consultancy in London
• Won a project to develop a pilot for
Internet shopping:
– Major UK supermarket
– Leading US-based IT vendor
• Recognised that success critically
depended on design
4. Does this sound familiar..?
• Lots of background design effort
– Psychology of shopping
– Physical versus virtual store layout
• Storyboard developed and accepted
– Designers were competent with HTML/CSS
• Data model designed and accepted
– Single A4 page
• So far, so good…
5. Does this sound familiar..?
• Developing it as a web application was
beyond the skills of the Design
Consultancy
• Brought in a team of programmers who
specialised in web applications
• The rot soon set in….
6. Does this sound familiar..?
• Oracle data model expanded to a diagram
the size of the board-room table
– Incomprehensible to all but the database guy
• Programmers produced a working version
– But the code was un-recognisable
• “where’s our HTML gone?”
– Could not be maintained by the designers
7. Does this sound familiar..?
• From the moment the programmers were
involved, the Design Consultancy were out
of the loop
• Project was in the hands of programmers
with no design skills
• Project extension:
– Given to the software company
– Design Consultancy frozen out
– Project later crumbled and fizzled out
12. It’s the single biggest problem in
web/Ajax application development
13. Why is it a problem?
• What makes an application successful?
• What differentiates:
– Poor applications?
– Mediocre applications?
– Great applications?
14. Why is it a problem?
• What makes an application successful?
• What differentiates:
– Poor applications?
– Mediocre applications?
– Great applications?
• It’s not the programming!
15. Web Applications
• What makes an application successful?
• What differentiates:
– Poor applications?
– Mediocre applications?
– Great applications?
• Answer: Design
16. What’s the problem?
• Web Application Development:
– Assumed to be a programming task
– Not a design task
• Designers do not understand:
– programming
– databases
• After the initial design stage, the designer has no
role in the rest of the development lifecycle
• Designs are easier to maintain than programs!
17. The industry solution?
• AjaxWorld: Yakov Fain (Farata Systems), Mar
30, 2008:
– Do We Need to Teach Designers Programming?
– “Adobe invited professors from different schools to
discuss what has to change in the curriculum of
Visual Design and Software Engineering disciplines
so designers can understand programming better and
software developers would be better at designing the
user experience”
– “Do we need to breed new creatures called d-
e-s-i-g-n-o-p-e-r and d-e-v-i-g-n-e-r? “
– “Developers are from Mars; designers are from
Venus”
19. Design-focused
Web/Ajax Development
• So I’m going to propose a way forward
– based on 13 years’ considering the problem
– and 10 years’ providing a solution
• Let’s first understand why things are the
way they are…..
20. What are web Applications?
• Programs that:
– Generate HTML
– Are accessed via HTTP
– And they access a database
21. What are web Applications?
• Programs that:
– Generate HTML
– Are accessed via HTTP
– And they access a database
• So they therefore require a programmer
– Designers understand static HTML pages + CSS
– Designers don’t understand programming
– Designers don’t understand databases
22. Why does it get so complex?
• The web was never designed as an
application platform:
– Stateless
• No concept of a meaningful ongoing dialogue
between browser and web server
– HTTP protocol
• Simple request/response protocol
• Wide open, simple URL + name/value pair
structure
• Inherently insecure and open to abuse
23. Why does it get so complex?
• The browser only communicates with the
web server
– The programs that process the requests and
generate the HTML responses are hooked in
behind the web servers
• The web pages are dynamically generated
by programs and content depends on:
– What the user has done so far
– The contents of the database
24. Why does it get so complex?
• Programmer’s responsibility to:
– Create the illusion of a session
– Provide the navigation between generated
pages in response to user activity
– Provide a consistent and adequate layer of
security around the URL requests within a
session
25. But we have frameworks don’t we?
• Rather than everyone re-inventing wheels,
tools have developed that automate these
mechanisms
• Almost all are based on the concept of the
Model View Controller (MVC)
26. Web Application: MVC View
Web Page 1
Step 1:
User decides
what to do:
eg clicks button
or link
28. Web Application: MVC View
Web Page 1
Step 3:
URL analysed
and mapped to Business
Controller
corresponding logic
business logic
URL map
29. Web Application: MVC View
Web Page 1
Step 4:
Business logic Business
Controller View
selects next view logic
URL map Database
(model)
30. Web Application: MVC View
Web Page 1 Web Page 2
Step 5:
View is Business
Controller View
generated logic
URL map Database
(model)
31. Web Application: MVC View
Web Page 2
Process repeats:
User decides
what to do:
eg clicks button
or link
32. Web Application: MVC View
• Web pages are programmatically-
generated markup = the “view”
• The URL is the focus of attention
• Closely reflects how it actually works
– Only a very slight level of abstraction
• Totally programmer orientated paradigm
– Focuses on the how
– The what and the design gets lost in a ton of
code
33. Creating the “Eh?” Team
• In the MVC paradigm:
– Designer storyboards the application
– Design agreed
– Handed over to programmers
– From this point onwards, designer can no
longer participate in the life-cycle of the
application
• What the programmers develop is
incomprehensible
35. Perpetuating the “Eh?” Team
• Little discipline applied by MVC environment
• MVC “plumbing” isn’t automated:
– How to submit, post and validate forms is left to each
programmer
– In-page coding is a free-for-all
– Cut, paste and modify components
• 1 or more years later, nobody can understand
their own code, let alone another developer’s
– Quicker to rewrite pages than figure out how they
work
36. So how do we solve this problem?
• Let’s stand back and look at what we’re
doing…
37. What are web applications?
• Programs that:
– Generate HTML
– Are accessed via HTTP
– And they access a database
38. What are web applications?
• Programs that:
– Generate HTML
– Are accessed via HTTP
– And they access a database
• Right?
39. What are web applications?
• Programs that:
– Generate HTML
– Are accessed via HTTP
– And they access a database
• Right?
– Yes of course they are in reality
– But do we need to think of them in this way?
40. What are web applications?
• Here’s another way to conceptualise them
41. What are web applications?
• Here’s another way to conceptualise them
• They are web pages:
– That have some content fetched from a
database
– Whose flow between them is determined in
part by:
• the user’s interaction; and/or
• content in the database
42. “Static” web sites
Next Next Next
Web Page 1 Page Web Page 2 Page Web Page 3 Page
43. Web Application
From a designer’s point of view:
Web Page 1
Step 1: fetchData()
Run a method that
fetches the data
needed for the page Database
50. Design-focused Web Applications
• Page content and navigation is the primary focus
– No programming code needed in pages
• “Fetch” method called when page loads
• “Save” methods linked with user-triggered
events (eg submit buttons)
• Technical stuff should “just work”:
– Invocation of methods
– Orchestration of the MVC mechanics
– Session and security management
51. “Static” web sites
Next Next Next
Web Page 1 Page Web Page 2 Page Web Page 3 Page
52. Design-focused Web Applications
Next Next Next
Web Page 1 Page Web Page 2 Page Web Page 3 Page
save fetch save
fetch fetch save
Database
53. What about Ajax?
• Event-driven DOM manipulation:
– replacement of innerHTML
• Page fragments
– “pages” that just contain the replacement markup
– fetch and save methods
• Just specify 3 key things:
– Event
– Page fragment name
– Target Id
54. Design-focused Ajax framework
“Front-end” technology (PHP, JSP, Python etc)
Container
Page
Fetch
Method
State & Session Management
“Back-end” Server
55. Design-focused Ajax framework
Replaces DOM content
Event
Container XMLHttpRequest Page
Page Fragment
Request
Page
Fragment
Fetch
Method
State & Session Management
“Back-end” Server
56. Design-focused Ajax framework
Replaces DOM content
Event
Container Page
Page Fragment
Request
Page
Fragment
Fetch
Method
State & Session Management
“Back-end” Server
58. Interfacing design and programming
• Clearly need a conceptual interface
through which the designer and
programmer can inter-operate
• This is provided by the “Session” data
store
59. The Session Interface
Provides the interface between the designer and the programmer
Session
Web Page Database
Data-store
Designer Programmer
Using special Using APIs provided
syntax to refer to by framework
Session values
60. No data binding!
• Data binding is a scourge!
– It begins with a blessing
– But it ends in a curse
• The Session data-store de-couples the
page’s data from the physical database
61. This changes everything
• Any designer who can design HTML
pages can be in control
– Abstraction using additional “macro” XML tags
– Describe what is required, not how to do it
• No coding apart from occasional, simple Javascript
– Designer’s high-level pages compiled to
produce the how
• Technology-independent
• PHP, JSP, ASP.Net, Ruby, Python, etc
62. This changes everything
• Transitions and method orchestration must
be automated
– Also session and security management
71. The “A” Team
• Designer stays in control throughout the lifecyle
• Designer doesn’t need to have any knowledge of
programming, business logic or database
structure/content
• Programmer just focuses on business logic to
fetch/validate/process/save data
– doesn’t waste any time on the “plumbing”
– Isolated from design issues
– Standardised processes
– Discipline occurs because it’s the line of least
resistance during development
72. Design-focused Development
• Proven benefits:
– Much higher productivity compared with conventional
techniques
– Applications are focused on design requirements
• designer retains control throughout the life-cycle
– Cuts out all the complexity of Ajax
– Integrates with most UI/widget libraries
• Leverage “best of breed” instead of reinventing wheels
– Significantly lower maintenance than conventional
techniques
• Because you just describe the what, not the how
• Build an “A” team, not an “eh?” team!
73. Conclusions
• The programmer-focused approach has
had its day
• Design, not programming, must take
centre-stage
• None of the main industry players have a
solution
• It’s not just theory
• Come and see how it can be done!
