Macpass: [Feature Request] Touch Bar Support

Created on 23 Jul 2017  Â·  9Comments  Â·  Source: MacPass/MacPass

At the moment, MacPass leaves the Touch Bar on the new MacBook Pros empty. Making use of it would allow users quick and easy access to commonly used functions without having to remember shortcuts.

I have created and attached a few mockups of what the Touch Bar interface could look like. If my proposal is approved of I'd be willing to implement it. All feedback is appreciated of course.

Locked Database

locked-default

locked-password-shown

While the database is locked, there are buttons to select a keyfile and toggle whether the password should be shown. The blue button to the right unlocks the database using the currently entered keyfile and password.

locked-choose-keyfile

Pressing the "Choose Keyfile…" button shows a list modal where the appropriate file can be quickly selected. The rightmost button allows loading a new file from the file system into the list.

locked-loaded-keyfile

If a keyfile has been selected, the button changes to "Deselect Keyfile". Pressing it will remove the keyfile from the selection and return the button to its previous functionality of choosing a keyfile.

Unlocked Database

unlocked-default

unlocked-entry-selected

In an unlocked database, the search function can be activated with the button to the left. The blue button's icon to the right now signifies locking the database. After an entry has been selected, buttons for editing it, copying username or password, and performing autotype become enabled.

unlocked-edit-item

Pressing the edit button brings up another modal dialog for adding an entry or group in the current context or deleting the currently selected item.

Most helpful comment

Okay, now I understand and I agree. I just looked at the Human Interface Guidelines again a bit more closely and noticed two things:

  1. The Touch Bar interface should resemble the physical keyboard, monochromatic colours are preferred. Especially buttons that are constantly visible shouldn't have distracting colours. Moreover, blue should be reserved for default controls. Looking at the other available buttons in this context, I don't think there is a clear default one. So I suggest simply removing the blue colour altogether.
  2. In your edited mockup, you moved the autotype button to the right. However, I think that the two copy buttons and the autotype button are closely related since they all relate to the username and password of a single entry and should be left together. On top of that, the guidelines say that the "left side of the app region works well for controls that persist across different modalities." Therefore, we should move the lock/unlock button to the very left.

Taking both of these points into account, the layout could look something like this:

locked

unlocked

What do you think?

All 9 comments

Should be implemented by someone with access to a TouchBar device. (as well as #514) but that's not me right now.

I do have a Touch Bar device, so I could implement it and create a pull request. I just wanted to give a heads-up before doing so to verify that people like the interface before actually implementing it.

The ideas look nice, but what I do not understand is the "edit" button. Why should you click on this? To move the focus to the input fields? To open the inspector if it's hidden?

The edit button lets you actually modify the database. It brings up the three buttons you can see in the last mockup at the bottom which basically have the same functionality as the three buttons to the left in the default toolbar.

So if an entry or a group in the database is selected, you can use the edit buttons to add an entry or group in the context of the currently selected group or delete the selected item with the third button.

I like the mockups very much and would like to suggest one change: on an unlocked database it seems reasonable to me to have _Perform Autotype_ as the highlighted option as this probably gets pressed more often than the lock database button.

1

@purejava Thanks, I'm glad that you like it.

I'm sorry, but I don't understand what exactly you mean with highlighted. All buttons on this level are of equal importance and can be accessed with one press since the Touch Bar is a touchscreen interface. This includes the autotype button.

The lock button is only blue because I chose to give it another colour as a bit of visual flair since it persists throughout all application contexts and represents the important state change of unlocking and locking the database.

@Novanoid With highlighted I mean the blue buttons and I know that you can use them all, no matter what color they are. I understand that you allways have the blue one for locking/unlocking the database.

But, I am under the impression that the blue button on the Touch Bar among the others is some sort of default or "pre selected button". When I select empty trash on the trash bin e.g., there are two buttons on the Touch Bar: _Empty trash_ (blue) and _Cancel_ (grey). So the blue button seems some sort of most common operation that is possible at the moment. Locking and unlocking, for me, is some sort of way off as a common operation and that is why I suggest _Perform Autotype_ instead.

Okay, now I understand and I agree. I just looked at the Human Interface Guidelines again a bit more closely and noticed two things:

  1. The Touch Bar interface should resemble the physical keyboard, monochromatic colours are preferred. Especially buttons that are constantly visible shouldn't have distracting colours. Moreover, blue should be reserved for default controls. Looking at the other available buttons in this context, I don't think there is a clear default one. So I suggest simply removing the blue colour altogether.
  2. In your edited mockup, you moved the autotype button to the right. However, I think that the two copy buttons and the autotype button are closely related since they all relate to the username and password of a single entry and should be left together. On top of that, the guidelines say that the "left side of the app region works well for controls that persist across different modalities." Therefore, we should move the lock/unlock button to the very left.

Taking both of these points into account, the layout could look something like this:

locked

unlocked

What do you think?

@Novanoid I agree to your arguments.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

magebarf picture magebarf  Â·  3Comments

uwqwxing886 picture uwqwxing886  Â·  5Comments

markushausammann picture markushausammann  Â·  3Comments

aliok picture aliok  Â·  7Comments

btxtiger picture btxtiger  Â·  7Comments