The new Handcraft is here!

Listen to the ‘i’ in Team

When a development team is made up of different specialities, one or more members are usually responsible for writing top notch quality HTML and CSS. Even though the common goal of the team is to build a kick-ass app or website, the individuals making up the team don’t always have the same path or means to get there. And as there is in fact an ‘i’ in Team, here’s our real life example of why you should listen to this individual and use the right tool for the job.

There is I in "team". Courtesy of Jaco Haasbroek.

There is an 'i' in Team. Courtesy of Jaco Haasbroek.

Another project kicks off

The designs have already been made when our development team kicks into gear. A version-controlled environment silently hums as team members work together on the same codebase. But there’s one team member that doesn’t need to care one bit about that codebase. Meet Elaine, one of our front-end interaction engineers.

Elaine is going to focus entirely on writing clean semantic HTML and CSS of the 5, 3 and gracefully degrading kind. Her individual goal within the team is to turn static designs made with Fireworks into real interactive web pages, a process that involves manually translating pixels to markup and stylesheets that is not for the faint of heart.

The team faced two options:

  1. Set up a running development environment on Elaine’s machine by doing a subversion checkout, have hibernated database dependencies, run a solr indexer and harvester process and then write ASP.NET MVC2 view pages based on a work-in-progress environment using object models and controllers that tend to change frequently over time and have a tendency to break when you least expect it.
  2. Write HTML and CSS in a separate environment.

Sure, there’s a slight exaggeration to the first option but it’s there to underline the importance of listening to the ‘i’ in Team: Elaine needs to focus solely on what she should be doing and that’s writing HTML and CSS without being distracted or interrupted by the development environment.

The team chose option 2 and use Quplo to do that, but here’s something interesting: you’d be wrong to think that all projects we do here at Q42 would automatically involve Quplo. In fact, it seems not everyone fully understands yet how Quplo could fit into the development process when the design has already been done and actual development is kicking in. So after Rahul explained the benefits to the team, I set out to write this blog post, as Quplo, perhaps surprisingly, can in fact be used beyond prototyping for this exact purpose.

Using Quplo for HTML and CSS production

For this project, Elaine could use Textmate, download jQuery, start writing HTML and put it all in a separate subversion branch. In fact it’s a pretty elegant approach that some of you might relate to. However, you might also relate to using an e-mail client when writing an e-mail, as it was designed with that specific purpose in mind.

In a similar way, Quplo was designed specifically for creating interactive web-based prototypes using HTML and CSS, ranging from low to high fidelity. By putting the focus on that, we’ve been able to distill everything you need when working on the front-end, which is exactly what Elaine will be doing. So we thought this was a good time to post a summary on why you should consider using Quplo for HTML and CSS production, if that is your specific goal within a  team:

  1. Focus. We didn’t set out to build a Swiss army knife IDE, but focused on writing HTML and CSS. You’ll notice that every step of the way from the editor, keyboard shortcuts and code completion to using browser tabs combined with full screen real estate.

    Quplo allows you to open up your sheets in different browser tabs, and work with a maximized writing canvas.

    Quplo allows you to open up your sheets in different browser tabs, and work with a maximized writing canvas.

  2. Goodies. Everything a front-end designer or developer needs is there. We call them goodies: javascript libraries such as jQuery or MooTools, CSS3 web fonts, loading images, icons, image uploading, scaling and cropping, you name it.
  3. Relax. No need to worry about backups or versioning.
  4. No redundancy. Don’t write the same HTML twice. Quplo offers HTML parts to be reused in pages, and we call them “parts” and “pages” because it makes things simple.
  5. Availability. The result is instantly available online to the client and the rest of the team, optionally secured with a password.
  6. Firebug. If you use Firebug to tweak CSS, Quplo offers a save button to make changes persistent. So no redoing Firebug changes when making things pixel perfect.

    Save CSS changes made with Firebug.

    Save CSS changes made with Firebug.

  7. Real data. Quplo allows you to work with with real data. Know that the design holds up when using titles longer than “Lorem Ipsum” or paragraphs that stretch to higher than 200 pixels.
  8. Export. Everything built with Quplo can be exported and converted to the development framework that the team is using.

Don’t take our word for it. Just sign up for free which will only take a minute, so you can get to know Quplo yourself and be the judge of whether it fits your needs.

And while we’re in beta you can use the invite code freeupgrade during the signup process to get a free taste of what paid accounts do for you. Already a registered user? Check out the details here on upgrading for free.

5 Comments

Ping RSS

  • Looks interesting… but what does it exactly offer for a hard-core emacs user, for example? I do all my writing (TeX, HTML, source code) using Emacs. Advantages?

    Cheers,

    Ruben
    Latest at my blog: 4 Reasons Why Pacman Is a Metaphor for Blogging

    by Ruben Berenguel • Sep 30th 2010 • 14:09

  • Ruben, Quplo does a lot of things for you which we described in the article that aren’t available in Emacs. I suggest you try it out for yourself by signing up for the free trial.

    by Rahul • Sep 30th 2010 • 15:09

  • How is the data from Quplo merged with the work of the rest of the team? This seems troublesome, especially if the interaction design changes when an earlier version has already been implemented.

    by Sjoerd Visscher • Sep 30th 2010 • 16:09

  • @SjoerdVisscher In this case, there isn’t a great way to do that with Quplo. You can copy/paste or you can use the exporter, but as Quplo was designed as a prototyping tool, not a tool to create final HTML/CSS, that problem hasn’t been solved. What we’re describing in this post is a use case for Quplo for which it wasn’t originally designed, which we’re seeing develop at Q42 due to the fact that it’s a really great HTML editor with several features supporting the HTML development process.

    In the situation described in the post, a complete visual design of the site is handed down via waterfall (despite being a Scrum project) to a HTML/CSS implementer. Most of this isn’t iterative. When we do have feedback, we discuss things with the visual designer and implement changes/tweaks in Quplo. Once the team is satisfied, the Quplo phase will be finalised and HTML will be moved to the development environment (ASP.NET in this case). Once there, we won’t iterate back to Quplo. If there are any changes necessary, we’ll make them in ASP.NET’s View Control system.

    Ideally you’d want to be able to iterate constantly between the different phases, but this is tough to design a solution for given the spectrum of different kinds of projects possible.

    by Rahul • Sep 30th 2010 • 16:09

  • Sjoerd, I took on Elaine’s role in another project here at Q42 (called “Vlak”) and all we did was agree on which html/css implementation was leading during development.

    I worked on the HTML, CSS and Javascript front-end in Quplo, while Kamil and the rest of the team worked on the technical implementation without any styling.

    Merging quplo’s results with the development branch was relatively easy; we simply handcopied the xhtml and css that quplo exports, which only took minutes.

    Near the end of the project we closed the quplo prototype though, and any design or interaction changes after that point in time were done only in the development branch.

    For us, this worked really great, and I even remember Kamil asking me things like “Hey Martin, I’m going to redo the entire Adlib integration tomorrow, which will break quite some stuff for a day or two. Is that okay with you?”. All I did was wait a few seconds on which he said “Oh, that’s right. You don’t care”. It made us grin, but it’s just another example of how all of us at a team had the benefit of working on our separate goals.

    by mrtnkl • Oct 1st 2010 • 09:10

  • Leave a reply