Blog

This is Brick by Brick – the BitMethod blog spanning everything from tech to code to business philosophy…not to mention bringing a little Valley culture to Flyover country.

Grab the feed

Authors

Categories

Newsletter

Sign up for our newsletter and stay in the loop.

Join Our Mailing List

Search

In 2011, you’re going to learn what a Content Strategist is, create a mental checklist to evaluate them, and start gagging on the bullshit of self-proclaimed “Content Strategy Experts”. I predict that awareness of the discipline of Content Strategy will see enormous growth in 2011, so I’m writing this article to help you buff up on the topic and gain some insight to help sort wheat from chaff when it comes to evaluating an “expert” claim in the content strategy arena.

Not sure what a Content Strategist is? Go read this, a more thorough content strategy primer than I could possibly write from HappyCog’s A List Apart. Go on, read it. I’ll wait.

You didn’t read it, did you? I know, it’s a lot of words. Fine: a Content Strategist works in tandem with the Information Architect (or pulls dual-duty) on a project to handle tasks including editorial planning, copywriting, taxonomy (such as blog tags and categories), even brand messaging. It depends on the project and depends on the strategist. Content strategy is a good home for people who accidentally majored in Journalism (like me1), tech-savvy writers, and librarians displaced by Google.

You may have noticed the A List Apart article is from 2008. So why is this a 2011 trend prediction? Well, shit takes time. Besides, we had to use up our collective tolerance of phony Social Media Experts before we could gang up on phony Content Strategy Experts. 2011 will also see the launch of ConFab, a promising conference planned for May in Minneapolis by the content strategy firm Brain Traffic 2. Increased ease in delivering media-rich content is precipitating this trend as well; New Twitter embeds video and photos right in the timeline, and I’m pretty sure everybody but me got an iPad for Christmas3.

Death to Lorem ipsum

The web development world recently underwent a collective “oh, duh” moment and realized Content Management Systems, websites, and social media campaigns are pretty much worthless without premium, enjoyable, and useful content. The lack of planning a big block of “lorem ipsum”4 can indicate has been the death of many well-intentioned web projects. Content strategists believe—rightly so—that content isn’t something you plug in after everything else is built; it’s where you start a project, it’s where you end a project, and it’s how you keep a launched site high on engagement.

Like most emerging disciplines, the guts of content strategy aren’t new; it’s old things in new contexts with fresh thinking applied. Mobile, another exploding trend, is the same way. Our favorite examples of Mobile technology include “notebooks” and “watches”. Nothing new there. Publishers and editors of print periodicals have been working in “analog” content strategy for years, though they wouldn’t call it such. Specifically, content strategy includes time-tested web stuff like SEO, blogging, old-fashioned copy-editing, and, yes, even social media.

Flighty buzzword or long-term trend?

“Harrumph,” says the old-timey Webmaster. “Content Strategy is just another stupid buzzword that will go away soon enough.” Bullocks, I say. Buzzwords are buzzwords until they’re not. Some will live and some will die. That’s tech. Content Strategy is a Very Useful Concept, buzzword or not. Whether you see fit to hire a content strategist for your project or to simply learn about and apply content strategy practices to your project, it’s a discipline worth embracing. Slow down a minute and ask “Wait, what actually goes in this spot marked Content Comes Later?”

Selecting a content strategist

Alright, let’s assume I’ve got you convinced: content strategy is important, and you might even want to assign someone to lead content strategy on your next project. What kind of person is right for the role? Here are some tips:

  1. They are most comfortable with words. Content strategists communicate with words—not data, not pictures, though they do enjoy a good diagram now and then.
  2. They are high level thinkers. While details are important for content strategists, they can’t get lost in details. They are system-level thinkers. Evaluate their digital footprint and ask, “Does everything flow together? Are they communicating the right message to the right audience on the right platform, 99.9% of the time, even with their personal brand?”
  3. They turn out a lot of (quality) content. Any jackass with 20 minutes and an ability to Google can set-up a blog, a Twitter account, a Facebook page, even shoot a Flip video, edit it, and upload it to YouTube. But can they do it again? Was the purpose of the content clear? Content strategists spend as much time creating a plan for their content creation as they do creating it, if not more.
  4. They’re not specialists. Being a kick-ass videographer or flash animator or writer does not necessarily make you a great content strategist. Great chefs aren’t always great restauranteurs.
  5. They use tags and categories, and those tags and categories are consistent, not flippant.
  6. They’re as comfortable helping someone else produce content as they are creating their own.
  7. They are bulldogs. Content strategists are fighting a war of attrition against “later”. “Copy will come later.” “Get the site set-up, we’ll figure out the video later.” “Throw a few categories in there for now, we’ll figure the rest out later.” Give a team an inch and they’ll take a mile—content strategists have to be very comfortable telling people “no” and “slow down”.

In conclusion

I challenge you, dear reader, to familiarize yourself with some content strategy basics. Read up, maybe even subscribe to a blog on the topic, and begin building your internal checklist to evaluate Content Strategists. As much as the term “Social Media Expert” has become an industry joke, good ones are worth their weight in gold and it’s up to you to know which ones are which. The same goes for Content Strategists. Tread carefully, learn what you can, and don’t be afraid to ask for help!

Further Reading

The discipline of content strategy: http://www.alistapart.com/articles/thedisciplineofcontentstrategy
Scatter/Gather, a content strategy blog by Razorfish: http://scattergather.razorfish.com/
The case for content strategy, Motown style: http://www.alistapart.com/articles/the-case-for-content-strategy-motown-style/
A content strategy mindmap: http://www.web-content-strategy.com/contentstrategyarticles/contentstrategymindmap.html
Complete beginner’s guide to content strategy: http://www.uxbooth.com/blog/complete-beginners-guide-to-content-strategy/

Footnotes

  1. For clarity, I am not claiming to be a professional content strategist, especially not an expert one, but I think my skill set lends itself well to the discipline and it’s a hat I often put on for projects at BitMethod.
  2. Of whom I am totally jealous for their name. Brain Traffic. Say it. Brain Traffic. How cool is that? How was that domain not taken already?
  3. Not complaining, just illustrating a point. I did pick up a delightful new Macbook Air for myself.
  4. In case you’re unaware, Lorem ipsum is dummy latin text that many designers use when putting designs together. It’s a necessary evil in some use cases, such as showcasing templates or other customizable designs, but should be avoided whenever possible. If your whole project is full of Lorem ipsum, you need to go back and put some real words together.

1 comments

Scott Kubie

About the author: Scott is BitMethod’s “Chief Nerd Translator”, filling project management and copywriting roles on most projects. He is passionate about media and has worked in radio, film and event planning. When he grows up he wants to be a Ghostbuster.

Reach out to Scott Kubie at scott@bitmethod.com

I love Amazon. I’m constantly impressed with how fun it is to use, but I had an experience with their site recently that got me thinking about how even the best websites can miss common tasks their users want to perform.

We decided to do computer upgrades at BitMethod a couple of weeks ago. I was really impressed with one of the upgrades I did and we decided to order another one for a different computer. I went back to Amazon, where we had purchased the original parts, to reorder it. Not feeling like searching for the product again, I went to my order history to find it.

I was greeted with a well-organized list of all the items I had purchased recently. Even better, each item had a menu next to it that said “Available Actions”. “Awesome,” I told myself, “there will be a reorder option.” Even though there were lots of other actions, no reorder button was there. It wasn’t a big deal, as reordering was as simple as clicking the link to the product and going through the usual steps.

If the “Available Actions” menu hadn’t been there, I probably wouldn’t have thought anything of it. But my mind was in reorder mode and, once I saw it, I thought I’d be able to line up my desires with the capabilities of the site.

Amazon has a reputation for follow-up sales. When you order something, it recommends a related product. When you first visit the site, it suggests products you may like based on your previous ordering history. Lists of your previous searches show the recent products you’ve looked at. It’s odd that they would omit a chance to encourage people to buy more.

Don’t Make Me Think, a book about web usability, features Amazon prominently in its examples. The author praises Amazon enough that a subsection of the book is entitled:

“If you love Amazon so much, why don’t you marry it?”

If Amazon concentrates so much on the various ways they can sell products to people, why would they omit a link like this? It may be because of something Steve Krug discusses later on in the book: how to perform usability testing. He terms the testing of specific workflows “key task testing”.

“Key task testing means asking the user to do something, then watching how well they do.”

Amazon likely has a full list of specific tasks they ask their testers to perform. But either they don’t have a usability test for reordering or they are aware of the confusion the “Available Actions” menu generates.

As web developers, especially on a small team, it’s easy to think that we have a grasp of every angle because we think we can see the whole picture. Usability testing like that advocated in Don’t Make Me Think involves sitting real people down in front of your software and watching what they do. Running across little gaps in functionality in sites with excellent reputations like Amazon can put our own near-sightedness into perspective and remind us of how important usability testing is everywhere.

Neil Roberts

About the author: Neil is a Dojo master (unrelated to Kung-Fu) and an accomplished programmer, educator, and author. He’s recently developed projects for iOS, Android, and the web. Neil freqeuntly runs JavaScript and iOS training programs for enterprise-level development teams, and has taught at Sun’s JavaOne Conference.

Reach out to Neil Roberts at neil@bitmethod.com

Monkey See, Monkey Do

by Neil Roberts in , 21 September 2010

Copying is fundamental to application development, especially as it relates to user interfaces. Every time you click a button or use a scroll bar, you’re experiencing it. These shared ideas grew and evolved as computers grew and evolved. Ideas don’t always grow the way their authors imagine. As other developers borrowed ideas, some turned into something better; others were copied without any understanding of the problems the original author was trying to solve.

A major shift in user interfaces has come about due to smartphones. Instead of a mouse, we use our fingers to interact. Screens are smaller, buttons are larger. New ideas are popping up regularly as we figure out ways to improve the user experience.

One of the most talked about ideas is the pull-down-to-refresh behavior originally implemented by Tweetie (now Twitter for iPhone). As you are scrolling up through the stream of tweets from those you’re following, you reach the top of the list and find a little instructional row that suggests you pull down to refresh. Pull far enough and the message will change to let you know you can release. It informs you that new tweets are loading and, when they’re loaded, they fill in above the row you were last looking at. All of this is done without losing your place in the timeline.

This behavior works because it extends your natural interactions with the app. The list is chronological, the newest tweets will always be at the top of the list, and most Twitter users need only wait a few minutes to find new tweets from their friends. On the flip side, there is no reason the user would want to reload other than being at the top of the list. You can’t reload yesterday’s tweets; they would remain the same.

There’s a great interview with the developer, Loren Brichter, where he explains in his own words why the idea works so well:

“reloading was simply ‘loading newer’, and ‘loading newer’ put new messages at the top of the list… and activated the action based on a finger motion that you were already doing. Why make the user stop scrolling, lift their finger, then tap a button? Why not have them continue the gesture that they are already in the process of making? When I want to see newer stuff, I scroll up. So I made scrolling itself the gesture.”

Tweetie won an Apple Design Award in 2009 and received a huge amount of press. Very quickly, other applications began copying this behavior. But they did so in a way that had very little to do with the original idea.

A number of egregious examples exist, but I’d like to focus on one of the apps I’m regularly upset by: Foursquare. Although it’s used throughout the app, I find its presence on the Places screen baffling. In Foursquare for iPhone, a screen exists to show me what places are nearby that I may check in to. In order to reload the list of places — which I would do if my location changed — I have to pull this list down to trigger the pull-down-to-refresh behavior.

On this screen, there is no clear reason to go to the top of the list. If I’ve relocated, I don’t expect new locations to show up above the locations I originally had on the list. In fact, the old list of locations is now meaningless. What I want to do is throw away the old list and load a new one. To nit-pick about vocabulary, I want to reload the list, not refresh it. Worst of all, the toolbar has adequate room for a proper reload button, which would be a more sensible element to use.

Marco Arment, a popular web and iPhone developer, says it well:

@atebits FWIW, I've never had Tweetie lose my place. Pull-to-refresh makes sense only when you're naturally scrolling up while reading.less than a minute ago via Tweetie for Mac

Why are these developers copying a feature that doesn’t have a place in their app? There are a number of temptations. Developers love “shiny” features that move around and animate. The press surrounding Tweetie was something that any developer would want to jump on. Reload buttons are boring.

Copying requires understanding. It’s true for pull-to-refresh and it’s true for the ubiquitous elements like buttons and scroll bars. If you copy an idea and retain the spirit of the original implementation, the author will be flattered. But copy an idea just to copy it and you show your users and colleagues that you don’t understand design.

Neil Roberts

About the author: Neil is a Dojo master (unrelated to Kung-Fu) and an accomplished programmer, educator, and author. He’s recently developed projects for iOS, Android, and the web. Neil freqeuntly runs JavaScript and iOS training programs for enterprise-level development teams, and has taught at Sun’s JavaOne Conference.

Reach out to Neil Roberts at neil@bitmethod.com

I don’t like being doom and gloom about security on the internet. Being a web developer, I’m pretty happy with the technology that currently exists. Unfortunately, many sites either omit or incorrectly implement these tools. One common and potentially disastrous error is poor password management.

Odd, overly-complex passwords are what I use when signing up for a new site. Every now and then, I try to use one of these passwords and get something like this (orange highlights mine):

If you see wording similar to the areas I’ve highlighted, it should send up a red flag. No site should enforce any restrictions on how complex your password can be. You should never see any messages about maximum character lengths or restricted characters. There is nothing specifically wrong with the other restrictions; trying to get users to do things like combine letters and numbers or use a longer password is a good idea.

Password Storage

When you send a password to a site, the site should not just store your password in a file on one of their computers. If a hacker manages to access this file, they can start visiting PayPal, Amazon, or any site that uses the same email address or username with this password to wreak havoc.

Most sites store passwords using something called a hash. A hash function can take a sequence of characters and turn it into an identifier (called a hash). The same hash will always be created for the same password and there is no way to reverse-engineer your password from this hash. The hash is what should be stored in a file by the site, not your password. Each time you sign in, the site will make sure that the current hash of your password matches the hash of the password stored on the site from when you signed up. It never has to use your actual password for comparison. If the actual password doesn’t matter, why should the site care about what characters you use or how long your password is?

Because this is how a password should be stored and because hashes allow for any characters to be used at any length, when I see errors that limit these things, it leads me to believe a hash isn’t being used. This means your password is probably being stored in a file on one of their computers, ready to be hacked.

I hedge my bets by creating a random password for every site I sign up for. I store these passwords securely on my computer and I’m able to look them up when I need them later. If I do this and a hacker manages to get access to my username and password on one site, they won’t be able to use that password on any other site.

You can do something similar by using 1Password. 1Password is an excellent password storage tool that comes with a password generator. It allows you to create passwords tailored to the restrictions of each site your sign up for and easily locate them later.

If I’m creating random passwords for every site, I might as well make each password as random as possible. My passwords are 16 characters of numbers, symbols, upper-case letters, and lower-case letters. Basically, everything I can possibly type. This can prevent what’s known as a brute-force attack on my password.

Password Cracking

When trying to figure out a password, a hacker will go through every possible password, starting from the most common types of passwords. Because most people create passwords that are easy to remember, the first thing a hacker will do is to use real words. When real words don’t work, randomly assembled characters are used next; starting with letters, then numbers, then symbols, until all possibilities are exhausted.

The character set in common use (called ASCII) allows for around 128 different characters. Calculating how many possibilities a password may have is done through: (options per character) x (number of characters). For example, if I am only using 1 and 0 for a 3-character password:

  1. 000
  2. 001
  3. 010
  4. 011
  5. 100
  6. 101
  7. 110
  8. 111

Each character has 2 possibilities and there are 3 characters. Doing the calculation (2 ^ 3) gives us the 8 options shown above.

From this calculation, you can see that both adding an extra possibility and an extra character will significantly increase the number of possible passwords. For my passwords, if I pick 16 random characters from the 128 different characters, a hacker may have to go through 128 ^ 16 possibilities (5,192,296,858,534,828,062,602,462,446,642,046). Even making a thousand password attempts a second, it could take countless millennia for the correct password to be discovered.

Bringing back the error message from the start of the post, it should be noted that hackers trying to crack a password will be able to reduce the number of passwords they have to try with this knowledge. From the message, a hacker knows that they can skip all passwords that contain only one type of character (417,754,194,688 possibilities). Also, passwords will be limited to letters, numbers, and 4 symbols for a total of 66 characters. This means a hacker will only have to test 0.5% as many passwords compared to a site without restrictions.

It’s impossible to know about every security problem a site you want to sign up for may have. You shouldn’t let this stop you from signing up for sites, but you should keep your eyes open for security problems where they are easy to spot. Try not to use the same password across multiple sites, especially if you’re worried about how your password will be stored.

9 comments

Neil Roberts

About the author: Neil is a Dojo master (unrelated to Kung-Fu) and an accomplished programmer, educator, and author. He’s recently developed projects for iOS, Android, and the web. Neil freqeuntly runs JavaScript and iOS training programs for enterprise-level development teams, and has taught at Sun’s JavaOne Conference.

Reach out to Neil Roberts at neil@bitmethod.com

You’re going to have to start over.

I’m part of a generation of programmers that was brought up with the promise of “Write once, run everywhere”. Colleges created computer science programs we assumed would teach us everything we needed to know; that we would never have to learn anything beyond what we got during our time there. We looked at the simple text-based applications of the past as being below us. We had every tool we needed to become the best programmers ever. It’s unfortunate that we view the programmers of the past with such disregard.

Early programmers were brilliant; they had massive technology constraints and had to know the tiniest details of the environments they were coding in. Every day, we use the technologies they created. The programs they wrote are still performing mission-critical operations decades after they were first written. Dreaming in Code, a book about the problems of programming, begins by introducing a real-life example of one of these aging but reliable programs.

In the classes I teach involving web technology, I find myself having to defend some of the features I explain are already part of the technologies they use every day. Students don’t believe me when I explain that GET and POST in HTML forms are meaningful verbs, that caching is done through HTTP headers, or that JavaScript isn’t the only language that allows first-class functions. Most of the time, the way I defend myself is by explaining how old many of these ideas are. JavaScript, for example, borrows ideas from Scheme and Self and the “weird” things we do with JavaScript can be traced all the way back to Lambda calculus (which is really old).

My generation has been very lucky. Computers are fast. The low-level work has been abstracted for us. We have tools that let us know when our program is written incorrectly. People have become used to waiting while our programs pop up little spinners and progress bars. It’s no wonder that if you begin looking for articles about bad programmers, you’ll find that many of them were written around the time my generation was completing its college education.

A few technology companies have started making programmers look bad. Many mobile phone applications expected to react instantaneously when the screen is touched. Users visiting our websites expect to be able to perform many tasks without having to wait for the page to reload every time they click something. But instead of accepting these expectations, we complain about how much more work we need to do in order to make our programs function the way they should have in the first place.

If we’re serious about fixing our attitude, we will start to find that the new tools we have are incredibly similar to the tools that existed years ago that we never bothered to learn about. We never learned manual memory management because computers were powerful enough to do it for us. Then we started using mobile phones and computers weren’t as powerful anymore. We only learned one way of doing programming because we hoped it would become the one true language. Then we realized it was poorly suited to all but the most structured tasks. We never bothered learning about how web servers were designed to work because we thought everything would just be a file being shown on a monitor on a computer desk. Then users expected to be able to interact with a web page, view the data in a native mobile application, or access their data from a different web site.

The changes we are experiencing right now show that the advances in technology aren’t linear. This shift is moving backward and reincorporating the ideas of a generation before us. There will be many more. Some changes will use what we already know in new and interesting ways. Other changes will be totally sideways. If you intend to continue programming for years to come, at some point you’re going to have to start over.

1 comments

Neil Roberts

About the author: Neil is a Dojo master (unrelated to Kung-Fu) and an accomplished programmer, educator, and author. He’s recently developed projects for iOS, Android, and the web. Neil freqeuntly runs JavaScript and iOS training programs for enterprise-level development teams, and has taught at Sun’s JavaOne Conference.

Reach out to Neil Roberts at neil@bitmethod.com