Frequently Asked Questions (FAQ) about how DoView has been designed and is being developed.
• What are the needs DoView is trying to meet?
DoView is outcomes modeling (program logic modeling) and evaluation software specifically designed for evaluators and anyone working with outcomes and strategic planning. It meets a need not catered for in other software by providing an affordable, easily used, general purpose 'outcomes processor' which lets you work in a flexible way when thinking about outcomes, evaluation, strategic planning and contracting. We intensively analyzed what's needed for drawing outcomes logic models (outcomes models setting out all of the higher-level outcomes being sought and the lower-level steps needed to achieve them). Traditionally, building outcomes models has been a four stage process: drawing the model in a meeting using a white board or yellow stickies; taking the results away and actually building the logic model; taking a printed version back to a subsequent meeting for amendment; and then the going away and amending it again. We identified that a piece of software which would help users build models in real-time in meetings would be a significant advance. Hence DoView is designed explicitly to be used in meetings. This requires a very simple command set; a limited number of formating options (so you don't have to make formating decisions on your feet); large icons so that the audience gets a sense of what you're doing when you interact with the software; and a way of structuring your model so that it can be read and amended when dataprojected. Not only is building and amending a model in real-time in a meeting more efficient (you can, of course always tidy it up later) but it also creates much more of a sense of ownership of the model by the group developing it. The model is no longer something which is created by you separately and 'brought back' to the group. Just as importantly, if you use the model for additional purposes (e.g. evaluation planning and implementation, by putting indicators and evaluation questions onto the model) it becomes a 'living plan' a dataprojected version of which can be used and updated in every evaluation or stakeholder meeting.
In addition to designing DoView for use in real-time in meetings, we identified the following additional needs for models built in DoView which are discussed in more detail later on this page: the software should create an underlying model not just a drawing; models should be able to be as large as you like; all key elements of the model need to able to be captured (e.g. not just those links you can fit tidily on a page); ultimately, all key elements of the model need to be able to be visualized using a standard set of formating conventions; it needs to be portable across different fomats (e.g. screen, dataprojected, paper, and HTML on the web); the model should not be locked into a proprietary format and therefore it should be able to be saved in an 'open' format like XML so that so that in the future you can visualized or analyze your DoView models in different, yet to be built, software systems built by others.
Finally, we knew that because users don't have the time to learn complex drawing or modeling software, DoView had to be exceptionally easy to learn and use.
• Why does DoView have a compact format which breaks outcomes logic models up into smaller diagrams (slices) which you jump between?
Our analysis identified that the optimal way of using outcomes models is to have them at the heart of all strategic planning, evaluation planning and contracting and delegation discussions. For this to happen, it is essential that a visualized model is portable across all of the different different formats (i.e. your screen, colleagues screens, when dataprojected, when printed, and when presented as HTML on the web). The traditional size of logic models has been dictated by a single traditional format (the printed page - either letter/A4 or ledger/A3). This limits the usefulness of such models when used in the other formats which are now becoming the dominant way in which outcomes models are worked with (rather than just viewed). In particular, the standard letter (A4) size has too much information on it when dataprojected at 1024 X 768 resolution on a normal sized projector screen in a medium sized meeting room. This results in the often heard comment: 'you won't be able to read the text in this model, but. . .' Being unable to read the text in the outcomes model means that a group cannot work with it in real-time and therefore it cannot perform its function of being right at the heart of the planning, evaluation and contracting process. Using a DoView model you have built in its compact format means that the outcomes model can always be viewed in different formats and it can then take its rightful place at the centre of planning, evaluation and contracting.
• Do I have to use the compact format in DoView?
No, you can also build models which are a rang of different sizes, right up to very large poster sizes. This allows you to build models which are optimized for printing out if you wish rather than just for dataprojecting. The suggested way of building models in DoView is to first build them in a compact format (using the DoView default 1 x 1 compact pages). You build your basic model out of compact diagrams and get all of the advantages of portability across formats. You then use DoView's unique 'clone' ('live copy') function to clone (create 'live copies') of all the steps and outcomes from your compact diagrams and arrange them on what every larger pages suit you, e.g. on several ledger/A3 sized pages (2 x 2 pages in DoView - meaning they can take 2 x 2 = 4 compact 1 x 1 pages), or on larger poster sizes pages. This gives you the best of both worlds. For instance, participants in a meeting can be given a printed ledger/A3 clone version of the model so they can overview it. At the same time, they can be working with the dataprojected compact version of the model amending the model in real-time. When some of the details of a step or outcome are changed on the compact version, because they are clones, they will also automatically be updated on the ledger/A3 version which can then be printed out later as an updated overview of the model.
• Why can't I currently select lots of different fonts and colors in DoView like I can in some drawing software?
In addition to the reason noted above, that options have been kept as simple as possible so you can confidently use DoView in front of an audience, there are two other important reasons. The first, as also discussed above, is to make sure that the fonts and colors will be portable across different modalities (e.g. a font which can be seen on a paper version may not be readable when viewed on a dataprojector in a medium sized room; dark step colors may work when dataprojected but when printed may obscure step names). We don't want users to have to be designers as the same time, we know that we don't want to have to make these kinds of decisions on the fly, we want them hard-wired into the software so we don't make formating mistakes we later regret when we try to use the model in a different format.
Second, DoView is modeling rather than drawing software. As we develop it further we are progressively using all of the available formating palette (font, colour, texture, border width) to visualize different key aspects of outcomes models. This means that we have to make sure that different parts of the formating palette work with each other in any one model to clearly communicate the major elements in the model using a common set of visual symbols. If there is some aspect of an outcomes logic model you want to communicate with, say colored lines, work out what is the underlying element of the model you're trying to communicate and let us know (use the comment form on the Support page). Chances are we're working on modeling that element in a future update to DoView and we may be able to change its priority on the development list or, if not, we would really like to hear about it so that we can consider putting it on our development list.
• Why is the distinction between DoView being modeling rather than drawing software important?
Drawing software lets you draw diagrams which contain visual objects just placed on the surface of the diagram. In contrast, DoView builds an underlying model of the important elements and then visualizes it for you. From your point of view this happens automatically when you draw your DoView model so there's not really any difference in ease of use, however once you've developed your DoView model it has much more potential than a simple drawn diagram. For instance, often in simple drawn models created by standard drawing software, information is left out because it cannot be fitted tidily onto the drawn diagram. For instance, causal links which would look too messy on the drawn diagram are dropped out, or notes about the evidence supporting links between steps and outcomes cannot be easily included because there is space for them. Such simple drawings are an incomplete representation of the underlying model and you have lost data (e.g. about the existance of the causal link) which should have been recorded in the model. The power of the modeling approach can be seen in DoView when you make links between steps within a model without having to draw them as lines and arrows at that stage and then later 'turn them on' and they will all appear as line and arrow links.
The power of DoView building an underlying model as it visualizes it for you is that firstly you have documented all, not just part of your model, and secondly it opens up the possibility that different visualizations and presentations of the data in the model can be generated from the model in a way that is not possible if using just a simple drawn logic model. DoView is not designed to replace more complex mathematically-based modeling and visualization software. It is designed to provide a model-based approach, which sits between the current too limited basic drawn models and more complex mathematically based models.
• What are the consequences of breaking up DoView models into compact diagrams?
Breaking DoView models up into compact diagrams has three major advantages and one disadvantage. The first advantage is that, as discussed above, it allows DoView models to be portable across different formats (screen, datashow, paper, web). Second, in combination with DoView's support for quick jumping (with DoView page-jump internal hyperlinks) between diagrams, it allow you to break out of the constraint of your models being just a single printed page. DoView models can be very large indeed. Users are currently working with models of up to 30 interconnected diagrams which they can quickly navigate through using DoView. And, of course, because of the way DoView has been designed, people can always see the content on the screen when the model is dataprojected.
The third advantage is that users are finding that breaking models up into compact diagrams is making model drawing more efficient. Dividing models into parts is a form of modularization which in the past has proven to increase efficiency in areas as diverse as manufacturing to software design. Typically, DoView steps and outcomes are grouped on compact pages into conceptually related groups, for instance in many models we are seeing individual compact pages emerging for national, regional, organizational and individual levels. Having the compact diagrams based on such levels makes them much easier for the reader to grasp than a single large diagram with different conceptual levels intermingled. This modular approach also makes it much easier to 'borrow' and amend diagrams from models which have been developed by yourself or others in the past.
For instance, if you're currently building a model for a program and working on the organizational level compact diagram within the model you can quickly look at the organization level diagrams from a number of other models, paste the one you want into DoView and start amending it to fit your current program. We're developing a set of outcomes models at OutcomesModels.org which anyone can freely use and hope that others will contribute their models to this collection.
There is only one downside to modularizing outcomes models and that is that it makes them harder to overview. At the moment in DoView you can develop summary higher-level models which you drill-down beneath to reveal further detail. You can also 'clone' (make 'live copies' of) your models onto larger poster-sized pages which you can print out.
• What's the vision for OutcomesModels.org
We've just set up OutcomesModels.org and there are currently just a few simple outcomes models up on that site at the moment. The idea is for it to become a repository of outcomes models which anyone can borrow (whether they are working commercially or non-commercially) to help them build their own outcomes models. The vision is then that they will put the models they have built back up on OutcomesModels.org for others to freely use so that the sector can progressively build and share better and better models. The models on OutcomesModels.org are covered by a Creative Commons copyright which means that the models are free for use in almost all circumstances (check more details here).