Entry field button improvements

[ldexterldesign]

Hi!

Thanks for software, as always

As a user, when I use entry field buttons (e.g. reveal/hide, copy, history), I want closer proximity position to field values so I don't have to cursor travel huge distances for the interaction

Screenshot:

Correct me if I'm wrong but button group position was beside field values (i.e. to right) until a few versions ago?:

• If true then what was the design thinking for changing it
• If false then ignore me, I'm imagining it

I understand button group position consistency is important across entries (i.e. different value lengths will yield different rags) but I think we need to prioritise feature proximity in the UI over consistency here

IMO button group position below each value would be a better position, we get:

• position consistency
• close value proximity
• scalable (get the whole row length to add new buttons)
• sacrifice vertical real estate not horizontal (I have a huge amount of vertical whitespace in each entry)
• only con is we're going to mess up visual hierarchy as button group is going to compete with label/value - if you're interested then I have a possible solution

If you're reading and:

• agree, then please vote up (e.g. +1, like), or;
• disagree, then please vote down (e.g. -1, dislike) - I'd love to know why?

Welcome feedback/input

Hope this helps and to hear back

Sincerely

hardware: Apple, MacBook Pro (16-inch, 2019) software - OS: Apple, macOS, 11.3.1 (20E241) software - application: Buttercup, Desktop @ v2.5.2 / Core @ v5.13.1 / Flags: installed

[julianpoemp]

Because these buttons are only visible on mouse over, I suggest the buttons to be moved to a popover box that is close to the cursor's position when the mouse is moving over one of the lines. With that solution users can click on one of the buttons as fast as possible and the UI is still clean as before.

[perry-mitchell]

Correct me if I'm wrong but button group position was beside field values (i.e. to right) until a few versions ago?

We had it requested to have them aligned vertically.. And this is the result.

I think it needs an overhaul but I haven't yet found an arrangement I'm happy with.

button group position below each value would be a better position

This would increase the height of everything which would also look janky in my opinion. I do agree with the proximity argument, but this is maybe not the best way to go.

only con is we're going to mess up visual hierarchy as button group is going to compete with label/value - if you're interested then I have a possible solution

What do you propose?

moved to a popover box that is close to the cursor's position when the mouse is moving over one of the lines

@julianpoemp I like this idea a lot.. Though it would make keyboard use (if we ever have it so that tabbing between UI elements is a first-party feature) very impractical.

[ldexterldesign]

What do you propose?

Increase the font size of the fields and put the interaction additions below

This way you'll manage visual hierarchy and uphold Fitts's law

If you must keep the progressive disclosure on hover (personally I think it's too much here, perhaps offer a setting?) then you'll no longer have this problem:

Hope it helps

[ldexterldesign]

An eloquent enhancement/solution may simply be to keep the interaction additions (IA) around a few seconds after the cursor/keyboard hovers/focuses away from fields (i.e. animation)?

This is a no brainer as things stand IMO and may be enough to solve this issue for me; striking a nice balance between the progressive disclosure and targeting of IAs

[ldexterldesign]

Aside, I think the Edit & Save/Cancel buttons also need the same proximity consideration - their placement is weird

Think about a web form, the Submit button is at the end of the form not fixed to the bottom of the web page. My sense is that these buttons are chunked with the more global actions (e.g. New Entry) for some arbitrary reason.

I would also argue the New Entry button's placement is odd too - we don't create a new group this way:

[ldexterldesign]

Apple Mail, create a new email, observe location/placement is very contextual:

[ldexterldesign]

Right, that's it for now - clearly I've had way too much coffee!

[perry-mitchell]

Haha.

Well I agree regarding the location of the New Entry vs New Group buttons/controls.. that makes sense. Not sure what's to be done there just yet - I like the size of the new entry button and it'd be harder to see in the same location as new groups. But then again the new group button is hard to see by comparison.

Increase the font size of the fields and put the interaction additions below

What do you mean by "interaction additions"? The "reveal" and field type buttons?

These are more tricky.. They're relative to the field they're aligned with, and I think it makes sense to keep them horizontally aligned.. Placing them below the field will look less thought-through imo. This change might need more thought in terms of options.

Maybe removing them entirely is a good ideal to aim for - copy could be simply clicking the field, reveal might have to be something else. 🤔

[ldexterldesign]

Well I agree regarding the location of the New Entry vs New Group buttons/controls.. that makes sense. Not sure what's to be done there just yet - I like the size of the new entry button and it'd be harder to see in the same location as new groups. But then again the new group button is hard to see by comparison.

My initial thought is move the Trash button into the Group (entries?) list - just make it distinct from the other list entries somehow; probably locate at the bottom of the list

Then we free up the Trash button space for a "New Group" button and have interaction consistency with "New Entry"

This goes against what I said before but divide and conquer hey:

I would also argue the New Entry button's placement is odd too - we don't create a new group this way

[ldexterldesign]

What do you mean by "interaction additions"? The "reveal" and field type buttons?

Yes, copy/reveal/history

These are more tricky.. They're relative to the field they're aligned with, and I think it makes sense to keep them horizontally aligned.. Placing them below the field will look less thought-through imo. This change might need more thought in terms of options.

I don't disagree, inline is ideal

Good readability is typically 50-70 character line length so I would use this as a start point to locate interaction additions (IA) rather than how they are currently located (i.e. far off to right)

My next thought is simply remember custom Group/Document/Entry column widths as a savvy user can solve this issue by reducing the entry column width but it's not an obvious solution for users:

Maybe removing them entirely is a good ideal to aim for - copy could be simply clicking the field, reveal might have to be something else. 🤔

I like this idea, but a bold move

Click to copy is how mobile app works and I like that

😆 https://github.com/buttercup/ui/issues/19

I rarely use reveal but when I do I would prefer it as a global option because I'm usually clicking in and out of various entries but I totally get the security/privacy implications of not having reveal a global setting

If all IA are removed then history is tricky to manage. Perhaps show the change history of a whole entry instead of each field - that would be more useful IMO as user gets change context relative to all fields not just one field. This change list could make use of the whitespace at the bottom of (most) entries and be toggle-able (i.e. show/hide)..?

[perry-mitchell]

Then we free up the Trash button space for a "New Group" button and have interaction consistency with "New Entry"

I really like this idea!

I rarely use reveal but when I do I would prefer it as a global option

I also like this idea, and it'd also match mobile in terms of behaviour. There's the case as you mentioned that someone doesn't want everything revealed, but I think if they're comfortable revealing one secret item they're comfortable revealing all, for a short time.

Perhaps show the change history of a whole entry instead of each field

Also a good idea. This would help promote the feature as well.

[ldexterldesign]

Oh god, not me again

Same issue here

To edit something mouse travel is insanely inefficient 😔

If you agree then happy to discuss a solution..?

Sincerely

[julianpoemp]

I was about to write something ironical like "What about making the window smaller?" But I think this is a good meme and I created one 😆 :

[ldexterldesign]

@julianpoemp

I'm aware:

My next thought is simply remember custom Group/Document/Entry column widths as a savvy user can solve this issue by reducing the entry column width but it's not an obvious solution for users

IMO users shouldn't have to mess around resizing windows and columns - how often do you resize a browser window to make the UI usable?

Disclaimer, I often have to do this to make line lengths readable - it's bad UX

[julianpoemp]

@ldexterldesign I understand your point. My previous post was just a joke ;)

[ldexterldesign]

😭

Anyone else agree this could be better: if yes then I'm sure some CSS flex love would fix this rag nightmare..?

Happy to move this comment to a new issue and attempt a PR but I think it's relevant to this issue's general UI layout conversation

Hope to hear back

Sincerely