Embodiments relate generally to software application development and more particularly to enabling enhanced customization of visual or interactive characteristics of a visual element.
Persons developing content (content developers) in an integrated development environment (IDE), for example, are afforded access to a number of graphical components that can be used to develop content in the IDE. Examples of such components include buttons, list boxes, text boxes, and data grids. Components used in an IDE can be created within an IDE by a content developer, i.e., custom-built, or they can be standard components, for example, provided through a software development kit (SDK). Content developers who create their own components have flexibility and control in determining how their visual elements can be configured. Creating components, however, can be time-consuming, cumbersome, and inefficient in comparison to using existing, standard components. Using standard components, on the other hand, enables content developers to develop content more efficiently but with less flexibility.
A content developer can include components in a software application in various ways. For example, a content developer may use an IDE to select a component and place it at a desired location on a what-you-see-is-what-you-get (WYSIWYG) canvas area in the IDE. The IDE may display and allow editing of a graphical representation of the component and/or program code or markup that defines the visual or interactive characteristics of the component's visual elements. The content developer can view and modify the representation and characteristics to change or otherwise configure the visual elements of the component. When the content being developed is completed, the content developer exports, compiles, or otherwise provides the content for use by end users who can use the content, for example, to interact with displayed components and associated visual elements in the provided content.
While standard components can enable faster and more efficient development, they can also restrict a content developer's ability to configure visual elements of a component. For example, content developers who use standard components may be restricted to only being able to configure certain visual and/or interactive characteristics. For example, a content developer who desires to create an application that allows data to be entered into rows and columns can select and include a standard data grid component in the IDE. The IDE may display the data grid's visual elements and allow limited configuration of its visual elements based on the definitions of the component's visual elements, i.e., the specification of the standard data grid component provided in an SDK. A row separator visual element of a data grid, for example, may include certain configurable attributes and other attributes that are not configurable. A content developer may wish to change color and thickness attributes of the row separator but be unable to do so if those characteristics are not configurable. As another example, a content developer may desire for a row separator to have interactivity such that when an end user clicks on the row separator, informational text is displayed. Again, the content developer may be unable to specify such interactivity if configuring such interactivity is not permitted for the row separator visual element of the standard data grid component that is being used. Content developers desiring to configure such un-configurable characteristics have had to resort to the often inefficient, time-consuming, and cumbersome option of creating custom components themselves.
One illustrative embodiment involves receiving, at one or more processors, input specifying a component in content being developed. The component, according to a definition of the component, comprises a visual element that is configurable based on type. The embodiment also involves receiving, at one or more processors, input specifying a type for the visual element. Visual or interactive characteristics of the visual element that are available for specification differ based on which type is specified for the visual element. The embodiment further involves providing, via one or more processors, the content. This illustrative embodiment is mentioned not to limit or define the disclosure, but to provide an example to aid understanding thereof. Additional embodiments are discussed in the Detailed Description and further description is provided there.
These and other features, aspects, and advantages of the present disclosure are better understood when the following Detailed Description is read with reference to the accompanying drawings, where:
a depicts an exemplary data grid that includes a selection indicator prior to a type being specified for the selection indicator visual element.
b depicts an exemplary data grid that includes a selection indicator after a type has been specified for the selection indicator visual element.
c depicts an exemplary data grid that illustrates an increased area in response to the selection indicator visual element being expanded in a vertical direction.
Embodiments herein relate to enabling the configuration of visual elements based on type. Enabling such configuration involves creating visual elements in a fashion that enables them to be used flexibly by content developers, whether that use be in an IDE or via markup that is separate from the IDE. For example, a content developer may add a component to content being developed in an IDE and recognize that a particular aspect of a visual element of the component cannot be configured as the developer wishes. For example, the content developer may wish to change the color and size of a row separator visual element of a data grid component but be unable to make such configuration changes based on restrictions applicable to the visual element based on its particular type or class. The content developer is, however, able to change the type of the visual element so that the particular aspects of the visual component can be configured. In the above example, the content developer may change the type of the row indicator visual element to a different type such that the data grid visual element has different characteristics available for configuration, e.g., allowing the content developer to specify custom color and size attributes for the row indicator can be custom configured as desired.
The following examples further illustrate flexible use of component visual elements. In one example, a data grid component is again included in content being developed and the content developer recognizes that configuration of aspects of the data grid's selection indicator visual element are desired but unavailable. The selection indicator of the standard data grid component, in this example, is a visual element that highlights rows, columns, or cells of a component having such attributes, such as a data grid. The selection indicator of the standard data grid component used by the content developer may allow only certain of its attributes, such as color, to be configured. The content developer may, however, wish to configure the selection indicator to provide enhanced interactivity in a way not permitted based on the selection indicator's default type. In this example, the IDE content developer changes the selection indicator's type by changing the “class” of the selection indicator such that the selection indicator's definition (i.e., specifying its features and interactivity and how such features and interactivity may be configured) is inherited from a different parent object. For example, the change may result in the selection indicator inheriting its definition from parent class B rather than from parent class A. Inheriting from class B rather than class A provides the selection indicator with interactivity configuration options not available when it inherits from class A. As a specific example, inheriting from class B may allow the content developer to specify that the displayed corners of the selection indicator comprise displayed handles and to specify the appearance of such handles. Including and configuring such handles allows the content developer to specify interactivity that he/she otherwise could not, e.g., specifying the inclusion of the handles for an end user to click and drag to increase the size of a selected area. Additionally or alternatively, classes may also be specified so that the selection indicator, or another visual element, can inherit characteristics of those classes.
As another example, a content developer of an application that is targeted for a handheld tablet computer that does not have a mouse may desire to provide hover indicator-like functionality. In particular, instead of a message being displayed when a mouse is moved over a cell of a data grid, the content developer may want to enable such functionality when an end user navigates to a cell by pressing an arrow on a keyboard, i.e., caret indicator. The content developer can specify the hover indicator type for the caret indicator visual element such that when a user navigates to a cell using the tablet computer keypad, a message is displayed in similar fashion to that when a mouse is held over a cell using the hover indicator.
Types of other visual elements associated with a data grid component and other components can be specified to give greater control over their customization to content developers. Examples of visual elements associated with an exemplary data grid component include but are not limited to row and column background, row and column separator, hover indicator, caret indicator, selection indicator, and editor indicator. These visual elements can define the appearance and behavior of a data grid component. Other visual elements may also be included. Similarly, other components may have these and/or different visual elements associated therewith.
Content developers are able to change the characteristics available for configuration of a visual element by specifying a type for the visual element. In this way, the customization of visual elements is limited only by the number of available types. In one embodiment, any available type can be specified for any available visual element. To accomplish greater control over configurability, visual elements can be standardized in an SDK such that they include a limited number of characteristics, such as those defined in a base or primitive parent class from which the visual elements inherit. The visual elements of a component may be defined in the component's “skin,” in a portion of the component that defines the appearance or behavior of a component, or otherwise. The component and its associated visual elements may be defined in the SDK such that an IDE using the SDK recognizes that a type of the visual elements can be specified. In one exemplary embodiment, a type of a visual element is a configurable attribute of the visual element. For example, a type of the visual element may be specified by specifying the particular class from which the visual element inherits. In such an embodiment, the component and its associated visual elements may be defined in the SDK such that an IDE using the SDK recognizes that a class of the visual elements can be specified. The IDE may present a list of available classes from which a content developer can select to specify a particular class for a visual element. In doing so, the IDE may provide information about the class, e.g., providing text explaining that identification of class A allows configuration of features X, Y, Z, identification of class B allows configuration of features W, X, Y, Z, etc. A content developer may also use a markup language to specify a particular class for a visual element.
As used herein, the term “device” refers to any computing or other electronic equipment that executes instructions and includes any type of processor-based equipment that operates an operating system or otherwise executes instructions. A device will typically include a processor 11 that executes program instructions and may include external or internal components such as a mouse, a CD-ROM, DVD, a keyboard, a display, or other input or output equipment. Examples of devices are personal computers, digital assistants, personal digital assistants, cellular phones, mobile phones, smart phones, pagers, digital tablets, laptop computers, Internet appliances, other processor-based devices, and television viewing devices. The exemplary IDE device 10 is used as a special purpose computing device to provide an IDE for creating software applications in a manner that enables enhanced configuration of visual elements. As used herein, an IDE is a software application that provides comprehensive facilities to content developers for software development. An IDE can include a source code editor and/or markup editor, a compiler and/or an interpreter, and build automation tools, e.g., a WYSIWYG interface and standard and custom-built components. IDE device 10 is illustrated in
As used herein, the term “component” refers to an object comprising one or more visual elements that provide the appearance and behavior of the object. A component can be depicted as a graphic that can be used in a graphical user interface (GUI) application. Examples of components include a data grid, buttons, text boxes, list boxes, or other objects that enable a user to view or interact with a GUI application. A component can be standard or custom-built, according to various embodiments herein. A standard component can be created with standard or default characteristics for its visual elements and included in an SDK for use in an IDE. Custom-built components are considered to be components that are created by content developers using an IDE or markup language within or separate from the IDE.
As used herein, the term “visual element” refers to a displayed element of a component. A visual element can have configurable visual or interactive characteristics. Which characteristics of a visual element can be specified may depend upon which type the visual element is associated.
A data grid is an exemplary component that includes various visual elements. The visual elements of an exemplary data grid include row and column backgrounds, row and column separators, a hover indicator, a selection indicator, a caret indicator, and an editor indicator. Each of these visual elements provides unique characteristics for the exemplary data grid. For example, row and column backgrounds define the appearance of the background for each visible row and column in the data grid. The row or column separator divides rows and columns into cells. The hover indicator displays various information when a mouse is moved over certain portions of the data grid. The selection indicator highlights selected visible rows, columns, or cells. The caret indicator highlights the visible row, column, or cell that corresponds to keyboard input. The editor indicator highlights a cell that is being edited. Types and corresponding classes for each of these visual elements can be specified.
As used herein, a “type” refers to an attribute of a visual element that defines configurable visual or interactive characteristics. A “class” refers to a construct that is used as a blueprint to create instances of itself. Specifying a type for a visual element effectively specifies a class that corresponds to the type for the visual element. Specification of a class can enable a visual element to “inherit” the characteristics of the specified class such that the characteristics of the inherited class are passed to the visual element for which the class is specified. The characteristics are passed by deriving a new instance of the inherited class. New or additional characteristics for a visual element can be included in the derived instance of the inherited class.
A computer-readable medium may comprise, but is not limited to, an electronic, optical, magnetic, or other storage device capable of providing a processor with computer-readable instructions. Other examples comprise, but are not limited to, a floppy disk, CD-ROM, DVD, magnetic disk, memory chip, ROM, RAM, an ASIC, a configured processor, optical storage, magnetic tape or other magnetic storage, flash memory, or any other medium from which a computer processor can read instructions. The instructions may comprise processor-specific instructions generated by a compiler and/or an interpreter from code written in any suitable computer-programming language, including, for example, JavaScript, ActionScript®, Java, Perl, C, C++, C#, Visual Basic, and Python. The instructions may also be created using markup languages such as XML.
In
Characteristics of a visual element can be specified during the creation of the visual element at block 304. In one embodiment, basic or primitive characteristics of a visual element, e.g., those fundamental characteristics that are shared by all visual elements, can be included in the class of a visual element during its creation. For example, all visual elements can share the characteristic of being locatable at a particular X, Y coordinate position on a layout or canvas area in an IDE. Characteristics in addition to fundamental, shared characteristics can also be specified during creation of a visual element. Embodiments herein, however, emphasize the specification of limited characteristics at creation time of a visual element to give content developers more flexibility in configuring the visual element.
The visual elements created as described in the embodiment of
The visual elements of the component received at block 402 can be identified at block 404. Content, such as program code or markup, that defines a type for visual elements can be displayed in the IDE when the component is received at block 302. The IDE can include, or alternatively provide access to, the various visual or interactive characteristics of the types that are available to be specified for visual elements in the IDE. Content developers can specify respective classes that correspond to these types for the visual elements so that the visual elements can inherit the visual or interactive characteristics of the specified classes (block 406).
Visual or interactive characteristics for a visual element can differ based on which type is specified for the visual element. Types can differ in a number of ways. For example, they can differ based on the characteristics available for configuration. For example, some types may have characteristics that enable an end user to interact with the appearance of a visual element, such as the handles located at corners of rows selected by the selection indicator visual element. Other types can have characteristics that display a message in response to end user actions, e.g., a hover indicator visual element type.
The content containing the configurable visual elements can be provided at block 408 of
a depicts a data grid component that contains various visual elements, such as a row separator 502, an editor indicator 504, and a selection indicator 506. Fewer or more visual elements may exist for the data grid component. The data grid and its visual elements can be standard elements that can be used in an IDE where a type can be specified for them. For example,
Content developers can specify a class 608 that enables the selection indicator 506 to be configured such that it can be expanded to highlight additional data. To accomplish this, according to one embodiment, specification of the type 608 can cause the selection indicator 506 to have handles 508a-d located at the corners of the selection indicator 506, as shown in
Prior to the specification of class 608, the selection indicator 506 would have been unable to expand as described. Only the colors as indicated by labels 604 and 606 could have been configured, for example. By creating the selection indicator 506 in such a way that enables content developers to specify a type for the selection indicator 506, content developers can choose to allow an end user to interact with the selection indicator 506 in the manner described above. Configuration of the selection indicator 506 as described is only one example of how a visual element can be configured. Additional visual elements and additional types of configurations can be implemented in various embodiments.
As another example, the appearance of cells in a data grid can be configured such that they appear as visual elements 705a-t in
Numerous specific details are set forth herein to provide a thorough understanding of the claimed subject matter. However, those skilled in the art will understand that the claimed subject matter may be practiced without these specific details. In other instances, methods, apparatuses or systems that would be known by one of ordinary skill have not been described in detail so as not to obscure claimed subject matter.
Some portions are presented in terms of algorithms or symbolic representations of operations on data bits or binary digital signals stored within a computing system memory, such as a computer memory. These algorithmic descriptions or representations are examples of techniques used by those of ordinary skill in the data processing arts to convey the substance of their work to others skilled in the art. An algorithm is a self-consistent sequence of operations or similar processing leading to a desired result. In this context, operations or processing involve physical manipulation of physical quantities. Typically, although not necessarily, such quantities may take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared or otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to such signals as bits, data, values, elements, symbols, characters, terms, numbers, numerals or the like. It should be understood, however, that all of these and similar terms are to be associated with appropriate physical quantities and are merely convenient labels. Unless specifically stated otherwise, it is appreciated that throughout this specification discussions utilizing terms such as “receiving” and “identifying,” or the like, refer to actions or processes of a computing device, such as one or more computers or a similar electronic computing device or devices, that manipulate or transform data represented as physical electronic or magnetic quantities within memories, registers, or other information storage devices, transmission devices, or display devices of the computing platform.
The system or systems discussed herein are not limited to any particular hardware architecture or configuration. A computing device can include any suitable arrangement of components that provides a result conditioned on one or more inputs. Suitable computing devices include multipurpose microprocessor-based computer systems accessing stored software that programs or configures the computing system from a general purpose computing apparatus to a specialized computing apparatus implementing one or more embodiments of the present subject matter. Any suitable programming, scripting, or other type of language or combinations of languages may be used to implement the teachings contained herein in software to be used in programming or configuring a computing device.
Embodiments of the methods disclosed herein may be performed in the operation of such computing devices. The order of the blocks presented in the examples above can be varied—for example, blocks can be re-ordered, combined, and/or broken into sub-blocks. Certain blocks or processes can be performed in parallel.
The use of “based on” is meant to be open and inclusive, in that a process, step, calculation, or other action “based on” one or more recited conditions or values may, in practice, be based on additional conditions or values beyond those recited. Headings, lists, and numbering included herein are for ease of explanation only and are not meant to be limiting.
While the present subject matter has been described in detail with respect to specific embodiments thereof, it will be appreciated that those skilled in the art, upon attaining an understanding of the foregoing may readily produce alterations to, variations of, and equivalents to such embodiments. Accordingly, it should be understood that the present disclosure has been presented for purposes of example rather than limitation, and does not preclude inclusion of such modifications, variations and/or additions to the present subject matter as would be readily apparent to one of ordinary skill in the art.