Transcript of Podcast 108

This is a transcript of Podcast 108: What you said you wanted from a course on creating screenshots and images

This is the Cherryleaf Podcast. 

I find myself in Windsor again and I’m by Eton Bridge, which goes over the River Thames and looking one way I can see into Eton and the shops in the pubs that way. And if I turn the other way I can see a castle, Windsor Castle. 

So there may be some noise in the background like bicycles going past, aircraft, boats on the river, and the like, but hopefully that won’t be too distracting.  

We’re just out of the lockdown here in the UK and I thought it be good opportunity to do another podcast episode outside rather than indoors. 

And this one is about images. We posted some questions on social media. One was, what would you want to know about creating screenshots and other graphics for user guides? And the other question we asked was what did you think you should be in a course about creating screenshots and other graphics? 

We got lots of responses. Really good response. So what we thought we’d cover in this episode is share what responses we got and then the reasons why we asked it. So let’s go through the responses that we got, and mainly the ones relating to the question about what should be in a course. 

If you wanted to learn about creating screenshots and graphics. So the question that we asked was what topics would, a course on creating screenshots and other graphics, what topic should be in it? 

So let me go through the answers or responses that we got. 

So one was from Professor Michael Meng, who is Professor at Merseburg University of Applied Sciences 

It should cover the empirical research that is available showing requirements screenshots have to meet to be helpful and effective. 

A good starting point could be the paper bei Hans van der Meij and Mark Gellevij, “Empirical proof for presenting screen captures in software documentation”, published 2004 in STC’s “Technical Communication”, 51(2), 224-258. 

And we had a response from Colin Hillis PhD FISTC, who is Senior Technical Communications Manager at White Hat Security.  

He said: 

It would be good to consider taking consistent screenshots when annotation is saved in the image, as opposed to annotating images in a layer in the finished doc. Consistent sizing of annotation is always difficult in this setting, given the amount of variables. Relevant points to consider are: size on screen pre-capture, extent of zoom pre-capture, quality of screen, SnagIt settings for quality, save resolution, and also the dimensions attributes used within image references in AsciiDocs. 

This is more relevant to AsciiDocs etc., where there are no drawing tools to annotate inside the writing tool, unlike traditional writing tools like FrameMaker and Madcap Flare. 

And we had a response from Adrian Warman, Principal Cyber Security Consultant at UK Ministry of Justice Digital and Technology: 

What accessibility considerations apply (both in text descriptions, and color/contrast options). 

Vinish Garg said: 

Metadata best practices for all images and screenshots in the technical documentation, and to align with this metadata with other images and digital assets used in the product code images.

And it’s raining. 

Ravikumar B. said: 

Writers must spend time in preparing the sample data that needs to be captured on the screen shots. Most of the first drafts contain screen shots with test data, which help in validating the UI, do not look good in documentation or training. The other common practice is to capture screen shots and paste or embed directly in the document resulting in large document size. Screen shots must first be saved as individual image files and then get inserted into the document. 

Steve Riley, Project and Account Manager, said: 

Using a short/simple style guide to keep consistency when working collaboratively – call out style, colours, fonts, resize %, etc. Helping non specialists contribute to a project, eg I sometimes get product specialists to work up a draft help topic on their area, that I might tidy up. The less for me to do editorial-wise the better 🙂 

Julian Maynard Smith, who wrote a book recently called Better Business Writing, provided some ideas from his book using graphics: 

* Only use graphics only to reinforce or illuminate what the text says – graphics used purely for prettiness place a cognitive burden on readers and can be misleading 

* Ensure that graphics are immediately after (or alongside) the text they apply to 

* Avoid very wide screenshots, which require you either to flip to landscape (annoying for readers) or to shrink the graphic (reduces legibility) – either crop the image to the important bit, or use arrows / callouts to indicate which bits are important 

* If you’re using MS-Word, don’t paste elements (such as bubbles and callouts) on top using Word’s native graphics, because if the main image changes position or size all the elements slide all over the place – instead, use MS-Paint or similar to “lock in” all the elements into one image 

André Tran, Technical Writer: 

I would love to know more about possible ways to automate screenshots. Maybe leveraging macro plugins in the browser or QA/testing tools (such as Selenium, Katalon Studio, etc.). 

The big challenge of course is that these tools can be rather complex, and it’s hard to know if the time to invest in learning them and setting them up is worth it… 

Gareth Bowen, Technical Publications Manager at Emerson and Renwick, said: 

Resource management, naming convention and batch editing. 

Sue Burnett said: 

Copyright considerations when using any third party content. 

We had a comment from David Hollis, who referred to a comment that he had made on LinkedIn relating to Tom Johnson’s podcast about simplified user interfaces. 

And David said graphics re use and management number breakouts for easier translation. And how common are screenshots of menus? I would take a screenshot of a window but not a menu. I just use file connect. No mobile device ET cetera. If a menu needed screenshot, surely that’s a problem with the UI. 

And Richa Arora said:  

How can I fix images in Confluence? 

Stuart Burnfield had a question recently about caption placement: 

This seems to be a consensus, though not universal agreements, that captions should go below diagrams but above tables. When did Sonic where weather in how to caption are screenshots the same as other official figures? 

– What diagram types work best for a given situation (e.g. explaining processes vs. explaining states vs. explaining systems) 

– Free-form vs. structured (i.e. UML and similar), benefits and disadvantages thereof 

– How to maximize screenshot lifespan and maintainability (this may be partly covered by your “automation” section) 

And Craig Wright – Tech Writer, said 

* Resolution 

* Image file sizes 

* File types and which ones work best for different types of image. For example, I find jpg provides smaller file sizes on retina screens. 

* Excluding irrelevant parts of the UI (using blur, blank boxes etc.) 

* Benefits of using number callouts 

*Importance of alt text for accessibility 

*Importance of white space, especially in complex diagrams 

*Importance of text to accompany diagrams for those people who struggle with diagram-only instructions. 

*Importance of not relying on colour-coding for important information. Colour blindness, visual impairments etc. 

And Rhonda Bracey, who is in Australia? Said: 

Layers. They do my head in. 

So why did we ask that question? 

And the reason for that is that we are moving into quarter two of 2021. We’ve got some capacity to start to develop some new elearning courses. It’s been a bit hectic for the last six months with project work and consultancy and developing virtual classroom courses. Those are the ones where we have a live trainer delivering over Teams, so we haven’t been introducing new  elearning courses for a little while. And we want to do that. And we have the opportunity to spend some time and put together some more courses. 

We have been thinking about creating an elearning course on creating screenshots and other graphics, and that’s why we basically ask the question – to get some research, check that what we’ve got planned as topics are the ones that people want covered. 

Why do we pick that topic?  

What we can do from a real learning platform so we can get statistics on the videos that people are watching and. 

What we can see from that is that rather than the courses around emerging themes, the ones that are really popular are actually the courses and videos on what you might call the bread and butter topics.

The ones that affect probably more people than than others, that in some ways you think most people would know about if they’ve got a little bit of experience under their belts. 

Another reason for picking this is that we do cover images and graphics in our foundation course. And the exercise we have on that when it comes to giving feedback, that’s probably the one where we add the most amount of detail and extra suggestions. It’s the area where we can talk probably more than the other topics. 

And of course screenshots and images if you’re developing documentation, the software, even hardware as well. I guess it’s one of those things that everybody has to do. 

So when it comes to developing a course, the way that we tend to do it, having identified a topic that we want to cover, is to start with a slide deck and put in topics blank topics for the subjects that we want to cover. Key points of information and we start moving things around and fleshing it out and then seeing if there are enough information to justify course. Do you know, do we have enough to say? 

And we had a list of topics, different things that people might want to cover. Things like creating images, using image maps, using colour, using icons, SVG, the software tools, automating tasks. 

But it didn’t really fit together. 

So many problems we had when we looked at that was there really wasn’t what you might call a path to success.  

So we took the topics and we’ve rearranged them and restructured them. We’ve taken an idea from somebody else. We’ve taken an idea from somebody called Cole Nussbaumer Knaflic.And she’s got a book and a course called Storytelling With Data, which is all about displaying numerical data. 

And so we’re going to follow basically the same structure that she’s applied to images and screenshots. So let me tell you what that is.  

So a good path to success for creating images, we believe, is to go through these stages.  

Start by understanding the context, when and where these screenshots be used, when and where would the user be viewing them. 

What device and so on? 

Decide on the appropriate visual display methods. So do you need to use a screenshot, full screenshots, a diagram or type of diagram, an icon, and so on. 

Present it in a way that the uses attention is focused on where you want them to be focused. 

And then use design techniques to make it pleasing and accessible. 

And then, his is topic really on its own, although we could embed it into all of those things, but we will consider it as a separate topic, ;ook at the different tools and technologies that are out there for creating this type of content. 

So within that type of structure ,we can cover things like  

How official information is perceived. 

Image Maps  

Simplified.User interfaces  

Wordless guides like IKEA use and so on 

Into that particular structure. 

And you might have a question in that, and one that I said that we consider when we’re planning a course is: is it really enough to talk about when it comes to screenshots and images? I mean, you just grab a screenshot, put it in, don’t you? 

A couple of things have indicated that it is definitely worth talking about. One is in terms of the slide deck that we’ve put together at the topics that are going to be talked about and discussed with now at 304 slides. 

And that works out at roughly about a day’s worth or a day and a half worth of training in a classroom. Because if you consider a classroom course, they usually begin about 10. They finish about 4:30. You have an hour break for lunch. You have coffee breaks. There’s the time for exercises, and going through what the answers are to these exercises. 

So if you look at the amount of teaching time where the trainer is up presenting giving you information, it’s probably 40 or 50% of the time of the actual course.  

Recording videos and creating exercises and answers combined all of that. It’s looking like it’s equivalent of what would be covered in a classroom, in, as I said, in a day or a day and a half. 

So we’ve had really the opposite problem in some ways of how do we keep it within boundaries, but we do not stray off too far and make it too big. 

And think about what we should cover we shouldn’t cover.  

So we’re doing this. We’re going to focus on images and screenshots for user guides and online help created by technical communicators, and as such will not really going to focus on things like highly detailed technical illustrations. For example, you might find in aerospace or in automotive industry  

And equally count drawings or three dimensional diagrams of physical objects. We’re only going to touch on those briefly. And topics like augmented reality and virtual reality that there’s so much to cover on that that that’s going to be outside of the realm of this course. 

And that was a bicycle going past. 

Wwe’re not going to look at how to draw or data visualisation. How to present statistical data. 

We also had lots of suggestions that we covered from the feedback on social media. Some of those edge cases were not going to cover the tricky question. Some of them probably best addressed by consultants. I would say the necessary on a training course. 

So that’s what we started on, and that’s what we’re going to be working on a elearning course on screenshots and graphics. 

And it will be an elearning course, given the lockdown and constraints that were under. We’re not at this stage looking at having it as a classroom course. 

And what we’re trying to do is to add it to the bundle of courses that are available on our Intermediate and Advanced course bundle. So it’ll be the 11th course in that bundle. That’s if you’re not familiar with it to pay monthly scheme. 

We are still in two minds, depends on whether there’s interest in just having it as a standalone course for a one off fee. 

We might see that. 

So when it will be available?  

We’ve recorded most of the videos for the course. We’ve got three to go, which is on SVG files, demonstrations of different tools, and a little bit about doing animations of drawings and the like. 

And the other things we need to do. 

If you’ve ever created a training course, you know these are quite a challenge. Some of the exercises and some of the answers to go with exercises. There’s about 20 exercises in the course. We’ve done 10. We’ve got tend to go where we have pretty much all the questions for the course. We’ve got 10 answers that we need to write to go with those. 

I know what we’ll do is we’ll put it through some testing. 

And announce it and release it. We might offer early access,  beta version if things get slowed down by one particular area. 

If that’s something you want to be kept up to date with or informed us of when it’s going to be released, your best bet is probably to sign up to our newsletter. 

I don’t think we’ve mentioned the newsletter for awhile. It comes out each month. It’s free of charge. 

The purpose of it is to help people become better business and technical communicators. So it has links to articles and news all around creating documentation, technical documentation, and business documentation from us and from other people. So if you’re listening to this podcast, I suspect a lot of that is of interest to you. I’ll put a link in the show notes you can sign up and I hope it’s of use to you. 

If you have some thoughts on what you’d like, a course on images and screenshots to cover, or you have thoughts on what should be in a course topics that you think should be in there that we haven’t mentioned. 

Then do let us know it’s not too late to tell us, and you can do that by emailing us info @ cherryleaf.com or I am on Twitter, @ellispratt 

I should say goodbye from Eton Bridge, from the Thames, and from the cyclists have been going by and again, thank you for listening.