The Molecular Foundry is currently using a web-based application to gather, track, rate and manage scientific proposals.
As the use level and overall flexibility needs have increased, the original version need to be replaced. The new version should:
- Do what the user needs (meet advertised needs and enable flexibility)
- Not be unnecessarily frustrating or complex (intuitive and simple)
- Be pleasing to the eye of the majority of potential users
- Allow the user to figure out how to do what he/she needs
- Not break all the time (higher reliability; fewer bugs)
- Encourage the user to focus on their work instead of the tool itself
- Map to the users understanding of the Molecular Foundry universe
Steps To Get To Version 2.0
The required changes to enable the Vision Statement need to happen in four steps. Each step will be performed offline in a new database sector so as not to interrupt the current Version 1.X functionality or utility during this creative process.
In step one, we will update the admin user interface to match the diverse programmatic needs.
In step two, we intend to update the database to match our business process requirements and guidelines.
In step three, we will update the external site to work with the new database.
In step 4, we will extensively test the new databases and its interfaces (external and internal) as well as verify database continuity between the old and new systems.
Step 1 - Update Admin UI
A visual description is better than a verbal description:
old ui (rigid, no sorting or filtering ability)
new user interface (ui) will flexible, sort, filter, export, change and save layout, drill down for more details, etc.
The basic strategy is to replace all functionality from the old ui and copy it into the new ui at a separate sector. Once this is complete, step two can occur.
Step 2 - Update database to model our business processes
Our database and business process are out of syncronization. Examples include users currently cannot have multiple roles, there can only be one user agreement, internal users and external users are considered different, same users are duplicated, no proposal history or auditing, etc.
Step 3 - Update internal and external site to work with updated database
Any time the database is changed, both internal and external site code must be updated and aligned. This will not be trivial on the Admin site; the external site will effectively undergo the same major rewrite as the Admin site.
Step 4 - Validation and Release of Version 2.0 database for general use
Classic 2-tier physical design using a single database server and 1 or more web server(s)
|framework||Microsoft ASP.NET (version 3.5 SP1)|
|development environment||Visual Studio 2008 |
|web framework||ASP.NET |
|data access layer||Subsonic 3|
|source control||Visual Source Safe|
|compare tool||Beyond Compare 3|
UI (ASP.NET) <--> BLL <--> DAL (Subsonic with LINQ queries?) <--> database (Oracle, but effectively database agnostic)
As with most 2-tier architectures, increasing scalability involves upgrading the database server to a more "beefy" machine and/or adding more inexpensive web severs, depending on which of the two is the bottleneck. 90% of the time the database will be the bottleneck.