We're developing a web application for a client, and I just wanted to share the planning process for this particular application. By no means is this meant to be a 'that's the way to do it' kind of post, but hopefully some people may find it useful. We'd welcome some suggestions on how we can improve this process.
Simple or complex, it's vital that users are identified, and goals/actions for these users are clearly documented. After all, who wants a website that doesn't do what it is meant to?
For more complex sites and applications, it may be useful to write User Stories, sort the Users into logical groups and then sort the User Stories in order of importance so that goals with the most Return on Investment (ROI) can be prioritised in the backlog and design.
A User Story goes something like this:
Here's an example:
At the end of this process, you should have Users, logically grouped, with their appropriate Goals or Actions assigned.
Now everyone involved in the process knows what is expected.
The first step in our data modelling was to identify each 'model', a model being a logically grouped collection of data. In our application, this was things like User, Company, Project etc.
Having identified the models, we then identified each individual element of data, say first name for the User model, and applied a database type and input type to it (with any options), which would be handy for when we came to build the relevant forms. Here's our complete User Model:
After that, we defined our relationship between the models, for example:
We felt that this was all that was needed to start building the database, and preparing the form views for the application CRUD (Create, Update, Delete). However, we did produce an ERM diagram of this information, but to be honest, that was overkill, and caused confusion amongst the non-technical people involved in the project (I can see it would be valuable for highly complex applications though).
Web Application Modeling
This is where everything gets visual, which can confirm everyones understanding of the project, and how the application will work. The chances are, this isn't going to be an exact model of the finished application, as CRUD actions will be moved around during the process, so that they fit logically into the workflow.
Our main aim was to sketch out the views, and their associated actions for each of our user types. We chose a simple workflow layout, rectangles for views, ovals for actions and chose green, blue and red for our users (users, admins, superadmins respectively). This essentially mapped out our application, and showed what level of access would be allowed to view them and perform the actions. This is where the bulk of the client understanding came from, and was actually the most time consuming part of the process as it acted as a catalyst for various client changes and requests. This was a good thing, it meant we could change the application without having to refactor code or design.
Here's an example Web Application Model:
These basically confirmed our understanding gained from the Web Application Modeling process, and then allowed us to layout the necessary information for each view, without design getting in the way. Having an asset that contains layout but no design allows users to concentrate on the important things like information hierarchy, without getting bogged down in 'subjective' design assessments.
It's at this point we produced the Backlog. This was simply a list of tasks to achieve our aims. We could group these into stages if required, and develop quickly with multiple iterations if we wanted to get 'agile'. If not, we could just complete the list and deliver the product to the customer.
I love it when a plan comes together!
Have you ever wanted to force a HTTPS connection for your ExpressionEngine website? If so, you may have also wanted to 'unforce' that connection for other areas of your website, either for performance issues or because maintaining both HTTP and HTTPS for the same section can be tricky. Avoid those pesky browser warnings about unsafe (non HTTPS) assets with this htaccess rewrite.
Everything looks better with an oilslick filter #Fireworks-- Delivered by Feed43 service11 Feb 2014 | 9:04 pm View full tweet
@meloncreative cool just be warned that the documentation for Form Integ. is incorrect, so if you are relying on it there are some gotchas-- Delivered by Feed43 service9 Jan 2014 | 5:39 pm View full tweet
@meloncreative do you need any sample code for the Form Integration?-- Delivered by Feed43 service8 Jan 2014 | 9:35 pm View full tweet
Thanks for your message! We will get back to you ASAP!