Re: Screen captures

Subject: Re: Screen captures
From: Ryan Pollack <ryan -at- clicksecurity -dot- com>
To: "Porrello, Leonard" <lporrello -at- illumina -dot- com>
Date: Mon, 11 Feb 2013 13:44:12 -0600

Much agreed! (relevant bits quoted below).


> I have to add that I am deeply opposed to including screen shots of each
> dialog in a wizard or anything else that is equally banal .... I do not
> support including screen captures of what could be described as
> “congratulatory” screens.
>


> I look forward to a world in which consumer oriented applications are
> intuitive enough and contain enough direction within themselves so as to
> not require additional documentation. As a writer, then, I would be
> collaborating in GUI design rather than writing comprehensive end-user
> materials.



On Mon, Feb 11, 2013 at 11:25 AM, Porrello, Leonard
<lporrello -at- illumina -dot- com>wrote:

> Thanks, Ryan. I agree that there is a lot of room for professional
> discretion, and as I was writing, I couldn’t help but think of how often
> necessity has required me to depart from minimalist ideals. For most of the
> things I have documented, at best I have been able to incorporate just a
> couple of Carroll’s principles.****
>
> ** **
>
> I also have to admit that sometimes I just want to be a user-monkey
> myself, so in those cases I would appreciate your documentation. “Just tell
> me exactly what to do!” And I would add that writing good documentation for
> user-monkeys is no small feat! For that types of things I’ve been
> documenting for the majority of my career, however, users have needed to
> become experts to use systems correctly and effectively.****
>
> ** **
>
> Having said that, I have to add that I am deeply opposed to including
> screen shots of each dialog in a wizard or anything else that is equally
> banal. Along these lines, if I’ve documented a procedure correctly and
> described the outcome, I do not support including screen captures of what
> could be described as “congratulatory” screens. As a rule, if the user can
> figure out a screen by looking at it for just a few seconds, then I do not
> document it. On the other hand, if a screen is crammed full of cryptic
> fields, graphs, and hidden functionality, then a screen capture with
> callouts can be very helpful. ****
>
> ** **
>
> I look forward to a world in which consumer oriented applications are
> intuitive enough and contain enough direction within themselves so as to
> not require additional documentation. As a writer, then, I would be
> collaborating in GUI design rather than writing comprehensive end-user
> materials.****
>
> ** **
>
> *From:* Ryan Pollack [mailto:ryan -at- clicksecurity -dot- com]
> *Sent:* Monday, February 11, 2013 9:04 AM
> *To:* Porrello, Leonard
> *Cc:* Erika Yanovich; Techwr-l
> *Subject:* Re: Screen captures****
>
> ** **
>
> Hm, interesting. Your comments about full screenshots with callouts are
> well-taken. I like to think that I use those kinds, but it never hurts to
> have a reminder of what really helps.****
>
> ** **
>
> It seems we may differ on a more fundamental level: to user-monkey or not
> user-monkey? :-) As you said, there is room for both approaches. I
> certainly agree with that. You write that you prefer teaching users to be
> self-directed. But for the situation I'm in at my company, I think of my
> goal as supporting users who forget, or wonder, how to do something, or
> what some function call is, or what some term means, or users who wonder
> whether they *can* do something in our environment.****
>
> ** **
>
> More generally, I guess my goal is to support the people who don't want,
> or have, the time to become an expert in our product. And I think that even
> experts will forget how to do things from time to time (they may just know
> *what* *to look for* more quickly than a novice.)****
>
> ** **
>
> I've never expressed it like that, and I"m not sure how I arrived at that
> philosophy, but those words feel accurate to me. Thanks for helping me
> formulate it :-)****
>
> ** **
>
> To everyone else who is submitting research: keep it coming ... ****
>
> ** **
>
> -R****
>
> ** **
>
> On Mon, Feb 11, 2013 at 9:58 AM, Porrello, Leonard <lporrello -at- illumina -dot- com>
> wrote:****
>
> Your theory is excellent, Ryan, and can probably be considered as part of
> the folklore of tech writing, but the research that I have seen doesn't
> bear out what your assertions. Instead, what the little research that has
> been done has found is that the only screen captures that notably help a
> user are those that are of a full screen AND which include call-outs.
> Otherwise, in timed performance, users of documentation with full screen
> captures (for the types of tasked being performed in the test--this is a
> big caveat) fared little better than users of documentation without screen
> captures. Users of documentation with only partial screen captures actually
> fared worse. Granted this and the additional cost that including screen
> captures adds in non-regulated environments, the argument from ROI for not
> including "too many" screen captures is pretty strong.
>
> Apart from the empirical research, there is the matter of better or worse
> theories. While the theory you present is compelling, I find John Carroll's
> minimalist theory much more compelling. The aim of Carroll's approach, in
> short, is to facilitate users in becoming self-directed learners.
>
> Having said all of that, I would argue that there is room for both
> approaches. If you don't mind the additional overhead of adding copious
> screen captures and only want user-monkeys who just follow the bread-crumbs
> through a procedure, then including lots of full-screen captures isn't a
> problem. If you want your users to become self-directed users, screen
> captures aren't generally necessary.
>
> Leonard
>
> PS, I seem to have misplaced the studies I had read several years ago.
> However, Steve Janoff is the one who shared them with me and he may still
> have them. As I recall, they were done by a PhD candidate in Sweden.****
>
>
>
>
>
>
> -----Original Message-----
> From: techwr-l-bounces+lporrello=illumina -dot- com -at- lists -dot- techwr-l -dot- com [mailto:
> techwr-l-bounces+lporrello=illumina -dot- com -at- lists -dot- techwr-l -dot- com] On Behalf Of
> Ryan Pollack
> Sent: Monday, February 11, 2013 7:31 AM
> To: Erika Yanovich
> Cc: Techwr-l
> Subject: Re: Screen captures****
>
> As others have said, "it depends". Screenshots are like anything else
> (tables, bulleted lists, videos, paragraphs, etc); they are a tool you can
> use in order to bring about understanding in your readers. Here are some
> reasons why I find screenshots very useful:****
>
> - Instead of "Select blah>>blah>>blah", a screenshot helps users follow
> ****
>
> a path visually instead of mentally translating steps into actions. This
> saves effort and time on their part.****
>
> - The above goes doubly true if you have a dialog box with, say, 15****
>
> options and the user has to act on one or two. Without a screenshot, the
> user has to spend a few seconds scanning the dialog box and trying to
> find
> the option you wrote down, following the menu tree you set out as they
> go.
> With a screenshot, you can highlight the necessary option, saving them
> this
> effort.****
>
> - People don't read; they skim. People's eyes go straight to****
>
> screenshots, which can save a lot of reading time, thus getting the user
> back into the software quicker and helping them feel better about the
> docs.****
>
> - If a user is switching back & forth between the help and the software,
> ****
>
> a screenshot helps users keep their place in the column of text, so they
> can quickly return to the docs where they left off. It's much harder to
> find your place in a wall of text.****
>
> - Screenshots generally add color to a document, making it more pleasing
> ****
>
> to the eye (if your UX person has done their job ;-)****
>
> - Screenshots make the doc look less intimidating by breaking up, or***
> *
>
> obviating, large chunks of text. The less intimidating a doc looks, the
> more likely someone will be to read it, and the better they will feel
> about
> it overall.
>
> Of course screenshots have drawbacks:****
>
> - They generally take multiple steps to generate (open your software***
> *
>
> program, get it into a proper state for taking a relevant screenshot,
> take
> screenshot, possibly annotate it, save it, insert into document, etc.**
> **
>
> - They are larger in size than text, which can affect storage space on*
> ***
>
> disk, download times if you are doing online help, or file sizes if you
> are
> delivering a PDF.****
>
> - They are larger in dimension than a block of text, increasing****
>
> scrolling in online help and page count if you are delivering a printed
> manual.****
>
> - They are not searchable, although if you are doing online help or****
>
> adding captions, you can associate text w/screenshots in order to work*
> ***
>
> around this. Keep in mind that not only can users not search, *you*
> can't****
>
> -- which makes it harder to determine what portions of your
> documentation
> need to change when a new feature comes around.****
>
> - They are binary, so if you use a source code control system, changes*
> ***
>
> to them cannot be merged or tracked.****
>
> - They can be a pain for localization departments, who have to recreate
> ****
>
> your setup in order to translate the screenshot.
>
> As with anything else, these are all just my opinions. In many situations,
> I think the benefits of screenshots outweigh the drawbacks. I have topics
> in my help system that are literally just a title and a screenshot :-)
>
>
> On Mon, Feb 11, 2013 at 12:08 AM, Erika Yanovich <ERIKA_y -at- rad -dot- com> wrote:
>
> > Users like to be reassured they got to the right screen after passing
> > through several other ones. I don't give screen captures of the
> > passing-through ones where the user just clicks something to get to
> > another screen, just of the final screen, where the actual work is done.
> > Erika****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> Ryan Pollack****
>
> Senior Technical Writer | Click Security****
>



--

Ryan Pollack
Senior Technical Writer | Click Security
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
STC Vice President Nicky Bleiel is giving a free webinar on best practices
for creating mobile help.

Learn more: http://bit.ly/WNaCzd

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com


Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
http://www.techwhirl.com/email-discussion-groups/ for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com

Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives


References:
Screen captures: From: Anonymous
RE: Screen captures: From: Erika Yanovich
Re: Screen captures: From: Ryan Pollack
RE: Screen captures: From: Porrello, Leonard
Re: Screen captures: From: Ryan Pollack
RE: Screen captures: From: Porrello, Leonard

Previous by Author: Re: Screen captures
Next by Author: Re: When is it too much information?
Previous by Thread: RE: Screen captures
Next by Thread: Re: Screen captures


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads