Ticket #4750 (closed Bug: fixed)

Opened 5 years ago

Last modified 4 years ago

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

Reported by: alfonsoml Owned by: alfonsoml
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

4750.patch (587 bytes) - added by alfonsoml 5 years ago.
Proposed patch
2010-03-23-110801_488x256_scrot.png (25.4 KB) - added by tobiasz.cudnik 4 years ago.
KDE 4.4 using QT4, Fedora 11
2010-03-24-142417_440x215_scrot.png (14.8 KB) - added by tobiasz.cudnik 4 years ago.
Recent GTK

Change History

Changed 5 years ago by alfonsoml

Proposed patch

comment:1 Changed 5 years ago by alfonsoml

  • Status changed from new to assigned
  • Keywords Review? added; HasPatch removed
  • Owner set to alfonsoml

comment:2 Changed 5 years ago by fredck

  • Milestone set to CKEditor 3.3

comment:3 Changed 4 years ago by matti

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 4 years ago by alfonsoml

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 4 years ago by garry.yao

  • Keywords Review- added; Review? removed
  • Component changed from UI : Dialogs to Accessibility

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 4 years ago by garry.yao

  • Cc tobiasz.cudnik added

comment:7 Changed 4 years ago by alfonsoml

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 4 years ago by garry.yao

  • Keywords Review+ added; Review- removed

Let's open new ticket for Linux when necessary.

comment:9 follow-up: ↓ 10 Changed 4 years ago by matti

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 4 years ago by alfonsoml

  • Status changed from assigned to closed
  • Resolution set to fixed

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 4 years ago by matti

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 4 years ago by tobiasz.cudnik

KDE 4.4 using QT4, Fedora 11

Changed 4 years ago by tobiasz.cudnik

Recent GTK

comment:12 Changed 4 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 4 years ago by zahreddin

  • Version changed from 3.0.1 to 3.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 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy