tdog.blog

1. Our clients have forgotten more about their businesses then we’ll ever know.
2. The universe of possibilities is endless–but if we work together, we can dial things down to a short list of possibles.
3. Better a series of small wins than a moon shot that goes horribly wrong.
4. Clients won’t understand it until they see it–so prototype!
5. Good process and good software only gets you so far–you gotta leave room for the human spirit.
6. Great ideas are all around us–but executing on them takes discipline, guts, and vision.
7. Creativity isn’t just about filling an empty void with new things, it can also be about transforming, improving, or streamlining what exists.
8. Sell the prospect, and you make one sale. Educate and empower the prospect, make a client for life.
9. Technology should always bow before the needs of the business, not the other way around.
10. Never push solutions–figure out what the problem is first.
11. A picture might be worth a thousand words, but if you’re a building a B2B web site, words almost always win.
12. Gunny Highway’s credo: Adapt. Improvise. Overcome.

Comments(0)

We recently took the same software and approach that we used to survey the Fortune 1000 and turned our attention on the Fortune Small Business 100. These folks, from Taser to Miva and Saucony, represent some of the fastest growing companies under $200 million in annual revenue.

We ran our spiders against the 100 web sites and were able to successfully connect with 94 of them. We mapped out each site to count pages and figure out how many pages were unreachable (404) and how many pages hadn’t been updated in over 30 days. Then we started to dial up these companies so they could answer a few questions about their web sites. This last part is taking a bit longer than I anticipated, but so far the answers we’ve gotten paint a clear picture of the marketplace.

But first, here are the numbers:

*4 of these sites had 5000 or more pages!

The first thing to note is a distinct similarity between this data spread and the one resulting from our analysis of the Fortune 1000. Just as with the Fortune 1000, we saw plenty of clumping near the bottom of the size range, a steady dropping off in page counts, then a sudden uptick at around 1000 pages.

When we looked closer, we saw no correlation between Web page size and number of employees or revenues, nor did we see any correlation between how well a Web site is run and number of employees/revenue. There were very large companies that ran small and large Web sites, some with as few as 1% bad links, some with 80% or more bad links. And the reverse is also true–very small companies with either well- or poorly-maintained Web sites.

Also note that in almost every single category, the problem with staleness is bigger than the problem with 404s (although in at least 2 categories–the smallest, ironically–they each present themselves as problems).

Then we hit the phones and started surveying these customers. We reached an average of 1 in 3, and so far we’re only about halfway through, but the answers we’re getting are also very enlightening.

The fact that virtually every single respondent said they were outsourcing their Web sites is an unsurprising development; the fact that many of these web sites had problems with 404s and stale content is something of a surprise. I also found it surprising that so many companies are still running static Web sites. In a world where a dynamic site can offer so much to an organization (not just ease of publishing, but ease of gathering customer data), static sites become to me artifacts of a bygone age.

As we continue to finish up our phone survey, we’ll keep updating this post.

Comments(0)

Customer: Symbol Technologies
Problem: FG SQUARED needed a CMS tool for Symbol.
Solution: We created an XML-powered publishing machine.
URL: http://www.symbol.com

Symbol’s web presence at the end of 2004 was enormous. When we first started talking about the scope of the project with FG SQUARED, we ran our spiders on the site and found it to contain at least 8000 content items. And www.symbol.com was only one of various Web sites comprising a whole range of online properties.

Symbol needed to get control of their content. Not everything up on the site still needed to be there, and not everything had been posted with complete authority or oversight by someone in charge. In fact, it was sometimes hard to say who had the final say on what went where on the site.

While FG SQUARED took on the epic task of gathering, prioritizing, and categorizing thousands of content items and working with 40+ stakeholders, the Triple Dogs got busy putting together a system that would stand up to very specific content publishing requirements.

• They needed to define their own content as they went. Today there may be white papers, case studies, and webinars to publish, but tomorrow they may need specialized press releases or support patches.
• They had a variety of content authors scattered across the organization, and not all of them had the privilege to do everything on the site.
• They needed a way to categorize all content inside a taxonomy.
• They needed a preview site and some kind of scheduling mechanism.
• They needed site caching for performance.
• They needed a search engine.
• At some point in the future they needed to integrate all of this content with their other Web properties.
• They needed to revamp the business logic that drove lead generation.
• Because they were a global company, they needed to support as many languages and locales as possible.

The core of our system was a three-part framework: taxonomy manager, which allowed us to create arbitrary category hierarchies to which we could assign any content; a content type manager which allowed content administrators to define content types as they needed them; an XSLT manager that allowed content administrators to assign custom look and feel to any content type.

We felt that of all the pieces of the core framework, the content type manager was the most innovative. By using a simple system of tags saved in an XML file, content administrators could mix and match different components (like headlines, dates, paragraphs, lists, etc) into sections, then mix and match sections into larger content types. Sections and tags could be reused, resulting in the ability to create, for instance, not only a white paper, but a white paper for the German market, or specialty press releases by industry.

To hold everything together, we devised a system of global metadata that was included in every node of the taxonomy and every content item. We were able to track language, locale, title, teaser, launch date, expiration date and other important pieces of information. The system thus had the flexibility of custom metadata held together by a core group of universal metadata.

The XSLT manager allowed content administrators to take these taxonomy and content items and apply the kind of look and feel they needed for a particular context.

Other tools then followed: user administration, scheduler, cache manager, user sandboxes and preview site, and more. UTF-8 support on all admin and display pages was instated from the beginning.

We wrote the tool with PHP 5 and XML, but we found that we needed to incorporate other technologies for performance. Site caching was added to generate flat files after any XSLT or PHP processing. A mySQL database was added to power the search engine and the scheduler, as it was a lot faster than repeated calls to XML files. Both mySQL and Apache caching were put in place to further speed up the site’s performance.

Along the way, we also assisted FG SQUARED by writing dozens of Perl scripts to help munge spreadsheets full of content into working XML. Because the content was in XML, we could also write other Perl scripts to make global changes very quickly across the entire content base.

The new symbol.com was launched in late July 2005. It contained approximately 4500 content items. We trained Symbol’s marketing staff and webmaster on the new system, and continued supporting the site with new upgrades until September 2005.

Comments(0)

The fine folks at businesslogs.com have created a very fine white paper on writing effectively for the Web. Please download it, it’s free. Read it a couple of times. Have a few martinis or margaritas or what have you. Then read it a few more times. Please follow the advice, it’s excellent.

Grab the Whitepaper

Here’s a sampler, on content & style:

…the style we promote to our customers is to write openly, and with personality…

And another one that I really agree with:

We’ve seen a lot of sites that look absolutely amazing, but lack amazing content.

Comments(0)

Dear Web Designer.

I am not a designer. I am a software developer. I’ve spent 10 years working in the mad world of Web this and that, and I don’t pretend to know the first thing about good design. However, I know a thing or two about usability, and a little bit about accessibility, and a little bit about how search engine spiders work, and I know a great deal about both writing and online information retrieval. And, of course, I know how to program in PHP, Perl, and other languages; and how to “code” in HTML.

I’ve learned a few things in the past 10 years about working with designers, which I’ll summarize thus:

1. You’re all very passionate about aesthetics–and I respect that.
2. Hardly any of you know HTML or other Web technologies–and I understand that.
3. An overwhelming majority of you first learned your craft in the world of print, and you don’t realize how different the world of Web is to that.
4. The client suffers because of it.

When I first noticed the gap between what designers were creating and what we were able to produce (and explain to everyone why the Photoshop file didn’t look exactly like their finished web site) I tried to understand what was going on. Was it our HTML production staff? Nope, they were pretty experienced. Was it the designs? No, they were effective design pieces–but they were effective in a print context. Or a static web site context. Take those same designs and skin a dynamic site with them, and it would end up breaking.

Why? At first I wasn’t able to put my thoughts into words, mostly because I lacked the vocabulary. I couldn’t sling the lingo with designers like I could with my developers, and therefore there was no way for me to put together a hit list of what I thought was going on. It’s not an issue of totally wrong or totally right, mind you–it’s always more like, “Can you adjust this over a bit and take off those rounded corners? Thanks.”

So I went looking for a way to talk design. And I found a nice pair of articles at Digital Web written by Joshua David McClurg-Genevese. The first article is The Principles of Design. The second is The Elements of Design.

What I would like to do in this blog post is follow each article, responding point by point to the author’s outline (Balance, Rhythm, Proportion, Dominance, Unity) and examine how they relate to a dynamic web application. I’ll also examine how these design principles weigh against such issues as web content usability, SEO, XHTML standards, and accessibility (woohooo!).

The goal here is to communicate. It is not to excoriate, accuse, discipline, staple, spindle or mutiliate. I hope that its taken in the spirit it is given.

1. Balance

Approximate horizontal symmetry is always best for a dynamic web app. Perfect symmetry gets, er, boring, because it just has no punch. Approximate symmetry gives us an opportunity to showcase featured stories or provide sidebars, etc.

Radial symmetry can work only if the design is some kind of background that sits under everything else. This will impact performance, and in an accessible design, is pretty much useless and can be a bit disturbing for those with cognitive impairments. It can also distract from the primary purpose of a dynamic site—which is to flow content (and lots of it) to the reader.

Asymmetry is a bitch to handle and isn’t conducive to most dynamic apps, because most of them are information heavy.

2. Rhythm

As regular as you can make it, please. It’s the wacky stuff like swirls, rounded corners, etc that add days to the effort. Wait until most browsers support CSS2, and then we’ll have built in capabilities to handle fractal patterns and whatnot. But then I still won’t do it in accessible environments—pointless for the blind folks and very distracting to those with cognitive impairments.

3. Proportion

Doesn’t seem to matter, but again take into account that most dynamic apps handle lots of user information requests. Perhaps the best use of proportion is by using bolding, color, highlighting, line chopping and other content chunking strategies to maximize web content usability.

4. Dominance

Aha. Excellent. Primary dominance in any web app is the CONTENT, usually written but sometimes visual. Secondary dominance is search/navigation elements. Tertiary dominance is pretty much everything else. Anything we can do to showcase the content and the way it is organized and the nav and its position/role on the site will work wonders for us.

This is true for sighted viewers, search engine spiders, and accessibility screen readers. (Which is why, by the way, we use CSS because we can place our navigation div at the top of our HTML file but use absolute positioning to put it further down on the display—the screen reader and spiders see it right away!)

5. Unity

Hmmmm. Gestalt theory. Takes me back to those horrible psychology in lit classes at SUNY-Binghamton.

• Closure is a very powerful design element that never gets old. We use it on the content side, too, but kind of in reverse, with the use of teasers and titles that draw the reader deeper and deeper into the site. The goal of any good web app is to drive deep linking. Which is why we spend so much time and effort creating modules to drive related content that has nothing to do with the primary navigation structure.
• Continuance. How does the eye track information on a web page? Think of the z-pattern evinced from years of studying newspaper readers. They start at the left, looking for a branding logo, go across to see what kind of navigation and search choices they have, stopping at the right edge of the screen. Then they jump down to the main content area scanning for interesting headlines and images. They normally don’t read for depth, they scan and look for things to come back to later. Once they’ve run out of interesting things and before they start scrolling down, they jump to the left nav to see what other choices they may have. Finally, they scroll down below the fold to see what else is on the site that might be useful.
• Similarity/Proximity/Alignment. Strong alignment tends to work the best, particularly in quadrilateral zones (squares/rectangles). Its okay to group like things together, this helps create cognitive cohesiveness, but we have to have some kind of differentiation between links and headlines, otherwise you get the experience looking for a needle in a stack of needles. Remember, there could be a jillion search results or news headlines to look through, so anything you can do with font sizes, colors, or little icons helps a lot.
• Positive/Negative space. Good web content usability calls for use of negative space to block content items away from each other, giving users room to breathe and digest the information. (Of course, we also chunk inside those text flows so they can scan to where they need to get at what they need).
• Visual center. Yes, on the screen it is very much like the visual center on a page, except the eye is more forgiving on a computer screen—eyetrack studies show that the eye spirals out from that point once it settles on the center.

Now lets move on to the second article.

• Colors. As often as possible, use web-safe colors. That’s the 216 colors that have RGB values of 00,33,66,99,CC,FF. Don’t have to do it all the time, but you’ll reach the highest audience that way. Your mocha-infused salmon pink on your mac will look like, well, pink or brown on our lowly PCs. Don’t waste your time. Color alone should never be used to indicate state change because color-blind and blind folks won’t have a clue.
• Color harmonies…hmmm. God help me if I see another dynamic site with heavy contrasting colors from the color wheel. It’s a much more pleasant experience for everyone if we stick to analogous, triadic, mutual complement, or monochromatic schemes. You see a lot of the latter in the blog community, so you can stand out by not doing so much of that. Just be aware that those with visual problems will take over your stylesheet and put in as much contrast as they possible can–usually black and white but other combinations as well. Most of which will make you scream.
• Texture—as little as possible in places where there is text or content. Deep backgrounds can have texture, but they involve images—pointless in accessible environments.
• Forms—quadrilaterals, quadrilaterals, quadrilaterals, quadrilaterals, quadrilaterals (rinse and repeat).
• Fonts. Please designate in ems or pixels, not points. Ems are better because they allow the old and poorly sighted to increase the teeny tiny nano-fonts you designers inevitably go for. By the way, its okay to be artsy with your static sites and their tiny fonts, but dynamic sites are typically information heavy—so, please give us a font size that is helpful in the conveyance of information.

Another note on fonts. Serif fonts are great for paper, but they suck suck suck online. We tend to use sans serif on info-heavy sites because they aid reading on screen. Then we use CSS to switch the printer-friendly view to your traditional serif fonts.

A Note on Chunking and Web Content Usability

Chunking – methods and tactics used by technical writers to make information more digestible. We break long flows of text into chunks, each chunk with a descriptive header, and important terms bolded or colored or italicized to bring them out. We use wide margins/gutters and even notes on the margins that help bring attention to the material. We use tables for data and infographics to show processes or illustrate our text with examples. Short line lengths offer each line of content in digestible mini-chunks (try reading a web page that has no styling and words from extreme left to extreme right margin—its tough to keep it all in your head, right?)

The goal of chunking is actually in two parts, each of which fights the other but if done right can lead to enormously pleasurable information gathering environments.

1. Keep ‘em separated. A well-chunked page will be like Tupperware—keeps the mashed potatoes out of the bean casserole.
2. Hold it all together. Again, think Tupperware. Without the lid you’d have a mess at the bottom of your lunch pail.

XHTML standards while chunking—we will NEVER EVER EVER use bolding and a special div to indicate a header on a chunk. Instead we will use a standard H1, H2, or H3 tag and then restyle it with CSS. Why? It may look the same to you and me, but to a search engine spider or screen reader for a blind person, it makes all the difference in the world. Furthermore, we prefer the use of DIVs for positioning instead of tables because it allows us to put navigation divs at the top (so accessibility readers and search engine spiders can see them right away).

Scrolling versus clicking. In a static web site, scrolling is bad and there aren’t enough web pages that clicking makes a difference. In a dynamic web site, clicking is tolerated only if the labels on the links make sense (after all, each click leads the user down a trail to the information they want) and scrolling is accepted, especially on leaf pages that contain the information they were looking for. Remember, the reader is after information and they don’t want to keep it all in their head by jumping around. Nobody minds scrolling in this context. However, the caveat is, really really long content (over 3000 words, say) should be paginated by the system. (Also lots of readers choose to print what they find on a dynamic site.)

Studies show that younger test volunteers take longer to go through heavily paginated articles, take longer to find the information they need, and retain less knowledge than their counterparts in the study who did the same test on pages that scrolled longer and had fewer page breaks. In older folks its almost the opposite—they tend to like paging through material according to a 1992 study—but this study is highly suspect since it is pre-Web and certainly pre-dynamic Web. As with everything in life, you have to have a balance: if the content is long, use fewer page breaks but certainly do everything you can to chunk the information within the pages.

Side note on effective copywriting: when I write promotional web copy, I tend to break a page not at a logical point but at some really crazy juncture, like in the middle of an anecdote or list of features, sometimes even in the middle of a sentence. Why? Because study after study shows that people have an irresistible urge to finish a task that was started. If they started a list of features, they want to finish it. They click to the next page. Keep doing that, and I get them to the order page. This is just one example of how everything we know about usability just doesn’t work in promotional environments.

Also, from an accessibility standpoint, its often easier for the person to scroll using the pagedown button than to tab around looking for a link to continue the article or piece of content. So on accessible projects, we would definitely go the scrolling route over the paging route.

Comments(0)