Many new KWALL clients are moving from one platform or no platform to a new web platform driven by a content management system or CMS. In this blog we'll attempt to answer many of the questions or expectations that come up while implementing a new web platform regardless of which one it is. We hope that this will give you some idea of what the process can take.
A couple things to keep in mind prior to kicking off a platform change:
1. Document current custom code and functionality - if it's not documented now, it will be difficult to track down throughout your project. Get all the technical information for things like API integrations, Login systems, Forms, eCommerce interactions, etc.
2. Identify functions and interactions you intend to use on the new web platform, compare to current user expectation - Every system is different. Like getting a different car they might both have air conditioning but the knobs and buttons will be completely different. You will want to decide if just having air conditioning is good enough or will it have to operate exactly like your current system. If it has to operate the same that can create an unknown risk to your development partner as they will likely utilize plugins and modules that work differently for the new platform.
3. Understand the current authoring experience for your web teams - Make sure that the new system will improve that process and that there isn't a step missing in the new system that they do currently. Look into how they manage files and images, what they might expect to create content.
4. Start learning how the new system manages content - Each system is different in how it works. Make sure you get online and learn how the system works by default.
5. Write down your expectations - What areas of a new software are must-have items for you? Without having a clear layout of how you prefer custom areas to operate you may end up with missed expectations on roll-out. Talk through your assumptions no matter how small. You will be surprised on the ones that aren't actually inline with the software.
6. Track your project scope - Make sure that what ideas you come up with throughout the creation of the customized system are within that original plan. It's easy to get sidetracked by features, modules, and plugins that add features but don't supply you with a final product as fast. If you stick to your scope of the original project you'll be successful faster.
Depending on your objectives the process can vary slightly. We like to start off by doing some research on what currently exists in your environment.
- Identify the current content or content types used on the current CMS
- Identify any forms or custom code that performs on the current platform
- Make a sitemap of the current website using an application like Xmind
- Write up a functional or technical plan outlining the architecture and customizations required in the new platform
- Identify features in the new system and compare them to the current configuration, identify modules which have similar features
- Learn about software version control such as GIT. GIT should be used in development of any system to provide you with the ability to revert changes to the software throughout it's use
Content management systems are setup to create web content in the form of pages, but new sites have different types of content that need different fields and different displays. Spend time defining what type of content is going to be displayed throughout the website. This might include, news, events, people in a directory, blog posts, products, departments, etc. Anything with fields more than just a title and a body of content should be mapped out. Making a solid architecture in the beginning will save time and rework while designing the layouts and integrations required in the development phase.
Write out an architecture plan or build one with a tool such as Xmind for more visual teams.
Define the types, fields, field displays, labels, how the content should be entered, etc. Additionally note the places this content will display in lists or grids and make sure the fields are there for those too.
Design and UX / UI
Once a solid architecture and plan are ready, move into design. Define the style and requirements of the design. Many people online use things like grid systems or frameworks like bootstrap to align web content and make styles work well on the site. If you are choosing to use a framework like that make sure to design for it. Make a design for each unique page layout based on the content types, grids and displays, form pages, and search areas. Design a general layout too since this is a content management system and you won't have full control of the layouts of every page. If you use a system like Atomic design you can identify different areas of the site and apply a general style to it.
Some features to determine through the design:
- Where menus will go
- What type of menu interaction it should have
- How the side menu should interact at levels deeper than the first and second level
- Where the header and footer start and stop
- What areas of content will be controlled by the content author
Define the features you know you require to make the site successful. This is the most difficult area to align your expectations with the platforms capabilities and add-on modules. The functionality may not be exactly as you would like. Sometimes changing something from a checkbox to a set of radio buttons on certain platforms could create an extra 50 hours of work or increase the risk of adding in a bug or breaking other features. Write up each feature you require, include every assumption or feature map you can create. Compare this to plugins or module that can be downloaded or purchased. It's always better to leverage existing functionality that has been used for similar engagements and been through growing pains of maturing as a software.
Many content management systems are laid out in regions. There tends to be a set of expected regions, blocks of associated content and a general center area where the content will flow downward in every content management system. Make sure the theme has the appropriate regions.
Take a look at predeveloped frameworks like bootstrap, zen, foundation and see if any work as a part of your custom theme and layouts. These can help with the QA and responsiveness of content.
Regardless of coming from a static site managed through FTP and Dreamweaver or Adobe Contribute to any database driven system you will need to move that content. Make a map of the current content types to the new content and make sure you have all the information you require. Make sure you track the URL that it's currently at, map to the new content type.
When planning consider:
- Redirects required from old to new URL - this will change on the site structure in the new system typically.
- How images and files will be migrated, not just content
- What fields to retain in the new content type
- The content URL's and if those need to be changed
- What will have to be cleaned up or rebuilt, look at what forms and iframes and tables will be carried over and either break or not be responsive
Look up the requirements of your platform and determine if you prefer to host yourself or with a provider. Additionally determine the amount of support you will require from the host if looking to have an experienced host supply the platform. Some hosts are purely web hosting that supply you with a place to put your web platform, while others supply support for the entire platform. This can be beneficial if you don't have 24 hour support staff experienced in the web platform.
Launching or "Going Live"
Launching or going live you will need to be sure you have your servers setup for use with the appropriate domain, the configuration has been well tested by visitor user roles or views, and that all the integration points are available on your production web host. Once the system is setup on the production web host, going live typically includes moving the domain through the DNS to the new server IP where the new platform resides. The DNS change is typically done where the domain is purchased or at an enterprise client they might have their own DNS servers internally that manage the domain. For more on this read here.
Decide what type of support you will need and either staff or hire a partner to support you. Determine what you consider a reasonable response rate as this tends to affect the pricing and vendor requirements.
Throughout this process it is normal to have new ideas for designs, features, or development that were above your original statement of work. Development post-launch should be done either with additional projects with new statements of work or through hour-bank approaches. With hour-banks you purchase a set of hours to do miscellaneous tasks within if you have limited needs. Either way all work should follow a traditional software development life cycle where you bucket tasks into a release, work on the release, test the release, and launch the release. Repeat through the next release. This keeps small tasks from creating bugs or making it difficult to completely QA the site. When you don't follow this approach it can initially feel like you are getting more progress but in time it will feel much more like a never ending pile because you will have to continually test changes and exhaust all resources.
Interested in talking more about how to move systems? Talk to us at KWALL here.