First of all, it’s important that we can access all our documents and applications from anywhere. Thankfully, that’s easily taken care of with online services like Google Apps and Dropbox.

A more serious challenge is how to facilitate social interactions. We need to collaborate effectively, but beyond that, we need to forge and maintain a bond between us. No one should feel isolated because being in the office is not an option. No one should be left out of the loop on important issues. No one should miss a chance to follow and contribute to what other team members do.

Our approach is to rely exclusively on online chat. Yes, it’s a bit awkward when 2 persons in the same office discuss silently on a chat, but the truth is that a conversation in a purely textual form has many benefits. For one, it’s a searchable record of what we’ve discussed and of every decision we’ve made. Discussions also tends to be more to the point, without long-winded arguments or repetitions. It’s not intrusive, so you can easily ignore a topic and save yourself the interruption, and finally, it’s accessible. You can quickly catch up and jump in whenever you feel like it.

Our experience with Campfire

For companies like us, the best role model is 37signals, so we naturally gravitated toward their online chat application, Campfire.

For about a year, we used Campfire for almost everything.  We used it for water-cooler chat,  to share information, to collaborate on customer issues and to discuss projects.

We also have a Basecamp account to manage our internal projects, but we found that we weren’t using it that much. Basecamp is good for sharing information asynchronously, in organized, well thought out bits (this shows that Basecamp was originally designed for client projects), but that’s not really how we work. We need the quick back and forth of a chat. It’s also not practical to have information spread across different applications.

So we stayed on Campfire, but it wasn’t ideal either. Discussions lacked structure, moving too quickly from one topic to the next. Action items would disappear from view, pushed back in the history. (Note that Campfire has the concept of “rooms”, but it didn’t seem practical, so we never really used it.)

We needed some sort of middle ground, so we decided to try Google Wave for a while and see how it went.

Switching to Google Wave

Google Wave is an instant collaboration tool. Discussions can be threaded, so we can cover several topics in parallel and keep them organized. We can create new “waves” as needed and easily follow the activity in  each wave from the “inbox”.  There’s an helpful “next unread” button that makes sure we don’t miss any message, regardless of where it’s posted. Of course, Wave is searchable too.

Each day we create two waves, one for a general chat and one to discuss customer support issues. In the support wave, we can keep each issue in its own thread. This lets us keep track of the work done and of who needs help to troubleshoot an issue.

We also have a weekly wave, where we list our priorities for the week. Everyone can update it if needed with a short status report. Finally, we have specific waves for long-term projects, where we collect our thoughts, post screenshots, discuss mockups and so on.

Google Wave isn’t perfect though. We found that sharing screenshots and mockups was difficult. Wave seems to downsample images, so we would always end up with blurry, unusable mockups. We had to resort to hosting images on dropbox and posting links to Wave. There are a few other irritating quirks, like the odd scroll bars that won’t let you scroll to the end of a wave in one try or the lack of audio notification (there are semi-reliable plugins for that).

Overall, we’re happy with Google Wave. We’ve consolidated two applications in one and it fits us well. When Wave launched, it had this reputation of being a tool nobody knew what it was for.  A sort of email-collaboration-programmable mash-up, with plugins and bots.  Turns out, it simpler than it sounds. The bare bone Wave is just what we need to run our business.

We try to be specific in our job descriptions, but we are in fact quite flexible and open minded. We don’t want to tell you that you must meet some arbitrary criteria, or that you have to apply in any particular way.

There are some common practices though that we find particularly irksome. Here are a few definite mistakes you should avoid when applying for a job here.

1. Not doing any research about us, about what we do, and about what we’re looking for. Some tell tale signs are:

• Sending us a generic cover letter.
• Not being specific about what you like about the job or our company.
• Talking in length about an unrelated technology or experience.

2. Filling your resume with vague and unsubstantiated statements (also known as bulls**t). Things like:

• “I am a good listener with good communication skills.”
• “I have a solid work ethic, and a desire to excel and meet deadlines.”
• “Excellent analytical and problem solving skills with ability to communicate effectively with peers.”‘

3. Showing a lack of discernment by listing every single project you’ve worked on, job you’ve had, course you’ve taken, skill you’ve learned, or software you’ve used. For instance, avoid:

• Listing your knowledge of various OS flavors or trivial software.
• Listing obsolete technologies or languages.
• Listing seminars or workshops you’ve attended.

Here are a few things you can do to help your chances:

• Make sure to show in your cover letter that you’ve read this. For instance, you could tell us about your favorite candy ;-)
• Sign up for our free service and give it a test drive, and then do the same with one of our competitor. The best way to impress us is to suggest improvements.
• Give us objective metrics:  grades,  ranks,  links to publications, contributions to open-source projects, etc..
• Show us something you’ve created in your spare time. Software, writing, furniture, whatever.
• Follow up even if you don’t hear back from us.

Our job openings are listed here. Get in touch with us if you’d like to apply. We’re looking forward to meeting you!

We’re not trying to change the world (just yet).  We’re patient. We take one day at a time. We try to better ourselves, to learn and master our craft.

We believe in opinionated software, but we don’t pretend to know everything our customers need.   We listen to them and if we can make their jobs a little bit easier, then we’re good.

Perhaps our most precious resource is the time our customers give us – time spent learning and using our software. We try to not abuse it.

Results are, in turn, the only thing we demand from ourselves. We work from home, coffee shops, or the office.  Hours and location don’t matter. Efficiency matters. We don’t work hard/play hard. We just tend our work; we get it right, we get it done, and we don’t make it hard.

We have the tools, the technology, the skills, and the freedom to make our job what we would like it to be: that is, rewarding, peaceful, useful, and meaningful. It’s not always like that of course. Our job can sometimes be tedious or stressful, but we’re always on the lookout for better ways to work and get things done.

If this sounds appealing, please join us. We need all the help we can get!

We track a lot of information with Google Analytics. Goal conversion rates, e-commerce revenues, adword campaigns, search keywords, referrers and so on. Collecting information is easy, but trying to make sense of it can be frustrating.

Google wants me to drown in a sea of data

I often find myself wandering through the Google Analytics reports, marveling at the shiny graphs or noting with curiosity that the middle of the month is always slower. While my intellectual curiosity might be satisfied, I’m still left confused, unsure about which variable to tweak and nothing to act on.

I eventually learned that, like Ulysses who tied himself to the mast to resist the alluring chants of Sirens, diving into the reports requires self-discipline and focus. First identify a specific page, then a metric, write it down and do not look at anything else.  Then go and try to improve it.

Another thing I learned is that you can’t just compare the performance of a page before and after a change and decide whether the change was a good idea or not.

Traffic is not a constant. It varies over time, quite significantly. One week the conversion rate is great, and the next one it sucks even though nothing changed on the site. Perhaps it’s a surge of unqualified visitors, or people who get antsy over the latest economic news, or just a random fluke.

I’m not willing to wait days or weeks for a clear pattern to emerge. If my new page is not performing as well, I’d like to  undo my mistake as quickly as possible.

That’s where A/B testing is really useful. It works by randomly splitting your incoming traffic between 2 different versions of a same page. With the appropriate tracking tool, it’s then very easy to see which page performs better.

Google the merciful rewards the faithful

So I finally decided to take a second look at Google’s Website Optimizer, a free A/B testing service.  I wasn’t convinced the first time around. It was rather limited, and I thought that our esteemed visitors would not be swayed one way or another just because we make our marketing copy a bit more clever. After all, we firmly believe in the greatness of the product we’re building,  shouldn’t it just sell by itself?

Well, it turns out that Website Optimizer got a lot better. It’s very easy to set up, you can test pretty much anything and it provides unambiguous results quickly.

No more trying to decipher the reports and understand what’s going on. No more agonizing over a design decision. Should it be a link or a button? Should it say ‘Sign up now’ or ‘Try it for Free’? Just try both and let Google tell you which one works best.

And when the result  is a 300% improvement in conversion rate, I sure feel stupid for not doing it sooner.

I’m not going to criticize this approach but I honestly thought there would be more young entrepreneurs in the Valley interested in emulating companies like Salesforce or 37signals.

It is quite ironic that David Heinemeier Hansson is seen as going against the grain, when his presentation was packed with nothing but grounded advice and a healthy dose of common sense. What’s wrong with the old true and tested way of charging money for your service?

Interestingly, DHH also said that Backback (37signals’ second app after Basecamp), had to be rebranded and relaunched as a “business” application when they realized that the consumer market wasn’t really profitable.

There was maybe one theme missing from the picture though. Building a successful business takes time and hard work. A lot of time and a lot of work, so it was great to meet you all, I have to go back to work now.

The On-Site edition offers the same great features enjoyed by thousands of our online users, but you can run it on your own server and keep your data safe and private.

FormAssembly On-Site is a reliable and secure solution designed to work on the most widely available configurations: Windows or Unix, IIS or Apache, and with any of the major database vendors. The support for such a wide range of technologies is made possible by the great open-source framework FormAssembly is built upon.

You can learn more about FormAssembly On-Site at http://onsite.formassembly.com

Several commenters have pointed out that @importRule would not be that useful since you can already assign more than one CSS class to an element.

However, having (apparently) some time to waste this morning, I thought it would be interesting to implement this pseudo css rule anyway.

Here’s the example page, with a short explanation of the (very simplistic) javascript:

Again, I’m not claiming that this is very useful, but if one wanted to create a javascript css post-processor, that would be a good way to start.

After months of work, the new FormAssembly.com is nearing completion.

This new version is a complete re-write, and since it is hosted on a completely separate platform, we are looking forward to a very smooth transition, with the two versions running concurrently for as long as necessary.

The feedback from the early beta-testers is pretty good. There are also plenty of new (and long requested) features, so I’m confident that our users will be happy with the new version.

I will also look at the traffic and conversion numbers attentively anxiously. In theory, the new site should perform much better, but sometimes what sells is really not what you think, so it will be interesting to compare the numbers. I’ll try to post my findings here.

A simple demonstration is available here, with all the explanations here.

Version 2.1 includes bug fixes and performance improvements. The major changes are:

• Upgraded to latest version of Sarissa (0.9.7.6)
• XSL stylesheet should now set the XSL:output method to “HTML”. This prevents an unnecessary HTML serialization & parsing step and avoids invalid HTML markup altogether, like self-closing <textarea/>. While this change makes 2.1 not backward compatible, this should be the only required change if you are using Freja 2.0.

I also updated the documentation and tutorials, which were beginning to be seriously out-of-date.

The Freja core development team is comprised of Cedric Savarese and Troels Knak-Nielsen. Freja is an Open-Source framework built on top of the Sarissa library by Manos Batsis.