Patent Description:
This application is also a continuation-in-part of <CIT>; which claims benefit of priority to <CIT>.

Examples described herein relate to a network computing system and method to implement a design system, and more specifically, a design system to selectively implement layout configurations amongst object groupings of a design under edit.

Software design tools have many forms and applications. In the realm of application user interfaces, for example, software design tools require designers to blend functional aspects of a program with aesthetics and even legal requirements, resulting in a collection of pages which form the user interface of an application. For a given application, designers often have many objectives and requirements that are difficult to track.

<NPL>) pertains to a visual composition editor based on visual, non-visual and composite beans. The visual composition editor allows a user to select and place beans to create graphical user interfaces, and to use nonvisual beans to perform logic and data access. A layout manager, for which components including beans may be depicted individually or in groupings, can be assigned to a container. In a layout, a user can then define properties for the layout that govern the specifics of the sizing and resizing behavior for the components.

<CIT> pertains to shape elasticity in visual layouts, in which a target object undergoes resizing and/or repositioning related by containment to one or more related object laid out on a computer user interface. Original sizes and/or positions of the related objects to the target object resized and/or repositioned are stored. During the resize and/or reposition operation of the target object, an impact on a related object is calculated based upon a change from the stored original sizes and/or positions of the related object.

Examples include a computing system that operates to implement an interactive graphic design system for enabling users to selectively implement layout configurations amongst object groupings of a design under edit.

In examples, a computing system is configured to implement an interactive graphic design system for designer, such as user interface designers ("UI designers"), web designers, and web developers. An interactive graphic design system as described is used to generate user interfaces, including functional or dynamic user interfaces. Such systems typically integrate a design interface with elements that represent the functional, dynamic nature of the functional user interface.

Examples further provide for an interactive graphic design system which enables a user to select and apply a layout configuration to an object grouping of a rendered design under edit. Once a layout configuration is applied to an object grouping, the system operates to maintain the layout configuration as the individual objects of the object grouping are manipulated by additional user input. Among other technical benefits, the system enables users to deploy layout logic with a selected object groupings to better control layout configurations amongst objects that actively receive user input.

Still further, in some examples, a network computer system is provided to include memory resources store a set of instructions, and one or more processors are operable to communicate the set of instructions to a plurality of user devices. The set of instructions are communicated to user computing devices, in connection with the user computing devices being operated to render a corresponding design under edit on a canvas, where the design under edit is edited by user input that is indicative of any one of multiple different input actions. The set of instructions are executed on the computing devices to cause each of the computing devices to determine one or more input actions to perform based on user input. The instructions further cause the user computing devices to implement the one or more input actions to modify the design under edit.

Accordingly, as described with some examples, an example interactive graphic design system is implemented in a collaborative computing environment, where multiple users can access and contribute to a design interface under edit at the same time. Such examples further recognize that in a collaborative environment, a rendered object grouping can receive input from multiple users, making a desired layout configuration amongst the object groupings difficult to control. An interactive graphic design system as described with some examples is able to maintain, and thereby control, a specific layout configuration amongst a grouping of objects while the objects are being actively manipulated by input from multiple users.

One or more embodiments described herein provide that methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically, as used herein, means through the use of code or computer-executable instructions. These instructions are stored in one or more memory resources of the computing device.

One or more embodiments described herein can be implemented using programmatic modules, engines, or components. A programmatic module, engine, or component can include a program, a sub-routine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines.

Some embodiments described herein generally require the use of computing devices, including processing and memory resources. For example, one or more embodiments described herein are implemented, in whole or in part, on computing devices such as servers, desktop computers, cellular or smartphones, tablets, wearable electronic devices, laptop computers, printers, digital picture frames, network equipment (e.g., routers) and tablet devices. Memory, processing, and network resources are all used in connection with the establishment, use, or performance of any embodiment described herein (including with the performance of any method or with the implementation of any system).

Furthermore, one or more embodiments described herein are implemented through the use of instructions that are executable by one or more processors. These instructions are carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing embodiments of the invention is carried and/or executed. In particular, the numerous machines shown with embodiments of the invention include processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on smartphones, multifunctional devices or tablets), and magnetic memory. Computers, terminals, network enabled devices (e.g., mobile devices, such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, embodiments are implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.

<FIG> illustrates an interactive graphic design system for a computing device of a user, according to one or more examples. An interactive graphic design system ("IGDS") <NUM> can be implemented in any one of multiple different computing environments. For example, in some variations, the IGDS <NUM> is implemented as a client-side application that executes on the user computing device <NUM> to provide functionality as described with various examples. In other examples, such as described below, the IGDS <NUM> is implemented through use of a web-based application <NUM>. As an addition or alternative, the IGDS <NUM> is implemented as a distributed system, such that processes described with various examples execute on a network computer (e.g., server) and on the user device <NUM>.

According to examples, the IGDS <NUM> is implemented on a user computing device <NUM> to enable a corresponding user to design various types of interfaces using graphical elements. The IGDS <NUM> includes processes that execute as or through a web-based application <NUM> that is installed on the computing device <NUM>. As described by various examples, web-based application <NUM> executes scripts, code and/or other logic (the "programmatic components") to implement functionality of the IGDS <NUM>. Additionally, in some variations, the IGDS <NUM> is implemented as part of a network service, where web-based application <NUM> communicates with one or more remote computers (e.g., server used for a network service) to executes processes of the IGDS <NUM>.

In some examples, web-based application <NUM> retrieves some or all of the programmatic resources for implementing the IGDS <NUM> from a network site. As an addition or alternative, web-based application <NUM> retrieves some or all of the programmatic resources from a local source (e.g., local memory residing with the computing device <NUM>). The web-based application <NUM> also accesses various types of data sets in providing the IGDS <NUM>. The data sets correspond to files and libraries, which can be stored remotely (e.g., on a server, in association with an account) or locally.

In examples, the web-based application <NUM> corresponds to a commercially available browser, such as GOOGLE CHROME (developed by GOOGLE, INC. ), SAFARI (developed by APPLE, INC. ), and INTERNET EXPLORER (developed by the MICROSOFT CORPORATION). In such examples, the processes of the IGDS <NUM> are implemented as scripts and/or other embedded code which web-based application <NUM> downloads from a network site. For example, the web-based application <NUM> executes code that is embedded within a webpage to implement processes of the IGDS <NUM>. The web-based application <NUM> can also execute the scripts to retrieve other scripts and programmatic resources (e.g., libraries) from the network site and/or other local or remote locations. By way of example, the web-based application <NUM> executes JAVASCRIPT embedded in an HTML resource (e.g., web-page structured in accordance with HTML <NUM> or other versions, as provided under standards published by W3C or WHATWG consortiums). In some examples, the rendering engine <NUM>, layout engine <NUM> and/or other components utilize graphics processing unit (GPU) accelerated logic, such as provided through WebGL (Web Graphics Library) programs which execute Graphics Library Shader Language (GLSL) programs that execute on GPUs.

According to examples, user of computing device <NUM> operates web-based application <NUM> to access a network site, where programmatic resources are retrieved and executed to implement the IGDS <NUM>. In this way, the user initiates a session to implement the IGDS <NUM> for purpose of creating and/or editing a design interface. In examples, the IGDS <NUM> includes a program interface <NUM>, an input interface <NUM>, a rendering engine <NUM> and a layout engine <NUM>. The program interface <NUM> includes one or more processes which execute to access and retrieve programmatic resources from local and/or remote sources.

In an implementation, the program interface <NUM> generates a canvas <NUM>, using programmatic resources which are associated with web-based application <NUM> (e.g., HTML <NUM> canvas). As an addition or variation, the program interface <NUM> can trigger or otherwise cause the canvas <NUM> to be generated using programmatic resources and data sets (e.g., canvas parameters) which are retrieved from local (e.g., memory) or remote sources (e.g., from network service).

The program interface <NUM> also retrieves programmatic resources that include an application framework for use with canvas <NUM>. The application framework includes data sets which define or configure, for example, a set of interactive graphic tools that integrate with the canvas <NUM> and which comprise the input interface <NUM>, to enable the user to provide input for creating and/or editing a design interface.

According to some examples, the input interface <NUM> is implemented as a functional layer that is integrated with the canvas <NUM> to detect and interpret user input. The input interface <NUM> can, for example, use a reference of the canvas <NUM> to identify a screen location of a user input (e.g., 'click'). Additionally, the input interface <NUM> can interpret an input action of the user based on the location of the detected input (e.g., whether the position of the input indicates selection of a tool, an object rendered on the canvas, or region of the canvas), the frequency of the detected input in a given time period (e.g., double-click), and/or the start and end position of an input or series of inputs (e.g., start and end position of a click and drag), as well as various other input types which the user can specify (e.g., right-click, screen-tap, etc.) through one or more input devices. In this manner, the input interface <NUM> can interpret, for example, a series of inputs as a design tool selection (e.g., shape selection based on location of input), as well as inputs to define attributes (e.g., dimensions) of a selected shape.

Additionally, the program interface <NUM> is used to retrieve, from local or remote sources, programmatic resources and data sets which include files <NUM> which comprise an active workspace for the user. The retrieved data sets include one or more pages that include design elements which collectively form a design interface, or a design interface that is in progress. Each file <NUM> can include one or multiple data structure representations <NUM> which collectively define the design interface. The files <NUM> may also include additional data sets which are associated with the active workspace. For example, as described with some examples, the individual pages of the active workspace are associated with a set of constraints <NUM>. As an additional example, the program interface <NUM> can retrieve (e.g., from network service <NUM> (see <FIG>), from local memory, etc.) one or more types of profile information <NUM>, such as user profile information which can identify past activities of the user of the computing device <NUM> when utilizing the IGDS <NUM>. The profile information <NUM> can identify, for example, input types (or actions) of the user with respect to the page(s) of the active workspace, or more generally, input actions of the user in a prior time interval. In some variations, the profile information <NUM> can also identify historical or contextual information about individual design interfaces, as represented by corresponding data structure representations <NUM>. As another example, the files <NUM> include layout logic <NUM> for implementing layout configurations amongst object groupings. For example, the files <NUM> include a collection of layout logic a user can select and deploy for a given design under edit. Additionally, the files <NUM> can include data sets which represent a deployed layout logic <NUM>. Such data sets can further include data that links or otherwise associates the particular layout logic <NUM> with a particular object grouping, as well as data that identifies settings, values and other selections of the user with respect to the manner in which the layout logic <NUM> is implemented on the design under edit.

In examples, the rendering engine <NUM> uses the data structure representations <NUM> to render a corresponding DUE <NUM> on the canvas <NUM>, where the DUE <NUM> reflects graphic elements and their respective attributes as provided with the individual pages of the files <NUM>. The user can edit the DUE <NUM> using the input interface <NUM>. Alternatively, the rendering engine <NUM> generates a blank page for the canvas <NUM>, and the user uses the input interface <NUM> to generate the DUE <NUM>. As rendered, the DUE <NUM> includes graphic elements such as a background and/or a set of objects (e.g., shapes, text, images, programmatic elements), as well as attributes of the individual graphic elements. Each attribute of a graphic element can include an attribute type and an attribute value. For an object, the types of attributes include, shape, dimension (or size), layer, type, color, line thickness, text size, text color, font, and/or other visual characteristics. Depending on implementation, the attributes reflect properties of two- or three-dimensional designs. In this way, attribute values of individual objects can define, for example, visual characteristics of size, color, positioning, layering, and content, for elements that are rendered as part of the DUE <NUM>.

In examples, individual design elements are also defined in accordance with a desired run-time behavior. By way of example, some objects are defined to have run-time behaviors that are either static or dynamic. The attributes of dynamic objects change in response to predefined run-time events generated by the underlying application that is to incorporate the DUE <NUM>. Additionally, some objects are associated with logic that defines the object as being a trigger for rendering or changing other objects, such as through implementation of a sequence or workflow. Still further, other objects are associated with logic that provides the design elements to be conditional as to when they are rendered and/or their respective configuration or appearance when rendered. Still further, objects are defined to be interactive, where one or more attributes of the object may change based on user-input during the run-time of the application.

The input interface <NUM> can receive and process at least some user inputs to determine input information <NUM>, where the input information <NUM> indicates (i) an input action type (e.g., shape selection, object selection, object sizing input, object positioning input, color selection), (ii) an object that is directly indicated by the input action (e.g., object being resized), (iii) a desired attribute that is to be altered by the input action, and/or (iv) a desired value for the attribute being altered. The rendering engine <NUM> receives the input information <NUM>, and the rendering engine <NUM> implements changes indicated by the input information <NUM> to update the DUE <NUM>. When changes are implemented to the DUE <NUM>, the changes are also reflected in the accompanying data structure representations <NUM> for the DUE <NUM>.

In examples, the rendering engine <NUM> executes in conjunction with a layout engine <NUM>. Among other functions, layout engine <NUM> operates to enable the user to (i) enable a user to select a layout logic <NUM> from a collection, (ii) configure the layout logic to selectively deploy and be linked with a selected object grouping, and (iii) implement a layout configuration that is defined by the select layout logic <NUM> for the linked object grouping while the linked object grouping is being manipulated (e.g., resized or repositioned) by user input. When a particular layout logic <NUM> is selected and linked to a rendered object grouping, the layout engine <NUM> further operates to detect and receive input information <NUM> for user inputs that are directed to the linked object grouping.

According to some examples, the layout engine <NUM> processes the input information <NUM>, which indicates, for example, a resizing or repositioning of one or more objects of the object grouping, using the select layout logic <NUM> that is linked to that object grouping. The layout engine <NUM> executes the selected layout logic <NUM> to determine, for example, a resizing or repositioning of individual objects of the object grouping for purpose of maintaining a layout configuration that is defined by the linked layout logic <NUM> while carrying out the corresponding input action of the user. The layout engine <NUM> further generates a result data set <NUM> from implementing the linked layout logic <NUM>. The result data set <NUM> includes position information, boundary information (e.g., position information that identifies one or more boundaries of an object or object set) and/or dimensional information (e.g., one or more dimensions of a frame of an object or object set) for individual objects of the linked object grouping. The result data set <NUM> represents a change to the object grouping as a result of the user input (e.g., to resize or reposition object(s) of the object grouping), as well as the implementation of the predefined layout configuration. The rendering engine <NUM> processes the result data set <NUM> to reflect the changes to the object grouping, stemming from the user input and the implementation of the predefined layout configuration of the selected layout logic <NUM>.

Each layout logic <NUM> includes an instruction set and data that collectively rules and settings for implementing a predefined layout configuration amongst object grouping. By way of example, the layout logic <NUM> defines a layout configuration that identifies a relative positioning, dimensional relationship and/or spacing as between or amongst individual objects of a linked object grouping.

As described in greater detail, a user can provide selection input to select one or more layout logics <NUM> of a layout logic collection for deployment with a select grouping of objects that are rendered as part of the DUE <NUM>. In examples, the layout engine <NUM> associates a selected layout logic <NUM> with a particular object grouping, such as a parent child grouping. Once the selected layout logic <NUM> is associated with a particular object grouping, the layout engine <NUM> implements the predefined layout configuration as a response to one or more predefined triggers of the select layout logic <NUM>.

As further described, the layout configurations which are implemented by the layout engine <NUM> are instant and responsive to changes made to other objects of the select object grouping. In examples, the layout engine <NUM> executes the selected layout logic <NUM> to (i) detect user input to resize or reposition a specific object of the object grouping, (ii) calculate changes to make in size or position to one or more objects in order to implement the layout configuration of the selected layout logic <NUM>, (iii) communicate the changes (e.g., object positioning data, object border data) to the rendering engine <NUM> for rendering, along with a change resulting from user input. In examples, the layout engine <NUM> executes with rendering engine <NUM> to fluidly, and in-real time, reflect changes to an object grouping as a result of user input to one or more of the objects of the object grouping. For example, the operations of detecting, calculating and rendering can be done at a speed that is approximately equal to <NUM> seconds, so that the changes caused by user input and implementation of the layout configuration appear fluid and instant to the user operating a <NUM> monitor.

The layout engine <NUM> executes select layout logic <NUM> to automatically implement one or more layout configurations amongst object groupings that are arranged, or otherwise linked, to have a parent/child relationship. For example, a user interacts with DUE <NUM> to parent an object to another object (e.g., select and drag one object over another object). In parent/child object groupings, the child object(s) are positioned within a frame of the parent object. The layout engine <NUM> executes select layout logics <NUM> to automatically resize or reposition one or more objects of a respective linked parent child grouping, where the resizing/repositioning is based on resizing or repositioning changes of other objects of the parent child grouping.

By way of examples, layout engine <NUM> executes a first layout logic <NUM> to implement a first layout configuration in which a dimension of a parent object is resized to minimize a difference between dimension(s) of the parent and child object(s) (e.g., parent object 'hugs' child objects). Additionally, the layout engine <NUM> executes a second layout logic to implement a second layout configuration in which a dimension of one or more child object(s) are resized to minimize a difference between the dimensions of the parent and child object(s) (e.g., by having child object(s) 'fill' the parent object). As an addition or variation, the layout engine <NUM> executes additional layout logics <NUM> that implement one or more spacing configurations as between select objects of the object groupings (e.g., as between child and parent objects, and/or as between child objects).

As another addition or variation, the layout engine <NUM> executes layout logic <NUM> to implement configurations for wrapping, reverse wrapping or no wrapping with respect to child objects that are added or removed from a parent object, so as increase or decrease a collective size of the child objects within a parent object. In a wrapping configuration, the addition of child objects causes a dimension of a parent object to increase in a particular direction (e.g., downward) to accommodate the addition, and an orientation of the collective child objects expanding (e.g., by addition of child objects) reflects that direction. Similarly, in reverse wrapping, the reduction of child objects causes a dimension of a parent object to decrease in a particular direction to accommodate removal of an object from the parent object, and a dimension of the collective child objects similarly reduces in that direction.

For an associated object grouping, the layout logic <NUM> defines (i) a target object set of one or more target objects, (ii) as associated object set of one or more associated objects, and (iii) rules and/or settings that define a layout configuration for the target object(s). The target object set corresponds to the object(s) that are to be subject to the layout configuration, as implemented by the layout engine <NUM>. The associated object set includes objects of the object grouping that trigger the layout engine <NUM> to implement the select layout configuration on the target object set. In defining the associated object set, the select layout logic <NUM> also defines one or more attributes of the associated object set which triggers the layout engine <NUM> to implement the respective predefined layout configuration on the respective target object set. As an addition or variation, the select layout logic <NUM> defines a change to a dimensional attribute or position of the associated object set, for purpose of defining when changed to the dimensional attribute or position of the associated object triggers the layout engine <NUM> to implement the predefined layout configuration on the target object set. By way of an example, the layout logic <NUM> provides that any change to the dimension of the associated object triggers implementation of the predefined layout configuration for the target object set. As another example, the layout logic <NUM> provides that any change to a position of a portion of an associated object (e.g., position or coordinates of an object's boundary) triggers implementation of the predefined layout configuration for the target object set. In this way, the layout logic <NUM> is responsive to one or more dimensional or positional changes of an associated object set.

Moreover, in some examples, users specify that the application of the layout logic <NUM> is specific to a particular direction or orientation (e.g., horizontal, vertical). If a layout configuration is specified to be specific to a particular direction or orientation, the layout engine configures implementation of the layout configuration to be specific to the specified direction. Further, the layout logic <NUM> is only responsive to resizing or repositioning of the associated object set in the specified direction.

Additionally, in some examples, the user specifies thresholds that define a magnitude or amount of change to an associate object set that is resized or repositioned, before the selected layout logic <NUM> implements a predefined layout configuration.

According to some examples, layout engine <NUM> implements operations to determine, in real-time, coordinates of a portion of an associated object (e.g., a left, right, top or bottom boundary of the associate object's frame, a corner of the associate object's frame, etc.) that is being repositioned, as part of a user input operation to resize or move the associated object or otherwise alter an associated object set. The layout engine <NUM> utilizes the determined coordinates of the portion of the associated object that is being manipulated as input for the layout configuration of the target object set. In examples, the layout engine <NUM> obtains and act on the coordinate information obtained for the parent object, so as to instantly implement the layout configuration on the target object set.

By way of examples, the select layout logics <NUM> that is deployed for use in association with a parent child object grouping includes fill layout logic, hug layout logic, and one or more spacing layout logics. As described elsewhere, the fill layout logic can implement a fill layout configuration where one or more child objects are automatically resized and/or repositioned, as a response to input that resizes or repositions the parent object. In variations, the fill layout logic is configured to apply changes to the target object set (child object(s)) in a particular direction (e.g., horizontal or vertical directions), as a response to changes to the associated object set (parent object) which are in the same particular direction.

The hug layout logic can implement a fill layout configuration where a parent object is automatically resized and/or repositioned. A trigger for the hug layout logic includes input that resizes or repositions individual child objects or the respective child objects collectively. In variations, the hug layout logic can also be configured to apply changes to the target object set (parent) in a particular direction (e.g., horizontal or vertical directions), as a response to changes to the associated object set (child object(s)) which are in the same particular direction.

As an additional example, an even spacing layout logic can implement a spacing configuration amongst child objects of a parent/object grouping, where the child objects are maintained in a configuration where they are evenly spaced from one another. The target object set of the even spacing layout logic corresponds to all child objects of a parent/child object grouping, and the associated object set of the even spacing layout logic corresponds to the parent object and all of the child objects of the parent/child object grouping.

When the even spacing layout logic is deployed with a parent/child object grouping, the layout engine <NUM> responds to the parent object being resized by equally resizing each child object of the parent object, and further by repositioning each child object (as resized) to be spaced from its respective neighbor child object(s) by the same amount. The layout engine <NUM> responds to the parent object being repositioned in similar fashion - by repositioning all of the child objects to maintain the even spacing between the child objects. In some implementations, if an additional child object is added to the parent object, or if one or more of the child objects are resized, the layout engine <NUM> automatically repositions each of the child objects to maintain the equal spacing amongst all adjacent pairs of child objects. Additionally, in variations, the even spacing layout logic is configured to implement the spacing configuration to the target object set (all of the child objects) in a particular direction (e.g., horizontal or vertical directions), as a response to changes to the associated object set (child object, parent object) that are in the same particular direction.

As another example, a fixed spacing layout logic implements a fixed spacing configuration amongst adjacent objects of an object grouping. In a parent/child object grouping, the fixed spacing configuration specifies a fixed spacing between, for example, a boundary of a child object (e.g., a boundary corresponding to a portion of a frame of the child object) and a boundary of a parent object (e.g., a boundary corresponding to a portion of a frame of the parent object). Thus, for example, input by a user to reposition or resize a parent object causes the layout engine <NUM> to reposition the child object so that the fixed spacing between the respective boundaries of the parent and child objects is maintained.

<FIG> illustrates a network computing system to implement an interactive graphic design system on a user computing device, according to one or more examples. A network computing system such as described with an example of <FIG> is implemented using one or more servers which communicate with user computing devices over one or more networks.

In an example of <FIG>, the network computing system <NUM> performs operations to enable the IGDS <NUM> to be implemented on the user computing device <NUM>. In variations, the network computing system <NUM> provides a network service <NUM> to support the use of the IGDS <NUM> by user computing devices that utilize browsers or other web-based applications. The network computing system <NUM> can include a site manager <NUM> to manage a website where a set of web-resources <NUM> (e.g., web page) are made available for site visitors. The web-resources <NUM> can include instructions, such as scripts or other logic ("IGDS instructions <NUM>"), which are executable by browsers or web components of user computing devices.

In some variations, once the computing device <NUM> accesses and downloads the web-resources <NUM>, web-based application <NUM> executes the IGDS instructions <NUM> to implement functionality such as described with some examples of <FIG>. For example, the IGDS instructions <NUM> are executed by web-based application <NUM> to initiate the program interface <NUM> on the user computing device <NUM>. The initiation of the program interface <NUM> may coincide with the establishment of, for example, a web-socket connection between the program interface <NUM> and a service component <NUM> of the network computing system <NUM>.

In some examples, the web-resources <NUM> includes logic which web-based application <NUM> executes to initiate one or more processes of the program interface <NUM>, causing the IGDS <NUM> to retrieve additional programmatic resources and data sets for implementing functionality as described by examples. The web resources <NUM> can, for example, embed logic (e.g., JAVASCRIPT code), including GPU accelerated logic, in an HTLM page for download by computing devices of users. The program interface <NUM> can be triggered to retrieve additional programmatic resources and data sets from, for example, the network service <NUM>, and/or from local resources of the computing device <NUM>, in order to implement the IGDS <NUM>. For example, some of the components of the IGDS <NUM> can be implemented through web-pages that can be downloaded onto the computing device <NUM> after authentication is performed, and/or once the user performs additional actions (e.g., download one or more pages of the workspace associated with the account identifier). Accordingly, in examples as described, the network computing system <NUM> can communicate the IGDS instructions <NUM> to the computing device <NUM> through a combination of network communications, including through downloading activity of web-based application <NUM>, where the IGDS instructions <NUM> are received and executed by web-based application <NUM>.

The computing device <NUM> can use web-based application <NUM> to access a website of the network service <NUM> to download the webpage or web resource. Upon accessing the website, web-based application <NUM> automatically (e.g., through saved credentials) or through manual input, communicates an account identifier to the service component <NUM>. In some examples, web-based application <NUM> can also communicate one or more additional identifiers that correlate to a user identifier.

Additionally, in some examples, the service component <NUM> can use the user or account identifier of the user identifier to retrieve profile information <NUM> from a user profile store <NUM>. As an addition or variation, profile information <NUM> for the user is determined and stored locally on the user's computing device <NUM>. As described with other examples, the user profile information is used to infer an outcome of an input action, based on the inputs of the user with respect to the DUE <NUM> (such as detected by the input interface <NUM>). For example, the profile information <NUM> is communicated to the IGDS <NUM>, where the profile information <NUM> is used to implement and develop the predictive logic <NUM>.

The service component <NUM> can also retrieve the files of an active workspace ("active workspace files <NUM>") that are linked to the user account or identifier from a file store <NUM>. The profile store <NUM> can also identify the workspace that is identified with the account and/or user, and the file store <NUM> can store the data sets that comprise the workspace. The data sets stored with the file store <NUM> can include, for example, the pages of a workspace, data sets that identify constraints for an active set of workspace files, and one or more data structure representations <NUM> for the design under edit which is renderable from the respective active workspace files.

Additionally, in examples, the service component <NUM> provides a representation <NUM> of the workspace associated with the user to the web-based application <NUM>, where the representation identifies, for examples, individual files associated with the user and/or user account. The workspace representation <NUM> can also identify a set of files, where each file includes one or multiple pages, and each page including objects that are part of a design interface.

On the user device <NUM>, the user can view the workspace representation through web-based application <NUM>, and the user can elect to open a file of the workspace through web-based application <NUM>. In examples, upon the user electing to open one of the active workspace files <NUM>, web-based application <NUM> initiates the canvas <NUM>. For example, the IGDS <NUM> can initiate an HTML <NUM> canvas as a component of web-based application <NUM>, and the rendering engine <NUM> can access one or more data structures representations <NUM> of a design interface under edit, to render the corresponding DUE <NUM> on the canvas <NUM>.

The service component <NUM> also determines, based on the user credentials, a permission setting or role of the user in connection with the account identifier. The permission settings or role of the user determines, for example, the files which can be accessed by the user. In some examples, the implementation of the rendering engine <NUM> on the computing device <NUM> is configured based at least in part on the role or setting of the user.

In examples, the changes implemented by the rendering engine <NUM> to the DUE <NUM> can also be recorded with the respective data structure representations <NUM>, as stored on the computing device <NUM>. As described with some examples, the rendering engine <NUM> can implement changes reflected by user information <NUM>, as well as changes represented by the result data set <NUM>, as generated by the layout engine <NUM> implementing one or more select layout logic <NUM>. The layout engine <NUM> can determine the result data set <NUM> for objects of an object grouping which is linked to a particular layout logic <NUM>, when one or more of the objects are resized or reshaped by user input.

The program interface <NUM> can repeatedly, or continuously stream change data <NUM> to the service component <NUM>, wherein the updates reflect edits as they are made to the DUE <NUM> and to the data structure representation <NUM> to reflect changes made by the user to the DUE <NUM> and to the local data structure representations <NUM> of the DUE <NUM>. The service component <NUM> can receive the change data <NUM>, which in turn is used to implement changes to the network-side data structure representations <NUM>. In this way, the network-side data structure representations <NUM> for the active workspace files <NUM> can mirror (or be synchronized with) the local data structure representations <NUM> on the user computing device <NUM>. When the rendering engine <NUM> implements changes to the DUE <NUM> on the user device <NUM>, the changes can be recorded or otherwise implemented with the local data structure representations <NUM>, and the program interface <NUM> can stream the changes as change data <NUM> to the service component <NUM> in order to synchronize the local and network-side representations <NUM>, <NUM> of the DUE <NUM>. This process can be performed repeatedly or continuously, so that the local and network-side representations <NUM>, <NUM> of the DUE <NUM> remain synchronized.

Additionally, the program interface <NUM> can record a selected layout logic <NUM> being applied to a particular object grouping. The active workspace files <NUM>, for example, can include instructions and data (e.g., a file) for a selected layout logic <NUM>. Additionally, the local data structure representations <NUM> can identify the portion of the DUE <NUM> for which input information <NUM> is to be handled by the layout engine <NUM>.

<FIG> illustrates a network computing system to implement an interactive graphic design system for multiple users in a collaborative network platform, according to one or more examples. In an example of <FIG>, a collaborative network platform is implemented by the network computing system <NUM>, which communicates with multiple user computing devices <NUM>, <NUM> over one or more networks (e.g., World Wide Web) to implement the IGDS <NUM> on each computing device. While <FIG> illustrates an example in which two users utilize the collaborative network platform, examples as described allow for the network computing system <NUM> to enable collaboration on design interfaces amongst a larger group of users.

With respect to <FIG>, the user computing devices <NUM>, <NUM> are assumed as being operated by users that are associated with a common account, with each user computing device <NUM>, <NUM> implementing a corresponding IGDS <NUM> to access the same workspace during respective sessions that overlap with one another. Accordingly, each of the user computing devices <NUM>, <NUM> accesses the same set of active workspace files <NUM> at the same time, with the respective program interface <NUM> of the IGDS <NUM> on each user computing device <NUM>, <NUM> operating to establish a corresponding communication channel (e.g., web socket connection) with the service component <NUM>.

In examples, the service component <NUM> communicates a copy of the active workspace files <NUM> to each user computing device <NUM>, <NUM>, such that the computing devices <NUM>, <NUM> render the DUE <NUM> of the active workspace files <NUM> at the same time. Additionally, each of the computing devices <NUM>, <NUM> maintains a local data structure representation <NUM> of the respective DUE <NUM>, as determined from the active workspace files <NUM>. The service component <NUM> also maintains a network-side data structure representation <NUM> obtained from the files of the active workspace <NUM>, and coinciding with the local data structure representations <NUM> on each of the computing devices <NUM>, <NUM>.

The network computing system <NUM> continuously synchronizes the active workspace files <NUM> on each of the user computing devices. In particular, changes made by users to the DUE <NUM> on one computing device <NUM>, <NUM> are immediately reflected on the DUE <NUM> rendered on the other user computing device <NUM>, <NUM>. By way of example, the user of computing devices <NUM> makes a change to the respective DUE <NUM>, and the respective rendering engine <NUM> implements an update that is reflected in the local copy of the data structure representation <NUM>. Additionally, as described with other examples, the layout engine <NUM> executes selected layout logic <NUM> for linked object groupings of the DUE <NUM>, and the layout engine <NUM> communicates the result data set <NUM> to the rendering engine <NUM> for implementing updates to the object grouping of the DUE <NUM>. From the computing device <NUM>, the program interface <NUM> of the IGDS <NUM> streams change data <NUM>, reflecting the change of the user input, to the service component <NUM>. The service component <NUM> processes the change data <NUM> of the user computing device. The service component <NUM> uses the change data <NUM> to make a corresponding change to the network-side data structure representation <NUM>. The service component <NUM> also streams remotely-generated change data <NUM> (which in the example provided, corresponds or reflects change data <NUM> received from the user device <NUM>) to the computing device <NUM>, to cause the corresponding IGDS <NUM> to update the DUE <NUM> as rendered on that device. The computing device <NUM> also uses the remotely generated change data <NUM> to update with the local data structure representation <NUM> of that computing device <NUM>. The program interface <NUM> of the computing device <NUM> receives the update from the network computing system <NUM>, and the rendering engine <NUM> updates the DUE <NUM> and the respective local copy of <NUM> of the computing device <NUM>.

The reverse process can also be implemented to update the data structure representations <NUM> of the network computing system <NUM> using change data <NUM> communicated from the second computing device <NUM> (e.g., corresponding to the user of the second computing device updating the DUE <NUM> as rendered on the second computing device <NUM>). In turn, the network computing system <NUM> can stream remotely generated change data <NUM> (which in the example provided, corresponds or reflects change data <NUM> received from the user device <NUM>) to update the local data structure representation <NUM> of the DUE <NUM> on the first computing device <NUM>. In this way, the DUE <NUM> of the first computing device <NUM> can be updated as a response to the user of the second computing device <NUM> providing user input to change the DUE <NUM>.

To facilitate the synchronization of the data structure representations <NUM>, <NUM> on the computing devices <NUM>, <NUM>, the network computing system <NUM> implements a stream connector to merge the data streams which are exchanged between the first computing device <NUM> and the network computing system <NUM>, and between the second computing device <NUM> and the network computing system <NUM>. In some implementations, the stream connector is implemented to enable each computing device <NUM>, <NUM> to make changes to the network-side data representation <NUM>, without added data replication that is otherwise be required to process the streams from each device separately.

Additionally, over time, one or both of the computing devices <NUM>, <NUM> may become out-of-sync with the server-side data representation <NUM>. In such cases, the respective computing device <NUM>, <NUM> can redownload the active workspace files <NUM>, to restart its maintenance of the data structure representation of the DUE <NUM> that is rendered and edited on that device.

Further, as described by other examples, the layout engine <NUM> executes selected layout logic <NUM> to implement a predefined layout configuration amongst a grouping of objects (e.g., parent child object grouping). In this way, the layout engine <NUM> can execute a select layout logic <NUM> for a linked object grouping in order to implement and maintain a configuration in which a parent object is resized to maintain a dimensional relationship with respect to one or more of its child objects. For example, the layout configuration provides for a parent object to be set to a dimension that borders, or is slightly larger than the combined or overall dimensions of its child objects (e.g., "hug layout logic"). When a user provides input that changes the combined or overall dimension of the child object, the parent object is resized accordingly, to maintain the set dimensional relationship between the parent object and its child objects.

When layout engine <NUM> is implemented in a collaborative environment, the IGDS facilitates users of different roles and/or skill-level in collaborating on a given DUE <NUM>. For example, the rendering engine <NUM> executes the layout logic <NUM> to enable a user that is highly-skilled and/or whom has primary control ("primary user") of the DUE <NUM>, to select to have a parent/child grouping of objects associated with the layout configuration or behavior. A second user who collaborates on the DUE <NUM> then enters input that manipulates the child object, without having to perform the additional task of resizing the parent object. Through use of layout engine <NUM>, the primary user controls size and position parameters relating to an object grouping, so as to better control other users (e.g., less-skilled or secondary users) from manipulating the object grouping in a manner that is undesired. In this way, the layout engine <NUM> enables primary or skilled users to select layout logic <NUM> to implement quality control in the design of select object groupings.

<FIG> and <FIG> illustrate example methods for providing an interactive graphic design interface, according to one or more examples. Methods such as described by examples of <FIG> or <FIG> are implemented on, for example, a user computing device that is configured to enable users to generate and edit design interfaces. For example, a method such as described by <FIG> or <FIG> are implemented by user computing devices on which an integrated graphic design system ("IGDS") such as described with examples of <FIG> is implemented. Accordingly, reference is made to elements of <FIG> for purpose of illustrating suitable components for performing a step or sub-step being described.

In examples, the user computing device <NUM>, <NUM> operates to (i) render a design interface under edit, and (ii) enable the user to edit the design interface under edit. The layout engine <NUM> operates to make available multiple layout logics <NUM> in connection with rendering DUE <NUM> (<NUM>). The IGDS <NUM> provides interactive tools to enable users to select and apply one or more layout logics <NUM> made available through the layout engine <NUM>, for use with rendered object groupings on a canvas <NUM>. Each layout logic <NUM> defines target object(s), associated object(s), and a layout configuration, which specifies, for example, spacing, positioning and dimensioning of target objects relative to associated objects and/or other references.

The layout engine <NUM> detects user input to select a layout logic <NUM> and a rendered object grouping to which the layout logic <NUM> is deployed (<NUM>). In response to selection input from the user that selects a layout logic <NUM> of the collection, the IGDS <NUM> links or otherwise deploys the layout logic <NUM> with the select object grouping (e.g., parent/child object grouping) (<NUM>). When the layout logic <NUM> is selected and deployed to a select object grouping, execution of the select layout logic <NUM> identifies (i) a target object set of the object grouping which are to be subject to a predefined layout configuration of the select layout logic <NUM>, and (ii) an associated object set of the object grouping, which, if manipulated (e.g., by dimension or position), triggers the layout engine <NUM> automatically implement the respective predefined layout configuration on the target object set. As an example, a first type of layout logic <NUM> (e.g., fill layout logic) is applied to a parent/child object grouping, with a layout configuration that is applied to child object(s) as a response to changes to the parent object of the parent/child grouping. Additionally, as another example, a second type of layout logic <NUM> (e.g., hug layout) is applied to a parent/child object grouping, with a layout configuration that is applied to a parent object as a response to changes to child object(s) of the parent/child grouping.

In examples, the selection input from the user selectively applies the select layout logic <NUM> to objects of the parent/child object grouping (<NUM>). In some examples, the user provides selection input to select one or more target objects from a larger class of target objects which is subject to the layout configuration of the selected layout logic <NUM> (<NUM>). For example, in the case of fill layout logic, the selection input identifies which of multiple child objects are to be resized or repositioned in response to changes made to the parent object of the grouping.

Additionally, in other examples, the user provides selection input to select one or more associated objects from a larger class of associated objects which could trigger the layout configuration of the selected layout logic <NUM> to be applied to an identified set of target object(s) (<NUM>). For example, in the case of hug layout logic, this selection input identifies which of multiple child objects is resized or repositioned to trigger resizing or repositioning of the parent object of the parent/child object grouping.

Additionally, in some examples, the selection input of the user selects an orientation or direction of application for the select layout logic <NUM> (<NUM>). For example, a user provides selection input (via the interactive tools) to configure the selected layout logic <NUM> to apply in one of a horizontal orientation, vertical orientation, or horizontal and vertical orientation.

Once a particular layout logic <NUM> is selected, configured and associated with an object grouping, subsequent user input with regards to the identified associated objects of the object groupings triggers the layout engine <NUM> to automatically and responsively implement the defined layout configuration on the target object(s) that are identified by the layout logic <NUM> (<NUM>). As described with some examples, the layout engine <NUM> can resize and/or reposition objects of the object grouping in order to conform the object grouping to the predefined configuration of the select layout logic. In examples, the layout engine <NUM> communicates the result data set <NUM> to the rendering engine <NUM>, to cause the rendering engine <NUM> to implement the changes resulting from implementing the layout configuration on the select object groupings.

With reference to an example of <FIG>, the IGDS <NUM> operates to render a DUE <NUM> (<NUM>). For example, as described with other examples, user computing device <NUM>, <NUM> includes a rendering engine that renders a design under edit, and further enables the user to provide input to alter the design under edit.

In examples, the IGDS <NUM> associates one or more types of layout logic with an object grouping of the design under edit (<NUM>). For example, layout engine <NUM> make layout logics available for user selection, and the user selects a particular layout logic to be linked to a particular object grouping.

In examples, the IGDS <NUM> enables the user to select which layout logic to associate or apply to an object grouping. In implementations, layout logic <NUM> is associated with object groupings that are triggered with subsequent user input to manipulate one or more objects of the groupings. The layout logic <NUM> is associated by default, or selected through, for example, user selection via a menu or user interface feature provided by the IGDS <NUM>. In some implementations, the layout object is implemented automatically in response to user input to apply the particular layout logic. In other cases, selection of the layout logic results in the layout logic automatically implementing a particular configuration amongst at least some of the objects of the grouping, as a response to user input to manipulate one or more of the object groupings.

In examples, layout object is associated with a parent/child grouping of objects. The layout object is triggered by user input to resize, for example, a dimension of the parent object, to automatically reconfigure an aspect of the child object(s).

According to some examples, the IGDS <NUM> responds to a user input to alter a dimension of a parent object from a first value to a second value, and in response to the user input, the IGDS <NUM> automatically implements a spacing configuration for the child objects (<NUM>). The spacing configuration provides that a boundary spacing between at least a first border of the parent object and an adjacent child object to that border is unchanged as the dimension of the parent object is altered from the first value to the second value (<NUM>). As an addition or variation, an interior spacing between each adjacent pair of child objects are made (or maintained) equal to one another when the dimension of the parent object is altered to the second value (<NUM>).

Accordingly, in examples in which IGDS <NUM> is implemented in a collaborative environment, a first user provides input to select a first layout logic to associate with a given group of objects. As described with some examples, a corresponding layout configuration is subsequently implemented in response to input provided by a second user with respect to one or more objects of the groupings. For example, a first user can specify a layout logic for a parent/child grouping of objects, where the layout logic implements a spacing configuration for the child objects. Subsequently, a second user can manipulate the parent object of the grouping, to implement the spacing configuration for the child objects.

<FIG> illustrate alternative implementations of layout logic which are provided by an interactive graphic design system, in accordance with one or more examples. In describing examples of <FIG>, reference is made to elements of <FIG> for purpose of illustrating suitable components for generating and implementing the user interfaces as described.

<FIG> illustrate a user interface <NUM> in which a DUE <NUM> is rendered on a canvas <NUM>, with an object grouping including a parent object <NUM> and a child object <NUM>. In an example of <FIG>, the object grouping <NUM>, <NUM> is associated with a layout configuration and behavior that resizes the parent object <NUM> automatically in response to the child object <NUM> being resized horizontally (or along the X-axis). In an example shown, the child object <NUM> is resized (as illustrated by input <NUM>), corresponding to the user selecting and dragging the right boundary <NUM> of the child object <NUM> from the original position <NUM> to the new position <NUM>. As described with other examples, the layout engine <NUM> executes the layout logic <NUM> to resize the parent object <NUM> automatically. As shown, the layout engine <NUM> automatically resizes the parent object <NUM> so that the right boundary <NUM> of the parent object is moved from the original position <NUM> to the new position <NUM>.

In an example of <FIG>, the object grouping <NUM>, <NUM> is associated with a layout configuration and behavior that resizes the parent object <NUM> automatically in response to the child object <NUM> being resized vertically (or along the Y-axis). Thus, if the child object <NUM> receives user input <NUM> to move the bottom boundary <NUM> from the original position 321to a new position <NUM>, the bottom boundary <NUM> of the parent object <NUM> is moved from its original position <NUM> to the new position <NUM>.

In examples of <FIG>, the spacing between the parent object <NUM> and the child object <NUM> is maintained while the child object is being resized. Thus, the distance between the right boundaries <NUM>, <NUM>, the left boundaries <NUM>, <NUM>, the top boundaries <NUM>, <NUM> and the bottom boundaries <NUM>, <NUM> of the parent and child objects <NUM>, <NUM> are unchanged after resizing occurs.

<FIG> illustrates a user interface <NUM> in which the object grouping <NUM>, <NUM> is associated with a layout configuration and behavior that resizes the child object <NUM> automatically in response to the parent object <NUM> being resized horizontally (or along the X-axis) by a user input <NUM>. The user input <NUM> repositions (e.g., drag) a right boundary <NUM> of the parent object from an original position <NUM> to a new position <NUM>. In response, the right boundary <NUM> of the child object <NUM> moves from an original position <NUM> to a new position <NUM>, so that a spacing between the respective right boundaries <NUM>, <NUM> is maintained when the parent object is resized. In this way, the spacing between the boundaries <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, <NUM>, <NUM>, <NUM> of the respective parent <NUM> and child objects <NUM> is maintained.

<FIG> illustrates a variation of <FIG>, when the selected orientation for the layout logic is vertical, rather than horizontal. Accordingly, resize input <NUM> to reposition the bottom boundary <NUM> of the parent object <NUM> from an original position <NUM> to a new position <NUM>, and the repositioning causes the bottom boundary of the child object <NUM> to move from the original position <NUM> to the new position <NUM>. In this way, the spacing between the boundaries <NUM>, <NUM>, <NUM>, <NUM> and <NUM>, <NUM>, <NUM>, <NUM> of the respective parent <NUM> and child objects <NUM> is maintained.

<FIG> illustrate an implementation of a spacing layout logic, according to one or more examples. With reference to an example of <FIG>, an object grouping <NUM> includes a parent object layout logic and a group of child objects <NUM>, <NUM>, <NUM>. As shown, the parent object <NUM> includes a frame with respective left and right boundary elements <NUM>, <NUM>. The child objects <NUM>, <NUM>, <NUM> correspond to, for example, icons, active graphic elements, wireframe objects, text objects, imported objects (e.g., social media posts), and other types of graphic elements.

<FIG> reflect implementation of a spacing configuration that is implemented by layout engine <NUM> executing a spacing layout logic, resulting in one or more child objects <NUM>, <NUM>, <NUM> being fixed relevant to a corresponding boundary <NUM>, <NUM> of the parent object <NUM>. Accordingly, as shown by <FIG>, the separation distance (D1) between left boundary <NUM> and the most proximate child object <NUM> is determined by default or by user input. Likewise, the separation distance (D3) between right boundary <NUM> and the most proximate child object <NUM> can also be determined by default or by user input. Thus, for example, the separation distance D1 and D3 can be the same or different, based on user input and/or default settings.

Additionally, <FIG> illustrates an example in which the child objects <NUM>, <NUM>, <NUM> of the parent object are evenly spaced from one another. For example, the first user can select layout logic to automatically implement an even spacing configuration amongst adjacent child objects, such as between the left-most child object <NUM> and middle child object <NUM>(reflected by separation distance D2), and between middle child object <NUM> and the right-most child object <NUM> (reflected by separation distance D2'). Thus, execution of layout logic can result in the separation distance between adjacent child objects being equal (D2=D2').

In some examples, the layout logic is associated with the parent/child object groupings <NUM>, such that subsequent input to resize the parent object <NUM> results in the spacing configurations of the child objects <NUM>, <NUM>, <NUM> being maintained. In an example shown by <FIG>, the parent object <NUM> is resized from a first dimension (A1) (as shown with <FIG>) to a second dimension (A2) (as shown with <FIG>). As shown in <FIG>, the IGDS <NUM> automatically executes the associated layout logic in response to second input (from the same or different user) to resize the parent object <NUM>. Thus, once the parent object <NUM> is resized to a new dimension (A2), the child objects <NUM>, <NUM>, <NUM> are reconfigured by: (i) maintaining a selected fixed separation distance between the left and/or right boundaries <NUM>, <NUM> and the respective closest child object <NUM>, <NUM>, such that D1 and/or D3 remain unchanged once the parent object <NUM> is resized; and/or (ii) maintaining even spacing between adjacent child objects <NUM>, <NUM>, <NUM> such that D2 and D2' remain unchanged once the parent object <NUM> is resized. The IGDS <NUM> executes the layout logic to implement one or more spacing configurations in accordance with a particular orientation (e.g., horizontal or vertical orientation). In <FIG>, for example, the spacing configuration(s) is shows as being implemented along a horizontal orientation. The horizontal orientation may be selected by default, automatically based on a preselected orientation (or alignment) of the parent object or the group of child objects <NUM>, <NUM>, <NUM> and/or by user preference or input. In other examples, the IGDS <NUM> can execute layout logic to implement spacing configurations in accordance with a vertical orientation, based on, for example, default settings, user input, and/or an orientation (or alignment) of the parent object <NUM> or the group of child objects <NUM>, <NUM>, <NUM>.

<FIG> illustrate another implementation of stretch or fill layout logic, according to one or more examples. An object grouping <NUM> includes a parent object <NUM> and child object set 370A, 370B, 370C ("collectively child objects <NUM>" or "child object set <NUM>"). When fill layout logic is deployed, the user can make selections as to an orientation or direction in which the layout logic is applied. In <FIG>, the selected orientation for the deployment of the fill layout logic is horizontal. Accordingly, changes to the parent object <NUM> along the horizontal ( X-axis) automatically result in corresponding changes to the child object set <NUM> in the same direction. As shown, for example, an input <NUM> is applied by user to a right boundary of the parent object <NUM>, causing the right boundary to reposition, and the parent object <NUM> as a whole to resize in the horizontal direction. As input <NUM> is applied to the right boundary of the parent object <NUM> to resize (expand and contract) along the X-direction, the child objects are similarly resized in the same direction, so that the spacing D4 between the boundaries of the child objects <NUM> and the parent object <NUM> remain the same. The implementation of the particular layout logic in a particular direction (e.g., horizontal) even though the horizontal axis is a counter axis to a direction of an object stack, which is in the vertical or Y direction.

<FIG> also illustrate that a particular type of layout is configured to include additional configuration, such as additional spacing configuration. For example, as shown, a user specifies that a separation distance between the right boundaries of each of the child objects <NUM> and a corresponding right boundary of the parent object <NUM> have a particular spacing value (represented by D4) that includes padding. As shown, implementation of the corresponding layout configuration maintains the spacing D4 (with padding), as the parent object <NUM> is resized or repositioned.

In an example of FI. 3J, the object grouping is shown to include an additional child object 370D. The input <NUM> could be applied by the user to a top or bottom boundary of the parent object <NUM>, causing the respective top/bottom boundary to reposition, and the parent object <NUM> as a whole to resize in the vertical direction. Similar to the case of horizontal resizing, vertical resizing the top or bottom boundary of the parent object <NUM> causes the child objects <NUM> to resize in the vertical direction. As illustrated in examples of <FIG>, the spacing value (D4) between, for example, the right boundaries of the respective parent and child objects <NUM>, <NUM> remain fixed in response to the resizing input. Likewise, spacing between the respective top/bottom boundaries of the child objects <NUM> and the parent object <NUM> can also be designated to be fixed. As such, examples provide that the spacing between boundaries of parent/child objects <NUM>, <NUM> remain fixed, rather than change proportionately in relation to the respective change of the parent and child objects.

While examples shown with <FIG> are described in context of <NUM>-dimensional resize input <NUM>, in variations, the input <NUM> is received and applied in two dimensions. In other words, the user provides input <NUM> to resize the parent object <NUM> in the horizontal and vertical directions, and the child objects <NUM> resize in both directions, as described by <FIG> and <FIG>.

<FIG> and <FIG> illustrates the stretch or fill layout logic, as shown with an example of <FIG>, configured to resize a select object, rather than all of the child objects. For a parent/child object grouping <NUM>, where parent object <NUM> includes child objects <NUM>, <NUM>, <NUM>, resize input <NUM> is received for the parent object <NUM>, causing the parent object <NUM> to resize in two dimensions. Further in the example shown, each child object <NUM>, <NUM>, <NUM>, <NUM> is resized in one direction (e.g., horizontal direction). Additionally, a user selection or setting can selectively specify individual child objects <NUM>, <NUM>, <NUM>, <NUM>, such as the first child object <NUM> as shown, to resize in two directions. Thus, the resize behavior of the child objects <NUM>, <NUM>, <NUM>, <NUM> can be individually configured to cause the respective child objects to resize in horizontal direction, vertical direction and/or both horizontal and vertical directions, responsively to a corresponding resize input to the parent object <NUM>.

It will be appreciated that numerous similar variations can be implemented by other examples. For example, some child objects <NUM>, <NUM>, <NUM> may be designated (e.g., with user input) to resize in one direction that can be specified for that particular object, or alternatively, designated to not resize unless another child object is being resized to encroach on a dimension or spacing configuration of the child object.

While examples of <FIG> are specific to fill layout logic, in variations, the configurations and selections which the user can make (e.g., to apply the layout logic in a particular direction, to specific objects rather than a class of objects which could have the layout logic applied, spacing configuration, etc.) can be applicable to other types of layout logic, such as hug layout logic, wrap layout logic, spacing configuration layout logic and others.

<FIG> illustrate examples in which spacing layout configurations of object groupings are visualized on a canvas of a design under edit. In particular, examples as shown by <FIG> illustrate object groupings <NUM>, <NUM> which have layout logic that implements spacing configurations between objects of the object grouping. With reference to <FIG>, the IGDS <NUM>, for example, generates a visualization with the object groupings <NUM> as rendered on a canvas <NUM>, to indicate spacing configurations that exist amongst or between objects of the object grouping. The visualization is in the form of shading <NUM>, coloring or other visual markers, as well as the user of markers <NUM> or other indicators. As described with other examples, the spacing configurations specify padding, or fixed spacing, which is maintained at a specific amount when objects of an object grouping are resized or repositioned. The spacing configurations can also include dynamic spacing, which is determined on the fly by rules - such as even spacing requirements as illustrated with examples of <FIG>. According to some examples, the user interact with a canvas <NUM> in order to visually indicate the spacing configurations amongst (or between) objects of the object grouping <NUM>. For example, spacing configurations (e.g., implemented by layout logic) can be visualized in a different color or shading to the user. Further, spacing configurations can be indicated by the markers <NUM> to show their existence and respective location. The user can view the spacing configurations through, for example, use of (i) a design tool provided on a side panel of the canvas, (ii) a shortcut key which the user can activate by, for example pressing and holding, and/or (iii) a canvas tool, such as described with <FIG>.

With reference to <FIG> and <FIG>, a visualization is displayed for the object grouping <NUM>. As shown, the visualization is in a form of a colored or shaded band <NUM>, to indicate a spacing configuration as between an outer parent object <NUM> and a child object <NUM>. child objects 412A, 412B of a parent object <NUM> the object grouping <NUM>. In the particular example, the visualization band <NUM> indicates the spacing configuration between a child object <NUM> and parent object <NUM>. In <FIG>, a colored or shaded band <NUM> indicates the spacing configuration between adjacent objects, such as adjacent child objects 412A, 412B of a corresponding parent object <NUM>.

<FIG> and <FIG> illustrate the use of additional visualization to indicate spacing of objects, according to one or more examples. In <FIG>, a first object <NUM> (e.g., circle) is shown to be positioned adjacent to a second object <NUM> (e.g., text box) on the canvas <NUM>. Both objects <NUM>, <NUM> can be provided within a corresponding parent object <NUM>, to form an object grouping <NUM>. As shown in <FIG>, the rendering engine <NUM> displays by default the canvas <NUM> and object groupings <NUM> without any visualization that indicates the presence of a spacing configuration between individual objects of that grouping. In an example of <FIG>, the user provides hover input near and/or over the object groupings <NUM>, or alternatively, near or over specific objects of the object grouping <NUM>, to cause the rendering engine <NUM> to display one or more visualizations that indicate existing spacing configurations between the respective objects. For example, in <FIG>, the rendering engine <NUM> is shown to display (i) a band <NUM> to visualize a spacing configuration that exists between object <NUM> and parent object <NUM>, (ii) a band <NUM> to visualize a spacing configuration that exists between child objects <NUM>, <NUM>, and (iii) one or more markers <NUM> that indicate a spacing configuration between the parent object <NUM> and the child objects <NUM>, <NUM> (or a sub-parent object for child objects <NUM>, <NUM>).

In examples, the user can further interact with the object grouping <NUM> on the canvas <NUM> to reconfigure one or more of the spacing configurations. In <FIG>, the IGDS <NUM> enables an embedded or on-canvas tool that allows the user to view and reconfigure spacing configurations between object. The tool can, for example, enable user interaction that can include positioning the pointer over one of the spacing configurations (e.g., the band <NUM>) to make the band selectable (<FIG>). When made selectable, the user can provide additional input to alter the spacing configuration represented by the band <NUM> (<FIG>). For example, the user can provide input to make the boundaries selectable (e.g., <FIG>), and further to move the boundaries in a given direction (<FIG>).

Accordingly, as shown, some examples allow for the user to alter spacing configurations when the spacing configurations are visualized on the canvas. In this way, the user can reconfigure a particular layout logic such that the layout configuration includes updated spacing, as indicated by the user through his interaction with the design interface. In examples in which a tool is embedded or otherwise provided with the canvas, the user can alter the spacing configurations as between objects, and also for a particular layout logic that is applied to the object grouping, through interaction with the embedded tool of the canvas. This type of interaction is more fluid and intuitive for the user. Examples recognize that design users are sometimes inconvenienced when having to interact with a tool panel. Accordingly, the rendering engine <NUM> enables an embedded or on-canvas tool such as described with examples of <FIG> to enable the user to view and reconfigure spacing configurations.

In examples, spacing configurations of one or more layout logics also be displayed as part of the tools provided on a side panel of the canvas <NUM>. In examples, a tool panel (e.g., sidebar to canvas <NUM>) is synchronized with the spacing configurations, so that individual tools provide the user with direct access values of the existing spacing configurations of a design on the canvas <NUM>. Furthermore, the tool panel enables the existing values of the spacing configurations to be viewable.

<FIG> illustrates example design tools for selecting and implementing layout logic for individual objects of object groupings. The IGDS <NUM> generates layout configuration tools <NUM>, <NUM>, <NUM>, <NUM> (collectively "design tools") that enable users to select layout configuration logic for object groupings of a given canvas <NUM>. In some implementations, the layout configuration tools <NUM>, <NUM>, <NUM>, <NUM> can be provided on an as-needed basis, where each layout configuration tool <NUM>, <NUM>, <NUM>, <NUM> is associated with a corresponding object grouping on the canvas <NUM>. For example, each layout configuration tool <NUM>, <NUM>, <NUM>, <NUM> is associated with object groupings of a given layer, level or position on the canvas <NUM>. The user further provides input to specify the properties for the tool, which coincide with the configuration that is to be implemented by target objects (or objects that are automatically resized, repositioned or reconfigured based on input for another object) of the respective object grouping. The user can specify the properties of the individual layout configuration tools using, for example, pulldown menus, text input boxes or other similar feature. By way of example, the properties for each layout configuration tool <NUM>, <NUM>, <NUM>, <NUM> can specify (i) the target objects that are to be reconfigured based on user input that reconfigures another object, (ii) the type of behavior or layout operation that is to be automatically implemented by the target objects, and/or (iii) values for use in reconfiguring the target objects. For example, the user can specify a 'hug' property for a given object, meaning the object is to be resized based on its child objects being resized (e.g., by user input). The user can alternatively specify "fill" property for a given object (or object set), meaning the object is to resize relative to its parent object being resized. As an addition or variation, the properties can specify spacing configurations, such as "fixed spacing" or "even spacing" configurations.

Accordingly, example design tools enable a user to select layout configuration logic for object groupings, so as to configure layout object for orientation, spacing and other attributes. Additionally, the respective design tools can identify the target objects for implementation of the layout configuration logic. Additionally, some examples enable for different objects of a common object grouping to be linked with different types of layout configuration logic. For example, child objects of a common parent child object grouping may be associated with a different layout configuration logic as those associated with the parent object.

<FIG> illustrates use of a multi-state design tool that provides a preview of the design tools next state, according to one or more examples. A multistate design tool <NUM>, <NUM>, <NUM> is provided as part of a tool bar <NUM> to associate a particular state with a configuration of an object or object grouping. For example, a layout for a given object or a set of objects includes different types of justification. A user's selection of a particular type of justification reflects the design tool's current state. If the user interacts with the design tool and initiates a selection to another state, the interactive design tool displays or provide preview <NUM>, which indicates a representation of the next state which the user selection will make. Alternatively, the user selection can indicate or choose one of the states of the interactive design tool, and the preview reflects the choice to the user before the user has committed to the choice. In the examples shown by <FIG>, the multi-state tools <NUM>, <NUM>, <NUM> correspond to layout configuration tools, such as shown in examples of <FIG>. Accordingly, the multi-state tools <NUM>, <NUM>, <NUM> indicate the next state of an object or set of objects, based on layout configuration logic that is associated with the particular object or set of objects. In this way, the respective previews <NUM> show how the target objects implement the layout configuration logic as a response to a particular type of input.

<FIG> illustrate implementation of an interactive design tool that is embedded with a canvas on which a design under edit is rendered. The canvas <NUM> includes an object grouping <NUM>, including parent object <NUM> and child object sets <NUM>. The interactive design tool provides visualizations of spacing configurations <NUM>, <NUM> amongst the groupings of objects <NUM> that are rendered on a canvas <NUM>. The spacing configurations reflect a layout configuration of a linked layout logic, as well as the spacing between objects which are not be grouped are linked to a particular layout logic. The user can interact with the tool, which is embedded to receive input directed to the canvas <NUM> (e.g., pointer can be hovered over or near the areas of the spacing configurations). The user interactions can include for example, the user clicking and dragging to increase/decrease spacing configurations between objects and implementing the change with respect to the particular layout logic for future implementation or execution of that logic.

In some variations, the embedded tool displays number reflecting a quantity or amount of the spacing. The user can further interact with the number in order to change the spacing configuration of the particular configuration layout.

Still further, in some examples, an object grouping is associated with a first type of layout logic. The IGDS <NUM> includes a design tool, such as an embedded canvas tool, to enable the user to toggle between the current layout logic (e.g., the first type of layout logic) and one or more alternative layout configurations provided by different types of layout logic. For example, a user can toggle between a hug layout configuration and a stretch layout configuration using a toggle feature provided as an interactive tool or a tool embedded with the canvas. The toggling causes, for example, the layout engine <NUM> to implement the alternative types of layout logic, with each layout logic resulting in the object grouping being shown to have a different layout configuration. In this way, the user can view the effects of applying different types of layout logic to an object grouping.

<FIG> illustrates a computer system on which one or more embodiments are implemented. A computer system <NUM> is implemented on, for example, a server or combination of servers. For example, the computer system <NUM> is implemented as the network computing system <NUM> of <FIG> and <FIG>.

In one implementation, the computer system <NUM> includes processing resources (or processor(s)) <NUM>, memory resources <NUM> (e.g., read-only memory (ROM) or random-access memory (RAM)), one or more instruction memory resources <NUM>, and a communication interface <NUM>. The computer system <NUM> includes at least one processor <NUM> for processing information stored with the memory resources <NUM>, such as provided by a random-access memory (RAM) or other dynamic storage device, for storing information and instructions which are executable by the processor(s) <NUM>. The memory resources <NUM> may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by processor(s) <NUM>.

The communication interface <NUM> enables the computer system <NUM> to communicate with one or more user computing devices, over one or more networks (e.g., cellular network) through use of the network link <NUM> (wireless or a wire). Using the network link <NUM>, the computer system <NUM> can communicate with one or more computing devices, specialized devices and modules, and/or one or more servers.

In examples, processor(s) <NUM> execute instructions, stored with the memory resources <NUM>, in order to enable the network computing system to implement the network service <NUM> and operate as the network computing system <NUM> in examples such as described with <FIG>.

The computer system <NUM> may also include additional memory resources ("instruction memory <NUM>") for storing executable instruction sets ("IGDS instructions <NUM>") which are embedded with web-pages and other web resources, to enable user computing devices to implement functionality such as described with the IGDS <NUM>.

As such, examples described herein are related to the use of the computer system <NUM> for implementing the techniques described herein. According to an aspect, techniques are performed by the computer system <NUM> in response to the processor(s) <NUM> executing one or more sequences of one or more instructions contained in the memory resources <NUM>. Such instructions may be read into the memory resources <NUM> from another machine-readable medium. Execution of the sequences of instructions contained in memory resources <NUM> causes the processor(s) <NUM> to perform the process steps described herein. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement examples described herein. Thus, the examples described are not limited to any specific combination of hardware circuitry and software.

<FIG> illustrates a user computing device for use with one or more examples, as described. In examples, a user computing device <NUM> can correspond to, for example, a work station, a desktop computer, a laptop or other computer system having graphics processing capabilities that are suitable for enabling renderings of design interfaces and graphic design work. In variations, the user computing device <NUM> can correspond to a mobile computing device, such as a smartphone, tablet computer, laptop computer, VR or AR headset device, and the like.

In examples, the computing device <NUM> includes a central or main processor <NUM>, a graphics processing unit <NUM>, memory resources <NUM>, and one or more communication ports <NUM>. The computing device <NUM> can use the main processor <NUM> and the memory resources <NUM> to store and launch a browser <NUM> or other web-based application. A user can operate the browser <NUM> to access a network site of the network service <NUM>, using the communication port <NUM>, where one or more web pages or other resources for the network service <NUM> (see <FIG>) can be downloaded. The web resources <NUM> can be stored in the active memory <NUM> (cache).

As described by various examples, the processor <NUM> detects and execute scripts and other logic which are embedded in the web resource in order to implement the IGDS <NUM> (see <FIG>). In some of the examples, some of the scripts <NUM> which are embedded with the web resources <NUM> include GPU accelerated logic that is executed directly by the GPU <NUM>. The main processor <NUM> and the GPU combine to render a design interface under edit ("DUE <NUM>") on a display component <NUM>. The rendered design interface includes web content from the browser <NUM>, as well as design interface content and functional elements generated by scripts and other logic embedded with the web resource <NUM>. By including scripts <NUM> that are directly executable on the GPU <NUM>, the logic embedded with the web resource <NUM> better executes the IGDS <NUM>, as described with various examples.

Claim 1:
A computer implemented method comprising:
making a collection of layout logics (<NUM>) available in connection with a design interface under edit (<NUM>, <NUM>) that is rendered on a user device (<NUM>), wherein each layout logic of the collection (<NUM>) is executable to implement a predefined layout configuration in response to one or more predefined triggers of that layout logic, the collection of layout logics including a first layout logic that implements a first layout configuration identifying a relative dimensional relationship amongst a linked object set where a target set of objects of the linked object set is resized in response to input that resizes an associated set of objects of the linked object set;
based on user input, linking the first layout logic with a parent/child object grouping (<NUM>), the parent/child object grouping (<NUM>) including at least one parent object (<NUM>) and one or more child objects (<NUM>, <NUM>, <NUM>) that are positioned within a frame of the parent object (<NUM>);
detecting input to resize at least a first object of the parent/child object grouping (<NUM>) that is one of the associated object set of the first layout logic; in response to detecting the input, automatically implementing the first layout logic by resizing at least a second object of the parent/child object grouping (<NUM>) that is one of the target object sets, so as to maintain the relative dimensional relationship identified by the first layout configuration.