Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#4750 closed Bug (fixed)

OK & Cancel buttons in dialog doesn't follow the OS guidelines

Reported by: Alfonso Martínez de Lizarrondo Owned by: Alfonso Martínez de Lizarrondo
Priority: Normal Milestone: CKEditor 3.3
Component: Accessibility Version: 3.4.1
Keywords: Review+ Cc: Tobiasz Cudnik

Description

I don't know the order in Linux, but in Windows the order of buttons is OK - Cancel, like CKEditor does right now, but in Mac it's the revere: Cancel - OK

This is defined in the defaultDialogDefinition private object of the dialog plugin, but it's impossible to change it from a plugin, just changing the definition to

	var defaultDialogDefinition =
	{
		resizable : CKEDITOR.DIALOG_RESIZE_NONE,
		minWidth : 600,
		minHeight : 400,
		buttons : CKEDITOR.env.mac ? [ CKEDITOR.dialog.cancelButton, CKEDITOR.dialog.okButton ] : [ CKEDITOR.dialog.okButton, CKEDITOR.dialog.cancelButton ]
	};

is enough.

Attachments (3)

4750.patch (587 bytes) - added by Alfonso Martínez de Lizarrondo 8 years ago.
Proposed patch
2010-03-23-110801_488x256_scrot.png (25.4 KB) - added by Tobiasz Cudnik 8 years ago.
KDE 4.4 using QT4, Fedora 11
2010-03-24-142417_440x215_scrot.png (14.8 KB) - added by Tobiasz Cudnik 8 years ago.
Recent GTK

Download all attachments as: .zip

Change History (16)

Changed 8 years ago by Alfonso Martínez de Lizarrondo

Attachment: 4750.patch added

Proposed patch

comment:1 Changed 8 years ago by Alfonso Martínez de Lizarrondo

Keywords: Review? added; HasPatch removed
Owner: set to Alfonso Martínez de Lizarrondo
Status: newassigned

comment:2 Changed 8 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.3

comment:3 Changed 8 years ago by Matti Järvinen

Can this be made so that custom plugins would honor OS default order too or should this be mentioned in API documentation? Should we decide one order over another based on OS market share?

Worst case scenario being that user plugins and core plugins have mixed order in Ok/Cancel buttons.

comment:4 Changed 8 years ago by Alfonso Martínez de Lizarrondo

Custom plugins inherit the default configuration, so this should work automatically for them. After all, this is doing a single change for the defaultDialogDefinition object, not a change in the dialog of every plugin.

comment:5 Changed 8 years ago by Garry Yao

Component: UI : DialogsAccessibility
Keywords: Review- added; Review? removed

Identify this as an usability issue.
If you can confirm the tab order should also be reversed I'm ok with the current patch, otherwise we should go with the layout change only.
I could confirm that GNOME has also the problem while I'm not sure if we can perform detection there. (Am I wrong Tobias?)

comment:6 Changed 8 years ago by Garry Yao

Cc: Tobiasz Cudnik added

comment:7 Changed 8 years ago by Alfonso Martínez de Lizarrondo

I've tested the "save page" dialog and tabbing it focus first the Cancel and then OK, so the order is correct.

The only question then is if we must add detection for Linux or there might be other environments like KDE where the order matches windows.

comment:8 Changed 8 years ago by Garry Yao

Keywords: Review+ added; Review- removed

Let's open new ticket for Linux when necessary.

comment:9 Changed 8 years ago by Matti Järvinen

Obligatory quote from J. Nielsen

"Do what the platform owner tells you to do."...

"If you're designing a Web-based application, the decision is harder, but you should probably go with the platform preferred by most of your users."

So if we can make it so that Win gets Ok/Cancel, Save/Cancel, Apply/Cancel and Mac gets other way around and everything else gets Win style it's good enough.

Could there be an utility function for button order so you could handle all variations easily (rare but not non-existent)? (Save as New/Save/Cancel)

comment:10 in reply to:  9 Changed 8 years ago by Alfonso Martínez de Lizarrondo

Resolution: fixed
Status: assignedclosed

Fixed with [5215]

Replying to matti:

Obligatory quote from J. Nielsen

"Do what the platform owner tells you to do."...

Yes, this is what this bug is about. No one is stating anything else.

So if we can make it so that Win gets Ok/Cancel, Save/Cancel, Apply/Cancel and Mac gets other way around and everything else gets Win style it's good enough.

So Linux users doesn't matter?

Could there be an utility function for button order so you could handle all variations easily (rare but not non-existent)? (Save as New/Save/Cancel)

In your custom plugin you can handle the order of the buttons in anyway you like, this is an adjustment for the provided buttons.

comment:11 Changed 8 years ago by Matti Järvinen

All I'm saying is that I'm worried that without proper documentation (or utility functions for sorting ok, cancel equivalents on basis of OS) on this matter users will end up doing plugins that are not following example set by above ternary operator buried in somewhere within CKEditor/_source.

This is mainly documentation issue and should be covered also with examples in CKEditor API documentation.

Changed 8 years ago by Tobiasz Cudnik

KDE 4.4 using QT4, Fedora 11

Changed 8 years ago by Tobiasz Cudnik

Recent GTK

comment:12 Changed 8 years ago by Tobiasz Cudnik

For the reference i've attached GNOME and KDE examples, which has opposite button positions. I think we can't provide any OS-specific ordering for linux because of this reason.

What could be done is to provide ordering based on the browser used by the user. Then Opera would have QT ordering, Firefox and Chrome GTK ones.

comment:13 Changed 7 years ago by Thomas Zahreddin

Version: 3.0.13.4.1

I can't see how this issue is fixed.

Best solution i.m.h.o. is to check the OS and decide the order of these two buttons on the OS.

Other solution: edit the source code to change it for every website… but then it will be a usability issue at least for some users.

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy