There are major hurdles to incorporating user-centered design into the software development process: requirements that are out of sync with design materials, prototypes that hastily get turned into production software, and the chasm that exists between interaction designers and developers. How do you quickly and convincingly mock-up interactivity? How do you make the transition from design to code while keeping managers, clients, and testers engaged and informed? The Informatics Solutions Group at Children's Hospital Boston has developed Clickframes, an HTML-based wireframing technique, and AppSpecXML, a simple XML-based model for creating detailed specifications of web applications. With the accompanying suite of supporting tools, we can convert AppSpecXML into interactive design artifacts and production-quality Java-based prototypes. In this session, we’ll describe the challenges we've encountered developing research software, including production systems with industry partners, at a major teaching hospital over the last decade. We’ll demonstrate how to use the Clickframes technique with off-the-shelf wiki software to rapidly prototype an interactive website, which can be used in design review sessions, sprint/project planning, and client presentations. Then, we'll describe the AppSpecXML model and do a series of live demonstrations, going from rough site map to fully-functional web application (with form validation, AJAX, and user authentication out of the box) in a matter of minutes. We will share how we have incorporated this technique into our own design and agile development processes to our team’s (and our clients’) delight. Presenters: Jonathan Abbett & William Crawford

1. Agile Design & Development
with Clickframes
Jonathan Abbett · William Crawford
Informatics Solutions Group · Children’s Hospital Boston
May 26, 2009

2.  Background
 Show & Tell: Clickframes
 Agile & UX
 Show & Tell: AppSpecXML

3. Evolution of a “design process” for
research software development

4. In the beginning…
(and largely still pretty much true)

6. Throw-away prototypes
• Vivid, realistic
• Time-consuming, resistant to change, dangerous

7. Use cases
• Good at defining business process details
• Low user experience value
• Hard to map text to a mental model

8. Product requirements
• De-risks the business types, provides traceability
• No one reads them, fewer understand them, never get updated

9. Wireframes/Mockups
• Vivid, easy to create and modify
• No clear definition of interactivity

10. David · The Young Investigator
David has advanced from the post-doc stage to a
fellowship position at a Harvard-affiliated
hospital. While much of his work is still under the
direction of his lab’s primary investigator, he has
begun applying for his own funding, including
NIH K grants. Despite Harvard’s size and
resources, he feels isolated, but is willing to do
the legwork to find new collaborators that he
knows are out there. His lab lacks a grants
manager, so the application process gets pretty
overwhelming, especially with frequently
changing NIH rules.
Motivations
 The Science. David is passionate about his research
and enjoys the intellectual satisfaction he finds in his
work, even though there’s no way to predict when
he’ll have the breakthrough which gets him noticed
by his peers.
 Getting a faculty promotion. To remain in his field
long term, David must achieve a tenured faculty
position. He recognizes the role that data collection,
publications, and grants play in his career progress.
Behaviors
 Takes control of his work. David’s research is highly self-directed, and he knows he’s
responsible for his own success. David takes the “lead quarterback” role on collaborative
grant efforts.
 Looks out for networking opportunities. David attends a monthly meeting of young
researchers to learn about new research at the hospital and network with other
investigators like him.
 Willing to try new things. While social networking isn’t in David’s blood, he’s willing to
trying a new technology a few times if it offers relief from the difficulties of collaborative
research.
 How to find Dr. Right?Potential collaborators abound, but it’s hard for David to know who
will be reliable, honest, and available from generic lists of researchers.
 Lack of great examples or instructions. Research faculty are often unwilling to share old
applications and budgets that can be used as templates or examples of proper writing
style. Though he can find reference materials, they’re not filtered down enough to be
immediately useful.
 Grant matchmaking. David wonders, “Which grants from which agencies are most
appropriate for me? Are R03s worth the time? Why choose an R21 over an R01?”
Children’sHospital Boston·InformaticsSolutionsGroup
Age: 36
Affiliation: BIDMC
Field: Biosciences
Level: Junior Researcher
Degrees: MD, PhD
Obstacles
Comprehend
application
requirements
Frequently
140 pages of
specs
Too many kinds
of grants
NIH materials
Sponsored
projects office
Old grants from
colleagues
Grants
administrator
Identify potential
collaborators
Reach out to
collaborators
Don’t know
enough people
Can’t find right
people
No response
Delayed
response
Not enough time
Personal
network
Mentors
Publications
E-mail
Need
connections
Phone
In-person visits
Occasionally Occasionally
Tasks
Frequency
Issues
Support
Find Grants
Grant
Search Results
Grant Details
Find
Collaborators
Contact List
Collaborator
Search Results
Skill Finder
Offers
Skill Finder
Wanted

11. Hal Helms’s “Wireframes”
 Popularized in ColdFusion/FuseBox
community in 2001
 Simple web-based prototype
– Page description
– List of links to possible destinations

13.  Easy to understand
 Cheap and easy to build
 Great for remote review
 Can be created with customers
 Just engaging enough to generate feedback
 Not too detailed = no distractions
 Clearly not production software

14.  Confusing name
 Insufficient detail limits planning
 ColdFusion-centric tools
 Difficult to maintain for large sites
 Still no great transition to development!

15. Clickframes
 Form Inputs
 Actions & Outcomes
 Global Navigation
 General Functional Requirements

18. Clickframes in a Wiki
Demo 1

19. Agile & Interaction Design

20. Agile, briefly
 Rapid iterations
 Focus on demonstrable software
 Self-organizing, cross functional teams

21. Integrating Agile
 Support the feedback loops
 Design artifacts as scrum targets
Concept
Design
Build
Deploy
Test

22. David · The Young Investigator
David has advanced from the post-doc stage to a
fellowship position at a Harvard-affiliated
hospital. While much of his work is still under the
direction of his lab’s primary investigator, he has
begun applying for his own funding, including
NIH K grants. Despite Harvard’s size and
resources, he feels isolated, but is willing to do
the legwork to find new collaborators that he
knows are out there. His lab lacks a grants
manager, so the application process gets pretty
overwhelming, especially with frequently
changing NIH rules.
Motivations
 The Science. David is passionate about his research
and enjoys the intellectual satisfaction he finds in his
work, even though there’s no way to predict when
he’ll have the breakthrough which gets him noticed
by his peers.
 Getting a faculty promotion. To remain in his field
long term, David must achieve a tenured faculty
position. He recognizes the role that data collection,
publications, and grants play in his career progress.
Behaviors
 Takes control of his work. David’s research is highly self-directed, and he knows he’s
responsible for his own success. David takes the “lead quarterback” role on collaborative
grant efforts.
 Looks out for networking opportunities. David attends a monthly meeting of young
researchers to learn about new research at the hospital and network with other
investigators like him.
 Willing to try new things. While social networking isn’t in David’s blood, he’s willing to
trying a new technology a few times if it offers relief from the difficulties of collaborative
research.
 How to find Dr. Right?Potential collaborators abound, but it’s hard for David to know who
will be reliable, honest, and available from generic lists of researchers.
 Lack of great examples or instructions. Research faculty are often unwilling to share old
applications and budgets that can be used as templates or examples of proper writing
style. Though he can find reference materials, they’re not filtered down enough to be
immediately useful.
 Grant matchmaking. David wonders, “Which grants from which agencies are most
appropriate for me? Are R03s worth the time? Why choose an R21 over an R01?”
Children’sHospital Boston·InformaticsSolutionsGroup
Age: 36
Affiliation: BIDMC
Field: Biosciences
Level: Junior Researcher
Degrees: MD, PhD
Obstacles
Comprehend
application
requirements
Frequently
140 pages of
specs
Too many kinds
of grants
NIH materials
Sponsored
projects office
Old grants from
colleagues
Grants
administrator
Identify potential
collaborators
Reach out to
collaborators
Don’t know
enough people
Can’t find right
people
No response
Delayed
response
Not enough time
Personal
network
Mentors
Publications
E-mail
Need
connections
Phone
In-person visits
Occasionally Occasionally
Tasks
Frequency
Issues
Support
Find Grants
Grant
Search Results
Grant Details
Find
Collaborators
Contact List
Collaborator
Search Results
Skill Finder
Offers
Skill Finder
Wanted

23. AppSpecXML
 An XML model for defining clickframes
 Pages become <page>s
 Links become < link>s
 Actions become <action>s
 Outcomes become <outcome>s
 General requirements become <fact>s

24.  Authentication
 Messages & Content
 Page Parameters

25. AppSpec
XML
Clickframes
HTML
Software
Requirements
Selenium
Test Suites
Development
Estimates
Enterprise
Java Code
Flow
Visualizations

26. Generating an application
with AppSpecXML
Demo 2

27. Basic project strucure
<appspec defaultPage="login">
<title>Issue Tracker</title>
<description>
The Issue Tracker allows a team to record their progress
on collaborative tasks.
</description>
...
</appspec>

28. A very simple page
<page id="createAccount">
<title>Create An Account</title>
<description>
This page shows the user an account creation form.
Login not required.
</description>
</page>

29. Links
<link>
<title>View Issue</title>
<pageRef>viewIssue</pageRef>
</link>
<link>
<title>Open search engine</title>
<href>http://www.google.com</href>
</link>
<page id="viewIssue">

30. Link sets
<linkSet id="global" global="true">
<title>Site Navigation</title>
<link>
<title>Home</title>
<pageRef>login</pageRef>
</link>
<link>
<title>Privacy Policy</title>
<pageRef>privacy</pageRef>
</link>
...
</linkSet> <page>
<linkSetRef id="authenticated" />
</page>

31. Page parameters
<page id="displayTicket">
...
<param type="text">
<title>Ticket ID</title>
<description>
The unique identifier of the problem ticket to be
displayed on this page.
</description>
</param>
</page>
http://hostname/application/displayTicket?ticketId=*****

32. <validation type="required“
description="Please enter a username." />
<validation type="required“
description="Please enter a password." />
<validation type="length(min=6)“
description="Password must be at least 6 characters." />
<validation type="required“
description="Please repeat your password." />
Data input and validation
<input type="text">
<title>Username</title>
</input>
<input type="password">
<title>Password</title>
</input>
<input type="password">
<title>Repeat Password</title>
</input>

33. Actions and outcomes
<action>
<title>Create account</title>
<outcome>
<title>Account created</title>
<description>
User's account has been successfully created.
</description>
<pageRef>login</pageRef>
<message>Your account has been created.</message>
</outcome>
<outcome negative="true"> ... </outcome>
<outcome negative="true"> ... </outcome>
</action>

34. The default outcome
<appspec>
<outcome>
<title>Default Error Outcome</title>
<description>
Should an unexpected operational error occur during
any transition, this outcome will define the
destination (i.e. error) page.
</description>
<pageRef>error</pageRef>
</outcome>
</appspec>

35. Authentication
<page id="viewIssue" login-required="true">
<security>
<loginPage>
<pageRef>login</pageRef>
<username>username</username>
<password>password</password>
<action>login</action>
<successfulOutcome>loginSuccessful</successfulOutcome>
<failedOutcome>loginFailed</failedOutcome>
</loginPage>
</security>

36. Facts
<page id="discussion">
...
<fact>
PAGE shall display discussion as a series of topics.
</fact>
<fact>
Each topic may have zero or more replies, in a single
thread.
</fact>
<fact>
Each topic or reply shall be labeled with the author's
name and the date of submission.
</fact>
</page>

37. Thanks!
www.clickframes.org
Jon Abbett
jonathan.abbett@childrens.harvard.edu
Will Crawford
william.crawford@childrens.harvard.edu

38. Photo credits
 Slide 3
Professor: http://www.flickr.com/photos/meneldur/10307644/
Developer: http://www.flickr.com/photos/chealion/619682250/
 Slide 4
Patient: http://www.flickr.com/photos/mkmabus/2910025091/
Capitol: http://www.flickr.com/photos/jcolman/542404143/
 Slide 9
Developer: http://www.flickr.com/photos/chealion/619012405/