Development of DDS: Predominant Ideology - Case Study Example

Development of DDS: Predominant Ideology DDS, in its predominant ideology, was meant to be designed as a virtual (digital) city that would promote public interaction within the community as well as with the politicians. This was to be achieved through providing them with free and easy-to-use access to the internet. DDS aimed to achieve democratic incentives through creation of a “sense of community” among people and inducing political discussions based on information sharing by the Government. The city was to be the first of its kind in Netherlands and its initial test phase was to be carried out in Amsterdam. The idea was inspired by Freenets in U.S. and the initial software was also purchased from a Freenet in U.S. The major objective behind the creation of the technology was to make it accessible to “everybody”. This, however, required the technology and its design to be extremely user-friendly in order to accommodate computer illiterates as well. This very need induced and highlighted the high level of user consideration in system design. Serious efforts were made towards achievement of maximum public accessibility. Public access Terminals were installed in a variety of public locations to make the city accessible to the masses and “everybody”. Initial interface of the system was DOS based and a helpdesk was also setup to provide telephonic support to the users. City metaphor was used in this first interface to further enhance easy usage. This was later called DDS 1.0 when next interfaces were implemented. However, the initiators and policy makers played an important role in constructing user images and representations that were central to the design of this system. They, idealistically, created a varied set of user representations that were rather abstract in definition of “everybody”. This definition was central to the teams of designers that subsequently worked on DDS 2.0 and DDS 3.0. Although the team behind DDS aimed to make this city accessible to everybody, but the end-users were not central to the technological choices made during its design phase. For a start, the designers decided to add a number of functionalities in the interface by changing the original software because of what they called “not invented here syndrome.” They incorporated six different software packages into the original software to achieve these additional functionalities, and, consequently, made the whole interface far more complicated to use. Further, the initiators of DDS got motivated by innovation rather than user-friendliness of the technology during the design of DDS 2.0. The key concepts of this phase turned into “experimenting” and “turning Amsterdam into innovative city”. They became interested in making this city a trendsetter for further development of digital cities elsewhere in Netherlands. This shift in orientation from original objectives had drastic impact on the design of this second interface. Graphic interface was introduced in place of textual interface to include the additional functionalities. The new interface posed serious problems to accessibility of the system. To use this new interface, the users required considerable amount of hardware and a special software. The accessibility of DDS was further hampered and reduced by gradual removal of public access terminals in view of high maintenance costs and complaints from the institutions where they were placed regarding the kind of people they attracted. During the period, the DDS team supported the action on the grounds that old public terminals were damaging the innovative and developmental image of DDS. This shows the shift in goals from democratic and public-oriented to innovative and more commercial. Thus, DDS became accessible to only those who owned a computer and requisite technology package. This major change in ideology and relevant goals came, primarily, through a miscalculation on the part of designers. Rather than allowing end-users to participate in and guide the design process of this public city, they assumed to base the user preferences on their own. Thus, involuntarily, putting implicit representation of end-users into system design and relying on their expert visions and “I-Methodology”. Moreover, no formal tests were carried out involving the end-users (current or potential) during the design of DDS 1.0 and DDS 2.0. And only a small-scale test involving a group only 11 members was carried out at a late design stage of DDS 3.0, which only contributed to numerous changes in buttons and colors on the interface. This truly suggests the root cause of exclusion of explicit user representation during the different phases of DDS development. Trial and error method of learning for the users was introduced in DDS 3.0, which was again not inline with the concept of allowing easy access to computer illiterates. The designers ended up designing a system that matched their own preferences, capabilities, and learning style. Moreover, the authors of the article contend that in addition to taking user perspective into account, user identity (gender) must also be considered in system design processes. They contend that ICT, predominantly, prioritizes male users only. The same was the case in DDS, where design teams included lesser number of female members and no explicit representation of female users was made and incorporated in its design. The situation gets more inconvenient for females users when considered the fact that computer illiterates are mostly male users. At this stage, if the initiators and policy makers of DDS wish to fall back to their initial objective of making DDS accessible to “everybody”, certain social, technical, political, and strategic concerns have to be addressed by them. From social, and foremost, perspective, the most important factor in accessibility for everyone is the affordability for everyone. The users can only access a technology when it is affordable for them. The innovative technology of DDS 2.0 and 3.0 requires set up costs that are not feasible for everyone to bear. The overwhelming initial response to DDS is suggestive that the users are inclined to this new concept of virtual city, but its success can only be marked by its accessibility. Alternatively, if the policy makers decide to keep current graphical interface in place for further development, it would require an additional number of public terminals to be installed at such places where the issue of social class differences can be effectively addressed. One idea behind DDS was providing easy access to the Internet (considered the “future mode of communication”). The concept is new to the people of Amsterdam and should be implemented through easy-to-use technology. Innovation in technical aspect of the system must be focused on combining ease-for-user with ability of the system to bear heavy traffic loads rather than designing complicated back-end and front-end of the system. The more complex the integration of these ends gets the more complicated it is to keep DDS simple for everyone. The design teams and initiators of the system have already failed to realize and acknowledge the significance of explicit user representation. Although, the City Council of Amsterdam initiated the process with the intention of gaining democratic incentives, it now needs to include social and technical incentives in its core objectives. The funders of DDS seem to have overlooked the need for devising the right set of measures to control and monitor the system development process. If the council still wants to fall back to its original objective of providing access to all, then it needs to commit itself to the high level of associated costs and devise a comprehensive plan for DDS implementation. It is imperative at this stage for the funders to estimate the associated costs to the whole project and related actions and commit itself to the required budget before moving ahead with it. Strategically, the council and initiators of DDS need to realize the magnitude of this task that entails involving everyone in the system. This requires addressing the issues of carrying out formal testing with end-users (involves costs and time investment), educating the people on DDS (already being done through helpdesk, but it entails recurring costs), making the system and technology easy for all and affordable for most (this may possibly require complete or partial roll-back of the last two updates of DDS), and keeping public access terminals installed at public locations (maintenance costs and discrimination among social classes are associated). It is critical to the future success of DDS to formally consider all the possible design approaches for its development. The decision on the suitable system approach can serve to address the needs of all the stakeholders involved. But right planning for further development can only be instrumental if the needs and concerns of user group are correctly identified and incorporated in design process. There are a number of alternatives available to the policy makers and initiators of DDS to choose from for a more formal proceeding on DDS development to achieve its original objective of accessibility to everyone. However, critical evaluation of these alternatives is mandatory. These are discussed hereunder. One is the “specifications-oriented approach”. Selby describes the approach as “Specifying. Develop a requirements specification for the product. Develop a design specification to implement the requirements. Develop the code to implement the design. Again, rework the resulting product as necessary.” (320) Analyzing it in the perspective of DDS development for future, it becomes clear that this may not work towards the desired goal of the system. With the presence of variety among the user classes and their related accessibility concerns, it is not feasible to draw on an extensive and (importantly) exhaustive set of requirements of the system. Therefore, inefficient requirements specification would again lead to ineffective design and implementation that would only give rise to repetitive rework on a massive scale. Defining the accurate requirements of a system is the core of this approach, but cannot be achieved in the case of DDS. Another approach for system development is “prototyping”. Selby explains it as “Prototyping. Build prototype versions of parts of the product. Exercise the prototype parts to determine how best to implement the operational product. Proceed to build the operational product, and again rework it as necessary.” (320) This approach, in the context of DDS at current stage, would bear great operational and conversion costs for the funders. The system already has gone a long way in the wrong direction with the use of innovation in its technology that has proved inaccessible for a large number of the end-users. Moreover, keeping the diversity of user groups and their preferences in view, a considerable amount of rework is expected to be carried out on the prototypes that would also increase the number of these interim prototypes. However, this approach may be feasible to follow if the whole system is broken into parts for modular development and each module caters to a singular user group from the community, thus altering the approach to “cooperative prototyping”. Participatory approach towards system development is more central to user involvement in the process. Jacko discusses this approach to system design as, “Participatory design (PD) is a set of theories, practices, and studies related to end users as full participants in activities leading to software and hardware computer products and computer-based activities.” (1052) Evaluation of this approach for further development of DDS indicates its compatibility to the basic objective of the policy makers. If a system is aimed to be accessible to everybody then everyone must be involved in its design and development process as well. This end-user involvement, as explained by Jacko above, is not restricted only to the front-end or interface of the system, but it also defines the technological choices that make the backbone of DDS. User-oriented approach is recommendable for DDS at this stage, as it can effectively cater to the diversity among the users and the differences in their levels of adaptability to the system. However, the formal inclusion of these user groups in the development process needs high level of professional maturity on the part of DDS policy makers. Therefore, this author recommends Participatory approach for DDS to follow for its further development. This approach effectively caters to the previous and current issue of implicit user representation in system design. The system, at this stage, is off-target by a huge margin and requires radical changes. The user-central approach yields two most significant aspects of a social system that is intended to operate on such a massive scale, “Political or ethical rationale. User involvement is justified, because users should have a right to influence decisions affecting their work practice. Pragmatic rationale (efficiency, effectiveness, and quality). User involvement is justified, because it leads to more useable systems, and so to people working more efficiently and effectively. Commitment and “buy-in” rationale. User involvement in design is justified, because it leads to greater commitment to the final design. Users are able to develop realistic expectations for the design and so reduce their resistance to change.” (McDonald, 137) These rationales, discussed in context of DDS, imply that the end users of the virtual city must be able to define the technological orientation of the system that they are eventually going to use. Such an involvement at this stage of the system would ensure the maximum level of its usage, efficiency, and effectiveness for the users. This would also allow the system give a personalized impression to the users who can relate to the technology and not take it as an alien innovation. A major component for further development of DDS, that this author recommends, is the breakup of the system for modular development. Each module caters to each social segment from the community and each segment defines its own set of requirements and limitations in context of the system. This modular functionality of the system can effectively incorporate the different levels of technical competencies and social interests of virtually every citizen of the digital city. Separate teams must be defined for each module that can work closely at the backend on system integration on incremental levels. Each team must have one (or more depending on the size of its user group) Ethnographer who can work on developing in-depth understanding of the activities that the users would perform in the system and the meaning of those activities and/or related system tasks to those users. These ethnographers would work as a liaison between the users and the design team, translating user requirements into design schematics for incorporation. Thus, each team comprises of users, ethnographers, and designers, where ethnographers work towards presenting real-world representations to the designers; therefore, the three components working collectively towards designing the system. Another important objective that can be achieved through this approach is educating the end-users on the system. The users would learn through information and feedback sharing with their teams and can logically expect the practical end result of their involvement in the system. This way, the issue of system alienation and its technological complexity can be averted to some extent. McDonald also suggests that “An important aspect of PD is the opportunity it provides for the mutual education of various stakeholders (for example, users and developers teaching one another about their work).” (141). This way, the designers also get to learn what they have to design and for what reasons. As it is imperative to start a project with a clear understanding to the appropriate system development approach, DDS has failed in midway to induce the sense of right direction for its development. Fundamental principles of system development require a clear sense of direction before a system is started, a straight follow up plan drawn on that direction, and finally delivery of an efficient and effective system based on the objectives. The project was started off with a user-central objective and implicitly changed its course to innovative ideology. Participatory approach would have been an appropriate choice to follow for achieving its initial goal. Therefore, at such late stage of its development, this author suggests that one variant of PD method can most suitably take up and define further development process for DDS. This method is called “Cooperative Experimental System Development (CESD)”. “…the CESD approach is characterized by its focus on active user involvement throughout the entire development process; prototyping experiments closely coupled to work situations and use scenarios; transforming results from early cooperative analysis/design to targeted object-oriented design, specification, and realization; and design for tailorability.” (Kyng, 201) This signifies the importance of keeping the users in perspective throughout the system development life cycle. This becomes important in case of DDS for further progress, as it has previously failed to incorporate user stated requirements and explicit user representations through active user representations. Further development of this virtual city now heavily depends on the technology and activities-specific input from its end-users. “In system development, particularly in cooperative and experimental system development, we argue that it is necessary to separate analytically the abstract concerns, for example, analysis, design, and realization, from concrete activities and techniques. Thus, we introduce a CESD model that provides a framework for handling this separation and at the same time makes it possible to identify and discuss the rich variety of relationships among concrete activities and the main concerns.” (Kyng, 201) This logical and physical segregation of activities from “abstract concerns” highlight the individuality of roles that the developers and end-users are anticipated to play during the development of a system. Logical precision and practical accessibility of a system can only be measured in terms of the clarity of its design specifications, and this clarity can be improved through participation of real life users of the system. CSED is important in current scenario, as the restructuring of DDS entails a longer time period and user involvement throughout this period of development is instrumental to its eventual success. This involves the paradigm shift from “what designers/developers think that user wants” to “what user wants”. Systems have the characteristic of dealing with complex human activities and the meaning of these activities can be well explained by the humans who deal with them. However, on a more practical level, the system is expected to experience methodology pluralism in its course to further development. The system would keep evolving with every new phase of its implementation as newer sets of user requirements are defined in more variable contexts and practical scenarios. Thus, inducing rework on the product and shaping the whole process as a workable mix of Participatory approach and Prototyping. Having already discussed the poor state of DDS in terms of user-orientation and its constraints in addressing end user issues, this author feels that Soft Systems methodology is of special consideration in addressing the current and future problem situations in the system. “ When hard systems methodologies are applied to social problems, some failures may occur. The analysis of those failures has led to the conclusion that in social systems the subjective interpretations of a problematic situation are often more important than the discussion whether or not the problem is an objective problem in real world.” (Strijbos, 156) This methodology can directly refer to the issue of technological crossroads that DDS faces right now; as the current interface and underlying technology pose accessibility restrictions to the end users and a roll back to the previous versions has associated high costs involved. Soft systems approach can help in addressing such future concerns and problematic areas. As has already been discussed, the participation and representation of each social group can address the core issues of development process for DDS. These groups broadly categorize into computer illiterates and computer users. Further breakup of these can be carried out to individually include females, housewives, pensioners, and the public class from lower status quo. These would mostly include people with no computer skills and who need formal training on using this system in particular. Another group that is of special interest in the development of DDS is of computer users who do not own a computer. Provision of access to all such people is an important factor in achieving the original goal of DDS. “The use of term “design” should not be understood as “being in control”. Designers may have intentions and plans, but the results are not always as intended, and there may be unplanned effects.” (Kyng, 81) Conclusively, it is logical to realize that designs can fail for a number of reasons but more important is the commitment towards making it right by adapting appropriate measures, countering the errors incurred, and incorporating the true set of elements to reshape the system. Works Cited Ed. Selby, Richard W. Software Engineering: Barry Bohem’s Lifetime Contributions to Software Development, Management, and Research. USA: Wiley-IEEE, 2007. McDonald, Sharon, et al. People & Computers XIV. UK: Springer, 2000. Strijbos, S., and Andrew Basden. In Search of an Integrative Vision for Technology. UK: Springer, 2006. Ed. Jacko, Julie A., and Andrew Sears. The Human-Computer Interaction Handbook. Lawrence Erlbaum Associates, 2003. Kyng, Morten, and Lars Mathiassen. Computers And Design In Context. USA: The MIT Press, 1997. Read More