From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <t.lamprecht@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id E669996107 for <pve-devel@lists.proxmox.com>; Mon, 23 Jan 2023 11:57:34 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id C403E258FF for <pve-devel@lists.proxmox.com>; Mon, 23 Jan 2023 11:57:34 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for <pve-devel@lists.proxmox.com>; Mon, 23 Jan 2023 11:57:33 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 60F5D45CC8 for <pve-devel@lists.proxmox.com>; Mon, 23 Jan 2023 11:57:33 +0100 (CET) Message-ID: <dc077dc9-8530-a96f-c661-b45b433e4e1e@proxmox.com> Date: Mon, 23 Jan 2023 11:57:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Thunderbird/109.0 Content-Language: en-GB To: Lukas Wagner <l.wagner@proxmox.com>, Proxmox VE development discussion <pve-devel@lists.proxmox.com> References: <20230120111712.243308-1-l.wagner@proxmox.com> <819b07ce-e9d2-b745-7a7b-e54e24c59e38@proxmox.com> <24dc416d-ffc6-63eb-91ea-f8a0abdd65fa@proxmox.com> From: Thomas Lamprecht <t.lamprecht@proxmox.com> In-Reply-To: <24dc416d-ffc6-63eb-91ea-f8a0abdd65fa@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.536 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -1.149 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [imgur.com] Subject: Re: [pve-devel] [PATCH manager/widget-toolkit 0/2] ui: replace non-clickable checkboxes with Yes/No text X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Mon, 23 Jan 2023 10:57:34 -0000 Am 23/01/2023 um 11:46 schrieb Lukas Wagner: > On 1/20/23 15:09, Thomas Lamprecht wrote: >>> While looking sleek, the problem with this is that from a user's >>> perspective, a checkbox generally implies that it is operable by >>> clicking on it (which we allow in other places, to make the matter even >>> more confusing). >> >> If it's editable it gets a pointer cursor, else not. >> I see were you're comming from, but do we also have any complaints on official >> channels w.r.t. this? > > No complaints, it's just something that I've run into myself repeatedly, e.g. when > enabling the no-subscription repo via the GUI. I think it's one of those UX > problems that might be annoying to some users (including myself), however it's not > severe enough that people care to report this in the bug tracker. > Ok, tbh. I have some faint memory that I saw some comment about this in the distant past; IIRC it was mostly due to the the "writeable" firewall and the "read-only" other usages using both the exact same display. > > I have played around a bit with FA icons, and I think I have found something that is visually > appealing, fixed-width and where it is IMO clear that it is not an actionable UI item. > For now, I think the nicest option is `fa-check` for enabled rows and `fa-minus` for disabled ones. > I've created an A:B comparison [1] between the old checkboxes and the new icons. > Please let me know what you think. > looks better than the status quo, especially UX-wise, and would be an option for icon only. So, if nobody else has hard feelings (but ideally somewhat rationally argued) for going with text over icon I'd go for your combination check-mark/minus icon combination. > > [1] https://imgur.com/a/tsXegNF >