Note to self: functions of social networking

Christina Wodtke recently posted some presentation slides, two of which describe the “Webb/Butterfield/Smith Model” of social network functions, as follows:

1. Identity
   • Profile
   • Connections
2. Presence
   • Availability of profile via search
   • Network design encouraging frequent updates
3. Relationships
   • Friends
   • Degrees of separation
4. Reputation
   • Recommendations
   • Positive moderation
5. Groups
   • Common interests
   • Signalling acquaintance but not friendship
6. Conversations
   • Comments
   • Forum posts
7. Sharing
   • Broadcasting talent
   • Creating resources

I’m posting this model because of its value in demarcating the areas of social network and application design — any successful network or application needs to do an extraordinary job of simplifying at least one leg of the model.

For the sake of focus, I reiterate that social networking fulfills the following objectives for those who engage in it:

• Formation of new relationships
• Maintenance and reinforcement of existing relationships, particularly those hindered by geographical or time constraints
• Conduct of asynchronous conversations
• Reputation/image management
• Contribution of capital to the “gift economy”
• Measurement and/or development of support for specific social/political/professional/business goals

Not all networks need to fulfill all goals.

How many tags can I name?

A quickie online HTML tag quiz has been making the rounds. I got about half of the tags on the first pass, and almost three-quarters on the second — while forgetting many of the elements I listed during the first pass.

For guys like me challenges like this verge in some respects towards irrelevance, because…

When you’re using CSS for your presentation layer, you don’t need that many elements in your markup

Solid knowledge of CSS obviates a lot of elements, leaving the producer with only a few that are essential:

1. Document structure: html, head, title, and body
2. Document metadata: link and script
3. Headings: h1…h6
4. Containers: div, span, and p
5. Lists: ol, ul, dl, li, dt, and dd
6. Links: a
7. Emphasis and de-emphasis: em, strong, big, and small
8. Forms: form, input, select, option, and textarea

To that producers working on diverse projects might add a few more:

9. Images: img
10. Plug-in content: object and param
11. Quotes and sources: blockquote, q, and cite
12. Data tables: table, tr, th, td, and col

Once you open the book of document usability and cross-media accessibility, things start to telescope a bit:

13. Parent element metadata: legend and caption
14. Form control helpers: fieldset, label, and optgroup
15. Table containers: thead, tbody, and tfoot
16. Acronyms and abbreviations: acronym and abbr

…These three lists comprise 50 of the 91 elements officially supported in HTML 4, and the core of the namespace occupies only a third of the total.

What I omitted altogether, and why

• base and style

  You only truly need these elements if the behavior of your publishing platform encourages or requires it.

• applet

  The inline-Java train left the station in 1998, boys and girls.

What I relegated to the secondary lists, and why

• img

  A picture may be worth a thousand words, but it’s been my experience that on most sites, images rarely comprise principal content. Getting full mileage out of the CSS background attributes is often more structurally/semantically appropriate.

• legend and caption

  If you’re on top of your editorial game, these roles are often (though not always) handled by headings.

• fieldset

  This is too easily abused … hell, even I abuse it because there’s no easy way to sequester label-control pairs. I’m not convinced that the design oversight doesn’t make div equally applicable.

• label

  Have you ever noticed that this element is only truly useful if you have a pointer input device? Yeah, me too.

• optgroup

  Though not actually obscure, the scope of this element is limited to situations in which the best alternative would be to use empty options as separators.

• Table containers

  As currently implemented, these acquire their greatest usefulness in paginated media — so using them is simply a signal that you’re really on top of your cross-media accessibility game.

• acronym and abbr

  Between their relative obscurity, their uneven implementation across user agents, and their limited scope, these really cannot be considered part of a core toolset.

The point to this dissertation (other than the fact that I’ve often thought of prettifying it and submitting that prettified version to A List Apart) is that… folks, HTML ain’t rocket science, folks. At least, not by itself.

Thence the Email Standards Project?

Over the past 24 hours everybody and their first cousin seems to be talking about this e-mail thingy per the title. I'm going to read up on it in a bit, but…

It occurs to me that as a proverbial Neanderthal who still believes HTML has no place in e-mail, I find the whole idea to be a non-starter.

Let them eat attached PDF’s, I say.

Update, 45 minutes later:

I scribbled more (similar) opinions on the subject over at Zeldman’s.

Thoughts: typesetting print-only pages

Earlier today I posted a comment on Twitter about the habit of some sites in which they set fixed-width columns for their bodycopy on print-specific layouts.

In short, this habit annoys me.

Print-only page audience

Other than printing, there’s one other reason to visit a print-only page: to click to an un-paginated article. I’m a fan of pagination, but not if it requires me to load a series of brand new pages; a solution like the one used for several years on iht.com is far preferable, to a point.

The result is that I, like so many other people, will click over to the print-only page for the benefit of making one single page request more, rather than three or more.

The point is that print-only pages get a lot of online use, because I know I’m not the only person who feels hostile toward excessive pagination.

…Which leaves us with bad and thoughtless typesetting

The practice of producing print-only pages with static column widths and auto-leading is, in short, a bad one.

• Auto-leading on long pages underscores the best reason for pagination, namely avoiding the discomfort of keeping one’s place in the copy while scrolling.

  However, I don’t believe that oversight is intended as a disincentive. Someone probably believes that auto-leading will conserve paper, but decreasing leading on magazine articles won’t conserve that much; increase leading by one-sixth of a line and, if you’re using twelve-point type, you reduce the number of words that can fit on a page by 60 or so (15%). Assuming stories of 500-1,000 words and plugging in this metric, auto-leading suggests that most of your stories will print across two or three pages.

  Where does this leave the cutoff?

  Pagination points in words for stories printed with 12-point bodycopy, with and without increased leading

  Page	Auto-leading	+ 1/6
  1	400	340
  2	800	680
  3	1,200	1,020

  The conclusion that can be drawn is that the only common story length likely to cause paper “waste” as a result of an increase in leading is 700-750.

  Unless 750 words is a happy place in your editorial guidelines, why not increase leading on the print-only pages? Your visitors will love you for it.

• Fixing the column width in pixels is an inconvenience to those who use text zoom rather than page zoom.

  Once Firefox 3 (which will support page zoom) ships, this concern will go away. In the meantime, it’s a pain to see my words-per-line decrease when I increase the type size.

  If ’twere me, I would:

  1. Link a stylesheet of type="print,screen”
  2. Create both @screen and @print blocks in that stylesheet
  3. Emplace width: 50em; in my screen bodycopy rule and no width attribute at all in my print bodycopy rule (which will allow the copy to occupy the full width of the printed page).

  …Why a line length of 50ish ems?

  50ish ems often translates to twelve or thirteen words, which is at the low end for optimizing the legibility of long passages of text. That approach also allows for fully justified margins, which for all but the longest paragraphs convey the idea of higher production values. Especially long pieces should avoid justified margins, however, as the ragged right margin eases place-keeping.

  The alternative is to allow the lines to run completely across the screen in both print and screen media, which at higher pixel pitches will improve readability at the expense of legibility.

This is all rather pie-in-the sky thinking, and when I look at my most recent print-only ruleset I see that I let the bodycopy run across the breadth of the page — you could say that I’m thinking this through for the first time.

Asus Eee: forward to the past for graphic design on the Web?

Well, it’s not the world per se that’s getting smaller. The Web is another story, because of developments in the ultra-mobile PC space — and I strongly believe that these developments will have far-reaching consequences for best practices of graphic design on the Web, if they take hold in the marketplace.

Think small

Almost two years ago, I tore open a box with a buy.com shipping label and removed my brand-new subnotebook computer, which since then has earned a lot of oohs and aahs — it’s obviously not a Macintosh of any description, and it was somewhat underpowered even when I bought it (1GHz Celeron M CPU, 512MB RAM, 60GB HDD, XP Home), but it’s still a piece of work. I’m a Web guy. I don’t need tons of juice to get my job done.

More to the point, I’ve spent my entire adult life living the car-less lifestyle, so a rig that I could easily carry and shoehorn into small-ish public spaces was (and is) a wonderful thing to own.

Now that it’s been two years, I’ve started looking casually for a replacement… which means that I’ve noticed the announcement of the Asus Eee and its appliance-ish cousins that are already on the market.

I may well buy one, even if I need to get a portable disk drive too; $400 is a hard price to beat for a widget that can support everything I need except graphics, and my professional development is definitely taking a sharp turn toward the programming end of things.

Don’t misunderstand me — the Eee is a 1.5G product at best, and it’s a matter of time before OEM’s concede that keyboards are both necessary and constrained by a hard lower bound on size. Kids and petite women can get mileage from machines like the Eee, and so can folks like me who are smallish-handed and know how to type. As for bigger guys¹, or power users who are tethered to ergonomic keyboards², fuhgeddaboutit… and if you rave on stylus interfaces, expect me to guffaw in your general direction.

My point is that people want small and affordable machines that they can actually use, and I strongly believe that eventually the 7" display, or something close to it, will gain share in the user population.

Necessity is the mother of invention ’n allathat. Touchscreens will improve, or someone will come up with a more-usable yet adequately-simple keyboard design that will fit into that form factor.

If I’m right, that means that the march to 1024w layouts will falter. Ponder that.

Footnotes

¹My best friend in town stands 6'4" and weighs 240#. He runs in terror from the prospect of borrowing my notebook.

²…But I can’t stand ’em. I do not need some smartypants industrial designer telling me how to use my hands; as a sinistral, I have my own way of doing things. I also have a ton of acquaintances who swear by ergos.

Web pet peeves

[I first posted this on 21 October to Chapel, where I’ve blogged sporadically for quite some time. It belongs here, too. I’ll still be posting the really weeeird stuff over there, because that’s what it’s for.]

I ran into a major Web pet peeve and posted it to Twitter, in the process remembering that I have several others (a few of which I spent all afternoon working around)…

• Web sources cited by mass media outlet content that don't link directly to them
• e-commerce sites that break at ANY point when you’re using a browser other than Internet Explorer
• e-commerce sites that don't create a semi-permalink to a customizable cart item
• any application that breaks the instant you press the Back button, without warning you in advance of the consequences of doing so
• failure to provide range selection support (beyond “check all”) for series of checkbox selection inputs (e.g. mail inbox)
• applications that crash on purportedly tested platforms
• process-critical services and applications that do not have a System Status resource
• sites and applications that treat content sections like static search results
• project sponsors who fancy themselves graphic designers despite a total lack of training and experience
• ads with sound on otherwise silent sites
• categorically, ads that talk
• news and social linking sites that toss resources down the memory hole without consequently returning a 410 (Gone) status code along with the title of the clobbered resource (or at least some indication that something formerly lived there)
• applications that enforce user behavior by limiting choice in a bizarre way (here’s looking at you, Facebook Status)
• sites that are only useful if you pay, yet imply otherwise in their create-an-account pitch
• anyone anywhere in any context asking how to “hide” source markup and things of the like
• anyone anywhere in any context believing that because their fucking nephew can “make a web page” in twenty minutes, they’re entitled to a full custom e-commerce site for a few hundred bucks…
• …and contrapositively, anyone who bilks the clueless out of thousands at a time for crap they build in twenty minutes with Flash or Dreamweaver
• anyone who thinks that just because they’re entitled by the right to free speech to an opinion, they really just ought to share it, despite the stench of banality and/or thoughtlessness it emits
• anyone who mistakes ignorance for willful malice
• anyone who mistakes obstinacy for courage
• anyone who thinks it’s okay to be narrow-minded about the narrow-minded

Aaahhh. Now I’m done.

If you bear any witness to irony, by all means bask in it.