Wrong

Two simple syndication tricks to get wrong: have an image and don’t trust iframes

Blogging is simple, but many people forget that there are freaks like me out there who have done this for quite a while who use RSS readers and that there are new folks out there who will share your links on Facebook, Google+ and other social networks.

Beastie Boys - Ill communication

Therefore it is pretty important to do two things in your posts:

  • Do not rely on iframes working
  • Do have an image for social media sites to show as a thumbnail

As to iframes, my good friend Jens Grochtdreis this morning posted about needing a new workflow in web development, proving his point by embedding two of his talks on speakerdeck (which are iframes). To me, his post looked like this in feedly:

Blog post with embeds not showing up - all I got is two headings promising content

Two headings, no content. I reported the problem on Twitter and now he linked the headings to the URLs on speaker deck. Everybody wins.

Most readers will filter out iframe content if it mixes http and https for security reasons. Something we’ll encounter more and more in the future when content security policy becomes a bigger topic (yes, the web is insecure, yes, it is our job to fix that).

The second tip about having an image is a nice-to-have but important. Having an image in your post – a real image element, not a background image – means that Facebook, Google+ and others will show this image next to your blog post title when someone shares the link on these systems. If you don’t pick a thumbnail, Facebook picks the first one. This means your link could show up next to an ad for another product and confuse potential readers. A great example I encountered the other day was Scott Hanselman’s Are you a Phony? post which, with a title like that, showed up next to an ad with an endorsement of his for his hosting service. Confusing message, much?

scott hanselman post shared on Facebook with a wrong thumbnail

Seems to me people click much more on links with contextually relevant images next to them. Thus, providing one makes it nicer for everyone.

Simple, but effective.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Everything wrong with your product in 140 characters or less

The video series “Everything wrong with $movie in $length minutes or less” by Cinema Sins is a big YouTube success and for a movie buff like me a lot of fun to watch.

statler and waldorf of muppet show

The team behind it take a lot of time to meticulously analyse goofs and issues in movies and mercilessly point them out in short movies. Frankly, I am amazed they can show that much footage of current movies without take-downs and that they have such a quick turnaround time. It is funny, it is parody and satire and it shows that even the most polished and expensive products of the entertainment history aren’t safe from slip-ups. What I like most about them though is that they are also pointing out how they themselves are not without fault: “We are not reviewers – we’re assholes”.

I see a lot of parallels in how people criticise products on the web – we don’t really look at the why and how something was built but from the get-go try to find the simple to prove fault and talk about that instead. The fault that probably only us web developers will ever see or even remotely care about.

This, in itself is not a bad thing as it shows that we care about our craft and look at what other people do. This can be gratifying which is why we leave code comments and easter eggs – a secret handshake from one professional to another. We want people to look at what we do. We do not, however need people to nit-pick at one small detail and disregard the rest of our work as that is hurtful and makes the person reporting the issue (and only this issue) appear as intentionally hurting or trying to find a flaw at all cost.

Things go wrong, and in many cases we don’t know the reason. It could be that the place the content is published has limited access to the writer, thus forcing us to use an image where a text with CSS would have been better. Zeldman put that eloquently in his Get off my lawn! essay where he explained that it is not ironic if an article about a certain best practice gets published on a platform that doesn’t follow that practice.

It could be that the product had to be shipped at a certain date no matter what and corners had to be cut – a fault of the project manager, not the developer/designer. Many things are impacting the release of a web product (and that includes apps in my book); it is unfair to blame the executing party.

Maybe it is a good idea to reconsider publishing that one fault publicly and instead do a two minute research finding the makers of the product and report the fault there. Instead of public naming and shaming and – let’s face it – gloating we could thus either report an unknown fault to those who can fix it or learn why something happened. In either case, this means you are a constructive critic and don’t come across as a know-it-all. It is very simple to point out a flaw, harder to fix it and hardest to prevent them. To the outside, our constant nit-picking doesn’t make us look an inviting bunch, and is the small moment of fame finding the obvious bug worth that?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Backflip Gone Wrong



VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)