US20140040769A1 - Multiple-stage interface control of a mobile electronic device - Google Patents

Abstract

An electronic device, such as a mobile communication device, and a method are provided for multiple-stage interface control of the device. The device is provided with a homescreen display, which includes a plurality of panels. The panels include at least one panel that is a fullscreen view of a first application executing on the device. This first application can be a messaging application, and the fullscreen view can be a unified inbox view for a plurality of different message types. The panels also include at least one launch panel having a number of graphical user interface elements, such as icons, representing access points to a corresponding application on the device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims priority to U.S. Non-Provisional application Ser. No. 13/706,782, filed Dec. 6, 2012, which claims priority Provisional Application Ser. No. 61/678,388, filed 1 Aug. 2012, the entirety of which is incorporated herein by reference.
TECHNICAL FIELD
• The present disclosure relates to a multiple-stage graphical user interface implemented by an electronic device to provide access to applications and data.
TECHNICAL BACKGROUND
• Mobile computing device platforms, such as tablet computers or smartphones, are typically subject to physical limitations that less portable computing platforms, such as desktop computing platforms, are not. Mobile devices, for instance, typically have a smaller form factor and an integrated display screen. These factors may limit the variety of user interface options available for controlling the mobile device: mobile devices are provided with smaller physical keyboards than desktop or laptop computers, or may have no keyboard at all; and the mobile device's display screen, smaller than a typical desktop or laptop display panel, restricts the volume of information that can be simultaneously displayed to the user while still being legible.
• Nevertheless, the types of information that can be stored on a mobile device can be just as diverse as the information stored on a desktop or laptop computer with more robust processing capabilities: messages of different types, productivity files, e-books, music and other entertainment products, not to mention the large variety of recreational, productivity and personal interest applications available for mobile computing platforms. All of this information still needs to be presented to the user in a manner that enables the user to locate the desired application or data file efficiently and conveniently.
BRIEF DESCRIPTION OF THE DRAWINGS
• In drawings which illustrate by way of example only embodiments of the present disclosure, in which like reference numerals describe similar items throughout the various figures,
• FIG. 1 is a block diagram of an example of an electronic device.
• FIG. 2 is a schematic diagram illustrating two example homescreen views of a multiple-stage homescreen and example gesture navigation instructions for transitioning between the two views.
• FIG. 3 is a schematic diagram illustrating four example homescreen views and navigation between the views.
• FIG. 4 is a schematic diagram illustrating a homescreen view and an application view and an example gesture navigation instruction for transitioning between the two views.
• FIG. 5 is a schematic diagram illustrating two example application views and example gesture navigation instructions for transitioning between the two views.
• FIG. 6 is a schematic illustration of interaction of views of a multiple-stage homescreen and individual application screens displayable on the electronic device.
• FIG. 7 is a schematic illustration of a layout of multiple-stage homescreens including an inbox or unified messaging pane.
• FIG. 8 is a schematic diagram illustrating four example homescreen views including a messaging panel and navigation between the views.
• FIG. 9 is a further schematic diagram illustrating four example homescreen views including a messaging panel and navigation between the views.
• FIG. 10 is a schematic illustration of interaction of views of a multiple-stage homescreen including a messaging pane and individual application screens displayable on the electronic device.
• FIG. 11 is a schematic diagram of select message-related components of the electronic device ofFIG. 1.
• FIG. 12 is an example inbox view forming part of a multiple-stage homescreen.
• FIGS. 13A to 13C are example inbox views forming part of a multiple-stage homescreen.
• FIG. 14 is a flowchart illustrating an example method of navigating a multiple-stage homescreen.
• FIG. 15 is a schematic diagram illustrating four example homescreen views including a messaging pane and a lock screen, and navigation between the views.
• FIG. 16 illustrates example views for a lock screen forming part of a multiple-stage homescreen view.
• FIG. 17 is a flowchart illustrating an example method of navigating a multiple-stage homescreen with a lock screen.
• FIGS. 18A and 18B are example inbox views for tagging or categorizing a message as a private message.
• FIG. 19 is a schematic diagram illustrating message views and homescreen views including a messaging pane and lock dialog.
• FIG. 20 illustrates example messaging views displayable in a homescreen mode.
• FIG. 21 is a schematic diagram illustrating homescreen and message views, and navigation between the views.
• FIG. 22 is a further schematic diagram illustrating homescreen and message views, and navigation between the views.
• FIG. 23 is a flowchart illustrating an example method of navigating a multiple-stage homescreen to access private messages.
DETAILED DESCRIPTION OF THE INVENTION
• The embodiments and examples described herein provide a device, system and methods for presenting and accessing multiple portions of a homescreen implemented on a mobile device, such as a tablet or smartphone, in which the homescreen includes an integrated application view such as a unified message inbox view. These examples may in particular be implemented on mobile devices adapted to normally execute applications in a fullscreen view and normally displaying, as a main display or view, a launchpad-style homescreen or landing screen. These examples will be described generally with reference to a touchscreen-based device, although variations and modifications appropriate to non-touchscreen-based devices will be known to those skilled in the art.
• These embodiments are described and illustrated primarily in relation to mobile electronic devices, such as tablet computers, smartphones, or any other suitable electronic device provided with sufficient user interface mechanisms as will be understood by those skilled in the art from the following description. It will be appreciated by those skilled in the art, however, that this description is not intended to limit the scope of the described embodiments to implementation on mobile or portable devices, or on tablets or smartphones in particular. For example, the methods and systems described herein may be applied to any appropriate communication device or data processing device adapted with suitable user interface mechanisms, whether or not the device is adapted to communicate with another communication or data processing device using a network communication interface adapted to communicate over a fixed or wireless connection, whether provided with voice communication capabilities or not, and whether portable or not. The device may be additionally or alternatively adapted to process data and carry out operations on data in response to user commands for any number of purposes, including productivity and entertainment. In some examples, data may be accessed from a different device. Therefore, the examples described herein may be implemented in whole or in part on electronic devices including without limitation cellular phones, smartphones, wireless organizers, personal digital assistants, desktop computers, terminals, laptops, tablets, e-book readers, handheld wireless communication devices, notebook computers, portable gaming devices, tabletop displays, Internet-connected televisions, set-top boxes, digital picture frames, digital cameras, in-vehicle entertainment systems, entertainment devices such as MP₃or video players, and the like.
• In the primary examples described herein, the electronic device includes an integrated touchscreen display; however, it will be readily understood by those skilled in the art that a touchscreen display is not necessary. In some cases, the electronic device may have an integrated display that is not touchscreen-enabled. In other cases, the electronic device (whether it possesses an integrated display or not) may be configured to output data to be painted to an external display unit such as an external monitor or panel, tablet, television screen, projector, or virtual retinal display (via a data port or transmitter, such as a Bluetooth® transceiver, USB port, HDMI port, DVI port, and the like). For such devices, references herein to a “display,” “display screen” or “display interface” are intended to encompass both integrated and external display units.
• FIG. 1 is a block diagram of an example of a portableelectronic device100 that may be used with the embodiments described herein. It should be understood that the components described inFIG. 1 are optional and that an electronic device used with various embodiments described herein may include or omit components described in relation toFIG. 1. Theelectronic device100 includes a number of components such as amain processor102 that controls the device's overall operation. Other processors or components can be included for functions not explicitly detailed herein, such as power management and conversion, encoding and decoding of audio and other data, and the like. Those skilled in the part will appreciate that such components, if present, are not illustrated here for ease of exposition.
• Theelectronic device100 may be a battery-powered device, having abattery interface132 for receiving one ormore batteries130. Alternatively or additionally, theelectronic device100 may be provided with an external power supply (e.g., mains power, using a suitable adapter as necessary). If configured for communication functions, such as data or voice communications, one or more communication subsystems104a . . . nin communication with the processor are included. Data received by theelectronic device100 can be received via one of these subsystems and decompressed and/or decrypted as necessary using techniques and components known to persons of skill in the art. The communication subsystems104a . . . ntypically include a receiver, transmitter, and associated components such as one or more embedded or internal antenna elements, local oscillators, and a digital signal processor in communication with the transmitter and receiver. The particular design of the communication subsystems104a . . . nis dependent upon the communication network with which the subsystem is intended to operate.
• For example, data may be communicated to and from theelectronic device100 using a wireless communication subsystem104aover a wireless network. In this example, the wireless communication subsystem104ais configured in accordance with one or more wireless communications standards. New wireless communications standards are still being defined, but it is believed that they will have similarities to the network behaviour described herein, and it will also be understood by persons skilled in the art that the embodiments described herein are intended to use any other suitable standards that are developed in the future. The wireless link connecting the wireless communication subsystem104awith the wireless network represents one or more different Radio Frequency (RF) channels, operating according to defined protocols specified for the wireless communications standard, and optionally other network communications.
• Theelectronic device100 may be provided with other communication subsystems, such as a wireless LAN (WLAN) communication subsystem104bor a short-range and/or near-field communications subsystem104c. The WLAN communication subsystem104bmay operate in accordance with a known network protocol such as one or more of the 802.11™ family of standards developed or maintained by IEEE. The communications subsystems104band104cprovide for communication between theelectronic device100 and different systems or devices without the use of the wireless network, over varying distances that may be less than the distance over which the communication subsystem104acan communicate with the wireless network. The subsystem104ccan include an infrared device and associated circuits and/or other components for short-range or near-field communication.
• It should be understood that integration of any of the communication subsystems104a . . . nwithin the device chassis itself is optional. Alternatively, one or more of the communication subsystem may be provided by a dongle or other peripheral device (not shown) connected to theelectronic device100, either wirelessly or by a fixed connection (for example, by a USB port) to provide theelectronic device100 with wireless communication capabilities. If provided onboard theelectronic device100, the communication subsystems104a . . . nmay be separate from, or integrated with, each other.
• Themain processor102 also interacts with additional subsystems (if present), the general configuration and implementation of which will be known to those skilled in the art, such as a Random Access Memory (RAM)106, aflash memory108, adisplay interface103 and optionally adisplay110, other data and memory access interfaces such as a visualization (graphics)processor125, auxiliary input/output systems112, one ormore data ports114, akeyboard116,speaker118,microphone120, haptics module122 (e.g., a driver and a vibratory component, such as a motor), GPS or otherlocation tracking module123, orientation and/or inertial navigation system (INS)module124, one or more cameras, indicated at126aand126bandother subsystems128. In some cases, zero, one or more of each of these various subsystems may be provided, and some subsystem functions may be provided by software, hardware, or a combination of both. For example, aphysical keyboard116 may not be provided integrated with thedevice100; instead a virtual keyboard may be implemented for thosedevices100 bearing touch screens, using software components executing at the device.Additional display interfaces103 ordisplays110 may be provided, as well as additional dedicated processors besides thevisualization processor125 to execute computations that would otherwise be executed by thehost processor102. Additional memory or storage modules, not shown inFIG. 1, may also be provided for storing data, which can contain flash memory modules as well. Examples include non-volatile memory cards such in the microSD and miniSD formats defined by the SD Association, San Ramon, Calif. Such storage modules may communicate with themobile device100 using a fixed or wireless connection.
• A visualization (graphics) processor ormodule125 may be included in theelectronic device100. Thevisualization module125 analyzes and processes data for presentation via thedisplay interface103 anddisplay110. Data originally prepared for visualization on a large-screen display may require additional processing prior to visualization on a small-screen display. This additional processing may be accomplished by thevisualization module125. As will be appreciated by those of skill in the art, the visualization module can be implemented in hardware, software, or a combination thereof, and can include a dedicated image processor and associated circuitry, or can be implemented withinmain processor102. Rendered data for painting to the display is provided to the display110 (whether thedisplay110 is external to thedevice100, or integrated) via thedisplay interface103.
• Content that is rendered for display may be obtained from a document such as a message, word processor document, webpage, or similar file, which is either obtained from memory at the device such asflash memory108 orRAM106, or obtained over a network connection. A suitable application, such as a messaging application, viewer application, or browser application, or other suitable application, can process and render the document for display in accordance with any formatting or stylistic directives included with the document.FIG. 1 illustrates possible components of thedevice100, such as theoperating system140 andprograms150, which can include zero, one or more applications such as those depicted. Other software components190 besides those explicitly illustrated inFIG. 1 can also be included, as is well known to those skilled in the art.Programs150 may be installed on thedevice100 during its manufacture or together with loading of theoperating system140, or at a subsequent time once thedevice100 is delivered to the user. These software applications may be supplied by the device manufacturer or operating system provider, or may be third party applications. The additional applications can be loaded onto thedevice100 through at least one of the communications subsystems104a . . . n, thedata port114, or any othersuitable device subsystem128.
• Example applications include anemail messaging application152, as well as other types of messaging applications for instant messaging (IM)154 and Short Message Service (SMS156). Other applications for messaging can be included as well, and multiple applications for each type of message format may be loaded onto thedevice100; there may be, for example, multipleemail messaging applications152 and multipleinstant messaging applications154, each associated with a different user account or server. Alternatively different applications may be provided to access the same set of messages or message types; for example, a unified message box function or application may be provided on thedevice100 that lists messages received at and/or sent from the device, regardless of message format or messaging account. Unified messaging or unified inbox applications and functions are discussed in further detail below. Other applications includesocial networking applications158, which may provide messaging function, a content reader function, or both;browser applications164;calendar applications160,task applications162 andmemo applications168, which may permit the user of thedevice100 to create or receive files or data items for use in personal organization;media applications170, which can include separate components for playback, recording and/or editing of audio files172 (including playlists), photographs174, andvideo files176;virtual machines180, which when executing provide discrete runtime environments for other code on thedevice100; “app store”applications182 for accessing vendor sites offering software applications for download (and optionally for purchase) to thedevice100; direct or peer-to-peer file sharing orsynchronization applications184 for managing transfer of files between thedevice100 and another device or server such as a synchronization or hosting service, using any suitable protocol; andother applications186. Applications may store data in the device's file system; however, a dedicated data store or data structure may be defined for each application.
• In some examples, theelectronic device100 may be a touchscreen-based device, in which the display no includes a touchscreen interface that provides both a display visual presentation of data and graphical user interfaces, and an input subsystem for detecting user input via a graphical user interface presented on thedisplay110 that may be converted to instructions for execution by thedevice100. Adisplay110 that is a touchscreen may be the principal user interface provided on theelectronic device100, in which case other user input mechanisms such as thekeyboard116 may not be present, although in some examples, akeyboard116 and/or additional buttons, a trackpad or other user interface mechanisms may still be provided.
• Generally, user interface (UI) mechanisms may be implemented at theelectronic device100 as hardware, software, or a combination of both hardware and software. Graphical user interfaces (GUIs), mentioned above, are implemented using thedisplay interface103 anddisplay100 and corresponding software executed at the device. Touch UIs are implemented using a touch sensing mechanism, such as the aforementioned trackpad and/or touchscreen interface, along with appropriate software used to convert touch information to signals or instructions. A voice or speech UI can be implemented using themicrophone120, together with modules implemented in hardware or software operable to detect speech patterns or other sounds, and to decode or correlate detected sounds to user commands. A tracking (e.g., eye-tracking or facial tracking) UI or perceptual UI can be implemented using thecamera126aand/or126b, again with appropriate hardware and/or software modules to analyze received visual data to detect the presence or position of a user's face or eyes, which are used to derive commands or contextual information to control device operations. A kinetic UI can be implemented using the device's orientation/INS module124, or using theGPS module123 or another locating technology module, together with appropriate software and/or hardware modules to detect the motion or position of theelectronic device100, again to derive commands or contextual information to control the device. Generally, the implementation of touch, voice, tracking/perceptual, and kinetic UIs will be understood by those skilled in the art.
• In touchscreen embodiments, thedisplay controller113 and/or theprocessor102 may detect a touch by any suitable contact member on the touch-sensitive display interface110 (references to the “display110” herein include a touchscreen display, for those electronic devices implemented with touchscreen interfaces). The configuration of the touchscreen display and display controller for detecting touches will be known to those skilled in the art. As only one example, the touchscreen display may be a capacitive touchscreen display with a capacitive touch-sensitive overlay having multiple layers including, for example, a substrate, a ground shield layer, a barrier layer, one or more capacitive touch sensor layers separated by a substrate or other barrier, and a cover. The capacitive touch sensor layers may be any suitable material, such as patterned indium tin oxide (ITO). Optionally, haptic or tactile feedback can be provided by thehaptics module122 in response to detected touches received through the touchscreen display, either through the housing of thedevice100, or through the touchscreen itself. The touchscreen sensors may be capable of detecting and supporting single-touch, multi-touch, or both single and multi-touch actions such as tap, double-tap, tap and hold, tap and drag, scroll, press, flick and pinch. A touchscreen enabled to detect only single-touch input is able to accurately identify only one point of contact on the display at a time. A multi-touch touchscreen is able to accurately identify two or more simultaneous contacts on the screen. The touchscreen display no detects these single and multi-touch actions, for example through the generation of a signal or signals in response to a detected contact, which may then be processed by theprocessor102 or by an additional processor or processors in thedevice100 to determine attributes of the touch event, such as the location of the touch action, whether defined by horizontal and vertical screen position data or other position data. The detected touch actions may then be correlated both to user commands and to an element or elements displayed on the display screen or view presented by thedisplay110. In response to the user command, the processor may take actions with respect to the identified element or elements. Touches that are capable of being detected may be made by various contact objects, such as thumbs, fingers, appendages, styli, pens, pointers and the like, although the selection of the appropriate contact object and its construction will depend on the type of touchscreen implemented on the device.
• The orientation/INS module124 can include one or more motion or tilt sensors capable of detecting gravity- or motion-induced forces to determine physical conditions of the device such as acceleration and angular velocity, which in turn can be used to determine the orientation or geometric attitude of themobile device100, or changes thereto, in two or three dimensions. Motion sensors can include an accelerometer for detection of linear motion, and a gyroscope for detection of rotational motion. The selection and implementation of suitable motion sensors will be understood by those skilled in the art.
• Although not shown inFIG. 1, theelectronic device100 may also include one or more proximity sensors which can be used to determine distance of thedevice100 from a surface. An example of a proximity sensor is a radiation sensor for detecting reflected radiation, such as infrared light, from a nearby surface. Such a sensor may typically be used in conjunction with voice or video communication functions on thedevice100 to determine when the user is present in front of or in close proximity to thedisplay110.
• Possible network topologies for use with thedevice100 will be known to those skilled in the art. As only one example, a host system may be provided, which can be an own-premises local area network (LAN), or wide area network in communication with LANs, with local computing resources such as one or more servers, data repositories and client devices such as terminals. The host system may comprise those components necessary to provide services to users over the LAN and also over a public or private network, such as the Internet, at theirrespective devices100. The services can include but are not limited to messaging, directory services, collaborative applications, calendaring applications, search engines and file servers. Thedevice100 could access the host system using one or more of its communication subsystems104a . . . n, for example through an access point, via the public or private network, and optionally via a public switched telephone network and a wireless network.
• As mentioned above, the typically smaller form factor of mobile devices (as compared to larger devices such as desktop or laptop computers, although it will be understood by those skilled in the art that the examples and embodiments presented herein can be implemented on desktop or laptop computers as well as other non-mobile computing devices) results in reduced size of its integrated display and greater challenges in presenting an effective graphical UI and options for physical interaction (via a touchscreen, pointing device, etc.). At the same time, although the overall storage capacity of a mobile device may not rival the capacity of a contemporary laptop or desktop computer, the mobile device may have just as many—or more—application programs and different types of data as a laptop or desktop computer. Given the easy availability of thousands of mobile device applications from online “app stores” and other distributors for modest cost, users of mobile devices may collect a large number of applications for their tablets and smartphones. It is therefore desirable to provide an effective means for the user to access specific applications or data of interest easily, without expending too much of the user's time—and the device's processing resources or battery life—locating the desired application or data.
• In view of the often-limited processing power and smaller screen size of the mobile device compared to desktop and laptop display panels, UI design on mobile devices has adopted some, but not necessarily all, elements of the desktop metaphor used for decades in personal computing. Applications available on a mobile device tend to be presented using icon representations arranged on a “homescreen” display containing arrays of icons representing the various applications. The homescreen can be considered to be a landing page, main display, or initial view of the mobile device's graphical UI much in the way the “desktop” is the initial view of the graphical UI of a personal computer executing an operating system presenting a windowed environment. The homescreen view (which, as discussed below, may comprise multiple stages) is typically generated and displayed by the operating system, and indeed, typically the initial view displayed by the mobile device on bootup or initialization is a homescreen view.
• An example of a view that may be displayed as a homescreen in amobile device100 is shown inFIG. 2. Example (a) shows afirst panel200a(also referred to as a “view”), which is a fullscreen view of a homescreen (also referred to as a “home display”) including a set ofgraphical UI elements220a. As is conventional in the art, these graphical UI elements are icons, i.e., elements of a pictorial nature such asicons221a, optionally displayed with accompanying text. Each of the graphical UI elements is associated with an entry point for a corresponding application. Actuation of a graphical UI element such as221a(e.g., by “clicking” or “tapping” on the element, or otherwise invoking a user interface event associated with the element using a touch UI, pointing device, keyboard or other user input mechanism) results in launch of the application, if the application is not already executing, and presentation of the application UI to the user according to the entry point identified by the graphical UI element; if the application is already executing, which may be the case in a multitasking or quasi-multitasking operating system, then the application UI is presented to the user in its most recently updated state. Thus, for example,icon225 may represent a messaging application such as email; actuation of thaticon225 will result in invocation of the corresponding messaging application, and display of its associated UI, which is typically a fullscreen display of one or more messages or a message listing.
• In this description, the meaning of “application” will be understood by those skilled in the art as meaning a software program distinct from the device operating system, generally directed to the accomplishment of a specific task or tasks, and including one or more components for interaction with a user. Typically the application includes at least one user interface for receiving user input, providing output or feedback to the user, or both. Given the dependence on graphical UIs in current mobile and personal computing environments, an application typically includes a graphical application UI for presentation to the user via the display no. In these examples, this UI may be referred to as the application “screen”, “panel”, “pane”, “stage”, or “view”.
• In this example, thefirst panel200a, together with a status area orbanner210, fills the entirety of the available display area of adisplay110. Regardless of the display area consumed by thestatus area210, thefirst panel200ais still considered to be a fullscreen view as it would be understood by those skilled in the art, as thepanel200aoccupies the remainder of the available area of the physical display no with the exception of any operating system “chrome” (UI elements that are substantially consistently displayed during device operation, such as frames, menus, status, task or navigation bars, and the like). In other examples, a fullscreen display may occupy the entirety of the display area of the display no when no status bar or other UI features are displayed. The status area orbanner210 can be used to display status or environmental information such as the current time, strength of the current network connection(s) and type of connection(s), and indicators of receipt of new messages such asicon212. A process executing in the background can update the information displayed in thebanner210. Not all of these features are necessarily displayed in thebanner210, and display of thebanner210 is not mandatory. In some implementations, thebanner210 is displayed consistently in the display no regardless of the current application or thread executing in the foreground (i.e., whether a homescreen is displayed or not); in other implementations, thebanner210 may not be displayed while an application (e.g., a messaging application, game, etc.) is executing, but thebanner210 is always displayed in a homescreen view.
• The set ofelements220aare arranged in an array in the example ofFIG. 2(a). In some examples, theelements220amay be arranged in a predetermined order, such as alphabetically, in order of addition to the homescreen, or in order of frequency of use; the order may alternatively be user-defined. In some cases, icons are automatically arranged to fill sequential positions in an array (e.g., left to right, from top to bottom of the screen) as in the example ofFIG. 2(a), but in some examples, the actual position or fill order of the icons may be customizable by the user, and need not be a regular arrangement such as a rectangular array. In the specific example ofFIG. 2(a), three visible positions in the array oficons220aare empty, as denoted byspaces222a. Graphical UI elements and their associated files are typically provided when an application or the operating system is installed or provisioned on themobile device100, and when the application is deleted from themobile device100, the corresponding graphical UI element is removed from the homescreen. In some cases, the graphical UI element files may include animations or alternative versions. Also, in some examples, notifiable events (e.g., receipt of a new message by a messaging application) may be indicated by a change to the icon, such as the addition of a badge and/or count number to the displayed icon on the homescreen, as in theexample icon225 and its associatedbadge226, which indicates that a new message has been received and is accessible by a messaging application represented by that icon.
• Not shown inFIG. 2, thepanel200amay also include a “dock” or permanent collection of icons representing favorite, frequently-accessed, or user-specified applications. The dock typically remains visible as long as themobile device100 is in a homescreen or home display mode, i.e. displaying screens at the same level as, belonging to, or associated with, the home display of the device. Also not shown inFIG. 2, icons may be organized in distinct collections or folders. The general configuration, organization, and display of a typical homescreen will be known to those skilled in the art.
• When there are too many icons to be displayed simultaneously within the currently displayable area of the homescreen, the user may need to scroll through the icons within the homescreen to view currently non-visible icons. Alternatively, or in combination with a scrolling feature, the homescreen may comprise multiple stages or panels. In a multiple-stage homescreen environment, the user can transition from a first panel to another to access additional icons, and can organize the icons on the multiple panels as desired. The transition from one view or panel to another may simply involve painting the next view to thedisplay110, or may include visual effects such as a slide effect (in which the current view is animated to appear to be sliding out of view at one side of the display no, and the next view appears to slide in at the opposite side). A slide effect is commonly used in conjunction with “swipe” touch gestures on a touchscreen device, in which the swipe gesture mimics a “pulling” of an adjacent but currently non-visible panel into view on the display no.FIG. 2(b) illustrates asecond panel200bof a multiple-stage homescreen. Thispanel200balso comprises an array ofgraphical UI elements220b; however, as can be seen in the figures, the number or arrangement of elements need not be the same as that in thefirst panel200aofFIG. 2(a), and again, arrangement of elements in thesecond panel200bwill be known to those skilled in the art.
• Navigation from a first panel to another panel in a multiple-stage homescreen can be accomplished using existing navigation techniques, such as a page next/previous button (e.g., a graphical user interface element displayed on screen that can be actuated to instruct the operating system to display a next panel of the multi-stage homescreen), designated keyboard keystrokes, or touch-based gestures such as a swipe gesture.FIG. 2 schematically illustrates the use of a touch-based gesture of a first type or class for changing the homescreen view from one panel to another while themobile device100 is a homescreen mode, i.e., a state in which homescreen views are displayed. As noted above, the embodiments and examples provided herein are described with reference to a touchscreen device, but these embodiments and examples can, with suitable modification known to those skilled in the art, be adapted for non-touchscreen devices.
• As can be seen by the arrows and theschematic gesture illustrations250aand250b, a first swipe gesture across the display110 (i.e., a touchscreen display) is interpreted by the device operating system and appropriate UI modules as an instruction to change views within the homescreen to a subsequent view selected according to the direction of the swipe gesture. The swipe gesture in this case can be considered to be a navigation command that is also directional, since the gesture itself includes a directional component. As can be seen in250a, the associated swipe gesture involves a touch on thedisplay110 by a contact point (e.g., the user's thumb or finger) as indicated by252a, and while contact is maintained on the display screen, the touch is swiped across the screen generally in the direction that the user wishes to indicate, as shown by this example asarrow254a. In theexample gesture250a, the direction of motion of the swipe is substantially parallel to axis α, which designates a major axis of thedisplay110. The device operating system and/or touch UI module may be adapted to interpret swipes that are angled away from the axis α but still include a substantial component parallel to the axis α as agesture250a, thus compensating for user inaccuracy in performing the swipe gesture. In response to detection of this first directional command while thefirst panel200aof the homescreen is displayed, the processor of themobile device100 displays thesecond panel200b.
• Similarly, a directional navigation command may be used to change the homescreen display back to theoriginal panel200a. In the example ofFIG. 2, thisgesture250bis the same as thefirst gesture250a, but is in the opposite direction, as indicated by thecontact point252band direction of the swipe indicated by thearrow254b. Thesegestures250a,250bcan thus be analogized to a directional “next page” or “previous page” command. These two directional navigation commands250aand250b, being of a similar type (in this case, both are a swipe gesture in a direction generally parallel to the same axis a of the display110), may be considered to both be input navigation commands of a first type or class. Repeated application of these particular navigation commands while the mobile device1900 is in the homescreen mode can be interpreted by the processor as commands to page through or cycle through a plurality of panels or views within the multiple-stage homescreen in a sequence determined by the direction of the command.
• The example ofFIG. 2 illustrates a relatively simple multiple-stage homescreen comprising only two panels or panes comprising icons. In some examples, the homescreen may include three, four, or more panels. The maximum number of panels may be fixed by a setting in the operating system, or may be user-configurable. The same first class or type of navigation command may be used to navigate from one panel to another within the homescreen. Turning toFIG. 3(a) through (d), an example of a four-panel homescreen is shown. The first twopanels300aand300bare similar topanels200aand200bofFIG. 2, whileadditional panels300cand300dare also provided, in this example again with various icons representative of different applications provisioned on themobile device100.Arrows310,320 and330 illustrate a possible navigation flow from one panel to another; as can be seen inFIG. 3, these arrows are bidirectional; thus, in response to a navigation command of the first type, the homescreen display may be sequentially navigable from thefirst panel300ato the second300b, and thence to the third300c, and back to the second300b. In this example, there is a defined sequence to the multiple stages or panels of the homescreen from300ato300d, and back. In some examples, the sequence may in fact be cyclical, and in response to the same class of navigation command, the homescreen display may be sequentially navigable frompanel300dtopanel300aand back, as indicated byphantom arrow340.
• Other directional navigation commands of different types (for example, swipe gestures in a direction perpendicular to thegestures250a,250bdescribed above) may be used to invoke different functions in the homescreen mode. For example, an upwards swipe on atouchscreen display110 while in homescreen mode may invoke a multitasking pane or a notification bar.
• Different classes of navigation commands may be input to navigate among the homescreen views and application views. For example, in a touchscreen-based embodiment, a simple touch input may be used to actuate an icon displayed in a homescreen view, which in turn invokes a corresponding application on thedevice100. Invocation of an application may include launching the application, or, if the application is already executing on the device in a background process or was previously executing and is now in a suspended state, increasing the priority of the application's processes or resuming execution of the application. This is illustrated inFIG. 4, in which anicon430 displayed in ahomescreen panel400ais actuated, as indicated schematically by thecontact point452 overlaying the position of theicon430 in touchscreen display no. The result is a display of a view of thecorresponding application400bin place of theinitial homescreen view400a. In this example, the type of navigation command used to invoke the application—a touch event—is distinct from the type of navigation command—a swipe gesture—used to page between one homescreen view and another. This second type of navigation command illustrated inFIG. 4 thus causes themobile device100 to transition from the homescreen mode, in which a homescreen panel is displayed, to an application mode or execution mode in which an application is executed in the foreground.
• If themobile device100 is adapted for multitasking, then more than one application may be launched without a previously launched application being terminated, and consequently more than one application view may be maintained in memory. How multitasking is accomplished varies according to the device operating system and the device's processing and memory capabilities. Techniques for implementing multitasking and sharing resources among applications in mobile computing environments will be known to those in the art; it is sufficient for the purpose of these examples to note that “multitasking” applications, in this context, includes “true” multitasking in which applications can execute unrestricted in the background; limited multitasking in which applications may register a thread with limited functionality and resources to run in the background; and simulated multitasking, where applications enter a suspended or inert state in which application data is maintained in memory, but execution of the application processes or threads is halted when themobile device100 returns to the homescreen mode or another application is invoked. W
• When an application is executing in the foreground and one of its views is displayed to the user, the navigation commands applied in the homescreen mode may have different results when invoked in the application. For example, as shown inFIG. 5, the first class of navigation command (in this example, the class including swipe gestures250aand250b) can be used while in the application mode to transition between views associated with different applications. InFIG. 5(a), afirst application view500a, in this example a messaging application, can be transitioned to asecond view500bfor a different application, in this case a game inFIG. 5(b).
• When in the application mode, themobile device100 may be returned to the homescreen mode through actuation of yet another command, such as actuation of a “home” button or other input mechanism (not shown), which is typically a physical mechanism, or selection of a menu option. If themobile device100 is capable of multitasking, thedevice100 may then save the current application state, view and associated data in memory for later retrieval.
• FIG. 6 illustrates the interrelationship between the homescreen mode and the application mode, and the associated types of navigation commands that may be used to navigate between them in this example. Themobile device100 may be configured to display, while in the homescreen mode, a multiple-stage homescreen, comprising a number of panels such aspanels610a,610band610c. Navigation from one panel to another may be accomplished as described above, through use of a directional command of a first type such as a swipe gesture, as indicated by the bidirectional solid arrows (refer to the legend inFIG. 6). Themobile device100 may also be configured to display one or more application views620a,620b,620cin an application or execution mode, and again, navigation from one application view to another may also be carried out in response to directional commands of the first type, again as indicated by the bidirectional solid arrows shown inFIG. 6. In this example, one such application view620 may be a view for a messaging application.
• However, themobile device100 might be configured such that navigation from the homescreen mode to the application mode using this first type of directional command is not possible. Instead, to invoke the application mode from the homescreen mode, a different type of command input is required, such as the aforementioned touch event on an icon of the homescreen. This is indicated by the first dashed arrows indicating the second class of navigation command betweenicon615aandcorresponding application view620a;icon615bandapplication view620b; andicon615candapplication view620c. Actuation of one of these icons invokes the corresponding application, thus causing themobile device100 to exit the homescreen mode and enter application mode. This second class of navigation is, effectively, one-way and not bidirectional like the first class of navigation command. To return from application mode to the homescreen mode—in other words, to dismiss the current application view and return to a display of a homescreen panel—a different type of navigation command is required, such as actuation of the home button or some other option, as indicated by the broken arrows corresponding to the third class of navigation command. Again, this type of navigation command is effectively one-way and not bidirectional.
• In short, changing the current mode from homescreen mode to application mode, or changing the currently displayed view from a homescreen panel to a particular application view, or from a particular application view back to the homescreen panel, involves the use of disparate navigation commands, some of which may be functionally different (e.g., a touch event detected by a touchscreen versus actuation of physical button on the device, or a swipe gesture detected by a touchscreen versus a tap on an icon detected by the touchscreen), and some of which may be functionally similar but have specific constraints depending on the current device mode (e.g., a swipe gesture detected while in homescreen mode results in display of a homescreen panel, but the same swipe gesture detected in application mode does not display a homescreen panel).
• Further, some applications or functions on amobile device100 may be more frequently used than others. For instance, messaging functions (email, IM, and SMS in particular) are generally popular and are frequently used by many users. Thus, a user may tend to repeatedly invoke a messaging application to check for current messages. On a mobile device provisioned with many applications (and thus many icons over a plurality of homescreen panels), locating the correct icon to invoke the desired messaging application may require paging through multiple views, and then invocation of the messaging application will result in increased consumption of processing resources.
• Therefore, a multiple-stage homescreen may be adapted to include a view of an application or a view for a frequently-accessed function, thus effectively incorporating a fullscreen application view normally available in the application mode only into the homescreen mode. An illustration of this adaptation is shown inFIGS. 7(a) and (b). These illustrations depict two instances of a multiple-stage homescreen700a,700b, each of which contains a series of homescreen panels. In these figures, the panels are positioned immediately adjacent to each other in a continuous “filmstrip”-type schematic, which is representative of the perceived continuity of thehomescreen700a,700bwhen the user navigates from one panel to the other. It will be appreciated by those skilled in the art that typically, only a single one of these panels (e.g., only710a, only712a, only714a, etc.) is displayed at a time by themobile device100. It may be observed that in the examples depicted in the accompanying drawings, the homescreen panels are arranged horizontally, in a row; however, in other examples that may be implemented with the various features described herein, homescreen panels may be arranged in a vertical (columnar) relationship. In such implementations, of course, the first type of navigation command may be a vertically-oriented swipe gesture rather than the horizontally-orientedgesture250a,250bdescribed above.
• While two panels in the example of7(a) (namely,panels712aand714a) include typical launchpad-style arrangements of icons, a first one of these panels,710a, comprises a message inbox view. This inbox view may be a unified or universal view, which includes messages for different accounts provisioned on the device, and/or for different message types or services, including email, IM, SMS, social messages, and the like. The operation of a unified messaging application or unified messaging function is discussed in further detail below.
• Visual navigation guides may be included in the various homescreen panels to indicate to the user which part of the homescreen is currently being displayed. A set ofvisual elements720a, for instance, may be provided on each panel as a navigation guide. The set720aincludes an icon or graphic for each panel in the homescreen; thus, inFIG. 7(a),visual elements722a,724aand726arepresent the three panels in thehomescreen700a. The visual element corresponding to the panel currently being displayed may be visually distinguished form the other visual elements. Thus, for example, inpanel710a, the first element—theenvelope722a—is shaded, while the remainingelements724aand726aare not. Inpanel714a, which is the last panel in the order illustrated inFIG. 7(a), thelast element726awould be visually distinguished from the first twoelements722a,724a. Further, in this example, theicon722ain fact is shaped or otherwise presented to be indicative of the corresponding type of view included in the homescreen; in the example ofFIG. 7(a), theicon722ais therefore shaped like an envelope to represent theinbox view710a.
• In a further example, when at least one application is launched and executing in a multitasking mode (for example, in the background, at a reduced priority, or in a suspended mode but still present in memory), a further multitasking panel is inserted in the homescreen. This is illustrated inFIG. 7(b).Panels712b,714bmay generally correspond topanels712a,714aofFIG. 7(a), but also included in thehomescreen700bis afurther multitasking panel711b. Themultitasking panel711bmay display reduced-size views (i.e., less than fullscreen size views) of currently multitasking applications on themobile device100. Thus, in the example ofFIG. 7(b), one application is indicated as executing on themobile device100, as there is only one reduced-size view730 present in thepanel711b.
• When themultitasking panel711bis included in thehomescreen700b, the set of visualnavigation guide elements720bis therefore altered accordingly to reflect the insertion of themultitasking panel711bin the set of homescreen panels. Thus, as can be seen inFIG. 7(b), theset720bnow includes the first element representing theinbox view722b; a second icon or element representing themultitasking panel724b; andfurther elements726b,728brepresenting the other launchpad-style panels712b,714b. When no applications are executing on themobile device100, themultitasking navigation element724bcan be removed from the homescreen displays. In these examples, the application or process providing the inbox view inpanel710a,710bis excluded from the multitasking pane, since it is provided with itsown navigation element722a,722b; indeed, if the inbox view is actually provided by an operating system process, then it may not be considered to be a distinct “application”. In other examples, not shown here, thenavigation element724brepresentative of themultitasking panel711bmay be altered to reflect a current status of the currently executing multitasking applications on themobile device100, for example, theelement724bmay indicate a count of the number of multitasking applications executing on thedevice100. Of course, in this example and all others discussed herein, the number of launchpad-type panels may be varied; there may be only one, or more than two. Further, the order of the various inbox and multitasking panels within the homescreen need not follow the order illustrated here.
• Since the message inbox view is included as a panel within the multiple-stage homescreen, it will be available in the homescreen mode, and thus the user may navigate to the message inbox view panel using the same type of navigation used to navigate between other panels of the homescreen.FIG. 8(a) to (d) illustrates navigation schematically, again using swipe gestures as a directional navigation command for paging from one homescreen panel to another. In this example, the panels are shown in portrait mode, but it will of course be appreciated that this may be implemented in landscape mode as well, as shown inFIGS. 2-5.
• Generally, as those skilled in the art will appreciate, mobile devices—especially those provided with touchscreen displays—can be provided with an orientation module for detecting the current orientation of the device (e.g., either “portrait” or “landscape”, as those terms are understood by those skilled in the art), and in response to a change in orientation, the device may be configured to reformat, re-layout, or scale displayed content to better fit the dimensions of the display screen in the new orientation. Predefined alternative layouts may be stored at the device, or the device may be configured to alter displayed content on the fly in response to a detected orientation change. Thus, the user may be holding the device in portrait mode while navigating from one panel to another, but rotate the device while still in homescreen mode. In response, the operating system would redraw the currently displayed homescreen panel in the landscape-friendly layout. The user may continue to navigate between panels as before, for example with swipe gestures as described above with regard toFIG. 2. Although the device has been re-oriented with respect to the user, typically the direction of the directional navigation commands used to navigate from panel to panel in homescreen mode will remain the same with respect to the user. This is illustrated inFIG. 8 byexample swipe gesture250b′, which includes a directional component substantially parallel to axis b of the device, which is perpendicular to axis a also illustrated inFIG. 8.Gestures250band250b′, and250aand the corresponding gesture to250awhen the device is rotated to the other orientation (not illustrated inFIG. 8), are thus considered to be input navigation commands of the same type or class, since their directionality is the same with respect to the user. While sequences of panels illustrated in the accompanying drawings have the same orientation throughout the sequence, it will be understood that their orientation may change during the sequence and that the examples and embodiments herein include such variations.
• Thus, inFIG. 8, navigation may be accomplished from the firstmessage inbox panel800a, to thesecond multitasking panel800b, to thefirst launchpad panel800c, to thesecond launchpad panel800d, using only one type of gesture such as250a, discussed above. Similarly, navigation back from800dto800acan be easily accomplished using another gesture such as250b, also of the same type asgesture250a, as discussed above.
• Accordingly, there is no need to invoke a different class of gesture (such as a tap on an icon or actuation of a physical button) in order to view a message inbox, or to leave the homescreen mode at all. In those embodiments where the message inbox is also provisioned as a distinct messaging application on the mobile device, this adapted homescreen may thus provide an alternative method for accessing the messaging application UI; it may be invoked either by navigating the homescreen while in homescreen mode, or else it may be invoked by actuating the corresponding icon provided for the messaging application on one of the launchpad views.
• In some instances, the message inbox panel may be provided by an operating system process, rather than by a distinct application process, thus avoiding the need to launch a full messaging application on themobile device100. Thus, the adapted homescreen alone provides access to this message inbox view. In either case—whether the message inbox panel is provided by a messaging application or as an operating system process—the message inbox panel may be launched on startup or initialization of themobile device100, just as the other homescreen panels are launched on startup. If the frequently-accessed function or other view that is supplied as part of the multiple-stage homescreen is not a message inbox, but is some other function supplied by a different application, that application may likewise be launched on startup of thedevice100 so that its view is included as part of the homescreen.
• FIG. 9(a) to (d) illustrate another example of an adapted multiple-stage homescreen. In this example, the homescreen includes asearch panel900a, as well as a message inbox panel good; the remaining launchpad-type panels900b,900care sandwiched between them. This example may be combined with the example ofFIG. 8 including a multitasking panel, although not illustrated here. Again, as withFIG. 8, the same first type of directional navigation command—gestures250aand250b—can be used to navigate between the various panels of the homescreen while in homescreen mode.
• The schematic ofFIG. 10 illustrates the interrelationship between the homescreen, in which an adapted multiple-stagehomescreen comprising panels1010a,1010band1010cis displayable, and the application, in which one or more ofapplication screens1020a,1020b,1020cmay be displayed. In this example,homescreen panels1010band1010cmay be typical launchpad-type panels bearing a number of icons for applications provisioned on themobile device100. Again, while a panel of the homescreen is displayed, navigation from onehomescreen panel1010a,1010b,1010cto another may be carried out in response to input navigation commands of a first type or class, as discussed above, and as indicated by solid arrows inFIG. 10. Similarly, in the application mode, navigation from one view of a multitasking application to another may be carried out in response to input navigation commands of the same type or class. In this case, however, one of the panels of the homescreen,panel1010a, is a message inbox view. Thus, it is not necessary to enter application mode to display the message inbox view. As before, entry into the application mode may be accomplished by input of a different class of navigation command, for example by actuating anicon1015a,1015b,1015c, thus invoking an application; and return from the application mode to the homescreen mode may be accomplished by a further class of navigation command, such as actuation of a physical home button.
• In some instances, as discussed below, the message inbox view may comprise a listing of messages for a variety of messaging accounts or services, and to view the content of a particular message, a graphical UI element representing that message in the listing may be selected and actuated to invoke an application associated with that specific message type or account. Thus, as indicated byarrow1030, themessage inbox panel1010amay also provide a means for entry into the application mode, just like those launchpad-type homescreen panels1010b,1010c.
• Themessage inbox view1010ais so called since it functions as a form of message inbox, listing messages received at thedevice100. However, as those skilled in the art will understand, “inbox” can include messages that are sent from the device as well as those received from the device, and can also include drafts and other messages that are not received at the device or stored in a received message folder or an inbox data store. Further, themessage inbox view1010amay be a unified inbox or unified message listing, comprising messages for more than one messaging format or service, and/or for more than one messaging account for a given message type. Themobile device100 may be provisioned for a single or for multiple messaging accounts and be configured to employ one or more messaging formats. For example, the user may wish to send and receive messages using multiple accounts provided by a single service provider, access multiple services operating over the same or different networks to send and receive messages in different formats, or access multiple services providing messages in the same communication format. Typically, messages associated with different accounts, services and/or formats are stored in distinct data stores, folders or files at themobile device100. For example, each message item received or generated at themobile device100 in association with a given service (such as email) can be stored as a separate message or data object in a data store associated with the service, retrievable for presentation to the user using a dedicated application executing at themobile device100 and associated with that particular message, service, or content format. These dedicated applications may be invoked using corresponding icons provided on the homescreen.
• For convenience, however, message objects may be indexed for retrieval on themobile device100 through unified search or collection process implemented in the device operating system, or through another application or process for presentation of message listings or message content. An example of this is the aforementioned unified inbox or unified message listing, which presents to the user a global message list. A unified message listing or unified inbox view can provide entry points for access to individual messaging services or to individual messaging applications associated with each of the message types including in the unified inbox. The message or content elements displayed in the unified inbox display may include, in the case of messages such as email, header data such as sender, timestamp, and subject line. In addition, or alternatively, at least a portion of the message body content may also be displayed in the unified inbox. In the case of other message types, such as instant messages, the information displayed may include message body content in place of message header data.
• FIG. 11 provides a more detailed illustration of a possible arrangement of a unified message view or application on themobile device100, and its relationship with disparate message stores and other applications provided on thedevice100. Thedevice100 may be provided with dedicatedmessaging client applications1150c,1150b, for example email applications, IM applications, SMS applications, and the like, as well as a unified inbox application orunified inbox process1150a. One or more message data stores are also maintained on either themobile device100, or else remotely from themobile device100. Typically, with amobile device100, message data stores are maintained at the device itself, although the data stores at the device may represent only a portion of the complete message data stored in association with a given messaging account. When themobile device100 is configured to support a number of message formats, message data may be stored in a number of distinct data stores, includingemail stores1120aand1120b,IM store1140,SMS store1142, PIN message (messages addressed using a personal identification number rather than an email address or telephone number)store1144,MMS store1146, andVVM store1148. There may be more than one store of a given message type, which may be associated with different user accounts or different service providers. Thus, there can be more than one message application for a given message format. The various message applications can obtain data from their respective data stores.
• A given message store, such as theemail store1120a, may include a number of folders such as aninbox folder1122, which may be a default folder specified for all incoming messages received at the electronic device100 (although, as explained above, the term “inbox” in relation to an application such as a unified inbox application or other messaging app need not be so restrictive), or at an online service or the host system on behalf of a user account theelectronic device100; a sentfolder1126, anoutbox folder1124 for those messages in the process of being transmitted; a deletedfolder1128; and other user-defined folders1130. Implementation of message “folders”—whether by means of an explicitly-set flag value, inclusion of a message in a particular file or physical location, and the like, will be understood by those skilled in the art, and all such examples are contemplated herein. The various message stores comprise a set of data sources that may be directly accessed by their corresponding dedicated messaging applications, as shown inFIG. 11; however, the unified inbox application or process may also register a listener for each data store of interest, and receive notifications from each store upon a change (such as storage of a new message in the message store or an update to the status of an existing message). For convenience, a unifiedmessage collection object1170 can be defined to create an aggregate master index of references for any messages stored in one of the message stores. An example of such an object is identified in U.S. Pat. No. 7,568,011, issued Jul. 28, 2009, the entirety of which is incorporated herein by reference. The unified collection is then provided to the unified inbox process orapplication1150a, and this latter process or application then identifies from the collection those messages to be displayed in the unified inbox view, and retrieves relevant message data (e.g., header data such as subject line, sender/recipient, timestamp) for those messages directly from the corresponding message store. The unified inbox application orprocess1150athen generates a message listing display using techniques known in the art.
• One or more filter or search collection objects1172,1174 defined with reference to one or more filter criteria (such as specific message attributes, header values, and keywords) to define a filtered collection of messages based on the unifiedmessage collection object1170 may also be provided. Further, messages presented in a message listing such as the unified inbox view may be presented in a “grouped”, “conversation” or “threaded” mode, in which messages identified as belonging to a common thread are grouped together and presented in a single entry in message listing. Accessing one of these single entries then invokes a further individual message list view in which the messages identified as belonging to that thread are displayed. The categorization or grouping of messages may be carried out using a variety of different rules and heuristics, many of which are known in the art. An example of determining thread membership is described in U.S. patent application Ser. No. 13/025,822 filed on Feb. 11, 2011, the entirety of which is incorporated herein by reference.
• The unified inbox view presented as part of the multiple-stage homescreen may take any one of a number of formats. A first example is theunified inbox view1200 ofFIG. 12, comprising mainly of amessage listing1210 for a variety of different messages types and accounts. This view presents a simple, reverse-chronological list of message entries, each entry corresponding to a particular message. Thus, for instance,message entry1212 represents an email message received using a first email account provisioned on themobile device100, andmessage entry1214 represents an instant message received at or sent from themobile device100. In this example, the unified inbox view also provides a series of application entry points for the dedicated messaging applications corresponding to each message. Thus, when the user wishes to read one of the messages listed in theview1200, the corresponding message entry can be actuated (e.g., tapped, clicked, etc.) to invoke the corresponding dedicated application, which will then retrieve and display the message content of that message. Thus, the unified inbox view provides an alternative to locating an icon associated with the dedicated messaging application elsewhere on the homescreen simply to launch the messaging application.
• As another example, the unified inbox view included in the multiple-stage homescreen may provide a preview of message content, so that invocation of the corresponding dedicated messaging application is not necessary. Turning toFIG. 13A, afirst messaging view1300ais shown. This view includes amessage listing1310 as well as aviewing region1320, for displaying content from a message or message thread selected from themessage listing1310. In the example ofFIG. 13A,message thread1350 has been selected, as indicated byhighlight region1360; thus, the content displayed in theviewing region1320 is taken from one or more messages from themessage thread1350. In some examples, thisviewing region1320 is merely a preview region, in that the display of message content taken from a new message in theregion1320 does not result in that new message being marked opened or read. For the message to be marked open or read, it must still be retrieved and displayed by the dedicated messaging application associated with that message account or type. (Terms such as “new”, “opened” and “read” take their commonly understood meanings, as known to those skilled in the art; thus, a message that is opened or read is no longer new, but the fact that a message is marked opened or read does not mean that the user has necessarily perused the message's contents.)
• As a further example, the unified inbox view may be configured to also receive data for preparing and transmitting reply messages or new messages. This option is also shown inFIG. 13A, in which theviewing region1320 also includes areply input field1330 and an accompanying send button orUI element1340. Content input in thereply input field1330 is then used to construct a reply message to the selected message in themessage listing1310 whose content is displayed in theviewing region1320, or alternatively, when the entry selected in themessage listing1310 is a message thread, to a selected message of the selected message thread (such as the most recently received message). Examples of the changes resulting in themessaging view1300aare shown inFIGS. 13B and 13C. Thus, inFIG. 13B, content has been entered in thereply input field1330 ofmessaging view1300b. Once thesend button1340 is actuated, thus invoking a command to construct and send a reply message to the last message received in the displayed thread, the entered content is inserted in a message body, and the message addressed to the sender of the last message as appropriate, and the message transmitted from thedevice100. The actual construction and transmission of the message may be carried out by the dedicated messaging application associated with the user's account that had received the message being replied to, or associated with the selected message type. Thus, in this example of a messaging view which forms part of the homescreen, themobile device100, while in the homescreen mode, passes data to a messaging application executing in the background, and the messaging application, executing in the background, prepares and transmits the message.
• The result of transmission of the message is reflected in thefurther message view1300cofFIG. 13C. Here, thereply input field1330 has been cleared, and theviewing region1320 now includes the content previously entered in thefield1330 inFIG. 13B. Further, the message listing has been updated such thatmessage thread1350 has been promoted to the highest position (since its timestamp is now the most recent). The updates to the message listing may be obtained dynamically by the unified inbox application orprocess1150aas new message data arrives in theunified message collection1170 as a result of the transmission of the message and its storage in one of the various message stores on themobile device100.
• A fuller description of the configuration and operation of a message inbox view comprising a reply input field is provided in U.S. patent application Ser. No. 13/536,508 filed 28 Jun. 2012, the entirety of which is incorporated herein by reference. In other examples, the homescreen does not include a unified inbox view, but rather comprises a dedicated message view (e.g., a view of only email message listings). In still other examples which may also be implemented in conjunction with a dedicated message view and not only the unified message view, rather than a singlereply input field1330, the unified inbox view or other messaging view included in the multiple-stage homescreen includes a full message composition interface, such that the user may input not only message content, but also addressees, subject line, and other appropriate message data, and send the message while still in the homescreen mode. In this case, the message data may still be passed to a dedicated one of the messaging applications executing on the device to prepare and send them message.
• FIG. 14 provides an overview of a method for presenting the unified inbox or other messaging panel in the multiple-stage homescreen. At1405, a first panel of the homescreen is displayed. At1410, an input navigation instruction is detected. This navigation instruction may be of the first type discussed above (e.g., a directional navigation command to display an adjacent one of the homescreen panels), or it may be of another type (e.g. actuation of an icon or other UI element to invoke an application or some other process on the device100). At1415, it is determined what type of navigation instruction has been input. If it is of the first type—i.e., a command to display another one of the homescreen panels—then at1420, a next one of the homescreen panels is displayed. In this example, it is presumed that this next panel is the messaging panel of the homescreen. If, on the other hand, the navigation instruction is not of the first type, an appropriate response to the input instruction is generated instead at1440.
• While the messaging panel is displayed, a further navigation instruction may be detected at1425. Again, a determination is made whether the received instruction is of the same type, in which case a next one of the homescreen panels (which may be the first homescreen panel of step1405) is displayed. Themobile device100 then awaits a further navigation instruction at1410. If, on the other hand, the further navigation instruction detected at1425 is not of the first type, but is a different type of command (e.g., a command to invoke a dedicated messaging application, or a command to send a message input at the messaging panel), then that appropriate response is generated by themobile device100 at1440.
• In still a further embodiment, the unified inbox or other messaging panel of the homescreen is protected with a screen or display lock and/or password. When a navigation command is received while in the homescreen mode to change the homescreen display to the unified inbox panel, rather than immediately displaying the unified inbox panel, an intermediate panel is displayed. The intermediate panel may require input of an unlocking input, such as a previously-defined gesture input, a password, a personal identification number, or other type of credential, for the unified inbox panel to be displayed. In this manner, the intermediate panel provides a level of security for the inbox panel without imposing the same level of security on the remainder of the homescreen panels. For example, if the user provides the mobile device for a guest user to use, the guest user can still be free to access other functions of the mobile device (e.g. other applications, voice communication, camera functions, etc.) via the homescreen, but will not be able to access the inbox panel of the homescreen, where potentially sensitive data is displayed.
• Alternatively, the intermediate panel may not require credentials, but might instead require an unlocking input comprising some non-secure confirmatory action (e.g. unlocking a slide lock or a confirmatory tap or double-tap) before displaying the inbox panel. In that case, the intermediate panel will effectively function as a privacy guard or “speed bump”, reducing the likelihood of inadvertent display or manipulation of message data in the event the user unintentionally navigates through the homescreen panels to the unified inbox panel. For example, in the event the user is over-enthusiastic in “swiping” his or her way through the homescreen panels using swipe gestures, he or she may navigate to the inbox panel without realizing it, then continue swiping and thus inadvertently select a message and perform a gesture command on it, such as viewing, deleting, replying, etc. The intermediate panel, however, “interrupts” navigation through the homescreen (as it does in the more secure credential-based implementation mentioned above), thus preventing inadvertent navigation through the inbox panel. In the case where the device is provided to a guest user, even if the inbox panel is not secured as above, the interruption provided by the intermediate panel may serve as a reminder to the guest user to observe proper etiquette and to avoid viewing the user's inbox messages. As will be seen in the examples below, the intermediate panel may be a distinct panel from the inbox panel, or it may be incorporated into the inbox display.
• A first example is shown inFIG. 15, which illustrates navigation between consecutive panels of a multiple-stage homescreen. Navigation from the launchpad-type panel1500cof the homescreen to another launchpad-type panel1500bmay be accomplished using a typical navigation command, such as theswipe gesture250aor250b. However, when navigating from one of the homescreen panels to the unified inbox panel, a lock orpassword panel1500ais displayed rather than the unified inbox. In the example ofFIG. 15, thispanel1500ais a password panel. To switch to the unified inbox panel, the user must correctly input the requisite password, personal identification number, or other credential. Upon successful entry of the password, theactual inbox panel1500a′ is displayed. In other examples implemented on a touchscreen device, the credential may be a gesture input or sequence of touch inputs rather than a typed password or other sequence of alphanumeric characters.
• When the user is finished with theunified inbox panel1500a′, the same class of navigation command (e.g., aswipe gesture250a) may be used to switch back to another panel of the multiple-stage homescreen. However, in this case, the navigation flow may bypass the lock orpassword panel1500a, and return directly to theprevious homescreen panel1500b. In other embodiments, though, the navigation flow may still include the lock orpassword panel1500a. A password-based implementation such as that ofFIG. 15 thus provides a level of security as well as privacy; although various applications can still be accessed via the unlocked portions of the homescreen (such aspanels1500band1500c), message content cannot be accessed without the password. In some implementations, theunified inbox panel1500a′ may be the only entry point provided on themobile device100 to access any messaging functions at all, so message data cannot be accessed using other homescreen panels or icons, with the exception in some examples of a notification window or panel displaying recent events (e.g. device alerts and/or recent new messages). In other embodiments, a unified inbox icon may be provided on another homescreen panel, but actuation of that icon simply displays the unified inbox panel, if unlocked (as in the examples ofFIGS. 8 and 9) or thelock panel1500a(as in the example ofFIG. 15). In other implementations, though, dedicated messaging applications may still be available to be accessed on themobile device100; optionally, these individual messaging applications may be secured with their own passwords (e.g., the user credentials associated with the messaging accounts for which those applications are provided). This security or privacy feature of theunified inbox panel1500a′ may optionally be set (including setting the password or code) or disabled through user- or administrator-alterable settings.
• Other variants of the lock or password panel are illustrated inFIGS. 16(a) to (c). In theexample panel1600aofFIG. 16(a), a lock panel is displayed including anoptional notification1610aindicating that the access to the panel is locked. Unlocking of the unified inbox panel merely requires a simple touch or other simple (i.e., non-password or code) input. Simply tapping thepanel1600a(e.g., in the area of thenotification1610a) would then result in theunified inbox panel1500a′ being displayed. (Althoughpanels1600aand1500a′ are shown in different screen orientations, it will be understood by those skilled in the art that these various views may of course be adapted for either orientation.)
• In the example ofFIG. 16(a), the message inbox contents may still be visible even though the inbox panel is locked. In a simple implementation, the inbox panel being “locked” means that further interaction with the inbox—for example, to select a message or view a message—requires some confirmatory action input while thepanel1600ais displayed. All other input events except for navigation to another homescreen panel may be disabled until the confirmatory action is received. Upon receipt of the confirmatory action, thenotification1610ais dismissed (if it was displayed), and any other input events detected by the device will be processed. In other implementations, the inbox contents may be displayed, but obfuscated (e.g., blurred, displayed with lower contrast, overlaid with a partially-transparent image).
• As another example, a touch slide lock is provided on the intermediate panel, as shown in thepanel1600bofFIG. 16(b). The slide lock is “unlocked” by an input swipe gesture applied to the slide lock user interface element, usually in a direction specified by the element. Touch-based slide locks of this kind are known in the art. While this input is simple and does not require input of a more complex password or code, the deliberate swiping action required to reveal theunified inbox panel1500a′ decreases the likelihood that the unified inbox will be inadvertently revealed. This likelihood may be decreased still further if the slide lock may be oriented so that the requisite swipe gesture to “unlock” the slide lock is different from a swipe gesture used to navigate from panel to panel in the homescreen mode, as shown inFIG. 16(b) (if it is assumed that navigation between panels is horizontal, while the slide lock is oriented vertically). Furthermore, either the simple touch-lock panel1600aor theslide lock panel1600b, or any other similarly simple mechanism, may be combined with thepassword panel1600c, as indicated by the arrows inFIG. 16; in response to the unlocking of an initialintermediate panel1600aor1600b, themobile device100 subsequently displays theintermediate password panel1600cas shown inFIG. 16(c), and the correct password or other code must be input before access to the unified inbox panel is granted.
• FIG. 17 illustrates a method implementing the lock or password panel ofFIG. 15. At1705, the first homescreen panel is displayed. This may be, for instance,panel1500b. At1710, a navigation instruction is detected. If it is determined at1715 not to be of the first type (i.e., not a command to navigate to another panel of the homescreen, and specifically the unified inbox panel), then an appropriate response is generated at1740. If it is of the first type, then at1720, the lock or password panel is displayed and input is awaited. At1725, that input is detected. If it is determined at1730 that the input was correct (e.g., in the case of a password entry, that the password matches a predetermined or previously-stored password; in the case of a simple lock mechanism, that the appropriate gesture or input was received), then at1735 the unified inbox panel is displayed. However, if the input was not correct at1730, then an appropriate response is generated at1740. In the case of a simple lock mechanism, the response may simply be to wait for further input or for a timeout. In the case of a password-based lock, then the response may be an error message, and optionally incrementing of a counter of the number of failed attempts to access the unified inbox. In the event the counter exceeds a predefined limit, themobile device100 may automatically wipe some or all of its user data.
• The above examples ofFIGS. 15 to 17 provide a degree of security or privacy protection to the inbox panel. In still other examples, the security or privacy guard function can be applied on a more granular basis to individual messages displayable in the inbox panel.FIGS. 18A and 18B illustrate an example message display view in which a selected message can be marked as “private”. InFIG. 18A, a first view of aunified inbox1800aincludes display of amessage1810 selected from a message listing. The selected message is displayed in thepreview area1820. An option is provided for the user to mark the message as private; in this case, a context menu183ois displayable with a number of options, including the selected “mark as private”option1835. Selection of this option thus instructs the device to tag or categorize the message as “private” or “secure”, or to associate the message with some other indicator indicating that the message is to be handled in the inbox as described below. Those skilled in the art will readily understand that designation of a message in this manner may be accomplished using other techniques, such as selectable user interface elements displayed with the message, application of rules to messages as they are received or after they are stored at themobile device100, and so on. Once the message has been so tagged or categorized, its designation may be visually indicated in the display of the message itself, as in the example view1800bofFIG. 18B. In this example, a tag user interface element184ois displayed, showing that the message has been designated “private”.
• Messages that are designated in this manner are thereafter redacted when the message inbox panel of the homescreen is initially displayed.FIG. 19 illustrates a sequence of navigation between homescreen panels similar in concept to that shown inFIG. 15. Again, navigation between launchpad-type panels such as1900b, or between a launchpad-type panel1900band an inbox panel, can be accomplished using a typical navigation command such as theswipe gesture250aor250b. In the example ofFIG. 19, only one launchpad-type panel1900bis shown, but it will be understood by those skilled in the art that there may be more than one such panel, and again, there may also be multitasking panels and other types of homescreen panels.
• UnlikeFIG. 15, when the user navigates from the last homescreen panel (e.g.,1900b) to theinbox panel1900a, the message listing of the inbox is displayed and is made available for access and to receive input. However, only those messages not marked as “private” (or however that designation is indicated) are immediately selectable or interactable in the message inbox. Those messages that are marked as “private” are at least partially obfuscated or hidden from display in theinbox panel1900a, and accessing those messages requires a further confirmatory step, such as the entry of a password or some other input as described above.
• For instance, inFIG. 19, it can be seen that various messages listed in theinbox panel1900aare visually distinguished.Message1912, which is a designated message, is visually blurred or obfuscated, while other messages such as1914 are not. Selection of the designated message1912 (e.g., by a tap on that message listing entry, as indicated by the contact point andarrow1920a) invokes an intermediate display of a lock orpassword dialog box1955, as shown inview1950a. Entry of the correct input at that stage, as indicated by contact point andarrow1920b, results in display of the designated message content inview1950b. On the other hand, whennon-designated message1914 is selected, as indicated by contact point andarrow1920c, the message content is displayed inview1950cwithout requiring any password entry or confirmatory input. Dismissal of any ofviews1950a,1950bor1950cmay return theinbox panel1900ato the display, as indicated byarrows1930.
• Examples of obfuscation or redaction of designated messages in theinbox panel1900aare shown inFIGS. 20(a) to (c). In the first example,inbox panel2000aincludes a listing of inbox messages, and merely visually blurs or shades the “private”message2010a, leaving the remaining messages such as2012 unobscured. Salient message header information or metadata, such as the sender/recipient name, timestamp, and/or subject line or message content preview, may still be included in the message listing. In the second example,inbox panel2000bagain includes the same listing, but the designatedmessage2010bis listed with less information that inFIG. 20(a). In the example ofFIG. 20(b), the listing for the designatedmessage2010bsimply includes an indication that the message is “locked”. Alternatively, reduced information such as the sender/recipient name may be included in the listing, but other information normally displayed in the message listing is omitted. In the third example, which illustrates a message inbox including amessage display area2018, at least some header information or metadata for the designatedmessage2010cmay be included in the message listing (e.g., sender/recipient name), but even when the message is selected, no message content is displayed in thedisplay area2018. Instead, a notification may be displayed that the message is “private” or “locked”. Of course, more than one designated message may be included in the message listing, whether immediately visible in the inbox panel or not, and those other designated messages are treated the same way (for instance, the inbox panel may be scrollable so that other message listing entries can be displayed in the same obfuscated or redacted manner). In still another example, not illustrated, no designated messages are displayed in the message listing at all. Accessing those messages may require the user to invoke the individual messaging application associated with that designated message, or to select a menu option or other command to show designated messages.
• Still a further example of message listing display of a designated message is shown inFIG. 21, which also illustrates how a designated message can be displayed when it is selected from the inbox. InFIG. 21(a), the further example of theinbox panel2100ais shown. In this case, a listing is included for the designatedmessage2110, but the usual message listing information is replaced with a slide lockuser interface element2110, such as type of slide lock introduced inFIG. 16(b) above. Correct actuation of the slide lock to “unlock” the message then invokes the display of the message, as inview2100c. Alternatively, unlocking the message invokes anintermediate view2100b, in which apassword dialog interface2120 is displayed; upon successful entry of the password, themessage view2100cis finally displayed. It will be appreciated by those skilled in the art that the various features and implementation details described in each example may be combined as appropriate with the features and details of other examples. For instance, the slide lockuser interface element2110 may be implemented in the combined message inbox listing-display area implementation ofFIGS. 13A-13C,16(d) and20(c). Thus, the message view may resemble view2100einstead, which includes amessage listing2132 and amessage display region2134.
• FIGS. 22(a) to (d) illustrate the process of displaying a designated message from an initial inbox panel such as those shown inFIGS. 20(a)-(c). When a designated message, such as themessage2010a,2010b,2010cis selected for display, an intermediate user interface element2210 (inview2200aofFIG. 20(a)) or2220 (inview2200bofFIG. 22(b)) is first displayed. The first example of an intermediate element,2210, is a notification that the message is locked, and optionally includes directions to unlock the message (“Tap to unlock”). The second example of an intermediate element,2220, is a slide lock element as described above. Theintermediate element2210,2220 may partially overlay or completely overlay or obscure the message inbox; in other examples, theintermediate element2210,2220 overlays or replaces the individual message listing entry for the selected designated message (similar to the placement of the slide lock user interface ofFIG. 21(a)). Correct confirmatory input responsive to the intermediate element (in these examples, a tap or other touch event for thenotification element2210, and a swipe gesture operating on the slide lock element2220) then invokes the display of the message content as usual, as indicated inFIG. 22(d), with either a fullscreen view of themessage2200dor a combination inbox listing-message view2200d′. Again, the confirmatory input may instead invoke anotherintermediate view2200c, including auser interface element2230 for receiving password input, similar to that described above in respect ofFIG. 16(c). Correct input of credentials at theintermediate view2200cthen results in display of themessage view2200d,2200d′.
• FIG. 23 illustrates a method implementing the message-level lock or password mechanism described in relation toFIGS. 19-22. At2305, a first homescreen panel is displayed. This may be a launchpad-type panel such as1900b. At2310, a navigation instruction is detected, resulting in display of the inbox panel (such aspanel1900a) at2315. The inbox panel displayed at this stage comprises a message listing including one or more designated messages. At2320, selection of an entry of the displayed message listing is detected. If at2325 it is determined that the message selected is not a designated message, then at2345 a responsive message action, such as displaying the message, is taken. If the message is indeed a designated message, then at2330 a lock element is displayed. This lock element may be theaforementioned notification2210 or slidelock element2220, or some other appropriate user interface element indicating that some level of protection has been applied to the selected message. At2335, an input is detected. If that input is detected at2340 to be an appropriate confirmatory action (e.g., a tap in response to thenotification element2210, the appropriate swipe on the slide lock element2220) or a correct password entry, then at2345 the message is displayed. If, however, the message is not a confirmatory action or correct password, then at2350 an appropriate response is generated. In some instances, the response may be to wait until a further input is detected, or to return to the initial inbox panel display; in others, an error or warning message may be displayed (in the event an incorrect password is entered, for example). If the detected input is a navigation command of the first type, used to navigate from panel to panel within the mode, then the appropriate response may be to display an adjacent panel of the homescreen. Thus, homescreen access to messages may be selectively blocked and optionally secured using credentials, without requiring the entire message inbox or the entire homescreen to be similarly secured.
• Accordingly, there is provided a method implemented by an electronic device, the method comprising: displaying a plurality of views of a homescreen mode of the electronic device, the plurality of views comprising a fullscreen view for a first application executing on the electronic device and at least one launch view comprising a plurality of graphical user interface elements each associated with a corresponding application entry point.
• In one aspect, the first application is a messaging application. The messaging application may be a unified message box application. The messaging application may comprise messages for a plurality of message formats and/or messaging services. Further, the fullscreen view may comprise a message listing. The fullscreen view may additionally or alternatively comprise a message viewing region for displaying content of at least one message. This at least one message may be a selected message of the message listing. The fullscreen view may further comprise a reply input field for receiving reply message content for a selected message.
• In a further aspect, the method may further comprise receiving input content in the reply input field; constructing a reply message comprising the received reply message content for the selected message; and transmitting the reply message.
• In another aspect, all of the plurality of panels are sequentially navigable using one type of navigation command. Applications other than the first application may be invoked using a second type of navigation command. Still further, one of the corresponding application entry points may be actuatable to invoke the first application.
• In still another aspect, the plurality of panels is displayed on a touchscreen of the electronic device.
• There is also provided a method implemented by an electronic device, the method comprising: defining a plurality of views of a homescreen mode of the electronic device, the plurality of views comprising a fullscreen view for a first application executing on the electronic device and at least one launch view comprising a plurality of graphical user interface elements each associated with a corresponding application entry point; while in the homescreen mode, and in response to a navigation instruction of a first class received while a first one of the plurality of views of the homescreen mode is displayed, displaying a further one of the plurality of views of the homescreen mode, wherein either the first one or the further one of the plurality of views is the fullscreen view for the first application.
• There is also provided an electronic device-readable medium, which may be physical or non-transitory, bearing or storing code which, when executed by at least one processor of a suitable electronic device, causes the device to implement one or more of the methods and variants described herein.
• There is also provided an electronic device, which may be a mobile device, adapted to implement the methods and variants described herein. The electronic device may include all or only select features of the example electronic device described herein.
• In various aspects, which may be combined, the first application is a messaging application; the fullscreen view for the first application includes a listing of messages received at or sent from the electronic device; the fullscreen view includes a preview of message content for a selected one of the messages; the fullscreen view includes an input field for receiving input content for a reply message to a selected one of the messages; wherein the first application is a messaging application and the fullscreen view includes an input field for receiving input content for a message to be sent from the electronic device, the method further comprising: while in the homescreen mode, displaying the view comprising the fullscreen view for the first application; receiving input content in the input field; and sending a message comprising the input content.
• In other aspects, which may be combined, the messaging application is a unified inbox application; the plurality of views of the homescreen mode includes a multitasking view comprising a reduced-size view of at least one other application executing on the electronic device; the plurality of views includes a lock or password view displayed as an intermediate view while navigating to the fullscreen view of the first application from another view of the homescreen mode.
• While a unified messaging application or function is used in the examples described herein, it will be appreciated by those skilled in the art that views of other types of applications or functions, such as a dedicated (not unified) messaging application, calendar, and so forth, may be provided in the panel instead. However, a view of a messaging application, such as the unified messaging application in particular, affords the user the ability to interact with messaging functions on the device—including not only viewing messages, but also composing and sending messages—from the homescreen, and while the device is operating in a homescreen mode.
• It should be understood that steps and the order of the steps in the processing described herein may be altered, modified and/or augmented and still achieve the desired outcome. Throughout the specification, terms such as “may” and “can” are used interchangeably and use of any particular term should not be construed as limiting the scope or requiring experimentation to implement the claimed subject matter or embodiments described herein. Further, the various features and adaptations described in respect of one example or embodiment in this disclosure can be used with other examples or embodiments described herein, as would be understood by the person skilled in the art.
• The systems' and methods' data may be stored in one or more data stores. The data stores can be of many different types of storage devices and programming constructs, such as RAM, ROM, flash memory, programming data structures, programming variables, etc. It is noted that data structures describe formats for use in organizing and storing data in databases, programs, memory, or other computer-readable media for use by a computer program.
• Code adapted to provide the systems and methods described above may be provided on many different types of computer-readable media including computer storage mechanisms (e.g., CD-ROM, diskette, RAM, flash memory, computer's hard drive, etc.) that contain instructions for use in execution by a processor to perform the methods' operations and implement the systems described herein.
• The computer components, software modules, functions and data structures described herein may be connected directly or indirectly to each other in order to allow the flow of data needed for their operations. Various functional units described herein have been expressly or implicitly described as modules and agents, in order to more particularly emphasize their independent implementation and operation. It is also noted that an agent, module or processor includes but is not limited to a unit of code that performs a software operation, and can be implemented for example as a subroutine unit of code, or as a software function unit of code, or as an object (as in an object-oriented paradigm), or as an applet, or in a computer script language, or as another type of computer code. The various functional units may be implemented in hardware circuits such as custom VLSI circuits or gate arrays; field-programmable gate arrays; programmable array logic; programmable logic devices; commercially available logic chips, transistors, and other such components. Modules implemented as software for execution by a processor or processors may comprise one or more physical or logical blocks of code that may be organized as one or more of objects, procedures, or functions. The modules need not be physically located together, but may comprise code stored in different locations, such as over several memory devices, capable of being logically joined for execution. Modules may also be implemented as combinations of software and hardware, such as a processor operating on a set of operational data or instructions.
• A portion of the disclosure of this patent document contains material which is or may be subject to one or more of copyright, design patent, industrial design, or unregistered design protection. The rights holder has no objection to the reproduction of any such material as portrayed herein through facsimile reproduction of the patent document or patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all rights whatsoever.

Claims (21)

1. A method implemented by an electronic device, the method comprising:

displaying a plurality of panels of a homescreen of the electronic device,

the plurality of panels comprising a fullscreen view for a messaging application executing on the electronic device and at least one launch panel comprising a plurality of graphical user interface elements, each of the plurality of graphical user interface elements being associated with a corresponding application entry point.

2. The method ofclaim 1, wherein the fullscreen view comprises a message listing.

3. The method ofclaim 1, wherein the fullscreen view comprises a message viewing region for displaying content of at least one message.

4. The method ofclaim 2, wherein the fullscreen view further comprises a message viewing region for displaying content of at least one message selected from the message listing.

5. The method ofclaim 1, wherein the fullscreen view further comprises a reply input field for receiving reply message content for a selected message.

6. The method ofclaim 5, further comprising:

receiving input content in the reply input field;

constructing a reply message comprising the received reply message content for the selected message; and

transmitting the reply message.

7. The method ofclaim 1, wherein the messaging application is a unified message box application.

8. The method ofclaim 7, wherein the unified message box application comprises messages for a plurality of message formats, a plurality of messaging services, or a plurality of both message formats and messaging services.

9. The method ofclaim 1, wherein all of the plurality of panels are sequentially navigable using one type of navigation command.

10. The method ofclaim 1, wherein one of the corresponding application entry points is actuatable to invoke the messaging application.

11. An electronic device, including:

a display;

at least one processor, the at least one processor being configured to enable:

displaying, on the display, a plurality of panels of a homescreen,

the plurality of panels comprising a fullscreen view for a messaging application executing on the electronic device and at least one launch panel comprising a plurality of graphical user interface elements, each of the plurality of graphical user interface elements being associated with a corresponding application entry point.

12. The electronic device ofclaim 11, wherein the fullscreen view comprises a message listing.

13. The electronic device ofclaim 12, wherein the fullscreen view comprises a message viewing region for displaying content of at least one message.

14. The electronic device ofclaim 13, wherein the fullscreen view further comprises a message viewing region for displaying content of at least one message selected from the message listing.

15. The electronic device ofclaim 11, wherein the fullscreen view further comprises a reply input field for receiving reply message content for a selected message.

16. The electronic device ofclaim 15, wherein the at least one processor is further configured to enable:

receiving input content in the reply input field via an input subsystem;

constructing a reply message comprising the received reply message content for the selected message; and

initiating transmission of the reply message.

17. The electronic device ofclaim 11, wherein the messaging application is a unified message box application.

18. The electronic device ofclaim 17, wherein the unified message box application comprises messages for a plurality of message formats, a plurality of messaging services, or a plurality of both message formats and messaging services.

19. The electronic device ofclaim 11, wherein all of the plurality of panels are sequentially navigable using one type of navigation command.

20. The electronic device ofclaim 11, wherein one of the corresponding application entry points is actuatable to invoke the messaging application.

21. A non-transitory electronic device-readable medium bearing code which, when executed by at least one processor of an electronic device, causes the electronic device to implement the method of:

displaying, a plurality of panels of a homescreen of the electronic device,

the plurality of panels comprising a fullscreen view for a messaging application executing on the electronic device and at least one launch panel comprising a plurality of graphical user interface elements, each of the plurality of graphical user interface elements being associated with a corresponding application entry point.

Images