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 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?