Tag: design

I’m Dreaming of a Better Social Media Client

I’m not a big social media guy. I’m certaintly not a social media consultant, nor a maven. I never used MySpace at all, and I was not among the first to use Facebook, LinkedIn, Twitter, etc. But I do find all of those useful to keep in touch with a bunch of people using all of the above, and I’ve grown quite frustrated with the sorry state of the client applications I’ve tried. Even those whose features work well and look good, don’t really go after the core problem we all either have it or will hit: information overload.

Here is what I really want in a social media client application for “power users” who receive a lot on their feeds: follow a lot of people on Twitter, have a lot of friends on Facebook, 500+ on LinkedIn, etc. Today, these are power users. Over the next few of years, this will be “everybody”. Most of these features make a lot of sense for a business managing its presense.

Table Stakes – The Basics

Support the Big Three (Twitter, LinkedIn, Facebook)

… and hopefully several more. But don’t even come to the party without the big three. I’m looking at you, Twitterific on the iPad, which I otherwise enjoy (and use every day, and paid for).

Ideally, RSS feeds would also flow in, and perhaps email and SMS too. But I don’t want this to be a “unified inbox” to replace an email client; this information would appear here as context for smart reading.

Run On Many Platforms

Mac, PC, iPhone, iPad, Android, Linux, maybe even BlackBerry. It’s not necessary to start with all these, but the target should to end up with all of them and more, with the core features present everywhere. I’m not looking for crappy ports though. Native, good citizens.

Keep Track of What I’ve Seen

Keep track of what I’ve seen, automatically. Don’t show me again unless I ask. But the act of closing the app should be meaningless, in that it should not mark all data as seen. An example of what not to do is TweetDeck, which has various settings for this, of which I can’t find any combination that does the Right Thing.

Next, the less common ideas:

I Paid for a Lot of Pixels – Use Them

Single-column feed display GUIs? Great idea for a phone. Silly on a PC.

Like most PC users, I have a wide, high resolution screen. Like many power users, I have two screens on some computers. I payed good money for all these pixels because I want to use them. Therefore, when I’m trying to catch up with all these data/tweet/etc. feeds, I want software that makes good use of those pixels. Show me a rich, dense screenful of information at one. Make it look like a stock trader’s screen (or screens).

Our Eyes are All Different – Give Me Knobs

I don’t want extensive customization. I don’t want a whole slew of adjustments. I don’t want a Preferences dialog with 82 tabs. I don’t even want themes. I want a good, clean, default design… but with a few well-considered knobs. Perhaps something like so:

  • font/size knob – because my eyes might work a bit better or worse than yours, and my screen might be higher or lower resolution than yours.
  • information density knob – because sometimes I want to admire a beautiful well-spaced layout, and something I just want to pack more information on there.

Aggregate Across Networks

Many of the people I follow, post the same data to at least three social media outlets; then a bunch of other copy/paste or retweet it. Please stop showing me all that duplication!

Instead, aggregate it all together, like Google News does for news sites. Show me each core message once, and then show a (dense, appropriate) display of who/how the information came in. Include a sparkline and other charts to show the continued re-arrival of that same data. This way, I won’t have to endure the duplication directly, and I can more clearly see how information traverses the (underlying, human) social network.

Some Tweets are More Equal than Others

In an ideal world, every Facebook update, every Tweet, would be a precious flower, to be admired in depth. We don’t live there. Instead, there is a lot of noise; an example fresh in my mind as I write this is the TV show Lost. It may be a great show, but it’s not one I watch, so to me all the Lost chatter is noise. I’ve probably scanned/scrolled past a couple hundred of them (some of them duplicates) over the last few days.

Therefore, a good social media client will make it trivial (one click) for me to tell it which bits I am interested in and which I’m not. I’m not talking about a scoring system, just a simple up/down arrow, for a total of three bins:

  • Important
  • Bulk / default
  • Junk

Apply some automatic classification mechanism (like the naive Bayensian that’s been common for several years now in email spam filtering) to learn from my votes and apply those to future data. By default, highlight the Important, show the Bulk, and hide the Junk.

I Have Several Devices – Sync Them Now

I might look at this river of news on my Mac in the morning, then on my iPad at lunch, then on my Linux netbook in the evening, then sneak an iPhone peek at bedtime. Keep all that “what I’ve seen” and “what’s important” data in sync across them. This means that my dream social media client needs a backend service behind it. It is not necessary for the data feeds to flow through the backend system (thought it might be useful); just the user’s attention metadata.

I believe that most or all of those features will be common in a few years. But I’m annoyed by the tsunami of social media feeds now. Is something like this out there? Where?

I could build such an application (with some help!). I’ve worked with APIs of all flavors. I’ve done mobile. I’ve created GUIs that elicit a “Wow”. I understand servers, and asynchronous operations, and scalability, and SaaS. But if I built it, would anyone *buy* it?

Why Choose Custom Software?

To meet the software needs of your business, there are two main paths:

  1. Buy software “off the shelf”
  2. Build custom software (in-house, or with a development firm)

In most cases, off-the-shelf makes the most sense, and it should be your default choice:

  • Acquiring and deploying off-the-shelf software is usually faster than getting custom software developed. Even complex installation and configuration it typically faster than developing new software.
  • Off-the-shelf software is generally cheaper than developing your own. The development cost of an off-the-shelf package is distributed among multiple firms, possibly many firms worldwide. These many customers more than offset the extra cost of mass production and distribution. Comparatively, with custom software your business alone bears most of the costs.
  • Off-the-shelf software typically has years of testing and years of production use, as well as feedback and improvement, giving confidence that it actually works.
  • Off-the-shelf software may include a money-back guarantee in case it does not meet your needs.

For all these reasons, the option of designing custom software bears the burden of proof in your decision-making process.

There are good reasons, though, to consider custom development, especially in mid-sized or large companies. Under the right circumstances, these advantages can make the decision to develop software the best choice.

 

Read the rest on the Oasis Digital blog.

 

Fix It So It Stays Fixed: An Example

A recurring theme in our projects is a desire to “fix things so they stay fixed”. I have in mind writing about that idea in detail later, but for now I’ll start with an example of how to do so.

A common and useful thing to do with disk storage space is to keep old copies of important data around. For example, we might keep the last 15 days of nightly backups of a database. This is easy to set up and helpful to have around. Unfortunately, sooner or later we discover that the process of copying a new backup to a disk managed this way, fails because the disk is full: the ongoing growth of the backup files reached a point where 15 old ones plus a new one does not fit.

How will we fix this?

Idea #1: Reduce 15 days to 10 days. Great, now it doesn’t fail for a while… but eventually it fills up with 10 of the now-larger files. It didn’t stay fixed.

Idea #2: Buy a bigger disk (maybe a huge disk, if money is abundant). A while later, it fills up. It didn’t stay fixed.

Idea #3: Set up an automated monitoring system, so that someone is informed when the disk is getting close to full. This is a big improvement, because hopefully someone will notice the monitor message and adjust it before it fails. But to me, it is not “fixed to stay fixed” because I will have to pay someone to adjust it repeatedly over time.

Idea #4: Sign up for Amazon S3, so we can store an unlimited number of files, of an unlimited size. Thus will probably stay fixed from a technical point of view, but it is highly broken in the sense that you get a larger and larger S3 invoice, growing without limit. To me, this means it didn’t stay fixed.

Idea #5: Dynamically decide how many old backups to keep.

The core problem with the common design I described above is the fixed N of old files to keep. The solution is to make that number dynamic; here is one way to do that:

  • Make the old-file-deletion process  look at the size of the most recent few files, and estimate the “max” of those plus some percentage as the likely maximum size of a new file.
  • Compare that to the free space.
  • If there is not enough free space, delete the oldest backup
  • Loop back and try again.
  • Be careful with error checking, and put in some lower limit of how many files to preserve (perhaps 2 or 3).

Like all mechanisms, this one has limits. Eventually the daily file size may grow so large that it’s no longer possible to keep 1 or more copies on the disk; so in this sense it does not stay fixed; but it does stay fixed all the way up to the limit of the hardware, with no human intervention.

National Geographic Chartjunk

National Geographic generally has lots of high quality content, with very high production values and attention to detail in layout and design. Keeping that in mind, I noticed this chart, below in the Feb. 2007 issue on page 56:

This, sadly, is an example of what Edward Tufte calls “chartjunk”. It contains extraneous elements that don’t help:

  • The United States label seems quite superfluous.
  • The mileage scales (including a separate scale for Alaska!) are completely useless in the context of this chart.
  • The “Panic! Panic!” red color is unhelpful; the chart could convey its data more clearly with a range of colors to show the data, rather than only values of red.

Yet it is missing the obvious details that would help:

  • There is a color scale, with the midpoint marked numerically, but no indication of the range. The middle of the range is 494 “deaths per year per 100,000 adults 35 years and older”; that is marvelous specificity, but we aren’t told whether “Low” is 490 deaths per year or 4 deaths per year. Is “High” 500 per year, or 2000? Is the scale linear, logarithmic?

Unfortunately, the meta-message is to not trust this chart – to assume the person showing us this chart is trying to influence us by their choice of what tiny bits of data to include (the midpoint only) and the scary coloring. If it had all the data, I’d be wondering things like “why do so many more people die of heart problems in some areas than others?” rather than “I wonder if they data range is so embarrassingly small that the graph creator chose to omit it?”

Label Placement in Forms… I was wrong.

In the process of designing “forms” in applications (both web based and rich client), I’ve had several discussions about where field labels should be located on the screen relative to the labeled fields. I’ve usually pushed hard for left-aligned labels, to the left of the fields, because this looks most tidy to me; I assumed that usability would be good also.

Ooops, it turns out that I was wrong. Matteo Penzo found, in an eye-tracking usability study (at UXMatters), that the best arrangement is to put labels above the fields, second best is right-aligned labels to the left of the fields; and of the arrangements studied, my favorite left-aligned arrangement is worst. Bold labels should be avoided… at least I was already doing that right. In the future, I will favor labels-on-top or right-aligned also.

YouTube’s 45 Terabytes… no big deal?

Over at the Wall Street Journal and Micro Persuasion and Computers.net and a bunch of other places, a big deal is being made of the YouTube’s estimated 45 Terabytes worth of video. It is “about 5,000 home computers’ worth”. Ouch, 45 Terabytes! Wow!

Or maybe not… consider the mathematics.

45 TB really isn’t all that much data. I’ll assume that each video is stored on 6 hard drives across their systems, for reliability and greater bandwidth, for a total of ~300 TB of hard drives. A 300 GB hard drive costs under $200, and ~1000 will be needed, so this is about $200,000 worth of hard drives, which is not a big deal for a major venture-funded firm like YouTube. (Side note – if you need a lot of read-mostly disk bandwidth, you are much better off buying several cheap hard drives with the same data on them, than one expensive hard drive. It’s not even close.)

The 1000 hard drives might be spread across 250 servers. If their systems is build in the economically smart way (the Google way – lots of commodity servers), each server could cost as little as $3000. Those servers could likely serve the traffic also, as well as (at a lower priority) do any needed video transcoding of newly uploaded video. After all, it is mostly static content, and it’s likely that a small fraction of the videos are a large fraction of the views, so the popular ones stay in RAM cache. Adding other machines for various purposes, network hardware, etc., a YouTube-scale app/storage cluster might cost as little as $2 million, of which a relative small portion (above) is hard drives.

Of course I’ve totally skipped the question of paying for the bandwidth (and power), which must be staggeringly expensive.