Guidance on embracing Metro Touch

[Tomica]

I am looking for guidance on how best to take an existing web app which is heavily-invested in RAD Ajax controls and transforming it to use the new Metro Touch skin.
I see that page layout will be affected because the touch components need to be larger (finger vs mouse pointer).

I also see that our reliance on Tooltip functionality might be complicated because there is no "hover" event that I know about. Although new to tablets, I do know that there are distinctions between taps, presses and "long presses" (press and hold).

It would be helpful for Telerik to provide some type of conversion or best-practices advice as the touch skins are evolved.

Please note that in our case, Kendo is not an option, nor are we creating native apps, rather a "standard" web-site that works reasonably well for touch users, while maintaining full capability for mouse/keyboard.

[Bozhidar]

Hello,

Thanks for your question. I was thinking also about what are the best practices, but actually I don`t think there are any...or much of them. In fact, the page with a normal or MetroTouch skin is one and the same, and as you note, the only difference is the element sizes. In such case, there isn`t a magic tool that could fix all the sizes and to rebuild the existing layout in order to fit the new sizes. In that case, I think everything should be done by hand and where the wrapper content is critical to find a way go apply different width in order to catch all the MetroTouch elements.

Each layout is specific and could not be geiven an universal tool or method how it should be turned to cover the MetroTouch requirements. If your container are fluid width, then the issue will be solved, but most layout are without fluid dimensions and if it`s specific for the default skin, it will be broken with MetroTouch.

Another option is to load for the desktop and laptop devices a normal skin - let`s say Metro, whlle for mobile devices to detect it and to load MetroTouch. This will ensure that the webiste will not be broken on the desktop machines and meanwhile you will have enough time to create and new layout stylesheet that will be loaded with MetroTouch, that will be improved for its dimensions.

Greetings,
Bozhidar
the Telerik team

[Tomica]

I understand, and realize there would never be any magic bullet solution to resize the layout effectively.

Since your reply indicates there is no intentional difference in behavior of the ASP.NET Ajax contols, I think the technical issues I am encountering are more likely internal to my code or incompatibilities with various tablet browsers.

For example, I have a regular drop-down menu which works fine in PC browsers and equally well on an iPad2, but on an Android ICS tablet, it drops, but then appears to hang, and then disappears.

If you are quick enough to tap on a menu item, nothing happens. If you repeat this a few times, the browser crashes.

I don't think a bug report is warranted at this time, since that application is using an Office2010 skin.

I have created test page with Metro Touch and I cannot duplicate the problem. But this is a far simpler page, so I have no conclusions yet.

So, one theory is that the "touch" skins also vary in behavior based on the underlying hardware, and traditional skins may not work in every scenario, and that's fine with me, as I don't think it is possible to build one solution that works everywhere.

[Bozhidar]

Hi,

In "theory", as you said, there shouldn't have any difference in the behavior of MetroTouch and all other predefined skin. The only difference is the visual part of the elements to bi bigger and appropriate for Touch devices. Actually in our predefined skins, we have a few more, that have some dimensions differences  - Sitefinity, Simpkle and Metro skins, and actually we have the same thing with MetroTouch skin, but all elements are much bigger, so if you have any issues with Office2010 skins, the same issues should be reproducible with MetroTouch also.

Probably you could use MetroTouch for both standard and mobile platforms and using CSS to adapt it looks well everywhere, but as you mentioned, it is hard to build a solution that works everywhere, but if you think you found and issue, nevertheless if it is for Android or Another OS and we will try to do our best to fix it.

All the best,
Bozhidar
the Telerik team

[Orin Book]

We are doing the exact same design considerations as you. I can give some lessons learned on web, tablet and phone using same telerik controls and code. 1. Standardize how your controls work. In aspx, place control with no options. on code from behind register the control with a core piece of code that sets all options for the control. We have an extensive ERP application and standardization this way is a must to test and change in one place the entire behavior of the control in different hardware. 2. For combo boxes, grids, docks, etc set width using percentage so it can grow and shrink based on skin used. Use your div containers as your boundary control. So when the tablet flips for landscape to portrait, the controls resize nicely. 3. Data collection pages, 3 columns is max for design, home pages, 2 columns. 4. Look at JQueryMobile for page design ideas. Menu on left automatically shifts as links to bottom of page for phone designed apps. Very nice example. Keep in touch as we too are learning how to best adapt. Our current design issue is the tool bar as it does not wrap around as the menu control does.

[Tomica]

Thanks Orin, very insightful advice, I will post our experiences as we learn.

[Orin Book]

Here is the beginnings of our telerik standards code. I will then show you our .aspx and our .aspx.vb calls. You can see how wehandle the calendar control because of Metro touch issues. One change and all is well.

Imports Telerik.Web.UI
Imports utility

''' <summary>
''' Public class with utiltiy methods for asp.net web application
''' </summary>
''' <remarks></remarks>
Public Class AspNetUtilities

    ''' <summary>
    ''' Method for setting commonly used properties of Rad Date Picker.
    ''' </summary>
    ''' <param name="radDatePicker"></param>
    ''' <remarks></remarks>
    Public Shared Sub SetRadDatePickerDefaults(ByRef radDatePicker As RadDatePicker)
        radDatePicker.MinDate = DateTime.Parse("1/1/1963")
        radDatePicker.MaxDate = DateTime.Parse("6/6/2079")
        ' When telerik bug in IE 6 fixed, set EnableShadows to true
        radDatePicker.EnableShadows = False
        radDatePicker.ToolTip = "Open the calendar popup"
        radDatePicker.ShowPopupOnFocus = False
        radDatePicker.PopupDirection = CType("11", DatePickerPopupDirection)
        radDatePicker.EnableScreenBoundaryDetection = True
        If LCase(Convert.ToString(safeSession("SkinName"))) = "metrotouch" Then
            radDatePicker.Width = Unit.Pixel(135)
        Else
            radDatePicker.Width = Unit.Pixel(100)
        End If


    End Sub

' .aspx call for calendar

            <telerik:RadDateTimePicker ID="dpMAEventDate" runat="server"></telerik:RadDateTimePicker>

' .aspx.vb call to load control with defaults

        AspNetUtilities.SetRadDatePickerDefaults(dpMAEventDate)

If you need to override or add any additional options to Control, just add after the .aspx.vb call.

I truly wish Telerik would provide better documentation to best practices for Metro Touch and tablets. I see this as just another , we provide options and you figure it out. However this approach is best approach to consistency in your controls, single place to make changes, and fix issues as they occur.

Respectfully, Tre'

[Bozhidar]

Hi,

We are trying to improve MetroTouch behavior. Unlikely we do not have a lot of mobile touch devices to check each scenario and often just a few people are QA-ing the things, and sometimes they could think of all possible scenarios. We count on your feedback to let us know what you don't like and what bugs you've found, as you are the ones that have the actual real-life scenarios and needs. Often while we are testing we test the control itself, or how it communicates with other Telerik's controls.

The simplest advice would be use table-less HTML structure and fluid layouts that could be easily manipulated through the CSS. It`s general I know, but probably we could research for the best practices building a mobile friendly web application and write a blog post that will give some basic steps and ideas how to avoid falling into most common mobile design traps.

Regards,
Bozhidar
the Telerik team