Installing CakePHP is quite a simple process and simply involves downloading it from the CakePHP page, after a donation, then uploading it on to the server. In our case it is our dedicated U.S. server that will host this application to ensure maximum load capacity and lowest latency for our target demographic. After CakePHP is extracted to a desired location we commit it into version control using Bazaar Version Control (bzr). Bzr is a distributed VCS similar to Git, however it is cross platform and has a much simpler command set.

Once we were able to see the CakePHP default page it was time to analyze the database models. Aulay, being the founder of JustRosters had the best idea of what the application should do and designed the database by himself. My job was to just make sure the table and column names matched the CakePHP conventions so that extra configuration settings would not need to be set on the CakePHP generated models. I also took the time to change any columns whose data types could be improved (int to tinyint) as well as start indexing foreign keys.

With only one hour our project foundation had been laid. Although it is not an exciting event our use of RAD frameworks makes it a much more relaxing process than previous projects where at least a week had to be spent gathering together various pieces of software that managed our database access, email access, templating, etc.

The next post will focus on setting up user registration, validation, as well as user logging in and out. Stay tuned for more.

JustRosters is a web application developed to make the creation and distribution of staff rosters easier, faster and more accurate. For a full list of features and a free trial, head over the JustRosters website.

Huge thanks to Alan, (lead designer) and Paul, (lead developer) for helping make this happen.

For those following the 8 part build, I will write part 6 and 7 soon.

For most developers, they solve this issue by writing how-tos and FAQs. FAQ pages are one thing I have never quite understood… if a question is being asked frequently, why isn’t it explained where the client first needed the answer?

Anyway, the approach to help / training that we find works:

• Build a simple, easy-to-use application in the first place.
• Fill your sales copy with print screens and screen casts of the actual application. This way the user is becoming familiar with the interface before they have even signed up.
• Add a small ‘?’ icon with a brief help text on mouse over, next to every input box. They are easily accessed and indentified by confused users, and ignored by others.
• Create a screen cast walkthrough of the entire system; present it to new users when they login for the first time.
• In the early days, look at every support request as if it is a FAQ; tweak the ‘?’ texts and screen casts where needed.

All the steps above can never completely replace the need for a good old contact page; but they can sure reduce its need.

For some it can be difficult to co-ordinate efforts to ensure that a customer’s inbound enquiries are resolved as quickly as possible. Using a highly structured system for so few staff members will lead to increased cost per response and slow down overall response time. A system that is too simple will mean co-ordination failures leading to confused or neglected customers.

Marvel Internet Group’s solution to this problem is to use a Gmail account for customer service email management. This is achieved by creating a single Gmail address for all customer service support requests. With Gmail’s labelling feature we can quickly label emails based on source so that the support person can be focused on supporting a single application or all applications’ customers. The general work flow that prevents neglect of customers as well as ensuring a streamlined support process is to check, label, and action. This involves having the first person to view the mail account go through all mail and either archive, label another staff’s name, or take action on an email. Then as other staff members check the account they can see which items require their attention.

Prior to implementation of this customer service email management system we had difficulties delegating and following through with customer enquiries that fell out of the support staff’s field of expertise. Using labels such as “waiting”, “todo”, and “complete” each request can be delegated and tracked with ease with staff members in and out of the company. The result of utilizing this customer service system is greatly reduced time spent on support as items are either actioned, delegated, or waiting. Finally an end-of-week or end-of-month review of all incomplete messages prevents any request from falling through the cracks.

To try this for yourself simply create or forward your support emails to a free Gmail account and let your staff understand the simple work flow of: check, label, action. Having your support request come from custom support forms will also save you even more time!

We had already established a basic look and feel while designing the back-end mock-ups, so the front-end needed to become an extension of that. Like any web entrepreneur, I spent a few hours half my life looking at other ‘successful’ sites with a similar target market, noting down design and navigation elements I liked. I built a basic sitemap in notepad, and started writing copy for each page. The sitemap went like this:

• Homepage
• Why JustRosters?
• Pricing and signup
• Order pages (linked from pricing and signup page)
• Affiliate program
• Login page x 3 (for administrators, staff, affiliates)
• Contact us page
• Any legal pages I needed + a sitemap, 404 page etc.

If you take out all the ‘standard’ web application pages I was left with 4. The homepage, the ‘why’ page, the pricing page and the affiliate program page. These had to be ‘conversion kings’, so I was intent on making them perfect.

It’s funny, most people think a designer is responsible for what a website ANY type of interface ends up looking like, but I think the copy writer has an equal part in the end product. The words we chose ultimately decide how each page can fit together. After what felt like an eternity of writing and re-writing sales copy, (ok, it was only about 4days), I got Alan onto the designs.

Nothing builds excitement quite like watching a front-end site come together in front of you. I was extremely impressed by how it was unfolding, and found it hard to stop hitting the refresh button every 5mins Alan was working on it. Here are some screen shots of what we came up with:

There is still a lot to do between scripting the home-page demo movie, having the legal guys go over the legal stuff and getting all the copy re-checked by a cool little Aussie start-up called Editeam. The semi-completion of the front-end has provided a huge psychological boost for the team and an opportunity to go get some feedback from some of the people I contacted way back in stage 1.

Hour logs show about 40 hours spent on copy writing and 75 on design. It might sound like a lot for a 15 page site, but I figure the difference between a 4% conversion rate and a 2% conversion rate could be the difference between becoming a millionaire or just a 500thousandaire

Our code library is split into three parts. One library contains global functions that are included in Cake PHP’s bootstrap file, which is loaded right after the configuration file and before everything else. We currently place debugging and some custom date/time manipulation functions in here so that it does not have to be duplicated elsewhere. Another part of the library is converted into a Cake PHP component. The custom component allows us to reuse convenience functions that are needed inside our controllers, such as permissions management, emailing with PHPMailer, PDF generation, etc. The remaining parts of our library are turned into a custom helper that performs view related formatting.

In total we have reused about 700 lines of code with the three files combined. Using the general rule of thumb that a programmer will produce about 100 lines of quality code per day we practically shaved seven days off our development time before we even started. The cycle of library building will continue and expand with JustRosters. Being one of our most Javascript heavy projects we are also writing a substantial amount of reusable Javascript code that can be combined into another library, or into jQuery plugins, that can be used by the development community as well as our future clients.

CakePHP is a framework started in 2005 that is compatible with PHP, a ubiquitous web development programming language that is used by more than 20 million websites, that follows the “model, view, controller” design pattern. CakePHP allows us to implement client-specific features using common functions that have been heavily tested and debugged by the entire CakePHP community. CakePHP offers polished database abstraction, templating, AJAX, caching, testing, and security features that can be implemented in client applications. Those pre-built features allows us to have a solid foundation from which we can quickly realize our clients’ vision in the form of a working prototype.

The productivity gains that comes with CakePHP would not be so great if a lot of time had to be invested in learning it. That is why CakePHP’s excellent documentation and active developer community means that we can quickly train programmers to become familiar with and productive with CakePHP in a matter weeks.

A real world case demonstrating the benefits of CakePHP comes from our experience with ICEF Online 2.0’s development. For this project we managed to take the version 1.0 program, which was developed without a framework, and re-code it from the ground up with 20+ additional core features in three months using one full time and one part time programmer. The part time programmer had never used CakePHP before and was able to implement our ordering system with less than one week training.

The product delivery time was a great improvement over version 1.0, which took well over six months using the same amount of human resources. We also saw improvement in the size of the code base, shrinking it from 137 megabytes to just under 50 megabytes. With all things being equal we have basically managed to half quoted times in our client application development and create a much higher quality application. This was possible because we were able to focus on what was important to the client, instead of worrying about the low level mechanics of the application.

After what felt like a million Google searches, we finally came across a script that would have done exactly what we wanted it to do, only to find out that it was incomplete. It had some of the features we needed, fixed header, fixed columns and scrolling of the inner data cells while remaining lined up. It just wasn’t cross browser compatible, did not support fluid width columns or row heights. I installed the script and after fixing it up for a few days, I got it to work….. sort of.

What we needed was to have the data table take up maximum width and height of the browser content area, but doing this broke the script or the cells didn’t line up. After a lot of trial and error, tweaking the JavaScript and the css, I was finally able to create a fixed header and column table with dynamic resizing based on browser window size, row count and column count. The resulting table can be viewed here for now, and will be integrated into the finished JustRosters staff scheduling application. When I get a chance I will post code snippets.

In our experience support emails can become rather difficult when the user does not provide adequate detail about what they are doing, or who they are. The lack of information means a lot of time is spent waiting on user clarification. The time spent identifying the problem often takes longer than providing the solution. This is where investing the time needed to create a custom support form comes in.

In a custom support form that we implemented for ICEF Online (1,500+ people use it almost daily), the form auto-embed hidden values identifying the user’s account, the page they were on before they loaded the support form, as well as browser information and screen size; all of which help us diagnose problems far quicker than if we just relied on plain email, or even an ‘off the shelf’ support ticket system.

For common cases where the reply just requires usage instructions, a custom support form can completely eliminate the need to wait for a user to reply with details of what they were trying to achieve. For more complex scenarios we are able to completely re-create the user experience for testing by reproducing user results with the same browser, operating system, and input values. The limits of how much information your support staff have access to diminishes to almost zero once the basic system is put in place, which is a very low cost given the customer satisfaction returns that can be achieved.

I work on a variety of projects at any one time, designing both shop front websites and web applications. I recently completing the design and development of the new Marvel websites in the Typo3 CMS, only 4,000+ lines of CSS!

I’ve also started on the interface designs for a new in-house project called JustRosters.com, turning VERY VERY rough sketches into attractive, working interface mockups. The biggest challenge so far has been getting the main interface to fit dynamically on any screen size, whilst maintaining it’s main functionality and useability. Sounds easy, but calendars never seem easy to work with. I’ve made good use of the Javascript user interface library jQuery, to provide the main interface functionality, while maintaining fast page load times.

Anyway, better get back into it, after all, those interface sketches are very rough, and Paul is hanging out to start coding!