OK & CANCEL button placement about openrefine HOT 14 OPEN

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.

from openrefine.

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:

from openrefine.

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).

from openrefine.

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

from openrefine.

@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.

from openrefine.

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).

from openrefine.

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

from openrefine.

so are the changes required in the buttons??

from openrefine.

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.

from openrefine.

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.

from openrefine.

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 ?

from openrefine.

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):

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

from openrefine.

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 ?

from openrefine.

@wetneb Could you assign this to me ?

from openrefine.