Archive for the 'Definitions' Category

Writing for Search Engines: Demystifying SEO

Published November 1, 2013 Definitions Leave a Comment
Tags: , , , ,

SEO may seem like just another confusing acronym, but it is not as complicated as it sounds. Search Engine Optimization (SEO) is simply a fancy term for adapting the content of a website so that it will appear higher in search engine results.

SEO SpidersWhenever someone types a term into a search engine, that engine’s web crawlers or “spiders” (cue an image of the robot spiders hunting for Tom Cruise in Minority Report) scan the web looking for sites relevant to that term. Fortunately, we don’t need to crack the complex search algorithms involved in this process (but you can read Google’s enlightening explanation of “How Search Works”). There are some basic guidelines that can be followed to ensure that your content, or the online copy that you’re writing for your boss, will appear higher up in the search results.

Choose, and use, relevant keywords

This may be the simplest and most well-known SEO technique. Is your blog about cooking? Make sure you write with words that people will use when they search for topics related to cooking. You may be tempted to employ cutesy titles such as “A Bowl of Cheesy Goodness,” but a more straightforward title such as “Broccoli Cheese Soup for Cold Winter Days” is more likely to show up when your readers search for “broccoli cheese soup recipe.” Also, be sure to think of possible alternate search terms, such as “chocolate icing” for “chocolate frosting.” If you’re having trouble choosing good keywords, then consider using a site like wordtracker.com

However, there is such a thing as too many keywords. Search engines now employ algorithms to detect “keyword stuffing.” The best away to avoid keyword stuffing is simply to write well. Write in a conversational, natural fashion, instead of trying to repeat the same word as many times as possible. This will enhance the experience for your reader, as well as keep your page from being labeled as spam.

Being connected through links

In a world that thrives on social media and other forms of online connection, it is no surprise that having a popular, well-connected website will increase your search engine visibility.  A moderate amount of relevant links on your site will rank well with search engines. Internally, you can link to your own content. For example, whenever you reference information that you have posted about previously, link back to that page. When giving your reader instructions, such as how to buy your company’s product, provide links to the different parts of the process.

Outbound links are also important. Links to other well-designed webpages about the same topic show that your site is thorough and well-informed. When other pages start linking to your webpage, that is even better, because now you are being identified as a reliable source. The better connected you are, ingoing and outgoing, the more visibility you get and the more the search engines are going to like you.

I know you love my headings… Well, Google search does too.

Good site organization is important for multiple reasons. It arranges your content in a way that is easier for the reader to follow and consequently, that makes it easier for the search engine spiders to find what they’re looking for. Instead of writing your page in essay format, dump those MLA-style transitions and use headings to organize your information. This is also a great, non-spam-y way to boost your keyword count. Breadcrumbs and a sitemap are other ways to make your site easy to navigate, and they also increase the number of internal links on your site.

Search engines: A new kind of user

SEO is really just another type of technical writing. At its core, technical writing seeks to communicate information to users in an understandable way. SEO simply adds a new user to the mix: the search engine. And as you optimize your content for the search engine, you are improving your content for your human readers too. After all, these three basic guidelines encourage you to write well with relevant vocabulary, be well-informed and well-connected to other sites that support your information, and organize your content effectively. What could be more user-friendly than that?

-Marianne Goodlin

Advertisement

Thinking about Iterative Usability Testing as Revising

Published October 29, 2012 Definitions , usability Leave a Comment
Tags: , ,

Last week, while preparing to give a presentation to a group of students, I encountered a problem. When I logged into my favorite online presentation editor, I discovered that the interface had changed almost completely.  There were unrecognizable menus across the top of the screen, and the buttons and menus I was used to were no longer there. I experienced a brief moment of panic. I had to present the next day: how was I going to learn a completely new interface AND complete a presentation visual in less than twenty-four hours? Fortunately for me, a banner appeared at the top of the screen offering me the option to switch back to the “classic” version, at least temporarily. I could create the presentation I needed using the version I already knew and come back later when I had more time to learn the new interface. Not every user is so lucky when it comes to other software or websites.

My potential panic could have been prevented if the developers of the online presentation software had utilized the concept of iterative usability testing. Dr. Jeff Bacha, a professor of technical communication at the University of Alabama in Birmingham, gave a lecture this week at the University of Alabama in Huntsville advocating “In-context” usability studies, and he touched briefly on iterative usability testing as a method of producing more efficient products–and subsequently happier users.

What exactly is iterative usability testing? Iterative usability testing differs slightly from traditional usability testing. In traditional usability testing, usability experts observe users as the users interact with the product after it has been completed or nearly completed. In iterative usability testing, users are offered the chance to evaluate the product throughout its development. In other words, as small changes are made to the product (the software, website, etc.), users are asked to evaluate the product and the specific changes that have been made. When I think about iterative usability testing, I like to compare it to the writing process. To adopt a writing term that many people may be familiar with, iterative usability testing is, essentially, revising. When we write a document, we draft, ask readers for feedback, make changes, and ask for feedback again. We may go through the process half a dozen times or more, producing slightly different–and hopefully improved–drafts each time. Iterative usability testing is a similar process undertaken for a product such as software or a website. The developer makes small changes to a software program or website, asks users for feedback, and takes their concerns into account when making changes to the next version.

In the diagram below, I illustrate the similarities between the two processes. The first stage of both processes is the creation of an initial version of the document or product, a “first draft,” as it were. In the second stage, the product is tested by users (or the document is read by readers) and feedback is collected. In the third stage, that feedback is incorporated into the document or product. In other words, the product or document is revised in order to reflect user/reader concerns. This results in the fourth stage of the document, the new “draft.” I do not say the final draft, because in writing and in iterative usability testing alike, each draft is sent again to readers and users for additional feedback, for as many “revising loops” as time and resources allow before a final version is produced.

The key to successful iterative usability testing is incremental change: if the changes to the product are too drastic, users may be overwhelmed and become unable to point out specific, fixable issues. Take the case of my interaction with the online presentation editor as an example. If the developers had not offered me the alternative to revert to the previous version of the controls, I would have quickly become frustrated, because I didn’t have time to spend on learning the new system right then. In all likelihood, I would have abandoned the editor altogether and gone back to a familiar system like PowerPoint, at least for the project at hand. On the other hand, if, instead of changing the interface all at once, the developers had changed things little by little, asking me along the way (through email surveys or on-site polls) which changes I liked and which ones I didn’t, my potential for frustration would have been greatly reduced.

Iterative usability testing, then, is useful in one respect because it prevents user frustration. However, it is also useful for developers; in the long run, it can save time. Incremental usability testing provides developers with user feedback throughout the development process so that they can tailor the product to the user’s needs. Finding out which features users actually use and which ones they dislike can direct the development process more efficiently. The developers won’t waste time making major changes that users neither need nor want.

Thinking of iterative usability testing in the same way writers think about revising could help developers prioritize their incremental changes. There’s no need to waste time working on an introduction to a document if readers think the draft is fine as it is; instead, the developer can focus on problem areas that will actually improve the reader’s experience. Likewise, there’s no need to work on changing the appearance of the forum on a website if user input shows that nobody actually wants to use the forum.

If the developers of the online presentation editor I was using had asked me, I would have told them that the menu interface was fine as it was. I didn’t need them to make changes to a system I already knew. Perhaps the developers have added new features or reduced the number of clicks it takes to add a YouTube video link to my presentation; I haven’t had time to go exploring in the new version yet. Whether it turns out that I like the new version better or not, the occasion did serve to remind me that when it comes to making changes to something, whether it be a document or a digital product, it’s important to keep the user’s needs first. And how do I find out what users need? I have to ask them—again and again—until I get it right.

–Bonnie Winstel

Snorkeling with David Foster Wallace

Published October 19, 2012 Definitions 1 Comment
Tags: , , ,

David Foster Wallace  spent much of his life trying to pinpoint the purpose of fiction, the role of the writer, and the sometimes tumultuous dynamic between self and artist, three searches that proved so vital to his existence yet so futile that he, also utterly debilitated by profound depression, ultimately hanged himself on his back patio at the age of forty-six. To a certain extent, I can empathize with his dilemma. As a graduate student pursuing a career as a technical writer, I am often asked, “What’s a technical writer?” And as embarrassing as it may seem, I find myself fumbling responses. What exactly is a technical writer anyway? Still, in my defense, I am not alone: few, if any, seem to have a handle on this.

In my particular search for meaning, I–unlike Wallace, who would have relished the opportunity to wrap his Harvard-by-way-of-Amherst tongue around Wittgenstein and company–will refrain from delving into philosophy and theory. And in a conscious effort to spare myself linguistic vertigo, I shall also avoid the kinds of semantic somersaults set in motion by others who have offered such circuitous, tail-firmly-in-teeth definitions as “writing about technology” or “writing technically.” The most effectively practical definition, I find, might be “writing to accommodate technology to the user,” which happens to be an angle Wallace would have appreciated. After all, in a way, he envisioned his fiction doing just that. (Not to mention the warm embrace he would have had for the term user, as he perceived every member of his audience as an addict of some sort.)

In fact, I argue that Infinite Jest,   Wallace’s magnum opus, may be viewed as one of the earliest technological documents, a digital dinosaur or trilobyte, if you will. Rather than the internet, the primary source of entertainment and information for Wallace’s era was the television, his “snorkel to the universe.” The novel essentially centers around the struggle to find meaning in oneself in (and in relation to) a world saturated by media and literally inundated by information, a site where ideologies are imprinted via waves (complete with rabbit ears). In this sense, Wallace’s prescient work becomes increasingly relevant, for we are comparatively even more saturated (perhaps overly so) by media and information today. And by looking at Infinite Jest (or iJest, if I may coin a phrase) as a piece of technical writing, we can glean some semblance of a definition for the nebulous field, or at least a template of sorts for style, structure, and purpose.

Stylistically speaking, most experts agree that technical writing should be concise. Well, weighing in at a formidable 1,079 pages and wielding encyclopedic-savant range, iJest does little in that regard to advance my argument. Another stylistic element common to the TechComm consensus, however, is explicitness (“to convey one meaning and only one meaning”), and Wallace readily falls in line here. At least in theory, for iJest, Wallace set out with “single-entendre” principles in mind, positing that such an unambiguous approach is imperative if one wishes to “effect any kind of emotional communication with people.” Having recently fallen out of love with postmodernism, namely Pynchon’s satire and Barth’s metafiction, Wallace believed he owed his readers unequivocal truths, and in his mind, he definitively delivered.

One of Wallace’s structural trademarks happened to be punctuating his works with copious endnotes. iJest, for example, boasts almost a hundred pages solely devoted to them. While it may be accurate that the agenda here was to avoid his editor’s recommended (user-friendly) cuts, a clever technique allowing this information hoarder to zip his many asides into a much smaller font tucked neatly away at the less conspicuous end of the tome, these endnotes, in a sense, engender a nearly digital appeal. Are they not, by their nature, simple forerunners for hyperlinks? For more information on this topic, click here. And sprinkled throughout, furthermore, are images, even complex mathematical formulae and graphs. Does this not constitute multimedia? Cyberjunkies might assert this is the equivalent of playing Pong, but I don’t think it’s too great a stretch to envision Wallace, short a youtube clip and/or a Facebook like, running literary BlackOps Live back in the mid-90s, oversized (of course) headphones huddled around his token white bandana. In short, he was well ahead of his time. He may as well have arrived at readings in a tricked-out DeLorean.

And finally, the intended purpose of iJest brings us back to the most functionally acceptable definition of technical communication: “writing to accommodate technology to the user.” Wallace, having himself overdosed on television, knew all too well the reader/user’s addiction to media and information, but more importantly, he felt he could convey (through iJest)  the ramifications of this particular societal dependency. This is what to make of your addiction, dear user. A lifetime fan of the whole recovery process–indeed, he seemed to walk through life twelve steps at a time–he deemed it his duty to play sponsor and thereby raise awareness, to facilitate a degree of reconciliation with our dependency on technology, and to have us hold ourselves accountable for our addiction. For the most part, he did that. The problem is, he failed to provide a cure, any tablet or gelcap of redemption. His Help page ultimately turned up blank. But perhaps that was due to his inability to find any relief for himself.

Hi, my name is Cody, and I have an iPhone. 

–Cody Roy

 

 

 

 

 

 

 

What is a Technical Writer? Video

Published August 19, 2011 Definitions Leave a Comment
Tags: , ,

Check out this short video defining the work of a technical writer. The video is interesting because it defines breaking down everyday subjects into steps as one domain of technical writers – in this example, Weddings for Dummies is an example of technical writing. (See Jo Ann Allen’s The Case Against Defining Technical Writing for a similar debate about whether cookbooks constitute technical writing). Watch the video and see what you think:

Archives