GB2502675A - Device customised website layout - Google Patents

Abstract

A user interface system for multiple device platforms wherein each page on a website communicates with an optimiser component that checks for the identity of the device being used and previously selected user preferences and provides style rules to the web page which when written into the web page modify the appearance or content of the web page

Description

User hiterface System for MultipLe Device Platforms The present invention relates to a browser user interface system for multiple device platforms; for example providing suitable display and relevant content of a given website on desktop, mobile, tablet and TV devices. The invention is intended to deliver a clear, meaningful, future-proofed and appropriate experience both efficiently and effectively from a website to an increasingly diverse range of internet accessible devices.

Background to the Invention

It is increasingly common for mobile telephones to be used to browse the Internet such that organisations with available resources have responded by creating mobile sites, responsive designs and various applications (referred to as "apps"). However, the subsequent advent of tablet devices such as the iPad®, PlayBook® and various other products using the Android® operating system, heralds a new "post-computer" era which will evolve further and will also include devices such as TVs and Sat-Nays.

To merely continue to develop an ever-increasing number of parallel sites, additional designs or device-specific apps will become expensive, unwieldy to administer and maintain, and potentially more complex/less friendly for the site user.

Therefore, a problem now exists that developers, website owners, marketers and content editors will need to find and afford effective ways to address the differing needs of an increasingly multiplatform audience compared with a personal computer-only one.

In practice there are three main approaches that are in use currently for tackling the problem the present inventors have identified. These approaches are driven largely, and in many cases exclusively, by the uptake of internet "Smartphones": Mobile apps: Recent years have seen an explosion in mobile apps being created and offered as an alternative to having a mobile-friendly website. However, where an app has been created simply as a means of accessing online information, this is a time-consuming, costly and device-limited alternative compared to effective use of the built-in browser.

The development of mobile apps is most appropriate when the app uses features and functions of the device itself. A good example of an app is a scan reader which can be used to read a QR code, using the built-in camera on the device, which in turn is then able to download certain information into the browser.

Mobile apps have to be built for each device/operating system combination they are to be used on. They also require downloading and installing by a device user. For example, iPhone® and Android® based applications are separate software programs and some apps are only available on one or the other device, which instantly excludes many potential users (who could be paying customers).

Mobile websites: A number of organisations already have mobile sites, but these tend to be separate from, and in addition to, the existing main PC (Classic view) site. For example Facebook®, the BBC® and eBay® each offer a cut-down service on mobiles compared with the PC experience, and served from a different URL (e.g. www.bbc.co.uk/mobile). This approach generally entails maintenance and update of more than one site.

Mobile sites are delivered predominantly by one of the following methods: 1. The user knowing the URL of the mobile site and entering it directly; 2. The user clicking on a link on the PC site to open the mobile site instead; 3. Being automatically redirected to the mobile site as a result of a server-side database device query; 4. The style being changed to suit a mobile display through HTML "media queries" (see below).

Responsive web designs: These use "media queries" as introduced above to query the screen resolution of the device being used to access the site. Different layouts are offered depending on the resolution. This technique is becoming increasingly popular, but is limited in that media queries do not distinguish between different platforms -therefore: 1. All mobiles are treated alike, not allowing any customisation for differences between, for example, iPhone® and BlackBerry® devices 2. This approach cannot differentiate between a small handheld screen that has a high resolution and a large screen with the same resolution (eg TV) that is viewed at a distance 3. It is not sufficiently sophisticated to enable a future-proof' system that can accommodate devices yet to appear on the market 4. Users typically cannot exercise individual preferences for how the webpage displays

Summary of the Invention

Accordingly, the present invention seeks to provide a solution to this on-going problem of multiple formats, and an alternative to the three approaches identified above, so that a website and its content can be delivered appropriately to an end user, irrespective of, and taking into account, the device used.

In a broad aspect of the invention there is provided a user interface system according to claim 1. Particularly the system caters for multiple device platforms, including: * the user accessing a website via a single URL (same URL for all devices); * each page on the website being able to communicate with an optimiser component from a central server in order to identify the device being used; * the optimiser checking whether the user has set their own display preference on their device for that website in a way that does not require login or knowledge of the user's identity; * the optimiser component directing the website to appropriate style rules as a result of the device identification / preference check; * the style rules being written into the page, and thereby; * the website providing an optimised (modified as appropriate) user interface and/or content on the device display screen dependent on the device being supported. If the device is not currently supported, and no preference has been set, the site is instructed to display a fall-back user interface and/or message.

Preferably the optimiser component is located on a central server and the style rules are located on the host server for the website, for ease of access and maintenance.

In a preferred form, as part of the device identification process performed by the optimiser component: 1. A first action checks to see if a suitable multi-paradigm general purpose programming language (e.g. JavaScript) is enabled. If not, the user is prompted to enable this function and/or directed to a browser page with help tips. If the language cannot be enabled then the user may be directed to an alternative interface.

2. The optimiser interrogates the device directly, to establish its identity, mainly through querying the User Agent (UA) parameters.

3. The optimiser checks to see if the user has activated their own display preference for that site on their device, e.g. by use of cookies.

4. The relevant optimised user interface is activated by a modular set of JavaScript codes.

5. Preferably the screen size in some instances is also queried when interrogating the device type. The optimised/modified user interface in some instances is adapted to display equivalent content with appropriate layout to accommodate varying screen sizes (e.g. when a tablet is turned from landscape into portrait orientation).

In a second broad aspect the invention provides a system for developing user interfaces for multiple device platforms that includes a previewer tool to represent different device views. This enables a webpage to be viewed and compared across different device platforms directly on the computer without the need to have the actual device to hand.

To achieve this, a variant of the device identification / optimisation process defined by the first broad aspect retrieves style rules to enable any changes made to the webpage to be previewed directly on developer's computer screen (i.e. in preview windows that represent the other devicels). The facility exists to provide modified style parameters if required for an individual site to adjust for significant differences between the actual device display and the previewer version.

The previewer tool of the second broad aspect above can be incorporated into the user interface system of the first broad aspect by providing a displayed visual output at the optimised user interface stage. In this way the previewer tool acts as a translator between the device display and the website server once the type of device has been identified in the interrogation step.

According to the invention; firstly, it is possible to deliver device-friendly experiences for online access to information and services at a time, location and manner to suit the user; secondly, the user can select from other experiences without the need to log in or otherwise identify themselves to the site; and thirdly, simpler to use devices, such as connected TVs, will be able to provide the chance to extend accessible internet services to users who are currently digitally excluded.

Brief Description of the Drawings

Figure 1 illustrates an overview sketch outlining the purpose of the invention; Figure 2 illustrates the overall system and process flow; Figure 3 expands on the identification / optimisation process; Figure 4 expands on the style rules process; Figure 5 illustrates the online previewer tool.

Detailed Description of the Preferred Embodiment(s) Referring to Figure 1, the general capability of the invention is depicted where a suitable user interface (UI) experience is provided via a single website address (URL) to a wide range of platforms, including connected TVs. It is intended that the same website would be viewable by users on one or more mobile phones (different operating systems), a tablet, a desktop PC and/or a television.

The invention involves implementing a cost-effective, modular solution capable of being used and afforded by all types of individuals and organisations. The previewers enable the developer/site owner/editor to see in real time, onscreen, a representation of how any content and design changes they make will display on various devices. This capability saves the cost and time of needing to have a range of actual physical devices on-hand.

As an alternative to the existing approaches currently being employed for delivering content to multiple devices, the present invention offers an elegant simplicity in its approach, using a single URL to access the site, and then delivering different experiences of the same content appropriate to the end user's device -thus there is no "poor relation" in content terms. In other words, one format is not subject to a significant excision of content over another device, but can be customised to suit particular needs, e.g. -messages can be customised and delivered to specified devices (e.g. referring to the availability of an iPhone app only where the device in use is an iPhone, and having no such reference in the case of where an app is not available on the platform being used to access the website).

-equally, where a website proprietor specifically desires a different site for a given platform, say for a designated marketing campaign, it is possible to use a redirect so that the end user still only needs to know the one URL, The invention delivers a platform/device experience by interrogating the device itself and then acting directly on that information, rather than using it to compare to a database, as with some solutions. This avoids an approach that is highly dependent on the integrity of the database. Particularly, errors in database entries can lead to incorrect device Uls being deployed.

Further User Interface (UI) options can (on supported devices) be selected by the user without the need to log in. Examples include: applying reverse contrast on mobiles to suit different light conditions, accessibility features (e.g. use of a larger typeface / bigger buttons), or choosing to change to a different device UI such as using the mobile interface on a tablet. Features of the end device (e.g. zoom) are preferably not over-ridden, so the user is still able to make the most of any inbuilt device capabilities.

According to the invention, style rules are central to the system, and have been developed to provide integrated attributes and functionality for specific devices: Use of Style Rules (1): * The user interface facilitates content to be specifically "shown on" or "hidden from" each supported device I groups of devices at the site editor's discretion.

For example, the site editor can enable a "show-hide menu" function for smaller screens to make better use of the available space.

* Certain mobile devices allow for the URL address bar to be removed once the page has loaded to make more use of the available space. As the technique to achieve this is not suitable for a PC display, it is only included in the style rules for devices that support this capability.

Example style rules (referring particularly to elements shown in bold): For Desktop Computer -calls the main style sheet for the desktop: document.write ("<link href=\"littp;\/\/charne]eonmuitiplatforrn.co.uk\/chameieon\/ui\/desktop\/c ss\/ioader.css\" titie=\"default\" rei=\"styiesheet\" type=\"text\/css\">"); For iPhone -firstly calls style sheets dependent on orientation: (portrait): docurnent.write("<link href=\"http:\/\/chameleonmultiplatform.co.uk\/charneleon\/ui\/iphone\/cs s\/icader.css\" t±tie=\"defauit\" rei=\"styiesheet\" tvpe=\"text\/cnn\" media=\"all and (orientation:portrait)\">"); (landscape): document, write ("<link href\"http:\/\/chame]ecnmuJt±p1atform.cc.uk\/charneJeon\/u±\/iphone\/cs s\/]cader css\" t±t]e=\"defauit\" re]=\"styiesheet\ type=\"text\ /css\" media=\"all and (orientation:landscape)\T1>n1) then defines viewport to manage initial scaling so content is readable: document.write ("cmeta name=\ rTviewport\Tu content=\ rTwidth=device_width\IT \/>fl) ; lastly hides the URL address bar: setTimeout(function() {window.scrollTo(0, 1); }. 500); The system for applying the style rules according to the invention allows for content to be managed in one place, i.e. a central server. Therefore, changes to website content only have to be made once and will automatically be applied to all supported devices.

The system also has the capability to work with different developer tools and techniques, eg traditional page builder' tools such as Dreamweaver®, or content-management systems such as WordPress®.

Use of Style Rules (2): Existing responsive website techniques rely on screen-size media queries, but there are a number of reasons why the present invention extends beyond this, namely: * It has been found that certain devices do not obey the media query style rules, and therefore cannot be made to behave as desired using this technique (e.g. Apple® products use device orientation instead of screen-width).

* The same screen resolution may correspond to more than one device type, e.g. a touch-screen tablet and a TV set-top box -where different display characteristics may be needed on each. An example might be that the font size and navigation buttons for a TV should be larger (to be readable from a distance) than for a tablet.

* Where there is a need to send messages to particular devices, the degree of control the system supports means the invention can ensure messages and corresponding actions can be targeted to suit the platform or device in question. Examples include links to external documents or to download a particular app, where the source content will need to suit the operating system, not the screen size.

Use of Style Rules (3): Some optimisation processes (eg database reference techniques) can be slow and cumbersome, and are often only applied on the homepage of a site. It is an important characteristic of this invention that it is easy to implement throughout an entire website of multiple pages.

* Every page that uses this system is optimised, e.g. if a particular page is bookmarked, when the user goes directly to that page, the device being used is identified, and the correct view seen via the style rules. Other techniques will only identify the need for a different view if the user goes to the homepage of the site.

* If a link from the site is sent to another user, the page (and the rest of the site) will present in its optimised format for that second user's device.

A useful way of explaining implementation of the invention is by reference to a use scenario, specifically: * A site visitor enters a web URL on a device of their choice, and the outline process begins in accordance with the flow diagram of Figure 2.

* The first action checks to see if JavaScript (or an equivalent multi-paradigm general purpose programming language that may later come into standard use) is enabled on the device's browser. In the event that it is not, a "noscript" message appears at the top of the browser page indicating this should be remedied. Preferably, this message contains a link to a page with help tips covering a number of the more common browsers and devices currently on the market.

* In the case defined above, the page reverts to using the original style sheet for the site. This means that the end user is not presented with a totally un-styled experience.

* With JavaScript enabled, the central component of the system of the invention (known as the "optimiser") activates. This uses a modular set of JavaScript codes to determine whether the incoming device is one that is specifically supported by that particular site. This secondary process is as outlined in Figure 3.

* The first step in optimisation is to manage "desktop" browsers. In the present context, "desktop" is the generic term used for IBM® compatible and Macintosh® computers, which includes desktop and laptop devices.

* In addition to delivering the appropriate desktop UI, the system also manages a range of previewers at this stage (e.g. if website content were being edited or design changes being made). An example previewer window is shown by Figure 5. In this case, the Android mobile phone previewer is opened in a PC browser via a secure online control panel.

* Once the desktop devices and previewers have been accounted for, the remaining test loop as shown in Figure 3 is to match the incoming device User Agent (UA) to the list of supported devices.

* The number and range of supported devices can effectively be as few or as many as the site owner or developer wishes. Device support code modules can be added or removed as desired during the optimiser configuration as part of the site set-up. These code modules can be updated when a new device or operating system (or upgrade) becomes established.

* All supported devices for a given site are directed to their associated style rule instructions, and once the loop has been completed, all remaining devices are directed to the fall-back instruction set.

* The device display instructions are applied in accordance with the flow diagram illustrated by Figure 4.

Upon identifying a supported device as covered in the section above, the style rules as defined for that device for the site in question are applied by a secondary script file, e.g. style.js.

If the device rule is to redirect to another site, such as a mobile specific site or a marketing campaign site, then the system loads the new web address automatically (no action by user needed). This may be in either the same, or a new window, depending on the site owner's preference.

If the device rule is to stay on the same site, the display parameters for the device in question are applied. The sequence is: 1. Apply the device-specific master style sheet, e.g. loader.css 2. Apply any other display rules (e.g. for iPhone / iPod, hide the URL address bar to make more of the display area) Details on any alternative design style sheets that the user can set as their individual preference are included within the main optimiser module.

In keeping with the modular design of the system of the invention, the style sheets are also managed and delivered in a modular way using standard file import rules.

Typically the style sheets are separated by either the area of the screen they control (e.g. header) or by function (e.g. forms), preferably working to adjust / override the master style sheet elements and apply attributes to suit the particular device.

An important aspect of the overall process includes giving the developer the freedom to apply their design experience and knowledge to create the full suite of user interface designs. Each platform needs a design that can reflect the core brand values of the site owner as well as specific elements that suit the display and navigation characteristics of the particular device, e.g. touch screen mobiles, remote control operated TVs etc. The system of the invention uses some specifically written code to implement the process as outlined above to deliver a simple, engaging and appropriate interface across a diverse range of devices to a broad user base. However, in keeping with many technical developments, a good degree of sophisticated know-how behind the scenes is needed to be applied in a clear, structured way such that site owners and site visitors alike can benefit from the simple solution.

The range of internet connected devices will only continue to grow and diversify and so the affordable, easy to use, future-proofed, flexible system of the invention will fulfil an ongoing role in enabling all sections of society to benefit.

A typical implementation scenario is outlined below to provide further understanding of the invention. Specifically, the invention has been designed to make it as simple to implement as possible. Furthermore it has been developed to allow: * creation of new sites (e.g. using a proprietary design site template with the code elements and calls already built in), and * adaptation of existing sites, through a series of steps, namely configuration, installation, implementation and customisation A remote diagnostics tool is included on the central server, and is accessible directly from any implemented site. This means that someone using the site can send information about their particular device directly to the central server. This in turn helps the proprietors to implement new design and display changes without the need to necessarily have access to the device in question. This is a key element in the future-proofing aspect of the invention.

It is also an important aspect of the invention that the future-proofing capability allows updates to be made on the central server to accommodate new devices, independent of the sites themselves. Depending on the actual configuration for a given site, the whole process for inclusion of a new device need not involve any new installations on the site itself, or may require upload of some new files.

Scenario 1: Creation of a new site: The developer of the site typically purchases either a proprietary site template or a software licence to include in their own design. This may be a page build solution for use with tools like Dreamweaver®, a theme for use in Wordpress® etc. The software is then configured for the new domain, and the appropriate elements delivered to the developer I made available for download. The central server elements are installed, ready for use by the new site.

The resources set includes: * a test page which checks all elements have been included correctly, and provides next step instructions * a settings page, where the options for different display modes are displayed, and * a diagnostics page to display User Agent and screen size information allowing users or developers to see what is understood about their particular device.

These pages also contain the link to the central server diagnostics feedback utility described above.

Scenario 2: Adaptation of an existing site: The developer typically purchases a software licence from the proprietor of the invention, again suited for the development platform of their choice. Similar to Scenario 1, the software is configured for the existing domain, then the appropriate elements delivered / made available for download. The central server elements are installed on the proprietor server, ready for use.

The site resources set is similar to those described in the new site scenario above, but the instructions in this instance exclusively relate to including the call for optimiser functionality (both local and from the central server) into the existing pages of the site.

The recommended procedure is for the site developer to create a copy of, say, the homepage, and use this to test and tweak the optimiser implementation and customisation without affecting the main live site. Once ready, a site-wide deployment can be made.

In both scenarios above, the customisation step mainly concerns checking and adjusting the application of colours, logos etc. to suit the brand identity of the site owner across the different platforms. Tools such as the support guidelines, development articles and the previewers are available to the developers via an online support portal.

Claims (11)

1. CLAIMS: 1. A user interface system for multiple device platforms, wherein: a host server hosts a website that a user, using an internet enabled device, is able to access; each page on the website is able to communicate with an optimiser component to check for identity of the device being used or a previously selected user preference; the optimiser component directs the website to appropriate style rules as a result of the device identification / preference check; the style rules being written into the page communicated to the device, and thereby; the website being able to provide a modified user interface and/or content on a display screen dependent on the device.
2. 2. The user interface system of claim 1 wherein if the identity of the device is not able to be determined and/or no user preference has been set, the website is instructed to use a fall-back user interface and/or message.
3. 3. The user interface system of claim 1 wherein the style rules are located on the host server or a central server separate from the host server.
4. 4. The user interface system of claim 1 wherein the optimiser component is located on the host server or a central server separate from the host server.
5. 5. The user interface system of any preceding claim wherein the device identity check comprises a first action to check to see if a suitable multi-paradigm general purpose programming language (e.g. JavaScript) is enabled and, if not, the user is prompted to enable this function on the device.
6. 6. The user interface system of any preceding claim wherein the optimiser component is activated by a modular set of JavaScript codes.
7. 7. The user interface system of any preceding claim wherein the screen size is also queried when interrogating the device type.
8. 8. The user interface system of any preceding claim, wherein the optimiser component includes use of a previewer that translates between a master website and another device platform.
9. 9. A system for developing user interfaces for multiple device platforms that includes a previewer viewable on a client computer to enable viewing the appearance of a webpage on at least one different platform from the platform of the client computer; wherein a user selects a specific previewer platform for viewing; the client computer contacts a central server; the central server provides instruction for using style rules specific to the selected platform; the style rules are written into the webpage communicated to the previewer; and thereby the webpage, as viewed in the previewer, substantially assumes the appearance of the different platform, dependent on the platform selected.
10. 10. The system of claim 9 wherein the style rules are provided to adjust for significant differences between one or more actual device displays and the corresponding previewer's rendition of the same view.
11. 11. A user interface system for multiple device platforms or system for developing user interfaces substantially as herein described with reference to the accompanying drawings.