Sunday
15Nov2009

My Verizon Droid

I got a Motorola Droid on Tuesday, and so far I'm very happy with it. I picked it primarily to stay on Verizon, but I've found several serendipitous features, mostly related to the user interface. While not perfect, I expect it will be an excellent smart phone, maybe even better than an iPhone.

While there are lots of really thorough Droid evaluations out there (I really liked the Gizmodo review), what I'm hoping to offer here is an "I'm a regular technical person who has lived with this phone exclusively" look at the droid. I'll go over

  • why I got a droid now (basically background),
  • what I wanted,
  • what has been awesome,
  • what has been just fine,
  • what has sucked,
  • and finally some overall impressions.

Although I have read and largely agree with the sentiment that the Droid is not aiming to be an iPhone killer, for me the decision really was iPhone or Droid, and so that's my vantage point. I was previously using a Blackberry Curve.

Background

Cell Phones (1 of 2)

Last Tuesday, my trusty Blackberry Curve finally gave up the ghost — the trackball fell out of the phone and I have no idea where it went, ending an otherwise lovely relationship. I had been considering a new phone for a while, and until hearing about the Droid, I was dead-set on switching to AT&T to get an iPhone. I've had an iPod Touch for a few years, and I've been mostly happy with it, so I felt like I knew what I was getting with an iPhone: a nicely designed device with lots of awesome applications and with a virtual keyboard that I find deeply frustrating.

The big unknown with an iPhone was the network; I see tweets and hear complaints about the lack of actual 3G coverage (and any phone coverage at all in parts of NYC and San Fran); I remember AT&T's network collapse during the inauguration (I only saw tweets from friends on other networks for most of that day); I read about AT&T's voicemail problems; and I get good value from Verizon's "in" program, since my family and many of my far-away friends (i.e., the ones I talk to on the phone) are on Verizon.

Had there been an iPhone on Verizon, I'd have almost definitely gone with it. But, after a week with my droid, I'm not sure that would have been the right decision. The iPhone is an incredible piece of hardware with a really slick OS on top, but so is the Droid. And, there are already things I really love about the droid that don't exist on iPhone.

What I was looking for

I'm not going to give numbered scores or anything, but I did try to come up with the things I was looking for in a new phone:

  • One device for media and communications, because I have only one pocket without keys in it
  • Good phone (as in talking on it) support
  • Better twitter and gmail clients than on my Curve
  • Better maps than my Curve with an un-crippled GPS
  • A reasonably good MP3 player that can sort through 10s of GBs of MP3s
  • At least 16GB for music, 32 GB would be better
  • Something like InstaPaper for reading web articles offline (on metro, specifically)
  • A platform that actually has apps
  • Fast internet and a reasonably good web browser
  • An app for reading books
  • A device that feels and looks good
  • A monthly bill that wasn't horribly higher than what I have now

I basically wanted my Blackberry to hook up with my iPod Touch and make me a new phone. The droid and the iPhone both fit that description, and in the end it was the "Fast internet" and "Good phone support" that tipped things for me.

What has been awesome

Cell Phones (2 of 2)

A lot, honestly. As soon as I got it, it had my gmail, had synced all my contacts to my google contacts, had my calendar, and within a few minutes was grabbing people's pictures and facebook statuses into my contact list. The phone part works really well, and as I'm used to, I have service pretty much everywhere I go that isn't a basement. Even better, I have 3G almost everywhere I've gone so far, so my phone's Internet connection is actually pretty zippy. The phone itself is really fast, too; apps launch pretty much instantly.

The operating system user interface is usable and powerful at the same time. I expected basic tasks (like finding the right app to launch) to be difficult, but instead I feel like in a lot of ways, this phone is easier to use than an iPhone. There's this "shade" status bar at the top of the phone that gives me notifications, such as new emails, voicemails, to-do tasks, and tweets. If I touch and hold it, I can drag it down for more information and touch on the notification to launch the appropriate app. This comes in handy particularly since there's multitasking -- I have apps running in the background and checking twitter, the weather, and even my location-specific to-do items (in Remember the Milk), so it's nice to have a heads-up display of notifications. Plus, for things that might have more interesting information that I don't want constant notices of (longer-term Todo items, the weather forecast, my current song I'm listening to), there's widgets that I can drop on my home screen. Finally, there's a back button on the phone and a cross-app history manager built in to the OS, so if I see a notice and go look at it, and then I want to get back to what I was doing, I just hit back and I'm back in the app I left to take care of the notification.

There's also a button on the screen and a widget on the home screen for search, which I find myself using often; if I can remember the name of what I want (be it person or application), I can just search and then take the appropriate action. There's also a pretty neat voice search built in, meaning often I don't even have to type — I just say what I want and it searches. If what I want isn't a contact or app, I get a web browser.

The combination of the speed of the phone and the internet, the notification system (with multitasking), and the excellent built-in search gives the phone a really powerfully usable feeling; it makes things feel instant. For a small, limited device, this is huge; when there's something I'd be interested in, it's in my notifications. Otherwise, I search for it. If I can't remember the name of the app, I can bring up all my apps and browse them alphabetically. If the app is something I use a lot (like my email), I can drop it on a home screen for quick access.

The operating system extends this "instant" feeling further by allowing apps to be designed for easy mashing-up; when I installed evernote, it became possible to send web pages and photographs to it from the native web browser and camera app. This is because the OS allows application developers to advertise "intents" that their applications support (such as sharing content or address-book functionality), and then to make reusable "activities" that can receive data from other applications. This makes it so applications reinforce one another, and makes the phone feel more powerful; it makes sense that I can share web pages through Evernote, Facebook, Gmail, Paperdroid, Google Reader, and Twidroid. What's nice is none of those developers had to collaborate to make it happen.

Additionally (and complementary), I've been very happy with both the physical and software keyboards. Android's text predictions are excellent and make typing on the screen pretty painless, and the physical keyboard is perfectly usable for me. A decent keyboard is a big win on a small device.

What has been just fine

There have been plenty of satisfactory-but-not-amazing experiences. I don't particularly love the look of the phone itself; it's not clunky or anything, but it does feel big and a little awkward because of the slide-out keyboard. It's definitely not sleek like an iPhone.

As for apps that I actually have cared about, I was able to find a twitter app (Twidroid, which is OK but definitely doesn't have my heart), something to get me metro times (DC Metro Train Info), and a good Amazon app. To replace InstaPaper, I found Read It Later and PaperDroid. I really hope PaperDroid adds tilt-scrolling; if it does, that'll pretty much entirely replace InstaPaper for me.

The media player on Android has been fine so far — it sorts my albums well enough that I can find what I'm looking to listen to. I'm not a particularly demanding music user though — I usually listen on random for a while until I hear a song on an album that catches my interest, then I listen to that album, then go back to random and repeat the process. I care more that I can hold lots of music on the thing, and I expect someone will release a really slick media player eventually.

The browser is as others have said: it renders pages well and the double-tap zoom is good, but the lack on pinch-zoom is lacking. It's a huge step up from my Curve's browser though, and doesn't seem to cause the Droid to crash the way Safari on my iPod Touch liked to, so I'll take it.

The battery life is neither great nor terrible. If I don't use the screen much, the battery holds out. If I do, I burn through it. That makes sense. If Motorola were to make a bigger battery that added a little more heft to the phone, I'd take it, as long as the phone still fit comfortably in a pocket. On the up side, the Droid charges over microusb, so I was able to get a bunch of cables for $3 a piece, and thus I'll have multiple chargers at home, one at work, and one in my messenger bag (you know, just in case).

I've barely touched the maps application, but it definitely uses GPS and knows where I am, and I hear the turn-by-turn directions are awesome, so I look forward to really putting it through its paces when I head out for thanksgiving.

What sucks

There's no doubt about the number or quality of apps compared to the iPhone: they're just not on droid. Many apps for droid from major companies are brand new, and lack the polish of their iPhone counterparts. The games in particular seem pretty pathetic. On the one hand, except for an iTunes remote that works, I've found apps for pretty much everything I want; on the other, it's hard not to notice the relative dearth of innovative apps. The lack of apps has meant no Kindle or Barnes and Noble apps, which means insufficient books for my taste; there just aren't that many ePub books that I want to read yet.

Worse than the lack of apps is a lack of momentum. I don't hear developers talking excitedly about developing android apps. I don't see lots of books coming out for android. I don't feel like there's a big market for the android apps people do develop. I don't think this is a permanent state; I think the lack of having Android phones on either AT&T or Verizon made the market too small. But, it's still worrying; someone's going to have to invest in even better developer tools and get people really excited. I have a number of additional thoughts on this topic that I'll hold for a separate post though; I'll update a link here once it's written.

Less bothersome but still annoying is the camera and the lack of a good music application. The camera seems to hate to focus. It tries, it gets in focus, then it takes the picture soft. I hear this is a software issue, but it's an annoying one. Getting music on the phone isn't a joy, either. On the one hand, you can just drag a bunch of folders on to the SD card and call it a day, which is pretty rad. But, that's not how I want to manage my music; I want to drag albums on and have them organized for me. That's not sync, but it's not the file system either. There's DoubleTwist, but it doesn't recognize the Droid as a media device and generally feels horribly buggy; it locks and crashes as often as it works. I've gotten music on the Droid and it hasn't been a dealbreaker, but it's still sucked. I have some hopes either someone like Lala will create a wireless sync, or maybe Songbird will step up and we'll see an Android plug-in there, which would be fine to me; I don't love iTunes.

Conclusion

One week in, I'm really happy with and excited about my phone. My girlfriend keeps grinning because I keep taking it out to play with it whenever there's downtime. The phone's UI and features give it an "instant" feeling that I've not had in many other computer devices. I've been able to find apps that do most of what I want; however, the app market in general is worrying because of a lack of momentum. The phone isn't perfect, as evidenced by the media player and buggy camera, but overall, I'm very happy with it and would certainly recommend it to other demanding technical folks.

Saturday
18Apr2009

Plone and its peers

Plone is doing pretty well against the rest of the field of content management systems in several key areas, which I learned in a presentation by CMS Watch's Tony Byrne.

Several months ago, I got to see a presentation by CMS Watch's Tony Byrne about the state of Web Content Management in 2009, hosted by DC's Web Content Mavens. I took notes and then sat on actually writing this post for, um, about four months. But, better late than never.

The presentation first went over several major prediction that didn't come true in 2009; namely, that Web Content Management Systems did not converge with Enterprise Content Management (ECM), Social Networking Systems, or Component Content Management Systems (CCM). None of these particularly surprised me; as I've learned from Plone and Drupal over the past few years, it's tricky to build systems that have adequate granular security and workflow features that also support large numbers of concurrent, logged-in users who are creating content and relationships. As for ECM overtaking/merging with WCM, my understanding there is real ECM is absurdly hard to do well, and so I'm not surprised that trying to bolt-on web publishing to records and document management systems proved to be a massive undertaking. And I really know very little about CCM to begin with, so I'll just keep my mouth shut there.

Overall, I was impressed at how many of these things Plone's been doing right for a lot more than a year, and how many of the things that it hasn't been are well underway. For a quick summary, check this post's accompanying mindmap; or, stick around for my commentary on the areas where we're doing well and falling down. I unfortunately can't post the slides (as they're not mine to post), but I can at least share my notes.

Friendly URLs

This one Plone's had for a long time, care of the zope publisher. Plone's default title-to-ID converter does a good job making search-friendly path components, and products like redirection tool give you total control over the URLs for objects. I am consistently amused when I see systems where they actually charge for the ability to set reasonable URLs for objects.

Repository Search

Plone doesn't have some much of a separate "repository" to speak of, at least from an end-user perspective; content objects are searchable via the site search and editable from their web-representations. The advanced search gives you some ability to find objects by type and review state, but otherwise we could use some work here. Out of the box, there isn't an obvious way to get a listing of all objects of a particular type and sort them meaningfully (although clever content managers can use their own collections for this purpose), nor to do anything like faceted search. I have heard of products coming out to support this, and I'd be interested to hear about others' ideas for making it easier to find content that needs editing without browsing the site or relying on full-text search.

Dependency Tracking

Plone actually got a screen-shot in here in the presentation, as a system that provided user-friendly dependency tracking. Byrne seemed impressed by the delete notifications Plone gives you. As the composite page story for Plone evolves and content can appear in more places on a site, it will be valuable to add more ways to track where a given object is showing up on your site.

System Management and Configuration Management for Business People

I've unfortunately forgotten what the different between System Management and Configuration Management were, so I'm just going to conflate them and say generic setup is wonderful. I realize that it can be opaque to system integrators, and I won't pretend that I haven't cursed as I tried to find something in a sea of <object /> tags, but the fact that Plone can serialize out configuration to a format I can teach my non-developer colleagues to edit, and then can easily read configuration back in from the file system, is a godsend. When you're starting a site from scratch, it can seem unnecessarily complex, but once you have a live site that users are updating constantly and you want to test changes before you deploy them, it's wonderful to be able to automate configuration changes and be sure of reliable repetition. Having spent some weekends trying to deploy changes in Drupal 5 and be sure I've clicked all the right places in the right order (often following someone else's notes), I'll gladly do some XML sit-ups for the sleep they save me at deployment.

[Content] Management Metrics

Plone could definitely use some work here. Clever use of collections allows content managers to create queues of pending, old, and expired content, which is a good start. However, if you're managing a large site, these queues aren't going to be enough; it can be really valuable to be able to get an idea of which sections of your site are getting the most updates, which sections are aging worst, and to know more about your aggregate site activity. To my knowledge, there's no good way to get this information from Plone; I remember Kapil Thangavelu mentioning a content auditing system that could use a SQL database to provide some of this information, but I can't even find it now.

Site Analytics

Plone doesn't do this one really at all — there's a box for inserting web-based analytics code into the footer of pages, and otherwise you're pretty well on your own here. There are systems that do provide some of this; the blogging platform I use actually gives pretty good analytics. And, on its face, it's hard to know why your CMS should provide analytics; with so many dedicated packages for that, why bother?

However, analytics combined with content metrics could provide powerful tools for content managers. Imagine being able to see where your traffic were going and how it was traveling through your site (or bouncing away), and then being able to overlay information about how frequently those pages were updated and re-reviewed, and who had been working on them. Right now, if you have firm goals for how your site should perform in terms of analytics, you might be able to get that information from a third-party system, but then drawing inferences from current practices requires either a lot of custom programming or some other external auditing system. This is another area where I'd love to hear comments — maybe I'm overestimating the kind of intelligence you could get from combined analytics and content metrics, or maybe there are systems that would make this much easier in Plone.

Word Conversion

This is an area where no one does well. It's hard to blame the CMSes, either. People use word badly, and then word makes matters worse by producing a ton of crazy markup when you paste from it (and it's different crazy markup depending on your word version). I'm not sure how a CMS could be expected to really accurately convert text destined for print to the web when that text doesn't use page-level styles. I know enfold desktop offers integration directly with word, but I've never been able to get it to work in a way that I found acceptable; then again, I haven't put a ton into it.

True Multi-Site Management

This is an exciting area in Plone right now, with the changes that went into 3.3 and the new lineage product. It's also an area where most other systems do a bad job, according to Byrne. With Lineage, it's now possible to setup a single Plone site with multiple independent children, where the parent site can access the content of the child sites, but the child sites are independent of one another and segregated from the parent. This solves a variety of use-cases, like campaign-specific sites or large institutions with several independent departments or divisions. I haven't gotten to play with lineage myself, but I'm looking forward to using it soon.

Usability

This is an area where I've always felt Plone really excelled; although the interface may not exactly be simple, it is gloriously consistent. In training end users to create content and manage sites, I've found that they learn quickly and are able to extend their knowledge easily, thanks to this consistency and the care put into keeping the UI logical. And from what I hear, Plone 4 will only get better, with a simpler interface and fewer concepts to master, even for complicated tasks.

Non-browser Clients

This is apparently a hot area for non-FOSS CMS vendors. According to Byrne, adobe's Flex has vendors all excited about creating "rich internet applications" for interacting with their products. I have trouble seeing how this would be useful for many tasks; you're managing a website, you might as well do it through the web. To my knowledge, Plone doesn't have any non-browser clients, but I'm not going to hold that against it.

Overall

Overall, I'm impressed. There are plenty of areas where other systems are just now playing catch-up, and plenty of others where Plone is keeping pace or maintaining its lead. And I don't see development or innovation slowing down, so I can't wait to see how we're doing in the state of content management in 2010.

Monday
02Mar2009

Links Let You Keep Your Deep Thoughts

Writing web-ready documents means thinking hard about linking. Long copy is not forbidden on the web; it's just likely not what you want to present to a reader first. Thanks to links, that's not a tall order to fill.

I've spent the last few weeks talking to colleagues and clients about web content strategy and web writing, and I've realized there's something fundamental that I've been eliding: you can still have thoughtful, in-depth content on your site. You just shouldn't put all your thoughtful content on one page.

It's tempting, when thinking about content, to think about the very familiar article and book models. In an article or book, people generally read from beginning to end. There's not a lot of skipping around. In a magazine, I might look up a specific article in the table of contents, but then I'm likely not going to begin somewhere in the middle of that article with my reading. It's not that I can't — I just likely won't. In print, the writer and editor has a great deal of control over the reading process.

The Web is Not a Book

Although users are less free on the web (you can't exactly flip randomly though a site the way you can a book), they have surprisingly a lot more control about access to specific content. So, instead of thinking in terms of a single, thorough and complete document, it's useful to think of landing pages and content chunks.

Guide Visitors with Navigation Pages

Navigation pages are where you hope most users enter your site. Your home page is a navigation page, and it's one people like to think about a lot, but many of your visitors aren't going there. Instead, they're searching for something specific that you have and landing farther in. Or, if they are entering through your home page, it's likely just to navigate deeper into the site — again, to find a navigation page to help them get to the content chunk they need.

Navigation pages perform a few tasks on a content rich site:

  • give an overview of what content is available related to the page, and give that content context
  • offer cursory information about a topic for visitors with a superficial interest/need
  • help visitors locate the more specific content chunk they actually want
  • highlight the content that you feel is important (e.g., new content, a sale item, etc)
  • give context to how content chunks under the landing page relate to one another and to your site

People get to the navigation page either from your navigation, through a search that lands them on it, or after landing on a content chunk from search and the navigating up a level to survey what other useful information you have. They help support the foraging for content, and they give you a chance to highlight your best stuff. They have been part of the web's architecture since the very, very beginning. When you optimise them for people to find via search, they're called Landing Pages, and a quick search yields a legion of resources on making good use of them.

You Can Also Have Longer Content

We web people get excited about navigation pages — we study them, we design them specially, and we show them off. The part I feel like we neglect, unfortunately, is the content beyond the landing page — that rich, nutritious copy that teaches your visitor something useful.

This longer content is what you expect people are actually looking for, and it makes your site worth visiting. The hard part is realizing that, instead of thinking of atomic, complete documents that are self supporting, you instead have to think of linked content chunks. Content chunks are different from articles in that they

  • focus on something specific, and they focus tightly on that one thing
  • get the the point quickly, relying on the landing pages and information architecture to give them context
  • link to other content chunks on related subjects

As Jakob Nielsen conveniently wrote about today, it's important to keep each unit of web copy focused on as few topics as possible so that it works in many contexts. You really cannot control how people are going to approach your content, but if you focus each chunk on a single issue, people will likely get that single point; you can then link to other related content in context to offer readers additional useful information. You can also structure your site so that content chunks have a place in the site — so that if I'm article about web writing, it's easy for me to get an overview of all your content on web content.

Focus and linking do not force you to keep your copy short or cursory though. You need to make sure your content is scannable and engaging, so be sure to follow the suggestions in my last post, but there's no limit on actual length or thoughtfulness.

Thinking About Linking in Practice

To help make this more concrete, pretend you're working on the content about your organization's history; let's pretend you work somewhere really interesting that has a history that people may actually want to know about. It's tempting to try to write an essay about your organization, starting with your founders' life histories, then moving to the early phases of your organization, your expansions through the '70s, new focus in the 80s, and triumphant navigation of the current era. You'd likely cover various products and events from the past and present in line.

Instead, though, imagine creating a navigation page that gives the broad outlines of your company's history, linking to articles on the eras and featuring some of the high points separately. In these time-period specific content chunks, you could link to biographies of important people from your organization's past, histories about specific products, and other material in more depth than would necessarily even make sense in an essay.

By structuring the navigation well, it would be easy to jump in at any point in the web and figure out where you are in the organization's history, zoom out to the era overview or the whole history overview, or learn about the person who invented the neat product you're learning about. In structuring in this way, you accomplish several goals

  • you cover your topic in greater depth than would make sense in a single essay, because you can treat each important facet of the history individually
  • you support a variety of visitors, from those really interested in the whole history to those interested in some specific product or person, to those who want to know more about what your organization has been up to recently
  • visitors who are foraging for specific information can quickly assess any given page for usefulness and more easily find exactly what they're looking for by following links and then reading just the tightly focused pages they need

This type of writing takes some getting used to, and I'm hoping to have some advice for how to practice that in the near future.

Sunday
08Feb2009

Web writing for Communicators

Writing for the web is different than for other media. You need to understand why people browse, have a strategy for your content, and write in a way that supports skimming. In this post, I'll explain how you can improve your content to attract and keep an audience.

Your Visitors Have Goals

Unless your site is entertainment or the wikipedia, your visitors are not dropping by to kill time. People visit websites to solve problems: they want to learn something new, check a fact, purchase a product, or accomplish some other goal. Visitors do not come to hear your point of view for its own sake (usually), enjoy the brilliance of your branding, or learn about your mission (unless they're preparing for an interview or to donate to you). For example, you're at this post to learn a bit more about web writing, not to learn more about what a knowledgeable web guy I am (though I wouldn't mind coming off that way).

Visitors forage around the web for information. They look for patches of useful information, surveying the land via search. Once they've found a promising looking patch, they dive in and jump from link to link, looking for information that helps them solve their problem. If they find it, they leave happy to solve another problem, and hopefully return again if they need you. If they don't, they leave frustrated and turn to your competition.

Your writing needs to support problem solving. And it needs to recognize that people are solving problems under time constraints and with little hope for the value of your content. People will arrive at your site via search or a recommendation (which is like search, only more social). They need to (quickly)

  • navigate to the useful content on your site
  • ascertain whether a page is valuable
  • read the parts of your site that help them
  • ascertain if there's additional, more helpful content on your site
  • get on with their lives

Your Content Must Support Your Visitor's Goals

You probably do not have unlimited time or money to put your site together. Worse, developing good content takes a lot of time and talent. So, if you want success, you need to think about a content strategy that takes into consideration

  • who do you want visiting your site?
  • how can you help your visitors succeed at something?
  • why should someone risk your wasting their time and visit your site?
  • what content resources do you have available already?
  • are the content resources you have really web-ready (more on this below)?
  • how can you ensure that people can find the resources you have?

Just converting lots of existing materials into PDFs or copying text from old documents and marking it up is not a content strategy. Your visitors have goals. They do not have a lot of time to sort through your materials. If they get frustrated, your visitors will leave; they will return to the search engine from whence they came and visit someone else's site.

Find content that supports the people you want visiting your site and that helps them solve their problems. This means you need a clear idea of who you really want visiting your site (because that's how you know which problems you should solve) and what content you actually have to offer them. Where you lack that content, develop it. When you have that content, be sure it's fit for web consumption.

There are Two Types of Content to Consider in your Strategy

Different problems demand different types of content. In general, there are copy pages, which solve specific, well defined problems, and there are articles, which teach a visitor something complicated. Copy pages provide

  • landing pages, which take visitors from a search engine link to your useful content
  • product descriptions, which help visitors decide whether to buy a product
  • instructions, which help a visitor complete a defined process
  • overviews of unambiguous information, like press releases or your company's mission or history

Copy should get out of the way. It does not need to be written in prose. It should be kept as short as possible. It does not need to be beautiful; it just needs to be clear.

Articles, in contrast, explain about something less clearly defined, such as web writing, a solution to the sub-prime crisis, or your well reasoned views on China's economic growth. They can be short overviews or long, in-depth analysis, depending on your audience. Articles are your opportunity to convey your perspective, and as long as they are written with the reality of how your visitors will read in mind (more below), they should have tone, voice, and style.

All Content Must Support Skimming

Web visitors do not read carefully. They skim. They will read somewhere between 20 to 80 percent of your page's words, according to Jakob Nielsen and the Poynter group. They will spend between roughly 25 to 35 seconds on your home page and read only 10 to 30 words there (Nielsen 2006). They will also bail if they see an interesting looking link (Pirolli 2007).

With this in mind, we do know that visitors pay attention to

  • the beginning of a page
  • bullets, or the first few words of them
  • links
  • bold text
  • images that don't look like ads
  • interactive elements that don't look like ads

You can use what you know about skimming to your advantage. Web writing is extremely demanding. Your sentences must be direct and easy to understand. Your paragraphs must flow well and highlight key information with text formatting. Keep your sentences reasonably short, and if your style allows it and your audience will accept it, write conversationally. Keep your paragraphs tightly focused and well organized. When possible, use the active voice (it's easier on the brain) and use your visitors' language.

Write in an inverted pyramid style, like a journalist. Provide a summary of the page at the beginning. If a visitor believes there's valuable content on a page, s/he will scroll down the page to skim it (Pirolli 2007), and a summary lets a visitor know there's valuable content.

Use headings (which are big and bold). Use the text formatting that's available to you, such as bold and italic. And of course, use bullets to break up your text; it is easier to skim a bulleted list than an inline one.

Make sure your links are long (seven to twelve words [Pirolli 2007]) and descriptive. Links are fundamental to how the web works. Search engines use links to understand what pages are about and how they relate to one another. Visitors use links to find the information they're looking for, since search engines don't always turn up the most relevant results. People forage using links; support them by making your links clear, honest, and descriptive. Don't use "click here"; it tells people nothing as they scan. And for yourself, make sure your link between content on your site to expose it to your visitors; you have an idea of the problem they're trying to solve, so offer them to everything you have to help them solve that problem.

Be concise and avoid made-up words. Your visitors are potentially reading only 20 percent of your text; you need to make sure that every word matters. And can you imagine how they feel if they're skimming and they come to some nonsense jargon word that your company coined? Sit in your visitor's seat: "I'm trying to understand something and they want to expand my vocabulary with words that only they use. I'll go elsewhere." Even better than avoiding made-up words is using the words your visitors would use, which you can learn by visiting them (both in real life and in their online communities) and looking for proxies, such as search keyword analysis tools and search logs.

Give visitors multiple ways to access your information by using images and interactive content. People learn and remember things better when they get both text and an image. This doesn't mean that you should just decorate your page with stock art; you need to illustrate your points, not decorate them. If you're not particularly visual, you can learn to be, and enlist the help of a professional (a graphic designer!) when you can. I'm not very visual myself, so I'm embedding mind maps in my posts and using simple comic characters to illustrate points. And if you have the resources, go beyond an image with a video or an interactive illustration of your point, such as a game.

Exceptions and Examples

For every rule above, there's some good reason to break it. Ironically, we can find some of the best examples of web writing in places where you'd expect the rules to be broken, though.

  • If you're writing for a highly motivated audience of specialists, and your content is excellent and valuable, you can expect people to really read your content. Look at the writing articles on A List Apart; they are not particularly easy to skim. Jakob Nielsen's writing on useit.com, however, is long but immanently web-ready (see, for example, his article on his research into how visitors actually read).
  • If you're writing a blog, people expect more quirks, more personality and style, and less polish. However, blogs like Jared Goralnick's Technotheory are insightful, appropriately personal, and written with a web audience in mind (see his post on packing for a long trip for an example).
  • Sometimes, your copy is going to be long; you may be writing instructions for something that is clear but complicated. However, check out the instructions for building a heavy-duty six-legged robot on instructables. The prose may not be inspired, but
    • they motivate you to want to understand with good previews of your finished product in pictures and videos
    • they break the long document into shorter, coherent chunks
    • they use subheads to get across the thrust of each step, so you know what you'll need to do before committing to the whole instructions
    • they offer a print-friendly version of the instructions because it's easier to read long documents in print than on your computer
  • Sometimes the point of your content is to introduce a new word that will make communicating a complicated concept easier. If you're writing for a motivated group of experts who will understand why the new word is necessary, some jargon is OK. It speeds things up. Look at the instruction above: "machine the motor linkages" isn't exactly clear to any random visitor; but for someone who might actually build that robot, it'd better be clear, or maybe that someone should consider a simpler project.

Moving Forward with Additional Resources

If you're looking for a coherent dive into some of this content, there are several books I can recommend to get a more in-depth look at web writing than could be offered in this blog post. If you

Additionally, there are plenty of websites that have articles that can help you.

And many more articles; just look at the results on delicious if you query "web writing," and you'll find thousands of articles.

Sunday
01Feb2009

Two quick SquareSpace tricks

In the process of migrating modulus to squarespace and starting a separate personal blog, I've come across two useful tricks that I wanted to share in case anyone else ever needs them.

The first is related to migrating from Drupal to SquareSpace. SquareSpace accepts a variety of formats, and they seem pretty ecited about their Moveable Type importer. I lucked out and found a script to export a drupal site to moveable type (scroll down for the python version), but unfortunately it didn't

  1. handle my node revisions correctly
  2. filter out unpublished comments
  3. write the date in a format that SquareSpace could handle
  4. have an obvious way for non-programmers to run it

So, I hacked in fixes to those four issues, and it worked like a charm. I tested it against drupal 5 -- no promises it'll actually work for you, but it was nice to have to work with.

 

def read_drupal(outfile,db,host,user,passwd):
import re,MySQLdb,time,wikimarkup
linefeed = re.compile('\r')
fout = open(outfile,'w')
db = MySQLdb.Connect(db = db,host = host, user = user, passwd = passwd)
c = db.cursor()
c2 = db.cursor()
cdata = db.cursor()
c.execute("SELECT nid,uid,type,title,status,created,comment from node where type = 'blog' AND status = 1")
stat = ["draft","publish"]
for (nid,uid,type,title,status,created,ncomment) in iter(c.fetchone,None):
#for i in range(0,10):
#(nid,uid,type,title,status,created,ncomment,teaser,body) = c.fetchone()
cdata.execute("SELECT body,teaser,format FROM node_revisions WHERE nid = %i ORDER BY timestamp" % int(nid))
(body, teaser,format) = cdata.fetchone()
# teaser = ''
# body = ''
body = linefeed.sub('',body)
if format==4:
body = wikimarkup.parse(body)
created = time.strftime('%m/%d/%Y %I:%M:%S %p',time.localtime(created))
c2.execute("SELECT name from users where uid = %s", (uid,))
(name,) = c2.fetchone()
fout.write("AUTHOR: %s\nTITLE: %s\nSTATUS: %s\nALLOW COMMENTS: %s\nCONVERT BREAKS: 1\nALLOW PINGS: %s\nDATE: %s\n" % (name,title,stat[status],ncomment,1,created))
c2.execute("SELECT name from term_node n, term_data d where n.nid = %s and n.tid = d.tid" % (nid,))
categories = [cat[0] for cat in iter(c2.fetchone,None)]
fout.write("TAGS:%s\n-----\n" % (','.join(categories)))
fout.write("BODY:\n%s\n-----\nKEYWORDS:\n/node/%s\n-----\n" % (body,nid))
if teaser != '':
fout.write("EXCERPT:\n%s\n-----\n" % (teaser,))
c2.execute("SELECT subject,comment,hostname,timestamp,name,mail,homepage from comments where status = 0 AND nid = %s order by cid" % (nid,))
for (subject,comment,hostname,timestamp,name,mail,homepage) in iter(c2.fetchone,None):
timestamp = time.strftime('%m/%d/%Y %I:%M:%S %p',time.localtime(timestamp))
#timestamp = time.strftime('%Y-%m-%dT%H:%M',time.localtime(timestamp))
fout.write( "COMMENT:\n")
if name != '':
fout.write( "AUTHOR: %s\n" % (name,))
if mail != '':
fout.write( "EMAIL: %s\n" % (mail,))
if hostname != '':
fout.write( "IP: %s\n" % (hostname,))
if homepage != '':
fout.write( "URL: %s\n" % (homepage,))
if timestamp != '':
fout.write( "DATE: %s\n" % (timestamp,))
fout.write( "%s\n" % (subject,));
fout.write(comment + "\n")
fout.write( "-----\n")
fout.write('''--------\n''')
fout.close()

if __name__ == "__main__":
read_drupal("filename", "tablename", "server", "user", "password")

 

The second is a bit of javascript for creating a music player on blog enclosures. I'm posting about a minute of music, about every day, to my personal blog, and I'd wanted an easy way for people to be able to play it. So, I found a nice, creative-commons licensed music player called dewplayer, and wrote some jQuery code to find MP3 enclosured and add a player for them to the entry.

 

$(function () {
mp3s = $(".enclosureWrapper a[href$=mp3]");
mp3s.wrap("<div class='player-wrapper'></div>");
mp3s.each(function() {
elem = $(this);
wrapper = elem.parent();
song = elem.attr("href");
playerHolder = $("<div class='player'></div>");
wrapper.prepend(playerHolder);
playerHolder.flash({
swf: '/storage/resources/dewplayer.swf',
flashvars: {
mp3: song,
wmode: "transparent",
showtime: 1
},
params: {
wmode: "transparent"
},
height: 20,
width: 200
});
});
});

 

Because SquareSpace uses YUI internally, eventually I'll rewrite that code to just use YUI and swfObject. But, for now, it works and isn't too heavy, and has the advantage of only taking about 15 minutes to throw together.