Archive for the ‘Web 2.0’ Category

Scrybe - It’s Cool But Who’s Going to Use It?

Saturday, December 1st, 2007

I just finished my first thorough usage of Scrybe, which is a new approach to online calendar tools.

It’s interesting. Strange… but interesting.

If you haven’t already seen it already, I recommend starting with this introductory video they put on YouTube. If you’re like me, it will pique your interest, and then raise some questions. I’ll try to answer some of those questions.

[youtube 1u3ekzwnYxw The Scrybe demo video]

What kind of technology is that? AJAX?
About 70% of my initial fascination with Scrybe came from my hope that it was built with AJAX, or some other basically-open technology. But in reality, it’s just Flash. Yes, it’s one big Flash application. And, honestly, that bores me a little bit. To be fair, it’s an extremely well designed and coded Flash application. It feels good to use — smooth animations, short loading times, modern UI conventions. It’s also database-driven, so I’m not quite so worried about my data being locked up inside a proprietary application. But it also has all the limitations that come with a Flash website.

Will it import my existing calendar?
Scrybe imports from two formats: iCalendar and CSV. The good news is that iCalendar covers almost all your bases. If you use Outlook, Google Calendar, Groupwise, or Apple’s iCal, then you’re in luck. All of those, and many others, can export to iCalendar format. For my test, I imported my Google Calendar which has next to nothing on it. All my events came through just fine, but I wasn’t able to test meeting invitations.

The interface looks great on that demo. Is it really that good?
Demos never tell the whole story. In a video, the demo guy always knows right where to click and most features are already set up to make a good show. My experience, however, was still pretty good. Their UI claim to fame is this “keeping things in context” approach. So when you move from the year view to the month view, the UI zooms in to that month. And when you click a day, that day expands within the month view. And when you click on an hour within a day, you zoom in to the details of that day. It’s nice eye candy, but I’m not sure how much benefit it adds. I use Outlook all the time at work, and I never really felt a loss of context. Sure, Outlook doesn’t zoom and pan like Scrybe does, but it’s still pretty clear what’s going on. I consider this more of an eye candy effect than a useful UI change. But it may help some people to understand their calendars better.

There’s also a few scattered artifacts of bad or incomplete design in their UI. Take a look at this screen shot:

Scribe UI Blunder

What do you suppose that little carrot in the bottom right corner does? Any guesses? No?
Clicking it reveals a drop-down list of miscellaneous extra functionality. Probably a bunch of features they decided they want, but didn’t know where to put.

Honestly, the calendar UI is quite good and innovative — a tough combination to achieve. The ThoughtPad feature, on the other hand, was not as impressive. More on that later.

How does the Offline Access feature work?
I’m not totally sure. My guess that Scrybe keeps a copy of your data on a server somewhere, and then regularly converts the database content into CSV format (or something similar), and then saves that in your browser cache. Maybe it puts all your calendar data into a cookie. I could do some tests to find out if anyone is really curious. At any rate, the feature works exactly as advertised, and it’s pretty cool. Well, except for in Safari. I couldn’t find a “Work Offline” function in Safari, so when I tried to log in without a connection, it just tried endlessly to access their server.

Thought Pad looks awesome in the demo. What’s your problem with it?
Scrybe treats the Thought Pad almost like an entirely different application, which is probably good. But the Thought Pad UI is very strange. When you click into the Thought Pad tool, you’re presented with a sort of inline tutorial, with arrows pointing to the various parts of the UI and explaining what they are. All UI designers know that kind of thing is almost always a tacit recognition that the design doesn’t make sense. In this case, it’s definitely true.

The inline tutorial helped me add a neat little link (they call it the “Scrybe Bookmarklet”) that, supposedly, lets you paste web content into your Thought Pad. You’re supposed to add this link to the bookmarks bar in your browser. When you select some text in a web page, you then click on the “bookmarklet”, and somehow the content gets into your Thought Pad. Sounds pretty neat, but it definitely didn’t work for me. I tried it in Safari and Firefox, and it didn’t work in either. Probably a known bug in the beta.

In my attempts to use the Thought Pad, I wasn’t able to create anything as rich and pretty looking at the Thought Pad in the demo. When you edit a note in the Thought Pad, you have some basic text editing tools, and some tools for inserting links, pictures, and videos. Only the text editing tools worked when I tried it.

The Thought Pad uses a unique paradigm for creating and categorizing the notes you create. I really didn’t like it or understand it at first, but I finally figured it out. It makes sense, but I just have to ask “why?”. What does this gain over a traditional create/categorize approach? It seems like a steep learning curve for no particular reason.

I wish I used Google Notebook to know how it compares.

How do the printed calendars look?
I printed my calendar in a couple of the formats available. The feature works as advertised, and it’s exactly as cool as having a printout of your calendar sounds like it would be. Of course, those people who would rather sync their calendar to their PDA will be grossly unsatisfied.

Any final thoughts?
It’s neat, but I don’t foresee it becoming broadly popular. Maybe that’s because, as a limited beta, it’s missing all the social networking features it needs. Why can’t I share my calendar with my wife? Why can’t I publish my calendar on my web site?

It’s also missing some critical functions to compete with Outlook in the business user market. I don’t know of any way for a Flash application to sync with a PDA, but then again I don’t know too much about Adobe Flex or Adobe Air or the other new advances coming soon.

But for right now, here’s the market for regular Scrybe users: very web-savvy, probably young, interested in keeping a calendar, and no PDA or iPod that they want to keep their calendar on. My gut says that’s a small market. But for those of you who are in it, be sure to check out Scrybe!

Hulu Review (It’s Fun To Say Out Loud)

Tuesday, November 27th, 2007

Recently, I realized that I have been neglecting to use a number of invitations to private beta sites, including:

Hulu - A joint venture between NBC and FOX to stream TV episodes online

BAAGZ - A unique combination of social networking and semantic search

Sandy - An electronic personal assistant that understands emails you send to her and sends you reminders (among other things)

Scrybe - An extremely Web 2.0 approach to calendars, but with unique features like the ability to view your calendar while offline or print a pocket calendar

So I’m making a point to try these sites and write reviews here. Today, I’m reviewing Hulu…

Initially, I’m pretty impressed with Hulu. It seems like a solid user experience paired with a nice technology for streaming video. It’s also nice to have a somewhat wide variety of videos at one site (unlike the NBC, FOX, ABC, and other video streaming sites, which are generally limited to a single network).

First, let’s examine the user experience.
You can browse videos through three methods:

  • Most popular
  • Divided by network/studio
  • Alphabetical listing

This seems like a pretty reasonable set of options to me.

Once you select a show, you’ll see an array of large thumbnails with episode name, number, and length. Once you choose an episode, there’s a few seconds of buffering, then a 5 second ad, and then the episode begins.

The default video size is reasonable. The video controls are visible briefly, and then they hide on the sides. When you mouse over the video, you’ll see video controls on the bottom, and a variety of other controls on the left and right. You can’t scrub through the video, but you do have pretty fine control over where you jump to, and there’s only a moment of buffering before the video starts again. (For reference, I have a relatively slow broadband connection. Your mileage may vary.)

The controls on the left include Share, Embed, Details, and Feedback. Of these, Share and Embed are definitely the most interesting. Share lets you send a link to the video to a friend. But before you send the email, you can drag a couple of sliders to create a custom snippet. When your friend clicks through the email to watch the video, they’ll start out at the beginning of the snippet you created (though the whole episode will be available).

Similarly, you can embed an whole or part episode using custom snippets. I’ve embedded a video snippet below. Notice how, after the snippet plays, you can watch any or all of the episode.



Important Note: The quality of these embedded videos is much worse than the quality when you watch directly on Hulu. Too bad, because it makes them look lame.

The tools on the right side include Full Screen, Pop Out, Lower Lights, and Rate.
Full Screen provides a truly full screen experience, meaning the video extends outside your browser window to take up the entire screen.
Pop Out puts the video in a new window (although you’re limited to a small video size in that window).
Lower Lights puts a semi-transparent gray overlay over the rest of the web page, giving the appearance that it has been dimmed. (This could be much better if it was more like the Divx feature that more literally dims the screen around your video, and which is not limited to the browser window.)
Rate allows you to give the video a rating between 1 and 5 stars.

Beneath the video, and beneath the other episode thumbnails, and then beneath the related video thumbnails, they have tucked away user reviews. This is just a standard place for users to rant about what they like or don’t like. It’s sort of an expected feature for video sites, even though I feel like it ads very little value.

I did notice a couple of problems that indicate to me why it’s still in beta:

  • The site is pretty good about picking up a video where you left off. Meaning, if you’re half way through Video 1, and you decide to click on a different video, but then go back to Video 1, it will pick up right where you left off. Unfortunately, it doesn’t work under certain circumstances.
  • The custom video snippet feature I mentioned earlier is a little buggy. If you create multiple snippets from the same video, it doesn’t always update the <embed> code with the correct time codes.
  • There’s a bit of a usability problem with the video navigation. When the video progress bar is minimized, it spans the entire width of the video, but when it’s fully visible, it only takes up about half the width of the video. So if you’re trying to navigate to a spot in the video when the bar is minimized, but then move your mouse one pixel too high, suddenly your mouse is on the mute button instead of the progress bar. It’s tough to explain, but it gets annoying quickly.

Overall, though, I definitely recommend that you sign up for the beta. It strikes me as much more well conceived than either NBC’s or FOX’s TV streaming sites. For sure, Hulu plays to a different audience than iTunes. If you like to own your TV episodes, this won’t help you. But if you’re just looking for a good streaming experience, Hulu is worth looking at.

(more…)

Adobe Thermo - Deserves a Second Mention

Tuesday, October 30th, 2007

I mentioned Adobe Thermo in an earlier post, but I recently found some more information that I thought was worth sharing. Peter Elst was able to snag a video of the Thermo demo at Adobe MAX in Chicago earlier this month. It’s just as awesome as you would hope!

If, as a designer, you’ve ever looked at a mockup you created and said to yourself, “I wish there was an easy way to make this just work” then Adobe Thermo is for you. After seeing how you wire together the parts of a mockup, it looks to be about as easy as you can make it. Well, it’s as easy as I can imagine it, which I think is saying something.

As Edna Mode from The Incredibles would say, “Words are useless, darling! Gobble gobble gobble gobble! There’s too much of it, darling, too much!”

[youtube ELM7rPiQyQY]

So I recommend you just watch the demo here. Be forewarned, the picture is really grainy. But if you’re interested in the next generation of rich internet applications, it’s a must see!

My only lingering question is about the fact that Thermo builds Flex applications, and I’m not sure how I feel about Flex. First, it’s an essentially proprietary format, like a Flash application. Even though Adobe has gone to great lengths to make Flex open-ish (e.g. announcing plans to make the Flex SDK open source), I would still prefer to build something that doesn’t require a special plugin. That’s strike one. Second, I’m not sure how accessible Flex applications are. Right now, the Flash plugin isn’t very friendly with screen readers and other assistive technology. That’s a potential strike two.

But, on the other hand, even if both of those turn out to be real problems, Thermo would still be a useful tool for communicating designs internally and to clients. Also, Flex is tied to another Adobe technology called Air, which promises to make Flex web applications into desktop applications that can run on Mac and Windows. So even if I can’t feel good about building Flex applications for the Web, it might still be a good option for desktop applications.

Bottom line: Keep an eye on this technology. I’m hoping it turns out to be great.

Adobe Thermo Rocks My World

Tuesday, October 2nd, 2007

I have a habit on this blog of complaining about something, and then quickly finding out that problem has already been solved (perfect example). Well, I say that’s good! Go on, World, give me less to complain about!

In this case, I recently complained about the state of rich prototyping tools, but then today I heard about new beta software from Adobe called Thermo. I’m fully expecting to love Thermo. Adobe’s article on it is extremely short winded, but it sounds very promising. In essence, it lets you draw a user interface (which I love doing in OmniGraffle and Visio) and then wire it up to act like a real website, without writing code. But the code it generates for you is actually usable! A developer can take the UI you’ve mocked up and turn it into a working Flex website.

If Thermo works as I understand it, then it solves all my major complaints about prototyping tools. I still get to draw my UIs, plus I can add interactivity without fiddling with code, plus I can turn my prototype into a working solution.

Of course, I’ll reserve final judgment for when I get to use it. For example, I’m guessing the rich interactions I have to choose from will be somewhat limited, especially at first. I could see Thermo providing a drag-and-drop interaction, but maybe not something more exotic, like an AJAX window resizing interaction. Version 1 will probably still require some hand coding to get just what you want. Nonetheless, I’m excited! Adobe, I’m ready to be a beta tester!

For a little more information, I also found an article at MacWorld magazine.

Apple Posts Human Interface Guidelines for the iPhone

Monday, October 1st, 2007

Apple is already well known for it’s original Macintosh Human Interface Guidelines (HIG), which have been deprecated by the new Apple Human Interface Guidelines, tailored for Mac OS X.

Now, Apple has introduced a HIG for the iPhone. The document is primarily about making web applications that look good and work well on the iPhone. I skimmed through it, and I don’t see too much that’s ground breaking. Basically, if you’re an iPhone web designer with much design sense, the HIG will save you a few hours of trial and error. Still, it’s cool that Apple is providing one. It suggests they’re taking iPhone development seriously at a time when they’re clearly cracking down on unapproved 3rd party iPhone applications.

One interesting thing that jumped out at me in the iPhone HIG is this picture of a “Multiple select element”.

iPhone Mutliple Select Element

I haven’t used the iPhone much, but I’m interpreting this to be something like a drop-down list, but with the ability to select multiple options in the list. If this convention is something we can apply to normal, non-iPhone web pages, then it would be a huge space saver in some instances. Can anyone who has used this widget before comment on its usefulness?

The multiple select element is described in the iPhone HIG here:
iPhone HIG > Metrics, Layout Guidelines, and Tips > Be Aware of Default Control Styles

As a side note, for those interested in iPhone development, you should check out the Interactive Gestures Pattern Library, (the brainchild of Dan Saffer). It’s a wiki designed to collect touch interface design patterns, such as those used in the iPhone. The goal is to create a set of touch interface best practices, so as touch interfaces take off, all our future devices work similarly.

The Awful State of Web Accessibility

Saturday, September 29th, 2007

This past week, my company has been promoting web accessibility through a series of seminars that explain its importance for business and some techniques that we can use to make our web sites more accessible. On Friday, I attended a seminar hosted by the Cincinnati Association for the Blind and Visually Impaired (CABVI), in which they demonstrated how web sites appear to users with poor or no vision.

For those with poor vision…

For users with poor vision, they have applications that can zoom in so close that the icon for one application basically takes up the entire screen. These users work more slowly, since they have to pan around the screen a lot, but they can still use most web sites. Mainly, you just want to provide ALT tags for your pictures, since it’s hard to tell what something is at that close range.

For those who are blind…

For users who are blind, they have applications such as JAWS or Window Eyes, which read the screen for you. This is a totally crappy experience on the web. Really, I can’t exaggerate how bad it was. They guy who demonstrated these tools is an instructor at CABVI, and he seemed about as savvy as you can get with the software — and it was still awful. The software provides a lot of keyboard shortcuts, such as a key to move down to the next heading in the text, or a key to open a list of all the hyperlinks on the page. These keys helped a little bit, but you still have no sense of context for what you’re hearing. The screen reader tells you the name of a link, but you don’t know if you’re in the main nav, somewhere in the body (left column, right column, a call out), or in the footer.

Filling out a form is next to impossible. Screen readers operate by reading the HTML behind the page, not the page you would normally see. So when the user tabs to a field, it often just says “edit field” without providing the name of the field. Who knows if it wants your name or your phone number or what. Unless the name of the field is directly before the field itself in the HTML, the screen reader doesn’t give you any context. (And although it seems like it would be easy to write HTML with the name of a field next to the field itself, it’s not. A lot of forms are built with ASP.NET or JSP, and it seems like those languages sometimes separate HTML and forms automatically.)

What can be done about it? - Part 1

In the meeting, my friend Ian asked if the people at CABVI have ever heard of Quicksilver. For those who don’t know, Quicksilver is an amazing program for the Mac. It’s like Spotlight, except much much cooler. You can find any file (let’s say a song) and do almost anything with it (e.g. open it with any application, play it in iTunes, show it in Finder, etc.) all with keystrokes. I think this would be especially cool for the blind because it’s very intelligent. For example, you could type “ffox” to find Firefox. The first time you do that, Firefox might not be the first result, but then next time you type “ffox”, Quicksilver is smart enough to know that “ffox” means “Firefox” to you. The developer, Nicholas Jitkoff, explains the theory behind his application in a Google video (warning: Nicholas is brilliant and worth listening to, but he’s not the most engaging speaker). In fact, his philosophy was a partial inspiration for my Google Social application.

So Quicksilver might be a good solution for the visually impaired on the Mac desktop (has anyone tried this before? can anyone confirm it?), but it doesn’t help too much for browsing web sites.

What can be done about it? - Part 2

My initial impression is that the people who develop screen readers are going to be constantly at odds with the legions of people who make web sites. Web developers are always finding new ways to do things, and web designers are interested in whatever technology helps websites look better (even though those advances generally seem to hurt accessibility), but almost nobody is thinking about accessibility. So these people developing screen readers are working as hard as they can to keep up with technologies that weren’t build with them in mind.

That reminded me of an important idea (that nobody talks about anymore) called the Semantic Web. According to the guy who invented the current world wide web, this is the future of the internet. Basically, it’s a new form of markup that allows machines to really understand what’s on the web.

Imagine, if we has semantically accessible web sites, your computer would know if a link is part of the main nav or part of the body. It would know the name of every form field. The computer would know what’s inside a picture. In the short term, this means your screen reader could actually be useful. In the long run, it means you could give your computer a command like “order me a medium pepperoni pizza from Pizza Hut” and it would do everything for you (like the Star Trek computer!)

Bottom Line

Those of us who are shaping the direction of the web need to support accessibility. My feeling is that making the web more accessible for the disabled will ultimately make it more accessible for everyone.

Web Prototyping - Tools and Techniques

Tuesday, September 25th, 2007

I’ve been thinking about picking up some additional skills, specifically around rich prototyping. So I’ve done a little reading, and I have a short list of options for creating Web 2.0 interactions in prototypes. Fair warning up front… I have only questions about these tools, no answers. If you have answers, please share!

First, there’s a new resource called Protoscript that claims it can help me easily add AJAX interactions to my websites. It looks fairly promising, but my immediate question is: why is this only for prototyping? If I’m adding rich interactions to my website, why can’t I go live using the same scripts?

From what I can tell, Protoscript isn’t substantially different from script.aculo.us, except script.aculo.us looks to be better documented.

But my feeling is that, in terms of time commitment, diving into all those javascripts is only one step down from learning Ruby on Rails.

I’ll confess to something up front… I can code, but I don’t like to. There’s nothing worse, for me, than trying to express an interaction I want, but being unable to because I can’t get some dumb script to work. That’s like asking a graphic designer to figure out how to get CSS floats to work at the same time as he’s coming up with a design concept. You don’t want to be struggling with a language that has its own quirks while you’re still working out the ideas in your head. So I know that the instant I have trouble getting a technology to work, I’ll go back to my trusty old copy of Visio, or OmniGraffle, or a paper and pencil.

This leads me to a product from Adobe called the Spry framework. Like Protoscript and script.aculo.us, it’s a javascript library that you can plug into existing web pages. However, it sounds like Adobe has gone to great lengths to simplify the process. They claim that using Spry is akin to using HTML, so you shouldn’t have to learn a lot of new tags. This sounds promising, but I’m still expecting something better. I’m expecting deep integration with Dreamweaver, so I can just click a few buttons and set a few options to add rich interactions to my web pages. When Adobe builds that, I’ll be on board.

In the mean time, I’ll probably stick with low fidelity methods of showing rich interactions (e.g. sketches, verbal descriptions, and a little hand waving). I wish I could find a link to a PDF I read recently. I’m almost positive the article was from Adaptive Path, and specifically from Jesse James Garrett. The document describes three non-rich methods for expressing rich interactions. My favorite of the three methods was just a sequence of static wireframes. So, for example, if you’re showing drag-and-drop behavior, you would have three frames — one for the object being grabbed, one to show it being dragged, and one to show the object dropped. I can wireframe that up in a minute, rather than taking an hour to fiddle with scripts.

But, admittedly, non-rich prototypes of rich applications fall a little flat when it comes time to demo. Which is why I’m still on the lookout for a tool that will fit my needs. If Adobe doesn’t rush to fill this need with Dreamweaver, I’m sure Microsoft will with Expression Web. (Hint, hint, Adobe!)

Google Social - A Thought Experiment with Clickable Wireframes

Monday, September 17th, 2007

I read an interesting article today. The Creative Director at frog design, Robert Fabricant, critiqued the iPhone for already showing it’s age. He picked out five “mistakes” in the iPhone, I think primarily pointing out that Apple wasn’t able to foresee some user interface and technical developments that have occurred since they started designing the iPhone who knows how long ago.

Some of his points don’t interest me too much, like when he says the TV icon for YouTube and the camera shutter animation are outdated. I would tend to think those were conscious design decisions that Apple made to give the device a warmer, more human feeling. But one of Robert’s points really hit home with me. He pointed out that the iPhone forces you to view your contacts as a feature of the phone tool. It would have made more sense, he argues, to let users see a list of contacts, and then choose any of the available methods to communicate with that person. For example, you would click on the name of a friend, and then choose to call, text, or email that person.

I’ve been thinking along the same lines for a new web application. In my head, I’ve been calling this application “Google Social” but it’s important that I point out that this is in no way affiliated with Google. I’m using their name as a conceit, because when I dream of web apps I dream in Google (and sometimes 37 Signals).

So what is Google Social? It’s a web tool that shows you a list of all your friends who are on the web. You click on a friend to view the social networks that they belong to (e.g. Facebook, LinkedIn, YouTube, etc.), and then you see a list of that person’s recent activity on that social network. It’s nothing terribly new — you can probably do most of this today through RSS and email notifications.

The important thing to me is the change in mindset. I’m no longer thinking “I’d better check LinkedIn to see what my contacts are doing.” and “Now I need to log in to Xanga to check my friends’ blogs.” and “Now I need to go to my friends’ Flickr accounts to see if they’ve posted new photos.” Instead, I go to Google Social and think “I wonder what Chris has been doing.” It’s a human-centered approach to social networks, instead of a platform-centered approach.

This web application interests me so much that I couldn’t help but design it in wireframes. So I invite you to look at Google Social, as presented in beta clickable wireframes.

These wireframes aren’t great, but I hope they communicate what I was thinking. You’ll notice some red dots around the pages. Not everything is clickable yet, so you’re mostly limited to what has a red dot by it. It’s like a Choose Your Own Adventure wireframe.

There are two ways to add friends in Google Social. First, you can search for people who have already created Google Social accounts. When you find someone, you can invite them to be your friend (very similar to LinkedIn). If they accept your invitation, then that person gets added to your friends list. Alternately, you can create a friend from scratch. This involves entering a fair bit of information. For example, if you have a friend who is a user on YouTube, you would need to enter her YouTube user name. Then Google Social monitors YouTube for any activity by that user and pulls it in for you to see. I’m hoping a lot of this kind of activity can be handled by RSS feeds that social networks are already putting out.

I know some things are still missing. I haven’t designed the sign up process yet, but it will be very important. It’s also missing a notification center for viewing invitations you have sent and received. It’s probably also missing a lot of other important stuff. But, hey, it’s only beta!

Please let me know what you think. Is this a compelling way to keep track of your friends online? What would make it better? Do you see any interaction problems?

OpenID and PeopleAggregator

Saturday, August 25th, 2007

Additional research keeps killing off my complaints about the state of social networking. It turns out that there is an open standard for describing people online, and it’s called OpenID (more on Wikipedia). It was created by someone at LiveJournal, and integration of OpenID is planned for Firefox 3 and Widows Vista. So this standard seems to have some momentum. What it needs is larger adoption from the white label social networking platforms I mentioned earlier.

Fortunately, I’ve found at least one platform that seems to be supporting it. Everyone needs to take a look at PeopleAggregator. They have a fantastic feature set, a great stance on open standards, and what appears to be a robust set of APIs. I’m going to show this to a colleague at work and see if it really is as good as it looks.

Here’s hoping!

It’s Called a “White Label Social Networking Platform” not a “Set of APIs”

Saturday, August 25th, 2007

Earlier, I pointed out three problems I see with social networking. My first two problems are, I think, still valid. But I’ve done a bit more research and found out that there is probably no need for another startup to create a set of social networking APIs. They would be entering an arena with at least 40 other competitors. Apparently, in my earlier searches, I wasn’t using the correct terminology. These companies that make APIs for social networking are called “white label social networking platforms”. “White label” meaning anyone can rebrand them.

I haven’t had the time (and who would?!) to look at all 40 of these platforms, but I can already share some preliminary thoughts…

First, the current arena of social networking platforms looks like many other emerging categories have looked before. There are way too many competitors for the marketplace. In the next few years, these competitors will die off, merge, or get bought. Ultimately, I’m guessing the major players will look like they do in other software categories. Microsoft will have SharePoint; Google will have its offering (probably a revamped version of a startup they’ve bought); maybe one more name brand offering (like Cisco or Oracle); plus one or two others that develop organically out of the mess of current competitors.

Second, I’m immediately drawn to a couple of the platforms I see on Jeremiah Owyang’s list. Ning looks awfully interesting, in part because of their feature set and in part because I just learned that they’re one of Adaptive Path’s clients. Ning gives me almost everything I’m looking for: a flexible tool for deploying user profiles, blogs, and groups, the ability to search for users within my social network, the ability to host my social network on my own domain, and the ability to include (or not include) advertising. However, they don’t make the cut simply because they don’t allow me to make my social network as independent as I’d like. What I mean is, your social network is always going to be a Ning social network. You can’t integrate a Ning social network with an existing registration system. And when a user registers to use your Ning social network, they’re also registered to use every other Ning social network. This is a major shortcoming for business applications. For a company that wants to create a social network, half the point is to get a bunch of users’ names and email addresses into your database so you can start sending them emails and coupons. Until Ning makes that possible, I don’t see it being used for many corporate-run sites.

Third, I’m scanning Jeremiah’s list to find a platform that is open source, modular, and purely utilitarian. I’m looking for the social networking platform equivalent of PHP or WordPress. Something easy to set up, without a lot of branding, lets me remix the features in a modular way (e.g. I want to install forums and blogs, but not groups), provides a registration engine, but also lets me integrate with an existing registration database. I haven’t seen one on the list that sounds like that yet, but I’ll keep reading. For my money, that’s would be the best of breed winner.