Skip to Content

This document describes several tips that we (the portal implementation team) recommend that you (portal application developers) use, so you can enjoy your application without compromising the UX/UI. From my experience of developing a framework and several applications, I summarized the highlights for designing and developing your application to run better on mobile.

Design your application for several devices

To enable your application to run on several mobile media devices like tablets, smartphones, and even on desktops, so you can “write once, run everywhere”, your application must recognize the device you run in (screen size, operating system) and adjust your web pages to exploit the full size of the screen.

By doing so, the look and feel of your web pages will be different for different devices. This can be done by implementing the design principles of “Responsive Design”. These principles can help you get the desired web pages for the desired device with easy and fast development.

There are many websites that implement these principles; here is a website that implements them well: http://www.breadandpepper.com.

To read more about this topic, see http://en.wikipedia.org/wiki/Responsive_Web_Design.

Less iFrame, more power

This is a painful issue for us, the iFrame issue. The portal on device framework runs “Portal iViews” and “Portal Pages” as an application inside an iFrame element. The use of an iFrame is to enable full control and isolation from the framework. The mobile devices that we’ve checked (iOS and Android) don’t have very good support for this element. The Safari browser on iOS devices ignores the height and width properties and stretches the content to its full height and width, with no possibility for scrolling. Moreover, if you place an iFrame inside an iFrame, the problems begin.

In the framework, your application runs under an iFrame. We do it like that to get “Portal Pages” that will work well on the mobile device. A “Portal Page” contains an isolated iView (embedded iView or Pages overwrite the JavaScript on the client), so we get an iFrame – Portal Page, which wraps an iFrame – Portal iViews. In this structure, the hand gestures and clicks are usually incorrectly placed and the browser makes the gesture/click with different x-y coordinates.

To bypass this limitation, we remove the wrapper iFrame and stay with single-level iFrames that the browser can handle. So if you need to run content in your application inside an iFrame I recommend that you open your application in a new window without the framework iFrame wrapper.

Another limitation that we’ve handled is the difference between the height of the content inside the iFrame, the height of the iFrame and the height of the wrapper div of the iFrame.

<div>

<iframe>

<html></html>

</iframe>

</div>


The wrapper element must be larger than or equal to the inside element so that the hand gestures and clicks work properly. Otherwise, the clicks inside the iFrame beneath the iframe/div height will activate the clicks in the iFrame/div height.

0 percent interest

To make your application more compatible and adjusted to mobile devices, use percentages (%) for your height and width properties and avoid using pixels. This way, your application will behave well on different devices, in portrait and landscape mode.

Click-events

If you use jQueryMobile, avoid using “tap” binding and go for click/mouseup events instead. We found that these events behave very well in the framework and in the application within the iFrames. There are some events for which you can implement or bind more complex events like swipe up/swipe down that will work well on tablets, but on smartphones those events have poor performance and usability.

In jQueryMobile, we found that the <a> element is bound to events whose scroll or click is rendered badly on smartphones. We recommend avoiding this, if you use jQueryMobile, and to implement it in a different way (<li> <span>…).

Transition

Many different technologies contain cool transitions from web page to web page or toggle between divs. On tablets, those transitions can work well inside an iFrame if the content is plain and not “heavy” with images. On smartphones, the transition can sometimes work properly, but I recommend the fade-in / fade-out transitions that always work.


Conclusion & outlook

In this blog I summarized some of the critical tips and tricks that the team and I discovered while developing portal on device. We found these tips and tricks very useful and want to share this information with you so you can build and run better applications on mobile devices. Hopefully, I will be able to share more information soon, and I would be happy to get your feedback regarding which areas/topics you would like me to focus on.

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Johannes Bacher

    Hello Dvir,

    you say: “…use percentages (%) for your height and width properties and avoid using pixels…”

    I tried to set the property “Width of external window” in my URL iview which is placed in the Launcher to “100%” but cannot save this, it seems to only accept pixel entries.

    How can I define widht and height of an URL iview in percentage ?

    thank you,

    Johannes

    (0) 

Leave a Reply