Small Services and Topology for the Same

Today I was trying to work with a few groups of friends on a few different projects at the same time all via the internet. We were doing a few things; research, content building, organisation and  communicating. None of these things by them selves are problematic and especially if they were been done in personal collaboration or by my self then no problems would exist. In this case however, it was very difficult to suitably take part in this system. I found that many of the small tasks I wanted to do could not really be done without a prohibitively large set-up time and more complex things I wanted to do could not be done without more sophisticated web tools. 

For example, I was working away and realised I had an idea for a way to deal with something I was not working on. So I wanted a tool that I could simply write a snippet of text into that would be like a post-it note. Not a big problem, but, I wanted this note to also be connected with the task I was thinking about and annotated so it would be seen by the relevant team members. Now I know there are tools that do this, and services that offer a lot in this respect but I can not afford to sign up for every service just so I can do a few different tasks, and more so, I can not expect all of the people I work with to do the same. So, the answer I think is appropriate is essentially a set of operators on basic communication networks and offer various things like content tagging, targeted messaging, really fast content dropping and so on. I think using as many existing networks as possible is really important, i.e. using email and im instead of creating a new notification methodology, such as the Facebook Inbox, because this approach lets messages go to non members and people who just need to know the content not anything else. 

A different example was when I wanted to create a simple and quick list that included images and some text, it needed to be sortable and searchable but nothing fancy. Now this can be done in many tools like Google Docs or Zoho but all these interfaces are pretty slow and arduous. Also, I wanted to make this list in a way that would make it useful for me later, so potentially I could get a feed out of it or at least use it as a data store for a website. In any case, nothing was really offering me what I wanted so I ended up doing it in a context that had the advantage of local speed, Compendium. Here i could make it both a graphical and context driven list or layout and get rich relationships between elements. Now I know I will have to remake the work later which I think is quite lame. So, I want a tool that lets me have more flexible content manipulation and output settings while also having a high speed interface. An AIR application may be a start and perhaps building it to provide basically a really fixable content bucket that has a hole bunch of import and export tools that are all based on standards. 

I hope open standard interface languages become more popular. I really think they are the answer to a lot of serious problems. But more than that,  I really hope people start to take advantage of them. RSS is a wonderful tool but very few services use it to its full. Similarly, dynamic OPMLs , lists of lists, could be so well used in certain contexts. 

I think almost none of what I have said here makes any sense. I really just want to say. 

1. Service should do one thing perfectly and nothing else. 
2. Everything should be built to work with other things in as many ways as possible.
   
3. The things things work with should be up to the user or the receiver if that role exists. 
4. Standards should even be used for preferences. For instance, how do I like being notified by a tool? The answer to this question should be used when I need to be notified by someone else's service that I have never heard of.
5. Naming and interfacing should be search to activity. (This I will talk about later)
6. Relevance should exist for everything. Like realtime, automated discourse mapping of everything that is relevent.