The objects of production in the knowledge economy have value if they convey research, design, image or information content. In short: of meaning. The value of the meaning of what we do, the direction in which we are moving, seems to be the basic key to the contemporary world. This leads the organization of production to constantly address the narrative, cognitive, social, scientific, technological and creative dynamics out of which the meanings the population prefers arise. The system works on the basis of the logic of complexity, in which every element is connected to every other.
I don'twant to rehash the nitty-grittydetails of the fiery "Should designers code?" brouhaha because it's mostly irrelevant, marginally an issue of semantics, and entirely the wrong question. Some designers code and others don’t — the world of design is so large there is room for a veritable rainbow of designers. I do, however, want to talk about the danger of reifying designers-who-code as chimeras and the corollary that the act of coding is a magical, mystical, unattainable endeavor.
If you've ever seen a concept map diagramming the territory of user experience (Dan Saffer, Jesse James Garret, et al.) then you know the purview of design is, to put it mildly, nebulous. And while it's true that neither Dan nor Jesse's graph includes code, Jesse explicitly states his model is incomplete and doesn't include development practices while Dan's could potentially include code in several areas of overlapping disciplines. Either way, it's not difficult to imagine how these diagrams could and would include code.
Dan Saffer's concept map of UX
And why wouldn't it? Code — loosely and intentionally defined as writing software for the purpose of learning, prototyping, creating art, or working professionally — is a tool for thinking and exploration. It's a way of understanding the system by using the system to build the system on any number of micro and macro levels. As Jennifer Tidwell points out, there are "enduring concepts behind software creation" that transcend any given language, environment, or ecosystem. It doesn't matter where you start or what your focus, code is a way of encountering, understanding, and interacting with these concepts.
The world of journalism is grappling with the same questions when it comes to the role of code, and while journalists and designers share similar rhetoric, efforts are underway at journalism schools to teach students everything from statistics to interaction design to programming. The intent isn't to transform journalists into a legion of expert programmers, but to teach and create a baseline of digital literacy. As Robert Hernandez puts it:
To me this feels like the right framing of the issue. By acknowledging that not everyone will or should code professionally while simultaneously demystifying the mechanisms underlying the primary communication platform of the 21st century, code becomes contextualized and approachable. Most of us aren't professional writers either, but it's widely accepted that practicing the art of writing is a Good Thing because it helps you think and communicate ideas. Just like the art of coding.
Most people make the mistake of thinking design is what it looks like. People think it's this veneer — that the designers are handed this box and told, 'Make it look good!' That's not what we think design is. It's not just what it looks like and feels like. Design is how it works.
Apple's design philosophy is nothing if not direct and concise, which I'm guessing is one of the (many) reasons their level of focus and execution is so incredibly high. As we begin building out the design practice at SimpleReach I've been thinking a lot about design leadership, ways to foster understanding and purpose across divisions, and approaches to creating a strong design culture. Nothing worth sharing right now, but tidbits from my research will likely wind up here.
The front-end tooling landscape has exploded recently and I'm totally excited about everything that's happening. If you haven't had a chance to check it out a good place to start is Addi Osmani's deck from his 2013 FOWA keynote, "Automating Frond-end Workflow".
I've been using task runners and package managers for a while, but hadn't thought about using something like Bower to create reusable Sass modules until I came across Stefan Baumgartner's article, "Create manageable Sass Components". It's a nice alternative to Git's submodules (which have bit me in the ass on more than one occasion), with the added benefit of managing versions and dependencies.
When it comes to Sass there's a base set of functions and mixins I rely on heavily — if I don't have them handy it's almost like I can't think. While I enjoy frameworks such as Bourbon and Susy and learn a lot from their approach to architecting Sass, I find them too monolithic for my needs.
So I took the ideas in Stefan's article and published my first Bower package, Bones. It's a very lightweight set of functions, mixins, and placeholder extends that I rely on for every project, whether it's a web app, marketing site, or pet project. I've already switched this site over to Bones and it's made my life oh-so-much-easier. I'll continue to update it as needed, but if you are doing any amount of heavy lifting with Sass, consider using Bower to create reusable Sass components. You won't look back.