From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: C-h K and C-h F in the Help menu Date: Sun, 21 May 2006 21:04:11 +0000 (GMT) Message-ID: References: <44701909.2050601@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1148245805 31363 80.91.229.2 (21 May 2006 21:10:05 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 21 May 2006 21:10:05 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 21 23:09:59 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FhvBU-0002Cq-PE for ged-emacs-devel@m.gmane.org; Sun, 21 May 2006 23:09:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FhvBT-0003Ou-Sa for ged-emacs-devel@m.gmane.org; Sun, 21 May 2006 17:09:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FhvBJ-0003OR-Ms for emacs-devel@gnu.org; Sun, 21 May 2006 17:09:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FhvBI-0003OF-Ab for emacs-devel@gnu.org; Sun, 21 May 2006 17:09:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FhvBI-0003OC-7H for emacs-devel@gnu.org; Sun, 21 May 2006 17:09:44 -0400 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FhvF6-00078b-M2; Sun, 21 May 2006 17:13:41 -0400 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id VAA00589; Sun, 21 May 2006 21:04:19 GMT X-Sender: root@acm.acm Original-To: Lennart Borgman In-Reply-To: <44701909.2050601@student.lu.se> X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:54974 Archived-At: Hi, Lennart! Just sticking my oar in a bit .... On Sun, 21 May 2006, Lennart Borgman wrote: >Eli Zaretskii wrote: >>> Date: Sat, 20 May 2006 23:19:02 +0200 >>> From: Lennart Borgman >>> CC: emacs-devel@gnu.org >>> I recently got some comments about the help menu in CVS Emacs from a >>> long term Emacs user and fan (+15 y usage). One of the comments were >>> that there are too many things in the help menu. >> For some value of ``too many'': we have 17 entries there. Why is this >> bad? Each entry can be useful in specific situations. >It is a good question. As I understand it the complaints was from a user >interface view. Such a view is a mixture of logical and psychological >matters. Neither a logical or a psychological argument is then entirely >useful on its own even if they on their own are completely valid. >At first sight one might think that the time to find something in a menu >is proportional to the length of the menu. I think however that the time >required rises much faster, but I have not read any research about this. >As I said before one of the factors is probably the short term memory >span. This means that clear grouping with horizontal lines will probably >help (as soon as the user understands the grouping). I think this is right. >In the process of trying to grasp the grouping it seems to me that there >should be a big advantage in fewer items. >Submenus will reduce the number of items even if there is only two >subitems and I believe that this will be helpful for the reasons I have >tried to outline above. Submenus don't reduce the number of items. They just make some of them invisible, thus _increasing_ search effort. Activating a menu item when it is hidden within a sub-menu is much slower than when it is directly there. A deep tree structure is fine if you're playing a dungeons and dragons type game, but can be infuriating if you need to do a depth-first search to find some "lost" menu item. That's one of the main reasons I detest most menu interfaces. The way to reduce the number of items is to reduce the number of items. If 17 is too many (which I can quite well believe), then categorise them into "must have", "should have" and "nice to have", and get rid of all of the last lot. :-) -- Alan.