With only a short time between starting work on the design and MobiCart’s launch (the guys kindly waited for me to finish writing my book), working on MobiCart meant working fast. That meant designing in a browser (yes, that old chestnut) and almost daily iterations. This meant that the design developed as the content and functionality came together, rather than starting with a grand plan for the design. In practice, I wrote HTML and CSS from the very beginning, dipping into Fireworks only when I needed to to make graphic elements.
As I rarely work on projects that need a full-blown version control system, nine times out of ten, I’ll work in Dropbox, duplicate the previous day’s work to create a new folder, then carry on. This might seem primitive, but it works for me and keeps all my files synced across multiple Macs. I shared the Dropbox folder with the MobiCart team and this had such real advantages that I now do it on every project.
- There’s no need for endless design meetings. MobiCart could see what I was making as I was working, so the design process was transparent.
- The MobiCart team could add content to my templates as I worked.
- Browser testing was almost instant as everyone could use their browser of choice.
- What they saw was what they signed off, so the differences between browsers became a non-issue.
- MobiCart’s back-end developers had access to HTML templates far earlier in the process.
At the start of this fast-paced project I created a simple CSS framework that provided a basis for layout styles and simple typography.
With all of my projects, I wireframe pages in HTML and CSS rather than in Fireworks or Photoshop. This gives clients the ability to interact with the elements on a page in their browser. HTML wireframes allow a far greater understanding of functionality and what content clients will need to collate or create. (For a complete picture, here’s the original wireframes PDF that MobiCart provided.)
I encourage clients, even ones that are not technically savvy, to add their own content into my templates as I work. This has a number of advantages. Clients can appreciate how much or how little content is needed and how it will look in situ. Less technically competent clients learn HTML as they go. This allows me to educate them on the right choices for HTML elements going forward, so training time is dramatically reduced and clients avoid common mistakes such as adding presentational elements and attributes.
As MobiCart watched their design take shape, they got a better understanding of the content and functionality they needed. Changing their minds or suggesting new approaches wasn’t a problem because as I was working in HTML and CSS, I could experiment with their ideas and they could react to them in minutes. This meant that I could spend time on the important aspects of the design and not in an endless backwards and forwards, trial and error approval process.
Of course not every aspect of the project was so straightforward. The more complex aspects of the back-end admin interface took longer. However, skipping the static design visual phase and moving straight from paper sketches to code meant that I had longer to think about user interaction.
I know from past experience that working fast can often involve making both rash decisions and compromises, but the process we adopted for this project meant working smartly as well as quickly. By avoiding the parts of the design process that chew up valuable time, we could spend more time on those important decisions while still keeping up high standards. I would recommend this type of process to everyone as it was creatively satisfying and productive for me and the MobiCart team.
I think it goes without saying that MobiCart was designed with HTML5 and CSS3 throughout.
There was even room for one or two hidden Easter Eggs to keep us all amused.