Questions part 6: Aftermath and beyond
There’s life after launch. Reassessing, maintaining and adjusting the website requires critical evaluation from time to time. I often tweak sites with questions like these. Part six of six. Questions part 6: Aftermath and beyond.
Questions part 5: Launch
Rather than the end of a project, launch is a milestone in a digital project’s lifetime. Part five of six. Questions part 5: Launch.
Questions part 4: Refining
Most digital projects I’ve worked on treat user testing as a last-minute event, if it occurs at all. If I’m lucky enough to have time for problem solving before launch, I ask these questions. Part four of six. Questions part 4: Refining.
Questions part 3: Testing
User testing can reveal funny (or disasterous) observations about a digital project. Accepting and dealing with the difference between expectations and reality requires a sense of humor and asking the right questions. Part three of six. Questions part 3: Testing.
Questons part 2: Design
No two apps or websites, are the same. Neither are the roads between concept and first draft. But questions arise from wading knee-deep into code and pixels. Part two of six. Questons part 2: Design.
Questions part 1: Concept
How should one start a website or app? Everyone has different questions in the beginning. These are mine. Part one of six. Questions part 1: Concept.
Little rewards and fewer frustrations makes content management less of a chore
Every website content management system lets people curate content. But I discovered that if the CMS itself is fun and painless, people are more inclined to update. Little rewards and fewer frustrations makes content management less of a chore.
Lessons from building word clouds
I’d never built a word cloud before. A collection of user-entered answers to weekly questions sounded like a maintenance headache if people used it, or a failure if they didn’t. The client set high expectations, but neither of us saw what was coming. Lessons from building word clouds.
A jQuery snippet to hide unnecessary support
We had a list of links that wouldn’t sit still. The client would occasionally change the links, including some to PDF files. To accommodate users, we added a link to Adobe Reader. But when the list had no PDFs, the Reader link became superfluous. Conventional wisdom would have left the Reader link on the page [...] A jQuery snippet to hide unnecessary support.
