Comments (16)
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.
@wetneb These changes
OpenRefine/main/webapp/modules/core/styles/reconciliation/recon-dialog.css
Lines 105 to 117 in f856713
from f856713 should probably be reviewed for removal as well. The CSS for the recon dialog shouldn't be messing with common styles.
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):
OpenRefine/main/webapp/modules/core/styles/reconciliation/recon-dialog.css
Lines 105 to 108 in f856713
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.
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.
from openrefine.
Related Issues (20)
- Add new GREL function to calculate the edit distance HOT 3
- Checking running status of OpenRefine with wget will not work correctly
- Move the Wikitable importer to an extension HOT 1
- Don't catch exceptions in Java unit tests
- Allow user to automatically report their OpenRefine installation configuration
- Incorrect localization for row/record count in main summary bar
- Restore deleted constructor to StandardReconConfig
- Import progress bar exceeds the intended box HOT 1
- Fail to open the browser after startup on linux without Desktop.browse support
- Update the UI for the starred tab in expression dialogue HOT 5
- Column menus: select submenu item by moving mouse diagonally
- When checking for a running open refine localhost should be included in the no proxy list
- Trying to load a 3.4.1 (or 3.6?) project using OpenRefine v3.8.1 HOT 1
- Introduce new top level GREL variable `record` HOT 2
- Fix OSSRH upload in release pipeline HOT 6
- join() of array with nulls throws NullPointerException HOT 4
- toTitleCase() second argument (delimiters) undocumented HOT 1
- Permanent logging to file HOT 1
- Carriage Return added to cell value incorrectly during import
- Null values in rows are not parsed correctly during import preview
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openrefine.