Patent Application
20090132915
User experience (UX) refers to overall quality of experience of user interaction with a system. User experience design is multi-disciplinary incorporating teachings of psychology, engineering, and graphic design, among others. The goal is to facilitate interaction by identifying and catering to end user needs, desires, and limitations. As per computer systems, user experience pertains to human computer interaction (HCI) at user interfaces.
User interfaces enable users to interact with a computer, device, and software executed thereby. Interfaces receive input from users to manipulate a computer system utilizing various capture mechanisms including, keyboards, keypads, pointing devices and the like. Interfaces output data and responses to user manipulations via text, graphics, audio, and/or video.
User interfaces have evolved substantially in terms of user experience. Initially, computer interaction was accomplished by entering text commands via keyboards. However, these commands were numerous, complex, and not easily discoverable. Graphical user interfaces (GUIs) were subsequently invented to address these and other deficiencies. In particular, GUIs employ graphical elements and a pointing device such as a mouse to trigger operations rather than typing commands. For example, various metaphors such as windows and a desktop were utilized to facilitate interaction with other graphic elements. GUIs further evolved from primitive monochrome graphics to much smoother and colorful interface elements. Current development continues to leverage gains in computational power, memory and the like to present even better graphical interfaces.
User experience and specifically graphical user interfaces are very important to applications. New functionality implemented by an application is of little value to consumers if it is not easy to use. To this end, one application design goal is usability. Also generally referred to as user friendliness, such factors include intuitive navigation, ease of learning, efficiency of use, as well as subjective satisfaction. Accordingly, programmers need to examine who their application users are including their knowledge level, background, and learning capacity, among other things and develop an interface based on these factors. As a result, a single user interface is conventionally provided, tightly coupled to backend programmatic logic, that seeks to address the average application user.
The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview. It is not intended to identify key/critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
Briefly described, the subject disclosure pertains to selection and switching views or user interfaces. Views and application logic can be separated or at most loosely coupled rather than tightly coupled or integrated to facilitate flexible, compositional construction of applications with different views. In accordance with an aspect of the disclosure, simple identification of a view in a declaration, for example, can trigger binding of the view to associated application logic. According to another aspect of the disclosure, end users can select and switch views as desired at runtime without additional work by developers. Further yet, views presented for selection can be filtered and/or ordered to improve user productivity according to yet another aspect of the disclosure. In accordance with still another aspect of the disclosure, transitions can be provided when switching between views to improve user experience.
To the accomplishment of the foregoing and related ends, certain illustrative aspects of the claimed subject matter are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the subject matter may be practiced, all of which are intended to be within the scope of the claimed subject matter. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
a-c illustrate exemplary styling of a selection mechanism according to an aspect of the disclosure.
Systems and methods of view selection and switching are described in detail hereinafter. Application logic and interfaces are implemented separately to enable more than one interface or view to by utilized in conjunction with the application logic. Support is provided for specification of a view for application logic by mere identification. Further, views can be provided to users for selection and subsequent provisioning dynamically at runtime. These views can be selectively afforded and ordered, among other things, as a function of contextual information including user identities, roles, and/or permissions, for instance. Still further yet, transitions can be applied when switching between views.
Various aspects of the subject disclosure are now described with reference to the annexed drawings, wherein like numerals refer to like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter.
Referring initially to
Various styles of displaying information (e.g., charts, tables, graphs . . . ) give end users different advantages in viewing and analyzing underlying data. Accordingly, the ability to display one set of data in multiple ways is important. Different users have different preferences in the way they want to interact with an application. For example, some people prefer to see their file directory as icons, others prefer to view this information as a list, and some want a thumbnail of the actual content. Therefore, it is advantageous for applications to support multiple user interfaces and be able to change views easily to display underlying data and logic in different manners.
Conventionally, developers are required to implement logic every time they need to produce a different display or interaction with their application. In fact, the logic and interface are tightly integrated in complex and inseparable ways. As a result, multiple interfaces are time as well as cost prohibitive. By separating logic from the view over the logic, different displays or interactions can supported more easily.
It should be appreciated that the logic component 110 and view/UI component(s) 120 need not be completely separate. In one embodiment, these components can be loosely coupled. For example, situations may occur where interaction with logic or data produced thereby is the same across different interfaces. In this case, a portion of an application user interface can be encapsulated within the logic component 110.
Furthermore, the view/UI component(s) 120 can interact with a shell. A shell is a user interface provided by a host application that defines the overall look and feel of the host application and provides screen real estate. The view/UI component(s) 120 can integrate with a shell's user interface. For example, the shell can be a computer operating system that provides a window for use by a view/UI component 120.
The logic component 110 and a view/UI component(s) 120 can be linked or bound by binder component 130. In one embodiment, the binder component 130 can provide or act as an interface such as an application-programming interface (API) providing a means for communicating between the two distinct components 110 and 120. Other embodiments are also possible and contemplated. By way of example and not limitation, the binder component 130 can integrate instances of the logic component 110 and view component 120. In any event, the binder component 130 enables a view or interface to execute together with application logic.
Declaration component 140 receives or retrieves information regarding what view component 120 is to be bound a logic component 110. This information can be transmitted or otherwise made available to the communicatively coupled binder component 130 for use thereby. In accordance with one aspect, views or interfaces can be linked or bound to logic by simple identification. For example, a developer can simply identify a view component 120 to be bound to a logic component 110. This could be accomplished with a markup language such as XMAL (eXtensible Markup Application Language), among others, by a specifying a type. If no view is specified for logic via the declaration component 140, a default view can be bound. In one instance, the declaration component 140 can be part of an API including the binder component 130. However, the claimed subject matter is not limited thereto.
By way of example and not limitation, consider the follow pseudo-code where a “Part” corresponds to application logic and a “PartView” denotes a view or user interface:
Here, a single part “SomePart” is declared as well as two views “SomePartView1” and “SomePartView2.” The following code snippet illustrates how a view can be selected based on type, namely “PartViewType”:
In this case, the second view “SomePartView2” is bound to the part “SomePart.” More specifically, “PartPane” inherits from “Pane” which can inherit from “ContentControl” of a presentation system. A new property on “PartPane” is added to enable developers the ability to select a “PartView” associated with a “Part” (self-contained logic). Developers can also specify which view to use more directly by setting the “PartViewType” property directly as follows:
Turning attention to
For purposes of clarity and understanding and not limitation, consider a scenario in which a user wants to monitor her stock portfolio closely utilizing a custom stock monitor where she can specify stocks to track. She can first write the custom application logic to acquire stock information from a web service. Subsequently, multiple views can be applied in conjunction with the logic to view the same data in different ways. More specifically, she can select from ten available views shown at runtime by identifying a particular view by name from a drop down menu, for instance. Similar scenarios exist for weather and RSS (Really Simple Syndication) posts.
It is to be noted that the selection component 220 can interact with, or be encapsulated by, the presentation component 210. For example, the selection component 220 can be embodied as a selection interface or menu that forms part of a window, frame, or chrome surrounding an area to be occupied by a default or selected view or user interface. Further, this selection interface can also be styled in various ways. These styles can be specified in accordance with a previous exemplary pseudo-code as follows:
a-c illustrate portions of a few exemplary selection interfaces. As shown in
Turning attention to
In accordance with the continuing exemplary pseudo-code, a filter can be designated for execution before generating a list of available views to show users as follows:
In other words, a “PartViewFilter” is set to “SelectionFilter” for a given “Part.” Accordingly, an available filter need only be appropriately identified by name.
Consider a real estate application including appropriate business logic and many views, for example. Based on a user's role or position, only a subset of views will be available to her. For instance, a user may have only four out of ten views available, while a real estate agency may be able to see six out of ten views, and only an administrator is able to see all ten views.
The filter component 410 can operate with respect to any contextual information that is available thereto. Accordingly, filtering can be arbitrarily simple, or complex. For instance, filtering can occur based solely on a user identity. Alternatively, the filter component 410 can infer the most appropriate views based on a variety of contextual factors including historical usage and/or preferences, amongst others. Further, various technologies can be utilized to provision context information. For example, global satellite positioning systems (GPS) can provide user location data to enable filtering based on location.
View ordering or organization logic can by specified by a programmer during program development. In accordance with one aspect, users can simply provide an integer that sets a view's order explicitly or specify custom logic for determining order of views at runtime. Exemplary pseudo-code for setting order by integer is:
In this case, “SomePartView1” is specified as the first view to appear. Order can also by set utilizing custom logic as follows:
Here, views binding to “SomePart” are organized in accordance with the order specified by “ViewLogicOrder,” which can be arbitrarily complex.
In this case, a “RotateTransition” is specified for transitions between views associated with “SomePart.”
Referring to
The aforementioned systems, architectures, and the like have been described with respect to interaction between several components. It should be appreciated that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. Sub-components could also be implemented as components communicatively coupled to other components rather than included within parent components. Further yet, one or more components and/or sub-components may be combined into a single component to provide aggregate functionality. Communication between systems, components and/or sub-components can be accomplished in accordance with either a push and/or pull model. The components may also interact with one or more other components not specifically described herein for the sake of brevity, but known by those of skill in the art.
Furthermore, as will be appreciated, various portions of the disclosed systems above and methods below can include or consist of artificial intelligence, machine learning, or knowledge or rule based components, sub-components, processes, means, methodologies, or mechanisms (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, classifiers . . . ). Such components, inter alia, can automate certain mechanisms or processes performed thereby to make portions of the systems and methods more adaptive as well as efficient and intelligent. By way of example and not limitation, the filter component 410 and/or order component 510 can utilizes such mechanisms to infer or intelligently determine appropriate views and orders, respectively.
In view of the exemplary systems described supra, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts of
Referring to
Referring to
The word “exemplary” or various forms thereof are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Furthermore, examples are provided solely for purposes of clarity and understanding and are not meant to limit or restrict the claimed subject matter or relevant portions of this disclosure in any manner. It is to be appreciated that a myriad of additional or alternate examples of varying scope could have been presented, but have been omitted for purposes of brevity.
As used herein, the term “inference” or “infer” refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines . . . ) can be employed in connection with performing automatic and/or inferred action in connection with the subject innovation.
Furthermore, all or portions of the subject innovation may be implemented as a method, apparatus or article of manufacture using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed innovation. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks (e.g., compact disk (CD), digital versatile disk (DVD) . . . ), smart cards, and flash memory devices (e.g., card, stick, key drive . . . ). Additionally it should be appreciated that a carrier wave can be employed to carry computer-readable electronic data such as those used in transmitting and receiving electronic mail or in accessing a network such as the Internet or a local area network (LAN). Of course, those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope or spirit of the claimed subject matter.
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system memory 1116 includes volatile and nonvolatile memory. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1112, such as during start-up, is stored in nonvolatile memory. By way of illustration, and not limitation, nonvolatile memory can include read only memory (ROM). Volatile memory includes random access memory (RAM), which can act as external cache memory to facilitate processing.
Computer 1112 also includes removable/non-removable, volatile/non-volatile computer storage media.
The computer 1112 also includes one or more interface components 1126 that are communicatively coupled to the bus 1118 and facilitate interaction with the computer 1112. By way of example, the interface component 1126 can be a port (e.g., serial, parallel, PCMCIA, USB, FireWire . . . ) or an interface card (e.g., sound, video, network . . . ) or the like. The interface component 1126 can receive input and provide output (wired or wirelessly). For instance, input can be received from devices including but not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, camera, other computer and the like. Output can also be supplied by the computer 1112 to output device(s) via interface component 1126. Output devices can include displays (e.g., CRT, LCD, plasma . . . ), speakers, printers, and other computers, among other things.
The system 1200 includes a communication framework 1250 that can be employed to facilitate communications between the client(s) 1210 and the server(s) 1230. The client(s) 1210 are operatively connected to one or more client data store(s) 1260 that can be employed to store information local to the client(s) 1210. Similarly, the server(s) 1230 are operatively connected to one or more server data store(s) 1240 that can be employed to store information local to the servers 1230.
Client/server interactions can be utilized with respect with respect to various aspects of the claimed subject matter. For example, various extensions or plug-ins (e.g., selection, filter, order, transition . . . ) can be downloaded from server(s) 1230 to client(s) 1210 executing an application across the network framework 1250. Further, application logic can acquire data running on a client 1210 can acquire data from a web service provided by one or more servers 1230. Still further yet, applications utilizing the described view/logic separation or loose coupling and associated mechanisms can be distributed across client(s) 1210 and servers 1230 in a myriad of ways and communicate over the network framework 1250.
What has been described above includes examples of aspects of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the disclosed subject matter are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the terms “includes,” “contains,” “has,” “having” or variations in form thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.
