Home / Community & Support / Developer Productivity Tools Forums / ASP.NET AJAX > Window > Confirm dialog compatibility issue

• eyal

  Posted on Nov 12, 2009 (permalink)

  Hi,
  
  Attached is a screenshot of a confirm dialog in Q2 and Q3. The style for the cancel button is missing?
  
  eyal

  Attached files

  • confirm-dialog.jpg

  Reply

• Vasil Yordanov Vasil Yordanov

  Posted on Nov 12, 2009 (permalink)

  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.

  Reply


• eyal

  Posted on Nov 12, 2009 (permalink)

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

  Reply

• TCF Schepers

  Posted on Nov 12, 2009 (permalink)

  Well Eyal,
  
  I couldn't agree with you more. I just posted this very same thing as a support ticket. Our are also used to the rich UI look and feel of the RadControls. Also, 'cancel' could and should not be categorised as a link; It just means you want to cancel the current action and return to the parent page.
  
  Regards,
  
  Thomas Schepers

  Reply

• eyal

  Posted on Nov 13, 2009 (permalink)

  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
  
  

  Reply

• Theodora

  Posted on Nov 16, 2009 (permalink)

  Philosophical discussions aside, are there any provisions in the current release or workarounds for overriding the style applied to the Cancel button?
  
  Many thanks,
  Theo.
  

  Reply

• Georgi Tunev Georgi Tunev

  Posted on Nov 26, 2009 (permalink)

  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>

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

  Reply

• Vasil Yordanov Vasil Yordanov

  Posted on Nov 26, 2009 (permalink)

  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>

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

  Reply

• eyal

  Posted on Nov 26, 2009 (permalink)

  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
  

  Reply

• Georgi Tunev Georgi Tunev

  Posted on Nov 26, 2009 (permalink)

  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.

  Reply

• eyal

  Posted on Nov 26, 2009 (permalink)

  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
  

  Reply

• Georgi Tunev Georgi Tunev

  Posted on Nov 27, 2009 (permalink)

  OK eyal,
  
  Your suggestion sounds good and I logged it in our database for future consideration. Your points were updated as well.
  
  
  
  Kind regards,
  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.

  Reply

• Theodora

  Posted on Nov 27, 2009 (permalink)

  Thank you Georgi. This is very helpful.
  
  Theo.
  

  Reply

• Lek Wah Chew

  Posted on Dec 2, 2009 (permalink)

  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

  PS

    

  Reply

• Georgi Tunev Georgi Tunev

  Posted on Dec 2, 2009 (permalink)

  Hello Lek,
  
  Thank you for your feedback - we highly appreciate it.
  As for your questions, as already noted in this thread, we kept the old look for Windows-like skins (Vista, Office2007 and Outlook) and we will bring back the old style for the other skins for the service pack that will appear next week.
  
  
  Kind regards,
  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.

  Reply

• Lek Wah Chew

  Posted on Dec 2, 2009 (permalink)

  Thanks Georgi for your reply and great to hear that you are bringing back the old design.

  
  

  One important thing is why this change was not in the "What's new in this version?" list? This is very important list and will first gets reviewed before upgrade. Or am I missing any statement in the list?

  
  

  I believe it's important to get this "What's new in this version?" list reflected with latest change for our reference.  

  
  

  Thanks,

  PS
  

   
  

  Reply

• Georgi Tunev Georgi Tunev

  Posted on Dec 2, 2009 (permalink)

  Hi Lek,
  
  Yes, you are absolutely right - this information should have been added to the "Changes" section. We sincerely apologize for the omission.
  
  
  Greetings,
  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.

  Reply

• Christian Surieux Master

  Posted on Dec 9, 2009 (permalink)

  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

  Reply

• Georgi Tunev Georgi Tunev

  Posted on Dec 9, 2009 (permalink)

  Hello Christian,
  
  Yesterday we released Q3 2009 SP1 where the dialogs have the old look (pre-Q3 2009).
  
  
  
  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.

  Reply

• Christian Surieux Master

  Posted on Dec 9, 2009 (permalink)

  Thank you Georgi and team.
  CS

  Reply

Back to Top

Home / Community & Support / Developer Productivity Tools Forums / ASP.NET AJAX > Window > Confirm dialog compatibility issue