1. Choosing your first CMS: the checklist

    When creating a site for the first time, business owners are often constrained in resources and don't give much consideration to its business objectives or how well it will support their publishing workflow. The site gets done, deployed, and used on a budget, but in the longer term it often gets counter–productive to the business, causing it to lose visitors and customers. While every website (and business) is unique, there's a handful of critical points to be aware of for a good start.

    Choosing your first CMS: the checklist

  2. What's new?

    Hey there! Been a while. What's new?

    I haven't been updating this space for close to a year now — but what a great time it has been, full of learning and creating.

    FIRST OFF: For a long time, it has bothered me that some of my favorite sites don't have the best user experience to match their incredible content.

    Such sites are run by entrepreneurs (busy, results–driven people), and often operate under all sorts of constraints — financial, human resource, experience, etc. These websites suffer from what they don't know they don't know — that investment in usability and an integrated, multi–disiplinary web strategy can pay off enormously on the bottom line.

    The web development field is a fascinating place to be, full of conversations about cutting–edge web design, user experience, marketing, and content strategy. However, these conversations mainly stay within the professional circles and a certain type of client: large, corporate entities with the budget and manpower to afford the best practices; and the occasional tech–savvy start–up.

    Meanwhile, many sites that feature unique, valuable, and authoritative content — run by people who actually have something to say — often remain on the sidelines. That is because having a website is low–barrier; but to have the best possible site — to rise above average – demands resources and expertise that aren't available to every small web team.

    That's not good enough. What such teams need is a "Best Practices 101", a state–of–the–art primer on the crucial aspects of running a website that is clear, jargon–free, holistic, and actionable.

    I've been writing a book — Successful Website DNA — to be such a guide:

    The best workbook for a busy, content–driven, entrepreneurial web team possible, EVER. Period.

    I have a deep interest in Design, Usability, Information Architecture, and Website Optimization. The more I learned about these topics, the more I realized how far most sites are from implementing all the radically effective stuff these disciplines have to offer. There's no better way to learn about something than experimenting with it in one's own backyard; and trying to explain it to someone else. That's what Successful Website DNA is all about.

    SECONDLY, my recent experimentations with Ruby, Lisp, and Responsive Web Design have yielded a number of insights; these will be featured on the blog, one at a time. Here are just some tasters for content that's in the works:

    1. How to protoype your app effectively using a "data & functions" approach.

    2. Some experiments in combining multi–column layouts (enabled by the CSS3 multiple columns specification) with Responsive Web Design.

    3. A library of modular layout recipes — things you can drop in your layout — to illustrate some of the layout patterns I describe in Successful Website DNA.

    4. Between proofs and tests — simple but effective rules of thumb for writing quality code.

    5. Solving a programming puzzle, with the emphasis on problem–solving strategies driving code.

    6. A new category — Curateda repository of stuff from around the web that merits attention and study.

    7. How to put on 10 pounds of muscle while writing JavaScript.

    (OK, I'm kidding about the last one).

    As Nathan Ford reminds us, an expert is someone who compulsively shares what he or she learns. The take–away? Don't wait until you're an expert to write, talk, and share about your areas of interest. Initiate intense study, and grow into experthood through sharing your lessons.

    So stay tuned; I'm going to do just that.

  3. Test-driven development: two scenarios

    How teams recruit for TDD:

    Scenario 1

    Them: So, what do you think about Test-Driven Development?

    You: That’s the way I program. It makes the process more efficient and the end product more robust.

    Them: We have a strong TDD culture here, so we’re glad to hear that. Looks like you’d be a good match for us in that regard.

    Scenario 2

    Them: So, what do you think about Test-Driven-Development?

    You: That’s the way I program. It makes the process more efficient and the end product more robust.

    Them: Oh, great. Our app is a ball of messy code that breaks when we look at it. It’s not tested because our previous developer told us that in Ruby, testing is built-in. Aren’t you glad you’ll be getting down&dirty with it?!

    Moral of the story

    Developers: when showing enthusiasm for TDD, be aware of the context.

  4. Some screencasts I'd like to see

    I’ve written before about how much I enjoy home-brewed publications on software development. However, I often catch myself thinking: “If someone did a screencast about this, it would hit right home”. So, here are some screencasts I’d seriously consider paying for:

    "How to create a web app with Clojure". Check! Chas Emerick recently released this great screencast.

    A thorough, beginner-level, "Clojure with Emacs" screencast. Topics:

    • Thorough coverage of the environment set-up. Emacs Live + Swank + Slime would be especially interesting; that's my latest set-up.

    • Working with standalone files (as opposed to projects).

    • A programming exercise involving extensive use of the REPL. Thought process and coding rhythm in an interactive development mode. Why the REPL is much more than a shell.

    • Creating a small but self-contained project. Project directory structure, necessary scripts, importing files, dealing with dependencies, resolving namespaces, organizing main code and tests, running the project.

    "Emacs in Org-Mode for technical writing". This would be perfect for my Literate Code project for which I'm considering to implement HTML exporting from Org-Mode.

    An "Advanced Pry" screencast. On the ThinkRelevance podcast #007, Clinton Nixon talked about how he uses Pry. A great discussion of high-level Pry usage - especially the part on how to develop with Pry in parallel to the editor, so that when source code is modified in a Pry session these changes are reflected back in the editor. I use Pry to navigate around program state, but what Clinton talked about sounded like the next level. I’d really like to watch how a developer switches between the Pry session and the editor in the process of programming. Let’s call this one “Pry on Steroids: Interactive Ruby Development”.

    Just a few ideas off the top of my head. I may update this list if more come to mind.

  5. Some self-published programming books worth knowing about

    I'm delighted when I see a self-published book on software development. To take the time and put one's technical expertise into a book seems to be quite an undertaking. But this is exactly what more developers are doing nowadays, and the web's distribution mechanisms ensure that valuable material gets the attention it deserves.

    Speaking of attention, here is a list of self-published programming expertise that has gotten mine lately:

    Kestrels, Quirky Birds, and Hopeless Egocentricity, by Reginald Braithwaite. A book about Combinatory Logic, but illustrated with runnable Ruby programs. That just hits the sweet spot between theory and application. Ruby meta-programming is woven into the themes. A winner.

    Objects on Rails, by Avdi Grimm. This one is about putting OO good principles back in the process of web application development. True OO isn't easy to get right even when given good defaults. This book builds an application objects-first style, then builds the app infrastructure around it.

    (I've done database-backed application development, implemented an ORM from scratch, and used the MVC pattern for web applications. At some point, it dawned on me that this kind of project should start its life as a small, well-designed Object-Oriented system that models the core logic. Persistence and user interaction should be added as the next step.

    It makes more sense to develop one's models and business objects as working OO systems before persistence and interactivity are added. Why? For one, it makes for a more modular development process; therefore, better overview and rhythm. (To take time to focus on the core logic, and only it, will pay off as better design in the end). Secondly, this allows me to think more freely in the language of the domain I'm modeling. Thirdly, it is good for rapid prototyping, but on core logic level as opposed to the UI level.

    It's great to have a book that can validate (or invalidate) these thoughts).

    Clean Ruby, by Jim Gay. When Alan Kay was asked what Object-Orientation meant to him, he replied: "...messaging, local retention and protection and hiding of state-process, and extreme late binding of all things" (quoted from Cunningham & Cunningham, Inc).

    Much of what passes as OO today is class-oriented development. Static typing, no messaging mechanism, early binding, objects and non-objects (including classes).

    That's why Clean Ruby is interesting. It's about writing Ruby in accordance to the Data, Context, & Interaction (DCI) architectural pattern. DCI is about how an object's behavior is determined by roles the object can play. These roles can vary and they are typically acquired at runtime, ie when requested by other objects. Behavior is acquired, requested, and performed at runtime. DCI looks like OO.next() - taking the Smalltalk school of OO (from which Ruby has descended) to the extreme.

    I listened to Trygve Reenskaug give a presentation on DCI at Öredev 2009, and was surprised to hear him say that this paradigm could be implemented in any language. For a long time afterward, I waited for DCI to be illustrated with actual code instead of theoretical discussion.

    The fact that the first book on DCI comes from a Rubyist tells me that some languages might just be more OO than others.

    Some more good ones:

    The SPDY Book, by Chris Strom.

    Essential JavaScript Design Patterns, by Addi Osmani. Impressive.

    Working with Unix Processes, by Jesse Storimer. Unix concepts illustrated in Ruby - neat!

    Software development knowledge is acquired through hard work. Support your local self-published software expert.

  6. Some lessons learned while creating a cross-device design

    Recently, I released a small design project called Literate Code — an adaptive toolkit for laying out programming essays. I’ve come to a few insights in the process that I’d like to share here.

    First off, on the question of mobile first vs desktop first. I find that for the best outcome, the two have to be considered concurrently. One reason for this is that what goes into the "mobification" of a page is fairly uniform. Multiple columns collapse into one; grid views become list views; sidebars get collapsed to the bottom; font sizes may scale down; images may disappear or resize; etc. There is a core of best practices associated with best-looking mobile pages. To derive your desktop design from the conventions used by the mobile design doesn’t seem like the optimal way - especially if your desktop and large screen versions feature special design elements.

    How to you go about concurrent cross-device design? Start with the Information Architecture. Consider how each element of the layout represents an element in the site's overall Information Architecture. Draw a table: line each such element up against the X axis. Against the Y axis, arrange Desktop, Tablet, & Mobile. For each cell, decide (first of all) whether that element should show. If yes, consider in which way: grid vs list, number of columns, floated or collapsed to the bottom, etc.

    It's a good way to approach cross–device design in a holistic, architecture–first way.

    Secondly, responsive vs adaptive. When word came out about Responsive Web Design, I jumped on the bandwagon and started designing fluid pages; this meant using percentage-based widths for containers. Then two things happened: I learned about the work of Joni Korpi - which showed me how one can adapt to varying viewport widths by smart re-sizing of screen space using narrow columns. And, I had a (rather spirited) email discussion with Peter Collingridge from Enhanced Editions.

    The gist of Peter's argument was: Web pages should follow established principles of print (and specifically, book) typography. In book design, line width provides the visual scaffolding upon which the layout builds; this isn't arbitrary. Certain ranges for line width yields best results in terms of readability (Robert Bringhurst recommends 45–75 characters for single-column pages, with 66 being "ideal"; and 40–50 characters for multi-column pages.)

    So a "responsive" page has to be careful to stay within those boundaries - which is hard to do when that page is fluid. Line length is a design’s contract with the user, and violating that contract isn’t good.

    I was convinced, and here’s why: cross-device design with static container widths (Adaptive Static Design) gives you a better way of utilizing screen real estate. Instead of resizing (responding?) pixel–by–pixel, you’re adapting column–by–column. Look at what happens to page margins as you resize a responsive page (try with the one you're reading). Text and margins resize simultaneously, right? Now try this with an adaptive page.

    To appreciate this, look at what happens when you resize a "fully fluid" responsive page, one that uses percentage–based sizing in all viewport ranges. Text and margins resize simultaneously, right? When the browser shrinks, everything within it shrinks. Now try resizing an adaptive page — the one you're reading.

    Now, you are creating and consuming margins as the viewport needs. When the margins on each side become consumed by the shrinking browser window, the text area gets reduced by two columns, one on each side. These released columns now create a new pair of margins for the text; this will be the next whitespace frontier to be consumed. And so it goes on: first, consume the current margins, then create a new set of margins by reducing the text area. When the viewport increases in size, the process is reversed.

    This results in a more efficient use of whitespace. Why change the line width of text when there's plenty of whitespace to feed to the browser window? Seems silly. Also, the usability is better. The line does’t dance around with each move of the mouse. It changes in a split second to a different "good default". The contract between design and user is maintained. The line stays within boundaries given by optimal widths.

    Basically, this allows one to use whitespace (the margins) to protect the integrity of the line of text. In turn, lines that stay constant in length or adapt column–by–column protect the integrity of the overall design. The question is then how to create several designs that each is optimal in the graphical, usability, and Information Architecture aspects, and then switch between those depending on the device (viewport width). I find this to be a compelling approach.

    Reflections

    One characteristic of cross-browser design is that the line between code, design, usability, and IA is blurred. Interestingly, this makes cross-browser design more Agile: you need to test more (simply because there are more devices to view the site on); iterate quicker (more code means that errors can multiply); and you need people of different skill sets collaborating. That is cool.

    Update Updated the article to reflect the fact that this site is now responsive in the "adaptive static" way, and not in the "fully-fluid" way as of the time of writing.