Multiple issues with keyboard navigation via Tab in “New Document” window

[JGD]

Hi guys,

I know I'm probably in the minority here, but as a former longtime Windows PC user, all my Macs get the "tab between all elements” treatment (using the Ctrl+F7 shortcut), and I'm the master nitpicker when it comes to finding inconsistencies in the tabbing implementation because I happen to use the Tab key *a lot* (that's also what having two big screens and losing your mouse cursor a lot on a daily basis, even with El Capitan's “shake cursor to enlarge” function, does to you).

This time, I realised two things:

1. When tabbing between fields and interface elements in the “New Document” window, I can never get to the four separators on the bottom half;

2. The little “Presets” button, with the four horizontal lines and the down arrow and to the right-hand side of the “Page Preset” drop-down menu, is never visually highlighted, though it is indeed selectable; also, when pressing the spacebar, the corresponding menu will not open adjacent to said button but underneath wherever the mouse cursor is; furthermore, this behaviour is reproducible in all Beta Affinity apps.

So, yep, that's about it. If I can reproduce any of these behaviours elsewhere in Publisher, I'll let you know.

[walt.farrell]

18 minutes ago, JGD said:

"tab between all elements” treatment (using the Ctrl+F7 shortcut)

Sorry, I can't really comment on the points you've raised. But I'm curious what you mean by "using the ctrl+F7 shortcut". Can you explain that for this Windows user?

(I think my curiosity was initially raised as I would not consider Ctrl+F7 to be a shortcut for Tab  so I figure I must be misinterpreting something )

[Old Bruce]

2 hours ago, walt.farrell said:

Sorry, I can't really comment on the points you've raised. But I'm curious what you mean by "using the ctrl+F7 shortcut". Can you explain that for this Windows user?

(I think my curiosity was initially raised as I would not consider Ctrl+F7 to be a shortcut for Tab  so I figure I must be misinterpreting something )

I find this feature to be quite hit and miss depending on the various ways it gets implement, more often not, by developers so you can see it is off for me. All controls means anything that could possibly be highlighted gets attention from the Tab key being hit. No rhyme nor reason to it.

[JGD]

On 12/1/2018 at 11:20 PM, Old Bruce said:

I find this feature to be quite hit and miss depending on the various ways it gets implement, more often not, by developers so you can see it is off for me. All controls means anything that could possibly be highlighted gets attention from the Tab key being hit. No rhyme nor reason to it.

Well, let me put it this way: I know it is a bit hit or miss, but consider the following:

1. Apple does it right;

2. Adobe does it right;

3. It's something that when activated on macOS, makes it behave a little more like Windows (something that would please a user like @walt.farrell, for instance, and which makes the Mac so much better and quick to use for me);

4. Seeing how both Adobe *and* Serif offer cross-platform apps (in fact, Serif started out as a Windows-only shop), and that tabbing is a pretty natural behaviour in Windows, it stands to reason that Affinity should behave well with keyboards and tabbing in particular.

Is my reasoning a bit of a stretch? You see, it's also not the first time I find weird tabbing behaviours in Affinity apps, the earlier one being, IIRC, a completely inconsistent tabbing order in the Transform palette, which made inputting values extremely cumbersome and unintuitive. Oh, news flash: I just checked, and I realised that it's still not completely fixed (at least the ordering on those four fields is now correct, I'll give them that). You see, when tabbing from the “link chain” constrain proportions button, you can't get to the next field, Rotate, and instead hide the Studio right away. This behaviour goes completely against this system-wide setting, too. You should be able to not only tab between all fields and buttons in each palette, but also to the palette separators and even between other palettes from the same group… Not even Adobe does that (when you select a field and start tabbing, you get stuck in an endless loop between the fields available in that panel, even with said system-wide “All controls” setting activated, but at least Tab doesn't hide the Workspace), but hey, there you have another golden opportunity to one-up them at something.

Also, while I'm at it (and even though I will probably create a new thread, or just bump one which I started on the same subject and which has been lying around dead somewhere in the forums for 2 or 3 years now, I still feel this other bug is completely relevant to the topic), I should add that the Separated mode still doesn't work properly; I'd love to be able to use it in Affinity Photo (in fact, I still use it in Photoshop), but Serif never got around to fix it and allow for docking the toolbar and toolbox, and/or at least prevent windows from going full-screen at all, zooming or even being dragged behind them, something which Adobe, Macromedia, FontLab, Microsoft, etc. etc. etc. got right more than 30 years ago (if that happens, you either have to toggle full-screen from the menu, or switch to a different app just to be able to access the window chrome)… Serif isn't adhering to the best practices from even the Macintosh 128K era! It's in these little things that their former Windows-centric background really shows, but please, oh please, if you're answering user requests (and said Separated mode was probably born out of one of those), at least polish them to… I won't even say perfection, but just basic usability. Actually take the time to learn how the Mac's original “floating window + toolbars + palettes” UX concept works, *and especially the zoom button*, and get the details right (if you have to fire up a bootleg Snow Leopard VM and install FreeHand 12, or Office 2001:mac, or FontLab 5, so be it… Oh, wait, never mind all that hassle; you just have to fire up Photoshop CC 2019, turn off the very prominent “Application Frame” on the Window menu, dock your stuff and you're all set, boom!, with a fully functional Separated mode for comparison's sake and reverse-engineering… and do try the zoom button while you're at it, please! Because having it duplicate a sort of “maximize” function is just useless, we might as well just use the regular full-window or fullscreen mode!), because some people, and some apps/workflows, really do benefit from that model (especially Affinity Photo, for obvious reasons; in fact, we'd be better off if Serif just killed Separated mode in the rest of the suite and concentrated just on getting Photo right). The same goes for keyboard support, I guess, and here I speak as a former PC user who actually values the competition's effort in keeping the software as close between platforms as possible…

IMveryHO, your (@Old Bruce's) way to go about OS-level features and Beta testing is completely lenient and backwards… I know I border on the obsessive and sometimes even on the aggressive with my nitpicking, but surely we should expect developers, especially self-proclaimed user-friendly ones and to whom we already gave our hard-earned money (maybe it's not your case, but it's certainly mine), to adhere as strictly as possible to Apple's HIG, am I right? Why make excuses for something which shouldn't be that hard to code correctly? This is not a full-blown new tool, or something that messes with the graphics engine and dependencies or whatever, and it's not some obscure accessibility setting either; it's actually just plain adhering to a top-level OS-wide setting which affects a default input method that makes a Mac or a PC, well… a Mac or a PC. In fact, I'd go even further and say that this is the kind of thing that should also be available on the iPad versions of Affinity apps or the upcoming Photoshop for iOS… I don't even know if you can tab between interface elements on iPad apps, but since there are first-party Smart Connector keyboards and built-in first-party and third-party Bluetooth keyboard support, complete with support for some system-wide keyboard shortcuts (yes, with a Command key, just like on a real Mac), you definitely should. Face it: keyboards may be archaic as hell, but they aren't going anywhere any time soon.

Now, some final considerations on the reasons which may be behind these issues… I'd venture a guess and say that it all comes down to the usage of custom interface elements, and a desire to keep the interface as close as possible on both the Mac and Windows sides of things (which, as you'll soon realise, it's not a fully achieved goal by default on Publisher, either; I have yet to test it on release-quality software, but I'll be sure to run a trial of Photo and Designer on a fresh VM just to check it out), and the usage of not entirely native/first-party frameworks as they were conceived (I'm talking about Interface Builder and default Aqua interface widgets, specifically, and its equivalente Metro counterparts in Windows). Interestingly, when tabbing on the “New Document” dialog on the Windows version, you can't even get to said button, you also get to a phantom field which triggers nothing when pressing space (in a different ordering… but maybe it corresponds to said button, only it doesn't work?), and you can indeed get to the lower fields, too, but never to said middle separators, either… In addition, the ordering on those lower fields is also different, and it makes less sense than on the Mac version; whereas on the Mac, you get from the two Width/Height fields to the “Portrait” checkbox and, only then, to the DPI field with drop-down button, on Windows you get straight from the Width/Height fields to said DPI field and, only then, to the “Portrait” checkbox. You see, consistency across platforms is also key (pun unintended), especially considering how Apple doesn't produce certain devices like the Surface Pro, or easily upgradeable desktop computers, and some creatives may indeed end up working with a mix of both iMacs and Surfaces, MacBooks and PC towers, etc. etc. Those users already have to deal with the nightmare of different shortcut triggers by default, so let's at least spare them the indignity of those inconsistencies, minute as they may seem…

[Old Bruce]

2 hours ago, JGD said:

IMveryHO, your (@Old Bruce's) way to go about OS-level features and Beta testing is completely lenient and backwards…

Hmm, could well be.

I would like to point out that I was unclear, a failing of mine, and that I think we agree on much of what you have written. My comment about 'hit and miss' was meant as a comment on the entire ecosystem using the "Full Keyboard Access:... All controls" I have found that many times I cannot use the tab key to speed things up because there are so many fields, buttons and checkboxes in a dialog box that it is easier and quicker to just mouse into the one I want. So I do not use the function. If I had difficulty using a mouse, as many people do, then I would engage it and silently curse the poor design of whatever dialog box I am in.

Much of the current betas from Affinity suffer from poor implementation of tabbing between fields.

Again, I think we agree on much of what you have written, perhaps all of it. Thanks for looking for instances of 'wrongness'.

 

[JGD]

1 hour ago, Old Bruce said:

Hmm, could well be.

I would like to point out that I was unclear, a failing of mine, and that I think we agree on much of what you have written. My comment about 'hit and miss' was meant as a comment on the entire ecosystem using the "Full Keyboard Access:... All controls" I have found that many times I cannot use the tab key to speed things up because there are so many fields, buttons and checkboxes in a dialog box that it is easier and quicker to just mouse into the one I want. So I do not use the function. If I had difficulty using a mouse, as many people do, then I would engage it and silently curse the poor design of whatever dialog box I am in.

Much of the current betas from Affinity suffer from poor implementation of tabbing between fields.

Again, I think we agree on much of what you have written, perhaps all of it. Thanks for looking for instances of 'wrongness'.

 

Indeed, I sometimes don't use thad function on more complex pieces of software… We still live mostly on a WIMP world, especially on the Mac. However, I rarely use the mouse to trigger confirmation buttons on most dialog boxes and prompts. In fact, I sometimes even press Tab followed by Space instead of pressing Return and triggering the default option, thus adding an extra step, to give me a split second to thing if I really want to save changes, print something, etc. Interestingly, you really need to have the “All controls” option selected for such a basic option, because otherwise you can only press Escape or Return (and those don't really cover all the options on many prompts.

In my case, it's not a matter of difficulty; sometimes I just want to speed up workflows that aren't slow enough to justify using action/macro-based automation, but boring enough to, you know, justify me not wanting to use the mouse for them. I'm also a heavy keyboard shortcut user, something that came, as I said, from my Windows days, but also became further ingrained after working at a Mac lab. I was responsible for 16 Macs in one room, and 10 more in another, so imagine what it would be like to turn them off at the end of the day without my faithful Ctrl+Opt+Cmd+Eject shortcut, or updating them without full keyboard access (again, those numbers and the high network speeds we had didn't justify using imaging techniques, but doing it without resorting to the keyboard would be a damn chore).

In my experience, that inconsistency, or overzealous UI coverage (that's precisely the point, in fact), is far outweighed by the advantages. It's just too bad that some apps which I already paid for and to which I desperately want to switch seem to be fighting me at every corner; Adobe's apps are also cumbersome in other regards, but seeing how I would always need them for certain projects and would, thus, have to use them on occasion (even if that entails running my trusty CS5 Design Standard on a crusty VM, or on Bootcamp, or whatever), the value proposition of Affinity apps comes out severely damaged from any and all defects that actually hinder the jobs I could indeed do with them right now.

As it stands, I only use Affinity apps for stuff which is manifestly better on them. Which means, guess what: mostly gradients. https://feedback.photoshop.com/photoshop_family/topics/photoshops_gradient_editor_needs_an_overhaul And only of the RGB or CMYK kind, because Affinity's support for spot colours is, I'm afraid, pretty substandard, especially when it comes to, ironically enough, gradients (and, alas, transparencies, which is a great – and seemingly simple to implement, one would guess? – use case for them); those are precisely the kinds of projects which would always force me to use Ai, the others being type design (Affinity Designer's support for sending standard PostScript-compliant objects to the clipboard, on the MAS 1.6 version, at least, is, alas, dismal and completely incompatible with digital type design apps such as Glyphs or FontLab).

[Edit: regarding gradients, I am very happy to see that the latest Affinity Designer 1.7 Beta finally supports spot colour transparencies/tints and gradients without converting them to CMYK but, when it comes to the latter, only to white (not even to a 0% tint of the same spot colour, which is a complete head scratcher because on Corel Draw 7 the reverse was true, and on Ai I believe both work just fine)… It is also indeed possible to make cross-spot colour gradients, but it entails setting an entire spot colour to be a global overprint colour (I sincerely hope you can have multiple swatches of the same colour, one in overprint, and one in normal mode, otherwise having to add an extra white object behind each object with a spot colour fill will be a pain), and overlaying the topmost colour over the other; the thing is, it only works for print, because on the regular display mode on normal PDF readers, only the topmost gradient to white will be visible… Overall, it's an extremely cumbersome workaround for something which Affinity will – or should –, hopefully, support soon]

[Edit #2: Upon further testing, I am also happy to report that the “Multiply” blending mode works effectively as an always visible overprint on the final PDF file and on a per-object basis, even for spot colours, which is great and maybe explains why the developers didn't even bother to implement overprints in any way other than on a global basis… On one hand, that makes my workaround easier and more visible, while also avoiding the side effect of undesired overprints on all other objects of the same colour, but on the other hand, it still doesn't excuse them for not implementing cross-colour gradients; it is technically feasible, it's just a matter of implementing it, so there's no reason why they should be converted into CMYK by default. I will likely update my original post accordingly, with new PDF and .afdesign file demos]

[Chris_K]

Thanks jgd  I'll get this logged