Version 3
Created by mwringe on Feb 20, 2012 5:38 PM. Last modified by mwringe on Apr 11, 2012 9:29 AM.

    Status

    Initial Planning Stage

     

    Introduction

    Developing for mobile devices may require some changes than developing a portlet for a normal desktop site. Things to take into consideration:

     

    • Desktop sites usually rely on a standard fixed pixel width, while on a mobile device the width is usually set to the width of the device.
    • Mobile devices have different constraints due to software (eg browser plugin support) and hardware (eg not mouse based input, not physical keyboard based input)

     

    For the default portlets which we provide as part of GateIn, we will use the mobile skin to make the portlets conform to the screen type. But for external portlet developers, should the portlet be aware that it is being rendered on a 'mobile' device? What information should be available to the portlet?

     

    Use Cases

    • Different Content for different device classes.
      • On the desktop site the portlet provides graphs and charts as interactive flash components. Since many mobile devices do not support flash (and mobile flash is being discontinued) they wish to provide either static images of the graphs/charts or provide some simple html5 based interactions
      • Most popular mobile devices support html5, the portlet developer may wish to use some of these html5 capabilities in portlet content, but wants to use html4 on the desktop due to older desktop browsers not supporting html5
    • Descriptive Content
      • On the desktop site, the portlet may provide a verbose description. On the mobile device they may wish to have a shorter description, or display only some of the content and require a 'read more' button to expand it. This may be due to the more expensive screen real estate on mobile devices
    • Image Sizes
      • A portlet may wish to provide different sized images based on the device it is being displayed upon. Note this gets a bit tricky since some mobile devices like tablets are going to have higher resolution screens than most desktops.
    • Look and Feel
      • Certain mobile operating systems have a distinct look and fell. The portlet may wish to return content which better matches the look and feel of the native environment.

     

    Background Information

    Currently portlets will have access to the user agent string from within the portlet. Portlet developers can already use this to customize the content they return. But as described in GateinMobileDetectionAndRedirection this only tells us about the browser wants us to think it it, and not what type of device it is being rendered on.

     

    Browser based capabilities detection can let us know more about the device the browser is being viewed upon (eg screen resolution). But this information happens when the browser displays the content, after the portlet's markup has been determined. See GateinMobileDetectionAndRedirection for more information. The portlet markup itself can use css media queries to determine how content should be displayed when on specific devices, and can use this to become 'responsive'. The portlets itself can also use javascript to determine if the site supports specific browser plugins or not (eg flash content). This is how most 'responsive' web design is currently done, and is a more standard approach to handling this. Even if we knew the device resolution before rendering the markup, this resolution can change if the device is rotated.

     

    The mobile portal sites are going to be separate from the desktop site. There may be different sites for different types of devices (eg desktop, phone, tablet, ....). We have no guarantee to the criteria that the admin will use when determining if a site is mobile or not.

     

    Mobile Portlet Development Recommendations

    We can't really know what screen size or device type we are rending the content on before the portlet content should be rendered. We also can't really know what is the criteria the portal admin used to specify the site as being 'mobile'. As such the recommendations to portlet developers should be:

     

    Mobile Skins

    If the content type between the mobile and desktop versions varies only in css, then the portlet developer should use the gatein skin service to load a different css files based on the skin. This will be how we will handle the internal/default portlets to make them mobile

     

    Mobile Specific Portlets

    Instead of trying to reuse exactly the same portlet between the mobile and desktop versions of a site, the developer can create a new portlet specific for the mobile site. This will be necessary anyway if the content varies greatly between the two.

     

    Use Portlet Preferences to Specify the Content

    Have the admin change a portlet preference for a particular portlet instance and have the portlet change its output based on this. Requires an extra step from the admin, but requires no changes to what is currently in the portal and uses standard portlet practices.

     

    User Responsive Web Design Practices

    If the portlet developer uses standard responsive web design practices, then the portlet should adapt properly to the type of device in use.

     

    User Agent Strings

    If the portal itself is solely using user agent strings, then it may make sense for the portlet to also use user agent strings to make decisions on content. Portlet developers can already access this information so no changes are necessary.