This is a migrated thread and some comments may be shown as answers.

Confirm dialog compatibility issue

19 Answers 453 Views

Window

This is a migrated thread and some comments may be shown as answers.

19 Answers, 1 is accepted

answered on 12 Nov 2009, 11:51 AM

Hi eyal,

There have been a long-standing discusses about these buttons. In particular - Positioning, Labeling and Visual Distinction. All these three subjects are closely related to the type of OS, the type of application /web or desktop/ and the specific scenario. The aim of these discussions was to see how we could make forms more usable & intuitive. And one of the items being discussed was the visual distinction of "OK" and "Cancel".

There are several reasons why we decided to change the look of "Cancel" button in the RadConfirm dialog.

First of all we wanted to visually distinguish the actions making it easier for the user to pick the right one.

Luke Wroblewski writes about this in his article Web Application Form Design.

He states that making the Primary action stand out more than the Secondary action is a good thing. In the findings of the usability test, he finds that it takes the user a little more time to complete the form if the Primary and Secondary action has a different design. But on the other hand it makes the user more confident and less prone to choose the wrong one. He suggest making the buttons in different colors or making the Secondary action a plain link.

Robert Hoekman, jr. recommends using a plain link for the Secondary action. His arguments for this is that it makes it clear which one is the most prominent.

In conducted tests it was found that users sometimes get confused by link, which acts as a button. We think that this might be because of never having encountered it in a form before. But as this practice gets more common in both web and windows applications, this should not be a persistent problem.

And as mentioning web and windows applications, we decided to keep the Button look of the "Cancel" for our "desktop" -like skins, namely - Vista, Office2007 and Outlook.

We are glad that you noticed this change. It is very important for us to know what you think on such, at first glance negligible topics. Your opinion is vital in the process of delivering the best possible solutions.

Best wishes,

Vasil Yordanov, UX Team
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

answered on 12 Nov 2009, 01:21 PM

Thank you Vasil for the academic-like answer.

It is indeed a long standing discussion, which definitely not going to end or be solved in this forum (just try to google buttons vs links...).

For me, the link seems strange for the same reason you mentioned - it is not too common to see such a UI on the web. In my opinion, the buttons can be differentiated for ex. by color or size. Links are more associated with navigation. And maintaining the "desktop" -like skins with the button look may confuse the developers as well as the end-users (inconsistency). After all, it is still the web and it's going to be much more of it. But let's see what other opinions come to this post.

eyal

ps. The hyperlink manager and format code block on the editor in the forums has the same issue - cancel button is a link but in this case does not have any indication while hovering (might be a minor UI issue).

answered on 13 Nov 2009, 07:59 AM

Let's add another dimension to the discussion. It is called aesthetics, which is known to have influence on people and their choices. Thus, aesthetics go hand-in-hand with usability, or the perceived usability (for more on this relation google usability aesthetics).
So which version is more aesthetically pleasing? and does the aesthetic difference can be a factor that counts in this specific case?

Briefly on labeling. The OK/Cancel labeling is probably originated from the binary way of thinking of computer scientists and the ability to conveniently format almost any question into a Yes/No question. Saves time for developers, but definitely not the way of thinking for most end-users. In the example I attached above, the confirm dialog simply presents a delete confirmation. From the end-user point of view, it would be more logical to label the OK as "Delete". Would it be possible to set the buttons' labeling in each specific radconfirm dialog?

eyal

answered on 26 Nov 2009, 07:18 AM

Hello Theo,

Yes, this is possible by modifying the confirm template in the RadWindowManager declaration. Just remove the rwCancel class from the template and you will get the old look of the dialog.
e.g.

<telerik:RadWindowManager ID="RadWindowManager1" runat="server" >

<ConfirmTemplate>

<div class="rwDialogPopup radconfirm">

<div class="rwDialogText">

{1}

</div>

<div>

<a onclick="$find('{0}').close(true);" class="rwPopupButton" href="javascript:void(0);" ><span class="rwOuterSpan"><span class="rwInnerSpan">##LOC[OK]##</span></span></a>

<a onclick="$find('{0}').close(false);" class="rwPopupButton rwCancel" href="javascript:void(0);"><span class="rwOuterSpan"><span class="rwInnerSpan">##LOC[Cancel]##</span></span></a>

</div>

</ConfirmTemplate>

</telerik:RadWindowManager>

All the best,
Georgi Tunev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

answered on 26 Nov 2009, 08:36 AM

Hi eyal,

I definitely agree that aesthetics is vital too, and in this case we may agree that it is more important than usability. So, we are considering this as an issue which should be solved for the service pack.

According to labeling buttons in specific scenarios, we may not fully support such feature for now due to localization and scenario diversities. However you can replace the "OK" label with "Delete" by changing the dialog templates.

E.g. you just have to replace "##LOC[OK]##" with "Delete":

<telerik:RadWindowManager ID="RadWindowManager1" runat="server" >

<ConfirmTemplate>

<div class="rwDialogPopup radconfirm">

<div class="rwDialogText">

{1}

</div>

<div>

<a onclick="$find('{0}').close(true);" class="rwPopupButton" href="javascript:void(0);" ><span class="rwOuterSpan"><span class="rwInnerSpan">##LOC[OK]##</span></span></a>

<a onclick="$find('{0}').close(false);" class="rwPopupButton rwCancel" href="javascript:void(0);"><span class="rwOuterSpan"><span class="rwInnerSpan">##LOC[Cancel]##</span></span></a>

</div>

</ConfirmTemplate>

</telerik:RadWindowManager>

For more information you can take a look at this help article:

http://www.telerik.com/help/aspnet-ajax/window_dialogschangingthedialogtemplates.html

Regards,
Vasil Yordanov, UX Team
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

answered on 26 Nov 2009, 01:11 PM

Thank you Vasil.

I am aware of the possibility to modify the dialog templates. However, as I wrote in the Editor forum about customizing dialogs, it is not my preferred method due to the over-maintenance work that it may cause.

The current confirm dialog syntax is:
radconfirm(text, callBackFn, oWidth, oHeight, callerObj, oTitle)
What issues can be caused by localization or scenario diversities if the syntax would be:
radconfirm(text, callBackFn, oWidth, oHeight, callerObj, oTitle, [oOKButtonLabel, oCancelButtonLabel])

It's only text labels. And if it throws an error, you set the OK-Cancel as default.

br,
eyal

answered on 26 Nov 2009, 02:09 PM

Hi eyal,

One of the problems that we should consider in such implementation is the case where the users puts some really long string as localization text - for example. "Yes, update the database now". Such text would not fit the size of the button and implementing a logic that would either change the size of the button or would truncate / replace the text would decrease the performance.

Since the current localization of the control is done on the client, I would suggest another approach - to change the localization strings right before calling the confirm dialog and then to reset them so you can use the standard strings in other functions on the same page.
e.g.

<telerik:RadWindowManager ID="RadWindowManager1" runat="server">

</telerik:RadWindowManager>

<asp:Button ID="Button1" runat="server" Text="Delete" OnClientClick="confirmDelete();return false;" />

<asp:Button ID="Button2" runat="server" Text="Upload" OnClientClick="confirmUpload();return false;" />

<script type="text/javascript">

function confirmDelete()

{

//change the localization

Telerik.Web.UI.RadWindowUtils.Localization["OK"] = "Delete";

//call the confirmation

radconfirm("are you sure you want to delete that item?", callbackFn);

//reset the localization string

Telerik.Web.UI.RadWindowUtils.Localization["OK"] = "OK";

}

function callbackFn(arg)

{

alert(arg);

}

function confirmUpload()

{

radconfirm("are you sure you want to upload that item?", callbackFn);

}

</script>

The localization strings are available in this KB article.

All the best,
Georgi Tunev
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

answered on 26 Nov 2009, 02:45 PM

Thank you Georgi for the quick reply!

Great! Your approach is almost similar to what I suggested. Thanks a lot.

Regarding localization and very long strings, rest assured that I have experience with this. Most of our applications use the Finnish local, a language known by its tendency for long strings :)

However, if we take for instance the LinkManager dialog of the editor, the labels for the hyperlink properties are also limited by its width. But they can still be localized. In case the localized text is too long, it is cropped (and yes, it did happen with our Finnish localization). Thus, the developer (or linguistic expert) is responsible to find suitable and meaningful text for each scenario.

br,
eyal

answered on 02 Dec 2009, 07:38 AM

Hi Telerik Team,

I may be late to this Forum topic but I would like to share my opinion of user experience for both product upgrades and development process and practices.

First of all, I'm sure many of us will be shocked by such changes to the "Cancel" button being displayed as hyperlink. I'm using this for all my projects and now I have to consider revert back to standard browser confirm box for the following reasons:

a) No maintenance required to existing and future projects/applications after upgrades.

b) Ensuring the UI consistency across existing and future projects/applications after upgrades.

In future, it will be great if you can share with us (Telerik subscription users) via email of all the "special" feature items during Beta version so that we can be prepared for such changes before upgrade. This will definitely helps and provides us sufficient time (for internal discussion of the product UI changed) dealing with our end-users/customers and whether or not to get this upgraded if the impact is big or go for alternative solution.

I have a suggestion where you should keep the current RadConfirm remain as before and make it as default behaviour. You can create new property to have a list of special UI so that we can always have the options and will not impact existing behaviour.

Is there a plan to revert the RadConfirm behave as before?

One more thing, I tested the same on your Demo (http://demos.telerik.com/aspnet-ajax/window/examples/browserdialogboxes/defaultcs.aspx) and it seems showing the old version Radconfirm? Does all the demos get updated with latest release together with Help file?

Please advise?

Thanks

answered on 09 Dec 2009, 09:38 AM

Hello,

I just realized that this cancel button style was not the result of some bug in our application.

I request you get back to the previous behaviour without having to change my code !!!

LET ME INSIST AS MANY OTHERS THAT SUCH CHANGES COULD NOT BE DECIDED IN THE CORNER OF A HIDDEN FORUM THREAD !!!!

When you do such a change you must proceed just as it has been done with previous breaking look&Feel changes: maintain the old way and allow path to change for new.
This could be done easilly with a property flag in radWindows (see FormDecorator with is default rendering feature).*

I have end-users on my application, and they don't appreciate these changes, your are breaking my business !

We have already suffered from the massive skin design change in 2008, please stop this way behaving, I appreciate your work and company, forum are a great tool to help BUT they should not be a source for such decision: USERS ARE NOT ON YOUR FORUMS, IT IS ONLY TECH PEOPLE LIKE ME, NOT THE END USERS !!! AND THEY DON'T APPRECIATE TECH GUYS DECIDE CHANGING THEIR TOOLS ! THEY DON'T LIKE THIS KING OF MAGIC !

Telerik should take care to such changes now that your propose a free CDN usage: this is a great idea but it would not support changes decided in a dark lost forum thread.

Hope my request will find its way out of forum to reach Telerik marketing.

Best regards

CS

Product Bundles

DevCraft

Web

Mobile

Document Management

Desktop

Reporting & Mocking

Automated Testing

CMS

UI/UX Tools

Debugging

Free Tools

Support and Learning

Productivity and Design Tools

Confirm dialog compatibility issue

19 Answers, 1 is accepted