Initial Planning Stage
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?
- 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.
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.
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:
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.