DoView

The DoView way is a different (and we hope a better!) paradigm but if you don't think so we'll change our approach

The current version of DoView (1.02) doesn't let you draw diagrams larger than ones that you can see when projected on a normal data projector (smallish sized diagrams). It also doesn't let you draw line and arrow causal links. If we get enough feedback from you that you want these things - we'll simply turn them on. In the meantime give us a moment to tell you our reasoning as to why we've not turned them on yet and want you to help us introduce a different paradigm for drawing outcomes and program logic models. 

Our learning journey

When we started developing DoView the first thing we did was to build a prototype which allowed us to draw large diagrams - we were excited about finally breaking out of the single printed page format. The second thing we did was to get it to visualize links as lines and arrows. We were very pleased with ourselves, but then we started building models and intensively testing the concept. In discussions between our outcomes expert, software usability specialist and software engineer, we soon realized that we hadn't distinguished between our needs and our wants. While we wanted to be able to draw large diagrams and line and arrow links, would such diagrams meet our actual needs?

After much testing and analysis we identified our diagram size needs as:

•  Being able to build large outcomes models - model size should never be determined by arbitrary constraints such as page size

•  Always being able to print model components out on normal letter-sized paper

•  Always being able to see the text on the models when projected with a dataprojector

•  Always being able to quickly work with the electronic version of the model in a meeting

•  Having enough space in a model to show not just outcomes and steps but also indicators and evaluation questions on the same model

•  Encouraging a 'modular' approach to building models which lets components from one model be quickly reused in another model. 

How we tried to solve the design dilemma

The approach we finally took in the current versions of DoView was to break models up into small diagrams which you can quickly jump between (and we're working on better ways of overviewing and moving around a model - e.g. with thumbnails). This approach achieves all the above needs. 

If we turned on DoView's ability to draw diagrams up to double letter size - which we could easily do - then immediately the approach would fail to meet some of the needs listed above:

•  Most people (i.e. those with only letter-sized printers) would not be able to print out the models.

•  In a meeting, you wouldn't be able to see all the text in the model (ever been at a meeting where someone projects an outcomes or program logic model and says 'you won't be able to read this, but. . .')

•  You'd lose the advantages of the modular approach. This is where an outcomes model is broken down into smaller diagrams which focus on a particular aspect of the model e.g. national level, locality level, organizational level, individual level. We're realizing the power of such modularity more and more in our outcomes and program logic work. First, its much easier for someone to quickly grasp a small set of outcomes which are related and all shown on a standard sized DoView diagram. In a larger diagram the reader has to come to terms with outcomes and steps at multiple levels. Second, now when we're building a new model we often come to the point where we say, for instance,  'we need an individual level diagram now' and we are able to go to a model we have built previously, grab the individual level diagram (slice), put it in our new model and amend it as appropriate. It's much harder to pull out of a previous outcomes (or program logic) model components which are all interwoven with each other if it is in a larger diagram. We believe that we are cutting the time it takes to build models by at least half through this approach. We are planning to make many models available at www.outcomesmodels.org for free so that we can all increase our efficiency by building on each others' work.  

•  We also fear that if people could build larger models then they would start working with them in meetings in their paper versions. What's the problem with doing that? In our experience paper versions of models and are very inferior to electronic versions of models which can be developed and amended in real-time in meetings. Paper versions are much harder to rearrange than DoView electronic versions. In both our work and reports we hear from others, taking away a paper version and amending it off-line from the meeting means that you get much less buy-in from participants for the model. It also means that you no longer can work in the way we are now working with organizations - using a dynamic electronic model able to be amended in real-time at the heart of all strategic thinking, prioritization, monitoring and evaluation for a project, programme or organization.

It does generally require more time and effort to build models which are broken into smaller pages, but we've done it with hundreds of models, others are doing it, and we've put some example of these up on outcomesmodels.org and we're going to put up many more. Having worked in this way for a considerable period of time now, our view is that its advantages far outweigh its disadvantages.

Why not have the normal linking lines and arrows approach?

Our thinking about linking lines and arrows followed a similiar path to that for diagram page size. We built it for the prototype but then turned it off in the final released version of DoView. The needs we identified in regard to linking were:

•  Links can exist between any outcome or step and any other - their existence shouldn't be limited by the number of lines you can fit on a page without it becoming impossibly messy.

•  Steps and outcomes in a diagram should be set out in the way which makes it easiest for the reader to quickly read them.

The traditional lines and arrows method fails to meet either of these needs. What normally happens (and we've personally done this with many outcomes and program logic models before we developed DoView) is that you start drawing in the lines and arrows, and then you start rearranging the steps and outcomes so that the lines will not cross. This creates a diagram which is not necessarily set out in the optimal way for a reader to read. What then often happens, from our own experience and that reported by colleagues, is that you just don't bother to put in some of the lines and arrows which link right across a diagram because there is just not enough room. This is a crazy situation to end up in - only some of your links are in your model because you ran out of room!

With DoView we did a lot of experimentation with how to deal with the linking problem. For the current version, we decided that the bottom-line functionality we needed to provide was to allow all links to be entered into the model. This is done very easily be dragging from one outcome or step to the one you want to link to. All these links are stored in the model and you can include notes about any link. So our first objective of allowing for all links to be put into the model was achieved. This is a great advance on many models drawn in normal drawing software where only a sub-set of links are included because of the line and arrow visualization problem. Second, we developed a link icon system so that you can see the immediate links of any step or outcome whenever you click on that step or outcome. We see this as only the first stage in visualizing links and are currently working on cool ways of visualizing more than just the links from one step or outcome within a DoView diagram. We are committed to doing this in a way that will escape the major problems we all face with the traditional line and arrow linking approach.

We want your comments!

Do you think our approach is right or wrong? Will you not buy DoView because you want it to be able to draw large models? Please send us a comment now using the form below. We are trying to launch a new paradigm and if users out in the field are not with us on this, we'll pull back from it and turn on DoView's ability to draw larger diagrams. Please let us know your view on this issue, we are really very interested in what you prefer regarding this question.