Patent ID: 12212632

DESCRIPTION OF EMBODIMENTS

The following description is presented to enable any person skilled in the art to create and use a system to select and modify views in a view hierarchy used to produce a user interface display in an electronic device and to track usage of such views. Various modifications to the embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and uses without departing from the spirit and scope of the inventive subject matter. Moreover, in the following description, numerous details are set forth for the purpose of explanation. However, one of ordinary skill in the art will realize that the inventive subject matter might be practiced without the use of these specific details. In other instances, well-known machine components, processes and data structures are shown in block diagram form in order not to obscure the disclosure with unnecessary detail. Identical reference numerals may be used to represent different views of the same item in different drawings. Flow diagrams in drawings referenced below are used to represent processes. A computer system may be configured to perform some of these processes. Modules within flow diagrams representing computer implemented processes represent the configuration of a computer system according to computer program code to perform the acts described with reference to these modules. Thus, the inventive subject matter is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Processes to Match View Selectors and Subview Hierarchies

A computer program code application typically includes a variety of different views contained within a variety of different view hierarchies that are used to generate a corresponding variety of different user interface displays. During the running of an application on a device, different user interface displays may be presented in response to different user inputs, for example. Thus, in the course of running an application, the user interface display that is presented for viewing by a user may change frequently in response to user input, for example. A different view hierarchy is used to produce each different user interface display. More specifically, the application program configures the device to call upon different view hierarchies to produce different user interface displays. In some embodiments, an application configures a device to use operating system software to use the view hierarchies associated with the application to configure a device to generate the application's user interface displays.

FIG.2is an illustrative flow diagram representing a process100to make modifications to one or more views used by an application to generate one or more corresponding user interface elements in accordance with some embodiments. Module102configures a device to receive an indication of an occurrence of an event that triggers an evaluation of whether a modification is required to a view used by the application. In some embodiments, an event that triggers evaluation can be a transition from one user interface display to a next user interface display in response to user input. For example, a user may provide input to scroll or to jump to a different screen or to otherwise invoke a transition from one user interface display to the different one. To make the transition happen, the application calls upon a next view hierarchy to produce the next user interface display. Before actually using that next view hierarchy to generate the next user interface display, however, a determination is made, as explained more fully below, as to whether to first make a modification to that next view hierarchy.

Thus, in accordance with some embodiments, module102configures the device to determine whether there is an impending use of a next view hierarchy to generate a next user interface display. For example, allocation of memory space for creation of the next view hierarchy typically indicates impending use of a next view hierarchy and may act as a trigger event. In response to an occurrence of a trigger event, decision module104determines whether one more first view selectors are associated with the application, and if so, whether one or more first view selectors that are determined to be associated with the application have not yet been used to evaluate whether to modify a view to be used by the application in response to the trigger event.

As explained more fully below with reference toFIGS.11-14, a computer readable storage device1212can store one or more information structures1112that associate view modification indicators1116with first view selectors1118. A view modification indicator1116indicates one or more modifications to be made to a view. A view selector1118indicates one or more constraints to be matched to select a view that is to be modified. In some embodiments, constraints can include view properties such as view class object type, structural relationships between views such as a superview/subview (parent/child) relationship, and visual appearance properties. Examples of visual appearance properties include color and text size and font.

In response to a determination by decision module104that one or more selectors require evaluation in response to the most recent trigger event, module106configures the device to choose a selector1118stored in device1212for evaluation. Decision module108configures the device to determine whether each of one or more constraints of a currently chosen selector matches properties of a subview hierarchy of one or more views of an impending view hierarchy that is to be used to generate an upcoming user interface display. In response to a determination by decision module108that each constraint of the chosen selector matches a property of a subview hierarchy of a view within an impending view hierarchy, module110configures the device to modify the view hierarchy according to a modification1116stored in device1212in association with the currently chosen first selector. Control next flows back to decision module104. In response to a determination by decision module108that at least one constraint of the chosen selector does not match a property of a view within the impending view hierarchy, control flows to decision module104.

In response to a determination by decision module104that there are no first view selectors that remain to be evaluated in response to the most recent trigger event, control flows to module112, which configures the device to use the impending view hierarchy, as modified by module110to include each change required by each matching first view selector, to generate a next user interface display. If no changes were made by module110, then module112configures the device to use the impending view hierarchy, as originally configured, to generate a user interface for display on a device display screen.

FIG.3Ais an illustrative flow diagram representing a process200to track occurrence of events within a user interface display in accordance with some embodiments. Module202configures the device to receive an indication of an occurrence of a user input event, such as a click or selection of a particular user interface element or scrolling, for example. In response to an occurrence of a user input trigger event, decision module204determines whether one more second view selectors are associated with the application, and if so, whether one or more second view selectors that are determined to be associated with the application have not yet been used to evaluate whether to track a view used by the application in response to the user input event.

As explained more fully below with reference toFIG.11-14, a computer readable storage device1212can store one or more information structures1114that associate event tracking indicators1120with second view selectors1122. A view tracking indicator1120indicates view usage to be tracked. A second view selector1122indicates one or more constraints to be matched to select a view usage to be tracked. In some embodiments, constraints can include view properties such as view class object type, visual appearance and layout. Examples of visual appearance properties include color and text font. Examples of layout properties include structural relationships among views in a subview hierarchy.

In response to a determination by decision module204that one or more second view selectors require evaluation in response to the most recent user input trigger event, module206configures the device to choose a second view selector1122for evaluation. Decision module208configures the device to determine whether each of one or more constraints of a currently chosen second view selector1122matches a property of a subview hierarchy of one or more views determined to be used in response to the user input. In response to a determination by decision module208that each constraint of the chosen second view selector matches a property of a subview hierarchy of the view used in response to the user input, module210configures an event indicator1120associated in the device1212with the currently selected second view selector1122to report usage of the view. Control next flows back to decision module204. In response to a determination by decision module208that at least one constraint of the chosen second view selector does not match, control flows to decision module204. In response to a determination by decision module204that there are no (additional) second view selectors1122that require tracking in response to the most recent user input trigger event, the process200ends.

It will be appreciated that user interaction with an application user interface, such as clicking a control button, typically triggers a change in a view hierarchy which in turn results in a change in the user interface display. Thus, reporting a view hierarchy change, in effect, reports the user action that triggered the change. The reported user interactions can be used, for example, for AB testing to ascertain user reaction to runtime changes to user interface elements of an application user interface.

It will be understood that the first and second view selectors1118,1122may be one and the same so as to track usage of views that have been modified.

FIG.3Bis an illustrative flow diagram representing a process250to track occurrence of events within a user interface display in accordance with some embodiments.FIG.3Cis an illustrative drawing of a monitor process260to monitor user input to a visual user interface element identified using the process of

FIG.3Bin accordance with some embodiments. It will be appreciated that the process200is similar to process250. Only those portions of the process250that differ from the monitor process200shall be described. Specifically, in response to a determination by decision module208that each constraint of the chosen second view selector matches a property of a subview hierarchy of the view used in response to the user input, a process260that includes a decision module262that monitors user input to identify user input using to a visual user interface element that corresponds to a subview hierarchy identified by decision module208as matching a chosen second view selector. While the decision module262continues to monitor, a decision module264monitors the view hierarchy to determine whether the visual user interface element continues to be displayed. If decision module264determines that it is no longer being displayed, then the process260ends. If decision module264determines that it is still being displayed then decision module262continues to monitor for user input. In response to decision module262determining that user input is provided to the visual user interface element, module266reports the user input corresponding to the matching subview hierarchy.

It will be appreciated, for example, that the visual user interface element may be a button or slider or other user interface input element, and that the processes250,260can be used to detect and report user input using the user interface element. Moreover, as mentioned above, it will be appreciated that multiple user input elements can be monitored simultaneously using the processes250,260.

Triggering Selector Operation

In accordance with some embodiments, module102can use a wrapper to detect a trigger event as explained with reference toFIG.4. In accordance with some embodiments, module102can use “swizzling” to detect a trigger event as explained with reference toFIG.5.

FIG.4is an illustrative object class diagram that represents a relationship between a view controller object and a wrapper object in accordance with some embodiments. In general, a wrapper object class, which sometimes is referred to as a proxy, “wraps” or “encapsulates” functionality of another object class. View controllers control the creation of view hierarchies in order to change an application user interface view. Since user interface views may change frequently view controllers and view hierarchies used to generate the different views are created and dismissed frequently. In accordance with some embodiments, in the course of creating a view controller902, a wrapper904also is created that “wraps” the view controller902. The view controller902can include an add view function906and can include additional functions x, y, etc. The wrapper904also includes a corresponding add view function908and corresponding additional functions x′, y′, etc. In operation, the wrapper904intercepts calls to the view controller902. In response to an intercepted call905to the add view function906, the wrapper's add view function908triggers the process100ofFIG.2, which can result in modification of one or more properties of a view hierarchy that includes the view that is to be created in response to the call. The wrapper's add view function908then calls the view controller's add view function906to add the view. In response to intercepted calls to functions x or y, for example, the wrapper's corresponding functions x′ and y′ call the view controller's x and y functions, for example.

FIG.5is an illustrative object class diagram that represents an object class in which a method has been “swizzled” in accordance with some embodiments. As used herein the term “swizzle” refers to substitution of a method into a class that makes use of the substituted for method as if for example, the substituted for function acts as a subclass of the added method.FIG.5shows an example view class1002that includes methods a and c and substituted method b. In response to a call1004to method b to add a view, for example the object1002calls the swizzled method b′ code1006instead. The swizzled method b′ code triggers the process100ofFIG.2, which can result in modification of one or more properties of a view hierarchy that includes the view that is to be created in response to the call. The swizzled method b′ then calls the method b code1008to add the view.

First Example View Selector Match Determinations

FIG.6is an illustrative drawing representing an example application user interface screen display1500produced by an application at runtime. The example screen display includes a window region1502, a first user interface element (UIEI)1504, a second user interface element (UIE2)1506and a third user interface element (UIE3)1508. It will be appreciated that first UIE11504can be a background element that completely obscures the window element1502and that UIE21506and UIE31508each partially obscures the first UIE11504.

FIG.7Ais an illustrative drawing representing an example application view hierarchy1700used by an application to produce the user interface screen display1500ofFIG.6in accordance with some embodiments. The view hierarchy1700can be stored in a non-transitory computer readable storage device. Structural relationships between views in a view hierarchy define traversal paths between views in the view hierarchy. The traversal paths can be used during rendering of visual interface elements to determine which visual interface elements are most closely related to each other in a user interface display. More particularly, in accordance with some embodiments, structural relationships include view-subview relationships between views.

More specifically, for example, at the top of the view hierarchy1700is a viewWINDOW1702. An index structure labeled (0), which may include a pointer structure and which is disposed between the viewWINDOW1702and a first view (ViewUIE1)1704, indicates a hierarchical traversal path between the viewWINDOW1702and a first view (ViewUIE1)1704. In a hierarchical relationship defined by the index structure labeled (0) between the viewWINDOW

1702and the first view (ViewUIE1)1704, the first view (ViewUIE1)1704is a subview of the viewWINDOW1702. Thus, the first view (ViewUIE1)1704has a subview structural relationship with viewWINDOW1702. The first view (ViewUIE1)1704is used, during rendering, to generate the first user interface element UIE11504.

An index structure labeled (0), which may include a pointer structure and which is disposed between the first view (View UIE1)1704and a second view (ViewUIE2)1706, indicates a hierarchical traversal path between the first view (ViewUIE1)1704and the second view (ViewUIE2)1706. In a hierarchical relationship defined by the index structure labeled (0) between the first view (ViewUIE1)1704and the second view (ViewUIE2)1706, the second view (ViewUIE2)1706is a subview of the first view (ViewUIE)1704. Thus, the second view (ViewUIE)1706has a subview structural relationship with the first view (ViewUIE1)1704. The second view (ViewUIE2)1706is used to generate the second user interface element UIE21506.

An index structure labeled (1), which may include a pointer structure and which is disposed between the first view (View UIE1)1704and a third view (ViewUIE3)1708, indicates a hierarchical traversal path between the first view (ViewUIE1)1704and the third view (ViewUIE3)1708. In a hierarchical relationship defined by the index structure labeled (1) between the first view (ViewUIE1)1704and the third view (ViewUIE3)1708, the third view (ViewUIE3)1708is a subview of the first view (ViewUIE1)1704. Thus, the third view (ViewUIE3)1708has a subview structural relationship with the first view (ViewUIE1)1704. The third view (ViewUIE3)1708is used to generate the third user interface element UIE31508.

Moreover, the index (0) and the index (1) are “ordered” within a hierarchy level in that each is associated with the same view, i.e. the both indices (0) and (1) are associated with the upper first view1704, but each index is associated with a different lower subviews, i.e. index (0) is associated with the second view1706and index (1) is associated with the third view1708.

In accordance with some embodiments, a first ViewCONTROLLER1710controls the first view (ViewUIE1)1704. A second ViewCONTROLLER1712controls the second view (ViewUIE2)1706. A third ViewCONTROLLER1714controls the third view (ViewUIE3)1708. The first ViewCONTROLLER1710also manages the second ViewCONTROLLER1712and the third ViewCONTROLLER1714.

Thus, structural relationships among the first view1704and the second and third views1706and1708are further defined in terms of index properties, which can correspond to pointer structures, that can be used to define traversal paths from one view to another within a view hierarchy. The first view1704includes a first index labeled (0) and a second index labeled (1). The second view1706is associated with the first index (0) of the first view1704. The third view is associated with a second index (1) of the first view1704.

It will be appreciated that the indices (0) and (1) of the first view1704are associated with a different traversal paths. The association of the first index (0) with the second view1706defines a traversal path from the first view1704to the second traversal path1706. The association of the second index (1) with the third view1708defines another traversal path from the first view1704to the third traversal path1706.

Furthermore, in the illustrative drawings ofFIGS.7A-7BandFIGS.8A-8C, described below, labels placed on the different component views represent visual properties of the views. Thus, for example, the first view1704has visual property “VUIE1”. The second view1706has visual property “VUIE2”, and the third view1708has visual property “VUIE3”. It will be appreciated that these labels are used to simplify the explanation and that actual visual properties may include color, text size, font size, images, background color, text color, text style (e.g., bold or italic), font face, text alignment, view width/height, position, padding, orientation and visibility, for example.

FIG.7Bis an illustrative drawing that shows an application subview hierarchy1750that may act as a view selector, during processes100and200, in accordance with some embodiments. The application subview hierarchy/view selector1750can be stored in a non-transitory computer readable storage device. The application subview hierarchy1750includes as visual property constraints, the third view (ViewUIE3)1708, the first view (View UIE1)1704and the viewWINDOW1702. It will be appreciated that the application subview hierarchy1750manifests the structural property constraints of its components, and that these structural property constraints act as selector constraints when the application subview hierarchy1750acts as a view selector during processes100,200. The application subview hierarchy1750includes as a first structural property constraint, the view-subview relationship between the Window1702and the first view1704, indicated by the index labeled (0) between the Window1702and the first view1704. The application subview hierarchy1750includes as a second structural property constraint view-subview relationship between the first view1704and the third view1708, indicated by the index labeled (1) between the first view1704and the third view1708.

Thus, the application subview hierarchy1750defines a structural traversal path that leads to and thereby identifies the third view1708. In particular, the traversal path starts with the Window1702, at the top of the application subview hierarchy1750, passes through the first view1704, and ends with the third view1708at the bottom of the subview hierarchy1750. The third subview1708can be identified by following the traversal path defined by the subview hierarchy1750.

The respective visual properties VUIE1, VUIE2 and VUI3 of the components1704,1706and1708also can act as constraints when the subview hierarchy1750acts as a view selector during processes100and200, although in the illustrative examples involving view hierarchies1900,1920and1940, discussed below, the focus is on structural relationships among views that define traversal paths.

It will be appreciated that the Window1702acts as a “root” node of the application subview hierarchy acting as a view selector1750, and that the third view1708acts as a bottom node of the application subview hierarchy acting as a view selector1750. In accordance with some embodiments, a matching determination according to respective decision modules108and208is used to determine whether there exists a view hierarchy in an application view hierarchy that matches the application view hierarchy1750acting as a selector. It will be appreciated that although the third subview1708is at the bottom of the selector subview hierarchy1750, and therefore acts as a “leaf node”, a selector subview hierarchy need not include a leaf node. In other words, a selector can match a view within an application view hierarchy even though the application view hierarchy contains views beneath the bottom view in the selector view hierarchy.

FIGS.8A-8Cshow three different illustrative example application view hierarchies1900,1920and1940that can be generated by the same example application that generates the illustrative view hierarchy1700ofFIG.7A. These three example view hierarchies are used to generate three different user interface displays (not show). In accordance with some embodiments, the processes100and/or200ofFIGS.2-3determine whether the subview hierarchy1750ofFIG.7B, acting as a view selector, selects, and therefore identifies, a view in any of the three example view hierarchies1900,1920,1940for modification and/or tracking. More specifically, in accordance with some embodiments, decision modules108and208of respective processes100and200determine whether there is a match of structural and visual properties of the application subview hierarchy1750, which acts as a view selector, and one or more of the example subview hierarchies view hierarchies1900,1920,1940.

FIG.8Ais an illustrative drawing representing an example first application view hierarchy1900that is produced at runtime in the course of the running of the application. At the top of the view hierarchy1900is a viewWINDOW1902. The first view hierarchy1900includes a first view (ViewUIE1)1904, which is a subview of the viewWINDOW1702. The view hierarchy1900includes an “X” view (ViewUIEX)1906, which is a subview of the ViewUIE11904. Assume that in this illustrative example, VUIEX1906ofFIG.8Aand VUIE21706ofFIG.7Arepresent different visual properties that do not match. The view hierarchy1900includes a third view (ViewUIE3)1908, which is a subview of the ViewUIE11904. A first ViewCONTROLLER1910controls the first view (ViewUIE1)1904. An X ViewCONTROLLER1912controls the “X” view (ViewUIEX)1906. A third ViewCONTROLLER1914controls the third view (ViewUIE3)1908. The first ViewCONTROLLER1910also manages the “X” ViewCONTROLLER1912and the third ViewCONTROLLER1914.

FIG.8Bis an illustrative drawing representing an example second application view hierarchy1920that is produced at runtime in the course of the running of the application. At the top of the view hierarchy1920is a viewWINDOW1922. The second view hierarchy1920includes a first view (ViewUIE1)1924, which is a subview of the viewWINDOW1922. The view hierarchy1920includes second view (ViewUIE2)1926, which is a subview of the ViewUIE11924. The view hierarchy1920includes a third view (ViewUIE3)1928, which is a subview of the ViewUIE11924. The view hierarchy1920includes a “Y” view (ViewUIEY)1929, which is a subview of the ViewUIE11924. A first ViewCONTROLLER1930controls the first view (ViewUIE1)1924. A second ViewCONTROLLER1932controls the second view (ViewUIE2)1926. A third ViewCONTROLLER1934controls the third view (ViewUIE3)1928. A “Y” ViewCONTROLLER1936controls the “Y” view (ViewUIEY)1929. The first ViewCONTROLLER1930also manages the second ViewCONTROLLER1932, the third ViewCONTROLLER1934and the Y ViewCONTROLLER1936.

FIG.8Cis an illustrative drawing representing an example third application view hierarchy1940that is produced at runtime in the course of the running of the application. At the top of the view hierarchy1940is a viewWINDOW1942. The third view hierarchy1940includes a first view (ViewUIE1)1944, which is a subview of the viewWINDOW1942. The third view hierarchy1940includes third view (ViewUIE3)1948, which is a subview of the ViewUIE11944. The third view hierarchy1940includes a second view (ViewUIE2)1946, which is a subview of the ViewUIE31948. A first ViewCONTROLLER1950controls the first view (ViewUIE1)1944. A third ViewCONTROLLER1952controls the third view (ViewUIE3)1948. A second ViewCONTROLLER1954controls the second view (ViewUIE2)1946.

Referring to the first application view hierarchy1900ofFIG.8Aand to the application subview hierarchy1750ofFIG.7B, which acts as a selector, there is a match since an application subview hierarchy1906within the application view hierarchy1900contains components1902,1904and1908that have structural property relationships and visual properties that match corresponding property constraints defined by components1702,1704and1708of application/selector subview hierarchy1750. Specifically, a traversal path from view1904to view1908proceeds via the second index (1) of view1904, which matches the traversal path constraint from view1704to view1708in view selector1750, which proceeds via the second index (1) of view1704. Additionally, view1904of view hierarchy1900includes visual properties “VUIE1” that match the selector visual property constraints “VUIE1” of the first view1704of the view selector1750, and view1908of view hierarchy1900includes visual properties “VUIE3” that match the selector visual property constraints “VUIE3” of the third view1708of the view selector1750. Accordingly, the view selector1750that has view1708matches the subview within view hierarchy1900that that includes view1908. In accordance with some embodiments, decision modules108,208determine that the view1908, which corresponds to the leaf node view of the view selector1750, is to be modified pursuant to process100and or have its usage tracked pursuant to process200.

Still referring to the first application view hierarchy1900ofFIG.8A, the subview containing Window1902, view1904and view1906does not match the view selector1750. In particular, the traversal path that arrives at view1906in the view hierarchy1900is different from the traversal path constraint in the view selector1750that arrives at leaf view1708. Specifically, a traversal path from view1904to view1906proceeds via the first index (0) of view1904, which does not match the traversal path constraint from view1704to view1708, which proceeds via the second index (1) in view selector1750. Furthermore, the visual properties “VUIEX” of the view1906of the view hierarchy1900do not match the visual property constraint of the view1708of the view selector1750.

Referring now to second view hierarchy1920ofFIG.8Band to the view selector1750ofFIG.7B, there is no match. In particular, although the selector visual property constraints of the component views1702,1704and1708of the application/selector subview hierarchy1750match the visual properties of component views1922,1924and1928of view hierarchy1920, their structural properties do not match. More specifically, in the application/selector view hierarchy1750ofFIG.7B, view property constraint1708is associated with the second index (1) of view property constraint1704, but in the view hierarchy1920ofFIG.8Bview1928is associated with a third index labeled (2) of view1924. Accordingly, decision modules108and208determine that no view of the second view hierarchy1920need be modified or tracked.

Referring to third application view hierarchy1940ofFIG.8Cand to the view application/selector1750ofFIG.7B, there is no match. Even though components1942,1944and1948of the third view hierarchy1940have visual properties that match those of respective property constraints1702,1704and1708of the application/selector subview hierarchy1750, the structural relationships among them do not match. More specifically, in the selector view hierarchy1750ofFIG.7B, view property constraint1708is associated with the second index (1) of view property constraint1704, but in the view hierarchy1940ofFIG.8C, view1948is associated with the first index labeled (0) of view1944. Accordingly, decision modules108and208determine that no view of the third view hierarchy1940need be modified or tracked.

Second Example View Selector Match Determinations

In accordance with some embodiments, property constraints associated with a subview hierarchy that is used to act as a view selector can be weakened so that the view selector can match a wider range of views used in a view hierarchy.FIGS.9A-9Care illustrative drawings showing the same illustrative example view hierarchy, which includes views2002-2016labeled to indicate their visual color properties: R (red), B (blue), G (green) and Y (yellow).FIG.9Ashows the application view hierarchy2000labeled to show a second traversal path2018.FIG.9Bshows the application view hierarchy2000labeled to show the second traversal path2020and a third traversal path2022.FIG.9Cshows the application view hierarchy2000labeled to show a fourth traversal path2024.

FIG.10Ais an illustrative drawing representing a first selector view information structure2101defined based upon the view hierarchy2000.FIG.10Bis an illustrative drawing representing a second view selector information structure2102defined based upon the view hierarchy2000. The second view selector information structure2102sets forth fewer constraints, and therefore, can be used to identify a larger number of views in a view hierarchy (not shown) to be modified and/or tracked.FIG.10Cis an illustrative drawing representing a third view selector information structure2103defined based upon the view hierarchy2000. The third view selector information structure2103sets forth different combination of color constraints than the first and second structures2101,2102.

The first view selector information structure2101ofFIG.10Arepresents a selector subview hierarchy, indicated inFIG.9Aby the views (2002,2004,2008,2012) that are intersected by dashed lines2018, which represents a first traversal path. The first view selector information structure2101(also referred to as the “first view structure2101”) is a representation of the subview hierarchy indicated by dashed lines2018. A first row of the first view structure2101corresponds to view2002and indicates that the selector view color property constraint is R and the selector view structure property constraint is the first index (0), which indicates a subview relationship with a selector view color property constraint corresponding to view2004. A second row of the first view structure2101corresponds to view2004and indicates that the selector view color property constraint is B and the selector view structure property constraint is the second index (1), which indicates a subview relationship with a selector view color property constraint corresponding to view2008. A third row of the first view structure2101corresponds to view2008and indicates that the selector view color property constraint is G and the selector view structure property constraint is index (0), which indicates a subview relationship with a selector view color property constraint corresponding to view2012, and indicates that the selector view color property constraint is Y. Since view2012is a leaf node view, its structure property constraint is “blank”, i.e. “don't care”. Thus, the first view structure2101corresponds to a first traversal path represented by dashed lines2018inFIG.9Athat proceeds from view2002followed by view2004followed by view2008followed by view2012. The decision modules108and208can use the first view structure2101to identify a view that corresponds to the leaf node view2012that is to be modified and/or tracked.

FIG.10Bis an illustrative drawing representing a second view selector information structure2102defined based upon the view hierarchy2000. The second view selector information structure2102(also referred to as the “second view structure2102”) is stored in a computer readable storage device. As explained below, the second view structure2102can be used to determine whether a view hierarchy (not shown) includes views that match two views2010and2012.

The second view selector information structure2102ofFIG.10Brepresents a subview hierarchy, indicated inFIG.9Bby the combinations of views (2002,2004,2006,2010) and (2002,2004,2008,2012) respectively intersected by dashed lines2020and2022, which represents a second and third traversal paths. The second view selector information structure2102(also referred to as the “second view structure2102”) is a representation of the selector subview hierarchy indicated by dashed lines2020and2022. A first row of the second view structure2102, which corresponds to view2002, indicates that the selector view color property constraint is R and the selector view structure property constraint is index (0), which indicates a subview relationship with a selector view color property constraint corresponding to view2004. The first row, therefore, constrains the second view structure2102to match the color property of view2002and to follow the respective second and third traversal paths2020and2022, which are contiguous at this point, via index (0). A second row of the second view structure2102, which corresponds to view2004, indicates that the selector view color property constraint is B and the view structure property constraint is “blank”, i.e. “don't care”. In accordance with some embodiments, the designation “blank” indicates that no structure property is specified, and therefore, that no structural property constraint is defined to limit traversal paths flowing from view2004. In other words, this constraint is a “don't care”. The second row of the second view structure2102, therefore, constrains the second view structure2102to find a match the color property of view2004. However, the second row of the second view structure2102does not provide a structure property constraint. In the absence of a structural constraint (i.e. in the presence of a “don't care”), the visual property constraint that corresponds to view2004has a subview relationship with every selector view color property constraint that corresponds to view2004. Since the view2004has subview relationships with two subviews,2006,2008, two traversal paths emerge from the selector view color property constraint that corresponds to view2004: the third traversal path2022flows to a visual property constraint that corresponds to view2006and a second traversal path2020flows to a visual property constraint that corresponds to view2008. Thus, the “don't care” structural property constraint of the second row of the second view structure2102constrains the second view structure2102to find a color match to both view2006on the third traversal path2022and view2008on the second traversal path2020. A third row of the second view structure2102, which corresponds to views2006and2008, indicates that the selector view color property constraint is G and the selector view structure property constraint is index (0), which for the view color constraint that corresponds to view2006, indicates a subview relationship with a selector view color property constraint corresponding to view2010; and which for the view color constraint that corresponds to view2008, indicates a subview relationship with a selector view color property constraint corresponding to view2012. A fourth row of the second view structure2102, which corresponds to views2010and2012, indicates that the selector view color property constraint is Y and the selector view structure property constraint is blank, “don't care.” The fourth row of the second view structure2102, therefore, constrains the second view structure2102to find a color match to both view2010on the third traversal path2022and to view2012on the second traversal path2020.

Thus, the second selector view hierarchy information structure2102defines the third traversal path2022that includes constraints that correspond to view2002followed by constraints that correspond to view2004followed by constraints that correspond to view2006followed by constraints that correspond to view2010. The second view hierarchy information structure2102also defines the second traversal path2020that includes constraints that correspond to view2002followed by constraints that correspond to view2004followed by constraints that correspond to view2008followed by constraints that correspond to view2012. Decision modules108and/or208use the third traversal path2022defined by the second view structure2102to determine whether there is a view in a runtime view hierarchy (not shown) that corresponds to view2010that is to be modified and/or tracked. Decision modules108and/or208use the second traversal path2020defined by the second view structure2102to determine whether there is a view in a runtime view hierarchy (not shown) that corresponds to view2012that is to be modified and/or tracked. In accordance with some embodiments, a match is determined in response to a view hierarchy matching of both the second and third traversal paths2020,2022.

FIG.10Cis an illustrative drawing representing a third selector view information structure2103defined based upon the view hierarchy2000. The third view selector information structure2103(also referred to as the “third view structure2103”) is stored in a computer readable storage device. As explained below, the third view structure2103can be used to determine whether a view hierarchy (not shown) includes a view that matches view2014. The third view selector information structure2103ofFIG.10Crepresents a subview hierarchy, indicated inFIG.9Cby the views (2002,2004,2008,2014) that are intersected by dashed line2024, which represents a fourth traversal path. The third view selector information structure2103(also referred to as the “third view structure2103”) is a representation of the subview hierarchy indicated by dashed lines2024. A first row of the third view structure2103, which corresponds to view2002, indicates that the selector view color property constraint is R and the view structure property constraint is index (0), which indicates a subview relationship with a selector view color property constraint corresponding to view2004. A second row of the third view structure2103, which corresponds to view2004, indicates that the selector view color property constraint is B and the view structure property constraint is index (1), which indicates a subview relationship with a selector view color property constraint corresponding to view2008. A third row of the third view structure2103indicates that the selector view color property constraint is G and the selector view structure property constraint is blank, “don't care”. In the absence of a structural constraint (i.e. in the presence of a “don't care”), the visual property constraint that corresponds to view2008has potential subview relationships with every selector view color property constraint that corresponds to view2004. Since the view2008has subview relationships with three subviews,2012,2014and2016, three potential traversal paths emerge from the selector view color property constraint that corresponds to view2008. However, only the traversal path corresponding to index (1) corresponds to a view (view2014) that has a visual property value that matches a visual property constraint (Green) specified in the third row of the third view structure2103. Thus, only one path emerges from the visual property constraint corresponding to view2008despite there being three possible paths due to the “don't care” structural property constraint. A fourth row of the third view structure2103, which corresponds to view2014, indicates that the selector view color property constraint is G and the selector view structure property constraint is blank. Thus, the third view structure2103defines the fourth traversal path2024that includes constraints that correspond to view2002followed by constraints that correspond to view2004followed by constraints that correspond to view2008followed by constraints that correspond to view2014. Decision modules108and/or208use the fourth traversal path2024defined by the third view structure2103to determine whether there is a view in a runtime view hierarchy (not shown) that corresponds to view2014that is to be modified and/or tracked.

Persons of ordinary skill in the art will appreciate that although the illustrative example first, second and third view structures2101,2102and2103designate traversal paths in terms of specific indexes, e.g., (0), (1), (2), it is also possible to designate traversal paths in more qualitative terms such as the path that traverses the largest number of view having the color property blue, for example.

The following are a few illustrative examples of other possible constraints that can be used in a selector in accordance with some embodiments. A constraint may depend upon properties of an element in a traversal path. For example, an element X might be determined to match only if, somewhere in the view hierarchy, there is a view displaying the label “Price”, and this label is configured to render to the left of X. A constraint may involve comparing or quantifying properties over several views. For example, the above “most blue elements” example is in the spirit of this. Another example is choosing a view that takes up the most space on the screen. Constraints also may involve more complicated checks on visual properties. For example, a selection may be made on an element only if a spam filtering algorithm determines that its text is likely spam.

System to Develop Application Modifications and Selectors

FIG.11is an illustrative functional block diagram representing a system1100and its operation in developing information structures for use to dynamically change a user interface of a computer program code application running on a wireless device in accordance with some embodiments. The system1100includes a developer computer1102, a network communications server1104and a client device1106. The developer computer is operatively coupled to a computer readable first storage device1108that stores the application1110. In some embodiments, the client device1106can be a wireless communication device that can run the application. The network communications server1104provides network communication services to the developer computer1102and the client device1106so that they can communicate during development. In some embodiments, the client device is capable of wirelessly downloading of the application1110from the server1104.

In operation, the developer computer1102is used to create first and second information structures1112,1114, sometimes referred to as “metadata”, that are stored in the first storage device1108. The first information structure1112includes an modification information1116used by an instance of the application1110running on the client device1106. The first information structure also includes a view selector information1118used to select a view to be modified. The first information structure1112associates the indication of a modification1116with the selector information1118. The second information structure1114includes an event tracking indication1120that indicates an application event to track. The second information structure1114also includes view selector1122used to select a view associated with an event to track. The second information structure1114associates the tracking indication1120with the selector information1122.

In operation, the developer computer1102runs the application1110while a developer (not shown) enters information to create the first and second information structures1112,1114. Example details of the entry of information to create the information structures1112,1114and example information structures are discussed below with reference to Examples 1 and 2 andFIGS.15A-17C. As indicated by the arrow1124, the computer1102transmits the information structures1112,1114to the server1104. As indicated by arrow1126, the server1104, in turn, transmits the information structures1112,1114to the client device1106. The transmissions1124,1126may involve communications over a wireless network in order to test the effectiveness of wireless delivery of the information structures1112,1114.

The client device is operatively coupled to a computer readable second storage device1128that stores an instance of the application1110and the received copies of the first and second information structures1112,1114. The client device1106uses the first and second information structures to implement changes to and tracking of the application1110. Details of processes to make changes and implement tracking are discussed below with reference toFIGS.2-3. As indicated by arrow1130, the client device1106transmits to the server1104one or more screen captures of the user interface as modified using the information structure1112. As indicated by arrow1132, the server, in turn sends the screen captures to the developer computer1102so that the developer can evaluate whether or not changes are satisfactory.

System to Deliver Application Modifications and Selectors and Track Usage

FIG.12is a generalized block diagram representing a system1200that includes a plurality of user devices1202that run the computer program code application1110that can be operatively coupled via a network1204with a server system1206that can transmit information structures1208to the devices1202and that can receive tracking information from the devices1202. The server system1206acts as a monitoring system to receive messages from user devices1202indicating use of certain application subview hierarchies to generate user interface displays. More specifically, the server system1206is operatively coupled to a storage device1210that stores a plurality of information structures that can be created using the system1100ofFIG.11, for example. Each respective device includes storage1212that can store the application1110that can run on the device and that can store metadata that includes one or more information structures1208. It will be appreciated that there can be many different information structures to implement different changes and different tracking, for example.

In operation, the application running on a given device1202periodically configures its device1202to transmit a request indicated by arrows1214to the

server system1206to request information structure updates. In response, the server system1206transmits to the device1202one or more information structures as indicated by arrows1216. The devices1202implement the processes ofFIGS.23, for example. The devices periodically transmit to the server system1206tracking information as indicated by arrows1218.

Developer UI and Process to Create Modification Information and View Selectors

FIG.13is illustrative flow diagram representing a process1400to create an information structure for use to configure a user device that runs an application to modify a view hierarchy used by the application to produce a user interface, in accordance with some embodiments. Module1402configures a developer computer, discussed with reference toFIG.11, to use the application to produce the example user interface screen display1500ofFIG.6. Module1404configures the developer computer to receive developer input indicating a user interface element from the user interface screen display1500that is to be changed. In response to the input, module1406produces a developer system user interface screen display that indicates a menu of changes that can be made to a view that corresponds to a selected user interface element. Assume, for example, that module1404receives developer input that indicates that the UIE31508is chosen for modification. In response to the example input, module1406generates the example developer system user interface screen display1600ofFIG.14. The screen display1600includes a left-side region1602that shows the UI display1500in which the selected third user interface element1508, which is to be modified, is displayed highlighted. The screen display1600includes a right-side region1604that shows a property change menu display1606that user interface elements to receive changes to be made to the view1708, shown inFIG.7A, used to produce the selected third user interface element1508. Module1408configures the developer computer to receive developer input to the property change menu display indicating changes to make to the selected UIE31508. Decision module1410determines whether the inputted changes include input that indicates a change to the view1708that corresponds to the selected user interface element UIE31508. In response to a determination by decision module1410that the developer input indicates a change to the view1708, module1412generates modification information that can be used to make the indicated change. Module1414generates and stores in a non-transitory computer readable storage device an information structure that associates the modification information with a copy of the subview hierarchy, such as subview hierarchy1750that identifies view1708, and the process1400ends. Also, in response to a determination by decision module1410that the developer input indicates that no change is to be made to the corresponding view1708, the process1400ends.

Example 1—Details of Example User Interface and Information Structure Code Creation

FIGS.15A-15Eare illustrative drawings representing a sequence of developer system user interface screen displays used to designate a first change in an application user interface of a device in accordance with some embodiments.FIG.15Fis an illustrative drawing representing a developer system user interface screen displays used designate a first event related to the first change in the application user interface of a device in accordance with some embodiments. FIGS.16A1-16A2and FIGS.16B1-16B2are illustrative drawings representing an example first information structure and an example second information structures stored in a computer readable storage device that are created in response to user input provided in connection with the example screen displays ofFIGS.15A-15F. In accordance with some embodiments, the first and second information structures are provided in a json file format. FIG.16A1-16A2shows an illustrative first example information structure that indicates a change to be made to a view hierarchy and that provides a first selector used to identify a view hierarchy to which the change is to be applied. FIGS.16B1-16B2shows an illustrative second example information structure that indicates an event to be tracked and that provides a second selector used to identify a view hierarchy to in which an event is to be tracked.

FIG.15Ais an illustrative drawing showing a developer system first user interface screen display with three fields that is produced on a developer computer system. A center field shows an application user interface display generated using a view hierarchy (not shown) generated using an application that is to be modified and tracked. In this example, the application user interface includes an illustrative thread of text chat bubbles containing example text messages, message6to message14. The user interface also includes an application user interface element in the form of a control button labeled “Send”. A left-side field and a right side field of the developer system user interface include some basic instruction for configuring a change to the portion of an application user interface shown in the center field.

It will be appreciated that the portion of an application user interface shown in the center field ofFIG.15Acorresponds to a view hierarchy (not shown) that is generated by a computer program code application, and that the view hierarchy is used to actually generate that interface portion on the developer system. During the display of the interface portion on the developer system, the view hierarchy used to generate the interface portion is accessible in a computer readable storage device of the developer system. The view hierarchy can be accessed and modifications to the interface portion can be specified and associated with a selector, as explained below with reference toFIGS.15B-15E. Subsequently, an instance of the same view hierarchy may be generated by an application running on a client device. A selector produced as explained below with reference toFIGS.15B-15Ecan be delivered to the client device and can be used in a comparison process described above with reference toFIGS.2-3, for example, to determine when the view hierarchy used to produce the interface portion shown inFIG.15Ais generated on the client device, so that the modifications specified using the developer system can be made to the view hierarchy generated on the client device so as to as to make corresponding changes to its application user interface.

FIG.15Bis an illustrative drawing showing a second developer user interface screen produced on a developer system in response to a developer selecting an application user interface element for modification. In response to the developer's selection of the Send button, the center field shows the non-selected user interface elements, the chat bubbles and their text, greyed or dimmed so that the Send button shows or stands out as if highlighted. Also in response to the developer's selection of the Send button, the right column is changed to provide a property change menu display with a heading, “Button States” and a menu of button property selectors that can be adjusted to change button properties, which in this example, are title color, title shadow, font face, font size and background color. The property values shown inFIG.15Bare the properties of the selected button as it exists in the application prior to entry of any changes by the developer. For example, in the screen ofFIG.15B, the text, “Send” appears in the text property field of the menu.

Still referring to the developer system user interface screen ofFIG.15B, the menu also includes a selection field, “Show advanced properties”, that a developer can select to display an expanded menu (not shown) of button properties that can be changed. The right-side menu also includes four button state selection fields, “disabled”, “highlighted”, “normal” and “selected”. In this example, the “normal” button state is selected. A like menu of button property selectors is provided for each state by selecting the appropriate field. For example, selecting the “highlighted” field provides the menu for the button in the “highlighted” state. A developer, for example, might select the title color red for the button in the “highlighted” state and select the title color green for the button in the “normal” state.

FIG.15Cis an illustrative drawing showing a third user interface screen produced in a developer system in response to a developer replacing the text “Send” in the text property field in the “normal” state with the text, “Ok”. It is noted that the center field shows all text removed from the selected button. The left-side field identifies the property changes. In this screen example, the left-side screen indicates that in the “disabled”, “highlighted” and “selected” states, the text property is, “Send”. In the “normal” state, the text property is “Ok”.

FIG.15Dis an illustrative drawing showing a developer system fourth user interface screen produced in response to a developer user replacing the text, “Send”, in the text property fields of each of the “disabled”, “highlighted”, “normal” and “selected” states with the text, “Ok”. In this next screen example, the left-side screen indicates that in the “disabled”, “highlighted”, “normal” and “selected” states all have the text property, “Ok”.

FIG.15Eis an illustrative drawing showing a developer system fifth user interface screen used to save the changes made by a developer to the application in accordance with some embodiments. This developer system user interface screen includes a field labeled “+ ADD ANOTHER VARIATION” that can be selected to add a new row which allows the developer to name a variation and edit its styles, for example. This developer system user interface screen includes a field labeled “SET WYSIWYG GOALS” ‘that can be selected to set tracking goals to track events related to the selected button.

FIG.15Fis an illustrative drawing showing a sixth developer user interface screen produced on a developer system used to register an event to track in relation to the selected button in accordance with some embodiments. A left side of the screen display shows the non-selected user interface elements, the chat bubbles and their text, greyed or dimmed so that the Send button shows as stands out as if highlighted. A track menu is provided to select an event tracking goal for a chosen user interface element, the Send button. Thus, the developer system user interface screens can be used both to designate changes to a chosen user interface and to designate events to track that are associated with the designated changes to the user interface element.

Thus, in this example, changes are specified to a particular control button of an application program user interface. The specified changes are stored in a computer readable storage device. The user interface control button corresponds to a view hierarchy that is used to generate the control button display in the application user interface. The view hierarchy corresponding to the control button, or at least a portion of it, that is used to generate the original control button is stored in association with the specified changes so that it can act as a selector used to determine when an instance of the application program running on a different device generates a matching view hierarchy so that the designated changes can be made to it prior to generation of the control button.

In addition, an event associated with the control button can be specified, and the selector can be stored in association with the event specification. The selector can be used to determine when an instance of the application program running on a different device generates a matching view hierarchy so that the modified control button can be monitored for user input that corresponds to the designated event.

First and second information structures400and410provide example details of specified modifications and corresponding selectors in accordance with some embodiments.

More particularly, a first information structure400shown in FIGS.16A1-16A2includes an indication402that identifies its name: “Send button text”. It also provides an indication404of the hardware and software requirements of a device to which an application user interface change is to be applied. The first information structure400provides an indication406of changes to be made. In this example, the changes are to change the text property of the chosen application user interface button to “Ok” in each of the four button states: disabled, highlighted, normal and selected. The first information structure also provides a first selector408that includes constituents of the original view hierarchy used to generate the chosen user interface element of the application user interface. In this example, the chosen user interface element is the Select button, and the first selector408includes the constituents of the view hierarchy used to generate the “send” button in the application user interface. More specifically, the constituents include object classes and attributes within the view hierarchy and hierarchical relationships between them in the view hierarchy. Object classes within the first selector include: “UINavigationController”, “UILayoutContainerView”, “UILayoutContainerView”, “UIViewControllerWrapperView”, “UIParallaxDimmingView”, “UIWindow” and “UIButton”. Properties within the first selector include various “accessibilityKey” values and various “index”, values, for example.

The second information structure410shown in FIGS.16A1-16A2includes an indication412that identifies an event type: “clicked”. It also provides an indication414of the hardware and software requirements of a device to which an application user interface change is to be applied. The second information structure410provides a second selector418that includes constituents of the view hierarchy used to generate the user interface element of the application user interface that is to be tracked for the occurrence of events. In this example, the tracked application user interface element is the Select button, and the tracked event is the occurrence of “clicks” of that button. In this example the constituents of the second selector418are identical to the constituents of the first selector408.

In accordance with some embodiments, the first information structure400is used to configure a user device to change the text displayed on the button from “Send” to “Ok”, and the second information structure410is used to configure a user device to track the occurrence of click events involving the button having the substituted text, “Ok”. It is noted that one use for the first and second information structures is for testing, and that the first information structure400includes the heading “experiments”. In an experiment, for example, the first information structure400can be used to change the button text to “Ok”, and the second information structure can be used to configure the device to track each application user click on the button labeled “Ok” and to transmit information to a monitoring system, which tracks the number of clicks. Gathering such information from a variety of user devices that generate the application user interface can help to provide a measure of the impact that labeling the button with the text “Ok” has upon frequency of user's clicking the button, for example.

Example 2—Details of Example User Interface and Information Structure Code Creation

FIG.17Ais an illustrative drawing showing a seventh developer user interface screen display with three fields that is produced on a developer computer system. This example shows a center field that includes the same the application user interface ofFIGS.15A-15E, which includes an illustrative thread of message chat bubbles containing example text messages, message6to message14and the control button labeled “Send”. In response to a developer's selection of the message8chat bubble, the center field shows the non-selected user interface elements, the other chat bubbles, their text and the Send button, greyed or dimmed so that the message8chat bubble shows or stands out as if highlighted. Also in response to the developer's selection of the message8chat bubble, the right column is changed to provide a property change menu display with a heading, “Basic Properties” and a menu of button property selectors that can be adjusted to change chat bubble properties, which in this example, are font face, text alignment, text color, text and background color. The property values shown inFIG.17Aare the properties of the selected the message8chat bubble as it exists in the application prior to entry of any changes by the developer user.

FIG.17Bis an illustrative drawing showing an eighth developer user interface screen produced in a developer system in response to a developer changing the background color of the selected message8chat bubble. It can be seen that background color is changed using a pull-down menu that provides a UI control to change the relative Red, Green and Blue (RGB) color constituents. It can be seen that the background color of the message8chat bubble has been changed in response to the developer user color change input. It is noted that the left-side field indicates that a change in background color has been made.

The property change menu of the eighth developer user interface screen inFIG.17Bincludes a toggle button labeled “Select Similar Elements”. A ninth user interface screen shown inFIG.17Cis produced in response to a developer actuating the toggle button so as to apply the change to a wider range of user interface elements. No other changes are made to the property change menu in the ninth screen. In response to actuation of the toggle button, the toggle button now is labeled “Select Single Element”. Moreover, in response to actuation of the toggle button, all of the message chat bubbles on the left side of the chat thread now have their color changed to the color selected through the developer input provided in the eighth developer user interface screen shown inFIG.17B. Furthermore, those left-side message chat bubbles are shown in highlight relative to the greyed out right side message chat bubbles.

As explained more fully below, the left side message chat bubbles are constituents of a larger view that contains a message8chat bubble view. The developer input provided inFIG.17Bhas the effect of changing the background color of the single view encompassing message8chat bubble. As shown inFIG.17C, however, toggling the toggle button has the effect of changing the background color of all of the left-side chat bubbles which are encompassed in the same larger view as the message8chat bubble. More specifically, the developer user input ofFIG.17Brestricts the background color change to a single message chat element, and the developer input ofFIG.17Capplies the same background color change to similar message chat elements. Even more specifically, the left-side message chat elements are produced using a table structure in a view hierarchy in which each chat element is implemented as a table cell, which is lower in the view hierarchy than the table structure that contains the cells. Changing the toggle state as betweenFIGS.17B and17Chas the effect of removing a constraint upon application of the background color change to a single cell and causes the change to be applied instead to all similar cells in a table. In effect, the removal of the constraint upon application of the background color designates this constraint as a “don't care”.

Moreover, in accordance with some embodiments, changing the state of the toggle button has the effect of changing the structure of corresponding selectors. Referring toFIG.18, a third selector is shown that corresponds to developer user input of the eighth developer screen ofFIG.17Band that includes constituent property values that constrain the change to one user input element, i.e. to the message8chat bubble. Referring toFIG.19, a fourth selector is shown that corresponds to developer user input of the ninth developer screen ofFIG.17Cand that omits constituent property values that would constrain the change to a single user input element, and as a result, the changed background color is applied to all left-side message chat bubbles. In other words, the fourth selector includes a “don't care” for the constraint upon application of the background color.

The third information structure700shown inFIG.18includes an indication702that identifies its name: “change one cell”. It also provides an indication704of the hardware and software requirements of a device to which an application user interface change is to be applied. It is noted, that the example information structure uses a json format, as an example, which is hierarchical. For each variation, there is what is referred to as wysiwyg (what you see is what you get) data provided, and within the wysiwyg data, there are styles which are applied only if a device form factor and version number match. The third information structure700provides an indication706of changes to be made. In this example, the changes are to change the RGB background color. The third information structure also provides a selector708that includes constituents of a view hierarchy used to generate the chosen user interface element of the application user interface. In this example, the chosen user interface element is the message8chat bubble, and the selector708includes the constituents of the view hierarchy used to generate the message8chat bubble in the application user interface. More specifically, the constituents include object classes and attributes within the view hierarchy and hierarchical relationships between them in the view hierarchy. Object classes within the third selector include: “MainViewController”, “UITableView”, “SimpleTableItem2”, “UITableViewCell”, “UITableViewCellScrollView”, “UITableViewCellContentView” and “UILabel”, for example. Properties within the first selector include various “accessibilityKey”, “row”: 8 and “section”: 0 and various “index”, values, for example. Significantly, it is noted that the “SimpleTableItem2” class710includes properties “row”: 8712and “section”: 0714.

The fourth information structure800shown inFIG.19includes an indication802that identifies its name: “chat bubble colors”. It also provides an indication804of the hardware and software requirements of a device to which an application user interface change is to be applied. It is noted that in accordance with some embodiments, some modifications work on some platforms, but not all. For example, a change that works for a version of an application targeted for one type of smartphone device might not work for a type of different device such as a tablet computer, for example. Thus, in accordance with some embodiments selector constituents to be matched also may include device hardware and/or application software version, for example.

The fourth information structure800is identical to the third information structure except that its “SimpleTableItem2” class810does not include a properties “row” property or a “section” property. Consequently, the fourth information800structure provides fewer comparison constraints than the third information structure700.

Thus, it will be appreciated that in connection with theFIG.17Cdeveloper user interface example, not only is a specified change, i.e. a change in background color, stored, but also a view hierarchy used to generate the individual user interface element for which the change is specified is changed so that such changed view hierarchy matches view hierarchies of other user interface elements to which the change is to apply. More specifically, in this example, the view hierarchy used to generate the message8chat bubble is modified to remove constituents that limit it to a particular table cell. With the removal of the table cell constituents, the modified view hierarchy is no longer constrained to match only the table cell corresponding to the message8chat bubble, but also can match to the view hierarchies of other table cells also.

The foregoing description and drawings of embodiments in accordance with the present invention are merely illustrative of the principles of the invention. Therefore, it will be understood that various modifications can be made to the embodiments by those skilled in the art without departing from the spirit and scope of the invention, which is defined in the appended claims.