Cloud Mouth

I recently started using Blueprint, a CSS framework “which aims to cut down on your CSS development time”, for a Web development project. I have found I can whip up a nicely laid out site that works across all browsers *much* faster with Blueprint than I could without it. As a result, I spend more time on creating business value and less time dealing with the many obscure bugs in Internet Explorer 6.

Having said that, I’ve had the opposite experience with other frameworks. This got me thinking, “What makes a good framework?”

Note: In the below examples, I compare Blueprint with Microsoft’s ASP.Net. Admittedly, this is sort of an apples-to-oranges comparison: ASP.Net is for server-side Web development whereas Blueprint is for client-side Web development. Nonetheless, they are two frameworks I am actively using and hence enable me to give personal examples.

Note 2: Even though I seem to suggest otherwise below, much of ASP.Net is great. In fact, we use it to power Faves.com. We just stay away from the parts of the framework that violate the following criteria.

With that out of the way, I think a good framework is one that ultimately saves time and/or cuts costs in meeting business objectives because it

• Avoids reinventing the wheel: This is arguably *the* point of choosing a framework instead of coding something directly. For example, the Blueprint framework gives me the following that I would otherwise have to create myself:
  
  • An easily customizable grid
  • Sensible typography
  • Relative font-sizes everywhere
  • A typographic baseline
  • Perfected CSS reset
  • A stylesheet for printing
    
    
• Still lets me do things the “raw” way: All frameworks have their limitations, and I often have to revert to doing something outside the framework. When using Blueprint on a page, I can still mix in my own non-Blueprint CSS styling and layout. On the other hand, if I want to use some of my favorite ASP.Net controls on a page, I am forced to adopt the ASP.Net Web Forms model and its associated evils for the entire page.
  
  
• Takes less time to learn than how much it will ultimately save: Blueprint *is* a subset of XHTML and CSS. ASP.Net, in an effort to make things easy for the novice user, actually makes me understand a completely different model. Ironically, this can make things more difficult for the seasoned developer.
  
  
• Creates consistency across the team: Implicit in using Blueprint is a set of naming conventions. This makes it much easier for a team of developers (or if using a Blueprint with a CMS, the content creators) to specify and read each others’ layouts.
  
  
• Follows best practices: The framework should deliver as is “generally expected”. For example, there are a number of SEO best practices for having your site properly indexed by search engines. But, ASP.Net violates a number of these, including this one. I need to find creative ways to work around each violation, costing me time and money. Ideally, best practices compliance is just included.
  
  
• Lets me view the source code: There are times I need to know what exactly the framework is doing in order to diagnose or prevent bugs.
  
  
• Is high performance: Slow performance is an issue if it *meaningfully* degrades the customer experience or *meaningfully* increases server and support costs as compared to how much time and money I am saving by using the framework.

I am currently reading Scott Berkun’s excellent book on project management, Making Things Happen and am enjoying it for it’s directness. It goes straight to the essence of being an effective project manager and leaves specific methodologies to other books.

His How to figure out what to do chapter is a good refresher, stating that the best project managers are multidisciplinary and able to synthesize business, customer, and technology viewpoints:

To me, this Venn diagram is *the* measuring stick for project-oriented settings, even when you are not the project manager:

• When you’re looking for a job: Is the organization setup for success, with strong representation in all three areas?
• When you’re writing a business plan: Does the plan adequately cover all three areas?  Or more specifically, does it answer the questions that should be asked of each of the three areas?
• When you’re building a project team: Have you allocated sufficient headcount in each of the three areas?
• When you’re a programmer at Microsoft (in an ideal world): Are you making engineering decisions with the key business drivers and customer needs & pain points in mind?

Later on in the chapter, he dives into the customer research component, describing how it is often incomplete or outright invalid — with folks ascribing too much importance to a single research method. Customer research experts make use of multiple methods, including focus groups, surveys, site visits, usability studies, and market research to make up for the limitiations in each individual method.

The entire chapter, containing an analysis of each research method, is available online for free [pdf].