Category: Uncategorized

The Importance of Copyediting

It may be interesting to see a headline for a $5 civil lawsuit, but upon closer inspection, it’s clear that this is actually a $5 million dollar lawsuit regarding the wrongful death of a prominent political leader. Normally, this would not be something I would bother to highlight on my blog, except for the fact that the topic really has nothing to do with what this triggered in my head: what does it mean when people are so quick to get things out the door that they fail to completely proof their documents?

There’s really two ways for me to approach this question: as a web site designer and as a writing tutor. Really, the answer here is much the same, but the perspectives on the issue are different.

Commentary from Both Roles: Being hurried in your writing is never a good thing, whether that’s for the web or for any other purpose (professional, academic, and so forth). Grammatical mistakes have cost people lots of time and money (and, in some cases, jobs), and factual mistakes can almost be far worse. In today’s world, though, it’s highly acceptable to shove out content before it’s anywhere near ready for public consumption. The New York Times used to (and still does occasionally) publish articles on their web site rife with grammatical errors and signs of bad copyediting.

This is a cultural phenomenon and a symptom of our high-paced society where, if we don’t get instant gratification, we’ll go elsewhere. The ones that win at the professional game of copyediting chess are those that are careful and don’t put information out there until it’s polished to a soft sheen.

Web Designer/Developer: This can be death to a web site depending upon whether it’s a major site (like our ongoing example of the New York Times) or a small one, such as the ones maintained by many of my past and current clients. There is, of course, a range of copyediting: the completely rough draft to the obviously polished, well-articulated statement. But carelessness when your web site shines in other places can really stick out like a sore thumb. Making sure that the text you put online is free of grammatical errors is to your benefit, since it not only strengthens your message, but also ensures that the reader keeps reading.

That said, please don’t forget to copyedit not only text, but images. I’ve seen many an image on the Web where it’s a beautiful piece of work, but its beauty is completely marred by one glaring grammatical error that should have been corrected before the image was completed.

Writing Tutor: I see a lot of students come in with grammatical errors (in fact, in my three years of working at the Writing Center, I’ve only ever had one paper come in the door that was literally perfect and needed absolutely no changes whatsoever). Since this is an academic environment, those grammatical errors don’t matter so much and don’t have as much of an impact on life. It is to the benefit of these students to understand how to properly use commas, dependent clauses, and modifiers, but it’s rarely as important that all the details be absolutely perfect before a paper is handed in. This is a very different approach to copyediting than in the professional world. This is a learning environment, so you are expected to learn something about how to properly write a paper, which includes grammar.

Yet, still, grammar is one of those things that literally nobody gets right 100% of the time. Especially in English, there are niggling, obscure grammatical rules that only apply a very small percentage of the time that can come back and bite you later (assuming that someone who actually knows that rule notices the error and points it out). That doesn’t mean you should throw up your hands and scream out to the Heavens for mercy on your poor, grammar-impaired soul; in all these situations, it merely means being cautious and observant about how a document is written. The example of the image I linked to above was an obvious, glaring error that could have been fixed if they had bothered to read their headlines before they hit the “Submit” button. Copyediting is as important as ever, and it’s important to remember this.

Ruminations on Separating Work and Work

It’s been a long, hectic quarter this time around – I’m not complaining when I say that, though I admit that there are some aspects of this class that make me wonder why I’m bothering with it. The bulk of my work is being focused upon our yearlong project, which, for me, consists of creating a new appointment system for the Writing Center.

Creating an application for a place that you yourself work is an interesting experience because it requires two hats. The first is the hat of the know-it-all business user: the one who knows how things are typically run, knows that certain procedures are executed in order A and not order B, that certain business rules are never enforced properly, that certain parts of our work are highly dependent upon the smooth operation of one part of the Center, and so on and so forth. The second is the hat of the non-expert applications developer: the one who questions every business rule and tests for its validity, the one that, when faced with a choice between efficiency and practicality, is forced to consult with the client to get their opinions properly registered, the one who needs to maintain some distance in order to keep an objective view of the work involved.

The whole “two hats” thing is both beneficial and a curse. It means that I can quickly answer business questions posed by my project partner (who is in no way connected to the Center and is the blissfully oblivious, inquisitive half of this team), but it also means that I always must be certain that the answers I give are framed in such a way that they are reflective of the operations of the Center rather than my opinion, whether that is an opinion of how the Center does or should operate. It means that clarifying logistics with our project sponsor is much easier because I work for her and can translate into her language, but it denies me the objectivity that my project partner has.

Frankly, it also means that I must be extremely careful not to let the wires cross, for fear that it will compromise my ability to effectively work in either environment; yet, for whatever reason, that has been unavoidable. Even if I’m not working on the system, I’m working on the system – in my head, I’m processing what goes on in terms of appointment scheduling and considering logistics. But here again, I must be careful: my visualization of what goes on and the snippets that I catch are not necessarily reflective of reality. I sit on the periphery of the appointment scheduling process that goes on daily because I am unable to participate in it – my hearing impairment bars me from effectively fulfilling a vital part of that duty.

So, in our process of peppering people with questions, convening focus groups, meeting weekly with both project sponsors and program faculty, I find myself now listless. It’s as if I have all the information in front of me, but because of the sheer concentration of the last several weeks, that information has transformed itself into a language I can no longer understand. I have not lost momentum; instead, I have lost my ability to sequentially address issues as they arise. It is not that I will simply stop. We are at the point where we cannot stop – we are close to a first-cut implementation of this program, and stopping now would mean severe delays further along.

How do you navigate with a foreign map in familiar territory? Intuition and memory. That’s what I must now rely on.

Seminar Summary of Classic ACM Papers: Part II

Here is another of my seminar summaries from Student Originated Software on one of the classic ACM papers we have been reading.

As with my last summary post, please don’t bother stealing this.  It’s immoral, unethical, and usually just plain rotten.  If you don’t understand the paper but you are required to turn a summary in, you need to read the paper carefully – this summary comes straight from the paper text, as with the summary posted in Part I.

PARNAS, ON THE CRITERIA TO BE USED IN DECOMPOSING SYSTEMS INTO MODULES

Parnas utilizes the example of a KWIC system to demonstrate how programs can be constructed by utilizing a series of different modules. By way of this example, he demonstrates how different modularizations yield different results in the level of information hiding available. He suggests criteria that might be used to properly construct these modules in order to ensure that modules may be developed independently of one another. He claims that the managerial and development time should be drastically reduced and that it should drastically increase the comprehensibility of the program for coders.

Parnas explicitly defines a module as a “responsibility assignment” rather than a subprogram, which may actually limit his argument. In larger programs, subprograms could in fact be fully modularized via responsibility assignments controlled by a master module called by the remainder of the program – the level of decomposition he discusses here can be more widely applied than is implied by the remainder of the paper. He creates two different modularizations for a KWIC index system: the first is based upon the stages the program steps through, the second is based upon discrete units of functionality. The first modularization utilizes five modules: input (reading in data), circular shift (finding the location of each circular shift), alphabetizing (alphabetizes the shifts), output (prints the shifts), and the master control module, which controls the operation of the program. This first module, Parnas argues, is the approach that would be used by most coders in creating a modularized system.

The second modularization utilizes six modules: line storage (responsible for the management of information regarding circular shifts), input (reads in from the input media), circular shifter (manages anything to do with shifts), alphabetizer (manages the alphabetical ordering of shifts), output (prints circular shifts), and master control (same function as the previous modularization). Parnas then begins to compare the benefits and drawbacks of each modularization. Both modularizations ease the ability to program each section individually, but only the second appropriately hides information so that the other modules do not need to rely on or replicate knowledge provided by other modules. After assembly, each module could be analytically identical, but the second module has more potential to be developed in an inefficient manner due to the information hiding available in this approach. Parnas also extensively discusses the changeability of each module and areas that could be modified and the impact that such changes may have on the programming of each module. Parnas is also concerned about the comprehensibility of code.

He proceeds to give an analysis of the impact of changing a particular portion of the design on both modules, isolating the circular shift algorithms. He gives examples of advisable decompositions for the system: creating data structures as a single module, pairing routines with their calling instructions is a single module, control structures are a single module, and information about the inputs are a single module.He also discusses the difference between hierarchical structures and modularization. He states that having a partial ordering of modules that allows different modules to use lower-level functionality and stand alone is beneficial; higher levels can be pruned to create a new program with the same base functionality.Thus, he concludes, a combination of modularization and hierarchical ordering can be greatly beneficial to a program.

In his conclusion, Parnas disdains directly correlating program modules with steps in a flowchart, instead urging the usage of a list of design decisions that could change and to press for information hiding whenever possible.

Agh, Technical Support!

I hate dealing with tech support people, over the phone or otherwise (though I have problems with the phone in general). At least part of this is because I am tech support, to a certain extent – my client work requires me to play that role (and, sort of offhand, so does my job in Evergreen’s Writing Center). So any example I can find that aptly illustrates just how stupid tech support people can be is just further proof to the whole situation.

Case in point. I’ve heard dumb stories from both the customer and the support technician’s perspective, but that one quite possibly takes the cake. My previous discussion regarding our experiences with Comcast not withstanding, this one’s pretty bad.

Seminar Summary of Classic ACM Papers: Part I

Student Originated Software, my yearlong software development program at Evergreen, requires us to write a weekly summary of the reading assignment for that week. I thought I might share some of these summaries, as well as links to the papers themselves.

I shouldn’t have to say this, but in this day and age, better safe than sorry – plagarism is a very bad thing. As a writing tutor, I condemn it, and if you steal my summary and pass it off as your own, then you are likely in violation of some sort of ethics code (more than likely academic, but possibly professional). Save yourself the trouble – don’t do it. If you need to steal a summary instead of reading the paper, perhaps you’re in the wrong place in life.

WIRTH, PROGRAM DEVELOPMENT BY STEPWISE REFINEMENT

Programming, according to Wirth, is too often taught in the abstract; rather than providing specific, concrete examples for students to follow and build on, students are crammed with abstract facts and information about a language, rather than focusing exclusively on methods of design and construction in the context of those languages. Thus, Wirth puts forth a problem by which to construct an ongoing example of how to design a program. The Eight Queens problem states that eight queens must be placed on an 8×8 chessboard in such a way that no one queen endangers the others. Wirth puts forth that the best way to develop a solution to this problem is, first, to develop an appropriately abstract notation in which to discuss the program’s development and evolution. He first posits an approach that is essentially “brute force”; try every possible combination until generating an acceptable result by examining every possibility in the problem domain. The issue with this solution is that it takes seven hours to come up with a single solution, much less multiple possible board layouts!

Wirth’s second solution is to generate two subset predicates from the overall result. Thus, the join of those two subsets yields the full domain of problem results. Through preselection, he reduces the problem to only a 100-second execution time. However, this second result isn’t beneficial either; rather than taking 2^32 tries to find solutions, this algorithm takes 2^24, an improvement of 0.003% – negligible! Wirth then proceeds with a third, far more elegant solution: treat each column on the board individually. As a queen is placed, she invalidates certain positions on the board: no queen may be placed on the same column, the same /-diagonal, or the same -diagonal. Since queens are being placed sequentially left to right on the board, you are only ever dealing with N queens in the Nth step. Therefore, place a single queen on the board; as that queen is placed, track in three arrays the diagonals and columns where other queens may no longer be placed according to a set of coordinates. If necessary, be able to backtrack from a particular solution so that all possible solutions within the problem domain are tested. Under this algorithm, the full solution set is found within 15 minutes.

Wirth then steps through the development of the code behind each of the possible solutions, showing how each step in generating the code is merely a refinement of the previous possible solution; he does so by developing a series of primitive operations and refining their definition step-by-step. By defining these instructions in the abstract and waiting until the last possible second to assert data representation, Wirth is able to create a solution that utilizes the same functionality in slightly different ways.

Wirth concludes that the best way for programs to be designed is through stepwise refinement which waits until the last possible step to determine data representation and to commit to a particular structure. This is the only way to do careful programming that yields a clean and efficient result.

The Importance of Good (Visual) Design

A study done recently on the reactions of web surfers to web pages reveals that visitors decide whether a site is worth looking at or not within milliseconds of seeing the page load. This, of course, is only a component of whether visitors decide to stay on a particular web site. Load times and quality of content still matter, but this is a suitable red flag to web designers, web developers, and graphics designers alike: visuals matter more than you might think.

It’s a little astounding that it took so long for this fact to come to light. It’s well-known in the Web world that you have somewhere around 5 seconds to grab a user’s attention once they arrive on a page, and this discovery doesn’t change that. Certainly, it’s possible for a page to be so monstrously hideous that a user must immediately cringe and recoil; we’ve known that too. Intuitively, we’ve also known that something that doesn’t look clean or professionally done is less likely to sell and be convincing than something that has a great deal of monetary investment and thought. From the physical marketing world, all this is one great big "well, duh"; the realization that visuals control not only impact but level of interest is something that has held in print media for a very long time.

So why does this come as news to web designers?

It indicates an evolution of the web. Whereas before, where we were merely concerned with the code, making valid and correct HTML that is readable across all browsers; where we prized content just as much as design; where we were sometimes more interested in simply providing the information quickly over the quality of the presentation; now, we have a kick upside the head. Again, "well, duh" – or is it? What does this have to say for beginning web designers just stepping into the world of online design? For that matter, what does it tell people like me who are good at layout, content management, and backend programming, but are absolutely clueless when it comes to graphics?

My personal lesson from this is a validation of my personal design philosophy: simple and clean. The key is to strike a balance between appropriate visuals and the information presented. Sometimes, this can mean very minimalistic approaches (I give the Teen Tutoring Project as one of my personal design examples). On the other hand, this can mean something very straightforward, but imbued with a subtle message that is hidden within the layout and design itself. That philosophy has held across all my clients. I tend to match with clients that share this philosophy, but that’s another article.

In the long run, having this information can only be beneficial, but we have to decide whether this is simply one more fact to intimidate web designers into using flashier technologies (no pun intended) or whether this is a broader lesson: one of balance and a warning not to oversell the message through visual impact.

To me, that’s not just another "well, duh".

Influencing Google’s AdSense

The New York Times today has an article on its web site entitled "Google’s Shadow Payroll Is Not Such a Secret Anymore".

This is an interesting article because it does discuss AdSense and how people have used the system as a profit resource on forums. The article also speaks more widely to the success of the AdSense program and how that program has grown with the introduction of more fine-grained target advertising.

One area of concern, Mr. Hogan said, was whether the forum’s participants would skew their postings to earn more money. For instance, since advertisers in certain categories, like sexual-performance drugs, pay much more to place their ads on Google and its affiliated sites, you might expect technology discussions to randomly veer in that direction.

“But that hasn’t happened, thankfully,” Mr. Hogan said. “Probably because there isn’t that much revenue in it for them.”

This raises a very interesting point, in my opinion – AdSense is marketed to be somewhat inconspicuous so as not to detract from the content on the site (and, I would say, achieves this fairly well). Certainly, the success of AdSense is driven by pure numbers – like most ad programs, they likely count only unique hits to site rather than total hits. But what happens when (or if) someone attempts to influence the direction that advertising goes by creating content so specific that AdSense can’t help but pick up on it?

This is a philosophical as well as an ethical question. Philosophically, it would make some sense to create this sort of targeting, since you would be drawing keywords from the AdSense network that you might not otherwise see on the site – whether this equates to higher revenue or not remains to be seen, especially since the commenter in the article seems to indicate that this is unlikely. You might also end up recreating your audience for the site entirely as an unintended side effect. But is this ethical? Strictly speaking, this could be construed as a violation of Google’s AdSense Terms of Service. Candidates for such infractions could include subsection 2, under “General”:

You agree not to display on the same Web page in connection with which any Ad Unit, Ad, Link, Search Box, or Referral Button is displayed (a “Serviced Page”) any advertisement(s) that an end user of Your Site(s) would reasonably confuse with a Google advertisement or otherwise associate with Google. If You have elected to receive content or Site-based Ads, You further agree not to display on any Serviced Page any non-Google content-targeted advertisement(s).

This is where it gets a little iffy – it could be said that, by attempting to influence the results of an AdSense advertisement by creating your own content, you are in fact creating something that could be “reasonably confuse[d] with a Google advertisement or otherwise associate[d] with Google”. More than likely, there are other sections of that Terms of Service that might directly be relevant to such an issue.

There is a social stigma, however, that is attached to trying to bypass or subjugate computing systems, so the social norm of most bloggers and forum posters on the Web would heavily steer the group away from this through the power of group dynamics. But the question remains, whether academic or otherwise. Whether there is a final answer to this has yet to be seen.

Further Excerpts from The Spam Bible

In the spirit of this old blog post, I bring you further excerpts from the Spammer’s Bible:

And the e-mail clients were ripe for picking, and they said to Us, “Advertise at a minimum cost! Make us distrust marketing entirely and sell us our Viagra!”

Overlooked was the fact that Viagra did not yet exist on yon Earth.

Those first billion e-mail transactions in thy faithful language of binary – 10010001 – blessed us holy and netted us one cent.

Thus spake the original spammers: SmallCap! Re-finance! Loww ratess! Skyrocket!

I have written of spam before, and it seems appropriate again now.

The Proper Care and Feeding of the In-House Graphic/Web Designer

My good friend Jeff Fisher somehow time-leaped into the future and posted The proper care and feeding of the in-house graphic designer. He has an excellent start, but I’d suggest a few contributions:

11. Ask Questions.

Many times, miscommunication about a project stems from the designer and her client speaking two different languages. Don’t be afraid to ask your designer how they came up with the ideas they did based upon the result you receive. As long as you are open and receptive, there is no reason why a conversation about the final result won’t result in better work later on (and a better understanding of your designer’s abilities).

12. Be Specific.

Closely related to numbers 5 and 7, if you have specific criteria for a project, state them as clearly and openly as you can. All the information in the world won’t make a difference if you wanted apples and got oranges.

13. Learn About You (From a Design Perspective)

Let’s face it – getting people to talk about themselves or their work can lead to a gold mine of information and better interpersonal relationships. Get your designer to talk to you once in a while about the trends she sees in your industry, the kinds of things that she thinks can be improved about your work, and pretty much anything else. An excellent relationship with your designer now pays back in spades later.

Further Thoughts

Sometimes the sad reality of lists like this is that designers have to "train" people to think this way. Beware – such activity may indicate that your designer will be leaving before you know it! Designers like to be in places where they fit in, are provided plenty of nourishment, and are, in general, proud of the work they do and proud of their company.

Something I tell people who are considering hiring a designer is to shop around a bit for a best fit. A designer who is thoughtful and intuitive but often quiet won’t do well in a company full of loud, boisterous employees. Consider not only portfolio work but how that designer interacts with her environment. Following all these recipes should make for a happy experience for all involved!