In another thread today with a UI suggestion, Joe Taylor emphasized the
small number of contributors to WSJT-X, as well as how the limited time
available to those contributors means UI polish tends to take a back seat
to functionality. The post concluded by welcoming UI improvements from the
community, but notably without conceding the suggestion may be a good one.
In this thread you have a well-illustrated, constructive, and specific
suggestion from a user about a particular aspect of the UI which is
confusing, surprising, or less helpful than it could be. Your response of
"I don't see a problem", "The principle of least surprise is working as
intended here", and "should be familiar to anyone who has used a mouse +
windows application for computer interaction" indicates you see no issue
with the UI, and anyone who thinks otherwise is a fool.
The lack of contributors to the UI should not be surprising. With such
dismissiveness and opposition to change, who's going take the time to
implement a patch only to endure belittlement and rejection?
On Mon, Feb 26, 2018 at 10:16 PM Bill Somerville <[email protected]>
wrote:
> Hi Phil,
>
> comments in line below.
>
>
> On 26/02/2018 21:47, Phil Frost wrote:
>
> On Mon, Feb 26, 2018 at 9:12 PM Bill Somerville <[email protected]>
> wrote:
>
>> BTW this is not our design but standard Qt widget behaviour, which is
>> consistent with recognized "standard" GUI design principles.
>>
>
> While the double- and triple-click semantics are typical, I'd call
> including the unit ("Hz") and labels ("Rx" or "Tx") within the box are not.
>
> I don't see a problem, doing so saves some valuable space because no
> separate label is required.
>
>
> See Microsoft's guidelines:
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb226829(v=vs.85).aspx
>
> "You may specify units (seconds, connections, and so on) in parentheses
> after the label. Place units in parentheses after the label and before the
> colon."
>
> Adding units after the numbers they apply to is standard in written text,
> why not in UIs too?
>
>
> Or GNOME: https://developer.gnome.org/hig/stable/spin-boxes.html.en
>
> "Label the spin box with a text label above it or to its left, using
> sentence capitalization. Provide an access key in the label that allows the
> user to give focus directly to the spin box."
>
> GNOME's example does include units in the box, but I'd expect when they
> are in the box I could edit them. So I should be able to enter "1200" or
> "1.2 kHz" or even "1.2e-06 GHz", but this does not appear to be the case.
>
> One of the issues with GNOME and other single system frameworks is that
> hot-keys become very scarce and it becomes almost impossible to design a
> multi-platform UI with a rich set of such hot-keys. That does mean that Qt
> applications do become rather mouse centric but there is little we can do
> if the desktop manager uses up most of the available accelerator key
> strokes (ALT+ CTRL+ CMD+ META+ etc.) before we get a look in.
>
>
> I don't think Apple even has spinboxes.
>
> Of course they do, here is an example - with text included in the entry
> field:
>
>
> https://developer.apple.com/macos/human-interface-guidelines/windows-and-views/boxes/
>
>
>
> Regardless of QT's default behavior or any of these guidelines, any UI
> that requires explanation for something as simple as entering a number is
> not quite right.
>
> I don't see a problem, spin boxes contain numeric text (or something akin
> to numeric text like a letter selection A, B, C, ...) that have a forward
> and backward sequence defined, may or may not support wrap around, can be
> directly entered just like any text field and have useful, relevant, mouse
> and keyboard semantics like sub-controls to click up and down, keyboard
> arrow up/down, and keyboard page up/down for larger increments.
>
> We are discussing this because someone selected some text and expected
> something else to be replaced when they typed, the bad behaviour would have
> been if what they wanted actually happened. The principle of least surprise
> is working as intended here.
>
> These sort of widgets occur in most applications and should be familiar to
> anyone who has used a mouse + windows application for computer interaction.
>
> 73
> Bill
> G4WJS.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> wsjt-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wsjt-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
