Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

November 19 2013


Fail Fast, Fail Often: An Interview with Victor Lombardi

Retrospectives are common. You’ve likely conducted one before. But how many companies are actually good at them? How many companies actually have the courage to be open and honest about their own shortcomings? My experience tells me that very few are. And that’s why Victor Lombardi’s recently released book, is so necessary: unlike the ones designers are used to seeing, Lombardi’s stories are full of objective, thoughtful, and insightful commentary.

An award-winning product designer, Victor Lombardi’s had a hand in over 40 different software and internet projects throughout the course of his career. And during that time he’s clearly paid attention to one thing: namely, all of the different ways in which a project can unfold. His new book, Why We Fail, tells over a dozen stories of projects gone awry.

So why do design projects fail? Many reasons. Lombardi attempts to answer the question from a number of angles: product ideation, design, development, and marketing. After reading his book, we brought additional questions to the discussion: How does bias factor in? Or branding? And, on a different level, what can we learn from

Our full interview appears, below. Additionally (as is always the case when we interview an author published by Rosenfeld Media) the publisher has graciously offered to give away a few books to readers. More information on that follows the interview!

Hey, Victor! Thanks for taking the time to chat. Throughout the book, you note a wide variety of places in which cognitive biases might affect an organization (“survivorship bias,” for example, is a perspective that exclusively favors success). Were you aware of bias and its effects from the outset or did you simply start to see bias the further you delved into your research?
I wasn’t expecting to hear about bias when I interviewed people for the book. Maybe that’s because I didn’t think people would open up this way. But they did.

I think it’s good therapy for us to talk through not only what we did during a project but also what we thought and felt. From there I brushed up on my psychology—Max Bazerman’s “Blind Spots” was particularly helpful—to explain the cognitive science behind the issues that led to failures.

Many companies find it (understandably) difficult to financially justify a culture that “embraces” failure. What advice do you have for them?
If senior management rules by ego, believing that the people at the top have the best ideas, then I’ve got nothing to say. They won’t hear my message.

For others, I think the overt message of “fail fast” is actually better framed as “experiment fast.” The most effective innovators succeed through experimentation. They’ve updated the traditional R&D department by stepping out of the lab and interacting directly with customers, running thoughtful experiments, and executing them quickly to learn quickly what works and what doesn’t.

Anyone doing user-centered design is already 80% of the way there. It makes a huge difference just to shift your process towards the scientific method, phrasing research questions as hypotheses and iteratively testing towards them. A key difference is in the results: instead of a lot of usability data to analyze and interpret, you get a true or false result. This makes it much easier to decide what to do next.

I recommend reading up on methods like customer development, lean startup, or by starting with the final chapter of my book.

In chapter four you recount the story of Wesabe and Mint, two startups who approached the financial space from slightly different perspectives. Wesabe suggested that users manually upload their financial data (in the name of privacy and security) whereas automated this task (at the risk of perceived security). Both were minimum viable products, but one failed while the other succeeded. Can you speak a little as to what startups can learn, generally, from Wesabe and’s subtle differentiation?
Wesabe was a useful service with a smart Web 2.0 strategy. Given more time and investment it would still be around. But certain classes of startups are dependent on attracting large numbers of customers in order to attract more investment. chose features and designed them in a way that excelled at attracting customers. They won the competition even though Wesabe was superior in many ways.

But this isn’t true in every case. In the book I cover a broad spectrum of products: startups and mature products; mobile, web, and desktop software; hardware; and services. Different situations resulted in different lessons. I summarize the lessons at the end of each case study.

One of my favorite case studies in the book is Google Wave, in which you suggest that the first sign of trouble was that everyone had a different definition of what a “wave” actually was. Personally, I think this speaks to the strong connection between user experience, semantics and branding. How do we fail in this regard and how might we do better?
The UX field generally is not good at the conceptual design stage of creating new products compared to, say, industrial design or architecture. We fall in love with our first idea, and we can quickly and cheaply move from idea to working prototype—it isn’t natural to stay in the idea stage for a while to explore alternate solutions.

It’s unfortunate that Google Wave failed because the problem still exists. The solution was close. …maybe “Concept Design” should be my next book ;-)

Chapter 7, titled “Do the right thing,” tells the story of Plaxo and, two companies who each decided to employ dark patterns to “better” their business. What other kinds of stories/examples did you consider including in this chapter that exhibited bad behavior?
In cases like I had no doubt the behavior was unethical. Others were less clear cut. Some of the things Plaxo did [ed: such as mass emailing its members’ contacts] that annoyed us back then are now accepted practice. So it’s relative. I decided against including others because there was no smoking gun, so I’ll refrain from mentioning them here as well. If you really want to know, you’ll have to buy me a drink sometime.
Last question! I know it’s a bit premature, but what, if anything, do you think designers might learn from the (highly publicized) failure of
Let’s say we solved for the myriad of political and vendor integration problems that plagued the project. What’s left are some intriguing customer experience issues. One seems to be that a long registration process is required before the customer can view prices of health plans, because the plans and prices are determined by your registration information. I don’t know how they ended up with that design, but the decision to design it this way sounds like a policy decision made around a conference table rather than through a design process that included running experiments.

What you can do if you find yourself in this situation is to acknowledge, out loud, that the goal of not showing prices prematurely is a good one, but the solution of making the customer do a lot of work up front is risky because more people will abandon the process before receiving any value from the site (see Wesabe vs. Mint). To mitigate this risk, you can generate alternate designs, mock them up, and test them out with customers.

Offhand, I can think of a few options:

  • Let visitors browse plans upon arrival and show the range of prices next to each plan to give people a general idea of cost. Then show them the actual prices after registration.
  • Show some realistic content so visitors know what factors will influence the price, like “Sally, a single mother of two in New York will pay $100/month for Plan X which includes benefits A, B, and C.”
  • If just a bit of data is needed to determine price, like state and income, just ask for that data, and require registration later when people are ready to buy a plan.

Thanks, again, for taking the time, Victor! Your book was a pleasure to read.

If you’re as jazzed about learning from failure as we are, I’d strongly suggest entering for a chance to win a copy of your own, courtesy of our friends over at Rosenfeld Media. To enter, simply follow UX Booth on twitter and leave a comment on this post answering the question: What’s your favorite story of design failure (one you’ve witnessed firsthand or otherwise) and what lessons to you think it provides? Rather than pick the winners at random, as we usually do, we’ll work with Victor to pick the three best stories of failure. Their authors will receive copies of the book. Entries must be made by Midnight, PST of November 21st. Good luck!

The post Fail Fast, Fail Often: An Interview with Victor Lombardi appeared first on UX Booth.

October 03 2013


The computer’s a dangerous instrument…

“…because it shapes your capacity to understand what’s possible. The computer is like an apparently submissive servant that turns out to be a subversive that ultimately gains control of your mind.

“[It's] such a powerful instrument that it defines, after a while, what is possible for you. And what is possible is within the computer’s capacity. And while it seems at the beginning like this incredibly gifted and talented service it actually has a very limited intelligence. The brain is so much vaster than the computer, but, the computer is very insistent about what it’s good at. And before you know it it’s like being with somebody who has bad habits — you sort of fall into the bad habits and it begins to dominate the way you think about what is possible.”

Milton Glaser, New York, 2007

Quoted from an intriguing interview with Milton Glaser.

Photo by Victor Affaro.

Sponsored post
Reposted byLegendaryy Legendaryy

September 11 2013


The Design Method

The Design Method is a new book by Eric Karjaluoto, creative director and founding partner of smashLAB. He kindly took time to answer a few questions that I thought would interest you. The questions are separated with some illustrations from throughout the book.

Both the client and designer play important roles in the creation of good design. However, each one holds certain strengths and insights that the other doesn’t. As such, think carefully about the part each group plays, and try to avoid stepping on the other’s toes.


You talk about presenting just one idea to your clients. I get occasional enquiries where I’m asked to create a number of designs. Have any of your clients been adamant about seeing more than one idea?

Although many clients start by asking for three options, I explain to them why aiming for one target is more sensible: Doing so minimizes tangential directions that can take the project off course, helps keeps the project on track/budget, and reduces the number of decisions they’re forced to contend with.

I explain that we run many (often hundreds of) variations in studio, and edit down the choices before presenting the most workable option for their review. If they disagree with our recommended direction, we note what isn’t working, and then iterate.

We don’t mind going back to the drawing board if necessary; we just want to ensure that we’re moving the client and project forward in one clear direction. When I explain this, most clients see the logic and agree that it makes more sense than the alternative.

IKEA’s designers employ a number of consistent rules when producing assets. As a result, you could change the text to gibberish and most would still be able to identify the brand.


You say the voice of the designer is irrelevant — what do you mean by “voice?”

I’m speaking specifically about individual personality and style. Design is often considered a close cousin to art, and this misunderstanding clouds what our industry is about. New designers, in particular, want to imbue their work with their own sensibilities, but this desire isn’t actually that important.

Clients, for the most part, don’t want the designer’s personality to show through the work they produce; instead, they need design that is built around their needs and amplifies their organization’s values and aspirations. Designers need to gear themselves to think about their clients’ needs first.

Leg warmers
It’s understandable that you’ll find trends compelling, but it’s a real drag to look back and realize that you were lured into the same pointless fads as everyone else.


How do you present your project quotes? Are they solely for what the client requests, or do you break it down into options, perhaps with a lower and a higher value in order to offer more choice?

Providing design quotes is almost always difficult, as the nature of design projects tends to be quite variable. On the odd occasion, a job is cut and dried, and I simply look back on past projects we’ve completed, with a similar scope of work, and use that (alongside a look at the billable efficiency of that project) to determine a suitable price. For the most part, we tend to provide a fixed cost; however, if the prospective client tells us that they have less to spend, we can sometimes reduce scope to meet their budget.

Increasingly, though, we’re asking prospective clients to contract us to complete some initial Discovery and Planning work, as a trial run of sorts. This approach allows us to really dig into their situation, needs, and expectations, and subsequently produce a plan for them. Upon having done so, they’re free to take the plan to another organization and leave us behind, should they choose.

Most times, they have us continue with the project, as they now have a better sense for our agency, how we think, and the way we work. Additionally, our pricing tends to be more accurate at this point, as having done this work allows us to really understand the scope of the project, instead of guessing what’s involved — which most studios are forced to do if they haven’t conducted any initial Discovery and Planning.

Stages and phases
The Design Method relies on four key process stages; however, the working phases you employ are informed by the kind of design you do and the project milestones you establish.


How do you protect your studio from potential legal issues that might arise after a project has started (where a client might not pay yet still use your work, for example)?

We produce a clear document at the outset of a project that lays out the scope of the project, timeline, and needs, as well as the associated requirements on the client’s behalf. After that, we request progress payments at key stages throughout the project.

Most of the engagements we take on are long and involved, and this allows us to really get to know our clients (and vice versa). Therefore, we tend to get a sense in advance if there might be some kind of discomfort/frustration on the client’s behalf. We then address such concerns before the situation gets ugly.

I’m sure that at some point we’ll need to bring in lawyers to help with a project that goes completely off the rails, but we’ve never yet found ourselves in that spot. Frankly, by the time you need to bring in lawyers to deal with such a situation, you’ve likely not been running your studio the way you should have been.

You want a trophy to celebrate your achievements? Why not join your local 4H club or bowling league, or attend a fishing derby? They’ll give you a trophy!


During a few of my past projects it became clear that the client wanted to drive the design, asking for this to go here, and that to go there, etc., almost to the point of relegating me to a pixel pusher. Has this ever happened to you? And if so, how did you handle the requests?

Yes — it happens all the time, and this will never change. The work designers do is very personal to those who hire us, and they’re going to want to get their hands “in there.” In my mind, both the client and designer play very distinct roles in this sort of work, and the designer needs to define these roles clearly in order to produce good design for their clients.

The client/designer engagement needs to be thought about practically. Most clients aren’t experts in creating brands, defining visual identities, producing elegant user experience, and the like. Meanwhile, most designers don’t really know their customer’s business, clients, history, operations requirements, and so on.

Therefore, each party needs to own their role and try to avoid infringing on the other’s — for the good of the work they’re trying to produce. This is an issue of perspective: Neither the designer, nor the client, should be concerned with what their individual visual preferences; instead, they need to ask how they’re going to reach the objectives set out at the outset of the project. Most times, this means concentrating on how the choices they’re making might impact the user.

So, when you’re struggling with a client getting a little too close to the work you’re helping them with, try to get them to pull back a little. Keep asking what will work best for the audience/user, and you should be able to steer the project back on course.

Exit signs
Although both signs seem like reasonable approaches, which one do you expect will make the most sense to someone who doesn’t speak English?


You say in the book that “if you want to get new business, taking prospective clients out for lunch may be more effective than chasing awards.” What proportion of your clients are local, and does it affect your working relationship when you’re unable to meet face-to-face?

The ratio tends to vary. At this moment, most of our work is for clients who aren’t in Vancouver. That being said, it’s the relationships that started with local groups that led to a number of these projects. For example, the website we built for The Vancouver Aquarium has been very well received by groups abroad. As a result of that project, we started working with organizations including WWF Canada, The University of Minnesota’s Institute on the Environment, and The Nature Conservancy. Personally, I like meeting our clients in face-to-face, but that isn’t always possible. For those who are close, though, we try to get together for lunch every here and there — not necessarily for sales purposes, but instead just to get a sense of what they’re up to. We’re lucky to work with a lot of nice people.

The Design Method

Book giveaway

Eric is giving away five codes for downloading digital copies of his book. They’ll go to five of you who leave comments that share the number of design options you present to your clients, and why. Names will be drawn from the comment thread (below) next Monday (16th).

The Design Method is available from the Peachpit website and here:


From the archives: What employers look for, by Eric Karjaluoto

September 02 2013


Interview With Lea Verou of the W3C

There's so much goodness happening on the web and as it continues to evolve, it's important that talented individuals step up into leadership roles to help shape the future of web development. And doing this isn't an easy task. Not only do you need to have the technical chops to help define new techniques and paradigms or create the next great technology, it's equally important to be able to effectively convey your message in a passionate and credible fashion so that your peers respect your direction.

Lea Verou is one of these new breed of leaders who is helping to push the web forward through her technical savvy and profound love for web standards. She's developed quite a following and her live coding sessions at major conferences are a thing of legend.

We had an opportunity to find out more about her in this Q&A.

Q Let’s start with the usual. Could you give us a quick intro about yourself?

I’m Lea Verou and I’m a web designer/developer and web standards geek (sounds like an AA introduction, doesn’t it?). I’ve created several open source projects such as Prism, a syntax highlighter used in A List Apart, Smashing Magazine,, MDN and other big websites, Dabblet, an interactive code playground, or -prefix-free, a JavaScript library that lets authors forget about vendor prefixes and code to the future standards. I’ve also come up with and published several CSS techniques, such as using CSS gradients to create patterns. I’m currently employed by W3C, although I’ve announced that I’m leaving at the end of July to pursue other challenges, such as writing and designing my first book.

Q You’ve risen quickly to be one of the most recognized and respected web developers around. Has that changed the way that you view yourself within the community and the responsibilities you may (or may not) have in promoting best practices and specific technologies?

Not really, to be honest. I still do my thing, make stuff and put it out there in the hopes they will be useful for someone. I still speak my mind about the technologies and best practices I like and those that I don’t. Whoever wants to listen to me, it’s their call. I’m not going to censor myself because of the number of people who are following me. That would be counter-intuitive, since being myself made these people follow me in the first place.

Q You’ve been very vocal about the problem with vendor prefixes. Do you think that’s been solved?

I think both browser makers and the WG (working group) have realized that vendor prefixes, although good in theory, do not work in practice. So, the way to go right now seems to be browsers implementing experimental features under a setting instead of behind a prefix. That way, developers will not start using it in production, forcing the WG to get stuck in early iterations, as was the case with vendor prefixes.

Q Along those same lines, how much responsibility did the W3C, the CSS WG and WebKit teams have in perpetuating what became an incredible hindrance to cross-browser development (especially mobile)?

There’s no single cause, but I believe a big part of the blame lies with developers. Although we’ve endured the pains of a browser mono-culture before, we did not learn much. IE6 used to be really cool stuff 12 years ago you know, just like WebKit is today. I can see the CSS WG being at fault too, for not realizing the issues with vendor prefixes early on, which turned web development into a popularity contest. Last but not least, the WebKit team shares some part of the blame, as they shouldn’t have implemented non-standard CSS features to get ahead in the browser game.

Q Developers want more modern features and they want them now. Is the pace of the standards bodies keeping up with the needs and wants of the developer community? If not, what needs to happen to change that?

I’m sure you are aware of the old project management triangle paradigm: Something cannot be fast, high quality and cheap, you need to pick two. I believe this applies to designing APIs as well. Budget is limited, as there are very few people paid to work on standards. So, basically, designing new features can either be fast or high quality, but not both. We can see the former when browsers decide to innovate: Usually, even when the original ideas are good, they are poorly thought out, since they were designed in the vacuum of a single company (examples: Drag and Drop API, -webkit-gradient()).

When the standardization process is followed through, features can be very high quality in the end, at the cost of taking a long time to be finished. Several parties with different interests need to reach consensus, a full test-suite needs to be written, it needs experimental implementations and several iterations based on implementor feedback. All of this takes time, but keep in mind that once a feature enters the open web platform, we’re stuck with it for years, if not decades. Therefore, it pays off to invest that kind of resources in to it, and to be patient. Short-term pain for long-term gain ;)

Q You recently announced your departure from the W3C. How will that affect your involvement in the standards process?

I will still be involved in the CSS WG as an Invited Expert. The WG voted on it in a recent telcon and I was happy to see several people in support and nobody against it. :) In fact, I will be able to devote more time to it now, since I expect to have more free time in general, and having worked at W3C gives me a unique perspective and insight into the standards process.

Q You’re renowned for your live coding demos, flooring conference attendees during your presentations. Aren’t you concerned about messing up and affecting your flow? How do you even prep for something like that?

I have several safeguards preventing me from messing up. I keep my code examples concise, showing only what’s needed. This also helps the audience understand, as the code is small enough for them to process. I believe that as the number of lines in a code sample grows linearly, understanding decreases exponentially. Most importantly, I practice a lot. I might not practice the delivery of the talk, but I always practice the live coding several times, even when I’ve given the talk before. Also, even if I mess up, which has happened a couple times, the audience is so glad to see the result gradually build up in front of them instead of being presented with a screenshot, that they can be incredibly forgiving of missteps. If something does not work, I will spend a few seconds trying to fix it and if I can’t, I will explain what was supposed to happen and move on.

I often see people ruining live coding presentations by showing too much code, with too many distractions (e.g. a full IDE around it and having to switch windows to see the result) and long delays trying to debug their code when something goes awry. All three are very effective in getting the audience to lose focus. However, done right, live coding can be a great teaching aid and make a talk more engaging and fun.

Q A lot of devs long to be as multi-faceted as you. Most seem to be good in either JS or CSS but usually not both. What are the techniques or resources that have allowed you to become as proficient in both to where you can do live coding demos near flawlessly?

My two biggest interests since my preteens were design and programming. So, when I started making websites, I was studying the languages involved, as much as studying graphic design principles. I fell in love with CSS because it felt like a bridge between the two, which is why I specialized in it.

Regarding resources, I was always the type of person that learned through reading and practicing (in that order). I would read an entire book and then build something that helps me put what I learned into practice to create something that I wasn’t able to before. I don’t learn easily from lectures, and I even glided through university (Computer Science) studying on my own, rarely attending any lectures. However, this greatly depends on the person, I know some amazingly skilled folks who absolutely hate studying on their own without anyone teaching them. I think that’s why I tried to take a different approach in my own talks, because I find conventional lectures so damn boring and hard to follow, except for the rare case where the speaker is as funny as a stand-up comedian (and while I like to think I have a good sense of humor, I’m by no means on that level).

More About Lea

Thank you Lea for taking the time to chat with us. To get to know more about Lea and her work on standards and web development, be sure to visit her website and follow her on Twitter. Also, if you have an opportunity to see her speak in person, definitely jump on it. Her list of past and future events can be found on Lanyrd which also link to videos of her previous presentations.

August 20 2013


Interview With Nicholas Zakas of Box

Having people you can learn from is an essential part of being a successful developer. No amount of reading will ever fully prepare you for the ever-changing web landscape, so being able to look to seasoned and experienced mentors is vital. Nicholas Zakas is one of those people that you can look to.

A leader in the JavaScript world and incredibly savvy in scalability and performance, Nicholas is one of those that helps define best practices through his vast experiences at companies like Yahoo! and Box. One of his most amazing attributes are his approachability and his desire to genuinely help push the web forward.

Let's get into our Q&A so you can learn a little more about this great developer.

Q Let's start with the usual. Could you give us a quick intro about yourself?

Certainly. I'm a software engineer who focuses on front-end web development. I love the web and knew very early on that I wanted to make that my career. That love has led me in many directions, including writing and speaking. At the moment I'm working at Box, taking on the challenge of helping the company scale.

Q You were a principal front-end engineer at Yahoo!. I think for most of us, it's hard to comprehend working at that scale. Can you tell us about the challenges you saw at Y! and how it has shaped your thinking since you've left?

Yahoo! was the most impactful professional experience of my life. Prior to that, I was a big fish in a small pond, and day one I realized I was now in an ocean. Solving problems normally and solving problems at scale require two different ways of thinking. At scale, there's never just "one more" thing. I remember one conversation in particular where someone wanted to make an extra Ajax request and I said no. His response was, "what's the big deal, it's just one more request?" I had to explain that one more request per user when there are millions of users means a dramatic increase in server load that we need to capacity plan for. I chuckled at that, because I was on the other side of that conversation when I first arrived at Yahoo!.

Everything I do has been affected by my experience at Yahoo!. I'm obsessed with scalability and the problems associated with it, and most of my work since then, both at Box and while consulting, has been in helping companies scale their web applications. My experience at Yahoo! made it so that I understand these issues from many angles, not just technical but also personnel-wise and organization-wise.

Q When I read your writings, you focus heavily on computer science principles. It's only in the last couple of years where I've seen an up-tick in that. Where do you see the bulk of the current generation of front-end developers heading in terms of embracing formalized CS principles in their work? Are they still lagging?

I think front-end developers are still lagging in having a solid amount of computer science knowledge. It's true that having a CS degree alone does not guarantee success as a front-end developer, but it certainly helps. I know several excellent FEs that are now going back and either taking computer science courses formally or trying to pick up more CS knowledge through reading and other means.

Web applications are so much more complicated than they were before, and understanding design patterns, abstraction, and architectural principles is becoming more and more important. Those who come into the industry without a good CS background will either be limited in their professional growth or will start picking up these CS principles some other way. I firmly believe that the best and the brightest are the ones who can bring CS principles back into the front-end. Whether that's through formal training or not, that knowledge becomes important to furthering your career.

Q Along those same lines, where do you see front-end devs lacking from a skills perspective? What are the things that they should be up on but aren't?

The biggest issue I see is lack of code organization. Part of the problem is that web technologies like CSS and JavaScript are mostly without built-in form. Whereas Java has packages and C++ has includes, web technologies don't give you a formal way of organizing your code. That leads to poor code organization and then poor architecture, because there are also not any built-in patterns.

Learning about design patterns, code organization, and architectural principles would benefit front-end engineers tremendously. Not just for their FE code, but also for the ability to participate meaningfully in conversations about other parts of their technology stack.

Q I've overheard conversations where the ECMAScript standards body is getting push back from a very vocal group which call themselves "practitioners" of the JavaScript language and are driving for more practical, real-world updates to JavaScript. Have you heard of this and if so, what's your take on this and the interaction between the traditional maintainers of JS and this new group?

Yes, there's definitely been an influx of practitioners getting involved in the standards committee. There's Rick Waldron and Yehuda Katz from the jQuery Foundation and Eric Ferraiuolo from the YUI team on TC39, people with real-world experience creating web applications and JavaScript libraries. There are also a lot of vocal people who participate on the es-discuss list regularly and who represent the practitioner view. Even I chime in from time to time when I feel like reality isn't quite intersecting with plans.

This communication between practitioners and those deciding the future direction of the technologies we use is imperative. Via es-discuss, TC39 members are generally responsive. I look at this relationship as being similar to the one between citizens and elected officials. If the citizens aren't telling the officials what's important to them, it's hard for the officials to know. Random people complaining about something here or there doesn't make someone think of it as important – it's when a critical mass all reach out and say, "yes, this is important" that change happens.

Q It seems that some of this may be founded considering the adoption of such DSLs as CoffeeScript, TypeScript and Dart which seem to bring flexibility and power to front-end devs. Is it a language issue or a developer expertise issue?

I feel like it's a developer expertise issue. What I see most frequently is people without much web development experience deciding that it's easy, so they're just going to hack something together. After all, JavaScript looks like many of the other C-based languages, and so they start writing it as if it were C or C++ or Java – then they get frustrated because the functionality they're used to doesn't exist…then they turn to things like CoffeeScript or Dart because it gives them back what they perceive to have lost.

If you flip the script a bit, if people actually took a little bit of time to learn JavaScript before diving in, I'd hope there would be a greater appreciation for what a unique and dynamic language it is. Unfortunately, the "agile" and "rapid" development processes tend to encourage people not to stop and learn about what they're trying to do, but just get stuff done so as to keep up their velocity and deliver. When that happens, finding something that looks familiar makes far more sense than using something completely new.

Q One thing you really harp on is performance and trying to educate developers on optimizing their code. Alex Sexton wrote a great article that's along these lines, elaborating on roles that specifically target optimization. Is this the optimal route for companies to take or should every developer be as versed in the nuances of performance?

To me, this is too specific a specialization. As a front-end engineer, your job is to cross-cut concerns, including performance, maintainability, internationalization, accessibility, and more. To put it another way: if front-end engineers are not thinking about these things, then I'm not sure what they're thinking about. In my experience, the more you split off specializations, the harder it is to convince everyone that it's their responsibility as well. "Oh, the performance team will take care of that." "That? The accessibility team will worry about it." This isn't to say that you don't have people who happen to be more in tune with certain concerns, but I believe that you want everyone on the team to be thinking about all of these issues all the time.

Q You always seem to be on top of the cutting edge stuff, especially in terms of JavaScript. What's your process for staying in the loop on all the changes?

I do a lot of reading. My Twitter feed is made up primarily of human news aggregators that let me stay up-to-date with what's going on. I also do a lot of writing, which I find leads me to research areas I might not normally look at in an effort to explain things better. Lastly, I'm constantly experimenting, both on my own and at work, and looking at the real-world problems people are having to see if I can come up solutions.

Q Last question. If you had to list the top five things front-end developers should be in tune with, what would they be?

  1. The changing API landscape – make sure you know what's possible
  2. How to effectively use the ever-evolving development tools
  3. Standards efforts – understanding what's coming, what's not, and why
  4. Browser feedback channels – you should be using them
  5. Code organization and design patterns


Thank you Nicholas for taking the time to offer up this insight.

I urge our readers to follow Nicholas on Twitter and also check out his blog, where he posts some of the most frequently referenced articles in web development.

August 06 2013


One to Many: An Interview with Leah Buley

Everyone’s been there: “going it alone.” Learning, prodding, and making sense of a problem – all in complete isolation. Sometimes the hardest thing in that situation is knowing that, regardless of whether or not we succeed or fail, we’ll have no one to share that outcome with. And that’s exactly what makes Leah Buley’s story so compelling. In her latest book, UX Team of One, Leah explains how we can beat the odds and feel that sense of camaraderie even when we’re the only person ensuring that our organization practices design in a user-centered way.

I first heard of Leah Buley from her presentation at UX Week 2008 titled, not surprisingly, UX Team of One. And at that time I could certainly empathize: I worked as the sole – and therefore “lead” – interaction designer at an agile development consultancy. By the end of the presentation I couldn’t help but share it with my colleagues and friends.

You likely saw something about it on UX Booth’s Twitter feed. Shortly thereafter, Leah received a book deal with Rosenfeld Media, giving her a platform to bring her message to the masses (well, the print-based masses).

Recently published by the gang over at Rosenfeld (PS: use code UXBOOTH if you decide to purchase a copy), I didn’t hesitate to reach out and ask Leah what I felt to be pertinent questions. Namely, it’s been four years since her presentation. That’s quite a while in terms of our industry. And not only that, but Leah’s made quite a transition herself in that time – from being a team of one to being an in-house designer at Intuit. Read on to hear Leah’s thoughts on her transition as well as a chance to win a copy of your own!

Congratulations on the book, Leah! To even begin to codify user experience design is an incredible feat. Now that you’re done, will you ever look at our craft the same way?

Thanks so much, Andrew! It’s pretty thrilling to have a book out and alive in the world. Truthfully, it took me so long to write it that I was secretly worried that its time might have passed. But the feedback has been really heartwarming, and it would seem that there are still lots of “UX teams of one’ in the world. So, phew! Thank heavens for that.

As for our craft, I don’t know. I feel like the more I learn, the less I know. When I look at the book, I realize how much is not included in it: responsive design, service design, lean UX, augmented reality, big data, flat design, the internet of things, retrofuturism, flying cars (well, self-driving, at least). There are so many new approaches and methods and possibilities emerging all the time. (Thankfully! That’s what keeps it interesting.) that I wince a little when I think about everything that’s not included. But it’s ok. When that happens, I take a deep breath and pour myself a glass of wine and reassure myself that my goal wasn’t to be comprehensive but rather to capture a mindset that can help user experience professionals win support and influence better work. I hope I’ve accomplished that.

You’ve made quite the transition since your initial presentation, switching companies as well as roles. How has your approach changed over the years?

When I started doing UX work I was full of misdirected bravado. I had this idea that UX designers should be able to fight for what’s right for users. I believed my job was to come in with guns blazing and challenge teams to reinvent their products.

I think the biggest change to my approach is now I focus less on the fight and more on the process. Consequently, I have less bravado and more innate confidence. I’ve become more confident because I’ve been through the research and design process repeatedly enough to know that it works. I have trust in the process. There seems to be a moment on every project where I feel like the solution is hard and unknowable, and I can’t possibly imagine how we’re going to figure out what to do. But I just let myself keep marching forward.

It sounds weird but I liken this to walking off a cliff. I walk off a cliff – into the abyss of the problem – and trust that insights gleaned from observing real people will point the way. And somehow they always do. I used to be afraid to let my colleagues know that I was in the abyss. Now, I try to be transparent about it; I try to help other people get comfortable with being in the abyss, too.

I’m actually leading a really complicated design project right now. The goal is to bring consistency to a user experience that connects a bunch of disconnected products while also bridging brand and product strategy and UX. It’s got, like, four dozen stakeholders. It’s a beast. Some days are really hard. Those are definitely falling-off-the-cliff days. But even on the hard days, I can remind myself that 1) I know how this process works and I just need to keep moving ahead, and 2) in the end we’ll have something markedly better than where we started. And I know this is true because I’ve been through enough messy UX projects to know that the user-centered design process will get me there.

You’re presently a design strategist at Intuit – a company who, I imagine, employs quite a few UX designers! In other words, you’re hardly a team of one anymore. What philosophies and practices mentioned in your book apply “UX teams of many” and what new techniques/practices have you learned?

I have a great job. I get to work on ambiguous design problems that cut horizontally across a large organization with a lot of vertical structures. Sometimes I focus on product-oriented, customer-facing design problems—things that affect our products – and sometimes I focus on process-oriented, internal-facing design problems – things that affect how we work. In both instances, the key to success is (and always will be) people. My job is to find ways to bring everyone along for the ride. In that way, actually, all the philosophies and practices from the book still apply. Intuit has an extremely large user experience community, and yet I still feel like a UX team of one. And that’s not because I’m unsupported, it’s just the nature of working with a cross-disciplinary team, which just about every UX professional does.

I’ve also add a lot of new techniques to my toolkit that I picked up at Intuit. Intuit has this really phenomenal program called the Innovation Catalyst. (Not invented by me, alas. Here, I’m just an eager student.) Basically, they train hundreds of people throughout the company in design thinking skills, and then send those people back into every branch of the organization to act as facilitators and coaches for design. The Innovation Catalyst program teaches loads of methods that run the gamut from customer research to generative design to rapid prototyping and experiments. One of my current favorite methods is this poster-sized canvas called the NEXT tool. Using the NEXT tool, teams answer some really interesting questions about their product vision, their “leap of faith” assumptions, and various hypotheses that they ultimately need to test with users. The NEXT tool is really complementary to the Lean Startup approach.

Another, simpler tool that I learned at Intuit that I really love is called a brainstorm box. If you’re doing a team brainstorm on product ideas, just put a box in the middle of the table with thought starters written out on sticky notes. If you get stalled, pull out a sticky from the box and, voila, brainstorm re-ignited. Some example thought starters: “What if it had to be purely mobile?” “What would be the opposite of our last idea?” “What would get us fired?”

Many people who find themselves as the sole UX professional in a company struggle with how much they need to “teach” the rest of their team. What are the essential principles a UXer should teach his or her team in order to be successful?

First and only principle: go watch some users. Actually, I wouldn’t even call it a principle. Call it a suggestion. “Hey, let’s go watch some users.” All knowledge derives from that. The ability to envision the product from a user’s point of view is like a muscle that can be strengthened. And like a muscle, it responds well to repetition. Jared Spool has written about user exposure hours and the high correlation between the number of hours a team spends watching users and the overall quality of their product. If you can get your team to take the time to actually watch real people in action (whether it be a usability test, exploratory research, or even lean-style rapid experiments) they will be strengthening that muscle. This makes the whole team better informed about user needs. But just as importantly, it will make them more curious and empathetic about users in general, which is how a fan of UX is born.

The second half of the book is comprised entirely of user-centered design activities and methods and serves as a wonderful resource for anyone working in UX. What gave you the idea to structure your book this way?
The structure of The User Experience Team of One was inspired primarily by my deep love for reference books. I covet and collect reference books of all kinds—cook books, dictionaries, craft and activity books. In my first job out of school, when I was still muddling my way through HTML and CSS, a co-worker gave me a copy of O’Reilly’s Javascript: The Definitive Guide. It was like my bible, the first reference book for my professional career. I loved its structure—this highly glanceable, easy-to-peruse manual for making interesting things. Ever since then, I’ve loved and looked for books that have clear, reassuringly repeatable structures. Surprisingly few UX books have that ’cook book’ quality. Two books that do this well are Universal Principles of Design and Universal Methods of Design, both of which contain one utterly complete, bite-sized thought per page.

That’s a wrap, guys! Thanks, again, Leah, for taking the time to share your thoughts with readers.

As for the giveaway, here’s how that works: just follow @uxbooth on twitter and leave a comment on this post answering the question: “What user-centered design technique do you rely on most frequently and why?” Be sure to include your twitter handle in your comment and to leave it before this Thursday at midnight PST. We’ll contact three lucky winners over Twitter. Good luck!

The post One to Many: An Interview with Leah Buley appeared first on UX Booth.

July 30 2013


Interview With Chris Williams

When you think about people who have made an impact in the JavaScript community, I think most people would immediately think of Brendan Eich, Douglas Crockford or John Resig. And rightfully so, as their contributions have unquestionably impacted JavaScript as we know it.

There's another person who I feel has made a profound difference in the way that JavaScript is viewed and has done as much as anyone to bring organization and structure to the JS community. And that's Chris Williams, the founder and organizer of JSConf. I think we tend to underestimate how important a community is to the vitality of a technology and Chris has worked hard to cultivate the JS community through his outstanding conference, making it one of the most sought-after events for web developers. It has been so successful that it has spawned off sister events worldwide, all with the sole focus of improving the community.

It's not to say that everything is always rosy but Chris is undeniably passionate about JavaScript (and now robots) so I wanted to ask him a few questions about his conference, the state of the community and what's the big deal about robots anyways.

Q Let's start off with the usual. What do you do and why do people love you so much?

It was the first time that a technology conference focused on the deep technical perspective of JS.

Well first off, hello everyone! I am a bit of a jack-of-all-trades these days. I am the Vice President of Product Development and co-founder of a senior safety monitoring company called SaferAging. As part of my work there, I created node-serialport, which is the package through which JS developers are able to control and manipulate objects in the real world through devices like Arduinos and Raspberry Pis (among others). The project has evolved into a larger idea called NodeBots which basically lays the groundwork for making hardware hacking accessible, easy, and understandable to any web or high level language developer. Watching the world wake up to the exciting world of hardware has been amazing, it is why we are starting RobotsConf in order to help more people experience this energy and happiness.

Alongside these efforts, and possibly where most people know of me (not entirely sure about love, but possibly), my wife and I started the JSConf technical conference in 2009. It was the first time that a technology conference focused on the deep technical perspective of JS. We did it with a strong focus on not just technical lectures, but on fostering a strong, social community, something that has continually grown year over year. We have worked to engender a strong sense of mission to the community whether it be through various charitable donation drives, constantly encouraging and supporting new conferences and community leaders, or using the platform we have built to fix the issues in our community.

Q JSConf is one of the most sought after conference tickets. Why not just open it up to a bigger audience?

By distributing the events around the world, we allow more people many more opportunities to participate in our community instead of allowing a small group have a chokehold on speaking slots and defining our community.

We do get this question a lot and it normally involves a long, philosophical dialog which ends roughly the same way every time. The original JSConf worked, because of its very intimate nature and that is something we have always tried to retain. By creating an intimate event, everyone at the event feels like they are part of something instead of feeling lost in the crowd. I have been to many conferences over many years and the ones that stick out the most in my experience were the ones where I felt like I could connect with everyone and left feeling part of something bigger.

All too often, the crowd demands "just add more seats" without understanding that by doing that you drastically affect the overall experience, the cost structure (conference costs do not scale linearly with attendee count), and, in my opinion, it yields an overall degraded experience for attendees. My proposed solution, largely influenced from a wonderful talk by Jason Fried at the SEED conference, is to make or help make many smaller, regional events that are finely tuned to and help reinforce the local community. By distributing the events around the world, we allow more people many more opportunities to participate in our community instead of allowing a small group have a chokehold on speaking slots and defining our community. The talk I referenced provided me with this great tidbit I have never forgotten and has been very shaping on my vision of how events should be, "I would rather sell cookbooks that help others make their own masterpieces than to be the greatest chef in the world".

I believe a lot of the argument rests on the assumption that a technology conference should just automatically accommodate everyone, which is impossible. JSConf US is organized entirely by the Williams family; yes, even the two year old and two month old helped out with this year's event as did our extended family. Trying to balance everything and maintain our family life and responsibilities, while still focusing on the conference, curation of experience, and quality of talks has already been almost impossible to accomplish. In the end, the size and style of the conference we organize is up to us and only us – we do appreciate the feedback, but for now we are going to continue as we see fit – for better or worse.

Q I find JSConf special because it's more than a technical conference. It's about friends and families which I love. I heard some people aren't thrilled with that and want more tech. What are your thoughts on that?

I have heard similar and when I pressed people that made this statement, what I eventually found out was that the issue was more about unmatched expectation, commonly due to the deep philosophical and very risky nature of talks we spotlight at JSConf. We want to spotlight people doing crazy things; things that might not be usable this week or month, but have a good possibility of changing the world. Things like:

  • Phonegap
  • Appcelerator
  • CoffeeScript
  • Cappuccino
  • Node.js
  • Gordon
  • PDF.js
  • Cloud9
  • Firefox OS

Some attend a tech conference with the assumption that they will be shown some tutorials, possibly a "big name" or two will present a replayed keynote, and be able to say they "learned something". JSConf is intentionally not that kind of event, which is exactly why it sells out so quickly. That said, we finally came up with a solution to handle these mismatched expectations with our new Training Track, which was always full and a huge success. In the end, there is always a grain of benefit from any complaint – you just have to refine it to something usable.

Q There have been a number of dust-ups at JSConf about speaker diversity, Brendan's political views and even the "significant others" track got attacked. How'd you feel about being placed in those situations?

My personal philosophy is that mistakes happen, don't judge people on them – judge people on their reactions to the mistakes and their actions to remedy the situation (if any).

Great question, awkward, but great. I take many things personally, arguably too personally, but if I can take the issues in and make something better for it, well then in my mind it’s a net win. Sure we have had "dust-ups", but I would expect nothing less from a conference that brings together some of the best technology people and puts them on the edge of the world to see what comes out. We didn't build JSConf to be risk-free, if anything it is almost the exact opposite. I view it like a bootstrapped startup – sure sometimes we misstep, sometimes we mess up huge, but that is part of the adventure and what SHOULD matter is how we react to the issues, not necessarily the issue themselves.

This is actually something I think the larger technology community needs to come to terms with, we are all too quick to vilify people without giving them 1) a proper trial and 2) a chance of redemption and thus we continue to perpetuate the bad behavior. In all the efforts I have seen, they almost always involve quick decisions, made unilaterally, with no recourse or review later. My personal philosophy is that mistakes happen, don't judge people on them – judge people on their reactions to the mistakes and their actions to remedy the situation (if any). With respect to my personal event, it is a private event in the end – my family has assumed all of the risk and I don't see anyone else willing to take on that risk, so for now I am going to continue forward.

In general, if you aren't making someone angry, you probably are not pushing hard enough.

Q In terms of speaker diversity, some argue that there should be steps taken by organizers to ensure an equitable distribution of male to female speakers. Is that the right approach or should organizers go for the best speakers possible regardless of gender?

The problem with the diversity in computing is that it is a systemic issue and therefore the answer must be one that immediately addresses this systemic nature.

This is a very touchy subject and one that many witch hunts have already been set out for. I have a different view in that I believe gender and racial diversity is not something that can be fixed in a generation, but something we must start now and fix upstream and continue to improve over time. There isn't a quick fix that will magically solve it. The problem with the diversity in computing is that it is a systemic issue and therefore the answer must be one that immediately addresses this systemic nature. Force adding female speakers to meet some unknown magic percentage, while a step in the right direction is by no means approaching a final solution.

From a historical perspective, conferences get better exposure (and yes it is negative exposure) by not having speaker diversity than those that do. Think back about "stand out conferences" and I can guarantee you that the names of "bad actors" stick out far more than "good actors", so we are inadvertently reinforcing bad behavior. This year at JSConf US we had an unprecedented 35% of our speakers AND trainers were female – we got zero community acknowledgement of it. With our attendees and our sponsors, we donated $10,000USD towards actively improving gender diversity in computing – it got less community acknowledgement than if we had something "bad" happen. This has to change, we have to start promoting the positive efforts alongside the constant, angry/frustrated negative rallies. Going beyond this, conferences and conference organizers cannot be the only line of defense pushing the change – we have thus far focused far too much on just one aspect — the raw count of "diverse individuals" present in a speaker roster. I believe this is misguided and a focus on short term gains at the loss of long term goals.

I and a friend, Matt Podwysocki, have been working behind the scenes on a different strategy for improving gender and racial diversity. We have been visiting middle to high school age groups, be at their place of education or through groups like DigiGirlz Day, introducing and exciting them about things in computing – giving them a better, brighter, and bigger picture of the world that helps them see it positively. Most women and minorities drop out of computing classes around middle and high school, one way to stop this is to offer mentoring or glimpses into how exciting of a profession it really can be. The presentations we have conducted are easily as fulfilling for myself as it is for the individuals present, I wish more of the community would do similar actions. I do firmly believe that setting up a strong mentoring or apprenticeship program is a vital and under served component of our industry, until we start trying to fix the diversity ratios in the next generation, it will continually get worse.

Q There's a tremendous amount of effort that goes into putting on JSConf. Have you felt that you've gotten a decent return on investment (whether it's relationship, financial rewards, or other)?

There really is a tremendous amount of effort that goes in and countless hours and incredible risk to run a conference the size and scope of JSConf. We are the only major conference for a major programming language that is run by a single family and as such sometimes it feels like we are on a reality TV show (or should be). Defining return on investment is a complex beast because when executing a conference like JSConf where basically everything is on the line and you just hope it all works out like the spreadsheet says it might is almost impossible. I wrestle often with this question because it is a huge strain on my personal life, my family, my work, and my personal code and hardware projects.

I would like to think if I ever needed a job, I could rely on my sponsors as a first line of request, but I don't want to be in a position to test this. I would like to think I am a leader in, at minimum, the JS community, but most people who could identify Alex Sexton, John David-Dalton, or Paul Irish do not have a clue who I am. I do know that among conference organizers, established and aspiring, I am well known which is incredible just to be counted among that crowd.

It is a strange world I live in where I have built a platform by which the JS community rallies together, some become incredibly famous, and yet I have been able to stay very much out of the limelight.

Some nights, I am greatly appreciative and happy of that resultant – others I wrestle with it. I have personal demons that I am slowly coming to terms with – we all want to be known and loved; and sometimes we lose sight of the context within which those goals apply. Sometimes I lose sight of that context and those moments drive me to either change my existence or change my perspective.

One day, that may mean JSConf just ends because family, friends, or work will take a larger importance in my life, many might complain or be angry or write hurtful blog posts, but in the end it is something that is just part of my life, not encompassing of my life, and there are many parts of my life that constantly require juggling, much like I am sure there are for you.

Q I've spoken to some developers who thought you ran all of the various JSConf events but that's not the way it works. This is a great opportunity to explain how the JSConf circuit works and what your grand vision is.

From the very beginning of JSConf, we always had a perspective for growth, mainly because we never wanted to limit the size of the event strictly based on our ability. Furthermore, we didn't want JSConf to be a "just US thing" as it is a global language with each region using it in a different, varied, and exciting manner. One thing I saw all too often from other larger conference organizers was the belief that if an event worked in San Francisco, it should work exactly the same way in Europe or Asia or Africa and to me, something is seriously wrong with that model. Stamping out the same event over and over again regardless of location misses the entire point of having a regional event.

For JSConf, we decided to set up a model similar to a restaurant franchise model where local groups or individuals, after attending an established JSConf, take on the risk and create the event in their own voice. This has yielded events that not only represent JS perfectly but also presents the local culture, leaders, and vibe, because they live in that environment day in and day out. They see the local rising stars long before anyone else does. They meet with the local companies that just need a little limelight to amaze the world. They are from the audience that would attend the very event they are trying to create and that is how they create such an amazing event. This was admittedly an accidental occurrence, but one we would never change as it has made the scope of JSConf so much broader while still making it so specific to the local event. I honestly believe it to be one of the most beautiful and unique aspects of the JSConf series because it is that loose federation that allows it to continually grow, expand, and stay fresh and exciting.

That said, much like a franchise model, we do have some structure to ensure that the event retains the same general ethos and we, established organizers, do have veto/oversight ability to ensure nothing goes too crazy, but otherwise it is a blank canvas for the regional organizer. So from a certain perspective, I do still have influence over all of the JSConf events, but I do not (nor could I possibly) personally execute each event. One thing that I do assert, at the end of every single JSConf event a family picture is taken and posted – to me this is the most important moment of the entire JSConf experience as it represents that you are not attending a single event in time, but becoming part of a broader family and at its core, that is what JSConf is really all about.

Q Has Fluent Conf motivated any changes in the way that JSConf is organized and run?

I have worked to be as transparent as possible with JSConf and things like this actually help inspire new ways to provide others with the information, data, and workflows for creating great events.

Last year, 2012, was the first year of Fluent Conf, something I had seen would eventually happen and mentioned in my closing keynote of JSConf EU 2010 – so at a base level it wasn't too much of a surprise. Over that year, various things happened as the big machine of a publishing company moved in, got settled and began implementing the same time tested methods and marketing that is employed for any large event. None of this was unexpected, but what was unexpected for me was the reactions from the community both for and vehemently against Fluent Conf. I, admittedly, had grievances with the way they propositioned the event as the first and only JS event for developers, but over time came to realize that was just standard marketing copy for any event. Others had issue with the way they handle speaker incentivization (travel, lodging, ticket reimbursement). Eventually this culminated in a rather unfortunate situation, the resultant of which left me with a self-imposed block on all things Fluent Conf, this allowed me to come to terms with the situation before new "information" clouded the picture, thinking slowly about the overall aspects instead of thinking fast in a reactionary response.

In the end, I came to the realization that it doesn't at all matter. The sheer size of the JS developer community is so massive that we could support many Fluent Confs without it affecting the various JSConf events around the world. Furthermore, JSConf is not impacted by Fluent Conf, because they target two very different markets with JSConf addressing the visionary/strategic leading edge market and Fluent (and others) addressing the tactical market and as such they are actually somewhat supportive of each other. As 2013 rolled around, we made decisions on the timing and placement of JSConf US based on one major factor, the impending birth of our son and the ability for us, all four of us, to be able to organize and attend the event. We scheduled the event roughly two months after the birth and picked the specific date based on the best pricing at the venue, unfortunately that is a similar selection process for Fluent Conf (minus the birthing aspect, of course). As such, this year we had a collision of dates which some heralded as a huge issue and representative of attacking between the two events.

This actually couldn't be farther from the truth, Gina Blaber and I corresponded over phone and email to identify how we could work together and created one of the greatest gender diversity fundraising drives ever by a technical conference. We started the #15ForAda campaign for the Ada Initiative and they, Fluent Conf, started a similar donation drive for Girls Who Code, both of which were largely successful and positive events. I am incredibly proud of this outcome and happy with the working relationship between the two events – for next year, we already have coordinated dates so individuals can attend both. One of the things attendees rarely see is how long out you have to lock in dates and put down payments and commit to insane contacts all before even announcing the event.

One of the outcomes from the date conflict this year is I decided to set up a backchannel for all JS events just to provide a space for any JS event organizers to provide early notice, ask for assistance, and offer to help promote each others events. I have worked to be as transparent as possible with JSConf and things like this actually help inspire new ways to provide others with the information, data, and workflows for creating great events. That is something I am confident will yield better events and collaboration that will in turn help foster a better community worldwide.

Q I remember you dropping off of Twitter entirely because of the drama on it. Do you still feel the same or will you be back on Twitter on a regular basis?

One thing I have quickly noticed is we are all focused on the wrong problems of society.

At the end of JSConf US 2012, there was a very angry and direct attack levied against JSConf and specifically myself about the perceived culture we purportedly foster at the event. The worst part of the event was witnessing all of the so-called friends quickly tuck tail and support this new trend despite being completely in opposite. The level of hypocrisy, witch hunting, and willingness to assume guilt without even so much as discussion affected me tremendously. Worse was seeing my wife, who had just dumped heart and soul into tireless nights putting together and putting on JSConf US 2012, read these callous and careless attacks against the event and our efforts. The individual in question, without any fact checking or prior outreach, levied some very exaggerated and aggressive claims against us as organizers that attacked our very spirit, ethos, and destroyed my personal willingness to do any of this "for the community" work again. It was at this point, I burned the very vehicle that allowed this to exist and perpetuate, cutting out twitter and all of its vapid so-called discussions.

The gang mob mentality has won Twitter and it grows worse every day. When you step away from the constant stream and "jump in" encouragement, you quickly start to see it for what it has become. The medium has become ideal for drive-by experts to sling their attacks-veiled-as-opinion in the most attention getting envelope – an envelope stewed in negativity. I am done watching people bicker and have it propped up and encouraged by the angry mob all in the search of blood, regardless of fact or consequence. I am tired of watching people just waiting to tear down anything that contradicts, but doesn't block, their opinion. I am too old and have too much already to deal with to also worry about the constant river that might include some semi-anonymous person that seeks to utilize my efforts, my sweat, and my work as their soapbox to fame.

I have since come back to post a couple bits of information, but for the most part – Twitter is no longer a valid communication channel for me. It holds no sway over my time, my mindshare, or my soul and I encourage you, the reader, to take a similar break – if just to realize how addicted to the constant stream of so-called real-time new you have become. I have taken the rare opportunities I get to present a similar position and one of the items I advocate for is not just disconnecting, but disconnecting with the intent to see reality for what it really is, instead of what we are told to see it as. We are told that we, as developers, must constantly be on the edge of technology and we must be constantly connected in order to stay on that edge – this couldn't be further from the truth. One thing I have quickly noticed is we are all focused on the wrong problems of society. We don't need yet another, faster, more pervasive video distribution network with commenting — we need a cure for cancer, obesity, HIV/AIDS, heart disease, and every other ill that has affected mankind. We need our brightest minds not focusing on scaling social networks but on solving the problem of cheap, renewable energy and widely available clean, fresh water. We need to start focusing on the right problems and putting the right time and effort on them instead of posting more vitriol on Twitter, Reddit, Hacker News, and the like.

If you don't want to spend time doing those things, then at least dedicate the time you might look at one of those outlets to mentoring or teaching computing to the next generation. Trust me, it is a billion times more fulfilling and more impactful than slinging 140 characters. Try it and see for yourself.

Q You've now spun off a new event called RobotsConf. That's a huge shift from JavaScript to robotics. What should attendees expect from this event?

RobotsConf is a chance for software and web developers who are normally confined by fear and learning curves higher up in the stack.

RobotsConf is more than just a new event, it is the dawn of something incredible and arguably something that isn't as much of a huge shift as it might seem at first blush. As mentioned in the beginning of this interview, I am the author and maintainer of the node-serialport project which is one of the main gateways for almost every single Arduino, Raspberry Pi, and other crazy hardware project. Due to this I have had the great pleasure and advantage of watching all of the wonderful things people have done on top of and as a derivative of my project including Johnny-Five, xbee radios, and even educational projects that have been presented to the President of the United States.

Hardware hacking has rekindled my excitement and love for computer programming, my basement has become a robotics lab with everything from a 3D printer to multiple drones to a full workbench with at least a dozen projects in process at any given moment. I am using hardware and things like nodebots and Johnny-five to teach my three year old daughter how to program in a manner that results in a physical outcome (robot, rocket, etc) and pure geek bonding. The beauty of hardware is that it operates in the physical world and just the easy win of getting an LED to blink is so fulfilling and so easy. From soldering to drones to 3D printing, everything I am working on, my daughter is almost always (unless after bedtime) right next to me helping out. So to say RobotsConf is just a spin off is grossly understating its value at a minimum to me.

RobotsConf is a chance for software and web developers who are normally confined by fear and learning curves higher up in the stack. We as developers build abstractions on top of abstractions such that we forget the ground upon which all of it stands and at some point that is detrimental AND becomes its very own prison. I have run several training courses for hardware hacking and the first question I ask is "We are working with USB ports, so how many of you think there is a risk of you getting electrocuted here today," to which most raise their hands. Learning the basics of hardware is not as easy as learning a new programming language, it is a drastically different and scary thing, but once you get the gist, the blend of high level software knowledge combined with low level prototype building capability becomes a very powerful combination.

I am fully aware of events like Maker Faire and others and they do a fantastic job of addressing their market which is mainly people who have worked with hardware and prototyping and fabrication for most of their life (or at least for a fairly longer period than never). To those just getting into the waters, it can be a very daunting uphill challenge made worse by all of the people "doing it so amazingly well", it would be like starting out JS programming by attending JSConf — it doesn't end well, you get frustrated and you never look back. That is not what I want for the rising hardware hacking software developers. RobotsConf is creating that perfect bridge point between high level software developers (JS, Ruby, Python, .NET, Java, etc) and the entire breadth of the maker movement in a non-confrontational, relaxed, social environment of friends.

At RobotsConf, we have the attendees participate in all the workshops from 3D printing to electronic fundamentals to interaction interfaces to robotics so they get a holistic picture of the world, then allowing them to specialize and dive deep into the areas they find most exciting. This is happening all with the guidance of the local, high level language experts (to speak your native programming language and translate to hardware easily) and domain experts (to provide insight into the low level and its use cases). We cap the workshops and build time with some of the best and brightest makers in the world to show the forest of capability and where things are heading. In total, it is a wholly different style event than has ever been attempted and we are supremely excited with how it is shaping up. The main goal is to take someone that writes software, day-in, day-out give them 48 hours of the most exciting and energetic guided hardware hacking so they can know where to go from that point, hence our tag line:

Where Makers Are Made.

When you look at all of the higher level development arena, getting back to hardware development is a massively rising trend. This is exemplified with the increase of dead simple libraries like Johnny-Five for Node.js and Artoo for Ruby and through the creation and expansion of events like Nodecopter, NodeBots and International NodeBots Day. There is clearly a need and a draw for returning to computing basics and the physical world, the combination of which allows a developer to start creating more than just digital items (sites, apps, etc.), but also changing their very own world in the manner we only saw in great 1980s movies. It truly empowers developers in a manner that I would argue few other technologies or technology shifts ever have. This is why I am excited for it and RobotsConf.

What we did for the JS community with JSConf, we are starting all over with RobotsConf, this time, hopefully, a little wiser and for the entire software development community. I am constantly asked by my Ruby, Python, and .NET friends to start something similar to JSConf for them – this is that event. It will be social, it will feature some of the most cutting edge technologies, and unlikely JSConf ever could be, it will be almost entirely hands on.

So the final question, Rey (and readers), why are you attending RobotsConf?

Thanks Chris

To answer your question Chris, while I'd love to attend RobotsConf, especially at Amelia Island, my schedule is really packed so I'll have to miss it this year. Maybe next year!

More importantly, thank you for taking the time to give our readers a peak at your thoughts.

July 25 2013


Interviewing the Interviewer, Part 2: A Chat with Maish Nichani

Earlier this week we shared part one of Steve Portigal and Maish Nichani’s conversation concerning the practice of user research. In the final half of their conversation, Steve asks Maish how he and his firm structure their approach to design research as well as how Maish thinks research might be facilitated in the future.

Hey, Maish! What are some internal initiatives you’ve used to develop interviewing skills within your own organization?
PebbleRoad is a small team comprised of “t-shaped” researchers, so when it comes to collaborating on a project we work to ensure that the “horizontal part” of our T’s overlap. For example, everyone needs to know the process and methodology of research interviewing.
We used to think we could rely on our people to carry the knowledge of our research process, but we were wrong. We kept finding interesting stuff we did many years ago that nobody knew about! To establish common ground, we created processes and tools to guide our practice, including:
  • A toolkit, comprised of guides, templates and forms that frame the practice;
  • Artifacts, which are physical things that give quick access to our shared knowledge;
  • Resources, such as collections of books and articles for new knowledge; and
  • Rituals, which are regular activities to keep the ideas flowing such as sharing sessions called Jolt Fridays!
  • Interesting! What’s in the toolkit, then?
    The research toolkit consists of:

    The toolkit is kept in our Google Drive and can be updated by everyone on the team. It helps establish a common ground upon which further conversations can take place. For example, we can quickly start discussing the research need and plan activities to meet that need.

    I’m assuming the books and articles are physically present in your space?
    Yes, we have a nice collection of 300+ books in our library. We read a lot! Current favourites include Service Design – From Insight to Implementation by Andy Polaine, Lavrans Løvlie & Ben Reason, Thinking Fast and Slow by Daniel Kahneman and Designing the Search Experience by Tony-Russell Rose and Tyler Tate. Our entire catalog is on LibraryThing!
    Could you give me an example of an artifact? Where does something like that live?
    In one of your webinars, Steve, you outlined the different types of interview questions one could ask and what they are used for. We found that list to be very useful when writing the interview planning guide, so we created an interview-types keychain!

    This is an example of an artifact. When we want to use it, we open the ring and spread all the cards on the table. We then discuss which types of questions will be most useful for the interview. When we’re done, we put the cards back on the ring. In fact, for those who want to create their own version, download the PDF or Indesign file.

    Okay, so, I’ve got to know: what happens on Jolt Fridays? It sounds dramatic!
    Jolt sessions typically happen on a Friday morning and anyone on the team can volunteer to host one. The host arranges for breakfast, chooses a topic, and researches it beforehand. We’ve had Jolt sessions on topics like How to Listen, Digital Marketing, Gamification and, yes, Qualitative Data Analysis. We also have screenings such as the documentary Art & Copy: Inside Advertising’s Creative Revolution. The big idea is to widen the organization’s collective thinking – to give it a jolt!
    In the past you mentioned that you were developing an app to facilitate user research. What is the app? Who uses it and for what?
    A few years ago we spent almost half a year developing a research data management app called Insightico. Sadly, we “archived” the project late last year.

    The idea was to collect and store research data in chunks. Researchers could import audio and video recordings, pdf files, ppt templates and other types of files into the app. These files could then be “chunked” up; for example, a video file could be broken up into individual segments and tagged. The big idea was that if we had chunked and tagged data from all sources we’d be in a better position to find patterns. Also, since chunks exist independently we could mix and mash up chunks from different projects for a session on crazy connections!

    The app was hosted in the cloud and expensive to maintain. We did this without any external investment. It was our pet project.

    Very quickly we learned that ideation is an “all-at-once” activity. Researchers are more effective when we can “see” all findings at the same time, not linearly like a blog post, which is how we presented it in the application. We know of only two ways of doing it today: Post-It Notes on a wall and spreadsheets!

    The app design team moved on with their projects and the development team disbanded so we had no other option but to “archive it”. I say “archive,” not “kill,” because I still think the idea has merit. If we can get a good team in place we might just have a go at it again!

    But it sounds like the technology had a limitation in that it didn’t support the “all-at-once” way of engaging with the data? Is that something you would design around if came back to the project?
    Yes. Even the pro research apps, like MaxQDA, are trying to get more visualization capabilities, but they’re not there yet. I think the problem is screen size. Unless we get something larger where many people can simultaneously interact with (multi-touch, multi-user), the physical wall with yellow stickies is going to win. Collaborative ideation needs something like what Jeff Han demoed on TED a few years ago!
    You’ve explored creating very analog and very digital tools to support the research process. What do you think the tradeoffs are in the different approaches?
    Digital is fantastic for capturing data and analytics, but when it comes to inference we need to take it out of the computer, as Jon Kolko advises.

    My biggest peeve is that we should be able to reuse findings across projects. This is where digital can really help but only if we’re strict about collecting it the right way. Vijay Kumar’s recent book, 101 Design Methods, talks of a “User Observations Database” that students can refer to when doing background scans. This database contains results of observation studies across different projects. This is the kind of reuse I’m interested in and it seems to be something for which digital is extremely well suited.

    If you could wave a magic wand and create any kind of tool or artifact to support the research process, what would it be?
    Research is really all about creating new knowledge and the more people who have access to that knowledge, the better. Currently, our research findings and insights are all locked up in (what Karen McGrane calls) “blobs.” We need it, instead, to be “chunked” (as Sara Wachter-Boettcher says) so that it can travel more freely and be mixed and mashed up to create, again, new knowledge. I don’t know of any existing project or initiative but I was thinking about using a schema (like what is already available on for research findings. That way anyone writing up research findings could use the same markup and then search engines and specialist apps could read and move those findings more efficiently.
    A while back, I asked my team to avoid actively discussing examples from a previous project while synthesizing a current one because it felt awkward. While our clients hire us because of the benefit of our expertise, is prior “data” off limits? Every time I hear about sharing across projects, I think about what might be legal or ethical issues. What do you think is our obligation to keep our data and our insights from a project to just that project?
    The main objective of research is to point to a design direction or decision. The multitude of these decisions leads to a design solution, in our case websites, intranets or apps. If we keep this frame, then the criss-crossing of findings across projects becomes a necessity. As an example, we recently did a project on the job market in Singapore. One of the core findings was a deep sense of “entitlement” of young Singaporean jobseekers. The reasons for this attitude are “macro” in nature—recent economic success, changing culture, political freedom, etc.

    Now, our latest project centers on workforce productivity. It would be a disservice to ignore a possible causality between the entitlement mindset and a productive workforce. This is the type of reuse I’m referring to; not about identifiable data, but broad strokes of understanding.

    And that’s a wrap! Thanks, again, Steve and Maish; we’re always delighted to listen in.

    Considering that the interview ended on such an ethical conundrum, I’m curious what readers think: is sharing research data a good thing or a bad thing? What about knowledge, the flashes of understanding we get as researchers? Finally, if anyone knows about a schema for structuring research findings, please share it with Maish in the comments, below.

    The post Interviewing the Interviewer, Part 2: A Chat with Maish Nichani appeared first on UX Booth.

    July 23 2013


    Interviewing the Interviewer, Part 1: A Chat with Steve Portigal

    Whether you’re new to the practice or a user research veteran, there’s always something to learn. So when researchers Maish Nichani and Steve Portigal got together to talk, we were delighted to listen in. In the following two-part series, Maish and Steve take turns discussing some of the oft-overlooked aspects of the craft.

    Over the course of his career, Steve Portigal has interviewed hundreds of people – families eating breakfast, hotel maintenance staff, architects, radiologists, home-automation enthusiasts, credit-default swap traders, even rock musicians. He’s also the founder of Portigal Consulting, where his work has informed the development of dozens of products and services. In his new book “Interviewing Users: How to Uncover Compelling Insights” (recently published by our friends at Rosenfeld Media), Steve sheds light on his seemingly simple but rigorous practice.

    Maish Nichani is a UX practitioner and principal at Pebble Road, an enterprise UX consultancy. He and Steve are friends. Prompted by the release of Steve’s book, the two of them get together to really discuss aspects of their work. They had a whole book to go on, after all!

    Included in the first half of the transcript are the differences between interviewing and day-to-day conversation as well as what Steve describes as the “tipping point” that occurs during research. Later this week, we’ll present a the second half – a sort-of reverse interview – in which Steve asks Maish what he thinks about the current and future state of the profession. And if that wasn’t enough reason to check back in, we’re also running a contest, giving away three copies of Steve’s book. Details below!

    Thanks, Steve, for taking the time to chat! What is hardest part, you think, for newcomers to grasp when it comes to interviewing users?
    I don’t think people really grasp that there’s a big difference between talking to people – something we do every day – and leading an interview. Some people decide to treat interviews exactly like conversations, whereas others decide to act like what they think “real interviewers” do (e.g., a list of questions that are read from a sheet of paper and don’t ever turn into an interaction). Both groups are missing out. Developing an understanding of the ways that interviewing inherits some aspects of normal conversation and the ways in which it differs is what separates newbies from those with a bit of skill.
    What is an appropriate response to give clients who insist on specifying aspects of your research methodology?
    Whenever a client approaches me and has already specified the approach we should take with their study, that’s usually time for a conversation. Sometimes teams create a research plan as a stake in the ground when what they actually want is feedback and a recommended approach. Sometimes, though, their plan is a good one, and we might just suggest one or two changes to see if they are amenable. I can’t count the number of times I’ve received a detailed request, exclaimed “what?!” and then had a really excellent conversation to better understand the reasons behind it. Obviously, no one should take a project where they don’t believe the method is going to produce results. An examination of a prescribed approach is one of the first tests of (the potential for) good collaboration.
    A common stakeholder complaint regarding user interviews is that they take too much time. How do you respond to clients who insist on lean research?
    It’s a red flag when someone approaches me with schedule concerns. Whether it’s their version of a lean process or not, I want to be sure that it’s feasible to address their issues with the given resources. Otherwise, it’s a project that’s going to fail – and no one wants to take that on!
    I provide a “typical,” phased research schedule in the book:

    As well as a version with highly compressed phases:

    My job is to help clients be mindful of the tradeoffs they’re making as they build a project schedule. The more time we spend, the more complex issues we can explore and the more certainty we will have about our conclusions. It isn’t always necessary to reach “the ultimate depths of complexity” with “the ultimate heights of certitude,” though. Clients should adjust the schedule while being aware of the tradeoffs.
    In your book, you suggest interviewers use “transitional rituals.” What are these rituals and why are they important?
    In the same way that interviews are not the same as everyday conversations, the time we spend with research participants is separate from the time we spend doing our “regular jobby stuff.” Transition rituals help interviewers switch contexts, providing a more objective interview. For me, this sometimes means assembling the materials and equipment, checking that I have the documents, etc. That’s sufficient. For someone else, they might want to remind themselves that what they are about to do is focus on the participant. That also has the benefit of reminding them to let go of the stuff-at-the-office – the report they have to give, the meetings they missing, etc.
    You go on to mention a certain “tipping point” that happens during interviews where the interviewee shifts from giving short answers to telling stories. Can you shed more light on that?
    Almost all interviews (if done well) get to a point in which the interviewer receives a great deal of information without feeling as though they’re “pulling” it out. For some interviewees, this happens in 30 seconds; for others it might 30 minutes, 60 minutes, or more. Ultimately, it’s an unpredictable element. While it doesn’t always happen oftentimes, when running an interview, I have the realization “Oh, now we’re there!”
    Are transcripts of interviews necessary? Do memos or notes suffice in some situations?
    Notes taken during or before an interview are filled with inaccuracies. It’s just beyond human capacity to fully capture everything. You need an audio or video record. Whether you later transcribe those (my preference) or just watch them again is up to you, but notes are not the same as the definitive recording of the interview.
    How do you identify insights when going through interview data? In other words, what makes an insight an insight?
    Insights come from successive refinement. I like to have conversations with my team throughout the research process about what we’re hearing. That way, when we’re actually going through the data, it’s not the first time we’ve reflected on what is interesting. Later I go through data with two filters on: the first is looking for specific things that I’ve already identified as areas to understand; the second is looking for things that strike me as interesting. But going through data is just about gathering individual data points; it’s when you put them all together into something new (e.g., synthesis) that you start to be able to report an insight. As far as defining the term, ugh; I’ll let someone else worry about it!
    Last question! What are some tips for design teams to spread the use of research findings inside their organization?
    In short, it’s best to look for opportunities to share findings throughout the process [Ed: notice a pattern?], not just when you’ve got “findings.” I cover this in more detail in my presentation “Championing Contextual Research in your Organization.”

    That’s all, folks! Thanks again, Steve and Maish, for sharing your knowledge with us. Here’s a summary of Steve’s points:

    • Leading an interview is very different from everyday conversation. This subtle difference makes all the difference.
    • Methods-first briefs (in which a client prescribes a process) provide opportunities for researchers to meet clients and understand their approach.
    • Research can’t be rushed. Time is commensurate with outcome.
    • Transitional rituals provide time to remove our own hat and wear our participant’s.
    • Tipping points indicate states of flow during an interview, a natural outpouring of information.
    • Always record interviews when you can. Don’t depend on memory or scribbled notes.
    • Insights come from two points of view: what’s specified as part of research and what’s personally interesting!

    In Part 2, later this week, we’ll share the “reverse interview” in which Steve Portigal asks Maish how he and his team work to hone their skills over time and as well as how research might be stored in the future.

    As for the book giveaway, longtime readers know the drill. To enter, simply follow @uxbooth on twitter and leave a comment on this post answering the question: What’s the most surprising thing you’ve learned while conducting user research? Be sure to include your twitter handle in your comment and to leave it before this Thursday at midnight PST. We’ll contact winners over Twitter. Good luck!

    The post Interviewing the Interviewer, Part 1: A Chat with Steve Portigal appeared first on UX Booth.

    July 17 2013


    Interview With Elijah Manor

    It's truly a unique and interesting experience to watch someone transcend from one community to another with little to no issues. In this case, we're talking about Elijah Manor who successfully worked to build his reputation in the open source community while still maintaining his strong presence in the Microsoft world. He has the best of both communities at his disposal, now able to leverage his cross-platform expertise into a new life-changing role with Pluralsight.

    We managed to snag some of Elijah's time amidst the many projects he has going on to learn about his new direction and how Microsoft has impacted his development views.

    Q You left a pretty comfy role at appendTo. What are some of the challenges you're finding now as a freelancer?

    I used to tell myself I'd never start my own business, but it came to a point where going out on my own just made sense.

    The time I worked at appendTo was great. I learned a lot and was privileged to work with a great and talented group of developers. While I was there, I participated in several consulting projects, architectural reviews, worked closely with Microsoft on some interesting projects, and led several front-end web development training classes.

    I left appendTo to try to focus my time primarily on the training, since that is what I've become passionate about over the years. I enjoy blogging, teaching, writing, and speaking and I wanted to try to find a way that I could do those full time. I used to tell myself I'd never start my own business, but it came to a point where going out on my own just made sense.

    I've actually only been on my own for about 3 months at this point. I am currently working with Pluralsight to author several front-end web development courses until the end of the year. I've finished two courses so far entitled Front-End First: Testing and Prototyping JavaScript Apps and Fixing Common jQuery Bugs. I'm also in the final stages of releasing another course in the next week or so called "jQuery Tips & Tricks" that will be available from my Pluralsight profile.

    Some of the main challenges I've faced thus far are trying to figure out how to start a business, how I go about paying business taxes, getting personal health insurance and dental coverage, and things like that. I've always relied on an existing company to provide or do many of those things for me. This is a brand new world that I'm slowly trying to figure out. Thankfully, I have a great financial counselor, lawyer, and CPA to help me navigate these uncharted waters.

    Q Focusing almost exclusively on Pluralsight is a gutsy move, especially since its author income model seems to be a long-tail revenue play. How do you envision turning your courses into a sustainable revenue stream and how long will that take?

    I have a wonderful wife and three lovely children and it's a huge priority for me to make sure I can provide for them, so before leaving appendTo I wanted to make sure we could handle this transition. It is true that Pluralsight pays royalties to their authors for how much of their courses' have been viewed, however, they also pay the author a completion fee at the point when their course is published.

    I've agreed to do at least 6 courses for Pluralsight which should get me close to the end of the year. After I finish the 6 courses my hope is that there will be a steady stream of royalties, but there is a risk on exactly how that will turn out. I will then reevaluate where I need to focus. I would like to continue making courses for Pluralsight, although I will most definitely need to slow down the pace some. I'd like to eventually start focusing on making my own content for on-site and remote trainings, but I'm not quite sure how that will play out. If I'm not making traction with any of these ventures, then I may start doing hourly work with a consulting company to help provide some consistency and stability.

    Q Your "Angry Birds of JavaScript" blog series seemed to be a hit. Have you received any feedback that this method of topic presentation resonates better with devs versus more straight up posts?

    I wasn't sure how the series would go over when I first thought of the idea. I liked the idea and this is my type of whimsical humor. Up until recently many of my blog posts and talks haven't shown my personality and I wanted to try and switch things up a bit.

    The blog series was really an attempt for me to make a new talk at a steady pace. Usually when I make a new talk I invest a lot of time working many nights right up until I present the session for the first time. Instead, I wanted to have a blog series that I could continue steadily and then string them together to make a new talk. The nice thing about this approach when speaking is that I can also add, remove, or swap items from the blog series depending on my audience and the amount of time I have to present.

    Generally, I have gotten positive feedback on this particular series in that it was clever, easy to search for on the Internet, and that there was a lot of helpful information. I've also received some negative feedback in that I was stretching the analogy a little too far, but that is totally understandable and I can see that viewpoint. My main goal was to create a semi-interesting storyline that might be memorable, fun, and informative at the same time.

    Q We first met during the early jQuery days and I've since seen you take a sharper interest in plain JavaScript. Where does jQuery fit into your workflow nowadays and what are the development decisions that are driving you to choose plain ole JS versus any library (not just jQuery)?

    If you look closely, you'll also see an interesting trend among front-end web developers to move away from jQuery altogether and to instead start using modern browser APIs.

    Over time I've continued to narrow my focus to what interests me at the time. I mainly picked up jQuery because I started to learn ASP.NET MVC before its official 1.0 release. I would read Phil Haack's blog and notice that he used jQuery to help with his Views. It was then that I started to learn about the ins and outs of the library and is when I began to engage with the community.

    Once I started working at appendTo, I was placed on several projects that challenged us on how to structure and architect large applications. jQuery was still a large part of our project, but in order for us to address the needs of the project, we needed other constructs and patterns to assist us as well. At first we came up with our own organizational techniques, but when we eventually moved towards making jQuery UI Widgets and then picking up Backbone.js and RequireJS to aid our development.

    If you look closely, you'll also see an interesting trend among front-end web developers to move away from jQuery altogether and to instead start using modern browser APIs. Although this is doable with modern browsers, I don't see the vast amount of developers going this route, at least not anytime soon. However, what I am seeing is a lot of developers moving to adopt AngularJS, which natively doesn't depend on jQuery, or other MV* frameworks. If this trend continues, then I do see the overall usage of jQuery decreasing over time, but it is hard to gauge how quickly and over what duration.

    With that said, I still think jQuery is important and that developers should know how to use the library and to understand what is really going on, which is why I've worked on two jQuery specific courses for Pluralsight entitled Fixing Common jQuery Bugs and soon to be published "jQuery Tips and Tricks" co-authored with Dan Wahlin, which will be listed on my Pluralsight profile once it's live.

    I briefly touched on this, but I do encourage you to pick up other tools for your toolbelt. For example, pick any of the MV* frameworks and invest some time learning one of them, whether it be Backbone.js, AngularJS, Ember.js, etc…

    Q You're a bit of a cross-over star in that you've bridged between your Microsoft .NET background into the OSS-based web development community. How has your experience with the Microsoft stack affected your development when shifting to OSS tools?

    Well, I'm just this guy who likes to learn and to share that with others. I started using ASP.NET WebForms many years ago when I worked at Acxiom in Arkansas and then I eventually moved to Nashville, TN to continue to work with .NET technologies. As I mentioned previously, jQuery only came to my attention when I started to use ASP.NET MVC. At that point, I was slowly introduced to the broader non-Microsoft community. In some ways it was a shock, but in other ways it was not. I was used to pretty good documentation by Microsoft and that their tools and libraries just worked well together. However, documentation can be lacking in many OSS projects and it can sometimes be hit or miss whether an OSS project will "play nicely" with another project. These are over generalizations and there are numerous exceptions to both of these statements. What I'm actually seeing is that both worlds are starting to meet in the middle, which is great for all!

    Q In some circles, building off a Microsoft stack is looked down on, which I think is a load of crap. If you could chat with a non-MS web developer, what would you tell them about your experiences with the MS stack compared to OSS stacks?

    The thing that I like about the MS stack is how much effort Microsoft puts into making them work well together. There are exceptions of course, but it's in their best interest that they work together and you can tell a lot of effort has been invested in that. What has most encouraged me about Microsoft in the last five years is the amount of focus they have put into OSS and how transparent they have been on many projects and tools. In addition, many of the new services and frameworks they are making provide extension and integration points, allowing developers to tie into well known non-Microsoft technologies such as Git and Node.js for example.

    Q You've recently become an "IE userAgent" which is similar to many MVP-style programs. Can you tell us what this about?

    The IE userAgent program is a new program that was started several months ago. The agents are a group of developers who love web standards and are passionate about web technologies. You will probably see us around in various developer communities across the web trying to promote cross-browser coding best practices and encourage and assist developers as they run into issues or roadblocks.

    Much of the negativity towards IE is usually targeted towards oldIE (IE6/7/8). IE9, IE10, and especially IE11 have really done a much better job on focusing on web standards and in many cases, as long as you follow many of the best practices, IE9/10/11 will just work. There are gaps in functionality as you can see from Can I Use, but for many of those you can utilize Modernizr and use a Polyfill or Shim to bridge that gap.

    I would say that IE userAgents aren't sold out for IE. Many of us actively use other browsers as well. We, as a group, want to see IE continue to move forward, we want to see websites work everywhere, and we want to make it easier for developers to do their job. is a great initiative, that the IE userAgents stands behind, and provides tools for developers to make it easier to test and debug their applications in oldIE as well as provide a nice tool to analyze your site for common coding problems.

    Q The "IE userAgent" program is obviously focused on Internet Explorer. How has this affected your usage with competing browsers like Chrome or Firefox?

    As a developer, I enjoy the Chrome DevTools a lot.

    Being an IE userAgent has encouraged me to use IE10 more than I did otherwise, which is great, because I've been able to provide feedback to Microsoft about the things I like and also areas where I would like to see improvement.

    You might find this strange, but I personally use Google Chrome as my primary browser. At the same time, I want Internet Explorer to succeed and I think it's important that developers don't code themselves to only one browser or rendering engine.

    As a developer, I enjoy the Chrome DevTools a lot. They move very quickly and I use the Canary build because I want the latest stuff now. With that said, I've been very impressed to see all the great work that Microsoft has put into the recently announced IE11 Developer Tools.aspx) and I look forward to watching those tools get even better. It's in my best interest to have multiple browsers on my machine and to be able to use them to their fullest as I develop applications and teach others how to do so as well.

    Q Where do you feel Microsoft is really doing well and what are the things you feel they could improve on?

    I have really enjoyed the transparency of the Visual Studio and ASP.NET teams in how they progress and communicate, not only in the public, but also among the Microsoft MVP and ASPInsider programs. Over the last several years I have participated in those programs, they have been very open about our feedback, have included us in their direction, and have enabled us to feel as we are guiding the future of those tools and libraries.

    However, with regards to Internet Explorer, I would say that transparency is also an area where Microsoft could improve. IE has thankfully changed a lot in terms of adopting web standards, having a renewed focus on performance, and pushing the web forward. The area that seems opaque is what features might come out in the next release of Internet Explorer and when those features might be released. This is easier to track with other browsers since they have weekly, daily, and nightly builds accessible to developers. Developers expect a new release of Internet Explorer at best only once a year. Those are some of the frustrations that I see in the developer community. I understand that Microsoft's model is different from their competitors and I imagine that comes into play with many of these decisions. I don't know the answer to this riddle, but the great and encouraging news is that with the introduction of the IE userAgent program, I have seen topics like these being seriously discussed and I have seen progress being made.

    Q I've always wondered this. You tweet at all hours of the day, so obviously you're buffering tweets (or you're a vampire). How do you decide what you want to send to your followers and what are the tools you're using to manage this?

    There have been several times where I've said that I would stop tech tweeting for one reason or another, but in the end I keep coming back.

    Yeah, I am not physically tweeting all the time. If that were the case, then I wouldn't be able to get anything done. I first started tweeting tech related articles because I was already scouring the web for new tech news and thought I'd start sharing those on twitter. I did most of my research in the early morning and then I'd tweet them all out, but soon found that was annoying some of my followers. So then I wrote a desktop program to schedule my tweets so that I could make the information more digestible. Since then, I've used other online systems to schedule my tweets and I currently use Buffer which works really well for my needs.

    When I first started sharing tech tweets the quality wasn't as high as they are now, but unfortunately, I didn't realize that at the time. I was pushing out numerous "Top 10 jQuery Plugins" types of posts, that tended to be popular, but really didn't have much substance to them. In addition, the more I've learned about front-end web technology, I've been able to better identify what is valuable and high quality.

    There have been several times where I've said that I would stop tech tweeting for one reason or another, but in the end I keep coming back. It really has become a part of who I am and what I do. I enjoy knowing the latest and greatest tools, tips, and technologies in our field and I also enjoy sharing those with developers that are interested. So, tech tweets are a natural extension of what I am already doing and is a way I can be involved with our community. There are many other avenues to get this information. A great list of resources of how you can keep up to date with various front-end technologies can be found at the Front-End Rescue.

    Thanks Elijah

    So now that we know that you're actually human and not a non-stop tweeting robot, we want to thank you for sharing this great info and wish you great success with your new endeavor!

    July 04 2013


    Interview With Dan Croak of Thoughtbot

    Dan Croak is the Chief Marketing Officer of the prominent development shop thoughtbot. Before he moved to San Francisco to start thoughtbot’s west coast branch, Dan was a friend of mine in Boston who helped me learn the ins and outs of Ruby on Rails.

    Dan’s a good guy to know because he and his shop have authored everything from core Rails commits to numerous gems and plugins (such as Capybara Webkit and Bourbon) that are known throughout the web community. I wanted to sit down with him and talk about Rails, its evolution, and how his company has built such a following around Ruby on Rails.


    Q How did you get started with thoughtbot?

    I hired thoughtbot in 2006 to complete a side project. I was writing ASP.NET web applications by day. I wanted to learn about open source, Ruby on Rails, Test-Driven Development, Unix, version control, etc.

    After they completed the project, I did some Rails freelancing, then applied for a job at thoughtbot and they hired me. I’ve now been at the company for more than five years.

    Q How did your firm settle on Ruby on Rails?

    Rails struck them as something that would be great.

    In 2005 Jon and Chad had been doing consulting projects in different languages, such as Perl and Java. After they did a couple of projects in Ruby on Rails, they felt it was state of the art and that they could be reliably productive with it.

    As a team, they needed to pick one language/framework and specialize in it. Rails struck them as something that would be great. The community surrounding the language were the kind of people that they would want to work with. They were one of the first consultancies to announce that Rails was their specialty.

    That was the turning point – they could have been a shop that split technologies but by picking one, especially an up-and-coming one like Rails, they were able to attract great people like Tammer Saleh, Jared Carroll, Eric Mill, and others.

    Q What role does Ruby on Rails play in your business?

    In total, our team currently spends about 2,000 hours/week interacting with Rails and its ecosystem. It is the main medium from which we work with our customers. It’s the environment we feel most efficient, and most able to create software with a solid test suite.


    Q What’s your favorite part of Ruby/Rails?

    I’m currently in a role where I’m reviewing a lot of code – reading thousands of lines of diffs a day – and it’s nice to have a language that doesn’t have a lot of ceremony or extra tokens. In the last year, we’ve developed a style guide that makes it even easier and more pleasant to review lots of code.

    There is always some shortcut in Rails to clean up a view by letting it render partials polymorphically, based on its type and based on conventional directory structures. Things like HAML and CoffeeScript further reduce clutter and help simplify the code to focus exactly on your ideas and how to express them in a web app.

    The community is a huge benefit, too. Ruby is a very stable, 20-year old language with a gigantic community. Libraries for dependency management (Bundler), testing (RSpec), authenticating users via OAuth (Omniauth), are in a great state. is a tremendously useful community effort. There are thousands of Rubyists with GitHub accounts contributing to gems. Ruby is the second-most represented language on GitHub.

    Q What role has thoughtbot played in the development of Ruby on Rails?

    Once GitHub came out, it became obvious that Git and GitHub were the superior way to share code.

    Prem and Arun show up on the Rails contributed list.

    Paperclip and Shoulda were early libraries that became pretty popular in the community. Both were continuations of testing and file uploading that we did before. Paperclip was inspired by file_column and attachment_fu. Shoulda was built atop Test::Unit – similar to how Sass was built atop CSS. That process of improvement is never ending in the community. Other great efforts in the file attachment tradition continue today with CarrierWave and

    I remember coming to Rails and learning a ton by going to technoweenie’s Subversion account. Paperclip and Shoulda were open sourced on a custom Subversion instance at

    Once GitHub came out, it became obvious that Git and GitHub were the superior way to share code. We moved our older libraries over to GitHub and have continued to chip in on other projects and some of our own. Shoulda has evolved into a library that works beautifully with RSpec. Factory Girl was written to replace fixtures.

    We added test spies to a fork of Mocha, then a standalone library called Bourne that extended Mocha, and more recently added spies to RSpec Mocks. We didn’t invent the test spy technique (we recommend everyone reads xUnit Test Patterns), but we worked hard to bring them into our workflow and add them to the existing tools in the community, evolving as those tools have gotten better and gained community support.

    We wrote Clearance (which I personally maintain) after writing email-and-password-based authentication a few times by hand. We wrapped it in a library with a great automated test suite. It’s now a battle-tested, four year old library. Things like that we’re always trying to tweak and improve, as well as blog about it to keep the community informed and see how we’re evolving our practices.

    Q What is your development process for a web application? How has it evolved since you started using Rails?

    We’ve described our development process in our playbook and guides.

    I’ve taken better advantage of my shell (zsh) and editor (vim). I’ve tightened my feedback loops, particularly when writing tests. I’ve gotten more consistent and disciplined about style and Git flow. I understand and use object-oriented techniques better.


    Q What do you think about the new Ruby 2 and Rails 4 releases?

    I think they’re great! I’m most looking forward to the speed improvement and named parameters in Ruby. I’m most looking forward to the additional Postgres integrations in Rails 4, like hstore and database array types.

    We don’t have any major projects in production on Rails 4 or Ruby 2 yet. Looking at the history of past releases, we tend to be careful not to jump the gun. We’ve been testing our open source libraries against both versions for awhile and reporting any issues back upstream, fixing what we can, but for the sake of our clients, we’re a bit more conservative to adopt the newest technology.

    Q How do you want to see Ruby on Rails evolve in the future?

    For a long time, I’ve been wrapping my head around some of the base choices you need to make as a developer. We’ve had a less-than-a-hundred-line shell script called Laptop for a couple of years to help us set up new machines while documenting the current best practice we know of. I still think there’s lots of room for improvement here, though.

    Let’s say you’re using OS X. You probably want to use Homebrew but it’s not the standard package manager for the operating system. I’d like to see Apple make that the standard. In the same way, Ruby installers, Ruby switchers, Bundler’s binstubs, the .ruby-version file community convention, and rbenv’s shims continue to evolve to manage different versions of libraries that you want to use on different projects.

    Q Will thoughtbot always be a Ruby on Rails shop?

    It’s unlikely we would make a primary replacement for Ruby as our server-side language.

    I don’t know! In the near future, definitely – there’s a lot we can accomplish with Ruby, SQL, and JavaScript. It’s unlikely we would make a primary replacement for Ruby as our server-side language. It’s more likely we’d work on projects that use service-oriented architectures and the various services start to use alternative frameworks and languages such as Go.

    I’d expect us to be more polyglot as opposed to replacing Ruby. We’ve used lots of databases in the past few years, although, Redis and Postgres can currently handle 99% of our use cases.

    I’d also like to try doing something like the Barack Obama 2012 campaign’s architecture, which was static HTML/CSS/JS served by Akamai and S3, with hundreds of backend APIs.

    Q Any final advice for people just getting started with Ruby on Rails?

    We’ve worked really hard for years to put our best advice on Learn Rails. We have a “trail map” specifically for learning Rails and we’ve curated it from across the web and in our own shop. Go in there and you can see which resources we recommend going through in which order. There’s an iPhone app that helps you self-assess your own abilities and keep track of your progress along the Rails, Git, Postgres, JavaScript trails, and other trails.

    In Conclusion

    Thank you Dan for taking the time to do this interview, we really appreciate it.

    June 25 2013


    A Q&A with UX Mad 2013

    When it comes to meeting with the community in-person, UX designers have plenty of events to choose from. One particularly unique option is UX Mad, bringing together speakers from all different walks of life. As it turns out, those walks of life were also prime candidates for an interview.

    UX Mad is an annual, one-track, user-experience-design conference held every July in Madison, WI. Featuring a wide variety of speakers – from professional musicians to craft ice cream makers – it offers attendees an opportunity to meet and mingle with an otherwise disparate group of passionate creators.

    In fact, the lineup reflects just how multidisciplinary experience design can be. Looking at their various backgrounds made me wonder: where do these speakers overlap? The answers, you’ll find, are surprising. Read on for wide-ranging insight into the creative minds of this year’s speakers and even a chance to win a ticket to the event!

    How do you define user experience? How did you get into it?
    Lea StewartLea Stewart: UX is a way to describe an ecosystem of products and services that consider a users’ needs, behaviors, and attitudes. Coming from Industrial Design, I don’t think of it as strictly digital. Instead of developing a next-generation training shoe, a UX designer might envision the “experience of running”.
    MoldoverMoldover: To me, user experience represents a change in focus from simply getting something to work to making it as intuitive and enjoyable as possible.
    Sergio NouvelSergio Nouvel: User experience is an evolution of design in general. Once you begin to care about users, you start to wonder which factors influence a good design beyond the mere look-and-feel. You start being a lot more aware of how easy the interface is to consume (which itself depends on how the content is structured, what it intends to do, etc.)
    Can you give us a sneak peek of your talk at UX Mad?
    Jenn DownsJenn Downs: Marketing automation is a powerful tool, but if used incorrectly it can reduce empathy for the user. Using technology to manage the relationship isn’t a replacement for human-to-human contact.
    Jessica PetersonJessica Peterson: I’m taking part in a discussion panel of people chosen from distinct disciplines with a similar regard for the role of research in the design process. We want to demonstrate why the science of research and applied research is critical.
    MoldoverMoldover: Human interface design for musical instruments presents unique challenges and vast new possibilities. The proliferation of low-cost rapid-prototyping tools has put the means of fabricating instruments within reach of any potential musician. I’ll go through the design process for some of my inventions.
    Pamela PavliscakPamela Pavliscak: Data isn’t just a four-letter word. Numbers let us track improvements and setbacks over time, communicate important information at a glance, and tell us where we stand against competition.
    Russ UngerRuss Unger: I’m giving a talk about Jim Henson and how the way he worked applies to what we can do in UX. It’s not one of those “X Things We Can Learn About UX From [a person];” it’s about the way he worked. It’s a little bit of history, observation, and fun. Oh! And Muppets–lots of Muppets! Probably a bunch of stuff you never knew about them, and Jim Henson!
    What was the last creative project you did for fun? How do you deal with blocks?
    Jesse ShternshusJesse Shternshus: I’ve been working with a designer to re-brand my company. I challenge myself by giving myself a couple minutes to think of as many terrible ideas as possible. Sometimes really good ideas come out of it.
    Martin AtkinsMartin Atkins: I like speaking and work pretty hard at the payoff of that. The same goes for my books. There’s a difference between the information and the delivery of that information in a form that works. I try to have enough going on that when I am creatively blocked I can keep my energy output up while the wheels and cogs keep turning and (hopefully) magically produce the solution like some fairground wizard.
    Pamela PavliscakPamela Pavliscak: Even though I observe and talk to strangers using technology all the time, I’m pretty awkward when it comes to mingling in large social groups. Recently, I had to go to an event by myself, so I decided random UX testing might at least give me some conversational gambit. A few takeaways: find a quiet corner, talk to people early in the evening, make friends with all the servers, and let people see some results.
    Sergio NouvelSergio Nouvel: How do I deal with creative blocks? I don’t. I don’t regard hitting the point of frustration as a “block”. I see it as a necessary step. I never consider myself blocked, so it helps a lot with the feeling of being blocked.
    What does mobile mean to user-centered designers?
    Andrew MaierAndrew Maier: Mobile means we can no longer depend upon a certain context in which people will use things (not that we ever really could). As a consequence, we have to make our solutions more robust – to consider alternative ways of presenting information and affording functionality.
    Golli HashemianGolli Hashemian: Honestly, it annoys me that everyone focuses so much on mobile as a separate topic of user experience. From a high level, designing for mobile isn’t a separate process – it’s an evolution of user-centered design. We study how our customers use our product and design accordingly, taking context into account as well.
    Sergio NouvelSergio Nouvel: Mobile has always been with us simply because we are mobile beings (unlike a tree). Mobile isn’t new: think of a watch as a mobile analog device. Mobile is a context. Devices will keep changing, and what really matters is not the resolution or the touch screen, but the context – the unpredictability of what’s surrounding a user, what state of mind they’re in, or what else they’re trying to do. The first step is admitting our inability to cover absolutely every scenario.
    What disciplines within user-centered design excite you? Why?
    Andrew MaierAndrew Maier: Civic design & social entrepreneurship. They’re areas that absolutely need our attention (as designers) because they have the most power to affect people on a day-to-day basis. Democracy is interactive by design. Nowadays, we’ve lost that feeling of empowerment.
    Jessica PetersonJessica Peterson: Nothing beats first-hand research. Making sure we understand what the users are thinking and what their needs are is just as important as making sure the interface is well-designed, the colors and proportions and pleasing, and the features are usable.
    Lea StewartLea Stewart: My background is in industrial design, so that’s where my passion lies. I have an internal struggle with creating more “stuff” that may someday be discarded. I focus on sustainability and to ensure that whatever I design is truly needed and wanted by users instead of heading for the landfill.
    MoldoverMoldover: Hardware. It’s refreshing to make physical objects when we spend so much time manipulating digital “things.”

    That’s all, folks! A big thank you to all of this year’s speakers for taking the time to answer our questions. Everyone listed above (and more!) will be in Madison this July 12-13, so come on out, meet them, have a good time, and eat some cheese!

    Welcome to Wisconsin

    Will we see you there? UX Mad is just a few weeks away. If you haven’t bought your ticket yet but you’re itching to go (especially after such riveting responses), you’re in luck: we’re giving one away.

    To enter, let us know who you’re most excited to meet and why in the comments below. Be sure to follow @uxbooth, and to leave your Twitter handle with your comment so we can get in touch with you for your freebie. Entries must be in by midnight (PST) June 27th. We know it’s tight, but we want to give the lucky winner the time to arrange travel and lodging, as we can’t provide those. Good luck!

    The post A Q&A with UX Mad 2013 appeared first on UX Booth.

    June 19 2013


    Interview With David Walsh

    Have you ever meet a brash punk kid that annoys you to no end but he's so damn talented that you can't help but want to work with him? That's how I felt when I first met David Walsh several years ago. Since then, I've seen him mature into a respected and often quoted software developer and most recently, a new dad. He hasn't lost his snark and feistiness and he continues to hone his skills daily, often sharing his best tips on his awesome namesake blog.

    It's time to get a little more info on what makes David tick and I had the opportunity to hit him with some tough questions.

    Q Silly question, but why did you go with a ".name" domain for your blog?

    My blog's domain was originally "", but I decided to brand the blog after myself since BluDice doesn't mean anything and it certainly wouldn't help me in my career path. All of the relevant .com's were taken and since I wanted to brand my blog after myself, .name just seemed to fit. In hindsight, I should have tried harder to find a .com. I bought "" a few years ago, so maybe I'll migrate to that some day.

    Q When we first met, you were a big proponent of MooTools. Are you still involved with the project?

    I'm not involved in the project anywhere near as much as I used to be and not as much as I would like to be. Job circumstances (working at SitePen for two years, which is a Dojo shop) took my attention away from MooTools. I'm still in the MooTools development IRC channel each day and still keep up with where the next version of MooTools is at, so I'm involved enough to know what's going on at all times. I also hope to make it to the next MooTools Hackathon in London.

    Q It's safe to say that jQuery won the hearts of most web developers. How did that affect the roadmap for MooTools?

    MooTools was created to provide a modular, compact, Class-based JavaScript utility, which was different than jQuery's goal at the time. jQuery's popularity didn't affect the MooTools roadmap at all. MooTools' goals and mission never changed beyond what we set for ourselves. Developers believe there is a competition or hatred between the JavaScript frameworks, and it simply doesn't exist, nor did it ever.

    Q There was always this "thing" between the jQuery & MooTools teams (I like to call it hyper-competitiveness). It seemed like both should've been able to co-exist but it didn't quite always work out that way. From the MooTools perspective, what were the underlying issues you saw?

    Creating crap code is possible with any framework…

    I can't answer this for the MooTools team, so my answer strictly represents my own thoughts. The tension between jQuery and MooTools was built up by members of the community, not necessarily the team members themselves. Maybe there was more on the jQuery side, but I know that we didn't give jQuery much thought.

    The main issue that jQuery has fought, from the perspective of other JavaScript framework users (not just MooTools), is that the low barrier of entry enables "n00b" developers to create a lot of unoptimized, crap code. Creating crap code is possible with any framework, but the other frameworks required more JavaScript knowledge and thus were more able to avoid this problem, to a degree.

    I also get the feeling that other framework users get hung up on jQuery's popularity and seeing it as an inferior toolkit; i.e. the "McDonald's" analogy that they're super popular but that doesn't make them good. Unfortunately in my experience in having worked within a whole bunch of different JS toolkit communities, jQuery seems to get the brunt of negative comments.

    I've been long accused of being a "jQuery hater", and while I'll admit that jQuery isn't my cup of tea and I don't choose to use it on my personal projects, I far from hate jQuery. It's a tool, like any other, it has been hugely helpful to millions of developers around the world, and that's something you must respect.

    Q Even while on the MooTools team, you created quite a bit of jQuery content. How did that go over with the rest of the Moo team?

    Aside from the locker room ribbing that I'm sure comes with being a part of any group, no one said anything, and why should they? In reality, creating mirroring tutorials and demos with both jQuery and MooTools helped to bridge the perceived code gap between the two frameworks, and hopefully got users of each framework to try the other. I learned a lot from the experience and hopefully others did too!

    Q I think people take for granted how hard it is to manage an OSS community. What were the challenges you faced as one of the more active team members?

    There are a number of challenges that come with being an active member of an open source community. Organization is incredibly difficult because you must deal with language barriers, cultural differences, time zone differences, and interesting personalities. You also need to keep in mind that OSS work usually isn't a developer's primary job (thus they aren't getting paid for the OSS work) and that they also have a family to spend time with. And of course, most OSS devs just want to develop and not promote or formally release work in a timely manner.

    To succeed in open source communities, it's important to be understanding, patient, and willing to work with different types of people. Everyone has a good heart, and everyone wants to succeed, but each brilliant dev has their own route of getting there. Once you learn to manage your contributors, your project will succeed and more contributors and users will flock to you!

    Q There's a big push in the industry away from libraries and frameworks, instead focusing more on pure JavaScript. How do you see the two blending? It seems they should be complementary, not one or the other.

    In a perfect world, JavaScript framework users would use the modules they needed and would avoid massive load.

    They should be complimentary, yes, but there are a few problems that we've seen since the explosion of framework usage. The first problem is that developers will include an entire framework (animates, AJAX, etc.) just to solve one problem, and thus bloat their website tremendously when a microframework or a few lines of pure JavaScript should do the trick. Another problem is that relying on frameworks and their abstractions prevent the developer from truly increasing their JavaScript skills.

    In a perfect world, JavaScript framework users would use the modules they needed and would avoid massive load; unfortunately that isn't a common enough practice today. More and more developers are adopting this practice though, so I'm hoping this won't be such a debate in the future.

    Q How do you see the new features of ES6 affecting the functionality of existing libraries? Will we see them become more specialized?

    They'll have to become more specialized and evolve or they'll find themselves irrelevant. Of course, we all know how long it takes for browsers to implement these types of new features, so we're assuming the same JavaScript frameworks will be there at that time. The main thing we can count on, however, is that evolving is the only way for any project to survive.

    Q Your work at SitePen allowed you to dig deep into the Dojo framework. What do you think is the reason that it didn't pick up the level of traction of other projects like jQuery, Prototype and MooTools, especially since many of the features we promote today were in Dojo for some time?

    Some JavaScript frameworks are heavy into promotion and some aren't. Dojo developers definitely aren't. Dojo also had a stigma of not having good documentation, which may have turned people away. I would also argue that Dojo's always been more focused on building feature-rich "web apps" rather than basic websites. Dojo's documentation has gotten much better and they continue to push the client side boundaries more than most JS toolkits, so I would really encourage developers to give Dojo a shot!

    Q Now that you're at Mozilla, have you seen any major changes in the way you structure your development considering you're working on a large web property and you're remote?

    Being a remote developer doesn't play as large of a role as most would think.

    Going from creating private, internal web applications to working on an important website that gets millions of views each month forces you to reevaluate your development process. The MDN (Mozilla Developer Network) team has adopted a frequent release cycle, pushing code updates many times a day. Spot checking and unit tests become increasingly important as we add features. Localization plays a massive part in MDN development too. Each piece of code requires a lot of thought, so we do code reviews before merging any changes.

    Being a remote developer doesn't play as large of a role as most would think. Our QA engineers and IT team are always there to lend a hand. Mozilla has made remote development a breeze.

    Q How does the dev team at Mozilla collaborate so well, especially with many being remote?

    Mozilla does well in recruitment so I work with dozens of brilliant, dedicated, and responsive developers. Most communication is done via IRC and Bugzilla tickets, and we're never shy about jumping on Vidyo or Skype to get some face-to-face time. Remote employees have weekly 1:1 meetings with managers to ensure everything is going smoothly. Most teams have a bi-monthly meeting where the team can discuss what progress has been made and what goals should be tackled next. Mozilla provides the perfect balance of freedom and structure, which is the main reason I'm so happy to be a Mozillian.

    Q How has Mozilla's mission and altruistic nature affected the way that you look at software and contributions to the community?

    Mozilla's support of open source and going the extra mile to improve the web have changed my thoughts on OSS development immensely. My colleagues are an inspiration and that energy is infectious. Most of my colleagues have popular open source projects and are happy to jump in and help when needed. A majority of Mozilla websites and back-end apps are hosted on GitHub, even sites like the Firefox Marketplace and Mozilla Developer Network, so basically everything is available to the community. When I got to Mozilla, I was surprised at how many contributors there were to the Mozilla family of websites. I loved the Open Source community and my experience has taken that love to the next level; I cannot imagine working on proprietary programming ever again.

    Q You had a recent addition (congrats!). How have your work/life balance considerations changed now that you're a new dad?

    Having a child puts life in perspective. Most nights over the past five years I would get done with work and then spend the rest of the night on my computer writing blog posts. I got a lot out of doing that, but I would frequently get burnt out. With Jack around, I'm happy to not spend so much free time on the computer, and instead opt to take him on walks, take him to visit his grandparents, and generally just get out of the house. Seeing your kid smile makes you realize there's more out there than loop optimization and dealing with negative tweets.

    Q How do you detach from work considering that you're a remote employee?

    Working from home is sweet; I get to save money on gas and food, take a walk when I get frustrated, avoid distractions from coworkers, set my own work schedule, etc. The biggest drawback is working too much, which is something I've been guilty of for years now. Just like moderating anything else, however, you need to get into a routine and cut yourself off at a given time. You should also cut yourself off when you feel the icy glare of your spouse… :)

    Q Do you see yourself pushing your son into programming? Why or why not?

    Let’s be honest, we have a pretty good gig.

    If he has interest in development as he grows up, I certainly won't push him away from that career path. Let’s be honest, we have a pretty good gig. We can (sometimes) work from home, make good pay/benefits, travel around the world, make extra money consulting from home, and generally won't have a problem finding a job. Tech jobs come with all of those benefits.

    Of course programming comes with its drawbacks. There's a lot of negativity in the JS community, remote collaboration can be a nightmare in some situations, and clients oftentimes don't understand the work that goes into creating a solid site/app, so justifying price becomes difficult.

    In the end, if it's what he wants, I'm happy to help him along the way.

    Q You've managed to successfully monetize your blog. Are there any secrets or tips you'd care to share for those looking to do the same?

    My advice is two-fold. First, choose sponsors which are good matches for the main topics of your blog. Second, don't overdo ad placement, remember that ease of consumption is still the most important thing. Writers should also avoid animated GIF ads, text link ads, and auto-playing videos. As your site continues to be usable and you put up content regularly, the income will arrive.

    Q Some people discourage bloggers from posting advertising. How do you rationalize placing ads on your site and how do you determine if a specific ad campaign is something your readers would even want?

    I get incredibly annoyed with people who assert that a blog shouldn't have advertisements and for so many reasons that I could go on for hours, but a few brief points are:

    • Criticizing someone else for how they make their money (assuming it's legal) is a really embarrassing thing to do.
    • Developers that spend hours writing tutorials, providing bug solutions, and providing code inspiration should be rewarded in some way, it's essentially another job.
    • The alternative is not blogging and instead doing freelance work, which helps only the client. Blogging ideas and solutions helps thousands of people and at no direct cost to them.
    • If I were to ask my wife and newborn what they thought about "@somedude on Twitter in godknowswhere" criticizing me for having ads, they'd laugh. They want to be financially supported, they don't care what a stranger thinks about it.
    • Too many people confuse open source with "free"; i.e. the code is free, everything else should be free. That's way off base.

    Picking a campaign is usually the easy part. You accept adverts from businesses you've used, believe in, and are reputable. Stick to those rules and you're bound to do OK.

    In the end I don't understand people who feel the need to comment on how others make a living; it's petty, rude, and again, embarrassing.

    Q You recently added forums to your website. Forums management takes a lot of work. Why would you take that on when there are so many established support forums available?

    I created a forum section for a few reasons. The first reason is that since the official MooTools-hosted forums were taken down, and the "unofficial hosted forums" were taken down, there's been no central place for MooTools users to get support. I also want to establish a more community feel to my site. Lastly, I get probably a dozen emails per day asking for help with a jQuery snippet, PHP problem, or follow up to a specific blog post. I'd much prefer those questions be posted to the forums so that (1) another user can help out if I can't and (2) I can avoid receiving and sending the same emails. It seems like a win-win all around.

    In Closing

    Thank you David, for participating in this interview. We really appreciate it.

    To connect with and learn more about David, be sure to check out his website.

    May 27 2013


    Learning by Pulling Apart: An Interview with UI/UX Designer Matt Dempsey

    Every once in awhile, we come across an amazing story of someone in the design world who seems somewhat hidden or insignificant. Matt Dempsey is such a someone. His career as a web and graphic designer begins at the very young age of 13 and includes such inspirational highlights as hiring a developer to build an app that was acquired by SitePoint when Matt was only 15 years old!

    March 12 2013


    Everywhere All at Once: An Interview with Sara Wachter-Boettcher

    Print design is not web design. This we know. And a design that works well for the web may not translate to mobile and handheld devices. True, true. But is there a way to ensure that content – the “stuff” around which design orbits, after all – can be communicated effectively regardless of the medium in which it’s presented? This isn’t a problem limited to visual designers; it affects the entire organization. Sara Wachter-Boettcher’s new book, Content Everywhere charts a path away from the web’s previously popular, one-size-fits-all approach.

    The motto guiding NPR’s API is abbreviated COPE: “create once, publish everywhere.”

    Now, there’s an idea. Wouldn’t it be nice to publish everywhere, rather than once for desktop, once for mobile? Once for this app, once for that one? Robust content frameworks such as COPE challenge the rather simplistic notion that designers can create templates beforehand, into which content is added after. They come from a place where content strategists, information architects, and visual designers – the entire organization, really – work together in preparation for publication; where content is viewed as a system, rather than a two-dimensional “deliverable.”

    Sara’s philosophy frees content from its container.

    And the book bringing this idea to a broader audience? Content Everywhere by Sara Wachter-Boettcher. We jumped at the chance to read it and, afterward, implored her for an interview to better understand her perspective. What, exactly, is the ethos guiding this movement? And how does she see it affecting content strategy as a profession?

    We don’t blame you if you’re just as fired up as we are. And if you haven’t had a chance to read the book just yet, don’t worry: we’ve got details on how you might win a copy after. Enjoy!

    Hey Sara, thanks for taking the time to chat! What inspired you to document your understanding as a book? Are there other mediums you’ll use to share Content Everywhere, well, everywhere?
    It all started in the summer of 2011. I’d long been thinking of the content I worked on as a system, not just a series of pages. I was pretty involved in decisions around content structure and architecture simply because I wanted the content to work – to be more usable and easier to find. I’d never formalized any of that thinking, though, or really even considered that it might be something other content strategists weren’t doing.

    Then Ethan Marcotte’s book came out and I realized the time was right. Responsive design makes it nearly impossible not to deal with content in a substantial, deep-dive sort of way. So I wrote some blog posts and started to talk about this stuff when I was subsequently approached about writing a book.

    Of course, I’ve given conference talks and workshops about this idea (I try to keep my Lanyrd up-to-date); I’ve written articles where I can. But one of the most important ways I spread this thinking is simply by bringing this ethos – that content is a system, and that we have to change not just templates but our practices—to everything I do. It’s changed how I tackle projects, talk to and educate clients, and collaborate with project teams.

    So how would you say this notion intersects with other user experience design concerns: findability, accessibility, aesthetics, etc.?
    Clear, purposeful content is also well defined, structured, and organized. This benefits everyone. Metadata and content chunks make content easier to find because they enable things like faceted search and also give you better deep linking – not to mention more ways that you can jigger your internal site search engine to give more relevant results. Clear labeling of content – according to what it is, rather than big blobs of text – tends to aid accessibility as well.
    In order to “chunk” content you’ve proposed content modelling, a process frequently employed by information architects. As content strategists take on tasks such as content modeling, where do you see the line between IA and Content Strategy?
    I don’t. That’s not to say that they’re the same discipline – or that they’re interchangeable – but content strategists and information architects have many shared concerns and practices, and I don’t see a problem with that. In fact, we should share concerns. You can’t have too many people on a project who care about content. You just have to be willing to cede control over some of the things you could do, but the other person might be better equipped for – and vice-versa.

    I’d also like to point out that information architects adopted content models from database developers in the first place. It’s not like any one discipline has a lock on them. In fact, precious few IAs – or content strategists, for the matter – are currently using them, and that’s a shame, because they’re really a great, cross-disciplinary tool. I suspect it’s because we’ve placed a lot of priority in recent years on interaction design (IxD) rather than IA. IxD is an important discipline, to be sure, but lovely UI patterns alone won’t solve the problems so many sites have: content that’s buried, lost, disconnected, and generally difficult for users to find and use.

    Many of the things for which you advocate – metadata, for example – feel poorly handled by today’s basic, off-the-shelf Content Management System (CMS) software (such as WordPress). Do you believe that architecting and maintaining a robust system of content necessitates that companies build their own CMS from the ground up?
    I specifically don’t advocate for any one technical solution in the book, because I don’t think you can make decisions about how to store and publish content until after you’ve figured out (1) what you’re doing, (2) why you’re doing it, and (3) what sort of content structure and systems you’ll need to support that. Well, that and the fact that I’m not a CMS expert.

    WordPress works great for lots of small businesses, and it works fine for my oft-neglected little blog. Many startups operate with no CMS, but they also often have tremendous engineering resources at their disposal and don’t really publish that frequently. It works for them to hard-code copy changes. But for the sorts of organizations and content challenges I’m talking about – in industries like media, higher education, nonprofit, and government – a CMS is pretty critical.

    Some organizations do well with completely custom CMSes. NPR, for example. They’ve built lots of structure into their CMS interfaces, so their content can easily make its way into the NPR API. They’ve also invested in their CMS’s interface, so writers and editors can focus on their job rather than getting an overwhelming desire to walk out into traffic every time they log in.

    But you can get structured, reusable content out of many, many existing CMSes – from open-source options like Drupal to enterprise-style products like Sitecore and Vignette. Their features and benefits (and drawbacks) vary, but they’re all capable of being configured to support many things for which I advocate: metadata, content modules, and the like.

    The problem is that, quite often, CMS purchasing and configuration decisions are made by an IT person with a checklist rather than someone with deep knowledge of the content being managed. The content crowd is oftentimes too daunted by the technical bits to try to poke their nose into the conversation.

    What I want is for content people to see that CMS decisions affect the success of their work, and to get comfortable enough with the vocabulary that they can be an advocate for users, and for the content itself, when CMS decisions are made. We could talk all day about the flaws with the CMSes that exist on the market: crummy code, bad text editors, broken user interfaces, baffling configurations. But they’re not going to get better unless people like us understand enough to know what to ask for.

    So what advice would you offer designers, writers, architects – or even developers – who want to make content strategy part of their wheelhouse?
    Content strategy, at its best, is more than the high-level goals and messages or the copy on a few key pages; it’s being able to design and work with your content as an interdependent system of assets, and about keeping that system of assets functional even as the site grows and changes. This means understanding both the big picture and all the little details that might stand in the way.

    For writers or editors interested in doing more strategic work, this often means pulling off the blinders and looking at a broader scope. For example, you might be used to assessing the narrative within a single story, adjusting structure and pacing to make it work. In content strategy it’s the same skill, but you’ve got to apply it a plane or two higher: how does this individual piece affect the narrative of the broader content system, and where does it fit? Is every piece of content serving a purpose, or are some things just filling up space?

    For people who come from design, UX, or development, there’s often the opposite gap to fill. While you might be used to thinking about systems, you might not be used to getting really, really close to the content that will go into that system – or considering how that content might change the way you design the system in the first place.

    Wherever you come from, getting strategic about content demands that you can do both – even if you’re always going to be stronger in one side than the other.

    Final question! With so many noteworthy books coming out recently, it’s almost impossible not to wonder: what’s next? What do you think is the next big thing for content strategy?
    The more we tackle content, the more we realize just how many of our problems start not on the website or even in the CMS, but in the very way our organizations are structured.

    So many people imagine content as living in “their” sections and belonging to “their” department, rather than thinking of it as a system of information another human (who almost certainly does not give a damn about said department) has to find their way through. And it’s hard to blame them. If your job description has always been tied to checking “content tasks” off a list, then that’s how you’ll see your role. We have to show people at all levels of an organization, C-level on downward, that they need to think of the web as more of an organism than a repository.

    The problem of silos isn’t new – it’s been coming since the internet started fundamentally changing both the way people live and what they expect from organizations. But the problem of disconnected companies is now impossible to ignore, because it’s being exposed, often painfully, by mobile and multichannel. If we want our content strategy work to be sustainable – to last once daily operations take over – then we’re going to have to keep unsnarling these messy organizational issues. There’s no other way.

    Closing thoughts

    Many thanks, again, to Sara for sharing her strategies with us. If you have a question that wasn’t answered above, please ask it in the comments below – we’ll do our best to make sure Sara sees it!

    Want to get bust some silos and create great content for your company? Head on over to and purchase Sara’s book with discount code UXBOOTH.

    But if “free” sounds better to you, you’re in luck. We’ve got five books to give away courtesy of the fine folks over at Rosenfeld Media. To enter for a chance to win, simply follow @uxbooth on twitter and leave a comment below. Be sure to include your twitter handle and tell us a brief story about the content strategy (or lack thereof) at your current organization. What problems have you solved? What problems might Sara’s book help you solve? We’ll randomly draw five members in the next week, and contact you over Twitter. Good luck!

    About the Author

    Sara Wachter-Boettcher

    Sara Wachter-Boettcher is an independent content strategist, writer, editor, and the author of Content Everywhere from Rosenfeld Media. When she’s not helping clients embrace flexible, mobile-ready content, she’s serving as the editor in chief of A List Apart; contributing to the Pastry Box Project; and speaking at conferences worldwide. You can reach her at

    The post Everywhere All at Once: An Interview with Sara Wachter-Boettcher appeared first on UX Booth.

    November 01 2012


    An Interview with Designer and Developer Benjamin De Cock

    Benjamin de Cock is a freelance designer who works out of his home office in Belgium. His focuses are interface and icon design, and he’s 28 years old. Benjamin spends most of his time designing Stripe and Kickoff. We caught up with Ben to talk to him about his design practices and approach.

    What software/hardware do you use daily?

    I exclusively use Adobe Fireworks CS6 as my design tool. I look more and more at Sketch 2 which is very promising but still a bit young to make the complete switch in my humble opinion. When I design for iOS, I also use quite a lot of LiveView and — surprisingly — iPhoto to quickly import screenshots to the Mac through Photo Stream.


    I’m not doing a lot of front-end development anymore but when I do, I still use the dying TextMate. I gave Coda 2 a quick try but I felt it wasn’t the right tool for me as I’m usually looking for extremely light text editors. I’ve heard great things about Sublime Text and Chocolat but since I lost some interest in coding, I must admit I haven’t found the motivation to properly try those apps yet.

    As for the hardware part, I work on a MacBook Air 11″ (always closed) connected to a Thunderbolt Display 27″. I should probably mention my iPad too as I work quite a lot on it. For example, I do most of the email stuff there and I truly enjoy the experience. Many people find it difficult to type on the iPad but it’s not the case for me. Editing text still feels complicated to me (I hope Apple’s working on improving the loupe or an alternative to it) but typing works just fine with me. I wouldn’t say I’m as fast as I’m on a real keyboard but I’m honestly close to it and I love the feeling of my fingers on the glass. :)

    Where do you get your inspiration from?

    It may sound cliché but I look at everything Apple makes, from their website (the iPad’s feature page is still amazing) to their device boxes. I honestly still haven’t found another company where the attention to every detail feels so important. I guess I should also mention Dribbble. While I have mixed feelings about it (showing some graphics out of context rarely makes sense), it’s still a great resource if you want to get inspiration on execution.


    What triggered your passion of design and development?

    Showing things to people and see those people actually using your creations has always been fascinating to me. Designing something exclusively for me wouldn’t be motivating at all. With the web, I have this amazing opportunity to easily share my work with so many people around the world so it was a no-brainer.

    As for the development part of the process, I must clarify I’m not a developer at all. I’m very comfortable with HTML and CSS (which is definitely not what I call “development”) and I also do some JavaScript but that’s everything I know. I always wanted to understand how things technically work but I’m not really interested in implementation details. It also feels important to me to be able to prototype some of my UI ideas to see if they can actually work. I think every software designer should have at least some notion of the technical side of the apps they’re designing.

    What’s a typical day look like for you?

    I usually start the day around 9am by answering the important emails on my iPad and checking some RSS feeds and tweets before moving to my office. I try to then focus exclusively on designing things, hiding all kinds of notifications that could disturb me. I repeat the same scenario after lunch and I usually leave my office around 6pm to take care of my son.


    What would you recommend to anyone wanting to get started in the world of design?

    I’m a huge believer in practice. Trying to replicate existing graphics is a good way to start learning your design software and to see how the original designer made all the details. Learning to make many iterations of the same mockup is very important too. We, as designers, are often too connected with the graphics we create. Trial and error is a frustrating but essential workflow to reach something really good. Experience is king.

    Thanks a lot for your time – keep up the great work!

    Thanks for having me Daniel!

    September 04 2012


    All of Us are Students: Interview With Designer and Podcaster Tim Smith


    For years Tim Smith has been vocal part of the design community. From the various projects and blogs that he has been a part of, to the even more literal interpretation of him being a part of the community as the voice behind the design and development related podcast, The East Wing. His enthusiasm and insights make him a valuable asset to the community, but beyond that, they make him an inspiration to all of those in this ever evolving field of web design.

    We had the opportunity recently to turn the tables on Tim, and put him on the other side of the interview. He was gracious enough to take time out of his busy schedule to provide some of his insights for noupe’s readers. Below are the answers he shared.

    Interview With Tim

    Thanks again for agreeing and taking the time to answer these questions. So Tim, if you don’t mind, take a moment and introduce yourself.

    Thank you! It’s a huge honor! My name is Tim Smith and I’m a Designer, Talker and Coffee Addict. I also run a small podcast called The East Wing, a podcast that talks about design with some very smart people.

    Who are some of your biggest influences in web design?

    This is always a tough question for me. I have a lot. I’d say anyone I’ve had or will have on The East Wing. Carl Smith, Jason Van Lue, Tim Van Damme, Janna Hagan, Aarron Walter and the list goes on. The way they think inspires me. They help me approach projects and design from a new angle, keep focus on the details and always remember that I design for people and that their experience with what I’m designing is of utmost importance.

    You’ve been working in design and part of the online community for several years now, in your opinion, what have been the best developments and worst developments in the field since you first dove in?

    I think for the most part, they’ve been great developments. I’m glad to see that design isn’t being seeing as decoration and that we as designers have been urged to recognize problems, assess personal and business goals and create designs that meet these goals. This has brought on new ways of thinking like responsive web design, designing for mobile and injecting emotion into designs. All of these developments come from knowing that our job extends far beyond making things beautiful. We want to make websites that are functional, accessible and alive. As we move forward, I’ve been doing a lot of thinking around constructive criticism and critique. In fact, I talked with Aaron Irrizary and Adam Connor about this on The East Wing.

    Given your proclivity for radio, The East Wing is something of a natural step for you. How did the show come about?

    Well, a podcast is something I had been trying to start. I had two failed attempts to start one and now that I look back, I’m glad it worked out the way it did. It gave me time to think about a solid idea. The show was the result of me wanting to educate myself more. I realized that there are so many smart people doing some amazing things in our field and I wanted to talk to them. My point was never to establish myself as an expert, but more as a student. I love the opportunity to pick the brains of these people and it makes me very happy to see that there are people who enjoy the show and listen to it every week. I’m very grateful to the listeners.

    How do you approach beginning a new podcast? Does the idea for each show stem from the guests you have on it, or do the guests you have on stem from the idea you wish to cover for each episode?

    It depends. Sometimes, I want to cover a particular topic so I contact a person who I know is well versed in it. Other times, I like someone and have been following their work and would like to know more about them and how they do what they do. For the most part, I only get the guest talking. It’s all them for there. Everybody is passionate about something, the art is finding the string so as to pull it.

    With so many steps to the design process, what would you consider the most important? Why?

    That’s a tough one. My gut feeling is to say each one and that would be true. You can’t do a good job by skipping steps. I do believe that a part of the process that get’s neglected is user experience. Unfortunately, some designers have the mentality that it’s not their job, but that of the “UX Designer”. I say that’s false. Wireframing, user testing, information architecture and more are all things a designer should be involved and actively participating in. This stage of the process is crucial and drastically affects the success of the project. I wrote an article about the importance of wireframing( actually.

    What do you think that the design field’s biggest strength is? What does the field really have going for it?

    Community. Although as in every place, there are jerks, I have never met such a friendly and willing to help group of people. I would’ve learned so many things the hard way if it hadn’t been for the openness of a lot of designers and developers. Not to mention, when I first started The East Wing, the guests were really nice and didn’t hesitate in coming on. I hadn’t published my first episode and I already had 7 guests lined up.

    In that same respect, what do you think that the field’s biggest drawback or weakness is?

    I think it’s constructive criticism. We have to get better at this. It’s usually one of two things. 1) Everybody loves something. 2) Everybody hates it. This helps no one. “Good job”, “Awesome” and similar things don’t really help people get better. Neither do statements like “Wow, this is ugly”. I think we should be helping each other with solid critique without ridiculing anyone. We make our community stronger and it helps us all put out amazing work.

    You work on a project that promises to teach Drupal to users, which is a slight change with WP monopolizing so much of the market. What would you say are some of the draws to Drupal that the average user/designer overlooks?

    Well, it’s a different type of problem. At Lullabot, where I used to work, we were solving complex editorial problems for huge companies that had a staff of writers, editors, managers and Editor-in-Chief. Drupal does extremely well with handling a variety of types of content and contrary to popular belief, scales very well. Lullabot has been doing the Grammy website for four years now and not once has it been down on event night. The way I see it, WordPress and Drupal are just tools. It’s a matter of deciding what’s the appropriate solution for a project.

    People talk all the time about how ‘we learn something everyday’. What have you learned recently that has impacted your workflow or usual methodologies?

    Fireworks and “box-sizing: border-box;”. They’ve changed everything for me recently. I use Fireworks to create wireframes which is a helpful tip from my pal, Jared Ponchot. It’s really fast and doesn’t make your wireframes ugly like OmniGraffle. The other tip has been really useful. I hated having to calculate the padding into the final width/height of a box. I hate math in general. That’s been a huge time saver.

    Speaking of learning, what is the one thing you wish someone had told you before you got into the design game?

    First off, I’d like to say I wish there was the Student’s Guide to Web Design when I was a student. I would also say that my recommendation is to be honest about who you are and where you’re at in your career. There is no shame in saying you’re a student or that you’re just starting out. All of us are students. If we don’t constantly have a hunger to learn, the web is going to leave us behind. Talk to people. If you like this interview, talk to me. I’d be more than happy to help out with questions or problems.

    After watching the web design field evolve over the years, what do you expect to see in the future of the web?

    I’m excited to see more and more an acceptance of mobile. Not from our side but, from the client side. We’re all on board but I look forward to seeing more and more people out of our circle embracing it and investing in better solutions that span different screen widths and devices. It’s a huge learning process, we’re all learning on how to organize and display the many different types of content appropriately.

    Speaking of the future, what can we expect to see from you in the future?

    That’s a good question. I want to see myself grow more as a designer. Hopefully be of more help to others by means of my podcast and my writing and also do some speaking. If you haven’t noticed, I love to talk so I’d welcome that opportunity. Other than that, time will tell.

    All For Now

    That closes this interview with Tim Smith, but you can get more from him and the design community through his blogs Timothy B Smith, Time Likes to Write, and the podcast The East Wing. Share your thoughts on the collected insights shared throughout this interview in the comment section below.


    April 26 2012


    Joost de Valk, Founder of Yoast, Shares His Success Story

    This is the link to the original article creator of this site, if this message appears to another site than 1stwebdesigner - Graphic and Web Design Blog - 1stwebdesigner is a design blog dedicated to bloggers, freelancers, web-developers and designers. Topics focus on web design and inspirational articles. it has been stolen, please visit original source then!

    Joost de Valk is the founder and CEO of He’s one of the top SEO and WordPress experts in the world, best known for his great WordPress plug-ins.  Joost also runs a WordPress Podcast and speaks at a variety of conferences.

    Joost, please introduce yourself to our readers.

    I’m Joost de Valk, founder and CEO of I’m also a 30 year old husband and father of 3 kids (2 boys, 1 girl) from a small town called Wijchen in the Netherlands.


    What is your background in web development?

    My background is kind of “funny”, I built my first website in ’94, 12 years old at the time, on a computer my parents lent me the money for because I’d broken theirs one time too many. I played around with small websites for quite a while but never really built anything substantial in that time.

    Professionally my career started in 2002 as a Java developer, as I like to call it, even though I was mostly coding JSP and JSTL at that time and wouldn’t have been able to write any “real” Java code. My official job title wasn’t developer though; I was an account manager and was mostly working on translating the needs of clients into something the developers could make technical designs for. From this job I went to another sales job, but in that sales job a small miracle happened: they “forced” me, although it didn’t take much forcing at all after my first day, to work on a Mac.

    Out of interest for HTML and CSS, I became active in the WebKit community, eventually becoming a committer on the WebKit team, a “title” I still hold, mostly because I built hundreds of automated test cases and maintained their Bugzilla. Through all my work in reducing bugs (a process where you take a webpage that causes an issue and start taking away everything until you have the smallest possible test case), I learned an awful lot about HTML and CSS. One of the things I specialized in was CSS3, which I was and am a huge fan of, causing me to write so called “CSS3 Previews”. I published those on my then domain and hit many a Digg front page with those, back when Digg still had traffic to give.

    That section on my site became so popular I decided to spin it off into its own domain, (which I have since sold), the first domain for which I really seriously started using WordPress. That’s when I had my “rebirth” if you will as a developer: I started developing WordPress plugins to do things I wanted to do on, beginning with robots meta, which still exists but is also at the core of my WordPress SEO plugin.

    What is your background in SEO?

    Time would teach me that while I like talking to people and don’t mind selling them stuff at all, I’m not a born salesman. I’m somewhat of an in-between between developer and marketing man, and in my next job I would become an SEO, which I would describe as exactly that. I was taught at Onetomarket in both some of their old blackhat ways (they’d been banned from Google the year before and knew exactly why) and their new methods. While we didn’t use the old methods for clients, I found, and still find this true today, that if you follow what blackhats do you can learn an awful lot about the behavior and choices of search engines.

    WordPress plug-ins

    Why do you focus so much on WordPress?

    Because I love using it and love the community around it. It’s great to be able to build something and help so many people. Of course that wasn’t always true, in the beginning I “just” did it because it was the most user-friendly way to power my websites. Now it’s a part of my business and I dare even say, a part of who I am online.

    How did you come up with an idea to create WordPress plug-ins?

    I scratch my own itches. WordPress doesn’t do something I want it to do? I’ll make it do it. 95% of my plugins have been built because of that, the other 5% were paid projects for clients.

    How do you find needs in the market that you can fill with your WordPress plug-ins?

    I don’t think I find needs, those needs find me. It turns out that my itches aren’t that weird, more people need the same functionality, so I build that functionality and release it to the public. In some cases I have probably “created” my own market a bit; in my article on WordPress SEO I have proposed strategies that people adopted, for which they needed my plugins.

    What is your process of creating a plug-in?

    It starts with a piece of code I built for myself, not too much stuff around it, just my own needs, from there on some plugins evolve into plugins I release. At that point I usually need to add an admin interface etc., which is usually far more work than building the plugin itself. That’s followed by the even more cumbersome creation of documentation, the thing in which all of my plugins “lack” the most.

    How do you market your plug-ins?

    By now, a blog post about them is usually enough to get people interested. When I first started it took a lot more work but I still go through somewhat of the same process today as I did back then: I email a few friends in the industry, leave a comment on blog posts that are topically related, basically, I make myself known to my audience, usually fellow marketers, who will then spread the word.

    Why do you think your plug-ins are so popular? What is your secret?

    Quality and doing what’s promised on the “tin”. Instead of calling one of my plugins an all-in-one plugin and doing only half of what’s needed, when I call my WordPress SEO plugin all-in-one it’s because it’s truly all you need for your WordPress sites’ SEO. When I call a plugin “Google Analytics for WordPress”, it does just that: add Google Analytics to WordPress. With, admittedly, a whole lot of options that you can choose to use but you don’t have to use.


    What got you interested in SEO?

    I was looking for a new job, clearly unhappy and not functioning very well in my position at the time, when my wife showed me this job for an SEO. I’d played around with search engines a bit, knew my way around all the HTML and CSS standards so I got hired. To be honest, until my wife showed me that job opening, I’d never considered becoming an SEO. I’ll be eternally grateful to her for showing it to me (and for marrying me and bearing my children, but that’s another thing altogether).

    How did you learn what you know about SEO?

    In several ways: I learned at my then employer, Onetomarket, but mostly, I learned by reading SEO blogs and forums and testing whether what they said about SEO was true. SEO is very much something you have to learn by doing and by deep diving: open up server logs and look for the movements of Googlebot around your site. Try to understand it, try to think as a search engineer. Once you start “getting” that, it’s the most fantastic job in the world.

    How did you get from an interest in SEO to being a world-renowned SEO expert?

    I built stuff, then I told people… I was in the lucky position that some of the people I told about what I built were very responsive. My first conference was a small conference called SEO Days by Dave Naylor. During that conference Dave took me aside for a while and we had a great chat, after which he connected me with friends of his, people like Chris Sherman and Danny Sullivan who got me speaking gigs on their SES and later SMX conferences and guys like Matt Cutts of Google and Greg Boser of now BlueGlass.

    Just a few days before I went to that conference I filled out a long survey on SEO ranking factors Rand Fishkin of SEOmoz had emailed me, which later became one of the biggest pieces of SEO research of that year.

    Combined, all these people seemed to like what I did, and still do, so I did more of it and more people responded, from there on it was just a big upwards spiral.


    Your personal brand is unique because it’s a fusion of web development and SEO with a sprinkle of content marketing. How did you come up with an idea to combine all these things?

    I’d love to tell you I planned this from the get go, but that would be nonsense. It just “happened” and when I saw it happen, I took the chance and built it out. Only recently have I become more eloquent about my university background (I studied Theology and International Business, though I finished neither degrees), because I think mostly what I learned in Theology applies to so much of what we do today.

    Content marketing, “story telling”, etc. All that is just the old art of evangelization in a new package. Evangelization, coming from Greek, means nothing more than “spreading the good message”, that’s what companies ought to be doing with their products, governments with their policies and heck, developers with their programs and plugins.

    How did you go about actually blending it all together? What were the biggest lessons learned there?

    I didn’t really blend it myself. I just wrote about what I did and at some point it became clear to me I was “WordPress SEO guy” to a lot of people and they were looking to me for advice and plugins in that area. The funny thing is that in my work as a consultant, I’m far more a “Large Site SEO” guy and a “News SEO” than a “WordPress SEO” guy, as most of my consultancy clients are companies with enormous websites and the issues that arise from that, but my “public” image is now completely affixed to WordPress in the first place and SEO as a close second.

    Many people want to become world-class experts, but only few do. How did you get to where you are now? How did you grow your brand and your business?

    To become a “world-class” expert you have to be humble in admitting what you don’t know, as well as nimble in making sure you get to know that what you don’t know but need to know as soon as possible. As soon as you’ve acquired knowledge worth sharing you then need to start giving away that knowledge through a blog, articles in magazines and speeches on conferences.

    It’s not something that happens overnight. I’ve been doing this for 8 years now, growing a following in the process. So it takes hard work, dedication and you need to forego monetary reimbursement for quite a while. I would never have been where I am now if I’d decided to sell my plugins early on, or if I’d kept my WordPress SEO knowledge to myself.

    Final words

    Last, but not least, what would be your advice to someone who would like to combine his or her strengths and build a strong personal brand and a successful business on them? What’s the most important thing there?

    The single most important thing is to do what you love. I know no-one in our industry who has become a thought leader, a world-class expert or a “guru” by doing something other than what they love. The reason for that is simple: love for what you do will make your work not feel like work; allowing you to put the necessary (often ridiculous) amount of hours in to gain the knowledge and the profile you need.

    Thank you, Joost! 

    April 25 2012


    Milton Glaser on Donald Trump

    A question recently posed to Milton Glaser was, “What do you think of Donald Trump?”

    “Well I’ve met him — I’ve even done a vodka bottle for him as a matter of fact. I don’t know how to think about him. He’s an example of the power of the ego. How can anyone be so totally egocentric to not understand that there are others in the universe. It also shows the power of that position: When you don’t think there are others, everything is attainable for you. I just find that the combination of incredible ambition and a lack of modesty can be a terrifying prospect. And if you’re in a roomful of people like that, you realize that that’s why the world is the way it is.

    Trump Vodka
    The Milton Glaser label design for Trump Vodka, bottle by Bruni Glass

    “And the other thing is: I can’t figure out his hair. From the point of view of someone who is into art and form-making, I can’t figure out the structure of it: where it’s coming and where it’s going. And then I also wonder, what does he think this object on his head achieves? It’s just a great mystery.”

    Catch the rest of the interview on New York Magazine. The same questions are asked to other New Yorkers in the magazine’s 21 questions series.

    From the archives: Milton Glaser on design studios.

    Published on David Airey, graphic designer (catch me on Twitter)

    Logo Design Love, the book

    Related posts on David Airey dot com

    March 29 2012


    How Ruben Gamez Turned Bidsketch Into A Successful Online Business

    Ruben Gamez is the solo founder of Bidsketch , an online proposal software website for web designers.  In only a year and a half, he managed to take Bidsketch from  a humble side project that he started while having a full-time job to a full-time business that allowed him to quit his job and enjoy the freedom he has always desired. How did he do that? Today, Ruben shares his story with 1WD readers.

    1. Ruben, maybe you could start by telling us more about Bidsketch? What it’s about and how does it help designers?

    Creating proposals are one of the most effective but painful things designers have to do. In fact, even though it’s one of the best ways to get clients, some designers will skip this step because it can take so much time. I created Bidsketch to be the fastest (and easiest) way to create professional looking proposals. The reason it exists is to cut down on the time it takes to create a proposal.

    “I assume that in order to build something like that, you have to know a lot about web design and freelancing. What is your professional background? What were you doing before Bidsketch took off?”

    Years ago I was a freelance web designer and became pretty good at building relationships and getting referrals to get work. I eventually got a job managing the web development department for a company because I grew tired of always having to find new client work.

    Managing the web development department I was often in charge of hiring outside design agencies so I was exposed to a lot of different proposals from the client’s perspective. It was a great learning experience since I was able to see how companies decide to hire a design company and what sort of proposals were the most effective.

    “Did you plan to turn Bidsketch into a successful business from the very beginning, or was it a side project turned into an unexpected success?”

    Bidsketch started as a side project so I didn’t expect that it would grown into something that I’d be doing full-time. In a year and a half it had grown to the point where I was able to quit my job. I had modest goals so this was a complete surprise to me but I’m very grateful for how things turned out.

    “How did you come up with an idea for a Bidsketch? Why did you think people will be interested in something like that?”

    I started thinking about building Bidsketch when a friend of mine came to me for advice about how to deal with proposal request from a client. I explained what I knew about it and tried to find him a template online and found a really old-school downloadable app that helped people create proposals. I tried it out and it was pretty bad and not something that would appeal to a designer (since it was meant for corporate sales teams).

    After that I checked the Google Keyword Tool which tells you how many people are searching for a specific term and found that it was something designers needed.

    I knew people would be interested in something that would cut down on the time to create really nice looking proposals because it was something that I had wanted when I was a freelancer. It was also something I had heard many people complain about in the past so when I also saw that people were searching for a solution I thought a product made perfect sense.

    “You had a good job in a place where you worked for nine years. Why did you decide to engage in entrepreneurial pursuits? Why build a business when you already have stable income from a decent job?”

    I had a job that gave me a paycheck but I was no longer doing what I enjoyed doing. Over the years I had been promoted to where I was a senior manager. I took the promotions because they meant more money which many people do. Unfortunately, more money meant more responsibility. I had no longer had freedom or flexibility which is really what’s most important to me (much more than money is).

    “You had to invest a lot of time, energy and money into Bidsketch long before you were able to see the returns. What made you feel confident that you will be able to pull this off? Did you have doubts and if so, how did you deal with them?”

    I had many doubts throughout the entire process. Even now that it’s a relatively successful product there can be days where I have doubts. I think most people that have a business feel like this from time to time but rarely talk about it.

    I’ve found that talking to people that understand what it takes to build and run a business helps. Early on, I almost gave up on the idea because I was having trouble getting feedback from people on web design forums. Luckily I emailed a friend who gave me some great advice and convinced me that I should keep going.

    “You built a business while working in a proper day job. How on Earth did you find enough time and energy to do that? Do you have any advise for people who would like to build a side business while keeping their day job?”

    It wasn’t easy that’s for sure. I basically worked from 8pm to 12am most nights and worked every weekend for a few months. The problem was that I was trying to do too many things by myself; I was doing the design, programming, marketing, and blogging, which was exhausting.

    Eventually I decided to get help and start over by outsourcing parts of the product. I didn’t have a lot of money so I couldn’t outsource everything, but the with that approach I was able to move much faster which was super motivating.

    So my advice to people that are doing something on the side while working full time is to get some help. You don’t need a lot of money and you don’t need to be some expert in outsourcing. Anyone can visit a site like oDesk and post a project to get some help.

    “You managed to quit your job eventually when Bidsketch took off. How did you know when was the right time to do it? What would you advise people who are running side businesses in regards to quitting their day jobs?”

    I lowered my expenses as much as I could before I quit by doing things like selling my car and getting rid of several monthly expenses. I talked to my wife to make sure she was comfortable with the idea. And once I had enough to cover our living expenses I decided to quit the job. I felt comfortable doing so because every month I saw revenue growth.

    I think that people often say they’d like to quit their job but often don’t do the things necessary to make that happen. First, you have to take action. Launch a product, it doesn’t have to be something big, just start making money on the side. Also, I think it’s important to think about ways to lower expenses and cut the major expenses (think about car payment instead of eliminating your daily latte).

    “As much as most people hate their jobs, they do provide a sense of financial security, since you know that the paycheck will come at a certain time of a month. Wasn’t it scary for you to say goodbye to this?”

    For me it wasn’t scary because I had was already earning money on the side and it kept increasing every month. So while there are no guarantees, earning money from a product where people are getting real value is much more secure than having a job in my opinion. With a job, you have one paycheck and many people in the company can decide you’re not needed for any number of reasons. If you think about it, it’s a pretty risky situation.

    “Was the transition from the world of traditional employment to the world of entrepreneurship difficult? What are the key differences in mindset of a successful employee and a successful entrepreneur? What habits should employees who want to become entrepreneurs drop and what habits should they adopt?”

    My transition was mostly easy since I was mentally ready for the change. Working on a product and earning money on the side before quitting the job let me get used to the differences slowly.

    One of the key differences in mindset have to do with time management I think. When you work for someone you’ll get paid no matter what you’re doing. When you’re working for yourself, spending 2 hours fixing some HTML bug in IE is probably not the best use of your time. There are many tasks that need to get done but it’s important to think about which are the important ones that can only be done by you, and which ones are worth spending a few bucks to have someone else do them.

    If money is tight you’ll have to do more things yourself, but that’s the perfect time to start eliminating tasks that truly aren’t necessary. Every productive minute counts and you want to focus on the things that move the business forward.

    As far as habits go, I think one of the more important ones has to do with letting other people do the work. I know I’ve said it a couple of times already but it truly is important to stop trying to do everything yourself; there’s simply too much to do.

    Other than that, I feel it’s important to make sure that your goal is to help your customers be awesome. For example, I focus on making my customers be awesome at growing their business. I do this by making it easy for them to create proposals that impress their clients and win projects for them. This is literally how I think about things. By taking care of your customers, you’re helping your own business in the process.

    “What are the key things that you would do differently if you would have to start all over again, with a day job and an idea for a business? What were the main lessons learned?”

    I think I would’ve started sooner. I took too much time to actually start doing something to move me forward and launch a product. It was something I thought about for a long time but never took action. It took me being very unsatisfied at work to push me towards action. Unfortunately, most people fall into this trap. It’s especially bad when people are comfortable at work because they’ll likely never take action.

    I made a lot of mistakes in the process of building and launching a product but was still able to make it work. I learned that persistence is unbelievably important. We’re all going to make mistakes, we just need to keep moving forward.

    “Last, but not least, is there anything you would like to say to our readers who have day jobs or freelance careers, but who would like to explore entrepreneurship?”

    Start with something small and have modest goals. If you’re curious or have some doubts, try it out on a small-scale and see how it goes. Even if it doesn’t work out you’ll learn a ton in the process. More importantly, once you start making money on the side you’ll see how your mindset changes.

    Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
    Could not load more posts
    Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
    Just a second, loading more posts...
    You've reached the end.
    No Soup for you

    Don't be the product, buy the product!

    YES, I want to SOUP ●UP for ...