Method for judging web interface interaction complexity

Abstract

The invention relates to the technical field of user interface development and evaluation, and provides a method for judging web interface interaction complexity, and the method comprises the steps: S1, dividing a web interface into a plurality of function modules; s2, counting the number of UI elements in each function module through an element number statistical model; s3, analyzing a data dependence or transmission relationship among the functional modules in the web page through a data flow hierarchy complexity model, and determining a transmission link depth of data among the modules; s4, counting the single-page data volume of the web interface through a single-page data volume statistical model; and S5, calculating the web interface interaction complexity based on the number of UI elements in each function module, the transmission link depth and the single-page data volume. Compared with a traditional function counting or code quantity statistical method, the hidden complexity such as bidirectional data flow and condition triggering refreshing in the module dependency chain can be accurately recognized, and a scientific basis is provided for development resource allocation.

Description

Technical Field

[0001] The present application relates to the technical field of user interface development and evaluation, and in particular to a method for determining the complexity of web interface interaction. Background Art

[0002] Currently, there's a lack of an objective, quantitative standard for determining page interaction complexity during front-end development and UI design review. Developers and designers often rely on their subjective experience to determine the difficulty of a page, leading to differing perceptions of the complexity of the same page.

[0003] This subjective estimation method leads to multiple problems: Underestimating complexity can lead to insufficient development cycles and resource allocation, risking delays; overestimating complexity can waste resources and prolong project cycles. Existing evaluation methods often focus solely on the number of features or code, lacking systematic quantitative consideration of the number of elements in the UI itself, the data interactions between modules, and the amount of content on the page. Consequently, they fail to fully and accurately reflect interaction complexity.

[0004] In addition, existing web interface evaluation technologies lack effective technical means to accurately judge the data interaction relationship between modules, cannot accurately determine the depth of the transmission link, and do not take the transmission link depth into consideration in the evaluation of the complexity of web interface interactions. Summary of the Invention

[0005] To help solve the above technical problems, this application provides a method for determining the complexity of web interface interaction, using the following technical solutions: A method for determining the complexity of web interface interaction, wherein the method for determining the complexity of web interface interaction includes: S1: Divide the web interface into multiple functional modules; S2: Count the number of UI elements in each functional module through the element quantity statistical model; S3: Analyze the data dependency or transfer relationship between various functional modules in the web page through the data flow hierarchy complexity model to determine the depth of the data transmission link between each module; S4: Count the single-page data volume of the web interface through the single-page data volume statistical model; S5: Calculating the web interface interaction complexity based on the number of UI elements in each functional module, the transmission link depth, and the single-page data volume.

[0006] Preferably, step S1 includes: the functional module includes: A filter area, including filter items, where the filter items include at least product categories; The product list area includes product data items, and the product data items at least include a product ID; The batch operation area includes batch operation buttons, which include at least batch deletion, batch listing, and batch delisting.

[0007] Preferably, step S2 includes: calculating the first complexity based on the number of UI elements in each functional module and the weight corresponding to each functional module.

[0008] Preferably, step S3 includes: recording the maximum level of inter-module dependencies as the second complexity.

[0009] Preferably, step S4 includes: when the web interface includes a single-page data volume, calculating the third complexity based on the single-page data volume and the corresponding weight; when the web interface includes multiple pages of data volume, calculating the third complexity based on the maximum single-page data volume, the average single-page data volume, the complexity accumulation value and the corresponding weight; the complexity accumulation value is the cumulative value of all single-page complexities, and the single-page complexity is calculated based on the single-page data volume and the corresponding weight.

[0010] Preferably, step S5 includes: calculating the web interface interaction complexity based on the first complexity, the second complexity, the third complexity and the corresponding weights.

[0011] In summary, this application integrates multi-dimensional indicators such as the number of UI elements, the hierarchical relationship of data flows between modules, and the load capacity of page content, achieving full-link complexity quantification from static interface elements to dynamic data flows. Compared with traditional function counting or code volume statistics methods, this application can accurately identify implicit complexities in module dependency chains, such as bidirectional data flows and conditional trigger refreshes, providing a scientific basis for development resource allocation. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 This is a flow chart of an embodiment of a method for determining the complexity of web interface interaction according to the present application; Figure 2 A schematic diagram of an embodiment of the web interface of the present application. DETAILED DESCRIPTION

[0013] The present invention will be further described below with reference to the accompanying drawings. The structure and principle of the present invention will be very clear to those skilled in the art. It should be understood that the specific embodiments described herein are only intended to explain the present invention and are not intended to limit the present invention.

[0014] Figure 1 This is a flow chart of an embodiment of a method for determining the complexity of web interface interaction in this application. Figure 2 A schematic diagram of an embodiment of the web interface of the present application.

[0015] Combine Figure 1 and Figure 2 It is understood that the method for determining the complexity of web interface interaction in this application includes: S1: Divide the web interface into multiple functional modules. Step S1 includes: The functional modules include a filter area, a product list area, and a batch operation area. The filter area includes filter items, which include at least product categories. The product list area includes product data items, which include at least product IDs. The batch operation area includes batch operation buttons, which include at least batch deletion, batch listing, and batch delisting.

[0016] S2: Counting the number of UI elements in each functional module using an element quantity statistical model. Step S2 includes: calculating a first complexity based on the number of UI elements in each functional module and the weight corresponding to each functional module.

[0017] S3: Analyze the data dependencies or transfer relationships between the functional modules in the web page using the data flow level complexity model to determine the depth of the data transmission link between the modules. Step S3 includes: recording the maximum level of inter-module dependency as the second complexity.

[0018] S4: Counting the single-page data volume of the web interface using a single-page data volume statistical model. Step S4 includes: when the web interface includes a single-page data volume, calculating a third complexity based on the single-page data volume and a corresponding weight; when the web interface includes multiple pages of data, calculating the third complexity based on the maximum single-page data volume, the average single-page data volume, the cumulative complexity value, and the corresponding weight. The cumulative complexity value is the cumulative value of all single-page complexities. The single-page complexity is calculated based on the single-page data volume and the corresponding weight.

[0019] S5: Calculating the web interface interaction complexity based on the number of UI elements in each functional module, the transmission link depth, and the single-page data volume. Step S5 includes: calculating the web interface interaction complexity based on the first complexity, the second complexity, the third complexity, and the corresponding weights.

[0020] Next, combine Figure 2 A typical product list management page is used to describe each step in detail. Suppose you need to evaluate the interaction complexity of a "product list" page in a backend management system. This page contains the following main functional modules: Module A: Filter area - used for users to filter products according to different conditions.

[0021] Module B: Product List Area - Displays filtered product information in a table format, supporting paging.

[0022] Module C: Bulk Operation Area - Provides buttons for bulk operations on selected products.

[0023] Step S1: module division and element statistics and step S2: element quantity weight evaluation.

[0024] Divide the page interface into several functional modules and count the number of UI elements in each module (such as filter controls, list fields, input items, operation items, etc.).

[0025] The element count model calculates elements based on the principle that different types of elements have different impacts on interaction complexity, so corresponding weights are assigned to them. For example, filter items can be assigned a score of 1, or a baseline weight of 1; list items can be assigned lower or higher weights, depending on project requirements; input items and button actions can also be assigned different weights for high, medium, or low difficulty. The number of elements in each module is multiplied by the corresponding weight coefficient and then added together to obtain the page's overall score for the "Number of Elements" dimension.

[0026] Module A (Screening Area): Contains 7 filter items (for example: product category, brand, status, price range start, price range end, creation time start, creation time end).

[0027] Number of filter items = 7.

[0028] Module B (Product Listing Area): Each row of the table displays 18 product-related data items (fields) (for example: product ID, main image, name, SKU, category, brand, price, inventory, sales, status, creation time, modification time, sorting value, etc., as well as 4 independent operation items such as edit, delete, put on shelf, and take off shelf).

[0029] Number of data items (fields) per row = 18.

[0030] Number of independent operations per row = 4. Operation complexity is low.

[0031] Pagination setting: Display 50 data items per page. Number of data items per page = 50.

[0032] Module C (batch operation area): Contains 3 batch operation buttons (for example: batch deletion, batch listing, batch delisting).

[0033] The number of operations in the independent module is 3. The operation complexity is medium.

[0034] The principle of element number weight evaluation is as follows: According to the provided standards: Module A (Screening Area): The number of filter items is 7, belonging to the interval [5, 10), and the weight score = 3.

[0035] Module A score = 3.

[0036] Module B (Product Listing Area): The number of data items in each row is 18, belonging to the interval [15, 20), and the weight score = 10.

[0037] The number of independent operations in each row is 4, which belongs to the interval [1, 5), the complexity is "low", and the weight score = 1×1 = 1.

[0038] Module B (single row) element weight score = 10 (data item) + 1 (operation item) = 11.

[0039] Module C (batch operation area): The number of independent module operations is 3, which belongs to the interval [1, 5), the complexity is "medium", and the weight score = 1×2 = 2.

[0040] Module C score = 2.

[0041] Page basic element complexity score: Add up the scores for each module: Score_elements = Score_A + Score_B_row + Score_C = 3 + 11 + 2 = 16.

[0042] Step S3: Evaluation of the complexity of data flow level. Based on the principles of graph theory and event-driven architecture, the functional modules in the page are abstracted as directed graph nodes. The data flow topology is constructed by collecting the event subscription relationships between modules. The topological sorting and dynamic programming algorithms are used to calculate the longest data transmission path level as the transmission link depth. The transmission link depth of the inter-module dependency is recorded as the second complexity. The data flow level is defined according to the number of path nodes, and each level corresponds to a preset incremental score. The algorithm uses user operations as the trigger source, determines the subgraph boundary by tracking the event propagation link, assigns a basic level value to isolated nodes, and calculates the actual level of the associated nodes through the longest path algorithm. Finally, the data flow complexity is quantified in combination with the level weight.

[0043] Specifically, they may include: Analyze the data dependency or transfer relationship between functional modules to determine the transmission link depth; Divide the data flow level into multiple layers and assign increasing scores; Build a data flow hierarchy complexity model through module identification, event collection, graph modeling, and edge classification; Based on the data flow hierarchy complexity model, a hierarchical calculation algorithm is used. With a single user operation or browser event as the source node set, directed edges are traced to form a subgraph, and the longest directed path is calculated to determine the hierarchy (transmission link depth). Based on graph theory and event-driven paradigm as the underlying principles, the hierarchy is determined and weighted according to the longest data flow path to quantify the complexity of data flow.

[0044] The principle of the data flow hierarchical complexity model is to analyze the data dependency or transmission relationship between the functional modules within the page and determine the depth (number of levels) of the data transmission link between these modules.

[0045] The more levels there are, the more complex the data interactions within the interface. Data flow levels can be divided into 1 to 5 levels, with scores assigned in ascending order of 1, 3, 5, 10, 20, etc. (this number can be adjusted based on actual needs).

[0046] The maximum level of inter-module dependencies is recorded as the data flow complexity score for this page and combined with other complexity factors.

[0047] The product of the sum of the weight scores of modules at each level and the weight score of the data flow level is the complexity weight score of the entire functional module involved in the data flow.

[0048] In this example, the data flow is analyzed: The conditions in the filter area (module A) affect the displayed content in the product list area (module B). Data flow: A -> B.

[0049] The batch operation area (module C) operates on the items selected in the product list area (module B). Data flow: B -> C (selection status) & C -> B (list refresh after operation).

[0050] Data flow definition: F1: The A → B filter condition triggers a query and returns new list data.

[0051] F2: The selected status of the B → C list is synchronized to the batch operation panel in real time.

[0052] F3: After the C → B batch operation is successful, a refresh event is issued to drive the list to re-request.

[0053] Data flow graph construction steps: Module identification scans the interface source code or UI specification document and classifies components with independent states and business boundaries as nodes V.

[0054] The event collection enumerates each node's outbound events and inbound subscriptions (such as onFilterChange, onSelectionChange, onBatchSuccess).

[0055] Graph modeling represents the system as a directed graph G(V,E): if event e is sent from node vi and subscribed by vj, a directed edge (vi,vj) is added.

[0056] Edge classification divides E into: Query type (data request) Stateful (UI state synchronization) Command type (profiling operation results) This facilitates subsequent impact analysis and performance optimization.

[0057] Longest Path calculation algorithm (based on single user trigger) Core definition: The level of a triggered chain = the number of nodes the chain passes through (including the starting point and the end point), which is equivalent to the number of edges in the directed path + 1.

[0058] Calculation principles: Take a single user operation / browser event as the source node set S; only track the directed edges directly or indirectly triggered by S to form a subgraph G_S.

[0059] If a node has neither incoming nor outgoing edges in G_S, it is considered an isolated node and its level = 1.

[0060] For the remaining nodes, find the longest directed path p = (v1 → v2 → … → v k ), then the level of this trigger is L = k (k is the number of nodes).

[0061] Pseudocode example: Input: DAG G′(V, E) Output: L = max distance(v) over V 1. TopoList ← TopologicalSort(G′) 2. for v in V: dist[v] ← 0 3. for u in TopoList: for each edge (u → v): if dist[v] <dist[u] + 1: dist[v]← dist[u] + 1 4. L ← max(dist[v]) Description of the underlying principle Graph Theory The data flow is viewed as a directed acyclic graph (G′ after contraction), and the number of layers is the length of the longest directed path.

[0062] The event-driven paradigm adopts the Publish-Subscribe or Flux architecture on the front end, and data is transmitted between modules only through events / Actions, naturally forming a one-way data flow.

[0063] Determine the level: Module A affects module B, and module C depends on and affects module B. There is data interaction between modules.

[0064] The longest data flow path can be considered to be 2 layers (for example, the user enters the filter conditions at A, and the data is passed to B for query and display).

[0065] According to the "Data Stream Serialization / Number of Layers Weight" standard, the weight corresponding to 2 layers is 3.

[0066] Data flow complexity score = 3. (According to the above content: "The maximum level of inter-module dependencies (the transmission link depth) is recorded as the data flow complexity score of this page").

[0067] Specifically, the principle of the data flow level complexity model: Analyze the data dependency or transfer relationship between the functional modules within the page, and determine the depth (number of levels) of the data transmission link between these modules.

[0068] The more levels there are, the more complex the data interaction within the interface is.

[0069] The data flow level can be divided into 1 to 5 layers, and given increasing scores of 1, 3, 5, 10, 20, etc. (can be adjusted according to actual needs).

[0070] Implementation steps: Module identification: Scan the interface source code or UI specification document and classify components with independent states and business boundaries as nodes V.

[0071] Event collection: Enumerates outbound events and inbound subscriptions (such as onFilterChange, onSelectionChange, onBatchSuccess) for each node.

[0072] Graph modeling: The system is represented by a directed graph G(V,E). If an event e is sent from node vi and subscribed to by vj, a directed edge (vi,vj) is added.

[0073] Edge classification: E is divided into query type (data request), state type (UI state synchronization), and command type (profiling operation results) to facilitate subsequent impact analysis and performance optimization.

[0074] Hierarchical (Longest Path) calculation algorithm: Core definition: The level of a triggered chain = the number of nodes the chain passes through (including the starting point and the end point), which is equivalent to the number of edges in the directed path + 1.

[0075] Calculation principles: Take a single user operation / browser event as the source node set S; Only the directed edges directly or indirectly triggered by S are tracked to form a subgraph G_S; If a node has neither incoming nor outgoing edges in G_S, it is considered an isolated node and its level = 1; For the remaining nodes, find the longest directed path p=(v1→v2→…→v k ), then the level of this trigger is L=k (k is the number of nodes).

[0076] Description of the underlying principle: Graph theory: The data flow is viewed as a directed acyclic graph (G′ after contraction), and the number of layers is the length of the longest directed path.

[0077] Event-driven paradigm: The front-end adopts Publish-Subscribe or Flux architecture, and data is transmitted between modules only through events / Actions, naturally forming a one-way data flow.

[0078] Determine the level: The tier is determined based on the longest data flow path.

[0079] In the example, module A affects module B, module C depends on and affects module B, and the longest data flow path is considered to be 2 layers (for example, the user enters the filter conditions in A, and the data is passed to B for query and display).

[0080] According to the "data stream serial / layer number weight score" standard, the weight score corresponding to 2 layers = 3.

[0081] Data flow complexity score = 3.

[0082] Through this model, we can systematically analyze the data dependencies or transmission relationships between various functional modules within a web page, and quantify the depth of data transmission links between modules, providing an objective basis for evaluating the interaction complexity of the web interface.

[0083] Step S3: Evaluate the complexity of single-page data volume.

[0084] The principle behind the single-page data volume statistical model is that if a page needs to display a certain number of data items, the amount of data that can or actually is supported on a single page often affects the complexity of user interaction. Compared to displaying only a small amount of data on a single page, displaying more data on a single page requires more complex information to be processed by the interface, and this also places a higher load on browsing and operation.

[0085] Therefore, this application defines several intervals for "single-page data volume" and corresponds to different scores. Please refer to the following example intervals: [1, 30): 1 point.

[0086] [30, 50): 2 points.

[0087] [50, 100): 3 points.

[0088] [100, 500): 10 points.

[0089] In actual designs, if the amount of data displayed on a single page falls within a specified range, the complexity score for that range is used. For example, if 50 items are displayed on a page, the complexity score is 3 points; if 200 items are displayed on a page, the complexity score is 10 points. If there are multiple pages, the "maximum single-page data volume," "average single-page data volume," or "accumulated scores across multiple pages" can be used as the measurement basis, depending on specific needs.

[0090] In this embodiment, the page is paginated, and 50 pieces of data are displayed on each page.

[0091] According to the "Pagination, number of data items per page" weight standard, 50 items belong to the interval [50, 100), and the weight score is 3.

[0092] Single-page data complexity score = product list area weight score 11 * weight score 3 = 33.

[0093] Step S4: Calculation of total complexity score and classification of levels.

[0094] The total score of the page interaction complexity is obtained by calculating the sum or product of the "number of elements and weight score", "data flow level score" and "single-page data volume score" based on the inclusion relationship.

[0095] Based on pre-set thresholds, the total score is divided into different levels, such as: 0 to 70 points: Low complexity.

[0096] 70 to 150 points: Medium complexity.

[0097] 150 points and above: high complexity.

[0098] Developers or project managers can make timely adjustments to project planning or resource allocation based on the final score. This scoring system can be implemented uniformly across different teams and projects, helping reviewers and managers quickly assess the difficulty of page interactions.

[0099] In this embodiment, the total complexity score = page basic element complexity score * data flow complexity score + single-page data volume complexity score.

[0100] Total complexity score = 16 * 3 + 11 * 3 = 81.

[0101] According to the preset level threshold: 0 to 70 points: Low complexity.

[0102] 70 to 150 points: Medium complexity.

[0103] 150 points and above: high complexity.

[0104] The total complexity score of this product list page is 81 points, which is a medium complexity level.

[0105] Through this example, we can see that this method can derive an objective complexity score (81 points) and level (medium complexity) for a specific web page through quantitative analysis of its UI elements, data flow, and data volume. This result can be used in project management, for example: Estimate development workload, assess whether design interaction is reasonable, set a reasonable development cycle, etc.

[0106] Compared to subjective judgments by project members, this method provides a unified, reproducible, and data-based evaluation basis, improving accuracy and consistency. If another page's calculated score is significantly higher than this one (for example, over 150 points), it can be clearly determined that its interaction complexity is higher and requires more resources.

Claims

1. A method for determining the complexity of web interface interaction, characterized in that: The method for determining the complexity of web interface interaction includes: S1: Divide the web interface into multiple functional modules; S2: Count the number of UI elements in each functional module through the element quantity statistical model; S3: Analyze the data dependency or transmission relationship between various functional modules in the web page through the data flow level complexity model, and determine the depth of the data transmission link between each module; S3 includes; Based on the principles of graph theory and event-driven architecture, the functional modules in the page are abstracted as directed graph nodes. The data flow topology structure is constructed by collecting event subscription relationships between modules. The topological sorting and dynamic programming algorithms are used to calculate the longest data transmission path level as the transmission link depth.

2. The method for determining the complexity of web interface interaction according to claim 1, characterized in that: Step S1 includes: the functional module includes: A filter area, including filter items, where the filter items include at least product categories; The product list area includes product data items, and the product data items at least include a product ID; The batch operation area includes batch operation buttons, which include at least batch deletion, batch listing, and batch delisting.

3. The method for determining the complexity of web interface interaction according to claim 1, characterized in that: Step S2 includes: calculating a first complexity based on the number of UI elements in each functional module and the weight corresponding to each functional module.

4. The method for determining the complexity of web interface interaction according to claim 1, characterized in that: Step S3 includes: recording the transmission link depth of the inter-module dependency as the second complexity.

5. The method for determining the complexity of web interface interaction according to claim 1, characterized in that: Step S4 includes: when the web interface includes a single-page data volume, calculating the third complexity based on the single-page data volume and the corresponding weight; when the web interface includes multiple pages of data volume, calculating the third complexity based on the maximum single-page data volume, the average single-page data volume, the complexity accumulation value and the corresponding weight; the complexity accumulation value is the cumulative value of all single-page complexities, and the single-page complexity is calculated based on the single-page data volume and the corresponding weight.

6. The method for determining the complexity of web interface interaction according to claim 1, characterized in that: Step S5 includes: calculating the web interface interaction complexity based on the first complexity, the second complexity, the third complexity and the corresponding weights.

Images