Aric, I like your reasoning there. Its also canon
As I see it what you have is a number of layers, which for ease I've divided into Functionality (Hardware and Software), Security (Hardware and Software), and Display.
1st level is Hardware Functionality: Is the console hardware capable of performing the required function? (Yes/No)
2nd level is Software Functionality: Is the console software capable of performing the required function? (Yes/No)
3rd level is Hardware Security: Is the hardware authorised to perform the function (e.g. hardwired command lockouts)? (Yes/No)
4th level is Software Security: Is the user authorised to perform the function? (Yes/No)
5th level is Display: Is the screen capable of displaying the information (e.g. is it big enough)? (Yes/No)
So to perform a specific function, all the above have to be true (Yes), for it to work.
As I mentioned before, very simple logic flow here.
That works perfectly!
1st: We'd have formfactors like Terminal, Wall Panel, PADD, Tricorder, Desktop Swivel Terminal. Damage could be factored in to this level, as in, is the terminal too damaged to function.
2nd: This for me, should mostly apply if the main computer is either down or locked out with some fractal encryption.
3rd: That is exactly how I see it. While almost all terminals can do the same thing, SF:Regulations do not allow for it.
4th: Same as the 3rd layer just with software! lol Agreed.
5th: This makes sense, and canon we never saw a "mobile version", though we do also know custom UI can be created and used via canon so if planned ahead, Terminal UI's could have a different layout depending on screen size.
That logic flow makes perfect, logical sense and works perfectly with canon! I love it!