As much as I love King County Metro’s Trip Planner utility for figuring out what bus routes I need to take to get to a particular place, loading this site on my Blackberry and entering information is more than a little time-consuming (and I’m often doing it right before leaving for a particular destination). Thus, I’m going to create a slight hack by using my own PHP script to post parameters into the Trip Planner.
Devious? Perhaps…
It can be quite interesting to look at past work that you’ve done as a web designer, even when you don’t actually expect to run into that content. I recently discovered the Internet Archive’s Wayback Machine (yeah, I know, where have I been all these years), which allows me to bring you the following nuggets of only partially-complete archive sites. Some of this stuff does actually show more than just some broken links:
My work has definitely evolved since I created some of these sites, but it’s still interesting to look back at the progression of the work. The only exception to this was students.overlake.org, where not all the work was done by me (the later leaf logo was my work, and some other students did the main layout work for a couple of those incarnations).
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.
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.
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".
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.
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!
I have just finished the PHP code needed to put naturalaxis’ Announcements and Press Releases page online. This has been offline for quite a while, but now has all the naturalaxis newsletters that have ever gone out, including the new ones in HTML format. It will also dynamically update itself when I add in a new newsletter to the system.
And with that, back to reading James Joyce’s Ulysses.
As part of the process of signing up for a SourceForge account, you are required to write some descriptions for the project you propose to create. SourceForge asks for a short (less than 255 character) description of the project. Pixelary’s entry is below:
Pixelary is a PHP-based account management system for web site designers. Running on any web server that supports PHP, Pixelary features support ticket functionality, the ability to define multiple contacts per account, and e-mail gateway capabilities.
SourceForge also requires “detailed, accurate, English-language description of your project, including technical aspects which cause it to differ from similar, existing solutions” for their use in assessing the project — this is used internally by SourceForge, but I thought I’d post it here. They further state that the “description needs to be technical and tangible, not abstract and philosophical. Please explain what the software will do, what purpose it will serve, and the basic problem it will solve.” Pixelary’s description is as follows:
Pixelary is being implemented in PHP using a MySQL backend to manage all data. It is being coded to be as robust as possible while still serving the needs of web designers quickly and efficiently. This will be achieved by allowing clients and consultants to interact with the system via e-mail to file support tickets and update their accounts, in addition to the web-based interface. The system may also (at some point in the future) branch off some of this functionality as plugins in order to better allow customization of the software.
Pixelary is created specifically to address the goal of increasing communication with web design clients by allowing clients full access to all data associated with their account, including timesheets, support tickets, and current/past bills.
I have requested registration with SourceForge, and should hear back within two business days (by Thursday). Hopefully, I get the space, though I realize the extreme pre-alpha status of the project as a whole.