The Traditional Way and the DoView Way

The Traditional Way of drawing outcomes models (program logics)

The traditional way of drawing outcomes models is to draw them on the biggest piece of paper you can print to (usualy letter/A4 or in some settings ledger/A3) and to use the 'line and arrow' paradigm to illustrate links. With DoView Version 1.1 you can quickly draw outcomes models (program logics) using the traditional way. And DoView's smart approach to laying out line and arrow links makes it faster to draw this type of model. The Traditional Way has the advantage that it's easy to overview a model printed on a single page. However it runs up against problems when you have more steps and outcomes in a model than you can fit onto a single printed page. It also creates problems when you  project you model using a dataprojector in a meeting because such models are usually too large to be able to be viewed as a whole on a single screen. Thirdly, the lines and arrows linking paradigm often creates problems when you try to link outcomes or steps right across a model. Often people end up with diagrams which only show some of the links (the ones which could be drawn without making the model look too untidy). From a formal modeling point of view, just being able to record some, but not all, of the links is less than desirable. 

The DoView Way is a different paradigm which has significant advantages

The DoView Way encourages the user to 'modularize' their outcomes model (program logic) and introduces a new paradigm for showing links between steps and outcomes (only the first stage of this paradigm has been implemented so far in DoView 1.02). Now with DoView Version 1.1 you can have it both ways if you wish. You can build a model using the DoView way using small compact slices and then 'clone' it (put live copies) onto a larger slice (diagram) for printing out on ledger/A3.  

Our journey

We have been on a long journey in trying to work out the best way to develop the next generation approach to outcomes models (program logics). Our design team consists of an experienced evaluator who has drawn hundreds of outcomes models (program logics) using a range of different types of drawing software, a usability expert and a software engineer. After much analysis and testing they identified our needs as follows: 

•  Being able to build large outcomes models - model size should never be limited 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 moved to, and reused, in another model. 

•  Being able to record all links between steps and outcomes and being able to visualize them in a way that does not  require the user to rearrange their diagram as inevitably happens when using the 'lines and arrows' paradigm.

•  Being able to record notes about steps, outcomes, links and other objects placed on a diagram. 

The DoView Way - next generation outcomes models (program logics)

We have build DoView to be able to deliver on the needs listed above, in addition to being able to support the Traditional Way of drawing outcomes models (program logics) (now available in Version 1.1). 

We think that in the DoView Way, we have the next generation approach to drawing outcomes models (program logics). The approach is based on helping the user break their models up into smaller modules which they can then quickly jump around. 

It does generally require a little more time and effort to build models which are broken into smaller pages, but it is usually compensated for by not having to do the type of formating of lines and arrows links which people face using the Traditional Way. We've used the DoView Way with hundreds of models, others are using it, and we've put some example of models draw using the DoView Way up on outcomesmodels.org (we're going to put up many more on that site).

If we get enough support from those building outcomes models (program logics) we are planning to keep improving DoView both in regard to its support for the Traditional Way, but also in regard to the new DoView Way with all the advantages it provides. For instance, we are hard at work looking at ways of showing multiple links on a diagram (slice) using the new DoView Way paradigm, we are also working on ways of overviewing and moving around a model beyond the simple slice list and hyperlink (hop-to) functionality supported in Version 1.02 (e.g. with by using thumbnails). 

We want your comments on our approach!

Please let us have any comments you have on our approach by sending us an email from the support page