[FM Discuss] issues with Kdenlive manual images

M R matrobnew at hotmail.com
Sat Feb 10 13:07:55 PST 2018


Mick:


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:


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.


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.


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.


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.


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 movingparts 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.


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.


Best,


Matt




________________________________
From: Discuss <discuss-bounces at lists.flossmanuals.net> on behalf of mick at flossmanuals.net <mick at flossmanuals.net>
Sent: Saturday, February 10, 2018 5:57 AM
To: discuss at lists.flossmanuals.net
Subject: Re: [FM Discuss] issues with Kdenlive manual images



On 09/02/18 20:16, M R wrote:
> 00 px is a pretty draconian limit for modern screenshots, though, as
> no one in their right might would use most of these editing tools at
> that width.  I get that the print version needs some kind of image
> width limit.  One would think that the "Constrain Proportions"
> function would at least, you know, constrain proportions if the image
> exceeded that limit, and simply show a smaller overall screenshot.
> But I can't get that to work in the editor: it seems to always take
> the actual height but constain the width.  No doubt why they fixed it
> in 2.2...

As Rosalind pointed out, I does seem to do that for the published
version. But I have seen squished images in the editor too.

So maybe we can work on a guideline for images width based on what they
look like when they are outputted to pdf. 800px for me seems about right
as above that it is hard to see what you want users to look at.

For me although the challenge of drawing the attention to the most
relevant part of the screen.

Thanks
Mick
_______________________________________________
Discuss mailing list
Discuss at lists.flossmanuals.net
http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net - you can unsubscribe here
Discuss Info Page - lists.flossmanuals.net<http://lists.flossmanuals.net/listinfo.cgi/discuss-flossmanuals.net>
lists.flossmanuals.net
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 ...



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.flossmanuals.net/pipermail/discuss-flossmanuals.net/attachments/20180210/0eb3d311/attachment.html>


More information about the Discuss mailing list