What if you’re actually terrible at what your real job is?

So this may be very Merlin Man (site, twitter, podcast1, podcast2, and podcast3) inspired, but I have to ask it, just for everyone’s sanity: What if you’re actually terrible at what your real job is?

Let’s say you’re hired to build websites. sure. You’re hired to build websites. But as Horace Dediu (podcast)  points out, a lot of what we need to look at is the “Jobs to Be Done” and when you look at it in that perspective, your Job to Be Done is really to solve their communication issue.

That’s right. You’re not building a website, but communicating information. Be it “This is good” or “That is bad”, or just “Buy this widget”, the job you are doing for your employer is helping them to disseminate information.

If you get up every day, build exactly what they tell you to build, exactly the way they say, there’s two very, very real possibilities of what is happening:

  1. You’re viewed as nothing more than a production worker
  2. You’re terrible at actually solving the problems given to you, and thus become #1

Sure. You have to be able to make things pretty to be a designer, and you have to be able to code to be a programmer, but you have to be able to problem solve to be effective at either.

So, what do you do if you decide you’re terrible at your job?

Get better.

Interesting issue with Assetic in Symfony2

So fkrauthan (in #symfony on freenode) ran up against an interesting issue w/ regard to generating paths to other bundles assets.

I don’t personally know much about the problem area specifically, but I worked with fkrauthan to develop a hack that got around the problem.

So, please, take a look at the github repository and chime in your two cents. I’m almost positive there is a more elegant way to do this, but we had no idea what that was.

How to build truly responsive images

UPDATE: it looks like Scott Jehl has already beaten me to the punch, so check out his github project!

So, I was almost asleep, and this idea popped into my head. I want to write it down for two reasons:

  1. So I don’t forget it.
  2. To see if anyone else agrees, disagrees, or sees any flaws in the idea.
Basically, I think I have figured out how to make images ridiculously responsive
  1. in a syntax that is logical and 
  2. in a way that can be powered by javascript and 
  3. fails gracefully to non-javascript supporting clients
The code starts out as simple as:
<image data-alt="Some image" data-width="300px" data-height="300px"
  id="my_image" class="some_class">
 
  <source src="/images/high-dpi/image.jpg"
    media="screen and (-webkit-device-pixel-ratio: 2.0)" />
  <source src="/images/print-dpi/image.jpg" media="print" />
  <source src="/images/regular-dpi/image.jpg" />
  <img src="/images/regular-dpi/image.jpg" width="300"
    height="300" alt="Some image" />
</image>

With no javascript, nothing but the <img> tag is displayed, and everything is happy.

With javascript, we run a system which turns it into the following (this becomes easier if we can evaluate media queries in JS, but I’m not sure if we can do that, so I’m showing an alternate way):

<style>
  #my_image {
    background-image: url('/images/regular-dpi/image.jpg');
    background-repeat: no-repeat;
    background-size: 300px 300px;
  }
  @media print {
    #my_image { 
      background-image: url('/images/print-dpi/image.jpg');
    }
  }
  @media screen and (-webkit-device-pixel-ratio: 2.0) {
    #my_image {
      background-image: url('/images/high-dpi/image.jpg');
    }
  }
</style>
<image data-alt="Some image" data-width="300px" data-height="300px"
  id="my_image" style="width: 300px; height: 300px;">
</image>

And now for the fun part – we can use document.getElementById(‘my_image’).style.backgroundImage to get the right image!

This means that the last and final step then turns into:

<image data-alt="Some image" data-width="300px" data-height="300px" id="my_image">
  <img style="width: 300px; height: 300px;" src="/images/high-dpi/image.jpg"
    alt="Some image" width="300" height="300" />
</image>

Which should make it happy with screen readers and other similar systems.

This approach has a few distinct advantages:

  1. It leverages existing tools for defining when to load a particular image (media queries)
  2. It provides a graceful fallback for no javascript support
  3. It (hopefully) will be relatively close to whatever is selected for moving forward in a browser integrated solution, as it fits with the patterns already established.

So that’s it. That’s my master plan. What do you think?

twitter