Creating content for mobile websites instruction

Instruction statement

This instruction provides RMIT content creators, web editors and web managers with best-practice principles and guidance on creating content for RMIT mobile websites. It ensures the standard of RMIT’s mobile web content is in harmony with the University’s extended web presence, providing a consistent, trusted and satisfying experience for users across all platforms.

Exclusions

Nil.

Instruction steps and actions

Instruction (including key points)

Responsibility

Timeline

1. Consider the context

1.1 Curate, create or reuse content appropriate to the mobile context. Time-consuming tasks are less likely to be completed on mobile (for example, lengthy articles and complex transactions, like filling in forms). If such tasks are important to your audience, link to where they can be completed (for example, documents and forms might be housed on the full site).

1.2 As a general rule, tasks bound to deadlines are more likely to be done on RMIT mobile devices. Our audiences will expect quick access to:

  • updated information (such as course schedules and times) to pursue larger goals;
  • concise information about the University (for example, short descriptions taken from the ‘About’ and Life at RMIT’ sections on the full site);
  • wayfinding information (directions and public transport)

Web Manager

Ongoing

2. Reuse content wherever possible

2.1 Following the Mobile Channel Policy and Web ContentPolicy, the COPE principle (Create Once Publish Everywhere) guides content creation from a ‘single source of truth’, principally RMIT’s content management system (CMS). Where content is developed according to the Content Types Instructions, it can be delivered consistently across several different devices from this source, avoiding duplicated and outdated material.

2.2 For some content (for example, programs and staff profiles), the single source of truth may be another system or database outside of the CMS, in which case Digital and Customer Experience Strategy (WSIP) should be consulted to avoid duplication across multiple systems.

2.3 Mobile content must be drawn wherever possible from the CMS to ensure consistency and limit the need to update content in several places. Content standards must follow instructions contained within the ‘Creating Web Content’ section of the Web Content Policy.

2.4 The mobile experience must incorporate intuitive, onward journeys between the mobile site and the full RMIT site. Responses to user questions on mobile and on desktop should be consistent. This is applicable on mobile even if the response is in the form of a link to the full site for more complex tasks.

2.5 Content reuse for mobile must follow the framework outlined in the Content Types Instructions, keeping in mind that a more succinct user experience will be incorporated into mobile. Brief elements like Headings and Short Descriptions will work best, so consider how these will display in this context.

2.6 If content is drawn from the single source of truth and reworked for mobile, the changes must be reflected back at the source system (ideally the CMS) wherever possible. This maintains the integrity of the single source of truth across channels.

3. Create content only if reuse is not possible

3.1 In some cases, it may be necessary to create new content for mobile (for example, it may not already exist in the CMS). If this applies, follow these key points and consult the Writing for the Web Instruction for detailed guidance (for image recommendations, see Section 5 below):

  • Write for all users. Content must be searchable and readable by many different users across a broad international audience. Employ plain English, fact-based language and a conversational tone.
  • Be direct. Keep to short, focused and essential sentence structures. Make every word count.
  • Make content scannable. Web users don not read every word on a web page. Instead, they skim for meaningful content, especially if searching for information relevant to a specific task (as happens often in the mobile environment). To enable this, keep text as concise and to the point as possible. Consider bullet points so users can easily find information.
  • Be task-orientated. Make use of metadata, calls to action and meaningful links to maintain a clear purpose for your page.
  • Avoid tables and forms. As these elements are difficult to implement for a satisfying mobile experience, provide alternatives. For example, instead of asking users to fill out complex mobile forms to make an enquiry, point them via links to contact information on the main site.
  • Avoid PDFs and Word documents. As these elements will not display effectively on mobile, provide summaries and links to sites where the documents are published online.

3.2 For frequently updated content, include the date of the last update.

3.3 Do not rework staff profiles or programs information – this must be reproduced as it appears on the main website.

Web Manager

Web Editor

Content Creator

Ongoing

4. Working with apps

4.1 In-phone functionality

  • Use media elements such as in-device maps instead of forcing users to navigate to external websites (for example, make use of Google or Apple maps).
  • Users should not be expected to open another browser to share content on Twitter or other social media platforms. Wherever possible, use in-device sharing functionality so that the user experience is contained within the application (app).
  • In-phone features such as GPS can be used to save time for the user by allowing quick input of information (for example, auto generation of postcodes and addresses using ‘current location’ functionality).

4.2 Push notifications

  • Consider the frequency of push notifications. Applications (apps) should be as simple and uncluttered as possible, and users should not have to choose from too many confusing options.
  • Don’t force users to accept push notifications before they get a chance to use the app. Allow notifications to be turned on by users, rather than turning them on by default before they know exactly what acceptance would mean (for example, sound alerts, which may happen at inconvenient times).
  • Don’t include user manuals. An app should be simple enough to be self-explanatory (perhaps with the aid of selectively used tips) without users having to consult pages of extra material.
  • If the app offers tips for enhancing the user experience via push notifications, do not overwhelm with too many at once. Make sure there is a clearly conveyed facility to disable tips (and push notifications in general).
  • Do not make tips too obvious – users will ignore them if they are not adding to their knowledge. Make sure all tips add value to the user experience.

5. Image and Video Content

5.1 Images should be used sparingly. Only include them if they can add depth and meaning to your content. Given the technical constraints of mobile use (slower download times and smaller screen size), do not use images purely for decoration.

5.2 Caption images if their message is not clear from the accompanying text content.

5.3 Optimise images for mobile use, with dimensions and file size as small as possible. Refer to the Media Content Type Instruction and to your relevant home page or landing page image specifications for size and orientation recommendations.

5.4 If you offer videos, include a description of what it’s about and, if possible, a link to a transcript.

5.5 Videos take longer to load on mobile, so make sure they are optimised. Ideally, they should be no longer than 30 seconds, although longer videos may be required at times. Make sure the duration is clearly stated so users can decide whether to watch if time or bandwidth is limited.

6. Deleting and archiving

6.1 Many mobile apps have a short life on mobile phones and, unless they have a real user need at their core, will not be used on an ongoing basis. Consider the requirements of transaction-orientated apps (such as myRMIT) versus content-based apps. Generally, the latter should be treated as disposable, as content is likely to be delivered for a one-off occasion rather than updated frequently. In these cases, plan carefully the lifecycle of your app and make sure there is a deletion and archiving process in place for all content displayed on it.

6.2 The lifecycle plans of all mobile properties (including apps) must be included in your completed New Website Proposal form, ensuring appropriate life spans of both content and technology.

6.3 End-of-life mobile websites must be removed in accordance with the Deleting Websites Procedure and Deleting and Archiving of Web Content Procedure.

Web Manager

After the project’s lifecycle

[Next: Supporting documents and information]