System and method providing responsive editing and viewing, integrating hierarchical fluid components and dynamic layout

Abstract

To adapt layout elements to build a responsive site by combining responsive editing functions with a process of a website building system.SOLUTION: A website building system includes: a processor; a database that stores website pages and layouts; and a responsive editing module that includes a rule engine to provide layout decisions of a website built according to dynamic layout rules and responsive editing rules associated with an incoming trigger; a responsive editor to receive the incoming trigger and dimensions of a current viewport, and to generate an updated fluid responsive design layout for the current viewport according to the layout decision; and a CSS (cascading style sheet) generator to map the features of the updated fluid responsive design layout design into a smart CSS for the current viewport.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] This application claims priority from U.S. Provisional Patent Application No. 62 / 850,244, filed May 20, 2019, and U.S. Provisional Patent Application No. 62 / 970,034, filed February 4, 2020, both of which are incorporated herein by reference.

[0002] The present invention relates to web site building systems, and in particular to response editing. [Background technology]

[0003] Website Building Systems (WBS) are used by both novices and experts to create interactive websites. Existing WBS are based on a visual editing model, and most WBS generally provide multiple templates, which may include a complete sample website, a website section, a single page or a section of a page.

[0004] WBS users (also called designers, subscribers, subscribing users or site editors) can design websites, and end users of the website ("users' users") can access the websites created by the users. End users usually access the system in read-only mode, but the WBS (and website) can allow end users to perform modifications to the website, such as adding or editing data records, adding talkbacks to news articles, adding blog entries to blogs, etc. A WBS may actually allow multiple levels of users (i.e., three or more levels) and assign different permissions and capabilities to each level. Users of a WBS (especially in a fully or partially online configuration, described below) can be registered with a WBS server, which manages the users, their websites, and their access by end users.

[0005] A WBS may be a standalone system or embedded inside a larger editing system. It may be online (i.e., the application is edited and stored on a server), offline or partially online (the website is edited locally but uploaded to a central server for publication). A WBS may use an internal data architecture to store a WBS-based site, and this architecture may organize the site's internal data and elements within the system that are processed. This architecture may differ from the external view of the site (e.g., as seen by an end user) and is usually different from the way the HTML pages sent to the browser are organized.

[0006] For example, the internal data architecture may contain additional properties for each element in a page (such as author, creation time, access permissions, links to templates, SEO (Search Engine Organization) related information, etc.) that are relevant to the editing and maintenance of the site within the WBS, but are not visible externally to end users (or some editing users). A WBS may implement part of its functionality (including both editing and runtime functionality) on the server or in a server configuration and part of its functionality on client elements. A WBS may also dynamically decide whether to perform some functionality on the server or on the client platform.

[0007] A WBS handles the creation and editing of visually designed applications (such as websites), which are typically composed of pages, containers, and components. Pages are displayed separately and may contain components. Components may include containers as well as atomic components. See FIG. 1, which is a schematic block diagram of a website building system (WBS) 2 that may be used to build a website 3, according to some demonstrative embodiments of the present invention. The WBS 2 may be used to build, create, edit, and / or generate websites 3 that may include pages 4 that may include components 5 (e.g., text, images, videos).

[0008] A WBS can also support hierarchical arrangement of components using atomic components (text, image, shape, video, etc.) as well as various types of container components (e.g., normal containers, single-page containers, multi-page containers, gallery containers, etc.) that contain other components. Subpages contained within a container component are called minipages, each of which can contain multiple components. Some container components display only one minipage at a time, while others display multiple minipages simultaneously.

[0009] These components may have little content or may have internal content. An example of the first category is a star component, which has no internal content (although it has color, size, position, attributes, and other parameters). An example of the second category is a text paragraph component, whose internal content includes the inner text as well as font, formatting, and layout information (which are not attributes of the component but are also part of the content). Of course, this content may vary from one instance of the text paragraph component to another. Components that have content are often called fields (e.g., "text fields").

[0010] A page can use a template, a general page template, or a component template. Specific examples of templates include the use of an application master page that contains components duplicated on all other regular pages, or the use of an application header or footer (repeated on every page). Templates can be used for entire pages or page sections. A WBS can provide inheritance between templates, pages, or components and can include multi-level inheritance, multiple inheritance, and diamond inheritance (i.e., A inherits from B and C, B and C inherit from D).

[0011] The visual arrangement of components within a page is called a layout. A WBS can also support dynamic layout processing, in which edits to a given component (or other changes that affect it, such as externally driven content changes) can affect other components, as further described in U.S. Patent No. 10,185,703, entitled “Website Design System Integrating Dynamic Layout and Dynamic Content,” issued on January 22, 2019, which is commonly owned by the applicant and incorporated herein by reference.

[0012] The WBS can be extended with add-on applications such as third party applications and components thereof, list applications (discussed in U.S. Patent Publication No. 2014 / 0282218, entitled "WBS Integrating Data Lists with Dynamic Customization and Adaptation," published September 18, 2014, which is co-owned by the applicant and incorporated herein by reference), and WBS configurable applications (discussed in U.S. Patent Publication No. 16 / 68338, entitled "System And Method for Creation and Handling of Configurable Applications for Website Building Systems," filed November 14, 2019, which is co-owned by the applicant and incorporated herein by reference). These third party applications and list applications can be added and integrated into the designed website.

[0013] Such third-party applications and list applications may be purchased (or obtained) through several distribution mechanisms, such as being pre-included in the WBS design environment, from an application store (integrated into the WBS market store or external) or directly from the third-party application vendor.

[0014] Third party applications may be hosted on the WBS vendor's own servers, on a third party application vendor's servers, or on a fourth party server infrastructure.

[0015] A WBS may also allow for procedural code to be added to some or all of the entities in the system. Such code may be written in a standard language (e.g., JavaScript), an extended version of a standard language, or a language that is specific to the particular WBS. The executed code may reference APIs provided by the WBS itself or by external providers. The code may also reference the internal structure and objects of the WBS, such as pages, components, and their attributes.

[0016] Procedural code elements can be activated via event triggers, which can be associated with user activity (such as mouse movements or clicks, or page transitions), other user-related activity (such as an underlying database or a particular database record being updated by another user), system events, or other types of conditions.

[0017] The activated code may be executed within a client element of the WBS, on a server platform, or using a combination of the two or a dynamically determined execution platform. Such a system is described in U.S. Patent Application Publication No. 2018 / 0293323, entitled "System and Method for Smart Interaction Between Website Components," published on October 11, 2018, which is commonly owned by the applicant and is incorporated herein by reference.

[0018] The creation of a typical site can be based on several models, including a visual editing model (where a user edits a previously created site), an automated site generation model, or a combination thereof as shown in FIG. 2 and described in U.S. Pat. No. 10,073,923, entitled “System and Method for the Creation and Update of Hierarchical Websites Based on Collected Business Knowledge,” issued on September 11, 2018, which is hereby referenced, co-owned by the applicant, and incorporated herein by reference.

[0019] It will be understood that throughout this specification, the acronym WBS (Website Building System) may be used to represent a website building system. Figure 2 shows a system 100 with a typical WBS 2 in communication with client systems operated by WBS vendor staff 61, site designers 62 (i.e., users), site users 63 (i.e., users of users), and an external system 70. The WBS 2 may further include a WBS Site Manager 10, an object marketplace 15, a WBS RT (Runtime) server 20, a WBS editor 30, a site generator system 40, and a WBS Content Management System (CMS) 50. It will be understood that the elements of Figure 2 may function as described in U.S. Pat. No. 10,073,923.

[0020] In the visual editing model, users (designers) edit a site based on one or more website templates. A WBS provider can offer multiple site (or other) templates, each of which may contain complete sample websites, website sections, single pages or sections of pages. Users may have the option to start with an empty site (essentially a "blank page" template), but typically start with an actual site template.

[0021] WBS providers may offer site templates ranging from the very general (e.g., mobile sites, e-stores) to the more specific (e.g., law firms, restaurants, florists) to the very specific (e.g., commercial real estate law firms or Spanish tapas restaurants). Such templates are typically stored in a repository accessible to users of the WBS and are typically categorized according to business type, subtype, or industry. Templates can also be created (and categorized) according to business type, but also style, color range, or other parameters. Site templates may be extended with additional (typically back-end) features, services, and code to become fully-fledged vertical solutions integrated with the WBS.

[0022] Thus, a user's initial experience when creating a site using the WBS visual editor might typically be for the user to select a template (e.g., according to style or industry type / subtype), possibly selecting a blank template, and then editing the template in the visual editor, including editing content, logic, layout, and attributes. Such editing might include (among other things) adapting the template and its elements to the specifics of the user's business. The user can then publish the modified site.

[0023] Under the site generation model, the WBS generates an initial site for the user based on a selected template, which is then potentially modified by filling in common elements of information, possibly allowing follow-up editing of the generated site. This filling in is necessary because the template contains different information (such as the business name and a description of the management team) in multiple places within its pages. Thus, the user may have to change the business name (for example) in multiple places throughout the template.

[0024] Furthermore, some template elements (e.g. a generic product page) may appear multiple times, with each instance displaying details of a different instance of the underlying entity (e.g. a different product offered on the site). Such multiple instances may be specified manually (e.g. details of different people in the company's management team) or may be dynamically derived from an external database (e.g. product details from a "products for sale" database). Such arrangements are often known as "repeaters".

[0025] Templates can also contain fields. For example, the WBS may allow a template designer to specify fields (also called "placeholders") to insert values ​​into the template, such as {CompanyName}, {ProductName}, {ProductPrice}, etc. Users can also specify values ​​for fields defined in the template selected for the website.

[0026] A WBS can allow users to enter simple or complex values ​​(e.g. text and images) as well as additional (non-field) information such as selection of included pages or website areas, colors, style information, links, formatting options, website display options, and decorative elements (such as borders and backgrounds).

[0027] The WBS may also allow the user to enter some of this additional information before selecting a template, and use this information to aid in the selection of the template (e.g., by narrowing the set of suggested templates). For example, the user may select a general color scheme (e.g., pastel) or style (e.g., business / formal), and the system may then use this selection to narrow the set of suggested templates.

[0028] The system may also display a series of views or questionnaires to allow the user to enter values ​​or selections (for both the defined fields and the additional information described above). The system may further create connections (or bindings) between the template's multiple instance elements (described earlier in this specification) and internal or external databases that provide the data instances used to generate the displayed instances.

[0029] Once a template has been selected and its fields and additional information specified (e.g., through a questionnaire or through binding to a data source), the WBS can generate a website containing the combined information. The user can then publish the site (through the WBS or otherwise).

[0030] WBS can perform semi-automatic site creation using another model described in U.S. Patent No. 10,073,923. Under this model, the system collects information about the user and the user's website requirements from multiple sources. The multiple sources can include, for example, user-filled questionnaires, existing user presence (such as existing websites or social media presence), industry sources (such as general trade websites), offline information, and an internal system repository (e.g., differentiating between real estate lawyers and personal injury lawyers) that provides information about specific industries, such as basic template information for specific industries (lawyers, restaurants, plumbers, graphic designers, etc.).

[0031] The system may also collect external information from other sites, both internal and external to the system. Such information may influence, for example, the surveys and layout element selections offered, suggested defaults, etc. Such information may also be collected on a statistical or summary basis, typically to not reveal information belonging to any single user and to protect users' privacy, anonymity, and legal rights (such as copyright). Such information may be found based on information provided by the user, which may be direct (e.g., existing website addresses) or indirect (business names and geographic addresses that may be used to find information about a business).

[0032] The collected information is analyzed and placed into a repository of content elements that are then mapped to layout elements that present the content from the content elements, and the layout elements are combined to form the site. The process of layout element mapping, selection, and combination can be fully automatic or semi-automatic (i.e., involving user interaction).

[0033] To support the above functions, a WBS typically maintains a set of repositories stored on one or more servers or server farms. Such repositories may typically include various related repositories such as a user information / profile repository, a WBS (WBS) component repository, a WBS site repository, a Business Intelligence (BI) repository, an edit history repository, a third party application store repository, etc. The system may also include site / content creation related repositories such as a survey type repository, a content element type repository, a layout element type repository, a design kit repository, a completed survey repository, a content element repository, a layout element repository, a rule repository, a family / industry repository, etc. A description of these repositories may be found in U.S. Pat. No. 10,073,923.

[0034] Responsive editing for web design is known in the art. In an era of creating and viewing websites on different sized viewports such as personal computers, tablets, and mobile communication devices (all having different screen displays and windows with different display dimensions), responsive editing allows a single web page to be rendered on a variety of devices and window or screen sizes. It can be understood that websites may be responsive, i.e., may change their design when viewed, and may be supported by a responsive editor. Alternatively, some systems may support the functionality of responsive sites without the use of a responsive editor. Thus, content, design, and performance are maintained across all devices and platforms, ensuring usability and satisfaction.

[0035] Sites designed to comply with responsive editing typically adapt their layout to the viewing environment by using mechanisms such as a proportion-based grid that allows sizing of page elements in relative units such as percentages rather than absolute units such as pixels or points. Elements may be docked on the page and breakpoints may be defined to specify points at which the content and design of a website page should adapt in a non-continuous way to fit different viewport sizes. Breakpoints define specific width points at which the web page should use a different layout or component placement accordingly (rather than continuously modifying the design).

[0036] There are many ways to implement a responsive website (both for viewing and editing). For example, responsive site behavior can be implemented:

[0037] On the server side, for example, the page definition is pre-processed or adjusted for a given target device or width.

[0038] On the client side, use JavaScript (or other browser-based language) to handle page width and other target characteristic parameters or changes.

[0039] On the client side, using Cascading Style Sheets (CSS) or other markup, presentation, and style definition languages ​​that provide the ability to query device, platform, or display information and create declarative style definitions based on the characteristics of the target device or display. Such declarative definitions can be executed within the browser's rendering engine without requiring the rendering of external code (such as JavaScript code) to be executed.

[0040] When the user changes the viewport display (by changing their device or display window), the website should automatically switch in one of the above ways (or a combination of them) to accommodate the change in resolution, viewport size and scripting capabilities. Summary of the Invention

[0041] Therefore, according to a preferred embodiment of the present invention, there is provided a website building system (WBS) and a method implemented thereon, the WBS having a processor, at least one database storing website pages and layouts including fluid components, breakpoint ranges for multiple viewport sizes, dynamic layout rules, and responsive editing rules for editing the fluid components according to the breakpoint ranges, and a responsive editing module executing on the processor, the responsive editing module further including a rules engine associated with at least one input trigger to provide a layout decision for a page of the website built by the WBS according to the dynamic layout rules and the responsive editing rules, a responsive editor receiving the at least one input trigger and a current viewport size, and generating an updated fluid responsive design layout for the current viewport according to the layout decision, and a CSS generator to map design features of the updated fluid responsive design layout to a smart CSS (Cascading Style Sheets) for the current viewport.

[0042] Additionally, in accordance with a preferred embodiment of the present invention, the at least one database also stores website pages and layouts that include non-fluid components.

[0043] Furthermore, in accordance with a preferred embodiment of the present invention, the system further comprises a smart mesh applier that applies a mesh grid to a static website design having non-fluid components and converts it into a responsive design for use in the responsive editor.

[0044] Furthermore, in accordance with a preferred embodiment of the present invention, the system further comprises a Machine Learning (ML) / Artificial Intelligence (AI) engine trained to provide ML / AI support for at least one of the layout decisions and the smart mesh applier.

[0045] Furthermore, in accordance with a preferred embodiment of the present invention, the ML / AI engine includes at least one machine learning feedback module.

[0046] Furthermore, in accordance with a preferred embodiment of the present invention, the responsive editor further includes an edit receiver that receives at least one input trigger, an edit handler that defines page changes to the component in response to the at least one input trigger and the size of the current viewport, and a previewer that enables the user to preview the layout at different breakpoints within the breakpoint range for the current viewport.

[0047] Further, according to a preferred embodiment of the present invention, the response editor further comprises an explainer and a suggester that provide explanations to the user in certain actions by the edit handler and suggest solutions or suggestions to the user in editing according to the ML / AI engine.

[0048] Further according to a preferred embodiment of the present invention, the edit handlers include at least one of: a DL (Dynamic Layout) handler for handling conflicts between responsive edit rules and said dynamic layout rules for at least one input trigger; a layout handler for arranging a layout of components depending on a current viewpoint size; a text scaler for scaling a text point size of a component between a minimum and a maximum predetermined value depending on a current viewpoint size; a visibility handler for managing hiding and unhiding of components in a breakpoint range; a component handler for processing component attribute changes based on at least one input trigger and applying the component to a layout design accordingly; an animator for generating animations for user selection of a component at a given width range or at a particular breakpoint; an add panel handler for adding presets and panels to a page depending on at least one input trigger; a component docker for docking a component into a responsive edit grid arrangement in its containing component as a result of at least one input trigger; a grid handler for adjusting the responsive edit grid of the containing component depending on an output of the component handler depending on at least one input trigger;

[0049] Further, according to a preferred embodiment of the present invention, the ML / AI engine analyzes the absolute layout definition in the responsive editor during editing and saving, detects the user's intent, and translates the user's intent into a declarative set of rules.

[0050] Furthermore, in accordance with a preferred embodiment of the present invention, the explainer and suggester includes a next move suggester that suggests the next move depending on the user's intent.

[0051] Further, in accordance with a preferred embodiment of the present invention, the input trigger is at least one of a user edit, a system change, a device type change, a user property, a user / device interaction change, a simultaneous edit by a second user, a system procedural change, and a user environment change.

[0052] Further, according to a preferred embodiment of the present invention, a smart mesh applier has a page receiver for receiving an input page having non-flowable components, a trigger handler for recognizing classes for input dynamic layout triggers, a page analyzer for analyzing the configuration and relationships of components of the input page, and a page converter for converting the input page into a mesh grid according to the analysis and classes and generating CSS definitions in a CSS generator.

[0053] Additionally, in accordance with a preferred embodiment of the present invention, the page converter includes a splitter placer that replaces implicit dynamic layout anchors using horizontal splitters, and a mesh grid generator that generates a mesh grid according to the output of the splitter placer.

[0054] Furthermore, in accordance with a preferred embodiment of the present invention, the mesh grid generator includes an add row generator that adds additional invisible rows, if necessary, to create additional grid space for supporting components on the mesh grid, and a wedge generator for implementing wedge elements within the mesh grid.

[0055] Furthermore, in accordance with a preferred embodiment of the present invention, the current viewport includes multiple displays.

[0056] Furthermore, in accordance with a preferred embodiment of the present invention, the class is one of processed Javascript, processed browser engine and underlying grid generation.

[0057] Furthermore, in accordance with a preferred embodiment of the present invention, the responsive editor supports drag-and-drop editing of layout designs that combine fluid components, breakpoint support, and smart meshes.

[0058] Furthermore, in accordance with a preferred embodiment of the present invention, the analysis follows at least one of dynamic layout rules, component properties, content, component edit history, associated business information, and component group recognition.

[0059] Therefore, according to a preferred embodiment of the present invention, there is provided a website building system (WBS) and a method implemented thereon, the WBS including a processor, a database storing website pages having at least one layout and including non-flowing components, and a mesh applier executing on the processor, the mesh applier including a page receiver for receiving an input page, a page analyzer for analyzing the configuration and relationships of components of the input page, and a page converter for converting the input page according to the analysis into a smart mesh architecture to generate a smart Cascading Style Sheet (CSS) definition, the smart mesh architecture supporting responsive viewing of components of the input page, the components of the input page being affected by other components and external triggers. [Brief description of the drawings]

[0060] The subject matter which is regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of this specification, however, the invention, both as to organization and method of operation, together with its objects, features, and advantages, may best be understood by reference to the following detailed description when read in conjunction with the accompanying drawings. [Figure 1] FIG. 1 is a schematic block diagram of a configuration of a website building system that can be used to build a website. [Diagram 2]1 is a schematic diagram of elements of a prior art website building system. [Diagram 3] 1 is a schematic diagram of creating, viewing, and editing a website using a response editor module constructed and operative in accordance with an embodiment of the present invention; [Figure 4] 4 is a schematic diagram of elements of the response editing module of FIG. 3, constructed and operative in accordance with one embodiment of the present invention; [Diagram 5] 5 is a schematic diagram of elements of the response editor of FIG. 4, constructed and operative in accordance with one embodiment of the present invention. [Figure 6A] 1 is a schematic diagram of how a component with a given source breakpoint definition can be applied to a page or container with a new target breakpoint definition. [Figure 6B] 1 is a schematic diagram of how a component with a given source breakpoint definition can be applied to a page or container with a new target breakpoint definition. [Figure 6C] 1 is a schematic diagram of how a component with a given source breakpoint definition can be applied to a page or container with a new target breakpoint definition. [Figure 7A] 1 is a schematic diagram of a site width variation on a site layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 7B] 1 is a schematic diagram of a site width variation on a site layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 7C] 1 is a schematic diagram of a site width variation on a site layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 7D] 1 is a schematic diagram of a site width variation on a site layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 7E] 1 is a schematic diagram of a site width variation on a site layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 7F]1 is a schematic diagram of a site width variation on a site layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 7G] 1 is a schematic diagram of a site width variation on a site layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 8] 6 is a schematic diagram of elements of the edit handler of FIG. 5, constructed and operative in accordance with an embodiment of the present invention; [Figure 9A] FIG. 13 is a schematic diagram of site width changes when text is not scalable. [Figure 9B] FIG. 13 is a schematic diagram of site width changes when text is not scalable. [Figure 9C] FIG. 13 is a schematic diagram of site width changes when text is not scalable. [Figure 9D] FIG. 13 is a schematic diagram of site width changes when text is not scalable. [Figure 9E] FIG. 13 is a schematic diagram of site width changes when text is not scalable. [Figure 10A] 1 is a schematic diagram of section usage and component selection for a breadcrumb display, constructed and operative in accordance with an embodiment of the present invention; [Figure 10B] 1 is a schematic diagram of section usage and component selection for a breadcrumb display, constructed and operative in accordance with an embodiment of the present invention; [Figure 11A] 1 is a schematic illustration of the use of add menus for various element types, constructed and operative in accordance with an embodiment of the present invention; [Figure 11B] 1 is a schematic illustration of the use of add menus for various element types, constructed and operative in accordance with an embodiment of the present invention; [Figure 11C] 1 is a schematic illustration of the use of add menus for various element types, constructed and operative in accordance with an embodiment of the present invention; [Figure 12] 1 is a schematic diagram of the use of create / close space for drag-and-drop editing, constructed and operative in accordance with an embodiment of the present invention; [Figure 13A] 1 is a schematic diagram of a user interface for design unification across multiple breakpoint ranges, constructed and operative in accordance with an embodiment of the present invention; [Figure 13B] 1 is a schematic diagram of a user interface for design unification across multiple breakpoint ranges, constructed and operative in accordance with an embodiment of the present invention; [Figure 14] FIG. 2 is a schematic diagram of stack components constructed and operative in accordance with an embodiment of the present invention; [Figure 15A] 1 is a schematic diagram of layouter components and possible arrangements thereof, constructed and operative in accordance with an embodiment of the present invention; [Figure 15B] 1 is a schematic diagram of layouter components and possible arrangements thereof, constructed and operative in accordance with an embodiment of the present invention; [Figure 16A] 1 is a schematic diagram of the use of a repeater, constructed and operative in accordance with an embodiment of the present invention; [Figure 16B] 1 is a schematic diagram of the use of a repeater, constructed and operative in accordance with an embodiment of the present invention; [Figure 16C] 1 is a schematic diagram of the use of a repeater, constructed and operative in accordance with an embodiment of the present invention; [Figure 17A] 1 is a schematic illustration of the use of a response edit grid, constructed and operative in accordance with an embodiment of the present invention; [Figure 17B] 1 is a schematic illustration of the use of a response edit grid, constructed and operative in accordance with an embodiment of the present invention; [Figure 17C] 1 is a schematic illustration of the use of a response edit grid, constructed and operative in accordance with an embodiment of the present invention; [Figure 17D] 1 is a schematic illustration of the use of a response edit grid, constructed and operative in accordance with an embodiment of the present invention; [Figure 18] 1 is a schematic diagram of a cropping process using a responsive editing grid background, constructed and operative in accordance with an embodiment of the present invention; [Figure 19A] 1 is a schematic diagram of a scenario involving design recommendations in accordance with an embodiment of the present invention; [Figure 19B] 1 is a schematic diagram of a scenario involving design recommendations in accordance with an embodiment of the present invention; [Figure 20A] FIG. 5 is a schematic diagram of the use of multiple machine learning models employed by the ML / AI engine of FIG. 4, constructed and operative in accordance with an embodiment of the present invention. [Figure 20B] FIG. 5 is a schematic diagram of the use of multiple machine learning models employed by the ML / AI engine of FIG. 4, constructed and operative in accordance with an embodiment of the present invention. [Figure 21] 5 is a schematic diagram of elements of the mesh applier of FIG. 4, constructed and operative in accordance with an embodiment of the present invention. [Figure 22] 22 is a schematic diagram of elements of the page converter of FIG. 21, constructed and operative in accordance with an embodiment of the present invention. [Figure 23] 1 is a schematic diagram of relationships between components and a splitter, constructed and operative in accordance with an embodiment of the present invention; [Figure 24A] 1 is a schematic diagram of an isolation of pushing relationships between components, constructed and operative in accordance with an embodiment of the present invention; [Figure 24B] 1 is a schematic diagram of an isolation of pushing relationships between components, constructed and operative in accordance with an embodiment of the present invention; [Diagram 25] 1 is a schematic diagram of the application of CSS grid rules to splitters and components constructed and operative in accordance with an embodiment of the present invention; [Figure 26] 1 is a schematic illustration of component distances and resulting docking effects, constructed and operative in accordance with an embodiment of the present invention; [Figure 27] 1 is a schematic diagram of a component-to-component pushing scenario using anchors, constructed and operative in accordance with an embodiment of the present invention; FIG. [Figure 28] 1 is a schematic diagram of a component-to-component pushing scenario using anchors, constructed and operative in accordance with an embodiment of the present invention; FIG. [Figure 29A]1 is a schematic illustration of the use of additional lines to maintain element layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 29B] 1 is a schematic illustration of the use of additional lines to maintain element layout, constructed and operative in accordance with an embodiment of the present invention; [Figure 29C] 1 is a schematic illustration of the use of additional lines to maintain element layout, constructed and operative in accordance with an embodiment of the present invention; [Diagram 30] 1 is a schematic illustration of the use of wedges to maintain component layout, constructed and operative in accordance with an embodiment of the present invention; [Diagram 31] 1 is a schematic diagram of the use of explicit components between distant components, constructed and operative in accordance with an embodiment of the present invention;

[0061] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, dimensions of some elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0062] In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

[0063] Prior art responsive editing systems typically operate at the website or page level, have predefined fixed breakpoints for adjusting the size of the website, and allow responsive editing on a limited number of viewports (including screens, displays, and windows). When a site is modified (such as a component changing size or position), the change can be understood to be continuous between breakpoints (within a single breakpoint range). When breakpoints are crossed, discontinuous changes occur and components may jump from one position to another (e.g., component A may move side-by-side over component B as the screen width shrinks). Components may also appear and disappear when breakpoints are crossed.

[0064] Applicant has found that if web designers have complete control over their breakpoints, i.e., can define their own ranges, they can effectively design web sites with the knowledge that the sizes of the breakpoint ranges can be handled continuously, and by modifying their design to display their web site across a wider range of viewports, thus allowing users to more effectively create and handle multiple sized sites.

[0065] Additionally, Applicant has found that a responsive editor suited to a hierarchical component-based system, i.e., handle functionality at the component level, can ensure that breakpoints can be handled not only at the page level, but also at the preset and container levels (e.g., using a responsive editing grid at the container component level for docking its sub-elements), along with any implemented hierarchy. Thus, the ability for designers to define their own breakpoint ranges can give them complete control over their media, such as the ability to switch the use of images from "background" to "floating," the ability to apply multiple focal points (one for each breakpoint), and the ability to provide different cropping parameters for each breakpoint range.

[0066] Applicant has further found that responsive editing components can be considered fluid and therefore responsive to dynamic layout triggers and events that may occur during website editing. A layout may incorporate fluid components whose size and attributes may be influenced by a parent (e.g., by a parent change or a viewport width change) or by additional triggers. Effects may be determined automatically by the system or may be specified or edited by the user (e.g., a component width is a given percentage or function of a parent component width).

[0067] The applicant has also found that the use of machine learning (ML) and artificial intelligence (AI) techniques and models to facilitate aspects of user work, such as understanding how a user works to automatically adapt the user's layout to best fit all breakpoints, may be integrated into the responsive editing system described herein above. This may include a system that provides sections and components by understanding and detecting the user's intent. The system may achieve its goal using several ML / AI engines using information available in the WBS, such as website component information, business information, editing history, and other site-related information, as well as WBS-based training feedback as described in U.S. Patent Application No. 16 / 878,831, entitled "System and Method for Integrating User Feedback into Website Building System Services," filed May 20, 2020, which is co-owned by the applicant and incorporated herein by reference.

[0068] Applicant has further found that using the application of rule-based and ML / AI engines, the system can also convert drag-and-drop designs into full CSS, providing full design expressive capabilities that understand the best fit locations of breakpoints, which can also include packaged layouts that support responsive design and fluid components and can further adapt to the breakpoints of the target design.

[0069] Thus, the responsive editing functionality can be combined with the process of the website building system described in the background, and the layout elements described can be adapted to build a responsive site.

[0070] Furthermore, applicant has also found that the above-mentioned functionality may be applied to existing non-responsive websites (i.e., websites without breakpoints) if they are converted or rendered into a smart mesh format that can be efficiently implemented on web browsers and other client systems. This capability may be applied to existing WBS sites, or sites imported from other systems. Thus, the smart mesh structure may be used to declaratively define (responsive and fluid) sites. In this way, the browser may (for example) respond to width changes inside the browser engine (e.g., as part of CSS processing and display rendering). This process may provide reasoning and analysis for effective dynamic layout manipulation based on analysis of WBS component properties (geometric / non-geometric) and accumulated information (such as edit history and collected BI) tasks such as group detection and anchor generation.

[0071] 3, there is shown a system 200 for creating, viewing, and editing websites using a response editor module constructed and operative in accordance with an embodiment of the present invention. System 200 may include elements of system 100 (as well as any sub-elements) as described in U.S. Patent No. 10,073,923, along with a response editing module 300. In alternative embodiments, system 200 may provide an integrated module that combines the functionality of WBS editor 30, site generation system 40, and response editing module 300, or a module that combines the functionality of WBS editor 30 with only response editing module 300.

[0072] The following discussion may be understood to refer to applications created by WBS and accessed by end users as websites, although system 200 is entirely applicable to other categories of online applications accessed using specific client software. Such client software may run standalone or may be activated from a browser (e.g., Adobe Flash plug-in). End users may access these websites not only with client software on a typical PC (as shown in FIG. 2 and currently referenced), but also on smartphones, tablet computers, and other desktop, mobile, or wearable devices. Alternatively, the description herein may apply to systems for generating or editing mobile applications, native applications, or other application types, as described in U.S. Patent No. 9,996,566, entitled “Visual Design System for Generating Visual Data Structures Associated with Semantic Organizations Based on Hierarchies of Components,” granted June 12, 2018, co-owned by the applicant, and incorporated herein by reference.

[0073] Further, the following discussion focuses on websites hosted by a website building system provider (implementing system 200). However, system 200 may be implemented with additional types of websites and other non-web digital creations. These include, for example, the following (or any combination of these): full websites and website sections (e.g., a subset of a website's pages) or a section of one or more website pages, websites designed for normal desktop computer browsing, mobile websites and tablet-oriented websites, and websites created by the website building system but hosted externally (i.e., not by the website building system vendor). They may further include websites that run locally on a local server installed on a user's machine, websites that act as a UI and are hosted within other systems (including embedded systems and devices), and other types of websites and other non-web digital creations, which may also include websites or other displayed visual compositions hosted within a larger system, including (for example) pages hosted within social networks (such as Facebook®), blogs, portals (including video and audio portals that support user-customizable pages such as YouTube® channels), and the like. This may include other types of remotely accessible online presences that are not considered websites.

[0074] Other types of websites and other non-Web digital creations may also include interactive (mobile or other) applications, including hybrid applications (which combine locally installed elements with remotely left elements), and non-interactive digital creations such as emails, newsletters, and other digital documents.

[0075] Reference is now made to FIG. 4, which illustrates elements of the responsive editing module 300. The module 300 may further comprise a responsive editor 310, a CSS generator 320, a mesh applier 330, a rules engine 340, and an ML / AI engine 350. The responsive editor 310 may enable a user to create and edit a responsive website (including specifying ranges of breakpoints) and may use functionality from the rules engine 340 and the ML / AI engine 350. The CSS generator 320 may generate smart CSS as a result of the editing changes and may use the mesh applier 300 to convert a non-responsive website into a responsive website with a grid that is a responsive target display change. It may be appreciated that the updated CSS created as a result of the editing may be stored in the CMS 50 as a CSS or as a data structure representing it. The CSS generator 320 may take this definition and generate smart CSS accordingly. The functionality of these elements is described in more detail below.

[0076] When implemented on a non-browser based system, it can be appreciated that system 200 may be implemented in different ways, including having some elements of the system integrated with the underlying system rendering or display framework, which may be on a server, client, or other element of the underlying system or platform.

[0077] Reference is now made to FIG. 5, which illustrates elements of the answer editor 310. It can be seen that the answer editor 310 can function as a normal editor that provides a standard editing UI for interacting with a user. The answer editor 310 can further include an edit receiver 3101, an edit handler 3102, a previewer 3105, and an explainer and suggester 3104. The functionality of these elements is described in more detail below. The explainer and suggester 3104 can further include a next move suggester 31041.

[0078] The edit receiver 3101 can receive input events or triggers (both from the system and from the user). The edit handler 3102 may determine the required handling of the edits, the previewer 3105 may provide a WYSIWYG preview of the application of the edits, and the explainer and suggester 3104 may provide an explanation to the user of a given action and provide solutions or suggestions to the user. The functions of these elements are described in more detail below.

[0079] As described herein above, the system 200 implements a responsive site based on a layout that can change based on changes to one or more site variables or parameters (herein "influence variables"). One example is a layout change (e.g., stretching or compressing the layout) in response to changes in the site's window or display width.

[0080] The responsive editing module 300 can allow a user to define width value breakpoints and match breakpoint ranges for displays associated with different viewports (e.g., 320-750 pixels for smartphone screens, 750-1000 pixels for tablet screens, 1000 pixels or more for desktop screens).

[0081] System 200 can also support additional form factors larger than normal desktop screens, such as the very large displays used in bulletin board systems (or multi-screen applications, described in more detail below), as well as very small ones (such as smart watch or wearable device screens). Thus, a website or application can be built for desktop resolutions with variations for both lower and higher resolutions.

[0082] It can be understood that when the width of a display site varies within a single breakpoint range, the layout can change continuously or semi-continuously. When a breakpoint is crossed, the layout can change non-continuously (as described further below), and components can change their position, size, visibility, or other attributes. This process is known as cascading.

[0083] As discussed in more detail below, the system 200 can implement additional influencing variables (such as changing the display height of the site) or a combination of multiple such parameters. Variables can also include other information besides size, such as platform type.

[0084] Furthermore, the influencing variables may be functions of multiple parameters rather than a single parameter (or combination thereof). For example, the system 200 may allow defining different layouts based on the aspect ratio of the display (which is a function of the width and height of the display).

[0085] As described herein above, layouts can incorporate fluid components whose sizes and attributes can be influenced by their parents (e.g., by a change in parent or a change in viewport width) or by additional triggers, described in more detail herein below. It can be understood that these effects can be either automatically determined by the edit handler 3102, or specified or edited by the user (e.g., a component width is a predetermined percentage or function of a parent component width). Such fluidity can be at the whole component level, but also applied to specific sub-elements of a component (e.g., a multi-column layout component where the width of a column may be specified as a formula based on the width of the whole component).

[0086] The system 200 can further apply dynamic layout techniques and other layout modifications in response to additional events and response triggers that occur in or to the site, as described further below.

[0087] As described above in this specification, the module 300 can enable breakpoint definition at several levels, including at the website level, at the individual page level, at the section level, and at the specific container level (including a screen-wide container or other container).

[0088] The module 300 may also define inheritance-based breakpoint definitions, for example, a site-level set of breakpoints, allowing pages and / or sections to create their own variants.

[0089] It may be appreciated that the fluidity of components as described herein above may be due to their ability to adapt in response to size changes or other affecting variable changes. Each component or layout may have its own processing rules that are processed by the rules engine 340 accordingly. These rules may be stored in the CMS 50. It may be appreciated that this ability to adapt may be due to the application of predefined processing rules along with the application of responsive editing grids and elements such as layouts, splitters, and wedges that allow components to be moved within containers and hierarchies, as described in more detail below in connection with the mesh applier 330.

[0090] It can be appreciated that processing rules may affect editing procedures such as auto-docking (changing alignment and margins of components when dragged), size transformations when reparenting, size transformations when changing units, dragging and resizing elements (updating grid area, size and margins), applying grid-over-content (updating grid area, size and margins), deleting a grid row or column, deleting the entire grid, resizing minimum and maximum values, changing the display of a layouter or repeater, etc.

[0091] Other rules can include dragging a component into a non-existent cell on a lower breakpoint (updating that grid area to remain in the viewport), creating stacks, unstacking stacks, changing alignments, expanding and contracting docking and margins, adding, removing and flipping sections (updating the page and section grids), and flipping sections from horizontal to vertical (updating component size and position).

[0092] Reference is now made to Figures 6A-C, which show examples of how a component with a given source breakpoint definition can be applied to a page or container with a new target breakpoint definition. This can be relevant in scenarios such as copying a section from one page to another (where the pages have different breakpoint definitions), using presets (where the user defines a different breakpoint range than the default one that comes with the preset), shared parts (common elements shared by inheritance across multiple pages), etc. This can involve detaching the shared part, going back to the page breakpoints, and moving elements from the page to the shared block or vice versa. In Figure 6A, the target breakpoints are fewer in number than the source breakpoints. In this scenario, one of the source breakpoints is dropped. In Figure 6B, the target has only one breakpoint. Therefore, the coverage is highest on the desktop, since the last breakpoint is defined to infinity (no maximum value). In Figure 6C, the target has more breakpoints than the source, and therefore the target breakpoints may be included in the source breakpoints or between them. A top-level overlap can be selected to define the mapping.

[0093] It will be appreciated that the responsive editing module 300 may also provide drag-and-drop editing, as well as a number of other capabilities as described below, to support editing, publishing, and running the generated site that supports responsive design, fluidity, and dynamic layout.

[0094] Further, it can be seen that the system 200 provides responsive design, fluidity, and dynamic layout capabilities during run-time (viewing a site) as well as during editing (when working in WYSIWYG mode to edit a site or when working in preview mode within the editor 310), and can also provide functionality at the save, preview, and publish stages.

[0095] The system 200 can also provide site templates specific to responsive design, fluidity, and dynamic layouts. Users can create and edit sites using such templates.

[0096] It may be appreciated that the module 300 may also provide additional functionality to standard website building system procedures, such as an add context panel and next move suggestions, described below, which may reduce editing time and improve usability (due to the user having fewer options to choose from or more options in focus).

[0097] The module 300 may also provide capabilities such as different breakpoints for existing layouts, and layout suggestions via the explainer and suggester 3104 for optimizing for site exploration and performance, allowing users to create better performing and more professionally designed sites.

[0098] As discussed herein above, the present description focuses on an embodiment of the system 200 in which the website layout is affected by changes in the displayed site width. However, the system 200 may be adapted to modify the site attributes and layout due to other affected variables, including changes and triggers. These include, but are not limited to, changes in device properties, such as width, height, orientation, changes in the display viewport properties (if the viewport width or height is changed), and changes in the site display subarea within the editor. This occurs, for example, when the response editor 310 has a site display area that is a variable subarea of ​​the editor area. The response editor 310 may allow this area to be resized by the editing user (as shown in Figures 7A-7G, currently referenced) and may modify the site layout based on this resizing. A detailed description of Figures 7A-7G is provided in more detail below.

[0099] Other triggers and changes can include user edits and modifications to components, their attributes and their layout, changes to user properties such as changes to device type (e.g., devices with different resolutions), changes to geography (location), user identity or other specific attributes associated with the user, and changes to environmental properties such as changes to lighting levels (day / night, indoor / outdoor).

[0100] Another trigger may be a change to an interaction property, e.g., a change in the distance between the user and the screen (affecting how the user sees the screen). Thus, a site may detect when a user is looking at it from a certain distance (thus effectively viewing the site on a smaller screen) and adapt the site to that distant view, perhaps changing the site layout and using a larger font size. Then, when the user moves closer to the screen, the site may change. The user's distance may be measured (for example) by any sensor available to the system, or by analysis of video camera output available to the system. This can also work with multiple viewing users (e.g., in a public setting) by optimizing the distance (e.g., average distance) that best represents multiple viewers.

[0101] It can be appreciated that the various triggers and modifications described herein above can be accomplished in a number of ways. If the trigger or modification is static, the site is opened with given parameters (e.g., a given device, resolution, width, or height). In such a scenario, the system 200 can configure the site based on various influencing variables, and this configuration may remain constant for the duration of the session.

[0102] The triggers may be distinct, for example, a site is opened on a mobile device in portrait mode (using a given width) and the user switches to and from landscape mode (having a larger width).

[0103] The trigger may be continuous, for example the site is opened in a window with a given width and the user changes this window width (either while editing or viewing) and the module 300 can respond to these changes continuously and modify the site to always adapt to the current width (or other influencing variables).

[0104] A trigger can also be non-user; that is, the site is affected by a change that is not based directly on a user's actions, such as a change in a system procedure. This could be, for example, due to any other change to an impact variable (as described above in this specification). This may also be the case when a user views a site that is being edited by a different user, in embodiments that support such simultaneous editing and viewing of sites.

[0105] It can be appreciated that all of these triggers and modifications are applicable not only when editing a site, but also during runtime access to the site. As described above in this specification, WBS2 may provide some editing functionality during runtime (e.g., allowing users of a blog site to create designed blog posts).

[0106] Some of the above triggers (e.g., changes in the environment or interactions) may also be relevant within physical environments, as well as non-physical environments (e.g., changes that occur during editing or interaction with a site in virtual reality, augmented reality, or any other non-physical environment).

[0107] Reference is now made to Figure 8 which illustrates the elements of the edit handler 3102. The edit handler 3102 may further comprise a dynamic layout (DL) handler 31021, a layout handler 31022, a text scaler 31023, a visibility handler 31024, a component handler 31025, an animator 31027, a component docker 31028, a grid handler 31029, an add panel handler 31030, a component grouper 31031 and an image handler 31032. The functionality of these elements is described in more detail below.

[0108] As described above, the edit receiver 3101 can receive an input event, which may be an edit, change, or trigger to the current site, page, or component. The edit handler 3102 can determine what changes need to be made as a result of the input event. It can be appreciated that sub-elements of the edit handler 3102 can use the rules engine 340 and the ML / AI engine 350 to improve their functionality, as described in more detail below.

[0109] As mentioned herein above, the system 200 can also integrate responsive design capabilities with triggered dynamic layout changes, as described in US Pat. No. 10,185,703.

[0110] The module 300 may implement dynamic layout processing during editing (e.g., reflecting editing changes made by a user) as well as at run-time. The system 200 may use different mechanisms in each case since requirements may differ between the cases. A third usage scenario may be a preview or simulation mode, a runtime view of a web page functioning within an editing environment, which may behave differently than a normal runtime view.

[0111] Dynamic layout may be understood to include moving and resizing components on a screen based on dynamic layout triggers. These dynamic layout triggers may include changes in content, changes in content formatting, switching components between multiple configurations, use of multiple target platforms (displaying an application using different technologies on different display platforms), multiple screens or display viewport sizes (displaying an application using multiple displays of different sizes and resolutions, such as screen rotation or window resizing). Other dynamic layout triggers may include dynamic data (use of components with dynamic data that changes over time), end user initiated changes, application initiated layout changes, moving and resizing components in an editor, and concurrent editing of a page (e.g., by other users in the system providing shared editing or immediate updates of a page edited by a user).

[0112] It can also be appreciated that a component can change its size / position at runtime due to various factors such as:

[0113] User-initiated content changes in components that allow runtime editing, such as the blog component (which allows user submissions / edits of comments).

[0114] Content changes that reflect content imported from an external source. This could be (for example) a field displaying a single field content, or a repeater showing multiple records from an external database.

[0115] Changes to content that reflect simultaneous editing of content by other users, or simultaneous editing of the same page by multiple users in a system that allows simultaneous editing and viewing of the same page.

[0116] Changes in content or size due to site-initiated / programmed effects (e.g. code tied to site events that affect component content, formatting, attributes or layout).

[0117] Requests made by other components or third-party applications (or other embedded components).

[0118] Page size changes due to environment size changes, for example, deployment to different sized platforms, window / viewport resize, form factor changes (portrait / landscape), screen size changes, etc.

[0119] Any other changes that affect the component, such as changes due to gallery scrolling, or mouse overs that affect the component (for example causing a zoom in).

[0120] It may be understood that pages and layouts are not always static. In particular, components may switch between multiple states and even be animated. State changes and animations may include changes to the component's position, size, layout, rotation, style, shape, transformation, etc. Module 300 may support multiple triggers for such state changes and animations, including cursor movement, scrolling, interaction with other elements, programmatic, database-based, etc.

[0121] The layout of the edited elements can take these changes and animations into account, either as driving dynamic layout operations or with respect to planning appropriate space for them in various page configurations. Also, state definitions and animations for specific components can be changed at individual breakpoint ranges.

[0122] It may be understood that all references above to content changes may also include format changes to the content.

[0123] Additionally, components that move or change their size due to dynamic layout may affect other components, for example, "pushing" them down or expanding them in the case of components that affect their containers. Such effects can be based on implicit (automatically generated) anchors or explicit anchors, as described in U.S. Patent No. 10,185,703.

[0124] It can be appreciated that anchors (as described in U.S. Pat. No. 10,185,703) can have multiple attributes such as docking / locking type (edge, corner, center), explicit / implicit nature, minimum or maximum size, one-way / two-way, one-way or two-way anchors, gating / breaking conditions, movement or resize effects, etc.

[0125] Furthermore, it can be appreciated that responsive design and dynamic layout are applicable both during editing and during run-time (as described herein above).

[0126] In a typical embodiment, dynamic layout deals with components pushing or resizing other components due to edits and content changes (typically down). Responsive design typically deals with layout changes due to width changes (including multiple configurations for different breakpoint ranges).

[0127] The DL Handler 31021 can make responsive editing and dynamic layout work in harmony and interact to prevent conflicts. For example, as the layout width changes, a component may become wider or narrower based on its anchoring to a containing component. As a text component narrows, the container text may be reformatted causing the text component to grow downwards. The component may then push the component below it down or stretch the containing container downwards. This can be based on explicit or implicit anchors as described in U.S. Pat. No. 10,185,703, or the use of editing elements such as stack elements or grids as described in more detail below.

[0128] We now refer back to Figures 7A-G to the effect of width changes on the site layout. Figure 7A shows several UI elements, including a resizable editing stage [A], width resize handles [B], a visual display of possible breakpoint ranges [C] (including an underline under the currently selected size (desktop mini icon)), and a customization dialog [D] showing a list of the current breakpoint ranges with an interface allowing the user to edit the breakpoints (and therefore the ranges).

[0129] The editing stage further includes a text paragraph component [E] and a container component [F] (a rectangle with rounded corners). Some of these marked elements appear in the additional views of Figures 7B-7G, and it can be understood that the same labels are associated.

[0130] It will be appreciated that the following discussion and Figures 7A-7G focus on a given set of components and containers and examples with the responsive design, fluidity, and dynamic layout capabilities of system 200 as described in conjunction with this limited set. However, system 200 can also implement the responsive design, fluidity, and dynamic layout capabilities for any hierarchy of components and containers and apply responsive design, fluidity, and dynamic layout throughout a containment hierarchy. Thus, for example, system 200 can apply layout changes at both the top level (e.g., when the entire page display viewport changes) and at inner containers (e.g., changing the layout of sub-elements depending on the width of a particular container).

[0131] As can be seen in [D] (FIG. 7A), the default settings range from 320 to 750 pixels for smartphone screens, 750 to 1000 pixels for tablet screens, and 1000 pixels or more for desktop screens. FIG. 7B illustrates the use of stacks (described in more detail below) to provide proper handling across breakpoint ranges. This is a mechanism that a user of the system 200 can use to create anchors between two components ([E] and [F]) to link them together and affect them. It can be seen that a stack container [G] can contain [E] and [F] and can also define spacing around them (e.g., around [F] in this scenario).

[0132] The DL handler 31021 may also implement other types of dynamic layout anchors (as described in U.S. Patent No. 10,185,703), including explicit / implicit anchors and anchors to enclosing containers, as well as between objects within the same container hierarchy level. Alternative embodiments of the system 200 may further implement cross-container anchors, e.g., anchors between components in different containers that allow for maintaining a similar ordering of elements between the two containers.

[0133] 7C-7E, the effect of width changes on a site is shown. A WYSIWYG edit display is shown with changes made using the width change handles [B] detailed above. The response editor 310 can provide multiple methods for width changes during editing, allowing the designer to view the layout under different widths. For example, the response editor 310 can allow discrete breakpoint width values ​​to be selected (using the Desktop / Tablet / Mobile menu [C] of FIG. 7A modified for the current breakpoint set). The response editor 310 can also allow continuous changes using the width change handles [B].

[0134] The response editor 310 may also allow a user to specify one or more width animations associated with a given command (a visual button, a keyboard shortcut, a mouse event, or other system input). Such width animations allow a user to view a site under a particular set or range of widths without having to repeatedly and manually exceed multiple widths.

[0135] Refer now to FIG. 7C, which shows a page that is approximately 1600 pixels wide.

[0136] Now refer to Figure 7D, which shows a page that is approximately 1100 pixels wide. At this width, it can be seen that the text font size of the text [E] has been reduced and has been reflowed (i.e., moving words to the next line). The container [F] has been squashed (so that it is now roughly circular compared to Figure 7C).

[0137] Figure 7E shows a page that is approximately 800 pixels wide. Note that the breakpoint indicator [C] indicates that the page is in "tablet" mode.

[0138] As discussed herein above, the previewer 3105 may allow a user to preview a particular component (including containers and component sets) within various breakpoint ranges. As shown in FIG. 7G, the previewer 3105 can display a preview [A] of the currently selected text component [B] and its immediate container [C] at all breakpoints. The preview may also include multiple states, including dynamic states (such as when the mouse hovers over the component).

[0139] 7F, there is shown a mechanism by which a text element may be defined to have a range of point sizes, rather than a single point size (as is the case with the [H] "scale text" button and the two text point size boxes). In this scenario, the text scaler 31023 can scale the text point size between a minimum and maximum value based on the viewport or text field width.

[0140] The text scaler 31023 may use continuous linear scaling (e.g., using fine-grained linear interpolation of font sizes within a given range based on the width value and its width range). Such fine-grained interpolation may vary point sizes by any smallest unit, e.g., tenths of a point. The text scaler 31023 may also use non-continuous linear scaling (i.e., limiting font size changes to a given "step", or limiting font sizes to a given set of values).

[0141] The CSS generator 320 can implement such dynamic font scaling directly with the generated CSS using a CSS definition such as the following: calc([min font size]+([max font size]-[min font size])*((100vw - [min viewport width]) / ([max viewport width]-[min viewport width]))

[0142] Rather than always using linear scaling, the text scaler 31023 can also perform smart scaling that combines text resizing and reflow to strike the best balance between the two. This typically involves analyzing the changes that result from changing the width of a component and making small variations from linear interpolation to get the best visual result.

[0143] Reference is now made to Figures 9A-9E, which show a similar configuration where the text is not scalable and therefore requires (comparatively) more space in a narrower configuration: Figure 9A shows that a single point size has been selected (in this case 28 points, as shown in the Text Scale / Point Selection UI [H]).

[0144] As can be seen in Figures 9B (~1260 pixels wide), 9C (~750 pixels wide) and 9D (~360 pixels), as the screen (and therefore the layout) becomes narrower, the text reflows and therefore becomes taller. The text then pushes down on the container [F].

[0145] As described above, the edit handler 3102 can define changes to the layout (and generally the page) based on changes in display width (or other affecting variables). As described herein above, sub-elements of the edit handler 3102 can employ rule-based functionality in conjunction with the rules engine 340. Such rules can include instructions for functionality such as auto-docking, site transformation, dragging and resizing elements, managing grids (adding, removing rows and columns, etc.), and changing the display of layouts and repeaters, as described in more detail below.

[0146] Thus, for example, in FIG. 9E (referenced herein), the rounded container and text are positioned side-by-side within the indicated breakpoint ranges, rather than one on top of the other as in FIG. 9D.

[0147] The edit handler 3102 can cause such (and other) changes when passing through breakpoints. These are discontinuous changes because changes within each breakpoint range must be continuous. As discussed further below, component positions and sizes can be defined using a variety of units, including absolute pixel sizes relative to the enclosing container (e.g., "size is 50% of the enclosing container size"), fractions (CSS "2fr" units), etc.

[0148] In a typical embodiment, the user can change the main parameters of the layout, i.e., component position and size between breakpoints (as shown in Figures 9B-9E). Thus, each page may contain multiple component layouts, one for each breakpoint range. It can be understood that each page may have multiple layouts (including layouts within a container component), but a particular (single) component may also have multiple configurations.

[0149] The layout handler 31022 may understand that it can understand the layout based on a mapping between a decomposition of the site (such as the groupings described above in this specification) and a classification of elements. The taxonomy provides its own hierarchy of site element concepts that may include "WBS World" concepts (e.g., picture + caption blocks) as well as "real world" concepts (e.g., "Our Products" page blocks or sections). Such taxonomies are described in more detail in U.S. Pat. No. 10,073,923.

[0150] Identification can be based on natural language processing (for the text contained in the component), information about previously labeled sites, computer vision and user feedback.

[0151] As long as the display widths are within the same breakpoint range, the layout handler 31022 can calculate the layout (position and size) according to a formula (which can still provide different results depending on the width parameters). This formula may be explicitly defined by the user or may be based on layout changes defined by the ML / AI engine 350, which may automatically generate alternative designs, as described in more detail herein below.

[0152] When a breakpoint is crossed, the layout handler 31022 switches to a new layout, possibly causing a non-sequential site change (i.e., a button jumping from one place to another).

[0153] Such changes can be made at the container level; for example, a container can be moved between different breakpoint ranges, while components inside the container can be understood to retain their positions and sizes for the different breakpoint ranges (relative to the container). In contrast, a container may also change its size between different breakpoint ranges, and components contained within that container may be affected (moved, resized, or changed as necessary).

[0154] The layout handler 31022 may also provide predefined arrangements of containers with different layouts for different breakpoint ranges (eg, side-by-side for desktop version and top-by-top for mobile version).

[0155] The edit handler 3102 can also allow additional component attributes and settings to be changed upon breakpoint crossing, such as component z-order, visibility (hidden / unhidden), and other attributes, as described in more detail below.

[0156] The visibility handler 31024 can manage the hiding and unhiding of components for specific breakpoint ranges. This may make it possible, for example, to use one method of site navigation for the desktop configuration (e.g., a side menu) and another method (e.g., a "hamburger" menu) for the mobile version.

[0157] Users can also define different layouts for different breakpoint ranges to "close gaps" for components that disappear within a given breakpoint range, or to "make space" for components that appear within a given range. Thus, user editing may be assisted by the create / close space functionality described herein in the context of component editing (which provides automatic repositioning of components as they are inserted or removed).

[0158] The visibility handler 31024 may provide the ability to do this automatically and dynamically using dynamic layout capabilities. This may be more applicable, for example, in the case of components that have variable sizes (e.g., due to different amounts of content determined during run-time). In this case, the visibility handler 31024 may, for example, consider the obscuring component to have been resized to zero (e.g., a zero-sized point or zero-width line) and apply dynamic layout processing to other components (in their new "shape") based on their anchors to the obscuring component.

[0159] The component handler 31025 may provide the ability to link multiple components together so that they share state or setting information. For example, if a user designs a responsive page for use on a tablet in both landscape (wide) and portrait (narrow) modes, and the landscape mode layout uses a side menu while the portrait mode layout uses a hamburger menu, the component handler 31025 may enable the user to link the two components together so that they share certain state information, such as beginner / expert menu complexity settings, the last option selected (if highlighted), etc.

[0160] Alternatively, the system 200 may provide similar functionality through a menu component that offers multiple variations, as described in more detail below.

[0161] It can be appreciated that the component handler 31025 can modify component attributes (including style information) based on parameters that affect responsiveness.

[0162] For example, the component handler 31025 can apply different colors to components in different breakpoint ranges. This may be needed, for example, when a component is relocated from a given breakpoint range into or near an area that has a different background color and a color change of the component is required.

[0163] Similar to the capabilities described for fonts above, the system 200 can also provide range definitions for some or all of the component attributes. Such range definitions can include minimum / maximum values ​​as well as associated interpolation formulas (e.g., the component handler 31025 can provide multiple such formulas, such as multiple color gradient methods, and the user can select which formula to use).

[0164] It will be appreciated that range changes per breakpoint can include changes related to component rotation and animation details, as well as other attributes.

[0165] Furthermore, it can be understood that a component remains a single component, and changes to the ranges per various breakpoints are essentially modifiers to the inherited version of the component in each breakpoint range. Thus, for example, if a component is deleted when editing a given breakpoint range (rather than simply hidden for this breakpoint range), it will be deleted for all breakpoint ranges (possibly triggering a change to the dynamic layout definition or a "close space" action as described herein). Similarly, if the actual content of a component is changed (such as when text is edited), the changed content is used for all breakpoint ranges.

[0166] Even though a component may be moved for a particular breakpoint range, an exemplary embodiment of the module 300 may require that the component stay under the same parent container (which may be a stack, layouter, or repeater cell). The component handler 31025 may prevent a component from moving from one container to another (known as "reparenting") at a particular breakpoint range. Note that this does not apply to grid "cells", which provide anchor support but do not form a set of containers per cell.

[0167] In alternative embodiments, the component handler 31025 may allow the user to waive this restriction and re-parent components between breakpoint ranges. However, this may have a significant cost (as it is more difficult to represent such structure and behavior in HTML and CSS). The component handler 31025 may implement this structure (for example) using multiple instances of the same component that are linked together (as described above in this specification) and that are hidden or visible depending on the breakpoint range in use.

[0168] It may be appreciated that some components may have multiple versions, variations, or configurations suitable for different sizes, resolutions, or aspect ratios, such as an image that may have multiple pre-rendered resolutions.

[0169] Also, a gallery can have multiple versions that can have different types (slider, matrix, horizontal flip gallery, vertical flip gallery, etc.) or different parameters (such as number of columns) depending on the assigned size and aspect ratio (for the gallery component). For example, a repeater component can change from a matrix gallery in a large screen desktop configuration to a slider in a mobile configuration.

[0170] You have a contact form that can be rendered as a button that opens a modal dialog (when resized below a certain limit), or alternatively, split into an initial and an extended section (that only opens when the end user presses the button).

[0171] A video player can also have multiple versions and can render different sets of control buttons depending on the available space (e.g. just play / stop, add skip to start / pause, add fast forward / rewind buttons, etc.).

[0172] It may be appreciated that a component definition may be discrete (i.e., selecting one of three available configurations) or may be based on one or more parameters (which may be discrete or continuous). For example, a matrix gallery repeater component may have different numbers of columns for different breakpoints.

[0173] The response editor 310 can support manual selection of which component configuration to use at each breakpoint range. Alternatively, the component definition can provide hints to the component handler 31025 on which component to select under different conditions. Thus, a component can provide its own breakpoints and rules, for example, use version A if a width between 100 and 300 pixels is available, and use version B if more than 300 pixels is available.

[0174] It can be appreciated that a typical page structure for use with the response editor 310 may consist of page sections, as well as header and footer regions. A page may contain multiple sections, each of which may contain components and containers, including supporting container types such as layouts, repeaters, and stacks. In a typical embodiment, the sections are arranged vertically, one above the other, and are coast-to-coast sections, i.e., occupying an entire horizontal strip of the page. Such sections may typically vary their width depending on the displayed viewport width. The response editor 310 may support additional layout elements, such as component rotation, animation, etc.

[0175] It can be seen that each of the primary support tools (such as a layouter, stack, repeater, or grid) can provide multiple sub-elements, including visual representation sub-elements that are displayed on the editing stage, editing support sub-elements that help the user use the tool (e.g., placing elements within a layouter), and implementation sub-elements that perform the actual layout calculations (along with other layout elements) to help generate the underlying CSS to implement the appropriate behavior at run time. This last sub-element supports the CSS generator 320 in its work.

[0176] The response editor 310 can also support the use of shared parts, components that can appear on some or all of the pages. A shared part displays the same content, which may still be parameterized per page (such as the page number in the page header) on all pages where it appears. In some embodiments, a shared part is also known as a master component or master block. The header and footer mentioned above are examples of such shared parts (as shared part containers that can contain other components).

[0177] It can be seen that components can move in and out of the shared portion (from the normal page area). The content of the shared portion can be shared in many ways, including multi-viewing, i.e. the same actual component is simply visible on multiple pages. Viewing changes on any page affect all other pages.

[0178] Content may also be shared through inheritance: pages inherit from a master copy. If the master copy is modified, these changes are reflected in all pages. If a specific page copy is modified, this is handled via a local modifier, which applies the changes only to this page.

[0179] Content can also be shared by copying it onto each page, with each page copy being separate and not connected to the main copy or to other pages.

[0180] The response editor 310 may require that sections be contiguous or allow for defining spaces between sections. Section heights may be determined in several ways, for example they may be fixed / predefined, may be set to the full height of the viewport used to display the site, or may be adapted to the largest contained object.

[0181] A component typically resides entirely within a single section. However, the component handler 31025 can allow a component to extend (i.e., protrude) from a given section and intersect into one or more adjacent sections. In this scenario, however, the majority of the component's area will typically be within the section with which it is associated.

[0182] Containers and other components may be defined as having a fixed size, stretchable, or relative to screen size, which can apply to various specific container types (sections, stacks, layouts, repeaters, etc.) described later in this specification.

[0183] Reference is now made to Figures 10A and 10B, which illustrate the use of section and component selection for breadcrumb display. Figure 10A shows such a structure with a page containing two sections. The response editor 310 may provide section handling and navigation tools [A] that allow sections (and other elements) to be selected, moved, removed, etc.

[0184] To aid in the selection of deeply embedded components, the response editor 310 can also use a breadcrumb path display [B]. When a component (which may be a container) is selected, a path display is displayed showing the path through the components from the top-level container to the selected component (as in example display [B], the path of the selected inner text is displayed as "Section>Container>Container>Text").

[0185] FIG. 10B (to which reference is now made) further illustrates a page structure that shows the separation between sections and the options available for manipulating the sections, since sections can be hidden for a given breakpoint (for example).

[0186] Additional options for section handling and page object selection, such as those described in U.S. Pat. No. 10,146,419, issued December 4, 2018, entitled "Method and System For Section-Based Editing of a Website Page," and U.S. Patent Application Publication No. 2019 / 0243882, published August 8, 2019, entitled "System and Method For Handling Objects in Visual Editing Systems," are commonly owned by the applicant and are incorporated herein by reference.

[0187] It may be appreciated that components are typically added by drag and drop from a menu of a set of available objects (component types) known as add panels. Add panels may include atomic components, containers, design elements (such as layouters and repeaters), and pre-built sections. Add panels may also include WBS services, and verticals such as blogs, stores, and bookings. Reference is now made to Figures 11A-C, which show such menus. Add panels and figures are described in more detail below.

[0188] The response editor 310 may allow components to overlap one another geometrically and be positioned in any position (via drag-and-drop or resizing). The component handler 31025 may further implement z-ordering or layering capabilities to handle such overlapping objects. Alternatively, the component handler 31025 may provide mechanisms for making space for inserted components, as described in more detail below.

[0189] Thus, the response editor 310 can provide a "create / close space" capability (in parallel with precise user-defined placement) during the insertion, deletion, or drag-and-drop of components. Thus, when a component is dropped into a given location (possibly overlapping one other component), the response editor 310 can resize or move some or all of these components to make room for the dropped component. Similarly, when a component is dragged out of the component placement, the response editor 310 can resize or move the remaining components to close the void that was created. The response editor 310 can handle the insertion and deletion of components in a similar manner (i.e., deletion as in drag source, insertion as in drag destination).

[0190] It can be appreciated that the drag source and drop destination locations may be within a container, for example a stack container having a vertical column of components. Reference is now made to Figure 12, which illustrates how when container A is dragged down (scenario I), container B is moved up in place of A and the two switch locations (scenario II).

[0191] The act of creating / closing such spaces may depend on a particular user action (e.g., using a controlled drag instead of a normal mouse drag) or on the use of particular handles or similar mechanisms as described in U.S. Pat. No. 10,185,703, entitled “Web Site Design System Integrating Dynamic Layout and Dynamic Content,” issued on Jan. 22, 2019, which is co-owned by the applicant and incorporated herein by reference.

[0192] Alternatively, it may depend on the type of container in which the drag source or drop destination occurs. For example, the component handler 31025 may apply the create space / close behavior to a particular container type (e.g., a stack container, described below), or to any container marked with a particular attribute or setting. In such a scenario, the create space / close behavior may differ between the source and target containers (e.g., close the space in the source container, but allow for an overlapping drop placement in the target container without creating space in the target container).

[0193] It can be appreciated that the ability to "make space" can be based on an analysis of the user's design intent, for example, using information from existing anchor types and directions to determine the best way to modify each adjacent component. The component handler 31025 can also use previous user activity and editing history, the layout of other areas within this website, and other information available within the system, such as described in more detail below in connection with the ML / AI engine 350.

[0194] It can be appreciated that the responsive editor 310 can support editing of a site across multiple breakpoints and provide multiple mechanisms for unifying the design and layout across a set of breakpoint ranges while optimizing the design for each breakpoint range. It can be appreciated that these goals can often be contradictory.

[0195] Reference is now made to Figures 13A and 13B, which show interfaces for design unification across multiple breakpoint ranges. Figure 13A shows an interface that may allow a user to copy the settings and design of a component in a given breakpoint range from that of the same component in another breakpoint range ("Pull Design" UI [A] - "Copy From Breakpoint" in the figure). A similar option (shown in Figure 13B) allows a user to copy the settings and design of a component in a current breakpoint range to other breakpoint ranges ("Push Design") as represented by "Make Everyone Like Me" in UI [B] in the figure.

[0196] Embodiments of the response editor 310 may also enable such copying to be done from instances of the same or similar component types in other pages on the same site or another site. This may be accomplished using clustering algorithms and selection of representative settings and design values, as described in U.S. Patent No. 10,459,699, entitled "System and Method for the Generation of an Adaptive User Interface in a Website Building System," issued on October 29, 2019, which is commonly owned by the applicant and incorporated herein by reference.

[0197] The animator 31027 can provide animation for user selection of a component for a given range of widths or for a particular breakpoint. The animation 31027 can reveal the full page, a particular page section, a particular container, or a particular component. Different versions of the page (with different widths) may take into account unselected components. Unselected components may be grayed out or hidden completely. This can be done to provide an intuitive view of what changes have occurred to a particular component or set of components between breakpoints. Unselected components are removed to simplify the reveal animation.

[0198] The response editor 310 may allow such animations to be viewed or exported interactively, and may allow them to be paused (reverting to a version of the site preview with the given greying / hiding applied).

[0199] The response editor 310 may also provide several tools to simplify object docking and anchoring during editing, as well as for positioning components within a layout.

[0200] The component docker 3128 can support automatic docking, showing the best way to dock components and enforce distance for each possible docking option. The docker 3128 can then suggest and apply possible dockings. For example, the docker 3128 can detect when a component is placed close to a corner of its container that is much closer than any other object in that container, and recommend docking to the two closest edges of that particular corner.

[0201] The response editor 310 can allow components, containers, and presets to specify their private docking parameters. Thus, a given preset can have, for example, a special grid arrangement that does not fit into the regular matrix format.

[0202] The ML / AI engine 350 can parse the absolute (WYSIWYG) layout definition during editing and saving (or other site operations), detect the user's intent, and translate it into a declarative set of rules that implement this intent, as described in more detail below.

[0203] As mentioned above, elements are typically added to a page via an add panel interface (in addition to moving, copying, and duplicating components).

[0204] Reference is now made to Figures 11A-C, which show how the Add Panel includes layout support elements (marked A in Figure 11A), regular components and containers (marked B in Figure 11B), and fully defined sections (marked C in Figure 11C). Such predefined sections are also known as presets.

[0205] The commonly provided elements (such as containers, components, and some section types) can be understood to be in the "WBS world" because they are abstract and relate to the world of components, layouts, and pages. The system 200 can also provide sections that correspond to the "real world," i.e., sections of human discourse that have meaning outside of the website (such as business terms). As can be seen in FIG. 11C, the response editor 310 can provide elements (preset C) such as About screen, Services list, Products list, Portfolio, etc.

[0206] The number of such possible sections and components is so large that the response editor 310 can provide customized and personalized add-on panels that can be established based on information available to the user, such as based on user input funnels, user attributes (such as business type), site attributes, current site structure, past actions, and design preferences, as described in more detail below.

[0207] The response editor 310 can support multiple situations where an object with a given source breakpoint setting (e.g., with three breakpoint ranges) is inserted into a page with different target breakpoint settings (e.g., with four breakpoints with different values). The component handler 31025 may match the inserted object to the breakpoints defined for the target page.

[0208] This can happen in several scenarios, such as when copying or moving a section (or another component) between pages (assuming the pages have different breakpoint definitions). This can be within a site (where different breakpoints per page are allowed) or across different sites.

[0209] It can also occur when including elements or sections (through references, inheritance, or other mechanisms) from another site or another layout authoring environment (e.g. another editor employed by the WBS), or when the user selects a preset (or another component) for inclusion on the page and the object inserted on the page has associated breakpoint ranges.

[0210] It can also occur in shared parts (shared areas such as a page header) when ripping a shared part back into normal page area, or when moving an element from a page into a shared part.

[0211] Refer now to Figure 14, which shows a stack. A stack [A] is a container that contains a vertical set of contained components (which can be other containers, stacks, or other elements) that push one above the other. The stack definition includes a gap [B] between the contained components. A stack maintains the void between its contained components, preventing them from overlapping. Similar components may provide a horizontal push instead of a vertical one.

[0212] It can be appreciated that stacks can allow drag and drop for placement of contained components as well as reordering of contained components during editing, which is done using create / close spaces as described above in this specification.

[0213] Similar to the layouters described herein, the layout handler 31022 may convert the stack into a different display format (eg, a slider or slideshow) if it is overfilled.

[0214] The system 200 may implement such stack elements using the HTML FlexBox element.

[0215] A layouter can be understood to be a container that provides a layout for a set of subcontainers. This provides an easy way to design containers that contain arrangements, lists or other repeaters. Layouters provide an easy way to define a set of subcontainers that will be rearranged upon width change, including both user-defined and system-determined rearrangements.

[0216] A layouter can support a variety of immediate siblings (i.e. directly contained elements), but in one embodiment may require that all immediate siblings be containers, or even containers of a particular type.

[0217] A layouter can provide multiple alignment options that determine where an item will be placed inside its row / column, inside the layouter container itself, and when there is space available (left / right / center / spacing, etc.).

[0218] Reference is now made to Figures 15A and 15B, which show layouter components and layouter configurations. Figure 15A shows a layouter [A] that contains five sub-containers (a-e), which themselves contain additional content (one or two buttons or hamburger icons in each of the five sub-containers). The sub-containers are stretchable and can be resized and moved.

[0219] It can be seen that layouters can behave like normal containers in the sense that sub-containers can be moved out of the layouter and outer containers can be moved into the layouter.

[0220] The layouter can allow the user to perform actions such as reordering while editing (with or without "create / close space" functionality), adding containers on the fly, adding containers from outside, removing containers from outside, and modifying the layout.

[0221] Of course, a layouter can support multiple types of arrangements (such as the "Display type" [B] in Figure 15A), including static arrangements (such as the Row, Column, and Rows arrangement in [B]) and dynamic arrangements (such as the Slider arrangement in [B]). This can include other types of galleries where only some of the subcontainers are visible at any one time, allowing the user (as well as the site viewer) to navigate to different portions of the underlying gallery.

[0222] As described herein above, many more arrangements are available, and the layout handler 31022 can further automatically switch a given layouter to a different arrangement if the space is filled (e.g., due to content stretching). Additional arrangements include cards, slideshows, sliders, lists, and columns, and the layouter can apply any of them without further editing by the user.

[0223] Layout[A] in Figure 15A uses a "Rows" arrangement. In contrast, the same layout[A] in Figure 15B uses a "Column" arrangement as shown.

[0224] It can be seen that the user can switch between various arrangements and the layouter can rearrange the subcontainers (with their contents) within the layouter according to the desired arrangement. The user can provide additional parameters for the arrangement (such as Margin [C] and Primary Directionality (L2R / R2L) [D] in FIG. 15A).

[0225] The layouter can also save a layout context for each of its possible arrangements: as the user may have modified each arrangement (e.g., changed the position, size, and order of a given arrangement), the layouter can save these modifications so that it can reapply them when returning to this arrangement.

[0226] Thus, the user can apply per-breakpoint range modifications, including using different alignments for per-breakpoint ranges, and making other modifications to subcontainers and their contents.

[0227] It can be seen that the user can move objects in and out of sub-containers of the layouter. When an object is dropped into the layouter such that the object crosses multiple sub-containers, the layouter can choose which sub-container to use.

[0228] Such a selection can be based on a number of parameters, such as the cursor position, the subcontainer with the largest overlap area, the largest combined vertical and horizontal overlap, or other criteria. The layouter can also assist the user during dragging by highlighting the subcontainer that will "receive" the dropped object (called a "hot zone").

[0229] If the layouter requires all immediate siblings to be containers (as described above), the layouter will automatically create a wrapping container around the dropped object.

[0230] Of course, the layouter together with the ML / AI engine 350 may suggest better design options, including recommended placement choices and various modifications within the same placement. These may be generalized suggestions or suggestions within the context of a particular breakpoint range. A generalized suggestion is one of a menu of generalized layout types (described in more detail below). A specific suggestion is a set of layout suggestions based specifically on the layouter's current contents, similar to the layout suggestions described in U.S. Patent No. 9,747,258, entitled "System and Method for the Creation and Use of Visually-Diverse High-Quality Dynamic Layouts," issued on August 29, 2017, which is co-owned by the applicant and incorporated herein by reference.

[0231] A layouter may be fixed, i.e., when the layouter's width changes, its subcontainers remain in the same arrangement (but they can resize or push each other for dynamic layouts). The only movement that occurs between breakpoint ranges is due to explicit edits by the user.

[0232] Alternatively, a layouter may be transformative, with its subcontainers moving in specific ways under certain conditions. One simple example is a row layouter (elements side by side) that is automatically transformed into a column layouter (elements on top of one another) when the available width falls below a certain value. More complex transformations can be specified (e.g., similar to the reflow of words within a paragraph when the width of a word processor changes). The system 200 can provide such transformation layouts and can enable users to design their own transformation layouts.

[0233] The response editor 310 can also support additional conversion capabilities as described above in this specification (with respect to layout changes under different widths). The response editor 310 can also support algorithm-based conversions using techniques such as those used to rearrange components for mobile displays, as described in U.S. Patent No. 10,176,154, entitled "System and Method for Automated Conversion of Interactive Sites and Applications To Support Mobile and Other Display Environments," granted on January 8, 2019, and commonly owned application Ser. No. 16 / 878,831, which is incorporated herein by reference.

[0234] Reference is now made to Figures 16A-16C, which illustrate the use of Repeaters. Repeaters are similar to layouts, except that subcontainers (also known as items) are multiple instances of a single subcontainer or set of subcontainers. Thus, changes applied to one subcontainer (e.g., inserting a new component) can be applied to all subcontainers and will appear in all subcontainers. Figure 16A illustrates several options [A] for Repeater display.

[0235] However, components inside a Repeater may still have specific data (e.g., text or image sources) that differ between pages. Such data can be managed manually by the user or by associating the Repeater with a data source (in-memory table, database, external CMS, etc.). The user can manage the data through an interface provided by the underlying database or CMS 50.

[0236] Repeaters can use items that are separate from the displayed data - for example, a Repeater could display a set of four boxes that form a "window" into a series of data elements (showing elements 1 / 2 / 3 / 4, 2 / 3 / 4 / 5, etc.).

[0237] The Repeater provides a "Manage Items" user interface [B] (as shown in FIG. 16B, referenced herein) to manage items, for example selecting how they are displayed and arranged, maximum number per row, and other attributes of the display.

[0238] 16C, referenced herein, when items are added to the repeater (e.g., by duplicating item1 and its duplicates), the module 300 can expand the repeater and create additional rows of subcontainers. The layout handler 31022 can perform other types of rearrangements (as described for layouts above), such as converting a grid display into a slider.

[0239] As described herein above, the responsive edit grid is a grid layout mechanism that can be applied to most containers to help align the components contained within the containers, and thus the responsive edit grid is visible to users who explicitly use it to position components.

[0240] It can be seen that the response editor 310 allows the user to manually apply a response edit grid to sections and all regular container types (but not to layouts and repeaters, which have their own layout mechanisms). Reference is now made to Figures 17A-17D, which show the implementation and processing of a response edit grid within a container. A sample 3x3 grid [A] (as it would be applied to a regular container) is shown in Figure 17A.

[0241] 17B and 17C, referenced herein, a user can specify parameters of the grid such as the number of rows and columns, the units of measure and size of the rows / columns, the horizontal and vertical gaps, etc. The rows and columns can be fixed size or flexible. The grid can also be further edited or removed with editing operations including stretching, swapping grid lines or columns, etc.

[0242] It can be seen that a grid provides horizontal and / or vertical lines that can be used for docking sub-elements of the container (to which the grid is applied). Docking can also use negative margins, so that an element is anchored to a given grid cell edge, but actually crosses that edge in such a way that it is partially outside the grid cell (or the entire grid).

[0243] It can be appreciated that grid cells are not separate sub-containers, and therefore components can be moved between them for different breakpoint ranges.

[0244] The grid handler 31029 can match between the size of the container and the parameters of the grid, and can modify line parameters as needed (even when working in non-% units). For example, grid lines with "auto" can stretch when dropping a large element (such as text). For example, compare R1 of the first row of the grid between Figure 17A (before dropping a text object) and Figure 17D (after dropping the text "Big Title").

[0245] It may be appreciated that the system 200 may support a variety of measurement units, such as pixels, %, fr (size fraction), vh / vw (based on the size of the viewport), em, rem, calculation-based, etc.

[0246] Fraction units make it possible to specify (for example) two columns with sizes 1fr and 2fr, where the first column uses 1 / 3 of the width and the second column uses 2 / 3 of the width.

[0247] The grid handler 31029 can manage the grid size and units of measurement so that changes according to the units used and changes of components in the enclosing container are automatically handled. Thus, when applying a grid to a container, the grid handler 31029 can maintain the existing design and recalculate it into a new grid including unit changes. The user does not need to worry about units and sizes. The grid handler 31029, together with the layout handler 31022, can further update the container size to fit the grid size and keep the grid in place.

[0248] It can be appreciated that image components and images used as backgrounds (relative to other components) often go through substantial processing before being displayed. In particular, a user may typically want to crop an image so that its most relevant portion is shown. The defined cropping defines (among other things) the default size and aspect ratio of the image. The response editor 310 can also support non-rectangular cropping through the use of shape masks.

[0249] Users may also want to specify a point of interest (focal point) in an image, which is required for some image display components (such as some galleries) to determine image display based on the focal point rather than a user-defined crop region.

[0250] Reference is now made to FIG. 18, which illustrates an image that has been cropped (using visual cropping) to act as the background for a given container and grid.

[0251] It can be seen that the system 200 can allow image attributes to be defined for each breakpoint range. Thus, a user can embed a single copy of an image on their site, but define different crops (and resulting aspect ratios) and different focal points for each breakpoint range. Thus, a page has a single image component, but multiple generated outputs from this single component.

[0252] The image handler 31032 can integrate this capability with other modifications made by the response editor 310 since (for example) the image has already been adjusted (e.g., scaled) to fit different breakpoint ranges. The image handler 31032 can also handle other image modifications such as zoom, focus, and color processing.

[0253] The above discussion has focused on building applications that display their output and handle their interactions on a single screen, and it will be understood that the single screen may be anything from very small (e.g., a smartwatch display) to very large (e.g., a billboard display).

[0254] In different embodiments, system 200 can support the design of applications that are split across multiple screens (that do not necessarily form a continuous "display surface") This can occur in a number of cases, for example, in a very large physical screen that is accessed as multiple screens (e.g., due to display management limitations), in a multi-monitor system, in a system with a primary display and an auxiliary display (e.g., a smart phone that runs some of the applications as a "virtual remote control" for the system), or in a system with actual multiple separate monitors on which the application runs.

[0255] In this scenario, an application may be partitioned for display on multiple displays (e.g., a main display and a remote control display). Each partition has its own set of breakpoints and can be adapted independently to different display sizes. Furthermore, the breakpoint model may be extended to support multiple screens with different widths, e.g., one layout definition for a single screen (with subdivision into different breakpoint ranges), one layout definition for two screens, etc.

[0256] Different monitors may be connected to a single system 200 or multiple systems 200. These multiple systems may coordinate among themselves when running an application. Additionally, the display / monitor configuration may change during application operation (e.g., when auxiliary displays, such as those described above, are engaged or disengaged from the system).

[0257] Thus, system 200 can also provide responsive design, fluidity, and dynamic layout editing and display capabilities adapted to such environments, allowing an application to be designed once and run (for example) on systems having different numbers of monitors.

[0258] As discussed above, the ML / AI engine 350 can be utilized to achieve the goals of the system 200, as discussed in more detail below. The ML / AI engine 350 can use information available in the WBS2, as well as WBS-based training feedback, as described in U.S. patent application Ser. No. 16 / 878,831, and can utilize several machine learning models or combinations thereof, as described in more detail herein below.

[0259] As described above in this specification (and as shown in FIG. 11C, to which reference is now made again), the system 200 can provide sections and components that correspond to the “real world” of human discourse having meaning (e.g., business terms) outside of a website.

[0260] Since the number of such possible sections and components is very large, the response editor 310 can provide customized and personalized add panel sections. The add panel handler 31030 can dynamically update the add panel with component selections and presets that the user is most likely to use or add, and can further recommend them to the user. Since the add panel is customized not only per user, but also per site and per additional information, the same user may see different add panels on different sites and in different contexts.

[0261] It can be appreciated that this customization can be determined by using an ML / AI engine 350 that can apply ML / AI techniques to learn user usage patterns when building the site. The ML / AI engine 350 can continuously learn from new sequential steps that lead to the creation of elements on the site, including pages, sections, containers, and components.

[0262] Additionally, it can be appreciated that this functionality can be combined with contextual data based on the site's palette, the layout the user has created, the parts built into the page, along with the page within the site, whether it is a home page or a page with a specific intent. This determines recommendations that best fit the user's design and intent. The ML / AI engine 350 can also use models to optimize results by the level of proficiency the user holds, the business goals of the site, and the user's own and other similar users' past behavior.

[0263] Contextual information can also include additional information available to the user and on the site, such as information based on the user input funnel (e.g., questions answered by the user at the time of input), user attributes (such as type of business and industry), user preferences (such as saved designs, saved presets, likes, dislikes, collections, etc.), and site attributes (e.g., which add-ons the user has installed and which add-ons are active).

[0264] The context information may further include the current site structure, past actions, user design preferences, and the current editing state (selected components, open floating dialogs, etc.) It may be understood that all information, including editing history and business intelligence, may be available from different repositories of the CMS 50 described herein above.

[0265] The system 200 can also recommend specific add-on purchases (third party applications, WBS configurable applications, vertical and other add-ons), as well as specific content, media, presets and other elements based on such analysis.

[0266] The next move suggester 31041 can use the ML / AI engine 350, and in particular models that are generative in nature, based on what the user has done so far, to suggest to the user what to do next. Actions can be component suggestions ("here's the time to place the third button") and placement suggestions ("this is the best place for the next image"), editing changes ("wrap these three components better in a stack"), or other WBS action suggestions. Thus, the next move suggester 31041 can act as a recommender or as an editing assistant (e.g., a "do it for me" assistant) and interface with the user via the explainer and suggester 3104.

[0267] The next move suggester 31041 can provide the user with multiple alternatives (either upon selection or via a "suggest something else" option through the explainer and suggester 3104), and can also provide different configurations for an existing component.

[0268] Reference is now made to Figures 19A and 19B, which show scenes with scenario recommendations. Figure 19A shows a case where the text box [A] is narrowed and the text "HUGE TITLE" that overlaps with the button [B] below it is split into two lines. In such a case, the next move suggester 31041 (using the ML / AI engine 350) can suggest to the user to surround the two fields (the text field [A] and the button [B]) with a stack container [C], as shown in Figure 19B.

[0269] The next move suggester 31041 can do this as a suggestion to the user, or can directly implement a suggestion and request confirmation from the user. This could be as simple as allowing the user to undo the suggested changes using a normal "undo" function. Such feedback can be fed directly into the next move suggester model used by the ML / AI engine 350 as additional training material.

[0270] It should be appreciated that the next move suggester model can make its predictions based on an analysis of multiple sources of information, such as an analysis of the user's actions and editing history, the environment, the context (as described above in this specification), the desired objectives, the component the user is attempting to place, and other available information.

[0271] In particular, the next move suggester model may be trained using actions performed by the current user and other users on similar sites or with similar edit sequences (e.g., using the same underlying template family or other criteria).

[0272] The next move suggester 31041 can further use segmentation analysis (eg, based on users and sites) to detect related user clusters (eg, users with similar site editing characteristics).

[0273] Next Move Suggestor 31041 also functions as a "design center", performing a general review of a site design and predicting the best layout elements to use for this design (suggesting or auto-creating them).

[0274] For both "Next Move" and "Design Center" modes, the next move suggester 31041 can recommend (or auto-apply / create) additional layout and formatting elements that are not regular components, such as stacks, auto-docking (including recalculate grid area per element, per layout, per breakpoint), adding grid lines, flexbox (added as a standalone element or as part of a stack), and pinned elements.

[0275] Additionally, it may be possible to achieve similar visual results (for a particular desired outcome) using different techniques or combination sets of techniques than those described above. The next move suggester 31041 may consider multiple ways of performing a given task ("next task" or otherwise) taking into account the quality of the generated layout / page (after modifications). This may include the quality of different variants of the layout across all breakpoint ranges (including uniformity between various breakpoint ranges).

[0276] Also, different designs may differ in their performance and efficiency, so performance and efficiency may be taken into consideration. For example, the system 200 typically maximizes the use of declarative CSS, which runs directly in the browser's rendering engine (which is faster and more efficient than JavaScript code execution). Thus, the next move suggester 31041 may select a solution that optimizes CSS usage as part of ranking possible solutions.

[0277] Thus, the next move suggester 31041 may provide (recommend or auto-execute) a single follow-up action, a set of follow-up actions, or a searched or generated description of what to do next (which may be via text, video, a game or game setting, animation, a simulation of the proposed action outcome, or audio description). It may also provide any combination of such actions or descriptions, or provide feedback to the user via other means.

[0278] The process described above in this specification is based on the user creating an initial layout (typically the broadest configuration, e.g., a desktop configuration) and then manually adjusting the layout and components for various narrower configurations for different breakpoint ranges.

[0279] In an alternative embodiment, the response editor 310 can support the user in the process of designing a desktop version (for example) and the next move suggester 31041 will suggest or rearrange the layout to other breakpoint ranges on its own.

[0280] This can be done using a rules engine 340 (such as that described in U.S. Pat. No. 10,176,154) or using machine learning based models via ML / AI engine 350 (trained using rules based systems, explicitly generated data, and user feedback, as described in more detail below). The next move suggester 31041 can also be trained generally based on the collected edit history of multiple users of the responsive editor, i.e., how the users fit a given layout into a given breakpoint range.

[0281] It may be appreciated that site adaptation to multiple breakpoint ranges may include replacing some components with fluid versions of those components (including the transfer of contained data and settings from regular to fluid components).

[0282] Furthermore, it can be appreciated that layout understanding and component grouping are fundamental building blocks of system 200, as they are used in multiple tasks related to site analysis and site transformation (e.g., responding to static and navigating static).

[0283] The component grouper 31031 can convert a site description (e.g., in a data description language such as XML or JSON) into a hierarchical set of group definitions. It can be appreciated that the component grouper 31031 can utilize a component grouping model such as that described in patent application Ser. No. 16 / 878,831.

[0284] A component grouping model can typically use one or more base models as shown in FIG. 20A, including RNN-based, computer vision-based, triplet-based, and a combination of triplets and computer vision. The ML / AI engine 350 can combine multiple such models and rank them according to multiple criteria (including manual grouping analysis, consistency, and comparison with known ground truth results from user feedback) to determine the best one to use for a given population or category of sites on which it operates. FIG. 20B, referenced here, shows an example of the results of a model (II) on manually labeled pages (I), ground truth information.

[0285] This information may be used directly by the layout handler 31022 as well as by WBS World elements of the system (eg, layout proposals).

[0286] It may further be appreciated that elements of the system 200 require the ability to evaluate pages, page subsets (sections and other element collections), and layouts based on their quality. The layout quality evaluation may be used by multiple elements of the system 200, such as the next move suggester 31041.

[0287] Of course, many techniques are known in the art for quality assessment, such as those described in the description of the layout quality evaluator 47 as described in U.S. Pat. No. 9,747,258. The ML / AI engine 350 may use ML techniques and feedback to train a model to provide a quality assessment. It may be appreciated that layout quality may be a matter of personal taste and preference. Thus, one embodiment of the system 200 may combine results from a generic model (trained for all users) with a model trained for a particular user.

[0288] Once the editing process is complete, the response editor 310 may save any changes in the CMS 50 .

[0289] As described herein above, the response editing module 300 provides full WYSIWYG editing, and the previewer 3105 provides the ability to continuously preview the site for any width, as referenced back to Figures 7A-7F. It can be appreciated that the response editor 310 may also provide a general preview for the entire page during the editing process. Thus, the previewer 3105 can enable a user to simultaneously preview particular components (and containers) at various breakpoints, as referenced back to Figure 7G.

[0290] It can be appreciated that editing complex hierarchical structures with multi-level constraints involves many cases where different constraints conflict with each other and must be resolved. Thus, the docking constraints of two different components may conflict to some extent. Similarly, the constraints of a container may conflict with the constraints of a component contained in the container.

[0291] Additionally, system 200 uses an ML / AI engine 350 (e.g., described in more detail below), whose actions and recommendations are somewhat opaque and not directly based on a set of predefined rules.

[0292] Thus, the explainer and suggester 3104 can provide the user with an explanation (similar to online help) for why the system 200 provides a given action or gives a particular recommendation. Such modules can be based on techniques from the field of explainable artificial intelligence.

[0293] As described herein above, the CSS generator 320 can map responsive, fluid, and dynamic layout design characteristics to declarative CSS and minimize the use of JavaScript code, resulting in performance and interaction benefits as much of the dynamic and responsive functionality of the site is performed directly by the browser rendering engine via the declarative CSS code.

[0294] By using the CSS generator 320, the use of JavaScript (JS) code is further minimized, resulting in better site load and interactivity values, since browsers typically load JS code at a later stage and may wait for the entire JS code to be loaded before starting JS execution.

[0295] Thus, the system 200 can, for example, implement stack objects using HTML Flex Boxes, implement grids using CSS Grid, or the like.

[0296] As described above in this specification, the system 200 can implement dynamic layouts and fluid components in a website page. The applicant has found that the functionality of the system 200 can also be applied to non-responsive sites by implementing fluid display (i.e., continuous layout changes for display viewport changes) and / or by adding layout variants for different breakpoint ranges to an existing (typically desktop) site layout. This can include converting an absolute layout to a stretchable layout. The generated stretchable layout may be stretchable in both dimensions. The following discussion focuses on changes in the horizontal axis. Thus, the system 200 can also modify the original site layout (e.g., adding responsive support elements such as stacks and layouts) and replace elements or components with their responsive or fluid counterparts.

[0297] Applicant has further discovered that this application can improve dynamic layout performance through the use of pre-processing that allows browser integration into the online dynamic layout process: rather than being implemented "on top" of the browser engine, the mesh applier 330 can transform the site into a representation that allows parts of the dynamic layout processing to occur inside the browser rendering engine (i.e., as part of the rendering and ongoing browser-user interaction).

[0298] As described herein above, layouts may incorporate fluid components whose size and attributes can be influenced by a parent (e.g., by a parent change or a viewport width change) or by various triggers. To implement functionality using breakpoint ranges, layout elements (components, z-order, anchors, etc.) are held in a smart mesh formation, a grid-like format where a cell (or merged cell) of the grid represents a component. The representation is created recursively at the container level, i.e., each container has its own mesh.

[0299] As described herein, when a page is sent to a browser (or rendered on a server, etc.), the smart mesh is converted into a specific format that may be rendered directly by the browser.

[0300] The following description focuses on an embodiment of the system that uses target forms based on CSS Grid features (as defined in the CSS Grid standard). This form is declarative in nature, allowing the browser to handle a significant portion of dynamic layout related interactions and processing without requiring higher level code (such as JS code). Other embodiments may be discussed in more detail later in this specification.

[0301] As described herein above, the system 200 can perform dynamic layout processing during editing (e.g., reflecting editing changes made by a user) as well as during run-time. The system 200 can use different mechanisms in either case as requirements may differ between the cases. A third usage scenario may be a preview or simulation mode, a run-time view of a web page functioning within an editing environment, which may behave differently than a normal run-time view.

[0302] As described herein above, dynamic layout includes moving and resizing components on a screen based on dynamic layout triggers. It can be understood that all references above to content changes can also include formatting changes to the content.

[0303] It can be understood that triggers (as described above in this specification) can be divided into multiple classes, such as browser engine handled (BEH) triggers, which may be handled internally by the browser (e.g., based on generated declarative definitions), JavaScript-handled (JSH) triggers, which may be handled by JS code associated with the page or components therein, and grid-regeneration based (GRB) triggers, which may require updating supporting grid structures, typically leading to a full or partial page re-rendering.

[0304] Classes may not be mutually exclusive: for example, some triggers may be handled differently depending on their exact parameters and the page change they represent.

[0305] Thus, the mesh applier 330 can provide a rendering platform for the system 200. It may require components to be adapted to it, and in particular the adapted components should not require JS to be executed before it is visible to the user (to improve the overall view time of the web page).

[0306] The system 200 can also support adapters for use with components not adapted for such a system. Such adapters can use a number of techniques to speed up page loading, such as hiding a component on the initial page view and only showing it when it is ready to be displayed (e.g., "below the fold" on a particular page).

[0307] Other adapters may include using a pre-loader display, using pre-generated screen captures of component displays that may be generated (for example) during publication, site activation, or based on predictions of user movement within the site, or using alternative (simplified, partial, or simulated) versions of the component as placeholders.

[0308] The mesh applier 330 can convert the page component structure into a mesh format that is implemented by the CSS generator 320 using the CSS grid definition on the initial runtime rendering. In this way, the browser implements the dynamic layout functions of the page at runtime in the browser's own rendering engine (based on the declarative CSS definition) instead of performing the dynamic layout functions using JS code executed in a JS engine.

[0309] It may be understood that the response editor 310 may also implement the same rendering framework provided by the mesh applier 330 (which may be applied to the displayed page stage as well as added editor UI). Alternatively, the response editor 310 may use a procedural absolute layout based framework for rendering. The response editor 310 may also combine the two. The previewer 3103 may typically use a mesh applier for rendering (e.g., to provide better performance as well as greater compatibility with the actual runtime behavior of the page). It may be understood that this runtime behavior may also be provided by the runtime server 20.

[0310] It may further be appreciated that the mesh applier 330 may pre-generate the CSS grid for the browser upon the first rendering of the page, be it client-side rendering, server-side rendering, or a combination thereof. As described above herein, this can be done recursively at the container level, such that each container can have its own grid definition.

[0311] Some components and containers may lend themselves to handling in other ways. For example, repeaters and other list-type components may be managed and rendered via a conversion to CSS flexbox (which may be better suited to handling one-dimensional collections such as lists compared to two-dimensional grids). Such alternative handling may be integrated into the mesh applier 30 or may run in parallel with it.

[0312] It can also be appreciated that a CSS Grid adapted page enables the browser to respond to and handle most (but perhaps not all) of the triggers listed above. (i.e., these are BEH triggers.) Thus, the browser can adapt the page as needed based on the declarative CSS Grid information without requiring grid modifications, page reloads, or re-renders. Such BEH triggers can include, for example, the following:

[0313] Changes that affect component content (including content, formatting, and other changes) from multiple sources, such as updates to database information, user edits to content, user interactions, and other sources.

[0314] Screen / window / viewport size changes (including related changes to view rotation).

[0315] Width changes across pre-defined breakpoint boundaries: Such changes may be supported through the use of CSS media queries and by including multiple layout options in the page / container definition (as widths match the available breakpoint ranges).

[0316] Changes caused by components pushing against other components.

[0317] It may be appreciated that other changes and triggers may require the grid to be modified / regenerated and the page to be re-rendered and / or reloaded. Such changes may include, for example, concurrent editing changes that involve changes in component positions or container-component parent relationships (e.g., moving a component from one container to another).

[0318] Note that the distinction between BEH, JSH and GRB triggers can be very fine: for example, a concurrent editing change that modifies a component's content can be handled without re-rendering, while a change to a component's position may require a re-render.

[0319] The system 200 may further implement incremental page updates and re-rendering, where only the portions of a page that have changed are updated and require re-rendering.

[0320] As mentioned above, the CSS generator 320 typically generates the CSS grid definition just prior to rendering (be it client or server-based rendering). In particular, the generated grid (and the component relationships and anchors it represents) can depend on the current contents of the fields (which can determine the size of a particular field), as well as the attributes of the current client device (and in particular the display width).

[0321] However, when receiving updates directly from the mesh applier 330 (referring back to FIG. 4), the CSS generator 320 can pre-generate multiple versions of the CSS grid pre-adapters for a particular platform / browser version combination and further adapt them (with updated values) just before rendering.

[0322] It can be appreciated that the described embodiment uses the CSS Grid standard. Alternative embodiments may be based on different web browser standards or capabilities, particularly those that provide declarative layout control in CSS.

[0323] It can be seen that using declarative CSS elements rather than JS elements for the majority of a page design improves performance as browsers typically load, render and display HTML and CSS before loading any JS code. Thus, in accordance with a preferred embodiment of the present invention, the loaded page is mostly interactive once the HTML and CSS are loaded, reducing the measurement of the "interaction time" of the page. This can be seen to be a measurement of the time it takes for the interactive, i.e., interactive elements (such as buttons) of the page to operate and perform their function. This is in contrast to the measurement of "view time", which measures how quickly the page begins to display even if no interaction is in place.

[0324] Furthermore, when working with the mesh applier 320, the CSS generator 320 can reuse grid styles in multiple places corresponding to component reuse. Thus, when the CSS generator 320 generates a grid representation of a given composite component, the definition can be sent only once and it can be automatically reused in multiple instances of the composite component. This applies, for example, to component groups / composite components (that are used repeatedly), as well as list-based components such as repeaters.

[0325] It may be appreciated that converting to CSS Grid may resolve issues related to bugs and inconsistencies in implementations between different implementations of CSS Grid (e.g., by generating a version adapted to the particular implementation used). The CSS generator 320 may further handle cases where the standard and correct behavior of CSS Grid (even when implemented correctly) does not provide adequate support for dynamic layout or does not properly implement a required anchor type, including adding relevant JS code to compensate for such issues or missing capabilities.

[0326] Based on the page analysis (described in more detail below), the mesh applier 330 may use an intermediate mesh format or internal data structure. This may involve converting the WBS component definitions and page data structures into a mesh format (mesh grid) or data structure and generating a CSS grid definition from this intermediate format / data structure. It may be understood that the smart mesh structure is actually used to declaratively define the site (with responsiveness and fluidity). The CSS generator 320 may also generate the CSS grid definition directly from the WBS page definition. The mesh applier 330 may further generate additional JS code required to implement the JSH triggers described herein above. The CSS generator 320 may adapt or adapt the mesh layout format to be a data storage format, i.e. "saved", i.e. as a deployment format, i.e. "published", or dynamically generated upon access, i.e. "load".

[0327] Also, in addition to the JSH triggers mentioned above, it can be understood that some functionality of the generated page has to be implemented in JS anyway - for example, getting a specific sized image for a specific modified layout requires JS to place a server call to get the image resized to the exact size from the server, which usually cannot be done with CSS.

[0328] Reference is now made to Figure 21 which illustrates the elements of the mesh applier 320. The mesh applier 320 may further comprise a page receiver 3301, a trigger handler 3302, a page analyzer 3303, and a page converter 3304.

[0329] The page receiver 3301 can receive an input page from the WBS editor 30 or can receive a site imported by WBS2 without a response flow component or defined breakpoints, and the trigger handler 3302 can recognize the type of input trigger class (BEH, JSH, GRB, as described above in this specification).

[0330] The page analyzer 3302 can analyze the received page to determine its composition and how best to handle it. Analysis can include breaking down the page hierarchy into elements, determining relationships between elements (such as docking elements in containers and creating implicit anchors where applicable), and, where related, grouping page elements into larger groups that should be processed and moved together whenever possible, such as identifying a text component and an image component as an "image+caption" pair.

[0331] The page analyzer 3302 can also perform a preliminary analysis of how to handle future triggers in all categories (BEH, JSH, and GRB triggers).

[0332] The page analyzer 3302 can take into account not only the basic geometric characteristics of the page and its components (size, position, overlap, proximity, layers, etc.), but also other WBS attributes and available information stored in the CMS 50 (edit history, extended WBS component attributes, etc.).

[0333] The page analyzer 3302 can use grouping analysis techniques such as those defined in the preprocessor 201 and supernode creator 230 of U.S. Patent No. 10,176,154. These elements may determine component connectivity (analysis of content, edit history, relationships of other components, etc.). This can be used, for example, to detect clusters of components that look better when they stay together.

[0334] The page analyzer 3302 can further support such page analysis and component group recognition using the ML / AI engine 350. It can be appreciated that page analysis may be performed recursively, i.e., at the page level, as well as for containers within the page.

[0335] It may further be appreciated that the analysis may be performed (fully or partially) at an earlier stage, e.g., during editing or publishing. Thus, the mesh applier 330 may detect component relationships (and generate implicit anchors) during editing or publishing, not just at the page serving stage. This allows the system 200 to provide information about inferred (implicit) anchors to the user during editing, and the user may edit or otherwise provide feedback, instructions and hints for the creation or attributes of such anchors. Such feedback may be used, for example, to modify the implicit anchor definitions or to provide feedback for the ML / AI engine 350.

[0336] The page analyzer 3302 may also be executed online (e.g., while the page is being executed / viewed). For example, changes to components during runtime may require a re-analysis of the page and, as a result, changes to the page (possibly requiring a full or partial regeneration and page reload). This may apply to concurrent changes (e.g., changes made by other users while the page is being executed) or changes performed within the page (e.g., changes to related code, or cases where end users may modify the page, such as a blog system where user comments can be added).

[0337] The page converter 3303 can use the output of the page analyzer 3302 to convert the input page accordingly.

[0338] The page converter 3303 can generate a CSS grid definition for the page that implements the processing of BEH triggers. The created grid can convert an object frame into a set of cells attached to splitters (as described below) or merged cells. The created grid can use additional techniques to support further dynamic layout processing, such as extra rows and wedges, described below.

[0339] Transformed pages may also contain additional code and elements, such as JS code required to process explicit anchors and other trigger types, and any associated embedded data.

[0340] Reference is now made to FIG. 22 which illustrates the sub-elements of the page converter 3304. The page converter 3304 may further include a splitter placer 33041 and a mesh grid generator 33042.

[0341] The splitter placer 33041 may replace the implicit dynamic layout anchors with a horizontal splitter that creates a grid. It can be understood that the splitter is per-container and not per-screen, as each container is represented by a grid (each container has its own grid). The following description focuses on horizontal splitters, but vertical splitters can also be implemented.

[0342] It can be appreciated that instead of implicit anchors between components, the page converter 3304 can anchor the components to a grid, which can allow for more efficient execution by the CSS generator 320.

[0343] A splitter can be understood to be a virtual line that can be used to pin components to the layout. Components pinned by a splitter may be pushed and pulled, and other components pinned to the same splitter may be affected by the resulting movement of the splitter. There may be multiple splitters defined for a page or container. Splitters are typically implemented using a declarative CSS mechanism so that no JS is required.

[0344] Splitters may only affect some components, since some components may reside in merged grid cells that are not affected by changes to some splitters. In a typical configuration, component A will push component B only if B starts after A finishes. Also, a component's height will only change depending on its contents. For containers, this includes being affected by contained components.

[0345] Referring now to Figure 23, which illustrates the relationship between components and splitters, there are shown components [a] through [g] and splitters 1 through 5. As can be seen, component [a] is only affected by changes in splitter 1, and its height is controlled by its content and not by the other components.

[0346] Component [b] is pushed by splitter 1.

[0347] Component [c] is pushed by splitters 1 and 3.

[0348] For components [d, e, f, g], each component is pushed by all the rows "above" them.

[0349] It can be appreciated that by expanding or contracting any component (or wedge, discussed in more detail below), the lines in the grid can be moved up or down. In this manner, the position of the components can be modified based on the movement of the splitter.

[0350] The same may apply to component sizes, since components within a grid cell may be anchored to multiple sides (e.g., the top and bottom of the grid cell) and may stretch / shrink as the cell size changes. The splitter placer 33041 may implement such anchors as automatic or explicit anchors.

[0351] The splitter placer 33041 may also allow the user to do this by pushing relationships between component "columns," as shown in Figures 24A and 24B, referenced herein. Figure 24A shows a situation where component a1 is above component a2, and component b1 is above b2 (four components aligned in two rows). The user wants component a1 to push component a2, and component b1 to push b2 (as they stretch), but does not want component a1 to push component b2, or component a2 to push component b1.

[0352] If the splitter placer 33041 places a single splitter S1 passing between Row1 and Row2, the downward extending component a1 will also push component b2. To prevent this, the splitter placer 33041 may build two invisible boxes / groups (each with its own grid) with [c] wrapping components a1 / a2 and [d] wrapping components b1 / b2 as shown in Figure 24B. Both boxes are contained in the enclosing frame K, and thus there is a separate pushing relationship between components a1 and a2 and between components b1 and b2.

[0353] It can be appreciated that once the page analyzer 3303 has analyzed the page and the page converter 3304 has generated the page's underlying CSS grid definition, the page can be rendered and displayed. It can be appreciated that the page analyzer 3303 and page converter 3304 can function during other stages as well and may not necessarily require rendering. The mesh applier 303 can now respond to various events and triggers. These can include the various trigger types BEH, JSH, and GRB discussed above.

[0354] BEH triggers (and the resulting changes in component size / position) are handled by the browser based on browser enforcement rules that govern the behavior of CSS Grid under page changes.

[0355] Reference is now made to FIG. 25, which illustrates the application of CSS grid rules to splitters and components. FIG. 25 illustrates a configuration with three components (A, B, and C), and scenario I illustrates their initial state. In scenario II, component C is expanded downwards. With default CSS grid rules, component C pushes splitter #3 downwards, and the increase in size is divided evenly between the first and second grid rows (so splitter 2 moves down by half of it), and component B moves down. The mesh grid generator 33042 may recalculate the grid. It can be seen that the entire operation can be performed within the browser engine without the involvement of higher level JS code.

[0356] Other trigger types are also not resolved within the browser engine. JSH triggers require JS code to be executed. This code may modify elements of the page (e.g. modifying the DOM structure) and require a recalculation of follow-up pages. The JS code may be at the WBS level (e.g. part of the WBS client code) or it may be part of a specific page-related JS code (e.g. page-related functions).

[0357] Some changes (such as changes to the page component hierarchy) can trigger a GRB trigger, requiring grid regeneration (full or partial) by the mesh grid generator 33042 and a re-rendering of the page by the CSS generator 320.

[0358] Since the CSS Grid definition is a W3 standard, it will be understood that its behavior is uniform across platforms / browsers / versions, and therefore the mesh grid generator 33042 can compensate for any bugs and implementation issues, or any differences that may arise in the future.

[0359] As described herein above, the page analyzer 3303 can perform its analysis based on geometric properties (size, position, overlap, proximity, layers) as well as available WBS 200 attributes and other available information stored in the CMS 50. This analysis determines the structure and layout of elements and the implied anchors / relationships between them (similar to the gateway conditions referred to in U.S. Pat. No. 10,185,703). It can be appreciated that based on this analysis, the mesh applier 330 can create a smart mesh that is used to create relationships between components (such as "A pushes B").

[0360] Of course, this smart mesh can be implemented at several levels. For example, a limited "pushing row" implementation can use a CSS grid with a single column per container with multiple rows that provide the pushing behavior. A more comprehensive implementation can use a CSS grid with multiple columns.

[0361] Reference is now made to FIG. 26, which illustrates an example of component distances and the resulting docking effect. As shown, component [x] is in the bottom right corner and is far enough away from other components [a-d]. The page analyzer 3303 may determine (based on its analysis) that [x] is intended to be aligned to the bottom right of the containing frame and should have implicit anchors [p] and [q]. This effect (known as "docking") may be part of the analysis performed by the edit handler 310, as described above in this specification, or may be part of a later analysis (e.g., during publishing or during page load).

[0362] Refer now to Figure 27, which shows another pushing scenario. Components [A] and [B] are above [C]. If either components [A] or [B] extend to a small enough distance [d] from component [C], they will push component [C] down. This is referred to here as activating the implicit anchor.

[0363] A user may wish to cancel / invalidate the implicit anchors of BC (e.g., by providing such instructions via the response editor 310) while leaving the implicit anchors of AC intact. To accomplish this (as shown in FIG. 28 to which reference is now made), the mesh grid generator 33042 may place components [A] and [C] in a separate transparent container [x] inside a transparent container [y] and component [B]. Both [x] and [y] can exist side-by-side in the frame [f] and are siblings in the component tree (although their areas overlap). Thus, when component [B] stretches, it does not affect component [C].

[0364] With regard to overlapping components, the mesh grid generator 33042 may employ an implicit z-order arrangement where components are kept in an array and always ordered. This order is used when rendering the HTML. Thus, the later an element appears in the HTML, the higher that element's z-order will be (if its siblings overlap).

[0365] The mesh grid generator 33042 may also place multiple components into a single grid cell within the generated grid and may use multiple mechanisms to control their order, placement, and alignment within the cell.

[0366] In particular, grid CSS allows for the specification of the coordinates of each element within the cell that contains it, since multiple components can be assigned to each cell (e.g., using fixed positioned components). Grid CSS further allows for the specification of guidance regarding the alignment and docking of each component (e.g., how the components are aligned within the cell). This allows for overlapping components, with their z-order defined according to the DOM order (i.e., the order of objects in the original file text). The mesh grid generator 33042 may also use the CSS z-index attribute for this purpose.

[0367] As mentioned above, the mesh grid generator 33042 may also use alternative layout methods or other mechanisms for component placement and cell content management (such as using a flexbox layout for list or repeater type components).

[0368] The mesh grid generator 33042 may optimize layout behavior by balancing the granularity of the grid and the placement of multiple elements within a single grid cell. It can be divided into more or fewer cells to optimize behavior for a particular placement / layout. This may depend on the performance characteristics of a particular browser / platform / version (e.g., the mesh grid generator 33042 may generate different grid combinations for different browsers).

[0369] Reference is now made to Figures 29A-C, which illustrate the use of extra lines to maintain element layout. As shown in Figure 29A, component [A] is placed in grid column R1, and component [B] is placed in grid column R2. Component [C] spans both rows (R1 and R2).

[0370] When a component spans more than one row, and the component stretches, the grid implementation needs to decide what to do with the extra space across all the rows that this component spans. (If every component belongs to exactly one row (no row spanning), this doesn't cause a problem.)

[0371] In this example, when component [C] grows downwards (e.g., because the size of its text content increases), it pushes line L3 downwards (the bottom row of grid row R2). The regular behavior of CSS Grid is to increase the size of both components R1 and R2 equally, causing [A] and [B] to occupy only a portion of their respective components (as shown in Figure 29B), thereby destroying the visual layout.

[0372] The extra row generator 33044 may solve this (as shown in FIG. 29C) by adding an invisible extra row R3. The component [C] is made to extend into row R3, so that when [C] extends, it only increases the size of R3 without affecting R1 and R2.

[0373] It can be seen that even with this extra line defined, the default behavior of the grid is to split the added space between the three rows (R1, R2, and R3). To prevent this and ensure that the additional space goes only to R1 and R2, the mesh grid generator 33042 generates a grid where the "regular" rows (in this case, R1 and R2) are defined as "minimum content" rows, and the additional row (R3) is defined as a "1fr" (fractional) row.

[0374] The extra row generator 33044 can implement a standard grid spatial processing algorithm that selects the rows that contain the least amount of elements. The extra space is then divided evenly among these selected rows. Thus, the extra row generator 33042 can generate "extra rows" that ensure that there is always exactly one row (that is extra) that receives extra space, thus preserving the design.

[0375] It can be appreciated that these extra rows are pre-created based on the user's specification of the expected dynamic layout behavior in the responsive editor 310. This specification can be thought of as a "reverse anchor" that specifies that the component should not extend downwards.

[0376] It can be appreciated that the conversion to a grid can also use a wedge element as illustrated in Figure 30, to which reference is now made. This is the use of an invisible "wedge object" that holds a particular splitter in place, thereby maintaining a minimum Y value for a given row.

[0377] The wedge generator 33043 may implement the wedge element using a DIV element with a static height (eg, 500px) and zero width (0px) to make the wedge element invisible.

[0378] As shown in Figure 30, splitter L3 is "held in place" at a pre-specified Y value by the wedge object [W]. Component [B] is allowed to stretch downwards until it reaches the L3 line. When component [B] reaches L3 it may begin to push L3 downwards (moving it lower than the end of the wedge [W]). As component [B] contracts back, L3 moves back until it reaches wedge [W], where it stops. Thus wedge [W] keeps row R2 at some minimum size.

[0379] The wedge generator 33043 essentially creates a soft anchor (eg, between the bottom surface of component [B] and L3) so that L3 does not rise above a certain point.

[0380] In embodiments of the mesh applier 303 that are implemented with CSS Grid, the internal CSS Grid mechanism may not provide sufficient support for some explicit anchor types.

[0381] In some cases, anchors and "short anchors" in particular are used in the context of creating groups of elements. For example, a user may group a set of elements that together form a product description, such as components that display the product name, illustration, and price. The user can pin them all together to preserve their combined layout and move them together when editing.

[0382] Such an arrangement can be detected (e.g., by the page analyzer 3303 using hints inserted in the response editor 310 or earlier at the template level). The arrangement of components may then be converted into an explicitly defined group, which may be implemented using a lightweight container. Such a group container still has an internal grid for laying out its child relationships, and thus it behaves similarly to nesting actual containers. A group is typically considered a single component, and may be implemented such that the component does not "break apart."

[0383] Reference is now made to FIG. 31 which illustrates a long distance anchor AB that cannot typically be implemented using CSS Grid and mesh grid structures. In this scenario, the mesh applier 330 can complement what can be done with CSS Grid by follow-up loading of relevant JS code. The JS code can measure page elements and implement additional interactions. The JS code can listen for field and layout changes (e.g., via JS onChange() or similar mechanisms) and explicitly change the anchor target.

[0384] Thus, the use of fluid components and mesh grids, along with the use of specialized elements such as layouts, wedges, and splitters, may enable a WBS to incorporate smart CSS generation during the access, edit, save, and publish stages of website creation and editing. This smart CSS may enable rendering at the browser level without the need for typical runtime compilation providing better page load and processing times. Additionally, the system may include additional elements to interface with different browsers, including elements such as browser add-ons or plugins, browser extensions, polyfills, or other elements intended to extend or enhance browser functionality.

[0385] Thus, the use of fluid components and mesh grids, along with the use of specialized elements such as layouts, wedges, and splitters, may enable WBS to incorporate smart CSS generation during the access, edit, save, and publish stages of website creation and editing. This smart CSS may enable rendering at the browser level without the need for typical runtime compilation providing better page load and processing times.

[0386] Unless otherwise indicated, throughout this specification, discussions utilizing terms such as "processing," "operating," "calculating," "determining," and the like, are understood to refer to the actions and / or processes of any type of general-purpose computer, such as a client / server system, mobile computing device, smart appliance, cloud computing unit, or similar electronic computing device, that manipulates and / or transforms data in the registers and / or memory of the computing system to other data in the memory, registers, or other such information storage, transmission, or display device of the computing system.

[0387] An embodiment of the present invention may include an apparatus for performing the operations herein. The apparatus may be specially constructed for the desired purpose or may comprise a computing device or system, typically having at least one processor and at least one memory, selectively activated or reconfigured by a computer program stored in the computer. The resulting apparatus, when instructed by software, can transform a general-purpose computer into an inventive element as described herein. The instructions can define the device of the present invention to operate with the computer platform for which it is desired. Such a computer program can be stored on a computer-readable storage medium, such as any type of disk, including but not limited to optical disks, magnetic optical disks, read-only memory (ROM), volatile and non-volatile memory, random access memory (RAM), electrically programmable read-only memory (EPROM), electrically erasable and programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, disk-on-key, or any other type of medium suitable for storing electronic instructions and capable of coupling to a computer system bus. The computer-readable storage medium can also be implemented in a cloud storage device.

[0388] Some general purpose computers may include at least one communication element to enable communication with data networks and / or mobile communication networks.

[0389] The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the desired methods. The desired structure for a variety of these systems will appear from the description that follows. Further, embodiments of the present invention are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​may be used to implement the teachings of the present invention as described herein.

[0390] While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art, and it is therefore to be understood that the appended claims are intended to cover all such modifications and changes as fall within the spirit and scope of the invention.

Claims

1. A website building system (WBS), At least one processor; an edit handler executing on the at least one processor for receiving edit actions and changes to display width parameters from a designer of the WBS and defining changes to a page of the WBS website for a component in response to the edit actions and changes to the display width parameters; Equipped with The edit handler: a dynamic layout handler for processing dynamic layout triggers associated with the edit action and modifying the layout of the page accordingly; a layout handler that calculates an updated layout for the page according to a formula based on the changed display width parameters; a text scaler for scaling text between a minimum and a maximum value in response to the modified display width parameter; a visibility handler that manages the hiding and unhiding of components in predefined breakpoint ranges of the page; a component handler that applies attributes of the component according to parameters that affect responsiveness, as modified by the editing action; having Website building system.

2. the dynamic layout handler processes the dynamic layout trigger by receiving content changes to a component, determining if the content changes affect the position of the component, and modifying the layout of other components on the page based on the size or position changes.

2. The website construction system according to claim 1.

3. the layout handler calculates the updated layout by determining a current breakpoint range based on the changed display width parameter, selecting a layout expression associated with the current breakpoint range, and applying the selected layout expression to calculate positions and sizes of components of the page.

2. The website construction system according to claim 1.

4. the text scaler scales text by determining a scaling factor based on the modified display width parameter, applying the scaling factor to a base font size to determine a scaled font size, and adjusting font sizes of text components of the page to the scaled font size.

2. The website construction system according to claim 1.

5. the visibility handler manages hiding and unhiding of components by storing visibility rules associated with each component in different breakpoint ranges, determining a current breakpoint range based on the changed display width parameter, and applying the visibility rules to the current breakpoint range to reveal or hide the component accordingly.

2. The website construction system according to claim 1.

6. the component handler modifies the component's attributes by identifying attributes of the component that are affected by the responsiveness-affecting parameters, determining new values ​​for the responsiveness attributes based on the modified responsiveness-affecting parameters, and updating the identified responsiveness attributes to the new values.

2. The website construction system according to claim 1.

7. a cascading style sheet (CSS) generator that generates CSS based on the changes defined by the edit handler; 2. The website construction system according to claim 1.

8. and an explainer and suggester for providing an explanation to a user for a given action by the edit handler and for suggesting solutions or suggestions to the user for the edit in response to a machine learning (ML) and artificial intelligence (AI) engine.

2. The website construction system according to claim 1.

9. at least one database storing website pages and layouts including fluid components and breakpoint ranges for multiple viewport sizes; The fluid component has a size and attributes that are influenced by a parent component in a container arrangement.

2. The website construction system according to claim 1.

10. a previewer that responds to the edit handler to provide a WYSIWYG preview of the edited application; 2. The website construction system according to claim 1.

11. A method for response editing in a website building system (WBS), comprising: receiving edit actions and changes to display width parameters from a designer of the WBS; defining changes to the WBS website page for components in response to the editing action and the change in the display width parameter; Have The above definitions are processing a dynamic layout trigger associated with the editing action to modify the layout of the page accordingly; calculating an updated layout for the page according to a formula based on the changed display width parameters; scaling the text between a minimum and a maximum value in response to the modified display width parameter; Managing the hiding and unhiding of components in predefined breakpoint ranges of the page; applying attributes of the component according to parameters affecting responsiveness that are modified by the editing action; having method.

12. processing the dynamic layout trigger includes receiving a content change to a component, determining whether the content change affects a position of the component, and modifying a layout of other components on the page based on the position change. The method of claim 11.

13. calculating the updated layout includes determining a current breakpoint range based on the changed display width parameter, selecting a layout expression associated with the current breakpoint range, and applying the selected layout expression to calculate positions and sizes of components of the page. The method of claim 11.

14. scaling the text includes determining a scaling factor based on the modified display width parameter, applying the scaling factor to a base font size to determine a scaled font size, and adjusting font sizes of text components of the page to the scaled font size. The method of claim 11.

15. Managing the hiding and unhiding of the components includes storing visibility rules associated with each component in different breakpoint ranges, determining a current breakpoint range based on the changed display width parameter, and applying the visibility rules to the current breakpoint range to reveal or hide the component accordingly. The method of claim 11.

16. applying the component attributes includes identifying component attributes that are affected by the responsiveness-affecting parameters, determining new values ​​for the responsiveness attributes based on the modified responsiveness-affecting parameters, and updating the identified responsiveness attributes to the new values. The method of claim 11.

17. a cascading style sheet (CSS) generator that generates CSS based on the changes defined by the edit action and the changed display width parameter. The method of claim 11.

18. providing explanations to the designer for a given action and suggesting solutions or suggestions to the designer for editing in response to a machine learning (ML) and artificial intelligence (AI) engine; 20. The method of claim 17.

19. storing website pages and layouts including fluid components and breakpoint ranges for multiple viewport sizes; The fluid component has a size and attributes that are influenced by a parent component in a container arrangement. The method of claim 11.

20. providing a WYSIWYG preview of the application of the edits in response to the edit action and the changed display width parameter. The method of claim 11.

Images