Marvel Internet Group blog

From this week I will be starting a multi-part series on the coding of JustRosters, touching specifically on the challenges and lessons learnt throughout the experience. Our journey starts on a February afternoon (02/02/2009) at 3pm. The first task that needed to be completed was the installation of a basic CakePHP install.

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.

It has been about a week since we launched JustRosters, and what a week it has been! We have made it with smiles on our faces and the first major revision of the logged in area rolled out.

FROM

TO

After watching a few new users of the system build a roster, we quickly realised that those slow with a mouse were spending a lot of time clicking cells on the left, then having to track over the right ‘Action Panel’ to enter the shift times. The wider the screen the bigger the problem, we needed to head back to the drawing board.

The most logical thing to do was turn the Action Panel into a pop-up balloon which appeared next to whatever was clicked. We made the balloon repositionable, in case you needed to look at cells immediately to the right of the cell you were editing.

The initial re-coding did not take long, but updating the getting started screencast did! We are in the process of changing our front page demo screencast anyway, so it has been replaced with a screenshot tour for now. It will be interesting to see how that effects our conversion rate as clicking the front page demo was the first thing one in two of our visitors did!

I hope new and existing users of JustRosters like the new pop-up balloons as much as we do.

Just a quick post to let everyone know Marvel Internet Group’s first in-house web start-up, JustRosters, has officially launched!

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.

Users on free trials will quickly dismiss an application when they are presented with a problem they cannot figure out for themselves. They do this because the only investment they have made by using a free trial is time, and the thought wasting more time is too much for most.

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.