Frequently Asked Questions (FAQ) about how DoView has been designed and is being developed.
• What are the evaluator needs DoView is trying to meet?
DoView is logic modeling and evaluation software specifically designed for evaluators by evaluators to meet a need not met by other software. We intensively analyzed what's needed for drawing outcomes logic models. Traditionally, many evaluators use a four stage process: drawing the model in a meeting using a white board or yellow stickies; an evaluator taking the results away and actually building the logic model; taking a printed version back to a subsequent meeting for amendment; and then the evaluator going away and amending it again. We identified that a piece of software which would let evaluators 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 an evaluator separately and 'brought back' to the group. Just as importantly, if you use the model for 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 evaluator 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 evaluators 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 logic models is to have them at the heart of all evaluation planning. 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 logics 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 this logic model, but. . .' Being unable to read the logic 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 evaluation planning process. Using a DoView model you have built in its compact format means that the logic can always be viewed in different formats and it can then take its rightful place at the centre of evaluation planning and implementation.
• Do I have to use the compact format in DoView?
No, you can also build models which are up to ledger/A3 sized by enlarging a compact slice to this size. This allows you to build models which are optimized for printing out on ledger/A3 paper if you want to work in just a paper-based modality. There may be advantages in doing this in some situations, and it means that DoView offers the same functionality as simple drawing software where you can draw diagrams this type of size. However, the primary reason we provided the ledger/A3 size diagram function was that it could complement, rather than be an alternative to, compact format models. In this approach, you build your basic model out of compact diagrams and get all of the advantages of portability across formats. You then use DoView's innovative 'clone' ('live copy') function to clone (create 'live copies') of all the steps and outcomes from your compact diagrams and arrange them on as many ledger/A3 sized diagrams as it takes. 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 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). As working evaluators ourselves, rather than designers, 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 logic models (e.g. we are currently looking at visualizing strength of causal connection). 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 logic 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 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 for the working evaluator, 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 (slices) 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 hop-to internal hyperlinks) between diagrams, it allow you to break out of the constraint of your logic models being just a single printed page. DoView models can be very large indeed. People are currently working with models of up to 30 interconnected diagrams which they can quickly navigate through using DoView.
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 slices into conceptually related groups, for instance in many models we are seeing individual compact slices 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 outcomes logic 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 other logics, 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 logic models and that is that it makes them harder to overview. At the moment in DoView you can develop a ledger/A3 sized diagram which contains clones of all of the steps and outcomes in your compact version (see the discussion above). However we are also currently working on additional ways of quickly overviewing all of the compact diagrams in a model within DoView (e.g. with thumbnails).
• What's the vision for OutcomesModels.org
We've just set up OutcomesModels.org and there are currently just a few simple outcomes logic 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 logic 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).