Data integration lessons come from unexpected sources. I recently opened a charge card at Lowe’s home improvement centers: Great deal. My first statement provided purchase detail that I found helpful and a contractor would find absolutely compelling. Then I downloaded the statement into my Quicken financial software. #fail is the best word. Here’s the larger context:
My partner and I are doing a major remodeling project in a small town where a Lowe’s center is the only big box home improvement center in town. That forced us into the store even though our experience with Lowe’s in our home town of Tucson is not good. The staff at the new store turned out to be the most helpful, knowledgeable, and friendly retail team I’ve encountered in a long time. Chalk up a customer win for Lowe’s.
This story gains relevance to our work at Accurate Information when you follow the data path from Lowes purchase to accounting. We opened a Lowes charge card because they offer a 5% discount on any in-store purchase you put on it. That’s a big deal on this project.
The card is managed by GE Money Bank, and the integration between Lowe’s and GE is stunning. You can see on the statement exactly what each item was, and more importantly for a contractor their categorization is superb. It’s easy to separate plumbing fittings from electrical parts; tools from consumables; fixtures from cleaning supplies.
Then I downloaded the statement into Quicken, and all that great data just ended up in the bit bucket.
A typical memo field on the credit card statement might read:
PVC pipe fittings sch 40
while the Quicken memo field shows up as:
I did not check to see of the same loss of data occurs when using Quickbooks (which we use to manage Accurate Information), but there are a lot of contractors out there who run their businesses as sole proprietarships in Quicken.
Lowe’s, GE, and Intuit are missing an opportunity to make this customer base loyal to the point of giddiness.
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.
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.
Most business-to-business video and podcast productions I see (and hear) online drive me nuts. They may use the latest editing flourishes, provide elegant transitions and have great lighting and sound quality, but they don’t respect the environment in which they are consumed. Every time I’m faced with a voice-over introduction or a video title sequence that tells me the name of the production, who’s being interviewed, what products are being demonstrated, who produced the segment, and on an on I hear mouses clicking away in droves.
Until you hook me, I DON’T CARE WHAT YOU CALL YOUR SEGMENT. If I am in a conference room I’ll sit through the introductions. If I’m in a movie theater I’ll use the title sequence to arrange my popcorn box. If I’m on YouTube I’m off to the next funny cat.
The solution is a technique I adapted from years of editing and writing technical articles: the simple pull quote, aka sound bite. I began using this technique for a podcast series I produce for a client, and productions using the new format are by far the most popular.
The solution is a technique I adapted from years of editing and writing technical articles: the simple pull quote.
In case you’re not familiar with the term “pull quote”, you just read one. Unlike the sound bite, which has developed a reputation as being vacuous drivel often taken out of context, a pull quote is used to draw an audience deeper into a piece where the thought can be presented in it’s full context. The technique is simple and requires almost no incremental effort. Here’s my process:
- Edit the production as though nothing has changed. I do my podcast work in Adobe Soundbooth which provides great tools for noise reduction, internal edits to eliminate verbal tics, and multi-track mixing to lay in soundtracks, voiceovers, etc.
- As you’re editing, listen for the soundbites. For the podcast series in question I listen for 5 – 10 second clips that carry the core message of the segment and also telegraph human emotion. The audience for the series is mobile application developers so the content of the clip needs to have substance. For less technical audiences I would limit the sound bites to 2 – 5 seconds each.
- Every time I hear a potential clip I select it and “save as” a separate audio file. (Be sure to save it in a lossless format so you don’t degrade sound quality from multiple compression pipelines.)
- When you’re done with the body edit, go back and listen to your soundbites and select the one that is the most compelling. That’s your intro. I like to present it solo voce and unadorned. I follow it with a quick introduction of the speakers (preferably without distracting voice-over) then right into the content.
- If you absolutely must have an opening sequence, run it after the soundbite. Your audience is more likely to tolerate the intro now that they’re hooked.
Here are two podcasts that illustrate the technique: