04/25/12

Balancing teamwork with personal opinions

Recently I’ve been researching how people with strong opinions (and often differing opinions) can work together as a team to come up with great solutions. I boiled it down to 5 factors:

  • Unity of vision. Establishing unity of vision within a team is super important. It helps to overcome flame wars and infighting over specific ways of doing things or technologies. If you provide a true north that everyone agrees upon, it’s easier to develop an understanding for team members that don’t share your opinions.
  • Slow to judge. Don’t judge something until you fully understand its benefits and shortcomings, especially in comparison to your current preferences, wherein lies an existing, festering bias. Don’t get defensive and fill up with FUD when someone mentions a new technology or methodology to you. Posture yourself to be excited and eager to see how it could potentially be an improvement. Give it a good shake before drawing conclusions.
  • Eager to learn. This means being flexible, curious, open, and adventurous in your pursuit of perfection. The web changes too frequently for you to be completely myopic and throwing the same solution at every new problem. A good way of measuring your eagerness to learn is to look at how much adoption you’ve put yourself through in the last year, and how many questions you find yourself asking. Both of these things should be regular activities.
  • Avoid the Great Philosophical Takeover™. This is the moment where a staunch philosophical stance builds up a religious fervor deep in your soul to the point where it pushes out any pragmatic evaluation of other people’s opinions. It can quickly turn into bitterness and discontentment that “the rest of the world doesn’t see things the right way, the way I see them.” Developing philosophical convictions is obviously a very good thing, but is more helpful to the rest of the team (and to yourself) if you rid the stench of dogma and myopia from them and are “open source” in your convictions, namely they are able to be changed by other peoples’ contributions. I’m not saying to just go with wherever the wind takes you, but just that you’re not relentlessly dogmatic to the point where objective evaluation goes out the window.
  • Your fate is tied to your teammates. It’s like a three-legged race. Your ability to run fast and be amazing by yourself won’t help you win. You have to work with your team. If you’re faster, you may have to push others to go faster. But you also may have to slow down so you can synchronize your pace. A good expression is make the others good. To succeed for ourselves, we have to work to bring out the best in others. This involves encouragement, suspending judgment, or asking tough questions and challenging others. We’re a team and our success is tied to our teammates.
01/27/12

Hurdles

It’s no question that web designers and developers have to continuously learn and add to their craft to be successful in what they do. The web is a very different place than it was 5 years ago, and what’s expected of you today is different than what it was yesterday. Learning on the job is a no brainer. But when is the most effective time to learn?

I was working on a fun personal project in Rails for a few minutes before dinner last night. In the time span of about 30 minutes a bunch of concepts, conventions, and principles that are essential in understanding Rails clicked. It was a serious turning point. I’ve been trying to learn Rails off and on for a few years now and nothing was really sticking. At that moment I understood that in most cases, I approach my work and my learning wrong: I train while I’m running the race.

Wikipedia says this about hurdling technique: Generally, the efficient hurdler spends the minimum amount of time and energy going vertically over the hurdle, thus achieving maximum speed in the horizontal race direction.

A successful project should feel like the well-trained hurdler: thoroughly equipped for the race, able to go from start to finish with ease, prepared and anticipating the hurdles he needs to jump without slowing down.

Since forever, I have approached projects like this: Run as fast as you can, and when you get to a hurdle, stop to analyze it and figure out how best to jump over it. I’ve always thought it was a good thing to learn during a project, and I’ve always enjoyed accepting challenges for the sake of learning them. I think I was horribly wrong in this approach for two reasons:

1. It’s easier and faster to train/learn when you’re not already out of breath. If you’re trying to train in in the middle of the race, you’re already tired from running. When I was learning Rails last night, I wasn’t in the middle of a project… it was at my leisure, in my own “gym”, and because of that my training was far more productive because I wasn’t already out of breath.

2. Pausing to train tampers with your momentum. Sometimes I’ve engaged in the “mid-race mastery”, only to find myself in mid-race misery once I got back on the regular track.

3. Anticipation alone isn’t enough for accurate estimation. You can look down the track and see all the hurdles, but you’re still going to make guesses at the level of effort to jump over them if you haven’t already done so in the past.

Given these reasons, there emerged a few practical outcomes for work:

1. Client projects are not the right place for training. Clients need you at your peak performance to run the race without stopping.

2. Set aside time dedicated exclusively for training. If you’re unencumbered by deadlines, requirement documents, feedback cycles, etc., the learning process is vastly more productive.

3. To the best of your ability, only take projects where you’re familiar with the hurdles. Swallow your pride. Few projects will be completely exempt from challenges, but don’t take on something you have no previous experience with at all. The fun part of engaging in a challenge should be in your time you’ve set aside for training, and tackling a challenge without being encumbered by the various aspects of a real-world project will free you up to be more creative, flexible and innovative.

12/28/11

Favorite 2011 albums

Here’s a year-end roundup of my favorite music.

02/23/11

Front-end Development Strategies for a Diverse Browser Landscape

The number of platforms, operating systems, screen sizes, environments and even contexts that users experience a web site in a browser has expanded and changed significantly since we created our first animated gif hosted on Geocities. It’s hard to believe that yahoo.com was table-based, using <center> tags and was 760 pixels wide when the first generation iPhone was released in June 2007. A lot has changed.

First of all, web technologies over the last few years have made a significant departure from browsers all-together. As I write this, my family is using the internet to watch the Cosby show on Netflix through our PS3. I haven’t visited twitter.com in ages because I much prefer their desktop app. We visit blogs less and less in favor of media coming to us, many times through apps outside the browser like Reeder.

But we still use browsers a lot, no question. Google’s taking a very different approach than Apple in the way they want people to use the web by bringing everything into the browser with ChromeOS. Most small businesses need a simple site that works in a variety of platforms, contexts and environments, and that’s it. But even that’s it can be a difficult task.

So where does this leave web designers and developers? How do we ensure that our lovingly crafted work performs great for all users in all of their various environments? I think we all agree that the short answer is we can’t, but there are some approaches that can greatly benefit our users and clients, and reduce our own headaches.

1. Gauge your target audience to decide how thoroughly you should debug versions of Internet Explorer

Chances are that for most projects a good chunk of your traffic is still using IE6. I know, it’s 2011 and Facebook dumped IE6 back in August of 2010. But the 20% of your visitors that are trying to figure out why a paperclip pops up when they start typing in Word (depending on your target audience) didn’t know Facebook did that and don’t care. Try to get out of the techno-bubble and make sure the information and usability of your site is adequate for the least tech-savvy people in your target audience. This is significantly more important than getting on a soap box about the semantic web and how css3 transitions and the canvas element will kill Flash by the end of the week. It doesn’t have to be the same design at the pixel level, but it shouldn’t look broken either. You can use “please upgrade your browser” prompts, but don’t rely on them to get away with a site that’s unusable in IE. There are folks out there that either don’t have a choice since it’s a business machine, or don’t even know what a browser is.

If your target audience for a project is pretty hip to the snip on the web, you can likely relinquish even more details for IE users, since the significantly small margin of your audience that uses IE probably came to the site through a link or a search and isn’t directly interested in the content. The level of graceful degradation you adhere to is different depending on your target audience’s web experience.

2. Yeah, media queries are cool, but…

….there are a million ways to conditionally change information, layout, design, etc. for users who come to your site from various mobile devices. Media queries are just one of many tools at our disposal for presenting “responsive” web sites, to coin the trending phrase. Many times it’s best just to serve up different code by running a server-side conditional that looks for the browser and platform, since a site needs to be significantly faster with less http requests in a mobile context. What good is a media query that just hides elements if the site is still as slow as molasses on a 3G network?

3. As much as you can, debug all the browsers your target audience will use at the same time during front-end development

I started doing this about 2 years ago, and will never go back. I just got sick and tired of searching for an element or nondescript javascript error in IE. I can’t tell you how many headaches I’ve avoided by going through this workflow:

- Create your markup all the way through for a given page before doing any css. This helps to ensure that your markup is as clean as possible since you’re focused entirely on the semantics
- Style one element and debug that one element for all browsers to the level you feel is appropriate for your audience. Add elements to the markup only if they are absolutely necessary, and only if they are semantically acceptable.
- If you need to do some scripting, write a bit of javascript and debug that one chunk of code for all browsers before moving on.
- Repeat numbers 3 and 4 until your css and javascript is white hot and ready for prime time regardless of what browser your visitor is using.
- Send off for review with the assurance that everything works as it should in all the browsers it should.
- Have pity on the people that are searching through a hundred lines of jquery for a missing semicolon that breaks a site in IE but works in everything else.

4. Use the latest technology first

If you follow the workflow described in number 3 above, it can really release you to play around with the latest and greatest css specifications and html5 markup, and there are some great tools for bringing more archaic browsers along for the journey with some of the more common css3 styles (CSS3pie, modernizr, html5shiv). You should be as forward-leaning as possible in this regard for a number of reasons. For the best browser rendering engine (Webkit) and fair ones that at least recognize a good chunk of the css3 specification (Gecko, Presto), using css3 can significantly reduce the size/weight of your site. It goes without question that it also greatly increases the speed of front-end development. Pushing the latest technology in your development is also a very good thing for the overall progression of the web technologies. You’re encouraging things to move forward. You’re learning the tools and skills that everyone will be using 6 months from now.

5. Consider the context before making radically alternative site design and functionality for mobile browsers

Unless there’s a very clear situation where your visitors would use your site in a mobile browser on a consistent basis, just make sure at the bare minimum that your site is usable in a mobile browser. If there is a specific situation/context where your users would visit your site often in a mobile browser, consider whether it would be even more useful as an app, or at the bare minimum that its interface within the browser feels intended and comfortable for mobile use.

6. Don’t start with following the trend. Start with searching for the greatest solution.

The web offers a vast ocean of opportunities to innovate and be creative. It’s good to have and develop technologies and standards like HTML5 that attempt to ease the burden of developers by providing consistency and predictability and creating cohesion between devices and platforms. At the same time, there really, really are no rules on the web. If you think of a better way to build something that proves to have great qualities (useful, reusable, lightweight, easy, framework/language agnostic, etc.), go for it, even if it flies in the face of the latest trend. This is especially true if you see that a trend is actually a very poor choice, and that there are several much better solutions out there. It’s beneficial for the web community at large for you to be creative, experiment, and share your solutions.

01/3/11

Simplenote Fluid userstyle

Inspired by Jon Hicks’ Fluid style for Simplenote, I’ve updated the userstyle if you want to clean up Simplenote as an SSB via Fluid.

•  Download css file
•  Download dock icon (.png, .psd)

Tagged:
07/23/10

Being creative in the mundane

I’ve spent most of my life subconsciously boxing the idea of creativity into making something, be it visual experiences (20s), songs (teens) or forts (every year before 14). Most of you creative people out there are probably way ahead of me on this, but lately I’ve really benefited from trying to flex my creative muscles in all areas of life, from how I can get stuff out of the attic without assistance to solving the dilemma of my financial software totally crapping out on me. This kind of mindset of “how can I be creative in solving this problem?” rather than “how can I solve this problem?” has been extremely helpful to me in the following ways:

  • It tailors solving even mundane problems to my strengths as a creative.
  • It has helped me to by default look for efficiency.
  • It has helped me with procrastination because the challenge of finding a creative way to do something is enough motivation to get me through it.
  • It makes doing stuff I normally don’t like to do tolerable and sometimes even fun.
Tagged:
07/3/10

Forging new trends by answering “why”

Trends come and go… tools, layouts, approaches, workflow, fashion, everything.

A key to developing new trends is to evaluate what’s currently being used and really dig into the question “why do people like this?”, and finally “how can I create the same emotional resonance with something I haven’t seen before?” I’ve found this especially helpful with design. Don’t start with just duplicating the trend… start by trying to answer “why do I like this?” and design from there.

Tagged: ,
05/17/10

Woody Norris, education and innovation

Here’s an old article I found interviewing Woody Norris, an inventor who works with the usual: hypersonic sound, helicopters, artificial hips, etc. Aside from the fact that he’s invented some completely mind-blowing things, I find that his approach to his work as an inventor really hits home for anyone who works with the web. After all, this industry is still just a baby and will be ripe for innovation for some time, so all of us are inventors. There are two things he talks about that I thought are good principles for those of us who work with the web.

1. Focus on learning things you’ll use for a long time

Woody made a pointed decision not to go to college because it didn’t provide enough focus for what he wanted to be learning about. He figured he’d waste too much time learning things he’d never use as an inventor.

You don’t have enough time to be proficient in everything related to the web (unless you’re Shaun Inman). Do research and pick technologies, languages and techniques that you think will be on the table for a long time, and then hit the books. Never rest on what you’re comfortable with, especially if you see the web going in a different direction. Stop developing in .net and start learning Rails. Don’t bother installing Flash CS5 with your next upgrade. Burn your PC, get a Mac, install Textmate, and get on gitHub. Cut out anything that doesn’t look toward the future, because that’s the stuff you don’t need to roll around in anymore, and could really start to set you back quickly.

2. Don’t let your education stifle innovation

“You cannot be stupid and do much in the world today. Too many other smart people out there. So I just happened to get my education in a different way. I’m not at all against education. I think it’s wonderful. I think sometimes people, when they get educated, lose it. They get so smart that they’re unwilling to look at things that they ‘know better than.’”—Woody Norris

This one really impacted me. I realize that the more I’m conforming to the semantic web, writing cleaner and cleaner code, following design trends closer and closer, the less willing I am to seek innovation. I think there’s a good balance between aspiring to know web technologies inside and out and being willing to push boundaries for the sake of innovation. Elliot Jay Stocks and Paul Annett are two designers who I think do a good job of balancing foundational knowledge and innovation in their design.

I think Seth Godin puts a good visual on this principle with his “edge of the box” analogy. Thinking outside the box is where you no longer acknowledge boundaries that can’t be changed, but staying on the edge of the box is where you can rest on what you’ve learned, but challenge traditions that have no function any longer.

The Z-Boys of Dogtown come to mind too. When they started bringing their love for surfing into the skate world and took their skateboards into the empty pools of back yards, they changed the sport forever. They used the foundation of a board on wheels and pushed what you could do with it to completely new territories.

Tagged: ,
05/6/10

If you design for web, you need to know front-end

…and to some degree vice-versa. If you’re a front-end developer, your mission is to preserve the integrity of the design with efficient semantic code, which means you need to have an innate knowledge, respect and passion for great design. That provides an enormous amount of security and comfort to the designer, who knows all of his hard work is in good hands when he passes the baton.

If you design for web, you have to be a proficient front-end developer. When you’re working your wireframes and comps you need to constantly be thinking about how this design will be constructed. You can’t design what a building looks like without knowing how to build it so that it won’t fall.

Tagged: ,
04/26/10

A/B testing resource: abtests.com

I love the idea of social research. abtests.com is a very informative resource that can help you make design and IA decisions to increase conversions without doing your own formal A/B testing. You can also upload your own test results to share with others what you’ve learned.

Tagged: ,