Infoglue is not some magic tool that let you skip the thinking process. On the contrary – by doing a good analysis before starting to build you can achieve a much better solution for your clients. Many things concern how you want the users to interact with the system or which way they feel comfortable in managing their site and the information in it. In this document we assume you have a functional spec as well as a design proposal which are to be implemented.
The first thing to do is to go through all the pages and analyse them in detail. Questions to ask are:
- What types of information are there and how we can generalize this into information types.
- What parts of the pages are there, how can we create a layout system which is both simple and easy to maintain and still dynamic and extendable for users who want that.
- What components do we have to build to make it happen?
- What complex functionalities are there, how we solve it?
- Are there some external systems that should be integrated somehow and if so – how is this best done.
- Do we need to create new page types other than the default? (unlikely)
One of the most important artefacts that should come out of this is a list of suitablecontent types. A content type is what a developer would use a Class for in Java. It defines what attributes a certain information type should have. A typical content type is “Product” which perhaps has the attributes “Name”, “Description” and “Price”. It may also have an attachment labelled “Product Image”. InfoGlue contains some default types for demo purposes but it’s up to the project to set up ones suitable for the customer. This is done in the management tool without writing a single line of code and is described in the user manual.
Template / Component-list
The next thing the analysis should result in is a list of templates/components needed to visualize the site. Most often a page can be fragmented into smaller reusable templates/components but it all depends on the design. This list is a good starting point when estimating the development effort as well as a good document to continue working on as part of the site documentation. We usually describe a component both visually, functionally as well as how the users are to interact / supply it with information etc.
comments powered by Disqus