Ambassador Programme
Table of Contents
Details
- Date Completed:13 September 2006
- Days/hours spent:8 days, 6 hours
- About the company:Fitness Professionals
- Software used:Dreamweaver MX, Photoshop CS
- Tag:Coldfusion, CSS, Framework, Javascript, XHTML
Currently working on…
Lots of freelance and e-commerce projects.
Latest Work
Search Portfolio
I developed this website in Coldfusion and partially designed as FitPro's Middleweight Web Designer.
1. Introduction
The Ambassador Programme is an integrated programme that utilises FitPro's quarterly BTS class relaunches to promote group exercise along with education and better hydration messages. The objective is to drive gym recruitment, retention and exerciser value utilising a team of Elite Ambassadors to manage club relaunches as well as driving day-to-day exerciser value through ongoing education and support (as quoted on the website).
2. Design
The design was already defined on the print side of things. So we didn't have to design anything from scratch (which is always good!) apart from changing it to fit a website layout.
There was a lot of imagery that we could select but I picked the guy doing a martial arts stance to add a bit of flare and power. So that the image we portrayed was cool, strong and professional.
The final banner design.
We needed to get a clear message of what studio coordinators or clubs where going to get out of the Ambassador Programme. There was three clear statements:
Build, Retain, Satisfy
The three statements on the home page.
As the meeting went on, a clear image came into my mind on how we could utilise these three statements on the home page. I also thought it should be clear to the visitor where they should go from the home page (“I'm a studio coordinator” or “I'm a club manager”)
Where the visitor should go depending on their profession.
3. XHTML and CSS
The Senior Web Designer finished off the template design in Photoshop and I converted that into XHTML and CSS (hand coded).
4. Development
Introduction
Our developers were busy with another project and there was a need for template system could be easily deploy a website without any development complications.
Dust
Following my dust framework project (PHP framework development), I decided to take on the task of creating a system in Coldfusion which is similar to what has been done in RubyonRails (MVC-style) with some slight changes to the methodology (due to the limitations of Coldfusion).
Thinking behind the system
The main issue with most web applications is how it would handle further complications to the structure. I believe in using simple mechanics to remove complexities in the structure and coding. As is important to migrate your ideas onto other people, and the easiest way to do that is by reducing difficulty of understanding.
Many things that previous programmers have told us to do might not be as effective when one's dealing with “non programmers”. For example, the way we write functions and variables can be inconsistent and lazy. For instance, a function that changes the path of the template might be called changeTemplatePath() or even setTemplatePath() then have another function which set the filename of the template, setTemplateFile() and so on… If one thinks about it, is this really the best way to introduce the system a non-programmer?
What about this?
We change the function name to template(string, string) with a required parameter of the template file, and template path. Now this makes more sense, as changing the template path is rather useless without changing the template filename.
Now the mechanics have been reduced and simplified, making it (I believe) a lot easier for a non-programmer to understand. The only time I'd create a function is when a piece of code is repeated more than three times (yes, three being the magic number).
The hardest challenge in my eyes is allowing web designers to use a system that minimises the developers' involvement (improvement of system architecture basically). The most logical method I've found is the RubyonRails technique (splitting the actions, database queries and HTML into different files). I never put much thought into it but RubyonRails uses an elegant method of creating and more importantly maintaining a web application.
The current Coldfusion methodology was stubborn in the sense of building a flexible web application. Creating a file called application that held the HTML head data and footer file, which closed the HTML file. Now what about if you wanted to change any of the HTML head data? Or if one wanted to have change the HTML completely? Maybe if the client required a WAP template for mobiles? Then the developer would have to create another application and footer files that had different applications names <cfapplication>.
Cold Dust
I applied the RubyonRails methodology when creating this system (Cold Dust). And I could instantly see improvement in range of flexibility.
Create three main folders, application, public, and system.
The Application folder contained the controller, database (model), view, menu, error and template files. If you're familiar with the MVC style of creating web applications, then you'd realise that controller, model and view files were the main files concerned. But I gathered that it was important to have menu files that contained different menu <ul> for each controller. The template files were complete HTML files with head, menu, view and footer data placed as variables.
This way, the content inside the view files are completely separated from the main HTML layout. It was important, as the layout might change (i.e. having different <div> tags for the layout, different web standard formats XHTML, WAP etc..)
The application folder structure
The Public folder would contain CSS, images, JavaScript, document files, etc. Again separating data proved to be important for websites that undergo rapid changes as it was easy to find and change compontents such as CSS styles. Because everything had its own logical folder and place within the system. I set up variables for these public paths, so that they could be used inside the HTML. This was proven to helpful as the dev and live sites might have different file locations.
i.e.
Old school way:
<img src=”website/public/images/skin/content-bg.gif” alt=”content” />
While this is a much better way:
<img src=”#images_path#/skin/content-bg.gif” alt=”content” />
The System folder contained all the code that would put the web application together as well as libraries for dates, strings, arrays and database functions. Keeping all the core Coldfusion code in one area made it much easier to update.
As one can see, the most important factors were simplicity and flexibility. Keeping to these goals made sure the code would not get to complex and different to maintain.
The system folder structure
Cold Dust framework has gone to version 0.2 with better features in mind (global CSS, images, HTML). The timeline for version 0.3 will allow one to create controllers automatically through a website interface ensuring consistent files.
