You are currently browsing the tag archive for the 'web' tag.
I’m from Eureka, a relatively rural town of about 30,000 people in Northern California. For those of you unfamiliar with the foggy, green, quiet town where I was born and raised, here’s a map.
Saturday afternoon, Eureka was hit with a 6.5 earthquake. The majority of my extended family still lives in Eureka, and I was very concerned. Not only about the potential for earthquake damage, but about the potential for a tsunami (there was one up there in the 60s, and it killed 11 people). My sister and I weren’t able to reach our Mom and Dad right away; cell signals were dead and land lines were unreliable.
So how did I get details about what happened and how the town fared? From the Internet, of course.
But not from online newspapers. No, I got my info from my Facebook network and from Twitter:
Mind you, these posts are from Facebook friends who don’t even live in Eureka any longer, but they had spoken to their respective families. This at least reassured me that Eureka wasn’t underwater, or complete rubble.
Twitter gave me some other pieces to the puzzle as well, thanks to the #Eureka hashtag (search it now for ongoing info). Even Mashable was running a story that featured user @amyeureka’s Twitter photos of the aftermath.
Thanks to all of these, I was able to at least get some idea of the current status: no reported deaths, no tsunamis, no obliterated buildings. Just a lot of broken glass, toppled bookcases and broken chimneys. I could make a somewhat reasonable assumption that at least my family was alive, though maybe missing a few picture frames and glassware. And I wouldn’t have obtained that information from broadcast news or the paper.
The good news? I was finally able to make contact with my family: thankfully, the only casualty at Mom and Dad’s was a television.
For those of you who don’t know, I’m deeply embroiled in a web redesign project. We’re (fingers crossed) very close to completion. But while I’m really looking forward to launching the site, I’m fully aware that even when the “live” date comes and goes, the work is far from over.
A web project, as previously discussed here, is never truly complete. The launch of a new site signifies the completion of one phase of the project, but at the same time ushers in a host of new projects and tasks, including keeping your site current and relevant. Here are some things to keep in mind:
Training. When you’re close to launch, train your staff on how the new tools work. Give them the opportunity to try things out for themselves – staff members make great beta testers. This will prepare them to use the site and to troubleshoot problems when your users are stumped. Additionally, brief the “higher ups” about the new site and how it will function. Communication is key.
Marketing. It sounds obvious, but have a plan in place for letting your users know that the site has gone live. Consider rolling the new site out to a small group of stakeholders, then a larger pool of several hundred people, then to your larger audience. This will help you make corrections and fix problems before your entire user base runs head first into a major bug.
Debugging, revisions, and inevitable issues. You might think you’ve found every bug, tested every link and examined each page with an eagle eye. It turns out your site probably still has wrinkles to iron out. Gasp! Have a plan in place for managing such problems. In other words, don’t cancel the project management/bug tracking software package just yet. You’re going to need it for at least a few more months.
“I don’t do computers.”
This declaration frustrates me. I hear it everywhere, from colleagues, constituents, family and friends. I hear it from people who don’t like computers, don’t understand them, or just don’t want to use them, and prefer to use more traditional methods of communication and information sharing.
I often hear this issue pegged as a “generational thing.” But I don’t think that tells the whole story.
The difference I notice between the “doers” (those who are comfortable with and like to use computers) and the “don’ters” (those described above) is a fundamental willingness or unwillingness to…test the technology waters. To try things. To investigate. To just “see what happens” when it comes to computers. In my limited observations, I notice that those who are comfortable working with computers are more willing to try out new software features: click the buttons, test the boundaries, to try to “break” things. The don’ters want to know exactly how something should work before they take the plunge.
The cover of the September 7 New Yorker depicts elderly folks taking a language course. But the language in question is modern tech-speak. They’re seated at computers practicing their LOLs and WTFs and OMGs. While the concept is funny to those “in the know,” it makes me wonder – is this really a generational issue? Or is it a matter of how we learn? Would a don’ter find a real-life course such as the one depicted on the cover useful? Maybe a printed manual to explain Twitter? I suppose this personality type is the target market for the “Missing Manual“ series of books. A “doer” would shun such documentation as a waste of time.
Neither of these approaches is right or wrong – it’s just a communication issue. It may not be generational (point of fact: my 94 year old great, great aunt sends emails daily, and has a cell phone) but an issue of how people learn. Take all of this into consideration when working with folks from different technology comfort levels.
Doers: find a way to communicate issues and interest in technology to the don’ters in a way that makes them more comfortable. Give examples. Show how things work. Use visual aids. Give demonstrations. Don’t dismiss them as disinterested.
Don’ters: Be willing to try a new technology or software. Dive in. Make a profile. See what’s there. Ask good questions. Try not to dig in your heels and get frustrated when the answer isn’t obvious.
All: share your experiences with such issues in the comments.
Trying to get a new, current website launched is about as futile as writing a book about the state of the Internet. As soon as you’ve published, it’s completely out of date.
However, the web is a lot more flexible than a printed piece. You can make changes on the fly, adjust content and adapt code. But you have put that capability in place BEFORE the site launches.
Flexible Design: make sure that your graphical layout is one that will flex and bend with the inevitable changes of your site. Consider images and layout as parts and pieces you can drag into and out of the site as changes are necessary. Textual content should be easily modified. Avoid building a site that looks visually stunning but is completely rigid and requires a total overhaul to update.
Flexible Programming: adding new tools, widgets and features should be simple and painless. Your programmer/developer/vendor should be prepared to make changes almost immediately after the site has its official launch. You should also build the need for inevitable changes into your plans for the next two weeks to six months. After that? Start thinking about your new site while you keep the current one…well…current.
Administrative Buy-In: pre-load the expectation among staff, volunteers and partners that the site will be fluid and flexible. This is an important step in mediating confrontation about changes after the site is up.
A website is never really “done” as far as I can tell. Enjoy your launch celebration, but remember that the work is only entering a new and different phase.
