From ALB@immedia.ca Sun Jun 22 10:11:00 1994 Received: from Clouso.CRIM.CA by dkuug.dk with SMTP id AA11761 (5.65c8/IDA-1.4.4j for ); Wed, 22 Jun 1994 17:07:27 +0200 Received: from immedia.ca by clouso.crim.ca (4.1/SMI-4.1) id AA22110; Wed, 22 Jun 94 11:07:15 EDT Return-Path: Received: by immedia.ca (3.2/2.D) id AA5433; 22 Jun 94 15:13:22 -0500 Date: 22 Jun 94 15:11:00 -0500 From: ALB@immedia.ca Message-Id: <199406221513.AA5433@immedia.ca> To: i18n@dkuug.dk Subject: Re: Decimal delimiters X-Charset: ASCII X-Char-Esc: 29 ---------- Message original: ============================================================================== A: RNET (BEALLE@TOROLAB6.VNET.IBM.COM, CPWG-MAIL@REVCAN.CA, PAREF@VM1.ULAVAL.CA,), RNET ( UMAVS@TOROLAB6.VNET.IBM.COM), ALB De: RNET (ALB@immedia.ca) Objet: Re: Decimal delimiters Date: mar 21 jui 94 Heure: 20:36 TU Type: Mail Livraison: Reguliere ============================================================================== ---------- I received this from Glen. Now I see why we did not understand each other. In ISO terminology (ISO/IEC 9995) function keys are numerous and are not limited to F1-Fn. TAB is a function key, and the decimal delimiter is also a function key which is not enforced (interpreted by most implementers as a specific character key, which it is not intended for). Now I think Glen will agree. Alain Message original: ============================================================================== A: RNET (ALB@IMMEDIA.CA), RNET (IMMEDIA.CA!ALB@UUNET.CA), ALB De: RNET (glens@fultech.com) Objet: Re: Decimal delimiters Date: mar 21 jui 94 Heure: 18:23 TU Type: Mail Livraison: Reguliere ============================================================================== I am replying to you alone, since I don't want to bore the group with our disagreement. I think you may have misunderstood me on several points. First, as to the definition of a function key: I have never heard TAB, RETURN, SHIFT, etc. called function keys. These are present on all keyboards, and have universally understood behaviour. I was referring to the keys typically labeled F1-F12, located in the almost-inaccesible top row, whose function can usually be understood only by reading the manual. It is the use of these keys as the ONLY or primary user interface mechanism, that I object to. If this is not what you were propsing, I apologise. At the same time, if you were proposing that we envent a new "decimal delimiter" key, recognize that inventions of this type typically take decades to get accepted, and cause confusion and grief in the meantime. Second, you seem to believe that my objection is theoretical, rather than being derived from practical experience. Let me assure you that nothing could be further from the truth. It derives from my own considerable experience with USING (not designing) GUI-based applications, and from observing others do the same. I hate applications that make it awkward to do input without using function keys, although I use the keyboard a LOT. (I also hate applications that force you to switch back and forth between the keyboard and the mouse!) The only circumstance in which I have observed others perfer funtion keys is where they are using a specific application so much that they discover that some action that they have to do a lot, that usually takes several keystrokes or a switch to the mouse, can be done in one keystroke with a function key. Note that this works because it provides the EXPERIENCED user with an alternative, without taking away the primary mechanism, which is usually much more intuitive (at least in a well-designed interface). You allude to a proactical situation that I may not be facmiliar with. You are probably correct, and I would be glad to hear details. Finally, you seem to have misunderstood my recommendation for when to use which delimiter. You infer that the user would be constrained to use the delimiter specified by the interface, regardless of how unnatural this may be. Again, this is the opposite of my intent. Rather, the interface should permit users to specify the delimiter that is most natural TO THEM. If a user always wants to use a ".", fine. If, on the other hand it seems easier to type the delimiter that appears on the hard copy that is being entered, also fine. The point is that the USER gets to tell the system which is preferable. Given all of the above, I have a hard time believing that any user would prefer a function key. I hope that this clarifies my intent. /glen ----- Begin Included Message ----- > From uucp@fultech Sat Jun 18 15:31:10 1994 Date: Sat, 18 Jun 1994 18:41:00 -0400 > From: ALB@immedia.ca ---------- Glen says: >I disagree strongly. Function keys are not mnemonic or intuitive >and are therefore distincrtly unfriendly to inexperienced users. >One of the best things about a GUI is the lack of the need for >function keys. > >For data entry, users will want to use the separator characters >that they are familiar with, or that appear in hard copy that is >being entered. > >Having said that, I don't see why the LOCALE numeric and monetary >specifications aren't sufficient to handle input. Whether the >sparators get converted into a generic code after entry is surely >an internal implementation issue. > > /glen > >----- Begin Included Message ----- > >Date: Fri, 17 Jun 1994 16:20:00 -0400 >> From: ALB@immedia.ca > >---------- >Keld suggestion is well intended, but it would not solve the problem of ease >of switching from language to language. Why having to specify a parameter >when the function is the same for everybody on input? When you input, you >input. If it is to be fed back on a screen, it is a presentation matter and >then you show the character specified in the LOCALE and even the thousand (or >chunck) separator. > >For input you should use a function (you press a function key), not a >character (not a character key), to indicate the system you want to delimit >the integer from the residual, fractionary part of the whole number. It >should even not generate a control character (at least not necessarily)... > >Alain This is based on a real practical problem I described but that I see, Glen, you were not confronted with. If a GUI is good in theory and is beautiful, shouldn't it suffer exceptions if it is not so elegant in practice. Function keys are indeed necessary for functions on keyboards. What about the select level 2 (traditional shift key, a now deprecated term), the tab key, the return key, the insert key, the delete key and so on. What will GUIs do to replace these? If what is necessary to operate on text is there, why wouldn't what is necessary for numbers be there? I still maintain that a function is required for that so that you don't have to change input parameters because you use different presentation features for translating for output the result of a same input function. In Canada indeed, I mean even in English Canada, I heard some scientists say they were using the SI conventions in scientific work (so a comma as a decimal delimiter) and if they use a banking software they will have to use a decimal point. Why changing input parameters for numbers even if presentation is changed? The same kind of conceptual objects, numbers, are manipulated in both cases. Furthermore, let's say you are also in Canada, and you do your billing for different countries and different currencies and currency presentation conventions, why should you bother the person that enter numbers in escudos to enter 123$45 sometimes, 123.45 some other times and 123,45 some other times (bothering will occur, as our users encounter the problem, when you're forced to adapt your input method to the output presentation characteristics of a report you will perhaps never see). No, really, I sincerely believe the problem our users have (which is a fact, not a theroretical fantasy) has only one solution: to have a function for separating fractions from integer. That fuction has no reason to be dependent upon presentation parameters, a bit like it was wise in ISO/IEC 10646 to choose coded characters for Arabic that are not dependent about the position of each character (Arabic letters have typically 4 different shape according to their placement in a word, initial, middle, ending or stand-alone, but coding does not code shape variants any more for normal applications). Now before I end, because this is a position adopted at our Canadian TG9 and that you're a Canadian, tell me if you still don't agree. If there is no internal consensus in Canada, I will present it as a personal contribution. I want to be loyal to my friends, and to the national body I represent. I will respect your opinion even if you don't agree with my further explanation. So far I maintain my personal position though. I will present your opinion to SC18/WG9 with the contribution, whether it has personal or national status, so that others can have all the light they need to form their own opinion. With my best and friendly regards. Thanks for this frank opinion. I need such opinions in advance. Not after an eventual ballot. Alain LaBont ----- End Included Message -----