I've written about that problem several times, here and in outlineruserlunaticswhining.com. Also, cf. my post re that Apple mobile Mac touch line above the F-keys, here, some year ago.
1)
In a year somewhere around 1982, in the "IBM XP" or "XT" or whatever they called it, there had been 12 F-keys, in 2 6-keys columns (F1...6 and F7...12) at the left of the keyboard (kb): almost perfect, for ANY "batch processing" of any kind. Then, those 12 F-keys were REPLACED by 12 F-keys above the kb, in 3 groups à 4 F-keys; if those lunatics had grasped the need for ADDITIONAL F-keys, we wouldn't have fallen into that Windows-PC non-interactivity we've now have endured for almost 40 years.
F-keys to the left are for "batch-processing of any kind", as I've just said. This means that whenever you do NOT much of typing, but do "batch" processing of any kind, your left hand (for left-handers: everything to the right, 2 times more expensive, I know) will not be above the kb, but on your desk, to its (the kb's) left), and your digit will press the relevant F-keys. On the other hand, for any command you'll need when typing, those F-keys 1...12 ABOVE the kb are perfectly situated, e.g. for bolding things, or whatever, so we always would have needed BOTH ranges of F-keys, but hardware lunatics stole that setup from us.
As an aside: Cherry lunatics have been particularly idiotic - wait: I'll prove it: they're real idiots! -: Whilst in the Eighties, really good, i.e. journalist's kb's were about 300 Deutschmark (= around 300 bucks/Euros now), with LOTS of additional (F-) keys, in those years, Cherry produced some kb's with just SOME additional F-keys, mostly above the (regular) number keys / the regular 1...12 F-key range, and then, they only continued to sell those in the U.S. - not speaking here of the 5 left-alone key placements around the 4 arrow keys on your (standard or whatever) kb; whenever Cherry put those 5 keys there, it was for CRAZY kb's, having, instead of the num-keys, some what do you call again, for finger-mousing? Crazy, as said.
Technically, there is not the slightest problem with 24 F-keys, since the Windows system, from its beginnings or at least since very numerous years, is able to process the scan codes for 24 F-keys, not just for 12; ok, those F-keys 13...24 do NOT have dedicated scancodes, but those of Alt-Control-F...1...12 or whatever; I'm too lazy to look it up for you, not being your valet, but fact is, introducing, and then maintaining, 24 F-keys instead of just 12, would not have caused the slightest problem with anybody's system.
As you perhaps know, some "gaming" kb's have introduced 1...5 or 1...6, in exceptional cases even 1...10 or 1...12 additional (!) F-keys, at the left of the abc keys of their respective kb. Unfortunately, these come with totally crazy scan codes, almost invariably (?), since my trial with such a Logitech kb (the G910; and such a trial implies that you have to send that piece of crap back, and they will never sell you any other thing, good or bad, most of the time) showed me that its 5 additional F-keys send the scan codes of F1...5 - are those coders outright crazy?!!!
As said before, there are quite almost reserved scan codes for F13...24, and it seems (?) that no hardware (kb) manufacturer currently has the minimal IQ (of around 85, or let's say 82 1/2) to em- and deploy them.
2)
Thus, you need additional input devices; some "keypad" or similar; of course some real numerical keypad which just doubles your regular numerical keypad will NOT do. (They send the same scan codes as your in-kb numerical kb does, so their only use if for left-handers using a regular, right-hander kb.)
As I said before (here and elsewhere), the almost-ideal solution for this problem is the Cherry (!) 4700, with 21 keys (18 of them being 1-key-size, 3 of them being 2-key-size: "0", "enter" and "plus"); the scan codes are NOT stored within some electronics within the keypad itself, so it relies upon (un-problematic) software, but it's just around 40 bucks/euro or a little less; the alternatives are a Preh 30 (with, you guessed it, 30 keys, which is, in theory, much better, but then, you can hold the Cherry (which then is always sitting on your desktop) in your hand, pressing the keys with your digit, and which comes tremendously handy, whilst the Preh 30 is much too big for that, and that implies you will NOT be able to press the (30) keys "blind", whilst you'll be able to do exactly that with the (21) keys of the Cherry).
And then, the Preh 30 (which was around 110-120 euro/bucks these last years) now costs around 150 euro/bucks, which is, for the little it has to offer, quite a fortune; similar for the U.S. alternative xkeys (came with 30 keys, now just offers 24; obviously, they GOT the very relevant idea of grasping the device with your hand, in order to then press the keys "blind"); both Preh and xkeys come with in-built electronics storing your functional assignments, BUT in your practical computer life, that does NOT make ANY difference to the ("electronic-less") "cheap" Cherry 4700 (and which is the only device tiny enough in order to be held in your hand, after all; and no, I do not get ANY dime for promoting the 4700 here).
There also are some foot pedals, but it's evident that with just 2 to 3 "keys" available from them, you will not travel far.
3)
In practice, you will assign some key "combinations" to those additional keys, in order for them to be sent to your system, and then, you will have some macro tool which intercepts those (as much else), and which then assigns the respective commands = specific key "combinations" (i.e. "shortkeys") to the applications in question, e.g. in AHK by "if active window is named something, send this command, else if it's named something else, send another command (but which - hopefully - similar functionality), and if it's something else, this, that, and so on ad infinitum in case).
For my 4700 - I also own a Preh 128, but your digit-travel to reach the relevant key is too long, so I shelved that -, in the Cherry software, I entered the following key assignments: 2 rows à 4 keys on top: Shift-Alt-F1...8, then the 3x3 digit-rows 789, 456, 123 sending out Shift-Control-Alt-F1...9 (so original 9 is 3 whilst original 3 is 9, and so on), then the 2-key-space 0-key is Shift-Control-F10, the comma-key is ditto-F11, the enter-key is ditto-F12, whilst the 2-key-space "plus" key is Shift-Alt-F9 again, and which leaves me with ALL Shift-Control-Alt-F keys being "taken" here, whilst only the Shift-Alt-F-10...12 F-keys are to be used otherwise, the rest of them being taken, too (as said, 21 keys here, not 24 or more which would have been much better indeed).
Then, in AHK, I do the "real" assignments, as "for +!F1:: in appli x trigger a, in appli y trigger y, and so on".
All these devices come with - regularly inferior - software which in theory would allow for assigning, instead of just key combinations, full "macros", but these tools are so bad that's in your interest to just "program" key combinations, and then do the "real work" within the macro tool of your choice, all the more so since you will not have your macros spread over several tools, but in just 1 tool, also "servicing" your regular F-keys, your regular numpad-keys, and other non-abc keys on your kb.
4)
With all those devices, the memory problem arises: How to know which key is the right one, for any such function, in any such program? As I said before, and of course, you will be interested in "targeting" similar commands to the same keys, "prev/next tab" should be assigned to the same keys, in every application, and whatever the specific commands in many such applications?
I have scripted a timer which, for every "active" application, updates (and displays) some "help file" for me, and in which I list the respective key assignments; it goes without saying that for such a setup, you need (quite big) 2 screens at the very least, and that there are 2 additional problems: (manual) sync problems with your real macro assignments and your updating your help files, and then, visually checking the help file, in some corner of your several-screens setup, doesn't really come handy since it takes time and effort. (It' understood though that you only need to check for rarely-used commands in your daily-used applications, and/or for (any) command in your rarely-used applications.)
5)
Enter keypads or whatever which will SHOW the current key assignment. For some years, there has been some Russian developer who sells keypads, etc., onto which the keys have some luminous inscription (how do you call it again), indicating the current functionality (by LCD within the key itself); the prices are within several dozen bucks/euros per such key, of course; you will note that those are mini-LCD screens embedded within the MOVABLE part of each key, so it's / it would be no surprise if this is both terribly expensive, and also probably not really long-life? But this being said, if money isn't a factor in your expenses, you'd be probably well-advised to buy that Russian thing; google "Art Lebedev" (no dime for that either).
A low-price alternative is the "Elgato Stream Deck", which for one, in its own software, specializes in facilitating YT stream commands, but which is also usable like any other external macro device, i.e. for sending out key combis; it costs, for 15 keys, around 150 bucks/euro, so it's only a fraction of the high-quality Lebedev devices, per key, but its quality is on par with its price it seems, cf. some review on the relevant German amazon page (it's also sold by MediaMarkt/Saturn and which "both" (b/c it's the same owner) sell a LOT of crap): You press those "keys", and you'll never be sure whatever the result will be; btw. any of those "keys" are either a "command" OR a "folder for commands", which means 2 things:
- 15 keys are not enough, I'd need ALL of them for "folders", i.e. for command RANGES alone, and:
- the software coming with those devices obviously is not able to check for itself in which "context" = application you currently are, and by extension, which SET of commands currently should apply, a task which AHK e.g. excels in:
In other words: You would have to switch to your "current context" manually, whilst in AHK, e.g., it's the macro tool itself which determines that context, and you just press the key in question.
6)
Also, there is a fundamental problem with such, "visual-hint" kb add-ons: Their intended use is with "icons", and my personal assumption (which could be erroneous) is that all this is a resolution problem, i.e. how many pixels would such a "key LCD" have, after all? SOME icons are ok, the ubiquitous ones, but for any lesser-used function, text-driven indications would be oh so much better after all; with the Lebedev devices, they may be possible; with the Elgato Stream Deck, they do NOT be seem possible (or perhaps then 2-4 big chars)?
Hence my reminder of my thread, 1 year ago, re that Apple "touch board" here, or whatever they call it, or of that age-old on-screen (!) current-F1...12 assignment hints (3 blocks of 4 > almost-immediate visual recognition) mentioned in that Apple thread of mine here; of course it would be feasible to devise additional kb's with LCD fields BETWEEN the keys, but as implied above, currently the Cherry 4700 is the only such additional kb which is really FAST in key pressing, and ONLY (again, see above) for "batch" commands (b/o its tiny size), NOT for commands-within-typing, and any additional even just 21-key device would be double its size if it had to contain LCD fields above those 21 keys.
7)
It's obvious that any non-lunatic kb manufacturer would do the following:
- use Cherry "brown" keys (for ANY key of course)
- put TWO 12-F-key ranges above the abc-and-numeric keys, sending the regular Windows F-key scan codes F1...24, and with 2 ranges of (quite-high-resolution) LCD screens, above and below (1 double-height such screen would put the second, the 13...24 F-keys range too much out of immediate reach of the users' fingers):
- the LCDs for F1...12 being "1-line", to contain the "regular" commands/macros, to be frequently triggered, and to be easily remembered (most of the time); the LCDs for F13...24 being "2-line", for "rarer" commands/macros / more-rarely-used applications, i.e. the LCD in place being able to neatly display some 20, 24 characters, incl. some (very short) comments applying to those commands/macros.
- again, top-to-bottom:
2-line LCD
F13...24
F1...12
1-line LCD
- then, for "bulk processing" - oh yes, since anytime you process "in bulk", e.g. distribute pics (or other, text/web/mail, entries) to their relevant tag or folder "targets", all those a...z and 1...0 keys are a helluva of a nuisance, in order to reach F1...12 (let alone F13...24) -, and you would like to put your left wrist on your desk: 2 to 3 ranges or 5 or 6 keys (if 6, with a little additional space between #3 and 4) to the left of the (yes, quite enlarged, but so what: whenever you do "batch processing", your fingers are NOT on the abc keys, but (should be, for left-handers) to the left of your kb: some perhaps 6, 8 cm further to the left then do not do any harm), and from left to right:
- very narrow LCD sidebar for:
- F-keys 25...30 (all these sending scancodes as explaines above, for "remote" key-combis)
- very narrow LCD sidebar for:
- F-keys 31...36, then:
- F-keys 37...42, and then a:
- larger LCD sidebar for the previous F-keys 37...42
- sell the thing for 300 bucks/euro
As you can see from the above, the only "difficulty" lies in assigning the relevant commands/"macros" to all these F-keys; it goes without saying that some such assignments will be doubled, appearing in the F1...24 keys for "immediate, in-text" triggering, as well as in the F25... keys, for "batch-processing", and that term also includes key commands triggered by your left hand, while your right hand actions the mouse, e.g. in graphic programs, in FontLab or similar (more-or-less graphical) programs (most of them being from Adobe nowadays).
Such "distribution of key assignments" should, of course, be specific to any given user, BUT it's also true that NO such user, or let's say probably 1 out of 10,000, would be willing to set up all this by themselves.
8 )
As explained above, I do it with automatically-displayed help files (rtf format) in some corner of my (3) screens; whenever I install new software, I assign the relevant commands/macros there onto the "standard" keys in question, and more "remote" commands/macros to additional ones; also, I use the whole standard numerical keypad (the one within my kb) for commands and macros (except for calc/spreadsheets applications, of course; as said, there's no manual application switching in AHK and similar tools): Since my Cherry 4700 is "too far away" for non-batch-processing, and since my only F1...12 keys are simply not enough, and not immediately-reachable enough either, in order to trigger lots of "in-text" commands/macros.
Most applications have got just a little bunch of "standard" uses, so it's possible to assign standard commands/macros to standard keys, even for other users, IF there's enough such standard keys.
Thus, for standard applications (and a lot more in my case), you simply need a range of standard commands/macros you often need, and then some standard "distribution" of all this functionality (which often replicates itself, more or less, over several such applications) over some standard keyboard distribution, together with the correct visual hint organization, and then your overall productivity will be enhanced by probably 30 p.c. or more.
9)
You COULD say that all these additionals F-keys were NOT necessary/useful, since, yes, all they do is trigger weird key combis, and which, at the end of the day, you could enter as such, why not manually entering all sorts of shift-alt, control-alt, shift-control-alt and whatever key combinations? But simply, most of you will not have the necessary memory (performance) in order to retain all those key combinations, spread over all those different applications (50? 80? more than 100, as in my case? hence my almost 20,000 AHK lines), so some kind of more immediate access to it all should be welcome, AND with visual hints!
This also implies, for standard software (there are some 5, 6 standard file managers out there, for example), a rehaul of their respective .ini files or whatever they apply in order to store their respective, most of the time totally lunatic (instead of a little bit standardized) key combinations; in other words, with such a real 40-years-later kb should also come alternative .ini files, and registry scripts for standard applications "doing it" within the registry, in order to get to some
STARTING NORMALIZATION
... from which then on the respective users could do, of course, all what they want, but especially for the lesser-standard, more specific commands/macros they will be in need of for their applications and specific use cases; this being said, it's obvious that my macros, in ANY application, num1 = "go to the very first tab", num2/3 = "go to the previous/next tab", are such a sort of tremendously helpful "normalization"; you need macros for it since according to the application in question, different "native" key combinations are needed to do that. (Another example: On my Cherry 4700, "1" is "cut" (red dot, and OF COURSE with the according macro which hinders me to then do a second "cut", before doing the (ie at least one) corresponding "insert") anywhere, "2" (yellow dot) is "copy", and "3" (green dot) is "insert" (and re-sets the "attention: pending cut!" variable to 0), while "comma" is the the same in any hierarchy, for "insert as child", whilst there, the "3" above is "insert as sibling" - in ANY hierarchy. And so on.
We're ALMOST FORTY YEARS after the introduction of the "personal computer", and up to now, all those promises of more efficiency have been quite poorly fulfilled, and no wonder: If you switch between dozens of applications, always having to remember which key to press for what function(ality), that's awfully poor, "more than 35 years later", don't you think so as well?
10)
It's obviously not about the soft- but about the hardware manufacturers; of course, it'd be easy to implement all the necessary "un-do"'s, i.e. scripts saving previous ini files and all that previous, individual user's info if they then aren't happy with the result, but fact is, with "overall", with "over-all-application" user-software NORMALIZATION, AND (much) better keyboards, ideally with visual indicators, both for the "learning" phase and then, also permanently, for "lesser uses", i.e. for the more "remote" commands / macros / applications... with what you'd call
visually-assisted user-machine-interaction normalization
and except for those very specialized users who predominantly do just ONE thing on their computer - just number crunching, just graphics, just writing fiction e.g. -, I seriously reckon you'd win at least 1, if not 2 hours EVERY DAY - but of course you're all free to laugh upon my lack of the necessary hardware factory, while continuing wasting your time and your energy.
(In the Eighties, journalists had special kb's, with special software but just for writing; of course, that market was too tiny, and at the time, nobody obviously had the idea to make real use of those ace keyboards, so they vanished, together with their special writing software, and now, almost 40 years later, almost everybody go with a kb that is scarcely better than a typewriter's, but now for ALL their work to do, and just because they're all too lazy to do some scripting, individually, whilst better human-machine interaction is hardly seen but in big corporations, here and there, and because hardware manufacturers obviously don't know anything about users' (global-software) needs.)
You know, years ago I published here my (original!) idea for young people of earning 4,000-5,000 (bucks/euro) a month BUT spending 2,000 on that, ever month, on some unofficial help, instead of getting their first freehold flat in record time, but in order to earn 10,000 a month very, very soon, after which those helps in further career will be fully official.
I'm quite sure some followed my advice, with brilliant results, and of course without any "thank you", all to the contrary, calls to be be silenced are all I get. And then, there are those who do not even "get" what they're told beyond their previous standards, and they are legion; ancient Rome is history: not because they were all dumb but because most of the decision-makers - not speaking of the idiot masses then and today - over there were lunatics: smart people but who insist on thinking on rails though.
EDIT:
Num 1/2/3: Num1: More precisely, if the application in question has the function(ality) "go back to the last-active tab"; if not: "go to the very first tab in the row" - it just occurs to me that the "go to the last-active tab" is possible, in most cases, by some application-independent variable, to be set on any tab change.
Ini files and other storage places of the original keyboard shortcuts of the specific applications: I missed the fact that many macro tools (incl. AHK) even permit you to leave those original key assignments mostly all alone since they permit to assign (original) key assignments to (macro-tool) key assignments, e.g. in AHK for a specific application: num4 = send Shift-Alt-F5, that +!F5 being the original key assignment for some command in that application, and +!F5 in AHK and hence for your global assignments, by this, is NOT "done with", but remains fully available, for assignments, so if you then do "+!F5" in AHK, even in that application, it will NOT trigger that application's command (except if you say so of course).
In my practical work, I usually avoid* such "broken circles" but simply re-assign the original shortkey, within the application, to "nothing", in case, assigning the "global" shortkey but within that application, to the desired functionality, but for a third-party, commercial product, you simply would LEAVE ALONE all these original shortkey assignments, and just OVERRIDE them in that "broken circle" manner. (Just very simple macro tools do not allow for this, not being able to intercept the original key (combi) assignment.)
*=Thinking about it while writing about it, it occurs to me that with my (at last) fast computer, there is no (more) speed reason to do so anymore; just intercepting the original assignments and transferring them to the wanted, (hopefully) "global" shortkeys (or at least, to some 1-key shortkeys, for original 2- or 3-key combis) is the "neater" way, not speaking of other people's pc's.
And in order to further simplify things, you can perfectly allow every user, individually, to put on or off any "global-software" interaction with their specific software tools (application-bound toggles): You just refrain from doing your key-assignment (i.e. interception) tree by key, then by application, but you build it by application, then by key (for speed reasons, this variant will not work well on 8088 computers, he, he!).
EDIT 2:
Well, to present this sub-subject correctly, some important commands, within the respective applications, do NOT have been originally assigned some shortkey, and instead of then doing (visually ugly) menu or ribbon commands, whenever it's possible to assign an(y) additional in-application shortkey which you then can simply intercept / further process later on, that's much preferable. Hence the need to run some script on those elements of the application in question. And this again shows what a poor "servicability" most applications have got, not API or such to smoothly permit such kb (or other setting) changes from the outside. Also, we see here how bad the OS (Windows) is; had they foreseen these global-standardization needs (of the users, in order for them to work efficiently, with multiple programs), they could have easily enforced the necessary interfaces between the application level and the OS.
Also, so-called window management is incredibly bad, by OS means; shifting around windows into different (standard) positions (for different workflow combinations) should be really easy, i.e. be available by kb - I've got quite some such key combinations consumed for such means now but can't really remember when I last tried to move or resize some window by mouse: just aligning windows is really the most primitive part of these routines... and all this is genuinely kb task (and so easy code-wise that you really wouldn't need some special tools for that), fit for some global kb package, which of course should comprise as many standard applications as benefit maximizing greed would allow to maintain up-to-date.
EDIT 3 (July, 23):
To be honest, the Logitech kb comes with software which then allows for assigning other functionality - hopefully some key combis - to those 5 keys, and which then you can probably trigger from your global macro thing; don't know since I bought and returned it when I hadn't a pc on which that theirs software ran; but even then, having to run another dedicated software package just for 5 additional keys is crazy, sending F13...F17 would have been so much more natural in that case, than, as said, sending another 1...5 again.
This being said, it MAKES sense to duplicate functionality, for in-text(ing) use AND for batch use, for right hand AND for left hand, in some cases; e.g. for cut/insert, for bolding..., but it certainly makes NO sense to double the functionality of left-hand 1...5 (over qwerty/z) with 5 keys just some cm away. -
Remember, in the Mac-mobile thread, I said that they did NOT ADD that visual-key line to F1...12 keys, but they just replaced them with it, but since all this application-specific (or even situation-specific) key assigning is about making available what you will most probably need there/then, just 12 or so "things" isn't enough, especially since it's not even user-specific but done by the respective developers for then all of their applications' users. It seems, in practice, that in most situations, will not NOT even have 12 virtual keys in that line, but more often than not, many less - while in theory, at least, it seems that within that line, even more than 12 such "keys" are technically feasible; of course, more needed precision in digit tapping will reduce your speed even more (additionally to the speed reduction caused by the fact that it's about virtual, not physical keys). -
Another aspect of mobile devices: If they don't come with a numerical keypad, you're more or less helpless, command-access-wise, since you will not even be able to use your regular keypad commands; in other words, you shouldn't buy 13" devices or lesser, and strictly discard any bigger-screen device which doesn't come with a numerical keypad - there's room for such a thing from 14" screens on, but even some 15" devices come without. -
As an aside and alluding to my sayings here re "application/window management" in some other thread, and also adding to what I've said above re the application-OS interaction, it's simply crazy that with "on-board means", you're unable to quickly and consistently identify the currently-"active" application, i.e. the one that will "accept" your kb input.
Btw, for fast window switching alone (the mouse cursor should be switched in line, which is technically very easy: it's simply crazy to switch active window, just for having then to find the current position of the mouse cursors visually (e.g. by moving the mouse a little bit), and then to move it manually to its new target window, but that's exactly what most of you do), you need some additional keys; for 4 such windows (left screen 1/3, left 2/3, right 2/3, right 1/3) I've used F9...12, but needing more such windows for 3 screens, also for some, 2 windows beneath each other, I'm currently searching for a better solution, shift-F9...12 and such not being fast enough; F1...24 above the 1...0 would have been the ideal solution for this problem, with up to 10 keys in 2 rows just for window targeting - the mouse having been invented for graphics programs in its day (and then you really need F-keys in some left-hand device, not, for your hand, on top of a full kb, beyond all the a...z keys for each key press).
So for active-window identification, I only found the really ugly solution to have a timer in case (ie if there's been a change) move some quite big color rectangle onto the caption of that active window, a little bit to the right so as to permit to read some of that caption's text altogether, and bigger than those captions, for better visibility - there's systematically some room for this (i said it's really ugly); in the old days, the active window had much better been identified visually, whilst today it's often almost impossible: it's more or less been smoothed out, for esthetical ("beautifying your screen experience", my ass!) reasons, up to a point where you need to revert to such crazy means as mine described here, in order to visually identify your active window (and not having to press the respective F-key; btw, such an F-key will only be really available for other, better things IN that window (and different such things, depending on WHICH application currently is in that window) if you can always be sure IF that window is currently active or not, without that visual check taking long seconds.
Here again, it's the "overall interoperability of your system" or whatever you call it, which is clearly lacking, buy OS means, not speaking of the fact that it's Windows itself, of course, which should correctly and automatically re-position your mouse cursor (within the center of that window, whatever it may be) with any active-window switch. (It goes without saying that within macros with interact with different windows in their curse, the timer stops, so as to not flash the visual indicator around while it's of no use for the user anyway.) -
As for additional (and left-hand, to be used in combination with the mouse in your right hand, or vice versa) input devices coming with software, there are available some such - at least software-wise, dedicated - devices for Adobe's Photoshop, and also for (equally expensive) video cutting software, the kind within the 4-digit range: It's obvious that people who make their living with such a program, and obviously for time (/) efficiency reasons (or their respective employers), are willing to spend several 100 bucks for such dedicated devices, coming with dedicated (? at least originally sharply targeted) software, which then can probably be adjusted to the specific user's needs, for that one single software (used many hours a day).
On the other hand, it's not worthwhile to even think about marketing such additional devices, including software, from a developer's point of view, since for one, as (more or less) explained above, it's not even reasonable to do much with additional devices, all day long in general pc use, a simple 4700 will suffice, and you will only need it in order to replace those missing 18 F-keys ideally on (! instead of to!) the left of your kb, whilst on top of the kb, there's some other 12 F-keys which are missing, and some other 5 keys missing "around" the arrow-up key - of course you can color those 5 keys differently, e.g. red within an otherwise grey or black kb, in order to clearly differentiate 3 groups of keys there, the 6 on top, the 5 additional ones, and the 4 arrow keys; btw, it's especially those 5 keys which I miss a lot, since the ONLY "functional" key which is in immediate vicinity of those arrow keys, is the "delete" key, and with all due respect to idiotic "engineers", it's clear as day that most of the time, if you do "manual batch processing" within some list, some tree, it's NOT for deleting most things, but for triggering other commands on (some of) them, and unfortunately, if you really want to use your numerical keypad for those commands, you would need to use your thumb for the arrow keys (down-arrow, most of the time), a thing which I never got accustomed to, or you would need to move your hand A LOT, in order for your digit to press the arrow keys AND then the - far-away - respective commands, your only other alternative being to press the numpad-keys, more-or-less "blind", with your ring (4th) finger - thus, not having those 5 keys "around" the up arrow available, I use my 4700, with my left hand of course, in combination with my right hand pressing the arrow keys, and that's far from being perfect since, being a right-hander, my left digit moves much slower, so that my right digit, being under-employed by just doing the navigation, waits almost all the time for my left hand to have pressed the correct command in-between; WITH those 5 missing keys, I could learn/train a 2nd/3rd/4th-finger use for this arrow-AND-command key package.
And yes, this invariably leads to the finding that if you had a (full-sized) additional key beneath (!) your down-and-right-arrow key (instead of, quite often, mini-sized "media" keys just there), doubling the down-arrow-key (but sending another scan code of course), you could finally press that key with your thumb, for anything and mostly for "down" = next item in (whatever) the list, using the full numerical keypad, with your 2nd and 3rd finger, at very acceptable speed; the current position of the down-arrow pressing your right hand into a very awkward (and unhealthy) position if you try to do that now.
And btw, the arrow keys were originally set up as a real cross, with a space (no key) in its center, and here again, the original, very good idea was then lost: nowadays, you will probably not be successful in discovering any kb where the arrow keys except for the "up" one will NOT be positioned within a line. Yes, that has some advantages, too, but the obvious solution for all these problems is "doubling" the down-arrow, in order to make its "double" "thumb-ready", with different scan codes but which by default would function as down arrows (if the user doesn't then re-assign otherwise, for some applications / workflow situations), just like the 1...0 keys and the num1...num0 keys send different scan codes (ditto for num-, num+, num-enter), but send identical digits by default.
Back to dedicated left-hand devices: Since they come with their "factory" set-ups, they allow for immediate use within that single application, and since they don't come with dozens of keys, the user's memory will not be really strained: After some hours, the users will have memorized which key to press for which function, more or less. It's obviously not the same situation for some system trying to make the user efficient overall, in all their applications and, ideally, all their standard "workflow" situations: Here, the memory problem is an overwhelming one, hence the need for visual indicators, and as explained above, you could do - well, with some fonds that is, having it physically made by third parties - it for an additional device, but again, as explained above, this would force the user to "do it all" on and with that additional, left-hand device, while most of the time, kb-integrated F-keys and the kb-integrated num-keypad would have been the much better choice, but which then isn't available because of the lack of visual indicators, and so it's not surprising at all that additional keypads have never become widespread: the lack of visual hints is only part of the problem.
Also, there would be some learning phase indeed; following visual hints is one thing, taking the time for reading them, in that apprentice phase, is another one. But integrating visual hints within a(n also otherwise amended) kb (instead of forcing the use of some left-hand device even for things you better do within the kb) is comparable to those mobile Macs' visual-hinting, virtual (and as said over there, "context-sensible") F-keys ribbon: It's all there, it's (automatically, without user-side scripting) context-sensitive, and it's so much better than (remembering, to begin with, and then pressing) some Shift-Alt-something, so the learning phase will be more or less long, depending on the applications and contexts, but users will use more and more of the immediately-available, 1- (or, just for "remote" things, 2-) key commands, simply because doing so will greatly speed up their work, and because 1-keys come so much more handy than key combinations, remembered or not.
As said, Apple took away the physical F-keys, so concerned users don't have a choice anymore, but that's not the point: even if Apple had left the physical F-keys alone (and making that LCD or whatever it is a little bit broader, in order to also give hints there for the current command assignments of those physical F-keys), users would have adopted the virtual, additional, context-sensitive "keys": anything which is immediately available AND useful in that work context, is more than welcome, instead of taking away your hand(s) from the kb, as for example it's needed in order to press weird key combinations: the interruption in your work is quite sensible with anything NOT immediately-available-when-needed - and that's perfectly understandable, too: Remember those authors do refrain(ed at the time) from pc use, providing the explanation that writing by hand was "immediate communication with the result on paper" (or something on that line of thought), whilst using a text program would "interrupt" their work: even using arrow/del keys for inserting something, some words up, then going back, breaks your "workflow" - in fact your flow of thoughts! - to a much larger degree, than just crossing out some words by a single line (of the needed, immediately available length) of your pen, and replacing it with some other term(s) perhaps, scribbled in-between your lines or in the margin.
Thus, it's upon kb manufacturers to physically build such (corporate and home) "office" kb's, and then the necessary software will be NO problem whatsoever, software costs of even perhaps 10 bucks per 300 bucks kb should be bearable, and with users' (forcibly) sharply rising productivity (and that info coming down to non-users, left behind provisionally), sales will rise consequently. Remember, better kb's were available at some time BUT came without pre-figured software, and writing the necessary code then - let alone the really bad software systematically coming with those kb's which, except for the fact that it's resolutely proprietary, often does not even allow for a simple "if" - simply isn't out of reach, and be it just for time reasons, of the "regular user", hence the current situation:
Almost "40 years after", there is NO generic smart input device available, while it's obvious that kb manufacturers could, with better hard- and real (call it "overall-productivity" or something like that) software, compensate lots of the OS's deficiencies; it's utterly ironic that even MS builds (or have being built by third-parties) kb's and mice, but that those come with the worst software of them all; not even key combination assignments to mouse buttons were possible at the time*; this may have changed in-between.
*=Here, as with the kb, for the time being and in the absence of such elaborate software coming with the kb**: You assign some weird key combi to the key/button within the software accompanying the device, and then, in your real macro software, you intercept that key combi and write the necessary, in case multiple, routines for it, specific to the active application and/or the current work context.
**=Any kb manufacturer would have such software proprietary in functionality, but, in view of facilitating user-side adaptations, written in some AHK- or AutoIt-aligned code, and since many users, some even for health reasons, prefer using a mouse (or similar) of their own choice, (even third-party) mouse integration would be provided by interception of the mouse commands (sent by the software accompanying the mouse) by the "global" software, accompanying the kb but fully replacing what your current AHK- or AI-installation could do (so at the end of the day it SHOULD be AHK or AI; both are more or less in the "public domain" and thus "adaptable and adoptable", I assume), incl. e.g. text expansion and other goodies; with some better OS / Windows-internals integration than what's available to me, I'm also sure that "window management" and especially "active window's better visual identification" can be done in some more elegant way.
In theory only, such software would be independent from the hardware, but at this point in time, there simply is no hardware available which would make such generic software acceptable to buyers: i.e. immediately useful to them, that factor being a condition for possible marketability. You just can script such tools for yourself, and then live with the current real-life conditions grossly reducing the potential of what you will have coded, kb manufacturing, let alone the integrated lcd's or whatever, being simply much too expensive for your usual 1-man shop. (Oh yes, and there's always "crowd funding", ho, ho, ho...)
