Understanding the purpose of a legacy microsite can help you determine whether you should fold it into your newly designed website or dump it. These tips will help guide you in the decision making process.
In my tenure as a web manager, I’ve worked on countless projects where the client wanted to redesign their website. The first step in a site redesign process is to complete a site mapping exercise, where various pages and content are identified. As part of the process, we frequently uncovered microsites, which is somewhat like finding a skeleton in the closest. The newly found microsites raise the question of whether they should be collapsed into the site or permanently removed.
While answer may seem elusive, I’ve found that the decision can be driven through thinking about the common characteristics of a microsite. These characteristics include:
- Unique branding
- Special content
- Custom navigation/URL
- Nonstandard content management
To clarify, a microsite is typically launched to support a new marketing initiative or promotion. The site may break the branding guidelines or rely on new print collateral so that the marketers can fully test their initiative. A microsite frequently has new content that doesn’t follow the normal content structure of the website. Additionally, the microsite may play a part in an SEO campaign or and SEM campaign so it may not link to the corporate site or require custom navigation so that visitors don’t have to think. Lastly, the content on the microsite may require more involvement than the corporate IT department can dedicate to this initiative.
So how do these characteristics help determine whether to migrate the microsite?
To answer this question, one must simply evaluate whether the characteristics of the site when it was built have stood the test of time. Some questions to ask yourself include:
- Has the marketing initiative or promotion become a permanent part of your marketing offerings?
- Can the design shift back to the corporate branding guidelines?
- Can the content fit within the corporate website through the use of an existing content template?
- Will the microsite continue to meet its goals if the navigation matches the corporate site?
- Can the content on the microsite be managed through a Content Management System or CMS?
By answering more of the questions above with a yes, the clearer the direction is to fold the microsite in with your website.
In my previous post on online forms and project requirements, I discussed what can happen to data once a form is submitted. And while it is critical to understand what happens to the data, web developers developers also need to better understand the form data.
As defined in the previous post, an online form is an interactive interface where a user can submit one or more fields. The fields allow a user to submit data, where it can be their name, email address or even password.
There are two general types of fields:
- Free-flowing fields. Often referred to as an input field of type TEXT, these allow a user to enter virtually any kind of data, including alpha numeric text, dates, or numbers.
- Constrained fields. Often referred to as a SELECT field or an input field of type RADIO or CHECKBOX, these allow a user to enter pre-determined data.
Once a user enters information into a field, the field can be validated to ensure that the data is of the expected type (IOW, an email field gets an email address and not a first name). This is often referred to as a required field or a field that must be filled in order for the online form to be submitted/data to be accepted. There are two types of form data validation:
- Server-based data validation is the ability to use the web server to validate the data once it is submitted to the server. This validation often relies on a server-side scripting language, including ASP, ASP.NET, ColdFusion, JSP, PHP, etc.
So based on the above, project management should collect the following requirements regarding form data:
- How many fields will appear on the form and what type of data will be submitted through each field?
- Will the form require any validation and will it require client-based or server-based validation?
- If validation is required (regardless of type), which fields will be validated and what is the expected data per field?
- If server-based validation is required, what kind of scripting language will be used to perform the validation?
These questions should help you round out the online form requirements gathering.
Online forms are an integral part of a website. They are frequently used to allow users to log in to an application or to submit their information. As a project manager, you should expect to have at least one website project that will have an online form. So it is important for one to understand what kind of requirements you should collect for a developer to build a form.
By definition, an online form is an interactive interface where a user can submit one or more fields. Once a form is submitted, there are three potential outcomes (see image below):
Outcome #1: The data that’s submitted is displayed back on the screen.
Outcome #2: The data that’s submitted is sent. The data can be sent as an email to a contact or a list of contacts or to a web service (I’ll define a web service at a later time).
Outcome #3: The data that’s submitted is saved in a data source. Data sources range from the ultra-simple file (which is often referred to as a text file or a flat file) or a database (eg: MySQL, MS SQL, Oracle, etc.)
So based on the three outcomes above, the base requirement to collect/understand would be to determine what should happen once the form is submitted, or action is necessary on the online form. Additional questions around this would include:
If the data is displayed:
- Where is it displayed and what kind of styling is required?
If the data is sent:
- Is it sent as email or a web service?
- If it is an email, who gets it and how should the information appear in the email (any special formatting)?
- If it is a web service, where is the web service, does the web service expect anything in particular (is anything required) and will the web service return a success/error message once it receives the information?
If the data is stored:
- Where is stored?
- If it is a database, what kind of database is it (MySQL, MS SQL, etc.), what is the version number,what is the database name, what is the database table(s), and what is the column name(s)?
Hope that this helps make the requirements collection process easier on your next project!