OK & CANCEL button placement

[cooperzoe]

In the newest version of OpenRefine, I notice the OK button is on the left hand side and the CANCEL button on the right in this window. I expected the OK button to be on the right hand side and found it's unusual placement counterintuitive.

I propose we either switch their placements, or put OK in the righthand corner and keep cancel next to it. If we choose the latter option, perhaps we could make the OK button blue, so they don't look too similar to one another.

[wetneb]

I would be in favor of agreeing one one convention and normalize all dialogs to follow that convention.

My vote goes to have both buttons on the right-hand side and the OK button to be marked as "primary" (meaning that its text will appear in bold).

[tfmorris]

I agree that the current placement is unusual. I think the application should follow the UI conventions of the underlying platform. They all have style guides and standard dialogs which implement those style guides (and perhaps they're all the same, but if not I think we should track the differences).

[tfmorris]

@areebqazi Thanks for you interest, but we still need to come up with a firm design for this before it's ready for work.

[tfmorris]

Although Jakob Nielsen says to follow platform conventions, except for web interfaces, I'd argue that we actually have enough information available about the user environment that we're closer to the platform case than the "web" case. He also has some input on button styling.

https://www.nngroup.com/articles/ok-cancel-or-cancel-ok/
https://www.lukew.com/ff/entry.asp?571
https://ux.stackexchange.com/questions/1072/ok-cancel-on-left-right

[vr-varad]

so are the changes required in the buttons??

[wetneb]

@tfmorris do you mean we should detect the operating system and adapt the button placement based on that?
I'd rather go with a uniform style regardless of the OS, for simplicity.

[tfmorris]

do you mean we should detect the operating system and adapt the button placement based on that?

Yes, I think that would give the best user experience.

I'd rather go with a uniform style regardless of the OS, for simplicity.

I understood that from your previous comment, but wasn't able to tell which style you were proposing. As I understand Zoe's proposal, she is proposing the Mac button ordering. Everyone agrees that all the buttons should go in the lower right corner, so, if using an order that the user expects is too complicated, we just need to choose between Windows (OK / Cancel) or Mac (Cancel / OK) ordering. Given that our Windows downloads are 2-3x the Mac downloads, I guess that means the default choice should be Windows.

[cooperzoe]

Hi everyone - apologies for the slow reply, I was out sick last week. Thank you for your input, @tfmorris @wetneb and everyone!

I've mocked up two options as @tfmorris has helpfully laid them out: one in Windows (OK / Cancel) ordering, and one in Mac (Cancel / OK) ordering. I hope the comparison is helpful to see:

[wetneb]

I'd propose to mark this as a good first issue, let's say with the Windows ordering ("OK" / "Cancel") for the sake of making a decision. The task would be to go through all dialogs and adjust them to this convention. It's a task that's a perhaps a bit harder than some other good first issues given that it will require a few more changes, but at least it should not require writing any test and is only requiring front-end changes.

[jquartel]

For what it's worth, I keep finding myself accidentally cancelling my custom facets, now, because I was used to 'OK' being on the right, so I'm in favour of moving 'OK' back to that region. I'm a Mac user and I didn't mind the OK/Cancel ordering we had before.

[zyadtaha]

Hi @wetneb,
I searched about this attribute bind="okButton" but it seems to be a custom attribute.
If I am right, can you tell me what it refers to ?

[tfmorris]

I was used to 'OK' being on the right, so I'm in favour of moving 'OK' back to that region.

I thought the current design was odd, but until @jquartel mentioned it, I didn't consciously realize it had been changed.

It looks like at least part of the problem is the styling is defined in multiple places, probably unintentionally. When I look in my browser, I see that .dialog-footer is being defined in dialog.css, which I'd expect, but also recon-dialog.css (from f856713) and column-join.css (27d5fb8) which are likely unintentional and which are overriding the base definition.

I think removing this override will fix the problem (or at least restore the previous appearance):

OpenRefine/main/webapp/modules/core/styles/reconciliation/recon-dialog.css

Lines 105 to 108 in f856713

	.dialog-footer {
	display: flex;
	justify-content: space-between;
	}

It looks like the problem was introduced just a few months ago, so the 3.8 beta is the only release it appears in.

[zyadtaha]

Awesome! so we just need to remove this line justify-content: space-between;.
but how to add the style="font-weight: bold;" to the Ok Button ?
Should I put the style in every button tag in HTML or just add a class attribute to all ok buttons and make css to the class ?

[zyadtaha]

@wetneb Could you assign this to me ?

[wetneb]

I'm adding this commit to the 3.8 branch as @tfmorris mentioned that the problem was recent, hence worth fixing before the next stable release.

[tfmorris]

@wetneb These changes

OpenRefine/main/webapp/modules/core/styles/reconciliation/recon-dialog.css

Lines 105 to 117 in f856713

	.dialog-footer {
	display: flex;
	justify-content: space-between;
	}
	.button-left {
	display: flex;
	}
	.button-right {
	display: flex;
	gap: 10px;
	}

from f856713 should probably be reviewed for removal as well. The CSS for the recon dialog shouldn't be messing with common styles.