From time to time, students or authors ask me why I never want to see their computer screen dumps in their papers . It may be useful to share some of the reasons behind my views on this.
In my own experience, I have never received a paper where the screen dump was a crucial part of the argument or narrative. Every paper I have seen that has included a screen dump has made only passing reference to the Figure, and the argument in the paper did not hinge on the appearance of the screen. Instead, we were either treated to a very low resolution image (as would be expected for a screen dump) that portrays either an open dialogue box, or a pixelated graph or Table.
When authors use an image of an open dialogue box to illustrate the input routines for their software, I simply wonder why they feel the need to do this. Is it because they think their readers don’t know what a dialogue box looks like? In this case, I am confident that the image is not needed, because I assume we are writing for people who are sufficiently computer literate to understand what one of those looks like. Moreover, software moves on and such an image soon looks dated when one looks back over a paper a couple of years after publication. A simple description of the input data is more important than a picture of a dialogue box, and such a description is probably still needed even with an image of the dialogue box.
When the screen dump is an image, perhaps from a building information model, CAD software or a graph from SPSS, or output from some kind analytical software, the resolution is usually very poor and the gratuitous use of colour quite jarring, especially given the predilection for software writers of all kinds to set default colour schemes that look interesting on screen, but a lot more distracting and confusing on paper. Such graphs and drawings are better if they are re-drawn in high resolution with black lines on a white background.
Some screen dumps are tables of numbers, resulting from an analytical procedure in the software. Since it is a regular occurrence to include tables of numbers in all sorts of papers, there is simply no need to portray them as a low-resolution screen dump with all the software buttons and grey-shades that usually surround them. The table would be easier to read if it were set in the usual way. Most readers can understand that the numbers were produced by an analytical piece of software, even if they cannot see the actual appearance on a computer screen.
Finally, if the purpose is to demonstrate input and output routines for the actual software, then, yes, screen dumps are extremely useful. But then I question whether this means that the author has actually produced a user manual, rather than a paper on the management or economics of some aspect of the construction sector. So, when authors produce a guide to their original software, that uses screen dumps to explain how it is used, we typically find that this is not a research paper at all, but a user guide, and therefore out of scope for the kinds of paper I get involved with.
For all these reasons, I generally reject screen dumps. I fully accept that there is an interesting field of research about user interfaces and perceptions of screen displays. Indeed, there are research projects on that kind of thing and, if they are properly theoretically positioned and robustly contextualized, they would be very interesting. One would then question, again, whether it was actually in scope for the kind of thing that I generally have to review, but I would not make that assumption just because there are screen dumps there. I would always read a paper fully before deeming it out of scope.
Despite my policy, I remain open to discussion and counter-arguments. I acknowledge the need to continuously develop this kind of arbitrary policy.