Mouseion's meta-info tool is classified as a Web Application, meaning that it works directly in conjuntion with the web browser of the end user and communicates with a Mouseion database over standard Internet connections. Following is the development process required. Steps 3, 4, and 5 happen simultaneously, with different levels of focus put on the aspects of each step at specific times during the development process.

Objective: To document the projected development process for the creation and implementation of the Mouseion meta-info tool.

Step 1: Product Development Research
Research the options for the development and implementation of the Mouseion tool. Include advantages and disadvantages for each option. Supply recommendations and technical research for each option. Estimate costs and projected development time for each option.

Option 1: IE-Only Web Application
Option 2: Cross-Platform/Cross-Browser Web Application

Step 2: Functional Requirements Document
This is the document that described in detail what the requirements, functionality, and intended end-use of the Mouseion meta-info tool will do. It describes the process an end user will use to operate the web application, the end user requirements, the tool architecture, and any specific aspects the developer needs to know about. Close and careful communication with the client is a necessity so that the functionality required by Mouseion is clearly communicated. Development time and implementation of the specified solution varies based on the number of features and functionality requirements requested by the client. No development can begin until this document is written finalized and approved by both Mouseion and the development team.

Step 3: Develop Web Application Back End
This involves researching, planning, and developing the back end programming that enables the tool to communicate between the database and the browser via the middleware layer. Once a clear set of functional requirements has been decided upon by Mouseion, development of the back end can begin. This would include the database design and architecure, allowing for hooks into it from the web application and/or the browser client via the API. This solution must be scalable, allowing for rapid growth and data stability.

Option 1: IE-Only Web Application
The back-end for Option 1 is made up of several different components, some of them proprietary. The first component is the extensible toolbar option of the IE 4.x and 5.x web browser. This allows for the addition of certain functionality to the end user's web browser, including the read/write access to a custom database on a remote server. This can be implemented by accessing the Windows Scripting architecture which is integrated into the IE browser, primarily through hooks placed into the browser by the browser development team. The custom toolbar contains controls that an end user will use to retrieve information and control custom data sets within the main page of their web browser, as served by the Mousion web site and database.

Option 2: Cross-Platform/Cross-Browser Web Application
The back-end for Option 2 is 99% server-side. Very little needs to be done by the end user to make this tool work in their browser. Most of the back-end would be a web server set up to handle HTTP requests from the client-side web application. Since the web browser renders the web application on-the-fly using JavaScript and DHTML components (HTML, CSS, etc.), no download or complicated installation is required of the end user. Development for this option would be a process during which programmers work in JavaScript, HTML, and CSS to build a web application. This development process is simultaneous across the 4.x browser set. The user controls are drawn using DHTML components and graphics inside a pop-up browser window, and interaction is enabled using JavaScript functions and database queries.

Step 4: Develop Middleware
Middleware can be described as the set of code that resides between the back-end database and infrastructure and the front end HTML-based client. It handles the database queries, the data transmission, and and secure connections required. Another name for the middleware is the API or the Application Programming Interface. Every software application, including web applications, has an API, which enables other software and applications to communicate with it in a pre-determined manner. Most APIs are standardized and documented fairly well. One exception is some Microsoft software APIs, which often require licensing fees, contracts, and/or Non-Disclosure Agreements from developers before documentation is obtained. All options require a database. The kind of database should be chosen based on the technologies used for each option and also based on the kind of data being stored.

Option 1: IE-Only Web Application
The Middleware/API for Option 1 can be a combination of ASP, JSP, PHP, and/or ActiveX components. The middleware for an IE-only solution has a couple of different components. The first component is the VBScript scripting extension that ASP can use to access the toolbar (browser). The second component is the method ASP uses to make database queries. (I'm not sure how data is displayed in the toolbar, more research needed). All data shown in a web page is displayed in HTML, as parsed by ASP, JSP, or PHP.

Option 2: Cross-Platform/Cross-Browser Web Application
The middleware/API for Option 2 and 2a can be a combination of PHP, JSP, and/or XML. The middleware acts as a kind of template rendering system, which parses the requested data through a pre-determined HTML template architecture. It's important to understand that the middleware technology resides between the web application and the data, hence its name. All data shown by the web application is in HTML format, as rendered by JSP, PHP, or XML.

Step 5: Develop Front End UI
The user interface is typically made up of HTML, GIFs, JPGS, and CSS (collectively know as DHTML) with JavaScript tying it all together via the browser DOM (option 1). The front end can be described as the web application browser window that the user interacts with. For option 1, the IE-only solution, this would require some programming of the extensible IE toolbar as described on the MSDN web site. Complete implementation will vary based on the functional requirements outlined in Step 2. For option 2, the cross-browser web application, this step involves integrating the DHTML-based UI with the back end code. The UI cannot be developed until the functional requirements in Step 2 are completed.

Option 1: IE-Only Web Application
The UI for Option 1 is drawn by the toolbar application that an end user is required to download and install. Development starts with a Photoshop mock-up created by a graphic designer and interaction designer working together. Once the major interaction states of the toolbar are designed, the developers will begin to integrate the look and feel with the client-side web browser. Depending on the functionality required, and the options made available by IE's toolbar structure, the design is modified during integration.

Option 2: Cross-Platform/Cross-Browser Web Application
The UI for Option 2 is drawn completely by the client-side web browser, using DHTML components and JavaScript. Interaction is enabled by employing JavaScript, which accesses the DOM of the web browser. Development starts with a Photoshop mock-up created by a graphic designer and an interaction designer. Since the web application UI is drawn by the browser, making changes to the UI during the integration process is fairly simple. End-user cutomization (personalization) of the UI is also a simple process, since UI templating in Option 2 is available.

Step 6: User testing
User testing should be be part of the ongoing development process. This requires locating alpha and beta testers for the product, setting up a feedback machanism, and incorporating fixes and suggestions made by your users. It's a good idea to locate a range of users with different levels of experience with the Internet, from power users to newbies.

Option 1: IE-Only Web Application
User testing for Option 1 requires locating a group of users with Microsoft Windows 95, Windows 98, and Windows 2000 installed. These users must also have various versions of IE 4.x and 5.x installed, each with a different environment (i.e. differing sound cards, video cards, email clients, peripherals, etc.) -- anything that might affect the behavior of the web browser. Each beta tester should report their experiences with the tool, and provide bug reports, suggestions, and likes/dislikes. Every time a new version of the tool is ready for distribution, these users must download and install it, after un-installing the old version. Depending on the version if IE installed this may require a re-installation of the web browser.

Option 2: Cross-Platform/Cross-Browser Web Application
User testing for Option 2 requires locating a group of Internet users (located anywhere) with various operating systems (Win 95/98/2000) and 4.x or 5.x browsers installed and operating properly. It's important to note what browser and OS each user is using, and this information should be included in every bug report or anomaly sent in. Because this tool is driven by the server and rendered in the browser, no download or re-installtion is required by the beta testing group.