The lists of sites built in Frontal is getting longer all the time. (And this doesn’t include the 50 or so sites that were built on the similar technologies that preceded and informed Frontal.) Given that, I thought it would be interesting to share some of our real world experiences with Frontal.
First, I should mention that Frontal has a close friend in the New York-based digital agency BASIK. It is this agency that has embraced Frontal the most and whose experiences I want to discuss.
BASIK is a boutique agency of around 10 people. A typical project will be handled by a project manager, a designer and a developer with the partners stepping in as needed to ensure the highest levels of professionalism and achievement. This is not an unusual arrangement and many agencies fit the same description.
What’s perhaps different about BASIK, though, is their project life cycle. It’s a life cycle in which designers, developers and even project managers contribute at all stages of the project in a very smooth and productive way. The key to this is, what else – this is the Frontal blog, Frontal!
Typically, when a rich-media project is accepted by BASIK, they first sit down and brainstorm the big ideas. These are a small number of points that will really drive the design and implementation of the project. As such, it is very important that the visual aspects of these big ideas be clearly presented to the client as full buy-in is essential. Sometimes this means putting together a storyboard of static images but often it means putting together an interactive piece. In that case, BASIK prefers to turn use Frontal.
The reasons BASIK chooses to do its prototyping in Frontal are first, because it’s easy. In fact it’s so easy that designers often do their prototyping without the help of a developer. And in those cases where a developer is involved, the designer is expected to pitch in. That is, the developer will do the heavy lifting and then the “styling” as BASIK calls it is left up to a designer. So, all those little fine tuning things that designers want but often have trouble communicating to developers, that developers tend not to want to do and that clients swoon when they see them are kept where they should be – in the hands of the designer.
And by the way, you know all those complications of allowing a bunch of people to work on a Flash piece simultaneously? With Frontal, they easily disappear for two reasons: first, 99% of a Frontal project is text-based and any source code control system (BASIK uses CVS) can handle merging changes to text files very well. And second, because the binary assets of the project may easily be broken into multiple SWFs and then loaded for use via Frontal. That is, binary assets become ancillary to the main framework of the site and so it’s easy to partition them to be work on by several people.
The grizzled veteran of the web world is cynically accusing BASIK of not employing pure designers but rather designer/developers – that rare breed of person that can do both design and development. Well, they don’t. And not that they wouldn’t it’s just that those people are elusive to say the least. In fact, at BASIK they call them unicorns because they’re more mythical than real. Nick Law of R/GA puts it on a graph. No, they use pure designers and pure developers. What they’ve found is that Frontal enables designers to do more development than they thought possible and enabled developers to work with style sheets such that their changes come out looking good with little effort.
So after prototyping and selling the big ideas is done, BASIK moves into design mode. Does this mean scrapping all those prototypes and what not? Absolutely not. The reason is that much like selling big ideas, selling designs requires a highlevel of buy-in from the client or else inevitably there will be major changes requested the week or day before the scheduled launch. And for the same reasons that BASIK chooses Frontal for prototyping, it chooses it for presenting certain aspects of design.
And when a design gets sign off and development begins, do they start from scratch then? No again. Those prototypes that made it out of the big idea and design phases became the basis of the production site. Ah, reusability. Music to my ears. And Frontal delivers it. So many interactions and functions get reused from one project phase to the next and one project to the next that often times what needed a developer at one point does not need one at another because the designer knows where to get the code and how to apply it. (It’s most often just copying over some declarations from a style sheet and maybe some markup that goes along with it.)
A great example of reusability with Frontal is the Google Analytics integration that BASIK uses. You simply include the file in your Frontal documents and you’re done! The integration piece is smart enough to track user interactions like changing sections, playing video and clicking on links with no effort from the developer or designer. Sweet.
Of course there will be change requests before a project is completed. Some of the most annoying are those little copy changes that the client needs. They’re annoying because traditionally the project manager has to capture them, enter them into the bug tracking tool, schedule someone to do them, wait for the result to be posted, verify them and so forth. So it’s not that they represent a lot of work in themselves, it’s just that they represent a lot of coordination. But what if the project manager could simply make these small changes themselves? With Frontal it happens. BASIK reports that they let their project managers check project files out of the source code control tool, make minor copy changes and check them back in. And they report that this approach is successful. Why? Because such changes are so simple with Frontal that even if things get botched, they are easily resolved. The overall savings support this approach then.
Now the grizzled Flash developer reading this is saying, “I’ve been using XML data files for years in my Flash work. I do that for just this case.” First, using Frontal is not the same as using XML data files. That’s because Frontal includes markup with content just like HTML. Why is that important? Well, what if that XML file has 10 entries that say “click here?” When I’m looking at the final site, which one maps to the one I want to change? In Frontal, that text will be in the context of the layout and so the editor will be able to figure it out. Also, as grizzled a Flash developer as you may have, in a one-off project they will not spend the time to make their XML data files as generalized as possible. And if they do, then they don’t have their priorities straight and are wasting time. But Frontal was designed from the ground up to solve every design problem and so while it certainly doesn’t achieve that, it does provide a very general solution. (By the way, that’s only clever in that we at Frontal noticed that HTML and JavaScript are effective technologies. It doesn’t take a genius to make that observation.)
So in the end, BASIK is very happy with their process based on the efficiencies and group dynamics that Frontal enables. As importantly, their clients are happy. (BASIK tells me that in one case, their client began updating their Frontal documents themselves with no training and not even any encouragement!) It seems they’ve found a good way to achieve pixel-perfect designs which any
good designer will tell you is the difference between a good site and a great one. And that way is to keep the whole team involved in the production and not just the aesthetically-challenged developers.
And finally, I saved what I think is one of the most important aspects till last. Many of BASIK’s Frontal-based sites are content managed. How did they do it? They simply used the tools they developed to publish HTML sites. Instead of publishing HTML files, they publish Frontal documents. Now that’s cool.
