Laying out a formal table

Wednesday, July 30th, 2008

Information marching across the page by ranks and columns looks more purposeful than when it’s milling about in paragraphs. But, even with a computer, laying out a table is labor-intensive.

The layout below will provide some useful guidelines. It exemplifies a “formal” table of the kind scientists and scholars construct when they have categories-within-categories of data to deal with.

The illustration is based on the ‘best practices’ recommended by the Chicago Manual of Style, a compendium of typographic and other conventions compiled over many years and many editions by the University of Chicago Press. This table features categories within categories, both in the header (the column head “spanner”) and within the left column, which printers used to call the stub. Columns are numbered so they can be easily referenced in the text. No matter what program you use, you’re probably going to have to come up with some workarounds to get the table to look the best it can. For example, Excel doesn’t allow for footnotes.

Use Word or Excel for formal tables?


Created in Microsoft Excel, the table illustrated above is passable, typographically speaking, but not particularly elegant. Better formatting might be achievable with Microsoft Word’s table tools.

However, judging by the MS Word documents we receive from clients, most people don’t use Word’s table tools. This is probably because, with Word, you (or I, at least) can’t always get the table to do what you want it to. But you may be able to get a little more done with help from the Microsoft Word MVPs.

Filed in Information Graphics | | Permalink | Comments (0)

Remember the multimedia

Monday, July 28th, 2008

Being in the multimedia biz, I’ve often heard (and even cited) bromides like “we remember 10% of what we read, 20% of what we hear, 30% of what we see, 50% of what we see and hear.” This is totally bogus, according to this guy.

Weiss-McGrath Screen Grabbed from PowerPointThe so-called “Weiss-McGrath retention study” is referred to in one of our clients’ marketing communication materials, looking quite authoritative. It appears in a 1963 book by Harold Weiss and J.B. McGrath, Jr., Technically Speaking, Oral Communication for Engineers, Scientists, and Technical Personnel. Not readily available, I think, judging by this Amazon link. Seems like something that would have been the subject of more recent (and possibly more authoritative) studies, but I haven’t run across any. I did run across some possibly interesting citations in a discussion of forensic animation — something I’d never heard of.

Filed in Stuff we've learned on projects | | Permalink | Comments (0)

How to use fewer words

Monday, July 14th, 2008

For if the trumpet give an uncertain sound, who shall prepare himself to the battle (1 Corinthians 14:8).

In a 2-Minute Explainer, there’s time to utter about 250 words. Consequently, the rule from Strunk and White’s Elements of Style, “omit needless words” is frequently invoked here. My favorite prescription for using fewer words is from Samuel Johnson, who said you should read over your compositions carefully, and whenever you meet a passage you think is particularly fine, strike it out.

Adverbs and adjectives make good candidates for deletion. “Profitable” is an attractive word that is no more attractive accompanied by “highly”.

All of us aspire to hit triples with assertions like “our solution is powerful, scalable and compliant.” But, unless you support the assertion with evidence, it won’t have much impact — much less if you just assert it, then go on to the next subject. With actual evidence, the adjectives and adverbs will be superfluous.

Efforts to fend off potential lawsuits based on the fact that some statement may not be true always and everywhere — expressions like “generally”, “often”, “may help”, — express wishy-washyness without really clarifying anything.

Phrases that are subject to challenge are always good candidates for deletion, e.g., saying you’re the “leading provider” of whatever you provide. Better to say what makes what you provide is better than what the competition provides.

Depolysyllabification

Dickens, Hardy, and Orwell are among the great writers in English who held that English prose can be beefed up by substituting good old “Anglo Saxon” words for degenerate Latin ones: prefer the short (Old English: scort) to the sesquipedalian (Latin for “foot-and-a-half”). This notion sounds a bit jingoistic and quaint now, with nifty words being added to English daily by people all over the planet. Nonetheless, a program of reducing the number of syllables (avoiding words of nine syllables like my coinage “depolysyllabification”) makes sentences seem shorter, even if they aren’t.

Filed in re: writing | | Permalink | Comments (0)

Perl Template-Toolkit

Tuesday, June 24th, 2008

We maintain this site with Perl Template Toolkit. Depending on how you want to use it, TTK is either a souped-up templating program or a souped-down content management system. Big, dynamic, content-rich websites using it include the popular IT news site Slashdot and the BBC.

Content form codeWith templates, you can see the structure of a page, as you can’t with HTML. This is the contact page of our website. It looks simple, which it is, but it also hides a fair amount of complexity. What’s nice is you can deal with the complexity when you have to, and not look at it the rest of time.

simple blockHere’s a block that makes up part of that structure.

And here’s a more complex block that makes up part of the previous block.

not simple block

Filed in Web applications and development | | Permalink | Comments (0)

Perl Data::Table

Sunday, June 22nd, 2008

When you ask a database for information, the result of the query is a table or “rowset”. People who are good at database management write queries that slice and dice multiple tables, perform calculations on data, and format it all before it ever gets reported back.

I’m not one of the people who are good at database management, so I generally retrieve more data than I need. I slice and dice it with Perl Data::Table.

Once you’ve connected to the database server, Data::Table, can run your query for you:

$sql = qq/SELECT * FROM Persons WHERE Gender="F"/ ;
$t   = Data::Table::fromSQL($dbh, $sql); # $dbh = DB handler

With the resulting data structure, you can:

  • sort on any column
  • print HTML
  • add or delete rows and columns
  • rename, reorder, swap columns
  • extract a subtable by matching cells to a formula
    (e.g., “DOB”>1978)
  • extract a subtable by matching a string (regexp)
  • clone the table
  • run a subroutine on every item in a column
  • run a subroutine on every row (e.g., put (cell6 + cell5) into cell8)
  • merge rows and cells into new tables
  • treat every row as a Perl array (indexed list) or a Perl hash (key-value pairs)

It seems particularly good at dealing with tab-delimited text files exported from Excel.

Data::Table was written by Yingyao Zhou and Guangzhou Zou. You can find it on CPAN.

Filed in Web applications and development | | Permalink | Comments (0)