<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Mick:</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">I just sent a version of this response with a doc attachment, but the listserve is balking at the size of the attachment as it has multiple screenshots, so here is just the text of my response repeated. Perhaps the moderator-machine
will let my first version with the attachment through in time. Meanwhile:</p>
<p style="margin-top:0;margin-bottom:0"></p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
I think you raise a valid point, and codifying screenshot guidelines sounds like a good idea; but I also think it just depends utterly on what kind of authoring or editing tool (and what kind of media) we're talking about. Generally speaking, the more complex
the media (or multimedia) being edited or authored, the more likely it is that a UI surface will need to have multiple panes/panels/windows showing different kinds of information, but that really need to be viewed simultaneously (more or less) to get a whole
picture of what you're doing in a given operation. And very little software UI design today, for such editors, assumes that users will confine themselves to anything like an 800 px-wide screen resolution.</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
Let's consider some concrete examples. Audio is in some ways the simplest medium, and so with a tool like Audacity, you're for the most part just working in tracks on a linear timeline, so showing just part of that timeline in a screenshot will generally suffice
to put across your operation. And a simple text editor, of course, can pretty much be sized however you want it, within reason. With code-editors it depends on how feature-rich the UI is. Static image editors and draw tools, same thing: I think our Inkscape
manual does an amazing job of working with probably too-confined real estate. Photoshop or Gimp would also be a challenge, though I can imagine it. Something like Powerpoint or comparable slide-deck tools is already pushing the limits for small-screen editing,
even of a 'static' product, since slide-decks really aren't static anyway.</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
For a video editor, that's already much more complex as you have a linear timeline plus a video display, plus typically other panes with important property information. So far in the new Shotcut manual I've just shown just portions of each of these, which
is fine for a walk-through of the different panels but will be a real constraint when I get to the actual 'how-to' chapters. But I'll do my best.</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
For a tool to author any kind of multimedia/interactive eLearning material (e.g. Articulate Storyline, Adobe Captivate), you can very rarely get away with seeing just 700-800 px of real estate at once. Or Flash (now reborn as Animate), or really just about
any Adobe-model multimedia authoring product. For 3D modeling and game-building tools, not a chance. It's true that you will still want to draw your reader's/viewer's attention to different parts of the UI, to understand what they're about, but to get a
sense of real-time operations you need to see the whole. In these cases there is no such thing as "the most relevant part of the screen" -- it's all relevant. This is really why video software tutorials almost always show the full software UI, taking up
most or all of the presenter's desktop, and are typically now shot in high-resolution and meant to be viewed wide-screen or full-screen too. </p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
I've already indicated other reasons why I think a text-and-screenshot document for a tool like Blender or Unity is pretty pointless. I'd extend that to many of the other tools I've mentioned here. Shotcut is probably pushing it, though at least in video
editing the number of <i>moving</i>parts is still (somewhat) limited. Still, if there were simply more decent video tutorials extant for Shotcut, I wouldn't consider it worthwhile to write an FM manual for it. And setting the moving-parts argument aside,
if I were designing a BookType-style platform now, I'd never put in a 700 px hardcoded limit for images, regardless of the target medium, even print. </p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
Attached (in the original, currently-embargoed version) is a doc with me putting my $$ or effort where my mouth is regarding tutorials for a tool like Unity3D. One can still find book-length text-and-screenshot manuals for Unity too, but to my mind they are
entirely pointless. For Shotcut, though, the effort still seems worthwhile, at least at this stage in the process. Ask me again in another few weeks.</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
Best,</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
<br>
</p>
<p style="font-family: Calibri, Helvetica, sans-serif, serif, EmojiFont; font-size: 16px;">
Matt</p>
<div><br>
</div>
<br>
<p></p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Discuss <discuss-bounces@lists.flossmanuals.net> on behalf of mick@flossmanuals.net <mick@flossmanuals.net><br>
<b>Sent:</b> Saturday, February 10, 2018 5:57 AM<br>
<b>To:</b> discuss@lists.flossmanuals.net<br>
<b>Subject:</b> Re: [FM Discuss] issues with Kdenlive manual images</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText"><br>
<br>
On 09/02/18 20:16, M R wrote:<br>
> 00 px is a pretty draconian limit for modern screenshots, though, as<br>
> no one in their right might would use most of these editing tools at<br>
> that width. I get that the print version needs some kind of image<br>
> width limit. One would think that the "Constrain Proportions"<br>
> function would at least, you know, constrain proportions if the image<br>
> exceeded that limit, and simply show a smaller overall screenshot. <br>
> But I can't get that to work in the editor: it seems to always take<br>
> the actual height but constain the width. No doubt why they fixed it<br>
> in 2.2...<br>
<br>
As Rosalind pointed out, I does seem to do that for the published<br>
version. But I have seen squished images in the editor too.<br>
<br>
So maybe we can work on a guideline for images width based on what they<br>
look like when they are outputted to pdf. 800px for me seems about right<br>
as above that it is hard to see what you want users to look at.<br>
<br>
For me although the challenge of drawing the attention to the most<br>
relevant part of the screen.<br>
<br>
Thanks<br>
Mick<br>
_______________________________________________<br>
Discuss mailing list<br>
Discuss@lists.flossmanuals.net<br>
<a href="http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net" id="LPlnk428840" previewremoved="true">http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net</a> - you can unsubscribe here
<div id="LPBorder_GT_15182966616010.08774375264512213" style="margin-bottom: 20px; overflow: auto; width: 100%; text-indent: 0px;">
<table id="LPContainer_15182966615970.5139390542661277" role="presentation" cellspacing="0" style="width: 90%; background-color: rgb(255, 255, 255); position: relative; overflow: auto; padding-top: 20px; padding-bottom: 20px; margin-top: 20px; border-top: 1px dotted rgb(200, 200, 200); border-bottom: 1px dotted rgb(200, 200, 200);">
<tbody>
<tr valign="top" style="border-spacing: 0px;">
<td id="TextCell_15182966615980.1372464797864208" colspan="2" style="vertical-align: top; position: relative; padding: 0px; display: table-cell;">
<div id="LPRemovePreviewContainer_15182966615980.9175548908119062"></div>
<div id="LPTitle_15182966615980.5009115045003227" style="top: 0px; color: rgb(0, 120, 215); font-weight: 400; font-size: 21px; font-family: wf_segoe-ui_light, "Segoe UI Light", "Segoe WP Light", "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; line-height: 21px;">
<a id="LPUrlAnchor_15182966615990.8408991922679212" href="http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net" target="_blank" style="text-decoration: none;">Discuss Info Page - lists.flossmanuals.net</a></div>
<div id="LPMetadata_15182966615990.31631360409658393" style="margin: 10px 0px 16px; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; font-size: 14px; line-height: 14px;">
lists.flossmanuals.net</div>
<div id="LPDescription_15182966616000.9902189375666932" style="display: block; color: rgb(102, 102, 102); font-weight: 400; font-family: wf_segoe-ui_normal, "Segoe UI", "Segoe WP", Tahoma, Arial, sans-serif; font-size: 14px; line-height: 20px; max-height: 100px; overflow: hidden;">
Discuss anything about floss manuals - its aims, what it does, how it does it, what it could do, and how it can be better. To see the collection of prior postings to ...</div>
</td>
</tr>
</tbody>
</table>
</div>
<br>
<br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>