Showing posts with label discourse mapping. Show all posts
Showing posts with label discourse mapping. Show all posts

Monday, April 21, 2008

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. 

Sunday, April 20, 2008

If strengths and weaknesses are the same thing

I think in some problems the strengths and the weaknesses end up being the same issue. For instances in Co-ops, where a main strength is the localised control over activity and intentions and similarly a main failing point is the exact same issue. This is an interesting prospect to me as it seems to suggest that good solutions only come through a wicked problems analysis. Or at least an IBIS one in which there are tightly quantised strengths and weaknesses to, essentially calculate net value of features in a system. 


So I am not sure if this is relevant or interesting to anyone but I think it is something worth considering. I would perhaps even say that this is a good measure for how solvable a problem is. If solutions generally include features as strengths and weaknesses then great solutions are probably hard to find. (I have no data supporting this it just seems to be an interesting possibility) I think this is a little relevant with the idea of how to ask an answerable question

Wednesday, March 26, 2008

Dialogue Mapping Webinar

This afternoon I took part in a dialogue mapping webinar which was fun though there was not a whole lot of new content. The things I found most interesting are as follows:

  1. The idea that Dialogue mapping is there to essentially give context to the comments that are made by members of a discussion that do not really address the issue at hand but that are still relevant.
  2. There fact that are tools which supposedly can be used to do collaborative mapping tasks - multi input mapping.
During the discussion I also came to think that making text chat based compendium tools would be good. I still really think that doing the tool set web enabled is really important but I think by adding various key features the value could improve greatly. The things I would want to see are:
  1. In browser audio and video sharing 
  2. Text (im) centric map creation, with things like text bubble drag and drop for mapping
  3. Auto map optimisation software. ( I really think very few people do this well. And it would make a world of difference to the users)
  4. Import export of data from compendium and others.
  5. Retro-processing data and offering assistance in extracting a good map from any external or old data source. 
  6. Keeping track of chronological data as well as issue based data as I think chronology is often overlooked in this kind of work. Perhaps even letting this inform the way maps render to some degree, to connote the flow of relevance in the conversation that lead to a given map.
  7. Building of rich and mixed model data systems. For instance, easily incorporate another dynamic data from the Internet and allow piping via connections in Compendium. 
  8. Use pain biased windowing, instead of the very wasteful window object model. 
So yeah. I hope that happens. If it does not I might just have to start a company to do it :-) Comments on what to put in such a thing would be really liked.

In other news, this whole thing being a webinar and all was interesting. I really think better remote meeting systems are a big part of the next frontier. 

Update: I now have a link to the complete webinar map series. Check it out if you are interested in this kind of thing. I think the Conversational versus Issue Based Structure.ppt offers some good insight for people who are really new this kind of mapping. 

Thursday, February 7, 2008

How do you Ask Answerable Questions

I think it is so easy to make design problems that are esentially impossible to act upon. I mean, problems that have requirements that do not take into consideration reality, the issue of course is that it is hard to tell how far something is from reality when it is conceived. I guess sometimes instances like this are considered over ambitious however I think it is actually an issue in many situations where evaluating the complexity of a problem is difficult. For instance in operating systems, the complexity of the systems involved is so high that working out what effect a requirement will have on the rest of the system is really not easy. In some cases, I would say problems like this can be considered wicked however in many cases I think it is not the problem that its self is complex it is the evaluation method that returns data on the problem that is too complicated. For example. The problem of going to the moon is not really that wicked. I mean it involves a lot of complexity and a lot of very high rigour decision making but it is really not a problem that continuously changes and in which any answer is only a very temporary answer. The issue of difficulty in deciding weather the question is answerable is really high. 


Q: Let's go to the moon (can we go to the moon)? 

A: Yes lets, yay (we have no idea if we can or not).

 I wonder, is there a good way to work out early on that a design problem is like this. I think it wastes a lot of time and energy when people persue unsolvable problems. And I really mean is there a way that humans can look on the problem level, not on the implementation level, and establish an informed point of view either way. 

If anybody knows anything about methods for this I would be quite interested. Please comment.