When it comes to use of social media in development, development institutions remind me of lumbering elephants walking down the autobahn. In any other sphere, development organizations would not be at such a disadvantage. We have been building roads for ever. There has not been any fundamental change in the technology of building roads. Development organizations learnt slowly but well about development challenges in various sectors and are now legitimate experts in these areas. All the same the title of “knowledge institutions” is a bit hard to swallow. The reason, probably somewhat unfair, is that knowledge today, for most people is intimately tied to technology, social media too is viewed as a medium for knowledge, much like the network of roads and highways are a medium for commerce.
However when you look at development organizations today – do you have operational staff with more than a basic knowledge of social networks? Most development organization staff probably have a Facebook account and stop right there and this is just from a user perspective. Development staff who are looking into using social media in project design need to go beyond a user level familiarity with social media.
Quite rightly, fiduciary and safeguard concerns have made modern development task teams expand to include financial management, procurement, safeguard expertise, as well as balance out sector-specific concerns such as Gender. However technology specialists are not a mandated part of task teams in development. In a world which is being increasingly ruled by technology, such laxness is worrisome.
However this does not mean we need technology folks with Masters in Computer Science and years of experience in SAP or the like. For development folks trying to use social media effectively, we need knowledgeable, tech geeks that are plugged into the social network, and who can learn quickly and effectively even in an environment of change. And, of course, they need to be savvy enough to understand the needs of development and go beyond purely technology solutions.
Building a Web 2.0 “app” is something that a modern task team engaged in development should be able to do. A Web 2.0 app is essentially a computer program that must follow a set of rules prescribed by the Web 2.0 data provider (e.g. Facebook, Twitter) to interact with their data. These rules determine how an app must identify itself to the data provider’s server; establish the syntax of the commands to be used to access the data and the format in which these data are returned to the requesting app. These set of rules are referred to as Application Programming Interface (API) and is the key building block of any Web 2.0 app.
The ability to cope with change is also very important. One has to deal with a lack of stability in the environment, in terms of documentation, constant API changes, and changes in authentication procedures. If the APIs were well documented and relatively static, developing useful applications would have been a fairly routine task. This is absolutely not the case due to the highly dynamic nature of Web 2.0 entities. Take Facebook for example. They are arguably the largest data provider of Web 2.0. The API documentation of Facebook has never been very good and the API has undergone significant changes, with the last big overhaul in April of this year.
The most current version of the API is named the Graph API to emphasize the significance of a “social graph” being the central point of Facebook data. The older API is called the REST API. REST stands for Representational State Transfer, which is a software architectural style for distributed hypermedia systems like the Web. The term originated in a 2000 doctoral dissertation Architectural Styles and the Design of Network- based Software Architectures about the web written by Roy Fielding (both APIs follow REST principles so it’s a bit of a misnomer and creates a lot of confusion). The old REST API in Facebook still works, but only partially. To get an app done, you may have to use both REST API and Graph API. The authentication process, whereby identity is verified, was also changed completely by Facebook. There is hardly any sample code or any real migration help. This seems to imply – if you are not being able to figure it out – you do not deserve to use it! All of this makes Web 2.0 programming difficult.
A more specific example? This weekend I tried to build a simple app in Facebook using PHP (a very popular Web 2.0 scripting language) to return the status of users. However my Facebook Query Language (FQL) query (using the Graph API) did not work and in a forum, one of the programmers commented that unless you put a limit on the number of results that you want, you will get an empty array back. This was not mentioned in the Facebook documentation. The biggest help one can get in web 2.0 programming, at least as far as Facebook is concerned is from other programmers, which means, for the most part, you are on your own.
I have described some of the potential issues in Web 2.0 programming mostly using Facebook as an example; however the rest of Web 2.0 is similar – much like the Wild West, offering great promise in terms of life changing applications, but also presenting huge challenges such as a complete lack of stability and structure. Thus Web 2.0 programmers need to be learning something new on the job virtually every day. I am repeating myself but it can’t be said enough - Web 2.0 programmers engaged in development need to be technology experts with an excellent technical background, as well as project experience, and the ability to learn and reuse information rapidly in response to a dynamic environment. This is the kind of professional we need, but are lacking in today’s development organizations. And unless we make an active effort to do so, development organizations will remain elephants plodding along the knowledge highway.
Photo Credit: Flickr user exfordy