What is the Anatomy of an Application Site?

If you've been excited about the buzz in the past couple of weeks culminating in  yesterday's announcement that several big players - Microsoft, Yahoo!, Google, IBM, etc. - all joined the ranks of others in the OpenID Foundation to establish a single identity standard for individuals on the internet, you might be just as geeky as me and have way too many accounts that you've lost track of. 

Actually, you don't have to be a geek.  If you've used any service on the internet over a couple of years, you'll recall over that time having visited other sites that required you to create a username/password combo, only to stop visiting it for some time - long enough to forget the password - and then maybe return to find that you need to "recall" or "reset" your password/account.  No biggie, right?  Happens all the time.   And you can just create a new (free!) account again if you really need to.

But these legacy usernames are really only a small part of the problem.  The question of establishing singular identity for individuals on the internet has vexed web services for a while now and there have been numerous approaches taken to resolve.  And some individuals have enjoyed the freedom that this allows you to create multiple identities in the same web space.  It's an interesting phenomenon of the medium that's not worth the space to discuss right now.  You can actually set aside the problem of ID alone (that's what OpenID is resolving anyhow) and you still have a wide breadth of content managed by web services.

Instead, let's take a look at the architecture/anatomy of a web service.  I should start by explaining that I'm not referring to web services here in the traditional architectural sense but in a broader front-facing "storefront" presence for a web site.  in other words, any site that is not just a series of flat content pages as much of the internet was say, 13 years ago.  If there are dynamic content, feeds, username/accounts/passwords, shopping, transactions, saved pages, tagging, blogging, etc. it's a web service.  This amounts today to Social Networks, Google, Yahoo!,  banking and financial sites, most newspapers and journals, shopping sites, wikis, blogs, polling services, etc. etc.

What's important to think about these sites?  Well, actually to get back to the point of web services, architecture.  There's a lot of thought an time put into the process of defining and creating a site that provides services - that's why the analogy to real estate development (commercial, residential) is appropo in  this medium.  The thing is that there are a lot of "out of the box" frameworks that makes it easy to mash up a site today.  If your security needs are low(er), your ambitions are not too high, you can craft up a pretty useful small web presence for your organization or business around the framework of a blog, wiki, or content management system these days - and the best part is that a good number of them are open source these days.  If you're a large corporation, institution, or have ambitions of growing to that size and presence on the web, there's a lot of custom in-house architecture and building going on these days to fit those needs.  Other corporations might go with an "Enterprise Content Management System" like Vignette, SocialText, CoreMedia, Plateau, etc. and engineer the process of making that ready made system fit their purposes. 

The point is, whether you're a small public blog on blogger or huge financial service with heavy security services, there's still a number of common features for all of these services.  I mean, both an outhouse and a skyscraper have at least one door, right?  They both have some kind of plumbing.  They both have some kind of stuff around (toilet paper, air freshener, file cabinets), and they both have transactions that occur in them (use your imagination, not mine), and they both have time limits (i.e. you don't walk in and never come back out).  Think about that last statement.  You don't walk in to Facebook without knowing that at some point in time, you're walking out;  same with Google;  same with the New York Times;  same with Amazon; same with Moodle. 

An interesting thing about these services is that, they evolve (rapidly; think about how often a building or home is remodeled) and they tend to rely on our returning to use their services often and again to stay familiar with who they are and what they do for us.  I don't do go Amazon all that often these days.  I used to buy a lot of books and stuff of them about once or twice a month or so, but nowadays, I can go three months without visiting their site.  Amazon is a great example of a site with web services.  Early on, they were a site that I was enthusiastic about creating an account registering all my shipping addresses, creating lists of content that I liked, etc. etc.  Now when I visit Amazon, some things don't always look familiar.  These days, you get greeted on the Amazon home page by a great big fat advertisement for the Kindle.  No problem - they do want to revolutionize the reading/book experience.   But eventually, I get back into looking at my "recommended lists," my "wish lists" my reviews, etc. - whatever I remember from my last experience at Amazon that was effective.

I have a similar experience when I revisit something like bebo which I never really used all that much - I'm still not entirely sure what makes it useful and when I visit it on occasion, I get pretty confused finding my way around.  Facebook had an interesting idea when they released a piece of the framework API to make it possible to "embed" or wigetize applications from other sites into the Facebook architecture.  But nearly a year later, there have yet to prove to be any real interesting applications that fit the framework that make any real sense.  I mean, this is a stretch, but I'd much rather login to google (or better yet petechen.com using google apps in the back) and access my email, my calendar, and edit my docs than try to organize things with the applications made for facebook.  In short, what I've always been saying is that, Facebook is a wonderful social networking application that has found a niche that bridges the 20-40ish crowd but it's hard to envision it ever being a platform that makes business sense.

Which is a long way of finally getting to my point - what makes business sense is 1.  understanding the needs of business, 2.  being able to design and construct utilities (solutions, applications, programs, idioms, choose your businesspeak) that  addresses those needs.   I think that many internet services (often mistakenly) believe that they do the second point so well that they end up doing a marginal job addressing the first.   The frameworks and tools that are out there today are really cool and fun stuff - it's like  having  a lot of really powerful tablesaws and nailguns and great quality wood, but there's such a rush to create "great sites" that you end up with these "office buildings" that have too many toilets - all on the same floor; or too few elevators or no recycling bins for all the spam, you get the idea...

So what is the solution here?  Well, I think we've started to see a cresting of Enterprise applications that have been built in a really unwieldy manner.  Companies don't stand for expensing out an application that they only use 5% of because the other 95% is incompatible or does not integrate with existing datasystems.  We've been led to believe before that all data was transformable into different systems and that process has gotten much better but we're still dealing with very large applications.   I like the approach where application building is more modular and built around the front end experience.  The  thing is there's a lot of garbage in the middle of the experience but what people want is their food in, and their waste out.  It makes for a more complicated task between the UI/UE people and the architectural team however, that process is getting better with every iteration of software that we see out there.  We also see that there is a base framework for "social applications" that include "personal information" (photos, location, im handle, etc.) could carry over from app to app.  Shopping sites allow users to "save" shopping lists and wish lists etc. that could match up with what other retailers might be able to consolidate and increase savings.  Learning and content management systems (that includes blogs, journals, newspapers) keep content within their domain such that there isn't much portability even though a user might want to aggregate, organize, AND add to the informational "collage" that they collect.  You get my point here.  The experience of web applications actually needs to get away from the site itself and shift back to what the end user want to use and make of that information. 

Now I'm not saying that we need to build a "desktop application" that resolves these issues.  I have a great citation management tool that I've been using the past few months that sits in the corner of my browser window called Zotero that I use to "save" articles and such.  And I've used del.icio.us for a couple of years to bookmark sites - these things are close but not perfect to a real custom user oriented organizational experience that makes business sense. But I think that if we think closer to the anatomy of what a web application is - like we were talking about earlier - we can get closer still, and really make great applications that will be well used and embraced but the business an general community.

Blogged with Flock