Objective: The Functional Specification document details the client's requirements for the application. The client often provides a functional summary, the rest of the requirements must be established by Alphanumerica, in co-operation with the client, and documented for client approval. The Functional Specification formalizes the requirements of the Web application and serves as a functional description of the contract between Mouseion and the organization they choose to develop the SiteSherpa Web application. It also ensures that those two (2) parties have a common vision for the application.
Accessing the database: The Web application needs constant and regular access to the Mouseion database, pulling data and displaying it in various formats. This database needs to be structured in a way that it can scale with the traffic and numerous data requests the SiteSherpa tool will demand of it.
User Interface: The user interface of the Web application is important, in that it must do many things simultaneously. The maximum amount of information must be displayed without losing the end user in a mass of information glut. At the same time, it must re-enforce the Mouseion and SiteSherpa brands. The over-riding goal of the user interface is to channel specific information provided by Mouseion to the end user.
Product Audience: The target audience for Mouseion's SiteSherpa Web application tool are experienced Internet users from 20-35 years of age who are frustrated by their lack of ability to find the information they are looking for, even on sites they are familiar with.
User Interface: The user interface consists of the sidebar add-on that is installed and activated by the end user. A general idea of the anticipated design can be derived from the SiteSherpa demo created by Alphanumerica.
Interaction States: The SiteSherpa sidebar has three (3) states: fully open, fully closed, and retracted. The Web app is opened and closed by the user using a small widget located towards the top of the UI. Upon first-use, the default state for the Web app is open. In the open state, SiteSherpa will perform all relevant database queries and user-tracking functions. If a user closes/retracts the Web app, this preference will be remembered for future use.
When the sidebar is fully closed, the Web application is considered turned off, and no database queries or other data connectivity is to take place. This includes user tracking, logging, and other data that is collected by Mouseion when the user is using SiteSherpa. The sidebar would be completely out-of-sight until the user chose to launch it via the browser menu (View-Explorer Bar) or a toolbar button.
When retracted, SiteSherpa will appear as a narrow bar down the left-hand side of the browser. Even when the Web app has been retracted by the user, it is possible to continue to track the user's clicks, paths, and actions. When the Web app is in a closed/retracted state, it is not possible to indicate if there is related info for a site without making database queries. Mouseion has a choice to continue or cease collecting such data in the retracted state. If privacy concerns are an issue, the retracted state can act similar to the closed state.
Search: The SiteSherpa tool will provide a small search interface that allows the end user to search many public search engines from one location in the SiteSherpa UI. This is an add-on functionality, not something that needs to be developed by the implementation team. Some work will be required in creating the search module that allows for dynamic searching across numerous sites.
Tabs: The tab metaphor is being used in the SiteSherpa UI as a way to conserve screen real estate. Every function should be assigned under particular tab, and the layout should be organized in a way that is componentized and modular. This is to allow for the future possibility of syndicating the SiteSherpa/Mouseion data, and presenting it in a UI chunk that looks and feels the same as the tool. The specific functions of each tab are noted by the labeling of the UI tabs, widgets, and information layout.
Advertising: There will be a small portion of the UI (screen real estate) that is set aside for advertising. The advertising should be non-obtrusive, non-graphical, and mostly text-based. The idea is to let the advertising complement the content, not overpower it.
Log in/Log Out: This is relatively straightforward. Once a user logs in, a cookie will be set on their hard drive which automatically logs them in whenever SiteSherpa is open. The tool itself will display the log in state the user is in. It is possible for log in cookies to time out after a specified amount of time (one month, one year, etc.), requiring the user to log back in during a revisit. Considering Mouseion's target audience for SiteSherpa, Alphanumerica recommends that cookies never time out. If at some time Mouseion determines that their tool will be used on public Internet terminals at libraries and other public locations, they may want to provide instructions for the system administrators of those machines to set an alternate cookie that times out after a very short amount of time (30 minutes).
Main Window: The contents of the main window depends on which tab (section) a user has chosen. As demonstrated in the demo created by Alphanumerica, the Overview section of the main Info tab is the default. When a user opens SiteSherpa from a closed state, the tool will return to the default tab. If the user reopens the tool from a retracted state, whatever tab they had previously been viewing is displayed. While the tabs will remain the same, the data displayed in the tool will be refreshed to represent the Web site the user is currently viewing.
If a Web site does not have any metadata in the Mouseion database, a default static data screen will be displayed in the main window area.
Related Links: The bottom portion of the SiteSherpa sidebar contains a list of related site links. Those sites are retrieved by a database query that chooses all of the Sites such that the categoryId is equal to that of the Site currently being viewed AND the rating of the Site is "recommended" (indicated by a 1).
Launching: Launching the Web app can be done in three (3) different ways. When the tool is first installed or when it is in the closed state, it can be launched via the browser menu (View-Explorer Bar) or by clicking a toolbar button installed by the user during the download and installation process. When the tool is in the retracted state, the user can click the "expand" widget located at the top of the retracted sidebar. Each of these methods will expand/open the Web app in the left browser sidebar and allow for data queries and tracking.
User Customization: UI customization by the end user is limited due to the specific nature of the IE browser extension toolkit functionality. Users will be able to choose the fields they would like to appear in each tabbed section. This will be achieved through use of a customization page on the SiteSherpa Web site. Due to the complexity involved in delivering customizable user interfaces and given the development timeframe required, Alphanumerica suggests that implementation of this non-mission-critical feature should be postponed until the second version of SiteSherpa.
Partner UI Customization: Given the modularity of the UI design, it will be easy for Mouseion to allow partners to customize the UI (to some extent) for their particular use. If the development and implementation firm separates the layout from the Web app structure, this shouldn't be hard to do. However, any portions of the UI that are hard coded into the Web application will not be easy to change/customize. Therefore, Alphanumerica recommends that the layout be implemented separately from the tool's structure.
Email a Friend: This is a link/button that resides in the UI that once activated by the user will open a page in the tool's main window that will allow the user to send an email to about a site they are visiting. Therefore, the user to stay at the site they are visiting while sending the email. The UI of this function should include the following fields: overview, sections, email-to, email-from, name-from. The email-from box will automatically be filled with the email address the user gave during registration. Users can choose which sections of data they would like to be included in the email (e.g., overview, tips, related).
Because the Web application is an Internet Explorer add-on module, a package must be downloaded and installed by the end user. An installation wizard will be created to simplify the installation process.
The download page of the SiteSherpa Web site will include a form that collects the following information: username*, password*, email address*, age range, gender, country, zip (if US), salary range, and whether installing at home or at work. The user is required to participate in this brief registration before downloading the tool. The application will be able to be installed on more than one machine, sharing one account. Therefore, an existing user should be allowed to download the tool without re-registering. In either scenario, during the download, a cookie that stores a username and password is dropped on the user's hard drive.
* = required field
Mouseion should investigate any legislation involving the recording of user biographical or tracking information. Alphanumerica is not equipped to offer such legal counsel.
Part of the Community functions of the Mouseion Web app will be the opportunity for users to send feedback to Mouseion regarding their content. There will be functionality that allows users to submit reviews of Web sites, tips regarding Web sites, and other specific types of consumer-oriented information. The fields for the feedback screen in the Web app tool are as follows: title, rating (1 to 5 stars)*, and comments. Username and date will be automatically added to the record. * = required field
All feedback and user-generated content will be reviewed by a team of Mouseion editors prior to being accepted into the database. This approval process will be implemented using standard HTML forms.
User tracking, traffic data collection, and other types of end user information aggregation needs to be carefully thought out by Mouseion prior to implementation, due to important privacy issues currently in the media.
Anonymous Tracking: This refers to collecting hit numbers without matching those hits up with a user ID. This is the safest method of collecting and using traffic information because it has the least potential for privacy invasion. The downfall of this method is that new queries require new fields be added to the database. Also, new queries cannot take advantage of past activity; they can only track future activity. This method would be implemented by adding fields to the Site table in the database, one field per query.
Individual User Tracking: This refers to tracking all information about a user including click-paths, user ID-matching, amount of time on a page, and other specific types of information that could be used to aggregate valuable marketing information. If Mouseion decides to collect this information, they may need to have a privacy disclaimer that indicates as such. Alphanumerica cannot offer accurate legal advice about this. Legal counsel should be sought.
Collecting such information can allow Mouseion to display directed information and advertising based on the aggregated user profile determined by parsing the collected data. In this scenario, user tracking history will reside in its own table which is linked to the User table and includes userId, siteId, previous siteId, and a timer. This table in conjunction with the User table can be queried in innumerable ways without altering the database. New queries will have access to the entire history.
Each user should be given a list of tasks to perform. These tasks will be timed. The beta testers will log their experiences with the tool, give feedback about what works and what doesn't, and report any problems they had with either the UI design or the information-seeking process.
Based on beta tester feedback, changes will need to be integrated into the SiteSherpa tool.
Cost: Approx: $200,000 - $250,000
Time: 3-4 months development/implementation process
This option requires that you develop on top of the Microsoft IE 4.x/5.x browser platform and use the proprietary technologies shipped with those particular Web browsers.
Development Time: The hours estimated above do not include project management and administration. Most of the work will be programming the IE toolbar (and meta-info tool) to interact with the back-end developed and hosted by Mouseion. The exact amount of work necessary will depend on what functionality is included in the final specification. Also a significant part of the work will be the development and fine-tuning the user interface.
The extendibility of the IE toolbar is pretty good. Much of the difficult programming has already been done by Microsoft. What is required for an integrated toolbar is directly related to how many features and how much functionality Mouseion wants implemented.
Note: Future versions of the software will require users to re-download and install the browser companion.
<?xml version="1.0"?> <!DOCTYPE query SYSTEM "sitesherpa.dtd"> <basics> <company_name>MP3.com</company_name> <country>U.S.</country> <ticker>MPPP</ticker> </basics>
A DTD (Document Type Definition) is a kind of reference that is included in the XML parsing layer of any application. It defines a record of the custom XML tags used by the data being stored and retrieved. The use of a standardized DTD is recommended as that will increase the potential of Mouseion's data and future services being used by other companies and firms.
How Mouseion's SiteSherpa uses XML will depend on how they want their data used. For instance, if they want to allow other companies to subscribe to or to license (syndication, aggregation) their content/data, then the data needs to conform to a standard XML DTD. Also, the parsing layer between the data and the Web application must also conform to a standard XML DTD. By storing your data in an XML-aware or XML-capable database, and using XML-capable middleware (parsing) technologies, Mouseion can optimize the usage and distribution of their custom data. This includes finite and extensive customization options for both Mouseion's end users and the end users of the data.<!ELEMENT basics (company_name, country?, ticker?, parent?, network?)> <!ELEMENT company_name (#PCDATA)> <!ELEMENT country (#PCDATA)> <!ELEMENT ticker (#PCDATA)> <!ELEMENT parent EMPTY> <!ELEMENT network EMPTY>
For extensibility and future services, it's recommended that Mouseion's data conform to a standard XML DTD. The specific DTD to be used needs to be chosen by Mouseion and implemented by the development contractor and the database engineer.
Possible DTDs to use would be Alexa's DTD, Dmoz/Open Directory DTD, etc. Mouseion will need to contact each DTD owner to determine if it is publicly available, whether a license is needed, or if they can extend a DTD to include specific Mouseion types of data and metadata.
Third-Party Data Integration: As Mouseion grows, they will be striking deals and partnerships with other content and data providers. The integration of this data needs to be carefully thought out so as not to conflict with the data that Mouseion has compiled. By using a standard XML DTD for their data, Mouseion can ensure interoperability with other data vendors without a lot of data conversion overhead.
Collaborative Filtering: This technology is not in the current scope of the Mouseion Web app proposal.
Content Distribution: This needs to be developed by Mouseion and implemented by a third party firm. If Mouseion maintains their data in a way that ensures interoperability, there is no reason that they couldn't license their content to other sites.