Enhancing effective implementation and adoption of web information system applications based on adoption theories
Stephen Hansen · 2006
Interface Design Abstract interface objects, responses to external events, interface transformations Abstract Data Views; Configuration Diagrams; ADVCharts; Design Patterns Mapping between navigation and perceptible objects Model perceptible objects, implementing chosen metaphors. Describe interface for navigational objects. Define lay-out of interface objects Implementation Running application Those supported by the target environment Those provided by the target environment Performance, completeness The requirement phase as shown in Figure 3-17, starts with identifying the users and their roles. Next, in the scenario phase, each user describes either verbally or in text their these roles. From the scenarios, use cases are constructed as in standard UML. OOHDM introduces a new construct the User Interaction Diagram (UID), not part of UML, that graphically represents the interaction between the user and the application. UIDs are constructed from the use cases and only describe the exchange of information between the user and the application, without considering specific user interface aspects. Chapter 3 Web Environment: A Review page 148 148 Identification of roles & tasks Specification of scenarios Specification of use cases Specification of user interaction diagrams Validation of use cases and user interaction diagrams Requirements activity Figure 3-17. The requirements activity addition to the OOHDM, adapted from (Guell, Schwabe, and Vilain, 2000) Following the requirements activity, OOHDM moves though conceptual design, navigational design, abstract interface design and implementation activities without specifying any further user dialogue. In relation to the adoption criteria, OOHDM formally, only provides interactions with the user in the requirement phase. Possible interactions of OOHDM and the Rogers adoption criteria are given in Table 3-19. Table 3-19. Summary of possible relationships to the adoption criteria of chapter 2 for OOHDM The OOHDM methodology Possible interactions with the Rogers adoption criteria Adoption Modeling Parameter Comments regarding this methodology Perceived Attributes of the Innovation to the intended user(s) ie, relative advantage, compatibility, complexity, trialability, observability Not directly addressed but possible through the requirements determination and navigation-user interaction phases Social System ie, norms, leadership, change agents, change agency/agencies, aides Not addressed Adopter Categories ie, innovators, early adopters, early majority, late majority, laggards Only addressed if identified Communication Channels ie, interpersonal, media, other Not directly addressed Chapter 3 Web Environment: A Review page 149 149 Types of Innovation Decision ie, optional, collective, authority, contingent innovation-decisions Not directly addressed Innovation -Decision Process ie, learn about the innovation, be persuaded as to the merits, of the innovation, decide to adopt the innovation, implement the innovation, confirm (reaffirm or reject) the decision to adopt the innovation Not directly addressed Institution/organisation ie, agenda setting, matching, redefining, clarifying, routinising Not directly addressed 3.5.3.1.3 Scenario-based object -oriented hypermedia design methodology (SOHMD ) 1999 SOHDM was developed after the early OOHDM, and addressed the requirements gathering phase lacking at that time in OOHDM. It defines six phases, domain analysis, object modeling, view design, navigation design, implementation design, and construction (Lee and Yoo, 1999). All these can map fairly well onto the fully developed OOHDM as presented in Table 3-18. SOHDM makes use of scenarios to capture user requirements. Apart from specifying a domain analysis which would result in the identification of stakeholders and users, Lee and Yoo do not develop any particular methodology to conduct scenarios. Scenario activity charts (SACs) are constructed from the scenarios. SACs are a graphical notation based on a flow chart notation to describe the interaction of “actors” with the objects from the system. The scenarios through the SACs are formed into objects in the form of CRC cards (Class, Responsibilities, and Collaborators). These define a class and list the attributes, responsibilities, collaborators, components and associations. From these objects the rest of the object modelling is undertaken a process similar to OOHDM is undertaken. Chapter 3 Web Environment: A Review page 150 150 In terms of possible interactions to adoption criteria, SOHDM does not add any additional possibilities than OOHDM. In the updated OOHDM model the use of scenarios has been added to strengthen the requirement phase. In this thesis SOHDM will be considered as part of the OOHDM umbrella.