Ulysses' Companions' Odyssey (provisional app review)

Posted by 22111
Apr 19, 2022 at 11:17 PM

To resume the first two third-party posts here:

- Whilst Mac users can trial Windows software on their Macs, prospects for Mac-only software are to first buy a Mac, then they may trial - by provision by the Apple management who by all legal means available close their system

- For Mac software, the general laws of man-machine interaction don’t apply, and everything’s inherently good by definition - it must be a religion

- Thence, their functional design must not be challenged, just as little as the physical devices one’s - that would be blasphemy

- Highly probable and specified assumptions are rejected by a sweeping You’re not allowed to comment on software you haven’t used, instead of confirming, negating or commenting the assumptions in respect of content - if you don’t see the necessity to do so, that’s fine, but trying to ape politicians’ way of discussing then, instead of just shrugging, might be considered pathetic

- No thanks for (excellent) advice, be it re tree / list navigation, be it re adequate inclusion of meta notes into the tree - additional invective instead (#1); it’s true that both advice fields presuppose tree formatting to some degree at least (necessarily), as well as filtering-by-formatting (ideally), and these conditions might irritate when not available

And no, I don’t try to prove that Windows software, especially for writers

(or the graphical professions; btw I heard that many members of the latter have switched back to Windows, advancing that Apple prices for extreme power, necessary for them, they say, has got over the top, whilst for Windows, it remains expensive but affordable for them - hearsay from web fora in fact) was inherently superior to Mac software, I just analyze both, and give details, as far as I can (proof above), ready to see my writings supplemented and/or rectified where applicable.

Wherever Apple does it right, or almost right, I say so, proof on file, https://www.donationcoder.com/forum/index.php?topic=43812.msg409013#msg409013 - it seems now that in their newest Macbooks though, they had abandoned their re-invention, the so-called “market” (i.e. user base) had not adopted it (as far as Apple had probably hoped for); some remarks for possible reasons:

- the same / similar functionality must be available by the same (here: virtual) key, in other software (several file managers, several word processors, etc.), so as you soon will be able to use them “blind”, i.e. instinctively; of course, re-attribution of keys by overall macro software helps enormously with that, and of course, their touch-bar should have been accessible to such key-re-attributions; I don’t know if that was/is the case though (and then, it’s not fatal anymore that many developers didn’t “participate” by re-allocating their shortcuts to those virtual keys; but as I just said in another thread, I’ve got the impression that Apple users, with exceptions of course, are not that much inclined to “case improvement”, “tuning”, but seem to want it “ready-made”; on the other hand, Apple owns hundreds of billions, so they could - and should - have hired some 20 persons to do the necessary adaption work for the most notable apps, and then they could have delivered their bar Macs together with the additional trans-app software to normalize the user-interaction, by establishing a nice overall plan for the users, and for intercepting the respective, proprietary app commands (all this with allowing further user individualizing by the user if so desired).

- for the same reason of quick “blind” communication, and all the more so in their actual situation, i.e. with NO normalization of those virtual keys between apps, they should never had displayed the “current” command attribution to the key just below (!) your finger, so that you had and have to first look, then move your finger there, but, by option (i.e. for the learning phase, when you had to have a (confirmation) look first indeed), also on-screen; this would have helped enormously with the user acceptance

- You have to distinguish between context-sensitive keys and virtual keys, their bar concept mixed it up, ok, but why did they remove the physical F-keys? (“Any lack’s a feature”, for them, I said.) It would have been nice to have both, 24 F-keys (physical, virtual, half-half, whatever) coming so much handier than just 12… and thus, at the end of the day, replacing (!) physical keys by virtual ones (instead of just supplementing the latter) did perhaps not please so many users, also considering pricing?

As for “proof on file” for my goodwill for anything useful and constructive, from whatever source (even Apple ;-) ), see (the rest is a replication of the link text):

Apple does it again - this time, they re-invent the context-sensitive F-key
« on: May 08, 2017, 01:43 PM »
Currently, I had the occasion to admire the new Apple touch-bar; new Mac Pro’s had it and started with about 2,000€, the 2016 models came without it (but with F-keys instead) and startet around 300€ less.

Apple certainly has had it patented, but they are re-inventing the wheel again (they did it with the iPad - there had been a mobile touch-screen device before by Microsoft but which was too bad, too heavy and so on), and somewhere I read “this software is touch-bar ready” indeed, while in fact there had been DOS programs with context-sensitive F-key assignments, or in short, context-sensitive F-keys.

It’s very difficult to find such context-sensitive F-keys in today’s Windows software, I cannot think of a single one at this moment, and I think I’ve read somewhere some discussion of it coming in the way of the user, being unspecific, being error-prone and all that; I doubt this, but cannot speak from experience; it’s very interesting that Apple now does exactly that thing, and I suppose that now that it comes from Apple, the old criticism will be very subdued since openly hating it would be “Apple-hating” this time; as said, I’m in favor of it, I’m just hoping that it makes its way into Windows programs, too!

I say it’s not different from the old thing, you will answer that’s not true. So to start, here’s a good introduction: http://appleinsider….h-id-for-macbook-pro

First, it replaces the F-keys, it doesn’t come on top of it, but even if it did, it wouldn’t make any difference. The current assignment of the (virtual) “key” (tap on the touch-bar) is indicated by changing lettering there, but this means - within the frame of the criticism that it’s not unambiguous and error-prone - that you first must read what’s available, or at least check that there it’s the function you expect to be there, and then only you can move your finger there in order to activate the function, since before, your finger would cover the lettering; this takes a moment of time.

The touch-bar isn’t only for traditional functions, but also for text expansion, which is probably a very good thing; since the suggestions are of different length though, I suppose that this means you cannot count on suggestion 1 being on a certain place of the touch-bar, suggestion 2 being on a certain other, defined place there, and so on, but that you first must read what is where, and then tap there, so the moment of time, referred-to above and needed for reading before tapping probably cannot be shortened or avoided.

How did those DOS programs convey the info? By using the bottom “line” of the screen in order to display 3x4 F-key symbols there, together with their current meaning, here’s an example from wikipedia: https://en.wikipedia…le:GW-BASIC_3.23.png - note that the symbols are of different length and thus could have contained text expansion suggestions, had that concept been already invented at the time. Here’s another example, even more basic where they do without even the symbols but just do a list: http://ece.wpi.edu/~...es/EE2801/Labs/tasm/ (both screenshots, by scrolling down).

Note that those screen symbols/texts are readable from the moment on the function is available (as is touch-bar lettering), but then even up to the moment you will have pressed the respective F-key, so there is available (but not forced-upon-you) a possible and wanted overlapping of checking time (“yes, it’s well the function I expect”) and time for moving your finger to the F-key in question, so at least for functions where you just check and don’t need to really inform yourself anymore (learning phase), it’s bound to be speedier than the touch-bar variant.

It’s evident that in order to be speedy, the F-keys must be grouped on the screen (3x4) which in my 2 DOS examples above they were not, but that was 35 years ago (they were not for 3x4 but for 10 F-keys in 2x5 rows to the left of the keyboard); also, it’s understood that the touch-bar has quite high resolution, and that your screen also should have quite high resolution in order to brilliantly display 12 different texts in 3 groups and in one single line, but whenever that condition is given, the F-key-plus-screen-display should be speedier than Apple’s touch-bar, at the very least for often-used functions, since F-keys always are at the same position, while the relevant function on the touch-bar is not, necessarily, or at least the boundaries of the functions are not that distinct as with physical F-keys, so at least some visual check, before moving your finger, is needed for the touch-bar command, while for F-keys it is not.

So it seems that the touch-bar is just another eye-catcher - yes, it’s cute when you look at it in the store -, but its full functionality should be replicated, both in the Mac and the Windows system, by physical F-keys plus visual indicators on the screen; 3x4-groups give immediate indication which F-key to press, even without looking out for their respective number, “counting” them or otherwise. Also, I doubt very much that the touch-bar of a tiny-and-cute MacBook Pro will present more than 12 different functions at the same time; if it really does, this will sharply rise the time for reading/identifying the correct function, so that could not be regarded as an advantage at all - the same is true for big screens where the readability then is much better, but the “findability” will not rise accordingly.

As for the old criticism that it’s not explicit: First, now it’s Apple which re-introduces the system, so it’s above “hating” but has to be accepted as anything else that Apple pushes into the market. Second, bear in mind that it’ll spare you, to the extend of the application of this system, both to have to remember weird key combinations, and to then press them (hoping you’ll press the right one). Third, bear in mind that you always have the “help file” before your eyes, and that even if you lose time by needing to read the lettering, you’ll quickly find the correct command, while in the alternative of dozens of multi-key combinations (Shift-Alt-Something and all that) you do not have the help on-screen but you will have to look up the right key combination elsewhere, in some file or some brochure.

Fourth, bear in mind that it’s perfectly possible to allocate standard functions (F3=search again) to their standard keys (F3 here), and that there will not necessarily be a mix-up of it all; this will depend on the courtesy of the developers, and in order to have users accept their software, they will have big interest in observing standards, like they now have in observing menu standards or ribbon standards; we all tend to discard software wherever possible when they don’t observe standards. Also, it’s possible for example to assign some 4 keys, F1-F4, for functions which are available from everywhere, while only F5-F12 may be context-sensitive.

Whatever you think of my endorsement of that Apple re-invention, it’s obvious that its functionally better variant, F-keys plus 3x4-groups in bottom screen “line”, should be made available in general, for Mac*, Windows, Linux.

*: The irony is, Mac developers who sell their software as “touch-bar-ready” will probably not adopt it to F-keys since that would ask for some hours’ work, and “modern” Macs, as said, don’t have F-keys anymore (like, they told me, Macs do without any mouse keys except one) - but that’s no reason for not making the context-sensitivity paradigm available again for pc and elsewhere where Apple cannot discard the F-keys. Since it has always been there, even dormant, I doubt Apple got the whole concept patented (perhaps for text expansion? but even that should be available on F-keys, Apple re-inventions notwithstanding).

EDIT:

And bear in mind the traditional key combinations (Alt-F4 for example) would remain available, and, depending on the agenda of the developer in question, even ALL possible key combinations could remain available, even re-assignable by the user, as we know it from many a software today, as alternatives, so a given function would be some key combination OR some context-sensitive F-key, at your choice.

You would, in theory only, “lose”, in my concept above, 8 F-keys out of 12, BUT what are those functions currently which you really need to be available from anywhere in a given application? In reality, those F-keys are dormant most of the time, while you effectively need other commands of which you will have to remember their weird key combinations, so in practice, do you really need F11 for “maximize” all the time, or could it be Control-F11 instead, from now on, and F11 (as F5 and following ones) being readily available according to context?

Also, what is “context”? This concept of context could be quite broad, for some keys (F5…F8), and quite narrow for the rest (F9-F12), which means that some keys would be available, for the SAME function, in EVERY situation where their function would be needed, so you would not need to muse, is it the right context here or not, or check visually, but you just press the key, you’re certain that it’ll work the intended way. While the “upper” F-keys are very specific, and thus have their specific meaning in very specific contexts, so for them, you may check indeed quite often if you don’t use them, in that specific context, all the time. Now compare with rarely-used commands with some control-alt-something (which you won’t remember from now for the next occasion 6 weeks later), and you see that the context-sensitivity paradigm is superior both for often-used functions and for rarely-used ones.