Menu

RIM’s petty diversion marketing

RIM Admits it is Behind Australia’s ‘Wake Up’ Campaign:

Those assembled [in front of the Apple store] chanted “wake up” and held placards decorated with the same message, while some protesters dressed as sheep, in another dig at Apple’s popular products and cult following.

I don’t understand why companies think that ridiculing Apple users is a better strategy than making good products. It’s what happens when you believe Marketing > Product.

Do you want critique, or a hug?

Jon Kolko gives some great advice on design critiques. I particularly enjoyed this part:

A “bad critique” is one of the most valuable things a designer can receive, because it short-circuits the expert blind spot and helps you see things in new and unique ways, and it does it quickly. But sometimes in the design process, you don’t actually want feedback at all: you want affirmation, and you want someone to celebrate your work so you feel good. Learning to understand the difference is critical, because if you ask for critique, people will give you critique. But if you ask people to tell you the three best parts of your design, they’ll probably do it. As Adam Connor offered in his IA Summit talk, “Don’t ask for critique if you only want validation. If you want a hug, just ask.“

Speaking of critiques, this is my preferred process to get the most value out of them.

Creating things of lasting importance

Paul Scrivens:

It is tough looking back at life and wondering if you had created anything of lasting importance. The creative person’s ransom is that you usually have to sacrifice something to achieve that feeling. It is tough and not every design that we go through will even come close to being that one of lasting importance. However, I think it is vital that we continue to look for those opportunities no matter if there is a dollar sign attached to them or not. No matter if the people on the awards sites will notice. No matter if our peers praise us or not. All of those things are great, but that isn’t what you are searching for deep down. That isn’t what is going to make you smile 10 years down the road.

The complex process of simplicity

Francisco Inchauste unpacks the difficult process of designing simple products in Simplicity Isn’t Simple. He explains that simplicity isn’t just something you start tacking on towards the end of a project:

It still amazes me how many people ask for simplicity but don’t realize this phase of the design has passed when they’ve already listed out what they want it to do, or in the case of a Website, tell you what needs to be on the homepage.

True simplicity starts at conception. It’s infused into the being of the creators, and by proxy, in the soul of every product they design.

He also outlines some practical strategies for creating simple products.

Klouchebag shows us how we should feel about Klout

Klouchebag – a satirical response to “influence” measurement site Klout – is making the rounds today. It’s a lot of fun (I’m apparently quite a nice person), but it’s more than that. At the bottom of the page, creator Tom Scott gives some excellent advice on how you should view your Klout score:

But… but my Klout score is important!

No it’s not. It’s like search engine optimisation, only for yourself. Ignore it. Concentrate on making amazing things, caring about the people around you, and not being a douchebag. If you do that, then you’ll soon realise that it doesn’t matter one jot what an algorithm thinks of you.

Not one jot. Sometimes only British English can describe a thing accurately.

Six Myths of Product Development

If you’re involved in any kind of software development work, I highly recommend the Harvard Business Review article Six Myths of Product Development (it’s paywalled, but keep reading”¦). It details 6 common misconceptions of most product development managers:

  1. High utilization of resources will improve performance.
  2. Processing work in large batches improves the economics of the development process.
  3. Our development plan is great; we just need to stick to it.
  4. The sooner the project is started, the sooner it will be finished.
  5. The more features we put into a product, the more customers will like it.
  6. We will be more successful if we get it right the first time.

The authors detail the effects of and possible solutions to each of these fallacies. Here’s an excerpt from the resource people utilization section:

In both our research and our consulting work, w’ve seen that the vast majority of companies strive to fully employ their product-development resources. The logic seems obvious: Projects take longer when people are not working 100% of the time””and therefore, a busy development organization will be faster and more efficient than one that is not as good at utilizing its people.

But in practice that logic doesn’t hold up. We have seen that projects’ speed, efficiency, and output quality inevitably decrease when managers completely fill the plates of their product-development employees””no matter how skilled those managers may be.

Unfortunately the full article is behind a paywall. You can read the whole thing if you haven’t hit your 3-articles-per-month quota yet (sigh”¦). Or you can download this PDF I made of the print view.

Design revolution: identifying areas where new interaction paradigms are essential

The Chronicle of Higher Education has a long but interesting review of Thomas Kuhn’s The Structure of Scientific Revolutions. Entitled Shift Happens, the article goes through all the misinterpretations of Kuhn’s work, as well as some of the major criticisms his ideas have received over the years. I found this part particularly interesting:

Scientific revolutions, according to [Kuhn’s book], don’t occur when an apple happens to find the head of a genius, or when enough facts have slowly painted a new picture. Rather, in yet another of Kuhn’s inversions, new paradigms emerge to explain the accumulation of anomalies: findings that do not make sense within the current paradigm. For example, if your paradigm tells you that fire consists of the release of phlogiston embedded in flammable materials, then the fact that some metals gain weight when burned is an anomaly. When a new paradigm is conceived that makes sense of the anomalies, science is in for a revolutionary shift.

There is a definite parallel with design work here. We often try to shift users to a new interaction paradigm because we think it works better. That’s fine, and can be successful – tab-based browsing comes to mind. But these are incremental changes/improvements, and they happen whenever designers approach an existing problem in a new way. They’re worthy pursuits, but rarely essential for an application to still fulfill its purpose.

By contrast some interaction changes are absolutely essential, and we need to keep our eyes open to recognize those elusive circumstances. Essential interaction changes need to happen when existing paradigms can’t cope any more, and new ones are needed. For example, clicking with a mouse isn’t a thing on touch devices, so that particular interaction became an anomaly that couldn’t be “explained” by existing paradigms any more. Therefore we are legitimately creating new paradigms for mobile design to accommodate the change from mouse to touch. We’re still navigating our way through this change, as apps like Path and Clear emerge to challenge our views on what we consider good design.

We often spend our time trying to improve existing designs, and we need to do that. But there is always the danger of hitting a local maximum – “a point [where] you’ve hit the limit of the current design”. To fight this danger, let’s remember that our energy is sometimes best spent identifying areas where existing paradigms are bursting at the seams in their ability to accommodate the design status quo. That’s where the opportunities for design revolution truly lie.

Reading and writing on the web: my tools and workflow

I’ve had quite a few questions about my reading/sharing/writing workflow in recent months, so I thought I’d write down what I do just in case it has some broader appeal. In this post I will outline the process and tools I use for reading on the web (and taking action on the good stuff). We all have to find our own way on the web, of course, but maybe there’s something here that resonates.

First, it’s important to say a little bit about why I spend so much time tweaking and improving this workflow. All of the process work is just a means to an end. And the end is to never stop learning new things. I like how Michael Schechter puts it in Finding Your Passion For Learning:

Today, I read more than I ever have before. Today, I crave new topics to dive into. Today, I love learning more than I have any time of my life. While I’m not always the best at learning what I should, I’m continually discovering and constantly seeking new ideas.

I couldn’t agree more with that sentiment. I read so much because I’m incapable of keeping my curiosity at bay. What ultimately drives me is a need to get better at what I do because I know I still have so much to learn.

So, let’s get to it. My workflow has two main phases, and I’ll discuss each in detail:

  1. Inflow is about the process of finding and reading good articles on the web.
  2. Outflow is about choosing the most appropriate ways to save and/or share the good stuff.

Inflow

As the old saying goes: Garbage In, Garbage Out. We are in a period of constant content bombardment, and unless we find ways to focus only on things that are worth our time, we’re going to be lost at sea. The process for disseminating good content is actually pretty easy once you get into a groove. It’s finding the right things to read that is the constant struggle. I use two main sources for finding things to read, and both requires continuous tweaking.

RSS feeds

RSS is dead, apparently. Well, maybe if you have 80,000 followers on Twitter and only care about major tech stories that’s true. But I don’t have that many sources following me, and I care about too many off-the-highway things to be able to rely solely on Twitter for news. If I only relied on Twitter, I most likely wouldn’t see posts from authors I love who only post infrequently.

I use Reeder on Mac and iOS devices to keep up with the feeds I subscribe to. I spend quite a bit of time adding new feeds and removing feeds I’m no longer interested in. I organize feeds in folders like Design, User Experience, and Coding. I also have two folders with must-read blogs that are always at the top: Favorite tech and Favorite Design and UX. These are the folders I make sure I check in on if I don’t have a lot of time. There’s a lot of churn as I learn more about what I like and read – I add and remove feeds in these two folders all the time.

Twitter

I envy people who treat Twitter like a river they can just dip their toes into every once in a while. I get nervous if I miss a few tweets, so I’m not able to follow more than about 250 people. This isn’t personal, it’s just how I choose to use the service. I like the way Chris Bowler puts it:

One fact that I do my best to keep in mind is this: there are two very different ways to use Twitter. Option A is as a social tool to interact and joke around with others, to connect. Option B is to use it as a source of sharing information, usually in the form of links to content or pithy blurbs of opinion.

Some people like the service for one, but not the other. Some people manage to strike a lovely, harmonious balance between the two. The catch is that “” in my opinion “” we mostly want to follow folks who use the service in the same way we do.

I use Twitter mostly for Option B, so those are the kind of people I follow. So, even though I do a little less shuffling on Twitter than I do on my RSS feeds, I do make some changes once in a while to adjust the type of content that comes into my stream. I also use Twitter lists extensively, mostly to keep up with people who are Option B users but extremely frequent updaters (and therefore too noisy for my main stream).

I use the official Twitter app on Mac, and Tweetbot on iOS devices.

Outflow

Once I see an article in RSS or on Twitter that might be interesting, a very specific workflow kicks into gear as I decide what to do next.

Read it later

If I don’t have time to read an article right away, I use Instapaper to save it for later reading. From RSS, Reeder has easy shortcuts to send articles to Instapaper. On Twitter I just favorite the tweet, and then there’s an If This Then That Recipe that automatically sends the link in the tweet to Instapaper. I could send the link directly to Instapaper from within the app, but I like to save the entire tweet so that I can credit the source if I end up doing something with that content. Attribution is really important to me.

Read it now

I usually spend about 30 minutes in the morning and 30 minutes at night just reading and catching up. This happens either in Reeder, or in Instapaper.

Save permanently

Whenever I read something I like, I save it to Pinboard immediately. Both Reeder and Instapaper have Pinboard integration, so this is a really easy process.

I have a paid archive account on Pinboard that enables additional features like full-text search and cached copies of articles. Seriously, everything in this workflow revolves around Pinboard. I’d be lost without it. It’s a safety net of epic proportions. I go there to look for articles I vaguely remember reading and suddenly need, and it’s constantly in use when I’m writing longform pieces (like this one). If there is such a thing as a hub in this little process of mine, Pinboard would be it.

(Yes, I’m a fan.)

Do something

Once an article is in Pinboard, I do one of four things with it.

1. Do nothing

If it’s just an article I’m saving for reference, or a new method I want to try at work, I move on and don’t do anything else with the article. I might come back to it later when I’m writing something or in need of a refresher on a new design technique, but I’d say I do nothing more for about 50% of the articles I save to Pinboard.

My Pinboard saved links are all private, but if you’re interested you can get access to the private RSS feed by becoming a member of Elezea.

2. Share on Twitter

If I think an article will have broad appeal I share it on Twitter. I usually do this with Buffer. The main use case for Buffer is to queue tweets for sending at specified times, but I use it mostly with the handy “Post now” link in the Chrome bookmarklet as well as the iPhone app.

I use Buffer as my tweet app of choice because it’s the only one I’ve found that allows me to send an article’s title and custom bitly-shortened URL from Chrome or mobile Safari directly to the app for easy posting.

The only exception to this is when I read something right away in Reeder and want to share it. Reeder has really good Twitter integration with custom bitly links as well (only on iOS though – for some reason the Desktop app doesn’t allow you to use your bitly Pro account, so you can’t track your links easily).

3. Share on Tumblr

If I want to share a short quote or photo that’s not directly related to what I write about on this blog, it goes to the B-sides. I use the standard Tumblr browser bookmarklet for sharing.

4. Share on Elezea

If it’s something I’d like to add some thoughts to it goes on this blog. There’s probably an 80/20 split between quick link posts and more substantive articles like this one. I don’t know if that’s the right split, so I’d love to get some feedback – let me know if you’d like to see more/less of something.

My writing workflow is probably worthy of a post on its own, but in short, here are the apps I use:

  • I use MarsEdit to post to WordPress. For link posts there’s a very handy browser bookmarklet that grabs the currently highlighted text and adds all the information you need to just start writing.
  • Instapaper recently added support for Simplenote, which in turn syncs with nvALT on the Mac. So more and more I find myself highlighting something in Instapaper on iOS, creating a new Simplenote text note, and then completing the post in nvALT on the Mac.
  • I use iA Writer for longer posts.
  • I write exclusively in Markdown. I use MarsEdit to post Markdown directly to WordPress, and the PHP Markdown plugin converts it to HMTL on the site. This means that I almost never see the WordPress Dashboard. Which is awesome.

And that’s it. Reading through this again, it suddenly looks complicated. So if you have any suggestions to improve the process, please let me know via email or on Twitter.

Here’s to learning.

More

  1. 1
  2. ...
  3. 168
  4. 169
  5. 170
  6. 171
  7. 172
  8. ...
  9. 195