Theme 4: Quality-In-Use
End-User Development
From human crafters to human factors to human actors and
back again:
bridging the design time - use time divide
Maceli, M., Atwood, M.E.
Enabling End User Development through Mashups:
Requirements, Abstractions and Innovation Toolkits
Cinzia Cappiello, Florian Daniel, Maristella Matera, Matteo Picozzi and
Michael Weiss
We are faced with an interesting question, what are
Mashups?
• Web 2.0 applications.
– High user involvement.
– Contents and functionality from open APIs or
reusable services.
– Users involved in content creation process.
– Known as web mashups.
• Web 2.0 applications.
– High user involvement.
– Contents and functionality from open APIs or
reusable services.
– Users involved in content creation process.
– Known as web mashups.
• There are also Enterprise Mashups. Enables
enterprise members to play with company’s
internal services.
This sounds interesting! How does Enterprise
Software look like?
With Enterprise Mashups, we grant the power
of designing the application to the End Users.
Even less skilled End Users could evolve from
passive receivers of innovation to actors
actively involved in the creation of innovation.
With Enterprise Mashups, we grant the power
of designing the application to the End Users.
Even less skilled End Users could evolve from
passive receivers of innovation to actors
actively involved in the creation of innovation.
Something like…
End User involvement in Mashup development
scenarios.
Two different approaches.
End User involvement in Mashup development
scenarios.
Two different approaches.
• Mashup tools can be used by expert developers to deliver applications
quickly. End users are not directly involved in the construction of such
Mashups but benefit from the shorter turn-around time for new
applications.
• Expert developers create services in a format that can be more easily
consumed and combined into Mashups by users who are not themselves
developers. (Most challenging, but also biggest pay-off)
Fundamental ingredients enabling the end user
composition of mashups.
• Domain-specific focus and terminology.
Important to use terminology which the End Users understand.
SOAP web services? Why, was the service dirty?
RESTful software architecture? Was the architecture tired?
• Abstraction from technical details.
Example:
class HelloWorldApp { public static void main(String[] args) {
System.out.println("Hello World!");} }
In the eyes of End Users, this looks the same as
('&%:9]!~}|z2Vxwv-,POqponl$Hjig%eB@@>}=<M:9wv6WsU2T|nm,jcL(I&%$#"`CB]V?Tx<uVtT`Rpo3NlF.Jh++FdbCBA@?]!~|4XzyTT43
Qsqq(Lnmkj"Fhg${z@>
This is HelloWorld in the language Malbolge.
The toolkit must hide the technical details.
• Continuous feedback.
End users typically have difficulties in understanding the difference between
design time and runtime.
• Composition support.
In order to achieve a tool that speaks the language of the user, it is also
important to aid those users that don’t speak the language of the tool.
Composition can be assisted or guided in multiple ways.
I am back!
Dashmash
Dashmash is an environment created by the authors of the paper.
It aims at an integration approach where a variety of different component
types and technologies, ranging from simple RSS feeds to complex SOAP
or RESTful Web services and UI components.
Questions:
•What is meant by 'design' and 'use' time?
•Can empowering users with the intent of bridging design and use time be a
cause of new challenges? If so, elaborate what are the challenges and to
whom...
•Can you come up with good examples of information systems (old or new)
that are successful in their design for use time in accordance with the
"Principles for Designing in Use"? How do they succeed?
Questions for you!
• Do you have any experience working with or creating Mashup toolkits?
• What kind of technical challenges do you think might occur when creating
a Mashup toolkit for End Users?
• Are there other challenges when involving End Users in the creation of the
application?