I wrote the following answer in May 2012. It's now October 2014, over two years later, and I'm amending it because I've come to realise my original answer was basically wrong
. It misses the forest for the trees.
Our quality has been inconsistent, with more misses than hits lately, and it's left me wondering why. I think I now understand.
When you start with a clean slate, what you draw on it is entirely up to you. You're totally in charge. HasGeek started with a clean slate. We had no code, no business, no deadlines and no reputation. No legacy
to sustain. You have to be a total n00b
to screw up when you start from scratch.
But most of us don't have the luxury of starting from scratch. We are building on existing code, designs and businesses, and have legacies we can't simply discard. Even if we have the option of starting afresh, we can't always afford it. Building from scratch requires considerable
time and effort to get to a viable prototype, and in the technology industry the ground is always shifting beneath our feet.
first went public, someone asked me what WordPress theme we had used. I was offended that my work seemed so trivial to him. He had trouble understanding that I'd attempt to write my own WP theme instead of downloading one from somewhere and focusing on the business side of the operation or (*gasp*)
that I'd be crazy enough build a CMS from scratch instead of just using WordPress like everyone else.
This is legacy
: past work that powers the new operation, that you've either acquired or inherited, and that you must update to suit your requirements. When you're working with a legacy, you're not simply building
on top of it. Often you're tearing down
parts of it, and tearing down is an entirely different sort of skill from building. Tearing down is politics
Good design isn't just how it looks, it's how it works, all the way down to the business model. If you're working on a new design with a legacy, you're tearing down parts of that legacy, and that could mean firing people, changing their job description, losing customers and partners who don't understand what you are up to, and generally overcoming resistance from the people you need as allies. Bet you didn't learn any of that in design school.
Have you wondered why most hardware makers don't list prices on their website or print ads, even though that's the crucial bit you want to know? It's because they got established in a pre-ecommerce era, when sales happened via retail dealers, and the dealers controlled what price was offered to customers. A manufacturer revealing the price to end customers undermines the dealer's negotiating power when making the sale.
A simple design change like listing the price required reworking an entire business model, and the winners like Apple were those that had the courage to tear down their own legacy.
HasGeek is now turning four and we've built our own legacy of code architecture and business models. To continue to remain innovative in design, we'll have discard parts of what we've built and hold dear. Do we have it in us? We'll find out.
Original answer below.
It starts with your philosophy as an organization. We consider the people who come to our events as our primary customers. When you focus on a single user group, it's really easy to meet their needs without worrying about who you are pissing off by not giving enough attention to.
Second, we are a really small team. When I started HasGeek, I built all the sites myself. I don't have graphic design skills, so I built websites with no images (DocType HTML5), or with simple pattern images from free collections (HasGeek Job Board). My process was to look at other sites with similar purposes (event websites, other job boards), note down everything that seemed like a good idea, and then put them on a page and in the interaction flow.
I'd then spend hours looking at the page, tweaking minor things like the shade of gray in separation lines or the spacing between elements. I'm partially colour-blind and have trouble distinguishing light green from yellow (and dark green from brown), so I avoid those colours entirely, working with reds and blues instead. There's no major science or art to this. I liked how vibrant Vimeo's colour palette was, so I went to ColourLovers and browsed for nice looking colour combinations.
Since I wasn't paying someone by the hour, nor had investors breathing down my neck, I could afford to go nuts spending endless hours tweaking little things and learning new tricks. My time had little value in the early days of HasGeek and, IMHO, being obsessed as a user of your own work makes a big difference.
With PHPCloud, I wanted to try something different but couldn't draw for nuts, so I talked to my friends at PPTSalon (Abhisek Sarda
is an ex-colleague). I made sketches of what I wanted, then took a bus to Goa and spent three days in their office working with their illustrator (Kaustubh Kamat). This made a huge difference to how quickly we got things done.
When you outsource work, you have to detail it up front, then wait days or even weeks to see what your designers have produced, give them feedback, and wait again. Any sensible design agency will bill by the hour (sometimes in blocks of days or weeks at a time), so one day you'll run out of budget and end up shelling out more, or more likely will can the project and use whatever you have so far, whether or not it's suitable. You run the risk that the designer doesn't understand what you want. I had to explain tech geek culture to design geeks. Your designers in turn may not trust you to know what's good for you (will you insist on Comic Sans because it looks friendly?).
It's important that you establish a high degree of trust with your design agency and you work closely with them to shorten the communication cycles. PPTSalon didn't have a good HTML/CSS/JS person at that time, so I took Photoshop files and turned them into HTML myself. We had enthusiastic volunteers by that point who helped with the process. For instance, I had never used CSS sprites. Aditya Yadav
took my HTML for the website and turned all the images into sprites. Aditya later coded the JSFoo website, for which PPTSalon again produced illustrations, based on a design theme I suggested to them.
HasGeek is now six people and we're trying to do an event every month, each with its own unique website. With such short cycles, we can no longer afford to spend hours obsessing over little details, so we now work in teams. Rahul Gonsalves
at Pixelogue managed the Droidcon website, PPTSalon made the illustrations, and Prateek Rungta at Miranj
coded it. I was too busy producing the event to work on the website. From Prateek's work, I learnt how to do responsive design, where the page layout adapts to the device's resolution and capabilities.
We've found that it's really hard to take a website from concept to execution in less than a month, and execution suffers if too many people work on it. (Droidcon's three-party process worked because Rahul is a great manager; the same three parties also built Rubymonk's website around the same time.) We now have teams working on different websites two to three months in advance. Parag Gupta built the Cartonama Workshop website while at the same time Prateek Rungta (Miranj
) built the Meta Refresh website.
The downside of doing this is that the quality of the work is not consistent from website to website. With each event we learn something more about how users use the website, but the next one is by a different person who hasn't internalized the learnings, so we end up with last minute patching. We also end up rebuilding layouts each time instead of reusing whatever worked the previous time.
Between Feb and March this year, I started working on a standardized "base frame" for all our websites, built on top of Twitter Bootstrap. I didn't bother to make specs, instead building it by feel
for a simple expense tracker app for internal use. It was tricky coding an app in two parts, with one containing all the reusable functionality. I grew frustrated and threw away all the work and started over more than once (switching back and forth between Zurb Foundation and Twitter Bootstrap), until finally settling on Bootstrap and coming up with a reasonable way to separate the parts. Prateek then built the Meta Refresh website with baseframe, and Parag is using it for The Fifth Elephant. I'm using it for HasGeek TV, which I hope to release before the end of May. Each of these websites looks completely different, but the effort they take is less than half what we spent on last year's websites, so that counts as progress. I'm hoping to find time for the next project, a mini-CMS "event frame" that makes per-event re-skinning even simpler.
There's been a fair bit of common tech across all these projects:
1. We use Sass with Compass for stylesheets. I've evaluated Sass and Less and I prefer Sass. It's the more mature of the two, having been around longer. (Aditya prefers Stylus and used it for JSFoo.) Initially, I misunderstood how Sass+Compass are to be used. Since they come with convenient mix-ins, I went wild giving every element of my pages an id and giving that id a custom style. You'll see this in the PHPCloud website. Later on I learnt about stylesheet reuse by defining "behaviour" classes and combining them in HTML (declarations like <a class="btn disabled"> rather than <a id="submit-disabled-button">). Behaviour classes make your stylesheets more manageable as your codebase gets larger, but they are also a harder concept to grasp.
2. Code decays with time, so I prefer to avoid dynamic websites for events. No one cares for the website when the event is over, but the code that powers it has to be kept running forever, and that is a maintenance liability. DocType HTML5 ran off a Flask server that manages user registrations, but the event series is over and you can no longer register, so that code is now lying around decaying, just waiting for someone to find a flaw and hack it to display spam or steal the old registration databases. AndroidCamp and PHPCloud's websites are plain HTML files served by Apache. JSFoo runs on Node.js because we initially experimented with including IRC chat on the website, powered by Socket.io
. That didn't make it into production, so we now have a Node.js server serving up a static website and doing nothing else (waste of RAM and CPU, and likely target for a security vulnerability). I should switch it to plain HTML.
The new websites run on Flask+baseframe, soon to be Flask+eventframe. This time we expect to maintain this code for future websites, so it's okay for them to be dynamic. By serving dynamically, I can use webassets to compress JS and CSS, and in future serve them from a CDN URL.
3. We used HTML5 Boilerplate for the initial websites, Zurb Foundation for one, and Twitter Bootstrap for everything since late March. Our copy of Bootstrap is customized and extended. I've borrowed many ideas from Boilerplate, added print stylesheets, and tweaked Bootstrap wherever I didn't like the way it did something.
I'm still not happy with Bootstrap's typographic grid. Lines don't line up properly if you have mixed headlines and paragraphs in two columns.See question on Quora