Timing issue on menus in screenshots

HelpXplain is the exciting new animated infographics and screencast tool that integrates with Help+Manual.

Moderators: Alexander Halser, Tim Green

Post Reply
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Timing issue on menus in screenshots

Unread post by Martin Wynne »

Great to see HelpXplain finally released. Well done. :)

I've been trying out the Screencast function as an alternative to video, and there seems to be an issue with menus. When the menu appears, the menu item which you are about to click is shown already highlighted before the mouse moves anywhere near it. Is this intended? It's great as a tutorial device to show what is going to happen next, but of course it is not what happens in actual practice, so there seems some scope for user confusion.

To explain what I mean I have made a short bit of xplain. Note how Select All and then Copy are shown already highlighted when the right-click menu pops up:

http://85a.uk/xplain/untitled.html

Windows 10 / 64-bit / HelpXplain release with all defaults unchanged

cheers,

Martin.
User avatar
Tim Green
Site Admin
Posts: 23155
Joined: Mon Jun 24, 2002 9:11 am
Location: Bruehl, Germany
Contact:

Re: Timing issue on menus in screenshots

Unread post by Tim Green »

Hi Martin,

I just did a run-through of this and I think it's definitely fine and also a positive. There are two reasons:

First, since you are creating a tutorial it is showing you in advance where the click is going to be. It focuses the viewer's attention and acts as an additional teaching reminder of what the step being shown is. If you recorded it exactly as it really happens the user would not have so much time to remember which menu item is being clicked. First they would see the entire menu as an unfocused list. Then they would only very briefly see the selected menu item and it would almost immediately disappear to continue with the next step. Much less memorable and intuitive.

In addition to this it saves space, because if you were going to show the entire sequence of opening the menu and selecting and clicking on the menu item you would need an additional two or three frames in the Xplain in order to achieve a less memorable and clear tutorial step. :)
Regards,
Tim (EC Software Documentation & User Support)

Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
User avatar
Martin Wynne
Posts: 2656
Joined: Mon May 12, 2003 3:21 pm
Location: West of the Severn, UK

Re: Timing issue on menus in screenshots

Unread post by Martin Wynne »

Hi Tim,

That was a spirited defence, but I'm not entirely convinced. Especially if you are claiming this as a direct replacement for screen-recording video -- in real life stuff doesn't get highlighted in advance.

I can see less-savvy users getting confused. I can read the support emails now -- "In your instructions the menu shows where it has to be clicked, but on my system it doesn't." :(

However, by duplicating the mouse cursor I have been able to make it much better, at least in my eyes. It's a bit of extra work, but still quicker than making a video:

http://85a.uk/xplain_1/untitled_1.html

cheers,

Martin.
Stewart Edgell
Posts: 9
Joined: Wed Aug 03, 2011 9:01 am

Re: Timing issue on menus in screenshots

Unread post by Stewart Edgell »

I'm inclined to agree with Martin - the predictive highlighting could cause some confusion. I would prefer to show the screencast as is, and add some explanatory text to the side.
Ga Bowen
Posts: 324
Joined: Mon Jun 27, 2016 5:05 pm

Re: Timing issue on menus in screenshots

Unread post by Ga Bowen »

FWIW I like it, for the same reasons Tim explains.

If it does change, I would like to see the option of the current method still being an option.
User avatar
Alexander Halser
EC-Software Support
Posts: 4098
Joined: Mon Jun 24, 2002 7:24 pm
Location: Salzburg, Austria
Contact:

Re: Timing issue on menus in screenshots

Unread post by Alexander Halser »

As Tim already explained, this is by design. It's not just menus, the same is true for any buttons that typically show a highlighted state when the mouse hovers over it. The question is: is this good or bad? I admit it, it looks a bit odd in the first place, but when you think about it, the highlight gives the viewer a clue where the cursor is going to click. And that's a good thing. Worst thing to happen: it isn't noticed at all. Best thing: it's noticed and shifts the attention focus of the viewer to the cursor's destination point early on.

When you look at it from another angle, it's not correct, either. What if the menu item was not highlighted in the screenshot? When you move the mouse there and click, this will look kinda strange, because we all know that a menu gets highlighted right before the click. We tried that version, too, but it looks like a kind of "unmotivated click".

During the beta phase (and Martin was in the beta group) we have experimented a lot with the screencast function. The first version produced a double-take: it created two screenshots per slide, one for the beginning of the cursor movement (in this case, that would be with a menu visible but not highlighted), and a second one for the end of the movement (that one that you see now). This version created a much more realistic screencast for the price of duplicating the number of screenshots and putting a complicated animation into every slide: the 2 screenshots were stacked and the upper one was hidden when the cursor arrived at its click destination. That moment the second screenshot came into display. The animations and the 2 screenshots, however, were difficult to edit and replace. Difficult to a degree that made it impossible to actually replace a slide later, or continue a screencast from a certain scene.

What's still missing in such a double-feature screencast is everything in between. Dragging objects across the screen, selecting text with the mouse, objects changing their display state while the mouse moves over them (though not with an intent to click), you name it. To capture all that, you have to create a video.

HelpXplain screencasts are not videos. And they don't want to be a fake video. Several of our beta testers opted to display screencast slides in a sliding manner - not a hard show of the next slide, but deliberately let the next slide visibly move in. This creates a really stunning effect, try it! It looks like an unreal kind of video with a meta level, that connects the dots from one scene to the next.

To sum it up...

* The highlighted menu item is a deliberate feature.

* If we don't show it highlighted, it looks equally wrong but makes creating screencasts more complicated: we need to capture the menu, don't we? But the menu takes a few milliseconds to pop up. The early solution was, to instruct the user to pause mouse movements for a second and take the screenshot with the menu popped up when the mouse starts moving again (hoping that everything is visible by then).

* We had a double-take screencast in place (which suffers from the same problem as point 2 above) but got rid of it. That was done to make screencasts easier to edit and to continue after a break. Easy editing is way more important than picturing everything 100% realistic. After all, HelpXplain is a tutorial tool and a tutorial does not have to be photorealistic. It has to be helpful for the reader.

* We don't say videos are a bad thing. They have a lot of advantages. Unfortunately, they also have even more disadvantages when creating them.
Alexander Halser
Senior Software Architect, EC Software GmbH
Post Reply