Typos and HIG violations in the UI

Describe the bug

  1. There is a typo in the dialog for adding a Bluetooth LE "Device Moved Away" trigger: in the
    table view, one of the columns is labelled "Eestimated Distance", note the extra E. in "Eestimated".

  2. In BTT's "File" menu, "Open selected group" should be "Open Selected Group", and "Close open group" should be "Close Open Group". I.e., nouns should be capitalized. This also affects various entries in the "Edit" menu.

  3. Also in the "File" menu, any "Save" entries should come after "Open"/"Close" entries.

  4. In the "Edit" menu, there should be a separator line after the "Redo" entry. Likewise, there should be one after the last Copy/Cut/Paste/Select/Delete entry.

  5. In the "Edit" menu, "Delete *" should come before "Select All"

  6. In the "Edit" menu, "Save assigned icons to file" should not be in between the Copy/Cut/Paste entries; in fact, it should be moved to the "File" menu

  7. Why can I select "Save assigned icons to file" when there is in fact no selection at all? And what does it save then?

Device information:

  • Type of Mac: MacBook Pro
  • macOS version: 10.14
  • BetterTouchTool version: 2.825

Also think there should be more separators in there.

@Andreas_Hegenberg

Yup, agree!

1 Like

Most of them should be fixed in v2.827 which will be online in a few minutes.

1 Like

Thanks for the super-quick reaction, I look forward to trying things out.

Right now, I think the new user interface has some problems when it comes to dealing with the situation where nothing is select. Various menu items then are still enabled that act on the selection. E.g. right now I could choose "Copy selected item(s)" and "Copy selected item UUID", but the only thin that is "selected" is "All Apps" in the left-side list of applications. Selecting either does not seem to copy anything. (Also note how the one says "item(s)", the other "item" -- not important, but still jarring to me. Any reason why those are not just named "Copy" and "Copy UUID"?

Likewise, when I configure triggers, then in both the list of "Groups & Top Level Triggers", and also of "Actions Assigned to Selected Trigger", I can always select the trash can button, even when there is no selection.

And if there is nothing selected in "Groups & Top Level Triggers", then I can still select the "Plus" button under the list of "Actions Assigned to Selected Trigger", which then does nothing... Or I can use the one inside the list, and that then indeed adds an "action", but not associated to any trigger, which is super confusing (because I tried to add an action to a trigger, but did not notice that I had not selected the trigger in the list, and weird things started to happen).

Another inconsistency: Removing things from the list of applications is done with a little minus "-" sign; for the other two lists, with a trash can; adding things for all three is done with a "+", though they look different for apps vs. the other two lists; and of course the order is different: for apps "-" is left of "+", in the other two lists, the trash can comes after the "+".
Also, the "+" for apps actually opens a popup menu with three choices (one of which has a submenu), while for triggers there are two "+" buttons.

Finally: Would it be possible to add a unified list of triggers? One where simply all types triggers are shown? Right now, if there is an app in my list of apps with triggers, and I want to remind myself which triggers I defined for it, I have to switch through all trigger types to find out. Why not show a single unified list, perhaps with two columns, one indicating the type? I am pretty sure I'd then only use that list view (esp. if I could "sort by type" in it).

Another inconsistency: In the list "Groups & Top Level Triggers", if I click in some empty space in the list (they to the left or right of the "+" button which is embedded at the end of the list), then this deselects the currently selected trigger. Which is precisely what I'd expect.

But the same does not happen in "Actions Assigned to Selected Trigger". In fact, I'd expect that click to deselect all actions, and then switch focus back to the (still selected) group or trigger (and thus the rightmost column then should show again the configuration options for that trigger) . Right now, I keep doing this automatically (muscle memory from how other apps works), and am confused because it does not work.

Anyway, after all this "complaining", let me say that I really love BTT, and it keeps getting better and better; it replaces more and more other applications for me :-).

The menu item "activation" state has not yet been implemented, however they shouldn't do anything bad if no trigger is selected. This will be added sometime soon. The naming like "Copy selected item(s)" is intentional, in the previous UI many people didn't know they can copy and paste selected items, now that I have a menubar menu I want to make that clear.

Good point about the icons!

Unified trigger list is complicated and comes with all kind of problems, which is why I currently don't plan to add it. I might however think about a "view" only one, that doesn't allow any edits, but just shows a list of all triggers.

Interesting, could you give a hint as to what the problems are? (Feel free to go deep, I've been writing AppKit programs since the OS X public beta myself ;-)).

Of course one has to think of various UI ramifications; e.g. when using the "+" button one has to specify what kind of trigger to create, but that shouldn't be hard (naively spoken, at least), one could e.g. show a popup with all possible trigger types. But I am curious to learn if this is perhaps harder than I imagine for some deeper reason; or if there are other issues I am not seeing at all.

Anyway, a non-editable "view-only" mode would already help me (and I'll survive without it, too ;-).

I just updated to 2.827 and would argue that there are now too many separators in the "Edit" menu -- there shouldn't be any between copy/cut/paste/delete. That said, I still prefer this way over the previous version :-). Menu items are also properly capitalized now, thank you, so much nicer.

It's not that anything about the code for the unified list would be super complicated or exciting, more like the general UI setup and the necessary work.

There are obvious things like that I'd need to group triggers by type and prevent dragging or copying them into a different group.
The add button logic would need to be changed in order to allow adding to a specific trigger group, it would need to insert it at a reasonable position.
The cells would need to get some additional icon to identify their trigger type ....and so on.

Also currently the various views & cells for the different trigger types look pretty much the same (some differences e.g. Trackpad triggers don't have icons but Touch Bar triggers do). In the future I think there will be various trigger specific improvements and I think it might look weird when mixing even more cell styles into one list. Also I'm thinking about adding extra columns for some trigger types but not for others, a unified list would need to account for all this stuff.

I know this doesn't sound like hard issues, but I already have many other things I need to improve before working on additions like this one (which sounds easy to do, but I'm sure it would take much longer than it seems to implement nicely) :grinning:.

Why would you need to group triggers by type, though? OK, you may want to do that, but to me, it would be perfectly natural to display them as e.g. Finder has been doing for decades: with one column for the trigger name, and one for the type, and clicking on either columns sorts (resp. reverse sorts) by that; could even optionally show "creation date" and "last modified" dates (though probably only power users with gigantic lists of triggers would be interested in that). Of course instead of displaying the type by name, you could also (or in addition) represent it by an icon -- again, similar to how the Finder does it.

That would then alleviate most of the concerns you list in second paragraph. But OK, if you want to represent triggers with additional information in the future depending on their type, then this might not work so well anymore.

Don't get me wrong, I am not trying to be pushy here at all, just trying to wrap my head around this. I totally understand that time is limited, and even seemingly "trivial" things can quickly add up, and so you have to set your own priorities somehow :-). So, thank you for taking the time to explain!

E.g. Touch Bar triggers are displayed on the Touch Bar in the order they appear in the list in BTT (unless the user specifically overrides this.), so sorting could be quite confusing.
In general the Finder concept only works because files are not "user" sortable, they are always sorted by one specific attribute.