Big stuff, check. Details, not so much.

I can’t believe I’m still hand-coding HTML in 2011. Not for fancy stuff, for basic functions that I should never have to mess with in this day and age. Let me explain.

A new venture on which I’m working just pushed our first “so beta” site live yesterday. The venture is Developer Think Tank, and my partner and I are building the site on Squarespace because they deliver on the big stuff for a reasonable price. For us, the big stuff includes:

  • Blog-easy content management with enough presentation-level control that not everything you publish needs to look like a blog. Squarespace calls these modules “journals” instead of blogs for good reason. Out the gate we already have two live journals — our blog (currently set as our home page) and our Developer Leader Profiles.
  • Appropriate template options. As anyone wading into big app stores knows all too well, it’s not quantity that matters. We considered hosting with WordPress, who have many more templates available than squarespace. Maybe it was just our preconceptions, but the templates we tested from WordPress all looked like blogs. Some looked like very good blogs, even great blogging sites, but we felt they made us look like a media venture. We found a collection of templates squarespace that makes the impression we’re after. (Note: this site is hosted on WordPress.)
  • User management. This was the clincher for us. With Squarespace we can segment portions of our site behind a pay wall. Multiple pay walls if we want. It can also handle registration and forms when we’re ready for that level of interaction.

The big features sold us on the service. It’s the little details that occasionally drive us nuts. Here are three:

  • Inadequate editor. Like any good blogging platform, Squarespace provides an online content editor for creating posts. In a quick review it looks powerful enough; you work in WYSIWYG mode by default but can choose to work in Textile, Markdown, or raw HTML. The problem is you can’t round-trip between modes. We were about to push the site live when I decided to clean up the formatting of our “contact us” list. It clearly needed a table. No table widget in the WYSIWYG editor. I figured I’d hack a quick one using Textile. No dice, when I drop into Textile mode it shows me the raw HTML created by the WYSIWYG editor. It then tries to interpret the HTML as Textile markup. The only solution I found was hand-coding the HTML table. Thus this blog post.
  • No style toolbar. Squarespace provides great freedom for customizing styles, but applying styles is clumsy at best. A service like this should have a style toolbar I can place where I want and apply styles from a menu. Squarespace requires us to go to the page we want to style and open up the “appearance editor” which occupies the bottom half of the active browser window. We position our content so it’s still visible above the style editor, then select the content in question to reveal the current style settings. It’s ugly.
  • No site-wide cloud. Squarespace includes tag cloud widgets, but they only index one journal on the site. We already have seven journal pages in progress, and as far as I’m concerned a tag cloud in the sidebar of a site better show me what’s on the entire site unless I have a good reason to restrict the scope.

Well, that’s my vent for the day. I guess like all choices in life, choosing your site hosting/creation service is a trade-off. The big stuff matters, but the little stuff will drive you nuts. And getting the little stuff right is often overlooked when marketing teams put together their PowerPoint presentation of the next great features to be released.

Social Media Data Mining Across Twitter ScreenName Changes

Well, I guess I should have seen that coming. For research I’m doing into the interaction among online developer communities, I’ve been building a data set of friends and followers of about 40 twitter accounts associated with community sponsors. I’m building my research tools on top of open source scripts published with Mining the Social Web by Matthew Russel.

I’m building the archive in a Redis open source key-value store instead of a more complex MSQL rdms, and I’m capturing and storing the values against keys based on the Twitter screen name. I love the readable nature of the Redis API as opposed to SQL calls, and the set functions in Redis are perfect for the research.

All was well until….

… yesterday when a branding change at Nokia changed their twitter screen name from @forumnokia to @nokiadeveloper. Nokia editor and social media guru Jason Black handled the transition perfectly, coordinating the branding change on their developer site with a change in screen name in their twitter account to preserve the conversations and the nearly 18,000 followers they have built on Twitter. He even used a second account to catch people who have bookmarks associated with the old @forumnokia handle and direct them to the new location.

So the transition worked relatively smoothly for Nokia, but I’ve got some work to do on my tooling and in my data set. Working with screen names makes for wonderfully readable code and data stores, but I need to change my lookup keys and API calls to use the stable userID field that would have handled this transition without a hiccup.

At one time Twitter did not allow users to change screen names, so I suspect the code from which I started is not the only code out there that needs updating.