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) design. 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. Now, you are creating and consuming margins as the browser needs. When the margins on each side become consumed by the shrinking browser window, the text area gets resized and a new pair of margins becomes available. This will be the next whitespace frontier to be consumed. And so on: first, eat up the current margins, then create a new set of margins and reduce 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.

Lisp changes the way you think.

I could leave it at that, and this would be the world’s shortest blog entry.

Or, I could write a longish exposition, with code walk-throughs, of a recent experiment I’ve done with solving a programming puzzle using first the object-oriented way, then more of a data-first, functional way.

The former sounds too cryptic. The latter feels a bit complicated. (I’m the kind of person who loses interest in a problem once it has been solved). But, the lessons I’ve learned are priceless. They are a paradigm shift (tired as it sounds) in my ability to write programs and solve problems.

(The short story is that functional programming wins. I was using Ruby, a hybrid language that lets one emphasize either the OO way or the functional way in the scope of a problem. This is perhaps Ruby’s greatest strength: one can hybridize styles on the fly. But the experiment itself was inspired by my recent exposures to Clojure, Lisp, and Rich Hickey’s talks on Clojure, state, simplicity, and functional programming).

So, in the name of contributing with something constructive and not being a “knowledge sink”, here’s a version that strikes a middle ground. It’s a list of principles and observations written in a short, koan-type style. No in-depth explanations are given; no examples. Just sharp arrows pointing to the truth.

• When confronted with a problem for the first time, answer three questions first: 1) what is the data we’re dealing with; 2) how is this data represented; 3) what are the main functions we need to turn this data into a solution. Data and functions are the core of any solution.

• Run your program against a real data set as early as possible.

• Just because the problem can be reduced to graph theory doesn’t mean we need graph objects or node or edge objects. By putting functions first, we can solve the problem in a leaner way, without adding a new level of abstraction.

• Objects = state, behavior, identity. Here’s how to create nicer smelling objects: get rid of state first. Minimize variables, all kinds of them. Behavior is methods. Simplify these by designing them for chainability. This way, you force them to return values. Functions operate on data. Then, decide which ones to put outside of objects. What is left is identity. It then becomes the sum of that object’s properties.

• Your objects are records. In other words: simple groupings of key / value pairs. Think JSON strings or JavaScript objects. (Or Clojure records).

• Favor data literals over data objects or variables (i.e., not a string variable, but a literal string).

• Use data structure literals liberally. Data structure literals (arrays, hashes, sets) are valuable because they reveal data and the containing structure in the context in which these appear. It is easy to see both structure and the values it encapsulates. This makes for more transparent programs and easier reasoning. Use data structures to expose data, not hide it.

• Favor functions that take a collection and return a new one.

• Bring data and data structures to the fore of your program.

• At some level, any computer works by manipulating 0’s and 1’s. At some level, any object works by manipulating data structures: arrays, hashes, sets. Also at some level, any object works by manipulating strings and numbers (primitive values). Therefore:

• When solving a problem, first compose a solution using these three core data structures and their combinations (array of hashes; hash of arrays; array of arrays). Resort to creating objects when this approach results in more complexity than needed. For example, you have an array of arrays that is n levels deep. At some level < n, you need a different structure because the arrays below that level need to be grouped according to other criteria. Create a record to contain those arrays.

• When solving a problem, make functions operate on primitive data types to the extent possible. Replace objects and records with their string or numeric representations. Powerful functions operating on primitive values are a great way to prototype any algorithm. They are a great way to come to the core of the problem quickly and head-on.

I'm morphing into a Lisp hacker. I'm shapeshifting. God help me.

PS. ;-)

If you've watched the Rich Hickey videos about the philosophical underpinnings of Clojure and would like to get practical with the language, I recommend watching the "Intro to Clojure" series of videos created by Code School. I find this to be a brilliant introduction to Clojure and Lisp - as dense and comprehensive as one can get in 10 videos of about 8 minute average duration.

The presentation is lucid and moves at a pleasant pace. What I especially like about this series is the great balance between the conceptual and the practical. Lisp concepts are illustrated using small, transparent code examples. This explains the core principles straight-on in a concrete manner without wandering off into abstractions and indirection.

Lisp is really more of a model of expression evaluation than a "typical" programming language and the videos make that extremely clear.

Topics covered, among others:

• What does being a "functional language" truly mean. Gold nuggets here!
• Clojure Persistent Collections and their implications for memory
• How object equality and identity are handled in Clojure
• List evaluation; symbols to vars and lists to function calls
• The two parts of Lisp code execution - the Reader and the Evaluator
• Organization of code: vars, symbols, function calls, and namespaces
• Calling Java from Clojure and Java objects in Clojure
• How language constructs (special forms) are evaluated compared to other expressions
• Literal evaluation with quoting
• Some great points about indentation of Clojure code compared to other dialects of Lisp
• Lexical scope and how it relates to referencing code in a different namespace
• Tail recursion
• Macros and code as data
• Lazy sequences
• Object Orientation in the light of Clojure-style functional programming
• Multimethods and variatic functions (functions with optional parameters)
• A short discussion of concurrent programming.

I feel I am more ready to take on Clojure after watching these videos. Check them out.

Here's to the giants of the digital age we lost this year - the inventors, scientists, & entrepreneurs. The list is by no means exclusive; it's just off the top of my head.

Paul Baran (1926-2011), one of the architects of the Internet.

John McCarthy (1927-2011), inventor of Lisp, one of the key figures of Artificial Intelligence research.

Dennis Ritchie (1941-2011), creator of the C programming language, co-creator of Unix.

Steven Paul Jobs (1955-2011), founder of Apple, inventor of the Macintosh, the iPhone, and the iPad.

They helped define the sandbox in which we get to play. And they thought thoughts that have a gotten a life of their own - powerful ideas that we find ourselves re-thinking, validating, and building on.

Want to know who wants to control how you use the web? Look no further:

List of companies that support SOPA (PDF).

Oh, and Merry Christmas everyone :-)

I am ever fascinated by the amount of new business books whose mission it is to convey to The Enterprise the benefits and finer details of having a "Social Media Strategy". It reminds me of the time every such business was searching for ways to profit from "this Internet thing".

I'd like to help. If you find yourself asking "How can I use social media to my company's advantage", your problem is likely not the lack of strategy; you might benefit from developing some social intelligence instead.

After all, we don't want to complicate things further do we. Using social media is totally self-explanatory!

Here's how (you can call it strategy of you will):

• Share what you like. Share what you find interesting & valuable.
• Like what others share. Comment, share, propagate, & like what others share and you like.
• Be somebody. Do something. Create value. Then, share that value and give people a way to like it and to find you.
• Do this on a continuous basis and make sure you're not pestering people.

Is that all? Where is the "strategy" part? Well, do you need a "party strategy" or a "socializing strategy" or a "how to get friends strategy"? What about a "how to be liked by other people strategy"? If you do, chances are no amount of "strategy" will help you. Good luck with the Interwebs.

Imagine there was a part of the world where speech was truly free, information was readily available, and the whole of humanity's intellectual capital could be accessed in a few seconds. A place where everyone with a solution could reach everyone else who needed that solution instantly and at (almost) no cost. Where knowledge was shared freely, contributed by everyone who had something to contribute, and thus amplified far beyond the capability of any one individual or group of people. A world where the cost of starting a business is often zero and where the best always rises to the top. A place to meet new people, learn things you didn't know you didn't know, and find opportunities that could turn your life in fresh, unknown directions.

Sounds familiar? We are all living in this reality right now - it's called the Internet. Chances are, if you have ever used a computer you have derived value from the Internet in some way and degree. The dream is here; the opportunity is now.

What about "sounds to good to be true"? Well, this might in fact become just a fantasy. If you and I don't take action, that is. Apparently, some people in the entertainment industry are not very happy with this Internet situation. They say it is used to steal the artists' work from them. To prevent this thievery, these people are lobbying the US government to pass some laws that will change how we use the web.

But this is a cover-up. The reality is, those entertainment industry people are middlemen, not artists. And the Internet is making their business model obsolete. Examples of artists who are using the Internet to find an audience are left, right and center. Ask Justin Bieber how he got to be so famous as to reportedly sell 50% of all music sold in the 2010.

We knew this all along: for every business model the Internet destroys, it creates ten new ones. But those people don't see it that way. They don't want to evolve with the time and adapt to the new reality. Instead of looking for ways to make the Internet work for them, they want to control how you and I use it. And in that process, they want to damage it.

This is ironic. The Internet is the closest the humanity has come to a free market economy in its entire existence. And now some business is lobbying the politicians to make it less free.

Listen, this thing called the Internet is not just a bunch of machines connected by a bunch of wires. It is a value system and a system for self-governance. EVERYTHING valuable about it comes from the fact that it's free. We have all grown accustomed to it; turn on your computer, and it's there. Herein lies the danger: if we take it for granted we could wake up one day and discover we cannot recognize it anymore. The forces that want to pass this bill like speed and stealth; and bribes - generous amounts of bribes. They want to achieve their objective under our collective radar.

I'm not too worried about Hollywood's capacity to get this legislation adopted. The Internet economy is massively bigger than them. It generates more revenue, creates more jobs, and produces more value. As one reader remarked, if only Google and Facebook blocked their US users for one day to give everyone a taste of an Internet-crippled future, the lawmakers would change their minds rather quickly.

But they don't have to - if we the users make our voice heard. Whether you tell your friends, tweet, blog like I just did, or find other ways to say no to SOPA, we're making sure we send a clear signal and those who need to receive it, do. In due time.

I just donated to Wikipedia. Here's why:

• When my schoolbook on Algorithms & Data Structures wasn't enough, Wikipedia articles on dynamic programming helped me make the exam.

• Technical articles on Wikipedia are of outstanding quality. Articles on data structures, programming paradigms, and math topics are lucid, detailed, and full of working examples. It's not just the ADT, it's the pseudocode and very often real code to illustrate.

• Information wants to be free. Knowledge is amplified when shared.

• It doesn't have ads flying in me face.

• I like the formatting and the visual style.

• It's a big part of the Internet culture.

• I use it ALL THE TIME.