End User Development and Meta-Design: Foundations for Cultures of Participation

End User Development and Meta-Design: Foundations for Cultures of Participation

Gerhard Fischer (University of Colorado, USA)
Copyright: © 2010 |Pages: 31
DOI: 10.4018/joeuc.2010101901
OnDemand PDF Download:
No Current Special Offers


The first decade of the World Wide Web predominantly enforced a clear separation between designers and consumers. New technological developments, such as the participatory Web 2.0 architectures, have emerged to support social computing. These developments are the foundations for a fundamental shift from consumer cultures (specialized in producing finished goods) to cultures of participation (in which all people can participate actively in personally meaningful activities). End-user development and meta-design provide foundations for this fundamental transformation. They explore and support new approaches for the design, adoption, appropriation, adaptation, evolution, and sharing of artifacts by all participating stakeholders. They take into account that cultures of participation are not dictated by technology alone: they are the result of incremental shifts in human behavior and social organizations. The design, development, and assessment of five particular applications that contributed to the development of our theoretical framework are described and discussed.
Article Preview

1 Introduction

“Service-Oriented Architecture” (SOA) is a way to structure large and distributed software systems, where services communicate over a network with the client and with other services, and can be combined into composite applications. Increasingly, companies are providing their operations, which may previously have required installing a custom application, as services on the Web, so they can be accessed from a browser. Enterprise SOA (eSOA) is focused specifically on supporting business processes across an enterprise by reusing existing services. When an eSOA application is being planned and developed, many kinds of people are involved. For example, business process experts, who might be titled “Solution Architects,” are knowledgeable about the business context but may not necessarily be professional programmers, and are often responsible for identifying and selecting which services will be used. These users might therefore be classified as “end-user developers” (Wulf, Paterno, & Lieberman, 2006). Specifications they write might then be passed to professional programmers, who are responsible for writing code that uses the actual services. Therefore, the documentation and some of the tools must be accessible to both business process experts and professional programmers.

In a service-oriented architecture, code on the user’s machine communicates with a remote service using messages across the Internet. When using Web services, the communication is usually encoded in XML, and the format of the messages might be described using a WSDL (Web Services Description Language) file, which has been formalized by the World Wide Web Consortium (e.g., http://www.w3.org/TR/wsdl).

As part of the “Natural Programming Project” (Myers, Pane, & Ko, 2004), we are interested in a whole range of usability issues around programming. Recently, we have begun to focus on the usability of libraries, frameworks, toolkits, and other application programming interfaces (APIs) (Ellis, Stylos, & Myers, 2007; Stylos, Faulring, Yang, & Myers, 2008; Stylos & Myers, 2008). APIs are crucial since most of modern development of all kinds involves finding, understanding, and connecting pre-built items, from small library calls to large-scale components. Enterprise SOA APIs are particularly interesting to study, because they can be large and complex, and therefore expose interesting issues of scale, and because they often target a wide range of developers.

Our previous research has shown that programming using eSOA APIs is not simple when the APIs are providing access to powerful business functionality (Beaton, Jeong, Xie, Stylos, & Myers, 2008; Beaton, Myers, Stylos, Jeong, & Xie, 2008). Some barriers we identified included long names for services, different behaviors of services due to different business behavior, parameters of the services as hierarchies of objects with complex dependencies driven by internal, not exposed, business logic, and lack of example code (Beaton, Jeong, et al., 2008; Beaton, Myers, et al., 2008). The current paper presents the results of a user study of the usability of the online documentation provided by SAP for their enterprise SOA product.

In summary, our results are that when navigating eSOA API documentation, users with business backgrounds did better, and they experienced the most benefit from process component documentation. The process component documentation provides diagrams showing the architecture of an eSOA API in terms of service interfaces, the service operations they contain, and the business objects to which they are connected. All users avoided sites with visual designs that were inconsistent with their starting pages. Developers without business application experience were unfamiliar with business terminology and so they focused on searching and scanning for individual terms with limited success. Based on these results, we recommend that documentation provide flexible ways to navigate for different users with different backgrounds. This study also inspired new documentation tools, which we briefly summarize at the end of this paper.

Complete Article List

Search this Journal:
Volume 34: 3 Issues (2022): 2 Released, 1 Forthcoming
Volume 33: 6 Issues (2021)
Volume 32: 4 Issues (2020)
Volume 31: 4 Issues (2019)
Volume 30: 4 Issues (2018)
Volume 29: 4 Issues (2017)
Volume 28: 4 Issues (2016)
Volume 27: 4 Issues (2015)
Volume 26: 4 Issues (2014)
Volume 25: 4 Issues (2013)
Volume 24: 4 Issues (2012)
Volume 23: 4 Issues (2011)
Volume 22: 4 Issues (2010)
Volume 21: 4 Issues (2009)
Volume 20: 4 Issues (2008)
Volume 19: 4 Issues (2007)
Volume 18: 4 Issues (2006)
Volume 17: 4 Issues (2005)
Volume 16: 4 Issues (2004)
Volume 15: 4 Issues (2003)
Volume 14: 4 Issues (2002)
Volume 13: 4 Issues (2001)
Volume 12: 4 Issues (2000)
Volume 11: 4 Issues (1999)
Volume 10: 4 Issues (1998)
Volume 9: 4 Issues (1997)
Volume 8: 4 Issues (1996)
Volume 7: 4 Issues (1995)
Volume 6: 4 Issues (1994)
Volume 5: 4 Issues (1993)
Volume 4: 4 Issues (1992)
Volume 3: 4 Issues (1991)
Volume 2: 4 Issues (1990)
Volume 1: 3 Issues (1989)
View Complete Journal Contents Listing