While not always practical, I try to include everything on one page. Rarely is an application that complex that it can’t be mapped out onto one page. I also colour coded functionality in various ways. Reporting is yellow, tasks are orange, and preferences are pink, and so on. I did this to help visualize how related functionality might be tied together.
When doing this, I discovered that there were ways to combine functionality into one page or that there was a need to break it up into multiple steps. You really gain a greater sense of your application by completing this step thoroughly.
This isn’t something that I normally do as a web application normally follows a pretty basic mechanism of request-response but I really felt the need to describe this process. This CMS is intended to be extremely modular and therefore I wanted to ensure that I was defining my framework properly.
Originally, I had separated the flow based on whether the user requested information or submitted information. If a person was running a blog site and a user submitted a comment to a post, what would happen? If a person was running a corporate site with a discussion forum and a user submitted a message, what would happen?
In going through this process, I came to the realization that the web site user is always requesting information (the web page to be displayed after clicking on a link or submitting a form). It just so happens that on occasion they’ll be sending information to the CMS in relation to a specific object in the CMS and that the module will need to have an interface to handle this.
Later this week I’ll talk about prototyping, which is the phase I’m currently at with my CMS. I’ll also unveil the state of my prototype so far.
Read the sidebar, Open vs. Closed Source, or the next installment, Prototyping.f2富二代官网入口