People + Media + Messages = Social
Share
In a social application there are always two domains: the domain you define, or the ‘problem’ domain, and the social domain. A video-sharing web application, for instance, has no problem domain. Its entire story can be described within the social domain: it has users, videos, possibly forums, possibly blogs, possibly syndication of content. In other words, there are patterns we can apply that allow us to describe this system to a framework without writing any code, at least not code that isn’t contained within some higher API-level abstraction. If we aren’t there today, then we should move in that direction.
Whatever is unique about this video-sharing application compared to all the others, then, is the element we can design and layer on top of the framework. That is the element that we find interesting, that teammates are passionate about, and that the Internet population will find exciting (we hope). The more we are able to focus on this element, the more enjoyable the process will be. It is also a matter of necessity: any application that does nothing more than re-iterate the acceptable interactions in a social domain adds nothing to the conversation, and is ultimately forgettable. Thinking that you can “just add blogs and tags” is not going to take you very far.
The crux of a social application is interaction. If social software had a paradigm to follow it might be called Interaction Driven Design. In “Designing for the Social Web“, Joshua Porter calls this the AOF pattern, or Activities, Objects, and Features. We’re designing for the need for your application to arrange itself so that it is evident what a user does, and what benefit they get from doing so.
The application you build is merely the implementation details of taking a description of a problem domain, and how it is allowed to interact with itself and other domains, and coupling it with a description of how its users may interact with each other. The more we can describe about those interactions up front, the less code we need to write. It is fortunate, then, that we already know much about the social domain, and it enjoys a healthy amount of overlap between the typical objects that we might find in a social application: people + messages + media. Are there any social objects that don’t fit one of these categories, and are the contracts between these categories not well-defined?
This blog was formed to explore and define the social domain, that which you can separate from your “secret sauce” and is the most likely candidate for abstraction. The principle we want to follow is that choosing to build social software in .NET should mean that we get to move from a great software idea to an implementation that already possesses the social domain, so that the harder work of creating your own interactions, the ones that make your application unique, is both more apparent and has common ground to relate with.
Socialized