WISDOM - A Method Engineering Perspective
The WISDOM method is explained through an example, followed by its meta-model. A short literature study is included as well to provide context.
The WISDOM method was developed as a result of perceived difficulties with other website design models, which were regarded as academic tools. WISDOM differs from these models by focusing on the needs of industrial website design while steering clear of optimizing for any one application area (Cocquebert, Trentesaux, & Tahon, 2010). The authors also state that while frameworks and content management can help in the creation of the actual website, they do not, and cannot, offer assistance in the design of said website. This is where the WISDOM method steps in. The goal of WISDOM is to guide website designers through the design process. It does this by integrating experience and design solutions from previous project and designers and offering this for select parts of new projects. Its focus is on aiding in the creating of presence and catalog websites, as defined by Gnaho (2001). While the other types might be supported, this was not tested. The actual method itself consists of an iterative process going through several design phases, which may be updated based on findings further down the line. Every phase has the website specifications and results from the previous phase (as applicable) as its input, with the entire process eventually outputting an initial software architecture. A more visual explanation of this process can be found in Cocquebert et al. (2010). The authors were all attached to the University of Valenciennes at the time the paper was released. As far as can be told, the paper was mr. Cocquebert’s Master’s Thesis and was originally written in French in 2008. Mr. Trentesaux is a full professor at the University of Valenciennes. Information on mr. Tahon could not be verified as a Google search resulted in multiple results.
As part of the WISDOM method a tool was created to guide designers through the process described in the paper. The tool is currently hosted by the University of Valenciennes and accessible by the public; however, at the time of this writing the tool was in French. The following example is thus based on the theoretical model and results may differ from the results as presented by the tool. In this example, we will attempt to utilize the WISDOM method to create a presence website. Gnaho (2001) defines a presence website as "having the main objective of informing people through the internet about their existence". An example of this would be a conference or concert website. While it would be beneficial to describe a single step in more detail, perhaps even in sub-steps, the WISDOM model doesn’t provide this type of granularity, as each step is done using the knowledge base. Furthermore, the method was designed to be used with the simultaneously developed online tool to output the software architecture template. The tool was deemed unusable as services like Google Translate would not suffice for knowledge based work. As an example is still required, it will be provided as a step by step walkthrough of the WISDOM process using my personal knowledge base, which is not made explicit as it isn’t part of the process. The example provided below is visualized in figure 1, however as an actual example requires use of the tool it is not certain if the example is valid.
The first step is context definition. In this step we want to create a website for a conference on website design. This fits the category of a presence website. Our next step is Navigation design.
The next step is navigation design. Based on both the context and the knowledge base (KB) we specify the different needed sections of the website. In this case we want a Home Page, Conference information, a Route and Contact data. We subsequently head for Presentation design, but the sections found will be used in the menu item choice.
In the presentation design phase we design the basic layout of the site. WISDOM defines a "display area" which may contain several areas, such as "navigation area" or "news areas" (Cocquebert et al., 2010). Based on our experience and that offered through the KB we decide to use just a navigation area, for the menu, and a content area, for the content. We lay these out side by side, with the menu bar at the left.
We will now iterate through the various menu items and create content for each one. As we use an external service for the route we will select this in the implementation choice phase. After this we will iterate through the remaining menu items and add content in the content design phase for each one. Because this is a relatively simple site, we can map the sections specified in Navigation design directly to our menu.
For our route we chose to implement Google Maps. The specifics for this are added in this Implementation choice phase.
For all other items we add content in the Content design phase. The Home page will contain a description of the conference. The Conference section will go more in depth on the speakers and topics. The Route will provide details and routes to the venue. Contact data for the organizers will be provided in the Contact section.
After all iterations take place we have an initial software architecture.
* Figure 1: WISDOM Example
Process Deliverable Diagram
The Process Deliverable Diagram (Weerd, I. van de, Brinkkemper, S. 2008) below consists of two sides. The left side contains the sequential activities of the WISDOM method. The right side contains the deliverables of these activities. The deliverables and their relations have been directly derived from the WISDOM paper by Cocquebert et al. (2010) and are explained there in more detail. The Process Deliverable Diagram is followed by two tables which explain the activities and concepts respectively.
As we analyze the Process Deliverable Diagram in figure 1 we see that both a knowledge base and website specification must be created before the WISDOM method itself can start. The deliverables of these however are not connected to any other concept on the right side. This is because both the knowledge base and website specification are vital input for all subsequent steps, but not a part of the website model resulting from the WISDOM method. They are not connected to any activity because the Process Deliverable Diagram does not allow for concepts as input for activities.
Note that the Processes described in table 1 do not go into much depth. This is because the executions of the various activities are done using the knowledge base, which is not a part of this method.
* Figure 2: PDD WISDOM
| Create KB
|| A KNOWLEDGE BASE must be created or acquired. It must be based on the experience of web developers.
| Create WBS
|| A WEBSITE SPECIFICATION is needed before the process is started.
| Context Definition
|| This step specifies the website category in one of the four categories researched by Gnaho (2001). The specific category is inferred from the KB (Cocquebert et al., 2010).
| Navigation Design
|| In this step the navigation menu is designed, again based on the KB. It delivers the MENU.
| Presentation Design
|| Again heavily influenced by the KB, this step produces the actual presentation of the website in a TEMPLATE, which is divided into several “design AREAs” (Cocquebert et al., 2010). This step can be followed by Menu Item Choice in case the designer wants to handle content, or can be followed by Implementation Choice in case the designer wants to focus on the implementation of the MENU.
| Menu Item Choice
|| “This step permits the designer to select a menu item for which he/she wants to define the contents.” (Cocquebert et al., 2010) While an important step in the process, it is not a very knowledge heavy one.
| Content Design
|| Actual data is added to the site here. The designer can either use the website’s own data or use an external source (Cocquebert et al., 2010). In the model this results in a GENERAL ITEM, which can be either DATA or an external source. If the content uses an external source the next step is Implementation Choice. Menu Item Choice and Content Design (and optionally Implementation Choice) will iterate for all items in the MENU.
| Implementation Choice
|| If this is the fifth step in the model, this step focuses on the specific implementation of the menu (for instance as drop-down or as a frame). In this case it is followed by Menu Item Choice. It may also be an optional last step in the model if content is pulled from an external source. In this case this step is preceded by Content Design (Cocquebert et al., 2010).
* Table 1: Activity Table
| KNOWLEDGE BASE
|| The KNOWLEDGE BASE contains and supplies the gathered experience from knowledgeable web designers on good practice (Cocquebert et al., 2010).
| WEBSITE SPECIFICATION
|| The WEBSITE SPECIFICATION specifies the purpose and audience of the WEBSITE (Cocquebert et al., 2010).
|| The WEBSITE is the resulting initial software architecture (Cocquebert et al., 2010).
|| The MENU consists of various GENERAL ITEMS that direct users to DATA, which can either be internal DATA or external services (which are GENERAL ITEMs). DATA itself is also a GENERAL ITEM (Cocquebert et al., 2010).
| WEB PAGE
|| A WEB PAGE is laid out according to a TEMPLATE and displays GENERAL ITEMs (Cocquebert et al., 2010).
|| A TEMPLATE is a collection of how its various AREAs are laid out (Cocquebert et al., 2010).
|| AREA’s define how DATA is displayed (Cocquebert et al., 2010).
|| DATA can be either internal or it can contain external DATA in which case it loads this from external sources. In either case DATA still consists of one or more GENERAL ITEMs (Cocquebert et al., 2010).
|| This describes the IMPLEMENTATION of various aspects of the WEBSITE. This can include the MENU, internal DATA (such as a forum) or external DATA (for instance a Google Maps applet) (Cocquebert et al., 2010).
| GENERAL ITEM
|| Everything on the WEBSITE is a GENERAL ITEM. GENERAL ITEMs may contain DATA (Cocquebert et al., 2010).
* Table 2: Concept Table
This literature section will consist of three parts. In part one we will discuss several of the design methods mentioned in the WISDOM paper, which were not discussed. After this several papers will be discussed which deal with website quality research. Finally, as the Knowledge Base is a critical part of WISDOM, we will briefly discuss the difficulties in creating this. The WISDOM paper, in its related work section, mentions several design methodologies, amongst which are RRM (Isakowitz, Stohr, & Balasubramanian, 1995), OOHDM (Schwabe, Rossi, & Barbosa, 1996) and WSDM (De Troyer & Leune, 1998). RMM concerns itself with efficient hypermedia design, but was simply not designed for the current state of the web, a recurring theme in all the mentioned methodologies. OOHDM, while purely a design methodology, uses a navigation based design but does not formally require the context of the website to be specified. This is mainly caused by its age; there was simply not a lot of versatility in how sites were made. WSDM (no relation to WISDOM) focuses on user-centric design and is optimized for what they call kiosk websites, which are largely analogous to Gnaho's presence websites. It does not support dynamic web 2.0 sites. For methods mentioned we can simply state that they were developed for a different web than the one designers face nowadays.
Gehrke & Turban (1999) discuss the various determinants for site success in their paper. While the paper is old, several of the lessons learned still apply. The main success factors are identified as speed, security, business content, navigation efficiency and the marketing focus. While WISDOM is not concerned with the technical aspects of a site, it does focus on optimizing both the content en navigation efficiency. A paper by Zhang (2000) separates the success design factors as being either hygiene based (functionality) and motivator based (user satisfaction). Website hygiene is largely code based and thus falls out of the scope of WISDOM, it does however aim to create a site with optimized motivators. In the WISDOM method, the website hygiene only starts playing a role after the initial architecture is delivered. Finally, Rosen (2004) attempts to create a website preference scale (WSPS) based on a four-scale system involving coherence, complexity, legibility and mystery. WISDOM provides in complexity and coherence, while legibility is mainly the content places on the final site. Mystery turned out not to be a major factor in their research.
Finally, with the Knowledge Base being such a critical component, some papers were consulted on the difficulties of creating such an entity. Swart & Kinnie (2003) and Haldin-Herrgard (2000) discuss several obstacles encountered with creating knowledge bases. Swart & Kinnie (2003) focus mainly on the barriers in promoting knowledge sharing in companies, with WISDOM even more at a disadvantage because its knowledge base should come from web designers in different companies. The paper by Haldin-Herrgard (2000) concerns the difficulties in creating explicit knowledge from tacit knowledge, and with WISDOM acknowledging that it's Knowledge Base is created from experience, making this a very relevant area which is not discussed in the original WISDOM paper.
Cocquebert, E., Trentesaux, D., & Tahon, C. (2010). WISDOM: A website design method based on reusing design and software solutions. Information and Software Technology, 52
(12), 1272-1285. Elsevier B.V. doi:10.1016/j.infsof.2010.07.002
De Troyer, O., & Leune, C. J. (1998). WSDM: a user centered design method for Web sites. Computer Networks and ISDN Systems, 30
(1-7), 85–94. Elsevier. Retrieved from http://www.sciencedirect.com/science/article/pii/S0169755298000427
Gehrke, D., & Turban, E. (1999). Determinants of successful website design: relative importance and recommendations for effectiveness. System Sciences, 1999. HICSS-32. Proceedings of the 32nd Annual Hawaii International Conference on
(Vol. 00, p. 8–pp). IEEE. Retrieved from http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=772943
Gnaho, C. (2001). Web-Based Information Systems Development-A User Centered Engineering Approach. Web Engineering
, 105-118. Retrieved from http://www.springerlink.com/index/75YKQCL6YUR7XR46.pdf
Haldin-Herrgard, T. (2000). Difficulties in diffusion of tacit knowledge in organizations. Journal of Intellectual capital, 1
(4), 357-365. Retrieved from http://www.emeraldinsight.com/journals.htm?articleid=883915&show=abstract
Isakowitz, T., Stohr, E. A., & Balasubramanian, P. (1995). RMM: a methodology for structured hypermedia design. Communications of the ACM, 38
(8), 34–44. ACM. Retrieved from http://dl.acm.org/citation.cfm?id=208346
Rosen, D. (2004). Website design: Viewing the web as a cognitive landscape. Journal of Business Research, 57
(7), 787-794. doi:10.1016/S0148-2963(02)00353-3
Schwabe, D., Rossi, G., & Barbosa, S. D. J. (1996). Systematic hypermedia application design with OOHDM. Proceedings of the the seventh ACM conference on Hypertext
(pp. 116–128). ACM. Retrieved from http://dl.acm.org/citation.cfm?id=234840
Swart, J., & Kinnie, N. (2003). Sharing knowledge in knowledge-intensive firms. Human Resource Management Journal, 13
(2), 60–75. Wiley Online Library. Retrieved from http://onlinelibrary.wiley.com/doi/10.1111/j.1748-8583.2003.tb00091.x/abstract
Weerd, I. van de, Brinkkemper, S. (2008). Meta-modeling for situational analysis and design methods. In M.R. Syed and S.N. Syed (Eds.), Handbook of Research on Modern Systems Analysis and Design Technologies and Applications
, 38-58. Hershey: Idea Group Publishing.
Zhang, P. (2000). Satisfiers and dissatisfiers: A two‐factor model for website design and evaluation. Journal of the American society for Information Science, 51
(14), 1253-1268. Retrieved from http://onlinelibrary.wiley.com/doi/10.1002/1097-4571(2000)9999:9999%3C::AID-ASI1039%3E3.0.CO;2-O/full
- 17 Feb 2012