Developing the Project
| Once the project has been mapped out on paper, it is time to implement the project on your CMS server. The site development phase includes a number of tasks that are unique to a CMS implementation. There are generally two areas in which you'll need to focus your attention. The first area is having the Web team build the site, including the framework and templates. Testing the functionality of these elements is essential before handing off the site to the content people for content development. While the content team is working on supplying the site with content, the Web development team can busy themselves with other development work. Because CMS is modular in format, your Web team can build one channel complete with templates, hand that off to the content people, and then work on other channels while the content teams are developing content for the first channel. It is not necessary for all the channels and templates to be developed before you hand the site off to the content people. The testing and approval workflow processes can be honed and refined during this phase. Your content teams should view the development phase as a chance to ensure that their workflow processes are adjusted and refined to make their future work flow as well as possible. At the end of this phase, you should have several elements ready to go. The first element is a working Web site that uses CMS for its content management. The second element should be documentation that contains instructions for those who will interact with the site, from both a development and a content user's perspective. A third element should be training for those who will need to learn how to use the Authoring Connector wizard to populate the site with content. Any project can be kept on track better through the use of milestones. Milestones are used to break up an overall project into bite-sized chunks. Holding people accountable to meet milestone deadlines ensures that the project continues to move forward. Be sure that before you release a channel and templates, you've tested each template's functionality and navigation elements. Nothing will irritate your nontechnical content developers more than a template that doesn't do what it purports to do. In large measure, the success of any CMS deployment depends on the ease of use experienced by the content developers. This ease of use comes from a well-designed template that is easy to use. Be sure to build your templates so that they display all the relevant information without being cumbersome or difficult to use. When you are planning the number and type of templates to host on your site, there will be a trade-off. One consideration is that the more templates you have, the tighter control you will gain for content exposure on your site. The balancing consideration is that the more templates you have, the more maintenance you will experience in keeping your site updated as new changes come down the pike. When planning your template types, depending on the type of content you wish to display, you may need to write several versions of the template for specific browsers and devices. Be sure to address these needs as well. Navigation elements include the links that people will use to navigate the site. Because CMS navigation is dynamically generated, when a page is added to the site, it can automatically appear in a list of links created by a script that uses the CMS API. If the script has been well planned, you will rarely need to touch it. And this is the stage at which these scripts will need to be planned.
NOTE: Always keep accurate documentation on each script that is developed for your CMS site, including scripts used to build navigation elements and scripts used to build workflow in your site. When creating such a script, be sure to consider several elements. First, be sure to consider the overall site navigation design. Second, decide between text-based and image-based navigation schemes. Text-based navigation schemes can be automatically updated when a new channel is added. Image-based navigation may require a graphics designer and/or Web designer to implement the new navigation element. Third, identify any hard-coded or static navigation elements early in your navigation design. And then ensure that these static navigation elements are not lost as the overall site design continues. Many sites will have global navigation elements, local navigation elements, and some type of breadcrumb trail that loops back up the channel structure to the current root channel, adding each step to the left-hand side of a series of links. When planning your navigation elements, you can probably use this three-tiered approach to your planning process. There are workflow specifications that ship with CMS. You can also implement a customized workflow, and if you do, you'll need to account for several considerations. First, you'll need to see if there are any existing Windows NT or Active Directory security principles that can be directly mapped to the CMS security roles. If so, you've just saved yourself some time. Second, you may need to have new groups created. This may involve the cooperation of your server group, so be sure to ping them early on to ensure the groups are created and are populated with the appropriate user accounts. Third, are there any unique CMS rights that need to be created? If so, can you clearly define the purpose of these rights and the groups with which the rights will be associated? If so, you'll need to plan these out as they relate to your CMS deployment. Any workflow paths should include how e-mail notifications will be used. How many e-mail triggers will exist in each workflow path? Will e-mail notifications be included for content that is outside a workflow path, such as expired content? You'll also need to determine how an e-mail address is derived from the user name and ensure that the same alias format is appended to each user's mailbox to ensure smooth delivery of e-mail. For example, if your users log on as gwashington (George Washington), but their current e-mail alias is george.washington@<domain_name_here>, then you'll need to ensure that your messaging administrators have added a recipient policy that creates a second e-mail address for gwashington@<domain_name_here>. Here is the developing-phase portion of the outline for your overall CMS deployment documentation:
|
EAN: 2147483647
Pages: 298