From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs raison d'etre Date: Wed, 13 May 2020 15:05:29 -0500 Message-ID: <87pnb7sira.fsf@red-bean.com> References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <70bb51fd-447d-928c-4d69-1c9673a44471@online.de> <871rnnvmdx.fsf@red-bean.com> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="45729"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Andreas =?utf-8?Q?R=C3=B6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 13 22:06:22 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYxe0-000Bla-Sl for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 22:06:20 +0200 Original-Received: from localhost ([::1]:40440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYxdz-0001qL-UJ for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 16:06:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50146) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYxdG-0001Kh-3e for emacs-devel@gnu.org; Wed, 13 May 2020 16:05:34 -0400 Original-Received: from mail-oi1-x22f.google.com ([2607:f8b0:4864:20::22f]:34740) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jYxdE-000879-VF for emacs-devel@gnu.org; Wed, 13 May 2020 16:05:33 -0400 Original-Received: by mail-oi1-x22f.google.com with SMTP id c12so21558470oic.1 for ; Wed, 13 May 2020 13:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=VJjG+jxmJaLEoTWB8nmpgp/po3b7yc7aMRYwxzRTTPs=; b=MUceeCJNS7Y5Xg6SakGLT0BEZpsm3upJvg3bvY1eW+Ew8ibBEcOi+xqJFGMTVGjiua Xr7Rj8FWOHuQrSH41n7gW6XAvEbWyJNF/vry5qxjOW+6lbscaT8RD5B89VuFM1tXCwNy LdI1zNXHyiA1BNROiI5+m1uI47SjcZqAr87ZJVbDUei7vfsTs4uewAVhxng8Sik67RNE iu+2zqbD0WOulrqxXYWSQynW69WQSfHCmYbDU9iLgSOuThHCkldjJWdaCLHUKjdG5hOj DiL6y0MZFfrbruqDlXZMpUdWIcebWkJm4ZLfssaSqS1Jee73DBglHVklhAK03CExbhpA Iikg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=VJjG+jxmJaLEoTWB8nmpgp/po3b7yc7aMRYwxzRTTPs=; b=JAp96rxHwMUWSKyowUwjb6b3LkYbK3ToJMiG32i8WwVjVdDLvPVBpYXFCKYewXIQU/ ql1TVHbmEHMOG2epDA9VqbOLIouTAkY3yojt1ioI2fLbTYBf9JnJo8N2W38upMvWXvbv d3D6u1zcI4RdgTNTU/9/QvKafO99VpIKB3e0o2UAH8E75M5eG09HxmUgxbkxaCxqWLaf oOVUjgAqNcjuyS86EYC91XL1C0TLSGP4CSdWvwebJqa1dSvf1c+84H0FPM9BAo0vOCjR c87SkdyyPHaw8nHCL1Bh+Qt45BJjVZSM64n9+Ev3DXvs4CXcTroIwcjC0vQrywk+OM9m uEDQ== X-Gm-Message-State: AOAM533UhY9bdO+kqQOq2nHZ0X12BH43WGPtAC5Zv8kgv4m5CWG0EFp7 85sOuOlpcfLVQIh89UjWLIQ5v1Kg X-Google-Smtp-Source: ABdhPJybQWQerTzB+Wm8MYOzKPFhBXUexpvshoSOyOSu9h1mg9vR1oIaFnBUEbxya6cDqykihpmCXA== X-Received: by 2002:aca:cf12:: with SMTP id f18mr2979752oig.117.1589400331496; Wed, 13 May 2020 13:05:31 -0700 (PDT) Original-Received: from floss (99-112-125-163.lightspeed.cicril.sbcglobal.net. [99.112.125.163]) by smtp.gmail.com with ESMTPSA id r11sm6150760oib.47.2020.05.13.13.05.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2020 13:05:30 -0700 (PDT) In-Reply-To: ("Andreas =?utf-8?Q?R=C3=B6hler=22's?= message of "Wed, 13 May 2020 21:39:52 +0200") Received-SPF: pass client-ip=2607:f8b0:4864:20::22f; envelope-from=kfogel@gmail.com; helo=mail-oi1-x22f.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250160 Archived-At: On 13 May 2020, Andreas R=C3=B6hler wrote: >Agree with everything beside two last paragraphs. Enjoying the >possibilities to extend and assisting new users being productive seems=20 >no contradiction. May you give an example where an smooth entrance >hinders the power of more complex functionality? The newcomer-vs-expert tradeoff is real, and it's pervasive throughout UI a= nd UX design. One example is button-based functionality. For both experts and newcomers,= those buttons/icons take away screen real estate -- but for newcomers they= make features easier to find, so it's worth it. For experts, they *just* = take away screen real estate, while providing little or no benefit. Use of small symbols to indicate state in the modeline is another area. Ex= perienced users know what "**" in the mode line means, what "%" means, etc.= Newcomers are frequently confused by the mode line; it is noise to them, = until they know how to interpret it -- but that takes a bit of investment. = Now, we could provide bigger, more verbose signs of current state -- but t= hen we'd be taking away screen real estate again. Another area is the keybinding space and the minibuffer. Just about every = time I have watched a new user use Emacs, I have noticed how frequently the= y accidentally hit some key combination or sequence and wind up in some wei= rd state that they never meant to be in -- and don't know how to get out of= . Often they have minibuffer prompts sitting around all the time, and are = unaware that Emacs is asking them for some piece of information (after all,= the user didn't mean to put Emacs into that state and has no idea she did = so). But having those keybindings available is *good* for experts, as we k= now from personal experience. I could go on. I've taught many newcomers to Emacs, and often the things t= hat are hardest for them are exactly the things that are *good* for the exp= erienced user. These design tradeoffs cannot be avoided. It would be a fallacy to think t= hat it's always possible to be *both* maximally newcomer-friendly and inves= tor-friendly.=20=20 (The term "user-friendly" is itself misleading. There is no such thing as = "a user" in a way that makes the term "user-friendly" meaningful. Better t= erms would at least attempt to make important distinctions -- "newcomer-fri= endly", "expert-friendly", "ADHD-friendly", "limited-movement-friendly", "v= isually-impaired-friendly", etc -- and would encourage designers to underst= and that being good in some categories means being bad in others.) Best regards, -Karl