Conference bulova::decw_jan-89_to_nov-90

Which "standard" key functions are you referring to?  Do you mean editing keys
in text widgets?  For that case, there is a standard on VMS (terminal driver
line editing), and there are several standards on Unix.  Which one of the many
standards would you like to see?

--PSW

I recently got a note about an effort to get a new LKx01 keyboard designed
specifically for Unix.  I'm not sure what it would look like, but my guess is
that the letters would be lowercase.

I'd be very interested in seeing that note. The only keyboards that 
are currently under consideration are the LK201, LK301 (recently canceled)
the LK401 (For the VT400 and DECwindows terminals - not specific to 
any O.S.) and the LK207 (Special keyboard for large customer.)

Who is it that thinks we're building a new keyboard specificly for 
Ultrix? They are (I believe) ill-informed. It is true however that 
replacing keycaps on the LK401 will be easier than the LK201 so it 
is possible that this is what they are meaning.

James

I suspect it came from a request for ATT.

All you really need to do to get a "Unix keyboard" is order a few
replacement keykaps from Synchronics, and make their DECTerms
initialize to having ESC on the ~` key, ~` ont the <> key, and put <>
back on the ,. keys.   This mode is already supported by the real VT320
and by the DECTerm emulator, but the legends on the keyboard don't
support it.

Synchronics advertises in each issue of DEC Professional, they do custom
keycaps for $2.00 each, cheaper in quantity.  4 are needed per
workstation, for an additional cost of $8.00 or less to get yourself a
"Unix keyboard".  Somebody should copy this note to the folks who are
trying to sell Pmaxes at AT&T.

For non-DECTerm applications, users are less likely to need these keys,
but there might be some way to fix that too, via the DECW$KEYMAP files. 
I don't know for sure.

    re: Note 214.3 by IO::MCCARTNEY
    
    "LK301 (recently canceled)"
    
    	Does that mean my LK301 keyboard is worth something? ;-)
    
    
    				--Doug
    				  (Field Test user for LK301)

    Yes, its worth is equivalent to a Rainbow 150, PDP-6, or any other
    cancelled project.

Okay, my VMS workstation now has a "Unix keyboard".  I figured this out
myself.  I don't work for VMS or DECWindows or anything even remotely
related to it (I'm in a chip development group in Hudson), so anything
you do with this is totally at your own risk.

What you do is the following:

$ create/dir sys$common:[sys$keymap.user]
$ copy decw$keymap:north_american_lk201la.decw$keymap -
	 sys$common:[sys$keymap.user]north_american_unix.decw$keymap

Using two of the small screwdrivers that come with most VSII systems,
swap the `~ keycap with the <> keycap.  Using a BIC pen (the ink wears
well), mark the top of the ,, key with a '<', the top of the .. key with
a '>', and the <> key with 'ESC'.  (Or go buy the three needed keycaps
from Synchronics.)

Edit SYS$MANAGER:DECW$DEVICE.COM to account for the following difference:
$ diff /number decw$device.com
************
File SYS$COMMON:[SYSMGR]DECW$DEVICE.COM;9
   81   $ decw$default_keyboard_map :== NORTH_AMERICAN_UNIX
   82   $ decw$keymap ==		"SYS$COMMON:[SYS$KEYMAP.USER]," + -
******
File SYS$COMMON:[SYSMGR]DECW$DEVICE.COM;3
   81   $ decw$keymap ==		"SYS$COMMON:[SYS$KEYMAP.USER]," + -
************

Number of difference sections found: 1
Number of difference records found: 1

Edit north_american_unix.decw$keymap to account for the following differences:

************
File SYS$COMMON:[SYS$KEYMAP.USER]NORTH_AMERICAN_UNIX.DECW$KEYMAP;3
    4   ! Keyboard : North American Unix Keyboard
    5   ! Model	   : LK201-AA with a few keys re-arranged by Jeff Lomicka
    6   ! Mode	   : Unix Mode
    7   ! Date	   : 23-FEB-1988
******
File SYS$COMMON:[SYS$KEYMAP.DECW.SYSTEM]NORTH_AMERICAN_LK201LA.DECW$KEYMAP;1
    4   ! Keyboard : NORTH AMERICAN
    5   ! Model	   : LK201-LA
    6   ! Mode	   :
    7   ! Date	   : 23-FEB-1988
************
************
File SYS$COMMON:[SYS$KEYMAP.USER]NORTH_AMERICAN_UNIX.DECW$KEYMAP;3
   73   BF	001B		001B		! ESC (key labelled  ` ~)
   74   C0	0031		0021		! 1 !
******
File SYS$COMMON:[SYS$KEYMAP.DECW.SYSTEM]NORTH_AMERICAN_LK201LA.DECW$KEYMAP;1
   73   BF	0060		007E		! ` ~
   74   C0	0031		0021		! 1 !
************
************
File SYS$COMMON:[SYS$KEYMAP.USER]NORTH_AMERICAN_UNIX.DECW$KEYMAP;3
   82   C9	0060		007E		! ` ~ (key labelled <>)
   83   CB	0033		0023		! 3 #
******
File SYS$COMMON:[SYS$KEYMAP.DECW.SYSTEM]NORTH_AMERICAN_LK201LA.DECW$KEYMAP;1
   82   C9	003C		003E		! < >
   83   CB	0033		0023		! 3 #
************
************
File SYS$COMMON:[SYS$KEYMAP.USER]NORTH_AMERICAN_UNIX.DECW$KEYMAP;3
  107   E8	002C		003C		! , (<)
  108   EA	0039		0028		! 9 (
******
File SYS$COMMON:[SYS$KEYMAP.DECW.SYSTEM]NORTH_AMERICAN_LK201LA.DECW$KEYMAP;1
  107   E8	002C				! ,
  108   EA	0039		0028		! 9 (
************
************
File SYS$COMMON:[SYS$KEYMAP.USER]NORTH_AMERICAN_UNIX.DECW$KEYMAP;3
  111   ED	002E		003E		! . (>)
  112   EF	0030		0029		! 0 )
******
File SYS$COMMON:[SYS$KEYMAP.DECW.SYSTEM]NORTH_AMERICAN_LK201LA.DECW$KEYMAP;1
  111   ED	002E				! .
  112   EF	0030		0029		! 0 )
************

Number of difference sections found: 5
Number of difference records found: 7

    I beg to differ!  The PDP-6 was not a cancelled project.  Somewhere
    around 50 systems were shipped to customers.

I agree. I spent many a time working on the one at MIT.

    Beg pardon.... obviously the PDP-6 was much more useful and valuable
    than the LK301
    
    

    By standard key functions, I mean, for example, that to get a file
    a user would always press Gold-G, as in WPS-PLUS, regardless of
    whether the use was in X or Y editor, a spreadsheet, a graphics
    package, a mail system,  a project management program, a 
    presentation/publication (e.g., Document) package, etc.  
    For deleting a word, a user would
    always press the keypad's dash, as in EDT.  I
    don't care what keys are used for what, but just keep the keys'
    function the same between applications.  If the key function
    standards are kept, it's amazing how much easier it is to learn
    any application.  If you've used a Macintosh, you understand what 
    I'm saying.
    
    I realize that different software requires different key functions;
    there's no equivalent of a spreadsheet's key for deleting a column
    in a mail system.  But if the software uses the function, it should
    Teduse the standard key function, e.g., if there's going to be a delete
    word key, then use the keypad's dash.                                    
       
    

>    I realize that different software requires different key functions;
>    there's no equivalent of a spreadsheet's key for deleting a column
>    in a mail system.  But if the software uses the function, it should
>    Teduse the standard key function, e.g., if there's going to be a delete
>    word key, then use the keypad's dash.                                    
 
The default STEXT widget key bindings have provided de facto defaults
for this sort of thing.  However, one must be very careful about imposing 
standards on editing functions.  This is exactly the area where there are
multiple, conflicting key bindings across different operating systems and
text editors.  VMS line editing uses linefeed for delete word.  KP-dash is
used in EDT (I think).  The Rational EDT Keypad uses KP-commma.  And so it goes.
This stuff must be user modifiable.

--PSW

re:.11                          -< Std. Key clarification >-

    The DECwindows Clearinghouse (Software Quality Management) is
    attempting to develop some standard for DECwindows.  It will
    concentrate on the ALT/ modified keys, as the ALT/ key is new with
    DECwindows.  No other bindings will be addressed since existing products
    will have to maintain historical consistency for their current customers.
    (Your plea was partially addressed in DECwindows V1 "by policy",
    discouraging all applications from using ALT except in very restricted
    ways.)

Would an application that maps user keystokes into application keystokes fit the
bill?  There is an application on the MAC that does something like this.  Quick
Keys is the name that comes to mind.  It performs key-to-key, key-to-text, key-
to-mouse, etc. mappings.

This application has two types of mappings, one is universal and the other is 
application-specific.  The universal keys are available anytime, the applica-
tion-specific keys are only available when you are running the particular ap-
plication.  The user then can customize keypads for any and all applications.

I agree that key bindings should be as consistent as possible across applica-
tions, but I also feel that those bindings should be completely up to the user
(with intelligent defaults for each application.)  Wouldn't it be nice if you
could change a binding in one application and have the corresponding bindings
change in all other applications?

Wishing,

Wook

    Re:  .12
            
>>    I realize that different software requires different key functions;
>>    there's no equivalent of a spreadsheet's key for deleting a column
>>    in a mail system.  But if the software uses the function, it should
>>    use the standard key function, e.g., if there's going to be a delete
>>    word key, then use the keypad's dash.                                    
            
>One must be very careful about imposing 
>standards on editing functions.  This is exactly the area where there are
>multiple, conflicting key bindings across different operating systems and
>text editors.  VMS line editing uses linefeed for delete word.  KP-dash is
>used in EDT (I think).  The Rational EDT Keypad uses KP-commma.  And so
>it goes.
>This stuff must be user modifiable.         
                                             
    This "delete word" is a great example of what I'm talking about.
    A user of all these tools must remember what s/he's in to be able
    to delete a word.  With multiple applications running in Windows,
    this requirement to be conscious of "What am I in?" versus
    concentrating on "What am I getting done?" doesn't allow the user to
    get the job done as easily as possible.  Why have these different
    keys and hinder the users?  I am begging for standards now because
    Decwindows is an opportunity to start over and do it consistently
    (and, in my opinion, "right").
    
    
Re:  .13
     
>     "When in doubt, let the user decide."
    
    Users, at least speaking for myself, don't want to have to dig in
    and decide on the alternatives.  They'd much rather just start using
    the application and, since it would be in Windows, they'd know what
    most of the keys did.  Why force them to read the manuals and learn
    new key bindings, or learn how to change the bindings to the ones
    that they're used to (of course, when their offsite and want to
    use an application on that site's computers, they're lost relative
    to the bindings).
     
>    The DECwindows Clearinghouse (Software Quality Management) is
>    attempting to develop some standard for DECwindows.  It will
>    concentrate on the ALT/ modified keys, as the ALT/ key is new with
>    DECwindows.  No other bindings will be addressed since existing products
>    will have to maintain historical consistency for their current customers.
                                                            
    OK, let's compromise.  In each application, have the set of bindings
    that are consistent over all Windows applications, but also have
    the set of bindings that are historically consistent for the current
    customers.  Have the bindings also be user changeable, possibly
    as Wook describes in .14:

>This application has two types of mappings, one is universal and the other is 
>application-specific.  The universal keys are available anytime, the applica-
>tion-specific keys are only available when you are running the particular ap-
>plication.  The user then can customize keypads for any and all applications.
              
>I agree that key bindings should be as consistent as possible across applica-
>tions, but I also feel that those bindings should be completely up to the user
>(with intelligent defaults for each application.)  Wouldn't it be nice if you
>could change a binding in one application and have the corresponding bindings
>change in all other applications?

    
    
    Ted

    A person who wishes to remain anonymous mailed this to me, but the
    points are good enough that I asked for permission to post, which
    I obtained.                                                    
                                                                   
                                                                   
        i think you're making an excellent point.  DEC is surprisingly
    weak when it comes to devising/enforcing corporate-wide standards.
    i think the notesfile discussion has confused two issues here. 
    being able to customize one's key bindings has very little to do
    with having multi-product key bindings.  there are two problems
    here and solving one does not solve the other.                 
                                                                   
    regarding the standard binding problem.  i wonder how easy it  
    would be to mediate the conflicts between DEC's various products
    and arrive at a good set of standard bindings.  the desire for 
    backward compatibility has a way of ruining good designs.  the 
    compromise you suggest might save the day, but sometimes having
    and eating one's cake only leads to indigestion.               
                                                                   
    i grant you that changing one's bindings is a formidable task on
    most systems, so formidable in fact that i almost never attempt
    it.  this state of affairs should not be used as an argument   
    against allowing users to define alternate bindings.  if anything,
    it argues for DEC's investing more time/energy/money into making
    it easy (trivial!) to change one's bindings.  there should be a
    single product (widget?) for doing this.  this sort of facility
    is very much in the spirit of DEC's "internationalization" effort.
    in essence, what we want is something vaguely similar to Unix's
    termcap facility.                                              
                                                                   
    but can DEC afford to develop this?  not only would DEC have to
    pay a few smart people to make a bunch of smart decisions, it  
    would also have to pay a few programmers to create this new    
    facility, and then get bunch of existing programs to use it    
    which means paying a lot of programmers to re-implement existing
    functionality instead of doing whatever it is we're doing now. 
    sure, we'd get additional functionality, but would DEC get its 
    money's worth?  (Maybe DEC should be buying lottery tickets :-)

    
    (My thoughts:  I don't believe DEC can afford not to implement standard
    bindings, since we have 130,000 employees now and I'd guess at least half
    of us will eventually use windows.  The training savings and
    increased productivity would overwhelm the programming costs, to
    say nothing of increased sales caused by easier to use systems).

Unfortunately you didn't list the points that you thought are `good enough',
so I may be having a very strong reaction to a point that you don't agree
with.

>    DEC is surprisingly
>    weak when it comes to devising/enforcing corporate-wide standards.

I'd like to see this statement justified.  It this in reference to the
continual resistance to pressure to proliferate new keyboard designs ? 
Or perhaps the resistence to changing the `one system, one architecture'
hardware/software architecture of VAX/VMS ?  Or perhaps to the total
redirection of all windowing to X Windows based DECwindows ?

The standardization efforts in DEC are very strong and are probably the most
significant reason for the long development cycle everyone complaina about.

>    regarding the standard binding problem.  i wonder how easy it  
>    would be to mediate the conflicts between DEC's various products
>    and arrive at a good set of standard bindings.

Take a look at the six keys above the arrows on the LK201; when they were
totally new, the issue of legends was a major issue.  Several different
factions argued for a long time about the legends that were to be placed
on keys that no one knew how to use.  At one point Gordon Bell brought
everyone into a room an declared that no one was leaving until there was
agreement.  Five years later, there is still no agreement.

The reason for the lack of agreement comes from forces outside of DEC, not
from within.  Unix, workstations, and PCs are all trying to force change.

One thing is VERY clear; there is ABSOLUTELY NO GOOD SET OF STANDARD BINDINGS.
The best set today will be different than the set tomorrow.  Why?  Because the
the software tomorrow will be different than the software today.  How can we
decide on the best set of key bindings today for the wysins text and image
processing software of tomorrow when almost everything today is simple text?

>   ...the desire for 
>    backward compatibility has a way of ruining good designs.

This is absolutely true; but this also says that there is no one standard, but
instead many evolving and new standards.  If you think that you can manage
this change better than the current process, I strongly suggest that you
describe your process and sell it to the corporation.

RE: .16

You have a rather cavalier attitude about backwards compatibility.  Consider a
customer who has 1000 users trained with the key bindings of a current product.
The cost to that customer in lost time and efficiency of retraining those users
to a new set of key bindings may be measured in the hundreds of thousands of
dollars.

Fortunately, the DECwindows program has done the right thing here.  The CTRL and
main keyboard bindings are being left as is, and the DECwindows program is
standardizing the ALT key bindings (which are brand new with DECwindows).  Thus,
we have both compatibility with the past and a set of bindings standard across
applications.

--PSW

    re: .18
    
    Actually the attitude about "ALT" (aka COMPOSE) is rather cavalier.
    I'm taking bets on how many millions it will cost DEC ib terms of
    thousands of hours spent answering the question "why doesn't compose
    work anymore?".
    
    

This was definitely handled wrong (backwards) for the LK201. When we have a 
keyboard which has both ALT and Compose keys, things will be obvious. While we
have a keyboard with just one key for both, it should be used by default AS
LABELLED!

In other words, Compose-Space should be ALT. Compose by itself should be 
compose. Is there some technical reason this wasn't possible, or was it
simply not considered? 

    re .20:  That usage is rather unnatural (regardless of labels).  ALT
    (or Meta) is a key modifier while compose is a keystroke.

I agree with .18.

As for DECwindows doing a rather good job on being consistent on the non-Alt
keys: have you looked at DECwrite?

	paul

Re: 214.17    
          
>>    DEC is surprisingly
>>    weak when it comes to devising/enforcing corporate-wide standards.
          
>I'd like to see this statement justified.  It this in reference to the
>continual resistance to pressure to proliferate new keyboard designs ? 
>Or perhaps the resistence to changing the `one system, one architecture'
>hardware/software architecture of VAX/VMS ?  Or perhaps to the total
>redirection of all windowing to X Windows based DECwindows ?
       
    No, I'm not going to spit on and burn the flag; I realize that
    VAX/VMS has been an enormous success.  I also appreciate the resistance
    to window and keyboard proliferation.  Let's keep the discussion
    to key bindings between applications.         
       
       
>>    regarding the standard binding problem.  i wonder how easy it  
>>    would be to mediate the conflicts between DEC's various products
>>    and arrive at a good set of standard bindings.
       
>Take a look at the six keys above the arrows on the LK201; when they were
>totally new, the issue of legends was a major issue.  Several different
>factions argued for a long time about the legends that were to be placed
>on keys that no one knew how to use.  At one point Gordon Bell brought
>everyone into a room an declared that no one was leaving until there was
>agreement.  Five years later, there is still no agreement.
       
    No agreement?  I've never used those six keys for anything besides
    what is labeled on them.  They're a WONDERFUL example of the benefits
    of standard keys, as I use them without being conscious of them,
    no matter what application I'm using.  Perhaps we should put all the 
    developers in a room until a set of standard keys are agreed to?        
                                                  
>The reason for the lack of agreement comes from forces outside of DEC, not
>from within.  Unix, workstations, and PCs are all trying to force change.
                                                 
    The fact that the Macintosh has standard keys between applications
    should challenge us to do the same.  Regarding the other two, 
    can Unix or the workstations force us to use non-standard key bindings?
                                                 
>One thing is VERY clear; there is ABSOLUTELY NO GOOD SET OF STANDARD BINDINGS.
                                        
    Try telling that to a Mac user!  S/he enjoys being able to sit down
    and immediately having a feel for how to use an application s/he's
    never seen before.  The pull down menues do the rest.                  
                                                         
>The best set today will be different than the set tomorrow.  Why?  Because the
>the software tomorrow will be different than the software today.  How can we
>decide on the best set of key bindings today for the wysins text and image
>processing software of tomorrow when almost everything today is simple text?
                                                         
    I agree; in the future it may need to change.  However, we have
    a real opportunity with Windows to get the right set for the next
    10 years.                                            
                                                         
                                                         
>>   ...the desire for                                   
>>    backward compatibility has a way of ruining good designs.
                                                         
>This is absolutely true; but this also says that there is no one standard, but
>instead many evolving and new standards.  If you think that you can manage
>this change better than the current process, I strongly suggest that you
>describe your process and sell it to the corporation.   
                                                         
    The compromise suggested in .15 is an excellent way of having the
    standard keys along with application specific keys.  This also applies
    to reply .18   I'd be willing to bet the only people who stay with
    the application specific keys are those who use only one or two
    applications; people who use two applications with standard keys and
    one with application specific keys will change over to using the 
    standard keys for everything at some point in time.  
                                                         
                                                         
From .15, nobody has addressed the third paragraph below:
                                                         
>>>    I realize that different software requires different key functions;
>>>    there's no equivalent of a spreadsheet's key for deleting a column
>>>    in a mail system.  But if the software uses the function, it should
>>>    use the standard key function, e.g., if there's going to be a delete
>>>    word key, then use the keypad's dash.                                    
                                                            
>>One must be very careful about imposing                   
>>standards on editing functions.  This is exactly the area where there are
>>multiple, conflicting key bindings across different operating systems and
>>text editors.  VMS line editing uses linefeed for delete word.  KP-dash is
>>used in EDT (I think).  The Rational EDT Keypad uses KP-commma.
                                                            
>    This "delete word" is a great example of what I'm talking about.
>    A user of all these tools must remember what s/he's in to be able
>    to delete a word.  With multiple applications running in Windows,
>    this requirement to be conscious of "What am I in?" versus
>    concentrating on "What am I getting done?" doesn't allow the user to
>    get the job done as easily as possible.  Why have these different
>    keys and hinder the users?  I am begging for standards now because
>    Decwindows is an opportunity to start over and do it consistently
>    (and, in my opinion, "right").                         
                                                            
    Perhaps with the standard FIND SELECT REMOVE etc. keys and the
    standardized ALT keys, I'll have a set of standard keys that have
    most of the functionality I need for any application.  I'm not holding
    my breath, because other users who've been in DEC for decades say
    that the application developers will all come up with their own
    best (and different) way.  Those comments are why I started this
    discussion begging developers to stay with the standard.
                                                        
    Ted                                                 
                                                        

RE: .23

Developers of DECwindows applications will do what the XUI Style Guide tells
them to do.  The carrot is that their application will be consistent with
other applications if they do so.  The stick is that the VMS and Ultrix SQM
groups will not let products ship that are not conformant (unless they come
up with a very good reason why they are not).  Yes, left to their own accord,
developers will independently invent things.  However, they are not left to
their own accord.

--PSW

   Reply .24 is exactly what I wanted to here.  I just want to make
    it clear to developers that the requirement for them to conform
    to the standard has many users behind it!!  When using Windows,
    then, I look forward to thinking about the task at hand rather than
    remembering what the key bindings are in a particular application.

    Thanks,                                      
    Ted