In a nutshell NeonMob is a web community for artists and collectors. Below is my personal user experience (UX) review.
An excerpt from the book: Design for Hackers by David Kadavy
This is a reminder for myself and for other designers who may struggle with feeling discouraged about their work. I want to remind us where we’ve been, that the process is much greater than the result, and that it’s important to keep practicing–keep working that craft, sharpening that knife.
As I observe today’s design trends: long shadows, long-pages, flat & muted colors, I find myself wondering what the next trend may be. It’s really interesting to think of the shifts in design as if they were movements in art history like the Renaissance movement, the Baroque movement, Impressionism, Cubism, Pop Art. Each movement had its common aesthetic qualities much like we have today, only now… movements seem to come and go like the wind.
Right now, I’m in Dallas at The Curtis Culwell Center hosting a BOF session to answer questions about design and theming for Drupal users but given the lack of bodies in the room, I thought it might be a good time to write some notes about the session I just attended which was a case study about creating a social brand for the Dallas Design District.
In the past, it’s generally taken me about twenty hours to complete a home page comp in Photoshop which I feel is a bit long. I’d be curious to know, on average, how long it takes other designers.
Even though the term “artist” is fuzzy, I do consider myself to be one. I think most artists share similar personaly traits: introverted, sensitive, perfectionism. I pour a lot of emotion into my work–I’m not sure you can create and not have this happen. Whenever I draw something, design a website, code an interface, I feel drained afterward–like I have nothing left. It doesn’t feel like a good state to be in, especially in a society that wants constant productivity.
"Once upon a time there were these things called books. They were heavy and awkward and you'd turn the page and it cuts your fingers. It was like an awful invention, I'm so glad they're not around anymore. They're miserable things... Ugh. But this idea: 'the page' has been with us for ages and we carry that into the web and we talk about this on all of our projects: 'how many pages is this site', 'how long is the home page going to take you?', 'We're a university and we have 15 thousand pages' and really this has been our mental model of the web since its inception." —Brad Frost, "Building design systems from Atomic elements" at the 2014 UX immersion conference.
That's Brad Frost introducing atomic design. He then shows this image to the audience:
He goes on to talk about the reality of the web today: tons of devices, all different screen sizes, different input types, different form factors, and he says this idea of a static web page just isn't practical anymore. I completely agree.
So, how are designers currently working around this multi-device reality? How are we communicating this to stakeholders and team members? We're designing mockups of a large home page on a desktop, a medium-sized home page on a desktop, an iPad version in landscape format, an iPad version in portrait mode, a small or mobile version... you get the idea. It's totally inefficient and it's not scalable. This is why atomic design is becoming increasingly important.
Before I go into the details I want to explain what atomic design is because there are different terms being used to describe the same concept. 'Atomic design', the term Brad Frost uses is essentially the process of building a digital product or website in pieces (e.g. the header, the search form, the sidebar call to action). Think about it in terms of legos where you're able to construct things with a box of common and consistent pieces. Here is an example of component design.
Personally, I've been eager to design this way for a while now. Conceptually, the process of designing a system with components to assemble a website made perfect sense but I didn't know where to start. It turns out it's pretty hard to shift thinking from designing a web page to its individual parts... Hard, but not impossible. After some extensive research and updating to current systems I recently started designing and coding in this way and the benefits are huge.
Benefits of component design
- Developers have a reliable set of building blocks with which to use to create digital products and time is saved by having styling code clean and organized.
- Designers save time by reducing the amount of mockups they have to create in Photoshop or Sketch. They also have the option to design in parts, getting approval on designs quickly and iteratively.
- Clients get a front-end system that can scale as their businesses grow.
- Everyone experiences products that are faster, more consistent, and enjoyable.
So, what does this process (designing by component) look like?
At the moment, there are two processes or workflows for designing by component. Certainly there'll be other approaches in the future.
1) The traditional approach: A visual mockup of a page or pages is designed and handed off to a front end developer. The front end developer then reviews those designs and identifies all of the components, the legos that make up the website: the calls to action, the side bar blocks, the navigation, the input fields, etc. She then writes code that creates those components at their most basic elements first and continues until all of the components are complete. She can then assemble and arrange them in a grid to form different layouts and pages.
2) The iterative approach: A designer can create and receive client approval on the components rather than the entire "page". For example, he can simply design a header (logo, navigation, etc.) and then present that component's design to get approval before coding. Once the component's design is approved he can code it himself or pass it along to another developer while he starts designing a new one, say the footer or the home page hero. This process is repeated until all the pieces are finished and "pages" can be assembled.
You're probably skeptical
I have explained (roughly) what this process, component design, looks like from an implementation standpoint and I've touted its benefits but I haven't talked much about the challenges or hurdles. I'll explain those now.
Clients, it's probably daunting to think about how designing a system like this will impact time and therefore budget. The majority of the budget goes to back end development, server architecture, content creation, etc. It sounds nice but it just doesn't seem feasable to spend money on this. Building a product through component design does take more time and therefore more money but, depending on the designer and their familiarity with doing this, it's low.
Agencies, you'll have the biggest challenge. Building by component is pretty straightfoward; Building the system and workflow around this idea is an investment. Front end developers and designers are going to have to do some research and figure out how they want to set up their system, what they want to call things (sometimes the most challenging), how they want to organize their files and code, and how this fits into their processes.
Production teams, atomic design is a learning curve. It was for me, at least. We've been building pages for so long so there was a bit of fumbling at the outset. The good news is that the learning curve is pretty short.
Building interfaces this way empowers teams and clients to build better and more scalable products and I'm convinced that it'll be the standard way to build user interfaces sooner than later.
Common questions to component design
What is the deliverable?
Visually, the deliverable is the same as it was before: a website, a digital product, but in the background there's an organized system that is built to last so that products are able to flex and grow. Front end code is organized and built holistically.
Does component design take more time?
Yes, but the time can be short depending on the developer. When the design is translated and delivered as an interactive user interface, so is its accompanying front-end style guide–the library of components that make up your digital product. That style guide takes some time to manage and update as the pieces get built but again, it's a short amount of time.
Can my site still be responsive?
Absolutely. One of the primary reasons for component design is flexibility. We want to be thinking about how components flex or stretch individually so they fit well when put together.
Resources & Learning
I love this stuff. If you have more questions, please give me a shout on the Twitters @nickvcomito or via email at nickcomito at gmail. If you want to do this yourself and don't know where to start, Brad Frost and Anna Debenham (and many others) have put together a bunch of resources for this here.
CSS3 makes it easy for us to add mutiple backgrounds on an element. For example, if you want to add a graphic in front of a background gradient—assuming you’re running compass—you can do it like this:
Here’s an excerpt of a post I wrote for my agency a few months ago:
I had a hell of a time getting CodeKit to run smoothly with Sass and Drupal. I finally figured out a solution and wanted to post — hopefully it’ll help others.The problem happens because css is being run through Drupal’s template engine and is hidden from CodeKit. More specifically, the refreshing is being blocked because of the $styles variable bring printed in the tag of html.tpl.php. I actually don’t know the technical details here, but I did find a solution.
Quotes I want to remember.
A place to put tools, apps, or things I want to remember
An ongoing list of my favorite podcasts:
I’m compiling an onging list of my favorite beers, mostly for myself, but I figured I’d make it public.
Ask questions and learn. Don’t stop, but go slow. Be humble. Practice self-awareness. Enjoy the ride, the process, the journey. Don’t take stuff too seriously. Nothing stays the same. Nothing lasts that long. And it’s really hard to practice these things.
Reusable components Changing web (fast) Multi-device Kittens (no bacon)