Interaction control method and device for interface control

Abstract

The invention discloses an interaction control method and device for an interface control. The method comprises the steps of obtaining interaction event data of a movable control in an interface; selecting a coordinate extraction path corresponding to the interaction event data through path priority rollback logic in the coordinate unified abstraction layer so as to output event coordinates; updating an interaction state of the movable control based on the event coordinates; and based on the interaction state, controlling visual rendering of the movable control. And the problem of cross-end interaction experience splitting is eliminated.

Description

Technical Field

[0001] This application relates to the field of human-computer interaction technology, and in particular to an interactive control method and device for interface controls. Background Technology

[0002] In existing graphical user interfaces, especially in interactive controls that need to support cross-platform compatibility (such as mobile and desktop), user input operations generate different types of event streams from different underlying systems or browser engines. For example, on touchscreen devices, user actions trigger a TouchEvent sequence, while on desktop devices using a mouse, a MouseEvent sequence is triggered.

[0003] However, the differences between these two event models in terms of data structure, propagation mechanism and coordinate attributes directly lead to the split of event processing logic. It is difficult to ensure that touch operation and pointer device operation are completely consistent in terms of response latency, judgment accuracy and animation feedback. This makes it impossible to provide consistent and reliable interactive response across devices, resulting in a fragmented experience between devices. Summary of the Invention

[0004] To address the aforementioned problems, this application proposes an interactive control method for interface controls, the method comprising: Get the interaction event data of movable controls in the interface; By using the path priority fallback logic in the coordinate unification abstraction layer, the path corresponding to the interactive event data is extracted to output the event coordinates; Update the interactive state of the movable control based on the event coordinates; Based on the interaction state, control the visual rendering of the movable control.

[0005] In one example, the step of using the path priority fallback logic in the coordinate unification abstraction layer to select the coordinate extraction path corresponding to the interactive event data in order to output the event coordinates specifically includes: According to a preset priority order, the system sequentially checks whether there is a usable coordinate source in the interactive event data that corresponds to the current coordinate extraction path; If it exists, extract the coordinate value from the coordinate source of the current coordinate extraction path, use the coordinate value as the event coordinate, and terminate the detection of the next priority coordinate extraction path; If the coordinates do not exist, the process will fall back to the next priority coordinate extraction path and repeat the detection and extraction steps until the coordinates are extracted.

[0006] In one example, when the movable control is a switch component and the interaction state is a control interaction behavior, updating the interaction state of the movable control based on the event coordinates specifically includes: Calculate the displacement offset of the current interaction behavior relative to the movable control based on the difference between the event coordinates and the initial press coordinates; If the absolute value of the displacement offset is less than the first preset displacement threshold, it is determined that the current interactive behavior is a click operation, and the control state switch is triggered. If the absolute value of the displacement offset is greater than or equal to the first preset displacement threshold, it is determined that the current interactive behavior belongs to the drag operation stage, so as to control the movable control to follow the touch point.

[0007] In one example, when the movable control is a track slider type, the visual rendering of the movable control is controlled based on the interaction state, specifically including: In response to detecting an initial press operation on a movable control, a dynamic buffer style is injected into the visual element of the movable control, and a calculation relationship is established between at least one variable visual style parameter of the dynamic buffer style and the displacement offset of the movable control; the visual style parameter is used to simulate the visual indentation sensation. In response to detecting a drag-and-drop operation on a movable control, the corresponding visual style parameter value is calculated based on the calculation relationship and the displacement offset. In response to the detection of a release operation on a movable control, the dynamic buffer style is removed.

[0008] In one example, when the dynamic buffer style is configured as a compressible buffer space style, the visual rendering of the movable control is controlled based on the interaction state, specifically including: In response to detecting a dragging operation on a movable control, when the displacement offset reaches a preset convergence threshold close to the dragging boundary, the movable control is controlled to enter the boundary compression stage. During the boundary compression phase, the display position of the movable control no longer follows the touch point coordinates; If the touch point is detected to remain within the response area of ​​the movable control, the buffer space of the movable control is compressed by dynamically reducing the visual style parameter value; In response to detecting a release operation on the movable control, the movable control is controlled to bounce back to the drag boundary.

[0009] In one example, the buffer space of the movable control is compressed by dynamically reducing the visual style parameter value, specifically including: The buffer space is compressed according to a preset step-by-step compression rule; the step-by-step compression rule divides the compression process into multiple consecutive compression stages. Within each compression stage, the following steps are performed: Based on the compression rules corresponding to the current compression stage, the buffer space is compressed by reducing the visual style parameter values; Based on the displacement conversion relationship corresponding to the current compression stage, the compression amount of the buffer space is converted into the corresponding buffer displacement amount to control the movement of the display position of the movable control. In at least two consecutive compression stages, the amount of buffer displacement generated per unit compression decreases as the degree of compression increases.

[0010] In one example, the method further includes: Based on runtime environment parameters, adaptive geometric transformation is performed on the baseline design pixel values ​​to obtain preset displacement threshold parameters, preset convergence threshold parameters, and injected dynamic buffer style parameters during the interactive control process. In one example, based on the interactive state, the visual rendering of the movable control is controlled, specifically including: In response to the detection of an initial press operation on the movable control, disable the transition animation properties of the movable control; In response to detecting a release operation on the movable control, restore the transition animation properties of the movable control.

[0011] In one example, controlling the visual rendering of the movable control based on the interaction state specifically includes: Responding to detected UI theme parameters; Based on the interface theme parameters and control business logic state parameters, the target visual style parameters corresponding to the movable control are selected from the visual style parameter set.

[0012] On the other hand, embodiments of this application provide an interactive control device for interface controls, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute an interactive control method for interface controls as described above.

[0013] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: This paper proposes a system-level unified interaction control method. At the upstream of interaction data processing, heterogeneous touch events and pointer device events are unified with the same coordinates, so that all subsequent logic is based on the same data. In addition, combined with the centralized management of the interaction state and state-based rendering control, it ensures that the operation responsiveness, judgment logic, animation feedback and final result perceived by the user are exactly the same, whether it is touch, mouse or other pointer device, fundamentally eliminating the problem of cross-platform interaction experience fragmentation.

[0014] Furthermore, the interactive control flow is an abstract framework. The unified coordinate abstraction layer can adapt to new input devices in the future, its set of interactive states can be expanded to accommodate more dimensions of interactive information, and its rendering control strategy can be configured with different animation curves and visual themes. This design allows this method to serve as a basic model, widely applicable to various interface elements that require direct drag-and-drop manipulation.

[0015] Furthermore, existing technologies either only implement touch event logic on mobile devices and only implement mouse event logic on desktop devices, or implement both touch and mouse event logic on the same device. This makes them unsuitable for mixed-use scenarios with multiple input devices (such as laptops with touchscreens and 2-in-1 tablets). Because users may use touch and mouse operations alternately or simultaneously, existing solutions either cause one input method to fail due to the lack of event listeners, or cause event conflicts, response confusion, or inconsistent visual feedback due to the parallel operation of two independent logic sets.

[0016] This application achieves an input device-insensitive interaction kernel by unconditionally and simultaneously listening to touch and pointer device events and performing real-time unified processing of all inputs through a coordinate unified abstraction layer. This means that the system's processing of interaction events does not depend on the prediction of device type, but only on whether the event itself has occurred. Therefore, even on a single device, users can freely and seamlessly switch between finger touch and mouse click operations, and the system can provide completely consistent, continuous, and stable interactive responses, state determinations, and visual animations. This feature not only significantly improves the user experience on hybrid input devices, but also enhances the robustness and future compatibility of the interaction control module at the architectural level, providing a reliable technical foundation for the increasingly prevalent multimodal input hardware environment. Attached Figure Description

[0017] To more clearly illustrate the technical solution of this application, some embodiments of this application will be described in detail below with reference to the accompanying drawings, in which: Figure 1 A flowchart illustrating an interactive control method for interface controls provided in an embodiment of this application; Figure 2 A flowchart illustrating a method for simulating pressing motion effects in a given scenario, provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an interactive control device for interface controls provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Some embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0020] Figure 1 A flowchart illustrating an interactive control method for interface controls provided in this application embodiment is shown. The process includes the following steps: S101: Get the interaction event data of movable controls in the interface.

[0021] In this example, a movable control refers to an interactive visual element in a graphical user interface that responds to touch and pointer device events and allows the user to perform continuous displacement by directly dragging it. The movement range of a movable control needs to be constrained.

[0022] It's important to clarify that touch operation refers to users clicking and swiping on a touchscreen using their fingers or a stylus. Pointer devices refer to users dragging directly. Touch operation means there's a direct spatial mapping between the user's focus and the visual feedback of the control. That is, when a user grasps a control or a specific part of it (such as a slider) with their finger or pointer, they immediately see that part move with their input device (finger or cursor), conforming to the WYSIWYG (What You See Is What You Get) direct control principle. Continuous displacement means that within a complete interaction cycle from the start of pressing to the end of releasing, the visual position of the control updates continuously and in real-time according to changes in the input coordinates.

[0023] Movable controls are diverse in form and function. For example, movable controls can be types such as track sliders, virtual controllers, directly manipulated objects, view controls, and authoring tool handles. Track sliders can include switches, adjustment bars, range selectors, etc.; virtual controllers can include game joysticks, simulated steering wheels, etc.; directly manipulated objects can include draggable windows, sortable list items, desktop icons, etc.; and view controls can include navigation viewports on maps, etc. Authoring tool handles can include control handles for adjusting curves in drawing software, and scaling and rotation anchor points for graphic objects.

[0024] It should be noted that switch components are used to toggle between two or more discrete states. Examples include power switches and mode switches. Adjustment components are used to adjust the value or intensity within a continuous range or a series of discrete levels. Examples include timeline playheads, volume controls, screen brightness controls, and temperature settings. The timeline playhead is a core, visual progress adjustment and indication control in multimedia applications such as audio / video players and editing software. Users can drag it directly to continuously and precisely set or jump to a specific point in the audio / video content. A range selector is an interactive component consisting of two independent movable sliders, which typically slide on the same track, representing the start and end values ​​of a continuous value range (such as price, date, age, or time). Users drag these sliders to set a desired range. The navigation viewport can be a rectangle appearing on a map; dragging the rectangle pans the main view. Curve handles are used to adjust the shape of a Bézier curve path. The scaling and rotation anchor points of a graphic object are control points on the object's border. Dragging the scaling anchor point adjusts the object's size, and dragging the rotation anchor point changes the object's angle.

[0025] Additionally, for movable controls, event listeners of different event types can be bound simultaneously. The runtime environment automatically instantiates and obtains interaction event data based on the event listeners when they detect input device actions. For example, when a user's finger touches the touchscreen, the browser creates a TouchEvent object; when the user moves the mouse, a MouseEvent object is created.

[0026] Based on this, we can obtain native data objects distributed by the system by registering event listeners of different event types for movable controls.

[0027] It should be noted that interactive event data is a structured data object that is generated and transmitted in real time in response to user physical operations on movable controls in the graphical interface. Interactive event data includes event type, target element, timestamp, and coordinate information.

[0028] Specifically, event types include strings identifying the interaction phase, such as `touchstart` and `mousedown` for start, `touchmove` and `mousemove` for move, and `touchend` and `mouseup` for end. The target element identifies which UI element the interaction initially occurred on. A timestamp records the time the event occurred. Coordinate information is stored differently in different event types. For example, in `TouchEvent`, coordinates are stored in the `clientX` and `clientY` properties of the `Touch` object in the `touches` or `changedTouches` list. In `MouseEvent`, coordinates are directly stored in the `clientX` and `clientY` properties of the event object.

[0029] S102: Using the path priority fallback logic in the coordinate unification abstraction layer, select the coordinates corresponding to the interactive event data to extract the path and output the event coordinates.

[0030] In this example, the coordinate unification abstraction layer sits between the raw device events and the upper-level interaction logic. It transforms input coordinates from different event models and data structures into unified, device-independent, standardized coordinate outputs. That is, regardless of whether the user touches or clicks the slider, the resulting raw event data will first flow into the coordinate unification abstraction layer.

[0031] The path priority backoff logic is an algorithm that attempts to extract coordinates from event data according to a preset priority order. Its core components are sequential attempts and conditional backoff. Specifically, if a coordinate extraction path in one sequence is invalid, it backoffs to the second sequence of coordinate extraction paths and continues to check for validity until a valid coordinate extraction path is obtained, at which point the backoff stops. In other words, the coordinate values ​​corresponding to the first valid coordinate extraction path are used as the output.

[0032] It should be noted that the preset priority order is determined based on technical analysis of the data reliability of different event models in real-world scenarios, ensuring that a unified event coordinate can be extracted with the highest reliability when any interactive event is triggered. That is, a unified event coordinate can be extracted in cross-platform (such as mobile and desktop) or mixed input environments (such as devices that support both touchscreens and mice).

[0033] The coordinate unification abstraction layer can be a utility function, module or class encapsulation, state machine or strategy pattern, or configurable or declarative rule.

[0034] In this framework, a utility function is an independent function containing conditional statements and return values. Module or class encapsulation encapsulates the fallback logic within a separate coordinate processing module or class, providing a unified method to the outside world. The state machine or strategy pattern defines each extraction path as an independent strategy object, with a context object activating these strategies sequentially based on event type. Configurable or declarative rules define priority order in a configuration table or rule set, executed by a generic interpreter.

[0035] Event coordinates are used to numerically represent user interaction points within the interface. These event coordinates are represented using viewport coordinates, which have their origin at the top-left corner of the currently visible application window or browser content display area. Their coordinate values ​​are unaffected by document scrolling. This coordinate system ensures consistency between the interactive positioning of movable controls and the user's visual focus and operational perception.

[0036] For example, toggle slider controls are typically fixed in a specific layout position on the interface (such as the top bar or sidebar). When a user drags it, they expect the slider to move within this currently visible fixed area (track). Viewport coordinates provide a stable description of the slider's position relative to this visible track, unaffected by scrolling of other parts of the page. Furthermore, the movement of a finger or mouse cursor on the screen is perceived by the user as movement relative to the current window. Viewport coordinates directly reflect this perception, making the experience more natural. Moreover, whether on a small mobile screen or a large desktop window, control interactions occur within the currently visible area, and viewport coordinates provide a unified way of describing this.

[0037] S103: Update the interaction state of the movable control based on the event coordinates.

[0038] In this example, event coordinates are transformed into a series of internal state variables that drive the logic and visual performance of the movable control. Interaction state refers to the dynamic data set maintained internally by the movable control throughout its lifecycle in response to user actions, used to drive logical decisions and visual feedback. It comprehensively depicts the interaction situation and logical context of the movable control at any given moment. The state set can include interaction behavior state, spatial location state, and business logic state.

[0039] It's important to clarify that interactive behavior state refers to the identifying stage of the interaction. Examples include the press stage, the continuous drag stage, and the release stage. Spatial position state refers to a quantitative state calculated based on event coordinates, used to describe the spatial position change of a control within the visual area. It directly and continuously reflects the drag distance since the initial press, i.e., the displacement offset. Business logic state refers to the business logic result represented by the control, representing the intended outcome of the user's interaction. For example, the on / off state value.

[0040] S104: Based on the interaction state, control the visual rendering of the movable control.

[0041] In this example, rendering control refers to a series of processes that modify the style properties of movable controls and trigger animations according to predetermined strategies. These modifications are interpreted and executed by the browser or graphics engine, ultimately generating the pixel changes perceived by the user.

[0042] For example, the position of a movable control can be determined based on its spatial location state, the visual strategy to be applied (such as pressed or released state) can be determined based on its interaction behavior state, and the theme color and final position of the movable control can be determined based on its business logic state.

[0043] Based on this, by rendering and controlling the visual properties of movable controls, corresponding animations, position movements, or state transitions are generated on the screen.

[0044] It should be noted that, although the embodiments in this application are based on... Figure 1 Steps S101 to S104 will be described sequentially, but this does not mean that steps S101 to S104 must be performed in a strict order. The reason this embodiment follows this order is... Figure 1 The order in which steps S101 to S104 are described is provided to facilitate understanding of the technical solutions of the embodiments of this application by those skilled in the art. In other words, in the embodiments of this application, the order of steps S101 to S104 can be appropriately adjusted according to actual needs.

[0045] pass Figure 1 This paper proposes a system-level unified interaction control method. At the upstream of interaction data processing, heterogeneous touch events and pointer device events are unified with the same coordinates, so that all subsequent logic is based on the same data. In addition, combined with the centralized management of the interaction state and state-based rendering control, it ensures that the operation responsiveness, judgment logic, animation feedback and final result perceived by the user are exactly the same, whether it is touch, mouse or other pointer device, fundamentally eliminating the problem of cross-platform interaction experience fragmentation.

[0046] Therefore, in existing technologies, although controls often listen to multiple types of events simultaneously to achieve cross-platform compatibility, their processing logic branches out at the source of coordinate extraction, essentially resulting in multiple sets of parallel logic. This makes it difficult to guarantee consistency in judgment accuracy, response timing, and animation feel across devices. This application aims to introduce a unified coordinate abstraction layer to normalize multi-source inputs into standard coordinates, and build a unified state judgment and animation rendering engine based on this. This evolves multiple sets of parallel logic into a single logic that processes cross-platform input, ensuring that users receive a completely consistent and highly accurate interactive experience on any input device.

[0047] Furthermore, the interactive control flow is an abstract framework. The unified coordinate abstraction layer can adapt to new input devices in the future, its set of interactive states can be expanded to accommodate more dimensions of interactive information, and its rendering control strategy can be configured with different animation curves and visual themes. This design allows this method to serve as a basic model, widely applicable to various interface elements that require direct drag-and-drop manipulation.

[0048] Furthermore, existing technologies either only implement touch event logic on mobile devices and only implement mouse event logic on desktop devices, or implement both touch and mouse event logic on the same device. This makes them unsuitable for mixed-use scenarios with multiple input devices (such as laptops with touchscreens and 2-in-1 tablets). Because users may use touch and mouse operations alternately or simultaneously, existing solutions either cause one input method to fail due to the lack of event listeners, or cause event conflicts, response confusion, or inconsistent visual feedback due to the parallel operation of two independent logic sets.

[0049] This application achieves an input device-insensitive interaction kernel by unconditionally and simultaneously listening to touch and pointer device events and performing real-time unified processing of all inputs through a coordinate unified abstraction layer. This means that the system's processing of interaction events does not depend on the prediction of device type, but only on whether the event itself has occurred. Therefore, even on a single device, users can freely and seamlessly switch between finger touch and mouse click operations, and the system can provide completely consistent, continuous, and stable interactive responses, state determinations, and visual animations. This feature not only significantly improves the user experience on hybrid input devices, but also enhances the robustness and future compatibility of the interaction control module at the architectural level, providing a reliable technical foundation for the increasingly prevalent multimodal input hardware environment.

[0050] based on Figure 1 In addition to the method described herein, this application also provides some specific implementation schemes and extension schemes of the method, which will be further explained below.

[0051] In one example, selecting the coordinate extraction path corresponding to the interactive event data through the path priority fallback logic in the coordinate unification abstraction layer may include the following steps: First, according to a preset priority order, the system sequentially checks whether there are any available coordinate sources in the interactive event data that correspond to the current coordinate extraction path.

[0052] In this example, the system maintains a pre-defined list of coordinate extraction paths, which specifies the priority order of each path and its corresponding coordinate source type. The logic starts execution from the path with the highest priority in the list.

[0053] It should be noted that the coordinate source can be a list of active touch event points (such as the `touches` list in `TouchEvent`), a list of changed touch event points (such as the `changedTouches` list in `TouchEvent`), or a standard pointer device coordinate attribute source (such as the `clientX` and `clientY` attributes in `MouseEvent` or `PointerEvent`). The active touch event point list includes information on all touch points on the screen. Even if the active touch event point list doesn't include recently left touch points, the changed touch event point list can still provide the final coordinates of that touch point, ensuring reliable coordinate acquisition even during the touch termination phase. The standard pointer device coordinate attribute source refers to the standardized pointer device coordinate attributes in the interaction event data.

[0054] Available coordinate sources refer to specific attributes or data structures within the interactive event data object that conform to the current path detection rules and can provide valid coordinate values. Availability is determined by the predefined detection logic for that path. For example, checking attribute existence and non-emptiness.

[0055] Therefore, for the currently active coordinate extraction path, the system executes the corresponding availability detection rules. For example, for the active touch event point list source path, the detection rule is to check if the event object's `touches` property exists and if its length is greater than 0. For the change touch event point list source, the availability detection rule is to check if it has a `changedTouches` property and if its length is greater than 0. For the pointer device standard coordinate attribute source, the availability detection rule is to check if the event object has a `clientX` property and if its value is a valid numeric value (e.g., not `undefined`, `null`, and a number type).

[0056] It should be noted that the priority order of paths can be configured based on the mainstream input devices of the target operating environment, performance considerations, or compatibility requirements. This reflects flexibility. For example, in a mobile-first environment, it can be configured as a source of active touch points, a source of changed touch points, and a source of standard coordinate attributes for the pointer device to optimize touch operation response. In a desktop-first or hybrid device environment, it can be configured as: a source of standard coordinate attributes for the pointer device, a source of active touch points, and a source of changed touch points.

[0057] Based on this, regardless of the specific path order configuration, the following can be achieved: internally, providing an absolutely unified coordinate interface to the upper layer, completely shielding input device differences; externally, forming a completely consistent interaction decision basis on the user side. Different order configurations may only differ in internal search efficiency, but do not affect the final interaction consistency.

[0058] If it exists, extract the coordinate value from the coordinate source of the current coordinate extraction path, use the coordinate value as the event coordinate, and terminate the detection of the next priority coordinate extraction path.

[0059] In other words, if the detection is successful, the system extracts the coordinate values ​​from the coordinate source corresponding to the path and outputs these coordinate values ​​as event coordinates. After this, the logic terminates immediately and no longer detects or attempts any subsequent paths in the list.

[0060] For example, the method for extracting the coordinates of the source path of the active touch event list could be to read the clientX or clientY attribute value as the output coordinates from a fixed index (e.g., the first element) of the touchches list. The method for extracting the coordinates of the source path of the changed touch event list could be to read the clientX or clientY attribute value as the output coordinates from a fixed index (e.g., the first element) of the changedTouches list. The method for extracting the coordinates of the source path of the pointer device standard coordinate attribute could be to directly read the clientX or clientY attribute value of the event object as the output coordinates.

[0061] Based on this, after successfully extracting the coordinate values, the system proactively exits the aforementioned detection loop and ceases performing any operations on the remaining paths in the list. This optimizes performance and ensures the determinism of the output coordinates (i.e., they only come from the first successful path).

[0062] If the coordinates do not exist, the process will fall back to the next priority coordinate extraction path and repeat the detection and extraction steps until the coordinates are extracted.

[0063] In this context, "rollback to the next priority" means that if the current coordinate extraction path fails, the control flow unconditionally jumps from the current coordinate extraction path to the next highest priority path in the list and begins executing the detection logic for that path. That is, if the detection fails, the current coordinate extraction path is marked as unavailable. The system automatically rolls back, switches the active state to the next highest priority path in the list, and repeats the above detection and coordinate value extraction process.

[0064] It should be noted that if all preset paths in the complete list have failed to be traversed, an error will be reported. In real-world scenarios, by designing a well-structured path list, it can be ensured that the logic can always successfully extract coordinates and will not enter a state of complete failure.

[0065] In summary, by using a well-encapsulated logic unit, upper-level callers (such as state update logic) do not need to know whether the current operation is a touch or a mouse operation. They can always obtain a coordinate value extracted by the same set of rules, completely shielding device differences.

[0066] Specifically: By explicitly defining a closed loop for successful termination and failure rollback, all possible execution branches are covered, ensuring that behavior is deterministic and predictable under any input. The short-circuit termination mechanism avoids unnecessary attribute checks and function calls, effectively reducing performance overhead, especially in high-frequency movement event handling. Even if the event model is expanded in the future, only new detection paths need to be added to the path list without modifying the core loop logic, demonstrating good open / closed principles and scalability.

[0067] In one example, selecting the coordinate extraction path corresponding to the interactive event data through the path priority fallback logic in the coordinate unification abstraction layer may include the following steps: First, check if there is a usable first-level coordinate source in the interaction event data.

[0068] If it exists, extract the coordinate values ​​from the first-level coordinate source.

[0069] If not found, fall back to the next priority level to check if a usable second-level coordinate source exists in the interaction event data.

[0070] If it exists, extract the coordinate values ​​from the second-level coordinate source.

[0071] If not found, fall back to the next priority level to extract coordinate values ​​from the third-level coordinate source available in the interaction event data.

[0072] It should be noted that the first-level coordinate source can be the list of active touch points, the second-level coordinate source can be the list of changed touch points, and the third-level coordinate source can be the pointer device standard coordinate attribute source.

[0073] Therefore, when the checks at the first two levels fail (meaning the event is not a touch event or cannot be extracted from touch properties), the system falls back to the third level. This ensures that input from pointing devices such as mice and touchpads can be processed ultimately and uniformly.

[0074] In this example, the availability detection of the first-level coordinate source includes: determining whether the event object has a touches property and whether the length of the list is greater than 0.

[0075] The availability check for the second-level coordinate source is a fallback when the first level is unavailable. This includes checking whether the event object has the changedTouches property and whether the length of the list is greater than 0.

[0076] The availability check of the third-level coordinate source is the final fallback when the current two levels are unavailable. Since clientX is a standard property, its availability is usually directly reflected by the existence of the property (which is guaranteed for compliant pointer events).

[0077] It should be noted that when a user touches and drags a specific movable control, starting from the touchstart event, the browser establishes an interaction event flow targeting that control. In this event flow, although the touches list may contain multiple touchpoints, its first element is consistently associated by the browser as the primary touchpoint controlling the control during this interaction session. Each time a touchmove event is triggered, the coordinates read from touches[0] represent the latest position of the finger. Therefore, continuously obtaining coordinates from touches[0] allows for stable tracking of the position corresponding to the control being manipulated.

[0078] In summary, the above architecture explicitly defines the coordinate extraction process as a deterministic algorithm with three preset levels, attempting sequentially until success is achieved. Once the detection rules for a coordinate extraction path are satisfied (i.e., a usable coordinate source is found), the extraction method for that path is immediately used to output the coordinates.

[0079] In one example, in existing mobile devices and user interfaces, switch components (such as sliders and toggle buttons) commonly employ two interaction modes: click-to-switch and drag-to-switch. However, when the interface supports both click and drag, the system struggles to accurately distinguish whether the user's intention is to quickly click to switch states or to initiate a drag operation, easily leading to false triggers. Existing solutions typically use fixed time thresholds for differentiation, which cannot adapt to different user operating habits or interaction needs in different scenarios. During the waiting period to determine the user's intent (such as whether the waiting time threshold has been exceeded), the system cannot provide immediate feedback, resulting in slow interaction response and a poor user experience.

[0080] Based on this, when the movable control is a switch component and the interaction state is a control interaction behavior, updating the interaction state of the movable control based on the event coordinates may include the following steps: First, based on the difference between the event coordinates and the initial press coordinates, calculate the displacement offset of the current interaction behavior relative to the movable control.

[0081] If the absolute value of the displacement offset is less than the first preset displacement threshold, the current interactive behavior is determined to be a click operation, and the control state switch is triggered.

[0082] In this example, the first preset displacement threshold can be set statically or dynamically adapted. For example, when set statically, a standard empirical value (such as 10-15 physical pixels) can be set based on ergonomic experimental data to balance accidental touches and recognition sensitivity.

[0083] The dynamic adaptation generation method can be as follows: Based on control size: The threshold can be proportionally related to the visual size of the control (such as the slider diameter) (e.g., the threshold is 10% of the slider width).

[0084] Based on user habits: The system can learn from the historical operation data of a specific user and slightly adjust the standard experience value to adapt to the fluctuation of their operation.

[0085] Based on device accuracy: a smaller threshold can be used on high-precision touchscreens or pointer devices, and a larger threshold can be used on lower-precision devices to adjust the standard empirical value.

[0086] It should be noted that triggering a control state switch means inverting the control's state. For example, switching from off to on.

[0087] If the absolute value of the displacement offset is greater than or equal to the first preset displacement threshold, it is determined that the current interactive behavior belongs to the drag operation stage, so as to control the movable control to follow the touch point.

[0088] In summary, in the early stages of interaction, based on precise displacement offset calculations, click and drag intentions are distinguished in real time, and distinct state update paths are executed accordingly, specifically as follows: It can accurately distinguish between click and drag intentions in the very early stages of a user's finger movement (with only a few pixel displacements), greatly reducing judgment delays and ambiguities, and achieving accurate and rapid intent recognition. It fundamentally solves the logical conflict between click and drag operations on the same control, making the two interaction modes clear, independent, and non-interfering.

[0089] Once a click is detected, the high-frequency coordinate monitoring or rendering calculations that are preparing for dragging can be terminated in advance, saving system resources.

[0090] Because of its rapid judgment, the system can enter the correct feedback path with almost no delay (such as immediately switching states or starting smooth following), significantly improving the responsiveness and intuitiveness of the interface. Furthermore, it aligns with user intuition (tap with a slight movement, drag with a swipe), and the operation results are predictable, reducing learning costs and error rates, making the interaction more natural and fluid. It also provides adjustable judgment tolerances for users with mobility impairments or varying degrees of operational precision, making the controls easier to operate.

[0091] In one example, in existing mobile applications and user interfaces, the interactive feedback of track slider type controls is usually limited to position movement and simple state switching, lacking a high-fidelity interactive experience that can simulate the pressing texture of the real physical world.

[0092] Figure 2 This is a flowchart illustrating a method for creating realistic motion effects in a pressed state within a given scenario, as provided in an embodiment of this application. Based on this, when the movable control is a track slider type, controlling the visual rendering of the movable control based on the interaction state may include the following steps: S201: In response to detecting an initial press operation on the movable control, inject a dynamic buffer style into the visual element of the movable control, and establish a calculation relationship between at least one variable visual style parameter of the dynamic buffer style and the displacement offset of the movable control; the visual style parameter is used to simulate the visual indentation sensation.

[0093] In this example, the trigger condition could be detecting a touchstart event or mousedown event for a movable control.

[0094] Dynamic buffer styles are a set of visual rules that are bound to the interaction state and whose parameters can be calculated in real time. Dynamic buffer styles include styles that provide compressible buffer space (such as increasing padding and size). Styles that only provide visual indentation feedback (such as only changing the inner margin distribution, shadow, color, and slight deformation, without reserving a clear space that can be compressed) and styles that provide other realistic effects (such as simulating material stretching, gloss changes, etc.).

[0095] The calculation relationship refers to the mapping rule between displacement offset and visual style parameter values. It should be noted that the calculation relationship between displacement offset and visual style parameter values ​​may differ for different operating states of a movable control or even for the same operating state.

[0096] The visual style parameters for dynamic buffer styles can include layout properties, geometric properties, and appearance properties. Layout properties include padding and margins. Geometric properties control the physical shape changes of controls, including size (width, height), scaling (horizontal, vertical scaling), and shape (rounded corners, skewing, distortion). Appearance properties control the texture and depth changes of controls, including shadows (blur, size, color), borders (thickness, color, style), and background / filters (color, blur, brightness).

[0097] For example, for a circular slider, the following compressible buffer space pattern can be used for simulation: A sense of indentation is created by increasing the inner margin. The inner margin of a slider refers to the fill distance between the core visual content area and the outer visible boundary within the slider's visual components.

[0098] The core visual content area may include the slider's icon, text, a central area with a fixed texture or background color. The visible boundary is the outermost outline of the slider as seen by the user. The fill distance refers to the space between the edge of the content area and the outer boundary. In a graphical interface, this space is typically filled with solid colors, gradients, or transparent pixels.

[0099] When the initial press operation is initiated, adding padding to the slider (e.g., by modifying CSS padding) causes a shift in the visible outer edge of the slider, while the core visual content area remains unchanged, thus altering the overall display size of the slider. For example, when swiping right, the right margin is increased; when swiping left, the left margin is increased.

[0100] During drag-and-drop operations, the inner margin is bound to the displacement offset and dynamically calculated.

[0101] It should be noted that the increased inner margin can remain constant, translating with the displacement until the release operation. Alternatively, it can change, producing deformation related to the drag direction and distance, as shown below: The padding initially remains constant, then dynamically decreases as the user approaches the drag boundary until the release operation. Alternatively, it initially decreases dynamically as the displacement offset increases, then dynamically decreases as the user approaches the drag boundary until the release operation. That is, if there is a relative delay in the user's release, the padding may have already decreased to 0. Or, it may decrease dynamically as the displacement offset increases until the release operation.

[0102] It should be noted that the dynamic buffer style will be removed when the user releases the movable control.

[0103] In addition, a sense of indentation can be created by directly changing the width.

[0104] Upon initial press, the slider's width property instantly increases from its original value (e.g., 60px) to a base deformation value (e.g., 65px). This simulates the initial state where the control's material is uniformly flattened and slightly bulges laterally when the fingertip first touches it.

[0105] During dragging, the width parameter is bound to the displacement offset and dynamically calculated.

[0106] It should be noted that the increased width can remain constant, shifting with the displacement until the release operation. Alternatively, it can be changed, as follows: As the displacement increases until the operation is released, for example, when dragging to the right: as the rightward displacement increases, the width value continues to dynamically increase from the base deformation value at the time of pressing (65px) (e.g., eventually increasing to 90px). Simultaneously, its height can remain constant or slightly decrease to maintain the illusion of visual area conservation. This simulates the continuous compression and accumulation of material on the slider in the direction of movement (to the right), causing it to widen horizontally and slightly flatten vertically, like a soft object being pushed from one side.

[0107] For example, for a circular slider, the following style can also be used to simulate the indentation effect by providing only visual feedback: The feeling of indentation is created by adjusting the distribution of inner margins. Upon initial press, the inner margins are increased evenly in all directions while the overall display size of the slider remains constant. This causes the core visual content area to shrink instantly, while the outer visual boundaries (such as background color blocks) expand outwards, creating a visual effect of being pressed inwards and having bulging edges.

[0108] During drag-and-drop operations, the inner margin is bound to the displacement offset and dynamically calculated.

[0109] It should be noted that the inner margin distribution can remain constant, shifting with the displacement until the release operation. Alternatively, it can change.

[0110] For example, based on the direction and magnitude of the displacement offset, the inner margin distribution of the control in the drag direction can be dynamically adjusted, decreasing the inner margin on one side and increasing it on the other, simulating compression and stretching in the drag direction. For instance, when dragging to the right: the right inner margin gradually decreases from a base value of 10px to 0px, while the left inner margin gradually increases from 10px to 20px. The circular content area shifts to the right within the slider's visual boundary, making the right side appear compressed and dense, while the left side appears stretched and sparse, thus simulating continuous compression deformation in the drag direction and enhancing the sense of direction and force during dragging.

[0111] The tilt creates a sense of pressure. An initial tilt angle is applied to the slider upon initial pressing. This simulates the minute, instantaneous distortion of an object when the point of force is not at its absolute center, enhancing the realism of the pressing sensation.

[0112] When dragging and moving, the tilt angle is bound to the displacement offset and dynamically calculated.

[0113] It should be noted that the tilt angle can remain constant, shifting with the displacement until the release operation. Alternatively, it can change, resulting in deformation related to the drag direction and distance.

[0114] For example, as the rightward displacement increases, the tilt angle dynamically increases from the initial (2 degrees when pressed) (e.g., eventually increasing to 15 degrees), resulting in a rightward tilt. This simulates the right side being pushed and deformed, causing the slider to tilt and twist, much like the deformation of a flexible object in the direction of force.

[0115] Create a sense of indentation through shadows. Upon initial press, replace the slider's original soft shadow with a larger, blurrier projection (e.g., increase the blur radius from 4px to 12px). This simulates the physical optics effect of the shadow beneath an object expanding and fading due to the force spreading as it is pressed down, creating an initial sense of depth.

[0116] During drag-and-drop operations, the shadow parameters are bound to the displacement offset and dynamically calculated.

[0117] It should be noted that the shadow parameters can remain constant, shifting with the displacement until the release operation. Alternatively, they can change, resulting in deformation related to the drag direction and distance.

[0118] For example, the blur radius and diffusion range parameters of the projection are bound to the displacement offset and dynamically calculated. As dragging continues, the blur radius of the shadow dynamically decreases (e.g., from 12px to 2px), while the vertical offset of the shadow may decrease and the color may darken. This simulates the feeling of space between a control and the background decreasing when the control is pressed down, as if it is being pushed into the bottom of the interface, thus reducing the visual height.

[0119] It should be noted that the injection process can involve adding a specific CSS class to the DOM element of a movable control, which defines style properties related to the indentation effect.

[0120] In addition, in the view model or state management corresponding to the movable control, initialize a flag bit and related style parameter calculation functions to establish calculation relationships.

[0121] In this example, the injected dynamic buffer style can be the slider's inner margin, as shown below: Increase the inner margin of the slider in the expected sliding direction to increase the displayed size of the slider in the expected sliding direction.

[0122] Based on this, the overall display width of the slider is increased, visually appearing as if the slider is expanding to the right or bulging when pressed. This visual effect simulates the deformation that occurs when a physical button is pressed, providing the user with clear feedback confirming the operation.

[0123] During the dragging and dropping of a movable control, the increased inner margin remains constant as the movable control is translated.

[0124] Therefore, by keeping the inner margin constant, visual interference and performance overhead caused by the continuous change of slider size during dragging are avoided, allowing users to focus on controlling the slider position and making the operation more stable and precise.

[0125] S202: In response to detecting a drag-and-drop operation on a movable control, calculate the corresponding visual style parameter value based on the calculation relationship and the displacement offset.

[0126] In this example, the trigger condition could be detecting a pointermove or touchmove event during the duration of the press state.

[0127] S203: Remove the dynamic buffer style in response to detecting a release operation on a movable control.

[0128] In this example, the trigger condition could be detecting a touchend event or a mouseup event. The removal process could be removing the CSS class or resetting all dynamically calculated style properties to null.

[0129] It's important to note that, to provide a smooth experience, this process is not instantaneous; instead, it triggers a recovery animation. For example, the CSS transition property allows the flattened slider to gradually return to its original circular shape using an ease-out easing curve.

[0130] pass Figure 2 The method binds visual style parameters with displacement offset in real time, making the degree of deformation of the control precisely correspond to the force and direction of operation, providing a delicate texture that traditional simple animations cannot achieve.

[0131] Furthermore, the method for achieving the indentation feel is encapsulated as an independent dynamic buffer style object, whose calculation relationships can be configured or injected via functions. Adjusting these calculation relationships changes the feel without requiring developers to rewrite the interaction code.

[0132] Furthermore, in the drag event loop, each coordinate update synchronously triggers parameter calculation and style rendering. Each frame only needs to perform a preset calculation relationship based on the displacement offset and update a small number of style parameters, avoiding the performance overhead of complex physical simulation, minimizing the computational overhead, and ensuring high smoothness on mobile devices.

[0133] In summary, a lightweight, mathematically mapped, dynamic calculation system for visual parameters enables high-quality skeuomorphic interaction within a general UI framework. This provides a new foundational capability for mobile interaction design, making high-quality interaction a standard solution for scalable applications.

[0134] In one example, in existing graphical interfaces, when a slider is dragged by the user to the edge of the track, the movement typically stops abruptly, lacking a transition, especially for toggle controls. This rigid boundary experience does not conform to the mechanical perception of the physical world, which may lead to abrupt interactive feedback and reduce the smoothness of the user experience.

[0135] Based on this, when the dynamic buffer style is configured as a compressible buffer space style, controlling the visual rendering of the movable control based on the interaction state may include the following steps: First, in response to the detection of a dragging operation on the movable control, when the displacement offset reaches a preset convergence threshold close to the dragging boundary, the movable control is controlled to enter the boundary compression stage.

[0136] In this example, the convergence threshold can be configured based on the control track length, visual design, or user experience goals. For example, it can be set to 3-7 logical pixels from the drag boundary. Once this condition is met, the movable control immediately enters the boundary compression phase. This triggering mechanism divides the continuous dragging process into two distinct sub-phases: an unconstrained following phase and a boundary-constrained compression phase.

[0137] It's important to note that when the displacement offset reaches the convergence threshold, it means the movable control is sufficiently close to the drag boundary. The drag boundary is the endpoint where the slider will eventually bounce back and stabilize after the user releases it. It's typically located at a slight offset inside the visual boundary. For example, for a toggle control with a 100px long track, the drag boundary in the "on" state might be set at 90px, not the 100px visual endpoint. Thus, after release, the slider will bounce back to this logical endpoint of 90px.

[0138] Then, during the boundary compression phase, the display position of the movable control is no longer controlled to move with the touch point coordinates.

[0139] In this example, although the user's fingertip or cursor is still trying to drag outwards from the boundary, the visual position of the control is locked near the location where the compression phase was triggered (typically the location corresponding to the convergence threshold). This behavior simulates the initial tactile sensation of an object coming into contact with a soft but resistive barrier, where movement is significantly slowed down and tends to stop.

[0140] Then, if the touch point is detected to remain within the response area of ​​the movable control, the buffer space of the movable control is compressed by dynamically reducing the visual style parameter value.

[0141] In this example, the response area typically refers to the hot zone of the device itself or the track area it is on. As long as the contact remains within this area, the system assumes that the user is still intentionally pushing and dragging the boundary.

[0142] From a visual perspective, the compression process is characterized by the gradual compression of the buffer space (such as the bulging inner margin and the horizontally expanded width) reserved for movable controls.

[0143] That is, the visual style parameter value of the movable control is dynamically reduced. The reduction process stops when one of two conditions is met: 1. The parameter value is reduced to 0 (i.e., the visual buffer space is completely compressed). 2. A release operation on the movable control is detected.

[0144] Finally, in response to detecting a release operation on the movable control, the movable control is controlled to bounce back to the drag boundary.

[0145] In this example, regardless of how much the visual style parameter value decreases during the boundary compression phase, it is immediately reset to its initial state before the bounce animation begins, and the dynamic buffer style is removed. This simulates the instantaneous shape recovery of the compressed object.

[0146] Specifically, the dynamic buffered styles injected into the control are removed, which means that all temporary deformations or styles caused by compression will be cleared.

[0147] Control the bounce of movable controls back to the dragged boundaries. The bounce process is typically achieved through a smooth animation. For example, the movable control moves from a compressed position to a precise boundary position with a flexible motion curve animation. This bounce animation not only provides a clear sense of completion but also enhances the certainty of the interaction and the dynamism of the interface by elegantly and vividly snapping the control to the correct final state.

[0148] In summary, when users drag movable controls towards the boundary, they first experience resistance to movement, and then perceive a gradual damping effect—a feeling of increasing effort as the control's visual style shrinks. This subtle and intuitive interactive feedback provides a clear and intuitive understanding. Furthermore, the dynamically compressed visual style clearly indicates to the user that the system has recognized the boundary intention and is processing the out-of-bounds operation, avoiding user confusion about interface responsiveness. Additionally, the bounce animation provides an elegant and definitive ending, precisely bringing the control back to the logical boundary while giving the interface a sense of life, significantly improving the smoothness and enjoyment of the interaction.

[0149] Furthermore, compressing the buffer space of the movable control by dynamically reducing the visual style parameter value can include the following steps: The buffer space is compressed according to a preset step-by-step compression rule; the step-by-step compression rule divides the compression process into multiple consecutive compression stages: Within each compression stage, the following steps are performed: Step 1: Compress the buffer space according to the compression rules corresponding to the current compression stage.

[0150] Step 2: Based on the displacement conversion relationship corresponding to the current compression stage, convert the compression amount of the buffer space into the corresponding buffer displacement amount to control the movement of the display position of the movable control.

[0151] It should be noted that in at least two consecutive compression stages, the amount of buffer displacement generated per unit compression decreases as the degree of compression increases.

[0152] That is, by exhibiting a decaying characteristic, the rate of increase of the system's output (displacement) is slower than the rate of increase of the input (compression), or the amount of displacement that can be exchanged for a unit of compression decreases, thus generating a sense of resistance. Therefore, by setting the transition relationship between each compression stage, the user's perceived operating resistance can increase as the degree of compression deepens.

[0153] In other words, the buffer displacement calculated from the compression amount is no greater than the compression amount itself. This conversion ratio changes throughout the compression process. That is, the buffer displacement per unit compression decreases at different compression stages, accurately simulating the physical damping sensation of increasing effort as compression progresses.

[0154] Based on this, the buffer space is actively and gradually compressed according to preset rules, and the amount of compression each time is converted into a corresponding visual position movement, thereby simulating a damping sensation rather than passively responding to user displacement. By controlling the relationship between the amount of compression at different stages and the displacement conversion that produces visual displacement, a non-linear damping feel with light resistance at the beginning and heavy resistance at the end is accurately simulated.

[0155] It's important to note that the compression rule defines the fixed amount or calculation method by which the buffer space is compressed each time within this stage. For example, compressing by 1 pixel each time (reducing the visual style parameter value). The displacement transformation relationship defines how much buffer displacement should be converted per unit of compression within this stage. For example, compressing 1 pixel moves the control position by 1 pixel. The displacement transformation relationship determines the resistance perceived by the user. Because a smaller transformation ratio means that greater compression is required to produce a visible movement, the stronger the damping sensation.

[0156] In other words, within each compression stage, the system repeatedly executes the following steps until the stage termination condition is met: Apply compression: Perform a compression operation on the buffer space according to the current compression rules (such as subtracting 1 pixel from the visual style parameter value).

[0157] Calculate and move: Based on the displacement transformation relationship of the current compression stage, the current compression amount is converted into a buffer displacement amount, and the display position of the control is fine-tuned accordingly. This results in extremely slow displacement of the movable control.

[0158] In this example, taking an indicator ball with a buffer size of 15 pixels as an example, the progressive compression rule can be divided into three stages, reflecting the design of increasing resistance, as follows: The pixel range corresponding to the first compression stage is: The pixel range corresponding to the second compression stage is The pixel range corresponding to the third compression stage is .

[0159] The first compression stage is the initial light resistance stage. The compression rule in this stage is that each active compression is 1 pixel. The displacement conversion relationship is that for every 1 pixel compressed, this 1 pixel compression is completely converted into a 1 pixel buffer displacement, which moves the display position of the control slider 1 pixel in the drag direction.

[0160] Based on this, the compression-displacement efficiency at this stage is 1:1. When the user applies dragging force, the buffer space is quickly consumed, and the slider still moves to some extent with the hand, so the resistance feels lighter.

[0161] The second compression stage is the medium-damping stage. The compression rule in this stage is that each active compression is 1 pixel. The displacement conversion relationship is that for every 1 pixel compressed, this 1 pixel compression is completely converted into a 0.5 pixel buffer displacement, which moves the display position of the slider 0.5 pixels in the drag direction.

[0162] As a result, the compression-displacement efficiency drops to 1:0.5. Users need to continuously apply dragging force, and the visual displacement generated by the system with each compression is halved. Users need to make the system complete two compressions (i.e., exert twice the dragging effort) to produce the same visual displacement as in the first stage, thus significantly increasing the perceived resistance.

[0163] The third compression stage is the medium-damping stage. The compression rule in this stage is that each active compression is 1 pixel. The displacement conversion relationship is that for every 1 pixel compressed, this 1 pixel compression is completely converted into a buffer displacement of 0.33 pixels, which controls the slider's display position to move 0.33 pixels in the drag direction.

[0164] Based on this, the compression-displacement efficiency further decreases to approximately 1:0.33. Users need to exert greater force to drive the system to complete one compression and produce an extremely small positional movement, resulting in the strongest sense of resistance, vividly simulating the feeling of being pushed to the limit of compression.

[0165] In summary, a predictable and configurable virtual mechanics model was constructed, achieving accurate simulation of complex damping effects. Furthermore, the compression and displacement transformation relationships at each stage can be independently customized. This provides designers with significant flexibility, allowing them to easily design various tactile curves such as linear damping, exponential damping, and logarithmic damping without altering the core interaction architecture. Moreover, the entire model is based on predefined rules and simple arithmetic operations, avoiding complex real-time physics calculations and ensuring smooth rendering performance even under high-frequency touch events.

[0166] In one example, in existing technologies, key parameters of interactive controls (such as threshold values ​​and animation amplitudes) are often hard-coded directly as fixed pixel values. This can lead to threshold values ​​being too low and operations being overly sensitive and prone to accidental touches on high-PPI mobile devices, while it can lead to threshold values ​​being too high and operations being sluggish on low-PPI large-screen desktop devices.

[0167] Based on this, adaptive geometric transformation is performed on the baseline design pixel values ​​based on the operating environment parameters to obtain the preset displacement threshold parameters, preset convergence threshold parameters, and injected dynamic buffer style parameters in the interactive control process.

[0168] In this example, the baseline design pixel value refers to the value, expressed in physical pixels, determined within a specific baseline design environment (e.g., on a device with a logical width of 375px and a pixel density of 1x), upon which the interaction logic and visual design are based. For example, with a drag boundary of 26px, the threshold for distinguishing between click and drag is defined as 10px, the boundary compression convergence threshold as 22px, and the padding of the dynamic buffer as 5px.

[0169] Runtime environment parameters refer to the actual environment information of the device on which the application is currently running. These mainly include: Device pixel ratio: the ratio of physical pixels to logical pixels (CSS pixels). Viewport size: the width and height of the current visible area, usually represented by logical pixels or relative units. Root font size: the current calculated font size of the root element of the HTML document, which is based on rem units.

[0170] Based on this, upon reading the preset baseline pixel values ​​related to interactive control, the values ​​are converted into values ​​suitable for the current environment according to a preset conversion strategy. For example, conversion to viewport-relative units: suitable for parameters strongly related to screen width or height. This ensures that the parameter maintains the same proportional relationship on screens of different widths. Conversion to root font-relative units: suitable for parameters that need to scale with the user's font settings or maintain proportional consistency with the page layout. This guarantees parameter accessibility and compatibility with the layout system.

[0171] In summary, this ensures that core interaction logic such as click / drag judgment and boundary behavior triggering has completely identical physical operation tolerances and triggering conditions across different devices, achieving reliable interaction that is consistent across all devices with a single operation. This achieves consistency in interaction logic. Furthermore, the visual intensity of realistic animation effects (such as press depth and compression amplitude) is proportional to the rendering size of the controls themselves on different devices, maintaining a unified design language and high fidelity in the visual experience.

[0172] For example, a preset displacement threshold parameter is used to distinguish between click and drag intentions. After conversion, this threshold can maintain a consistent physical size perception across different devices, avoiding differences in misjudgment rates due to variations in screen resolution.

[0173] Preset convergence threshold parameter: The critical displacement value used to trigger the boundary compression phase. Adaptive transformation ensures that the concept of proximity to the boundary has a consistent spatial proportion across tracks of different sizes, so that the timing of damping triggering matches user expectations.

[0174] Injected dynamic buffer style parameters: Visual parameters used to generate realistic press effects (such as inner margins and deformation). Through transformation, the visual amplitude of the indentation appears proportionally consistent across different screens, neither too weak nor too exaggerated, maintaining a unified visual language and texture.

[0175] In one example, in modern graphical user interfaces, movable controls are often given various transition animation properties to enhance the visual experience (e.g., their position, size, or transparency smoothly changes over a specific time period when their state changes). However, when a user intends to directly manipulate the control by pressing and dragging, these pre-set animations present two main problems: the system may need to wait for the previous transition animation to complete before it can begin responding to a new drag command, resulting in a perceived delay in the start of the operation. During dragging, if the system simultaneously attempts to execute transition effects unrelated to the drag target's position (e.g., animations triggered by layout changes), the control's movement trajectory may become out of sync with the finger's movement, producing jitter or ghosting, disrupting the illusion of direct control that follows the finger's movement.

[0176] Based on this, controlling the visual rendering of the movable control based on the interaction state may include the following steps: In response to the detection of an initial press operation on the movable control, disable the transition animation properties of the movable control.

[0177] In this example, disabling the animation can be achieved by modifying the style of the control element or adding a specific CSS class to override the existing `transitionCSS` property. This operation is performed early in the event capturing or bubbling phase, ensuring that the animation is disabled before subsequent translation logic is processed.

[0178] In response to detecting a release operation on the movable control, restore the transition animation properties of the movable control.

[0179] In this example, the restore operation could be removing inline styles or specific CSS classes that were previously added to disable animations, restoring the transition property of the control element to its original value defined in the stylesheet.

[0180] In summary, the system immediately disables all tweening animations the moment the control is touched, ensuring strict synchronization between control movement and user movement without any interpolation delay, achieving zero-latency responsiveness. Furthermore, it prevents tweening animations from preempting dragging, ensuring an immediate, clear, and animation-free response. Additionally, smooth tweening transitions are enabled for movable components to converge to the drag boundaries. Restored animation properties make bounce animations smooth and natural, providing a clear sense of interactive completion.

[0181] In one example, in modern graphical user interfaces, especially in applications that support switching between dark and light themes, the visual design of toggle controls faces the following challenges: Color schemes for controls in light themes may lack contrast or exhibit semantic inconsistencies in dark themes, and vice versa. Changing colors solely based on state while ignoring the global theme can lead to controls clashing with the current interface theme, resulting in a lack of visual consistency. The on and off states of controls require clear and immediate visual differentiation. Furthermore, in the context of theme switching, fixed state colors may not provide optimal visibility across both themes. Hardcoding style values ​​for each state under each theme leads to code redundancy and requires multiple modifications when adding new themes or states, resulting in poor scalability.

[0182] Based on this, rendering control of the interaction state may include the following steps: First, respond to the detected interface theme parameters.

[0183] In this example, the interface theme parameter is a variable that indicates the current application or system-level visual mode. Typical values ​​are binary enumerations, such as light and dark, but can be expanded to include more themes (such as high contrast, color modes).

[0184] Then, based on the interface theme parameters and control logic state parameters, the target visual style parameters corresponding to the movable control are selected from the visual style parameter set.

[0185] In this example, the control logic state parameter is a variable that describes the core functional state of the control. For switch-type controls, the basic state is a binary enumeration, such as on (on / enabled) and off (off / disabled). This state can be extended to more granular interactive states, such as dragging and locked.

[0186] The visual style parameter set is a predefined, structured data storage object, such as a mapping table, configuration object, or key-value pair collection.

[0187] It's important to note that the key is a composite key consisting of both the theme parameter value and the logical state parameter value. For example, the key can be the strings "light:on" and "dark:off", or the object "{theme:dark, state:dragging}". The key value is the corresponding target visual style parameter.

[0188] Visual style parameters can be color values ​​(such as background color, border color, slider color), but they can also be any visually perceptible CSS or rendering properties such as size, transparency, and shadow. For example, the set of visual style parameters can include visual colors corresponding to four combinations: light theme - on, light theme - off, dark theme - on, and dark theme - off.

[0189] Based on this, the selection process can be as follows: using these two parameters as query conditions, perform exact matching or conditional matching within the set of visual style parameters. The matching process is an efficient search operation, rather than a complex calculation. For example, it can be done by directly indexing using a composite key, or by traversing the set to find the first item that satisfies the theme and state conditions. Upon successful matching, the corresponding target visual style parameters are output.

[0190] In summary, ensuring that the semantics conveyed by the state of a control are clearly expressed through visuals best suited to that theme, regardless of the theme, achieves cross-theme consistency in visual hierarchy. Furthermore, style logic is separated from business logic. All visual rules are centrally managed in a set of visual style parameters. When adding a new theme or state, only this set needs to be expanded; there is no need to modify the control's behavior logic.

[0191] In one example, taking a switch control as an example, the following problems exist in the prior art: Mobile and desktop devices have two event models: touch and mouse. Traditional switches often suffer from inconsistent coordinate acquisition and dragging being misinterpreted as a click or the opposite, resulting in false triggering.

[0192] The judgment threshold is coarse: it lacks the ability to distinguish between slight swipes and effective drags, resulting in switching states after short-distance swipes and a high rate of misoperation.

[0193] Lack of drag boundaries and bounce: The slider lacks strict limits and buffering strategies during dragging, making it easy to go out of bounds or jump abruptly, resulting in an inconsistent experience.

[0194] The mobile device lacks realistic pressing motion effects: the timing and motion effects of pressing / dragging / releasing are not decoupled in stages, and there is a lack of instantaneous zero-delay responsiveness and boundary damping simulation, resulting in animation preemption, visual disjointness and startup lag, and inconsistent pressing feel.

[0195] Visual and animation inconsistencies: The animation strategies for the press and release phases are not differentiated, resulting in tweening animation preemption during dragging, causing lag or delay.

[0196] Insufficient geometric adaptability: Dimensions and displacements are inconsistent across different device pixel densities / layout units, resulting in significant travel errors. Theme adaptation is incomplete: Light and dark themes and status colors are not managed in a unified manner, and color switching is delayed or inconsistent.

[0197] Therefore, for interactive control scenarios of interface controls, in order to solve the above problems, the relevant settings may include the following: System initialization: After the page loads, construct a rounded corner track (approximately 80×44) and a thumb slider (approximately 30 in diameter, initial left of 7px, translated using transform), using v-model. <boolean>Maintain state and expose click / change events; disabled is masked and weakened by pointer and opacity; prepare configurable active / inactive color parameters.

[0198] Unified events and coordinates: Bind touchstart / move / end and mousedown / mousemove / mouseup simultaneously and use .prevent to suppress native scrolling. Extract clientX (touches → changedTouches → mouse back) uniformly through getclientX(e). Use isPressed / startX / offsetX to manage the effective drag cycle.

[0199] Based on this, the problem of misjudgment and inconsistency caused by cross-platform event inconsistency can be solved.

[0200] Press-state realistic animation and drag: set isPressed=true onPress, record startX, disable transition (zero delay follow-through) and inject fitPXTOVW(15) dynamic buffer on the tail side to form indentation and subsequent damping. During the drag period, bind offsetX to the basic displacement and translate in real time to obtain the pressing feel that follows the finger.

[0201] For example, a phased animation strategy—disabling transitions (transition:none) during the press phase achieves zero-latency responsiveness; during the release phase, restoring the transform with 0.2s ease for smooth convergence, preventing the transition animation from preempting the dragging action. This can solve the problem of coupled press and release animations, resulting in discontinuous and sluggish dragging.

[0202] A tail-side dynamic buffer (paddingLeft / Right = fitPXTOVW(15)) is injected into onPress and bound to the displacement in real time to simulate indentation. The press phase has zero transition responsiveness, the drag phase is limited, and the buffer is removed and smoothly converged when released, so as to obtain low latency responsiveness during the press and damped feel at the drag boundary.

[0203] Based on this, the problem of insufficient realistic motion effects for pressing on mobile devices can be solved.

[0204] Judgment threshold and multi-segment limit: When releasing, offsetX>10 is used to determine opening, offsetX<-10 is used to determine closing, and the interval is regarded as click inversion. The drag displacement is limited to the upper limit of sumHtmlRem()*1.35417, and combined with the small threshold of 1.14583rem / 0.15625rem / 0.20833rem to suppress out-of-bounds and abrupt changes. Then, the buffer is cleared, transform is restored for 0.2s ease, and change(value) is triggered uniformly.

[0205] Based on this, the problems of false triggering and exceeding the limit during short-distance sliding can be solved, and the threshold can be combined to provide a damped feel when dragging the boundary.

[0206] Adaptive and theme-linked: Geometric dimensions and travel are adapted to different viewports and root font sizes via sumHtmlRem() / fitPXTOVW(), and the background color is jointly selected by modelValue×marioisnight as activeColorWhite / activeColorDark / inactiveColorWhite / inactiveColorDark to achieve consistent geometric performance and unified visual brightness / on / off status across devices.

[0207] For example, by using sumHtmlRem() and fitPXTOVW() to map pixels to rem / vw, adaptive calculation is achieved (e.g., 26px → 1.35417rem, 15px → fitPXTOVW(15)), ensuring consistent stroke across different resolutions / root fonts / viewports.

[0208] In switchStyle, a joint decision-making mechanism for theme and state is introduced: modelValue×marioisnight selects activeColorWhite / activeColorDark and inactiveColorWhite / inactiveColorDark, and parameterizes the colors as configurable props to achieve a unified and scalable visual presentation.

[0209] Based on this, the problems of inconsistent geometric representation under different devices and viewports, and the lack of linkage between theme (bright / dark) and status (on / off) color matching can be solved.

[0210] Based on this, in the initial press phase: when the press is detected, the tween transition animation of the movable part in the switch control is immediately disabled, and a lateral dynamic buffer style is injected into it to achieve a zero-delay responsiveness and visual indentation.

[0211] Drag phase: During the press duration, the displacement calculated based on unified event coordinates is bound to the movable part in real time, and the dynamic buffer is maintained. When approaching the drag boundary, the damping sensation is simulated by compressing the buffer space.

[0212] Release phase: Upon detecting the end of the press, remove the dynamic buffer style and enable a smooth tween transition animation for the movable part to converge to the drag boundary position.

[0213] In summary, based on unified cross-platform event coordinates, drag thresholds, and multi-segment limits, combined with realistic press-state animations (zero transition when pressed, buffered style, displacement binding), rem / vw adaptive design, and theme linkage, a highly consistent, low-misclick, and highly responsive switch interaction is achieved. In other words, starting from reliable interaction and consistent presentation, a universal UI switch control suitable for both mobile and desktop platforms is developed.

[0214] Based on the same idea, some embodiments of this application also provide devices and non-volatile computer storage media corresponding to the above methods.

[0215] Figure 3 A schematic diagram of the structure of an interactive control device for interface controls provided in this application embodiment includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform an interactive control method for a user interface control as described above.

[0216] Some embodiments of this application provide a non-volatile computer storage medium for interactive control of interface controls, which stores computer-executable instructions capable of executing any of the above-described interactive control methods for interface controls.

[0217] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and medium embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the description of the method embodiments.

[0218] The devices and media provided in this application are one-to-one with the methods. Therefore, the devices and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0219] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0220] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0221] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0222] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0223] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0224] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0225] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0226] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0227] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the technical principles of this application should fall within the protection scope of this application.< / boolean>

Claims

1. An interactive control method for interface controls, characterized in that, The method includes: Get the interaction event data of movable controls in the interface; By using the path priority fallback logic in the coordinate unification abstraction layer, the path corresponding to the interactive event data is extracted to output the event coordinates; Update the interactive state of the movable control based on the event coordinates; Based on the interaction state, control the visual rendering of the movable control.

2. The method according to claim 1, characterized in that, The method of using path priority fallback logic in the coordinate unification abstraction layer to select the coordinates corresponding to the interactive event data to extract the path and output the event coordinates specifically includes: According to a preset priority order, the system sequentially checks whether there is a usable coordinate source in the interactive event data that corresponds to the current coordinate extraction path; If it exists, extract the coordinate value from the coordinate source of the current coordinate extraction path, use the coordinate value as the event coordinate, and terminate the detection of the next priority coordinate extraction path; If the coordinates do not exist, the process will fall back to the next priority coordinate extraction path and repeat the detection and extraction steps until the coordinates are extracted.

3. The method according to claim 1, characterized in that, When the movable control is a switch component and its interaction state is a control interaction behavior, the interaction state of the movable control is updated based on the event coordinates, specifically including: Calculate the displacement offset of the current interaction behavior relative to the movable control based on the difference between the event coordinates and the initial press coordinates; If the absolute value of the displacement offset is less than the first preset displacement threshold, it is determined that the current interactive behavior is a click operation, and the control state switch is triggered. If the absolute value of the displacement offset is greater than or equal to the first preset displacement threshold, it is determined that the current interactive behavior belongs to the drag operation stage, so as to control the movable control to follow the touch point.

4. The method according to claim 1, characterized in that, When the movable control is a track slider type, the visual rendering of the movable control is controlled based on the interaction state, specifically including: In response to detecting an initial press operation on a movable control, a dynamic buffer style is injected into the visual element of the movable control, and a calculation relationship is established between at least one variable visual style parameter of the dynamic buffer style and the displacement offset of the movable control; the visual style parameter is used to simulate the visual indentation sensation. In response to detecting a drag-and-drop operation on a movable control, the corresponding visual style parameter value is calculated based on the calculation relationship and the displacement offset. In response to the detection of a release operation on a movable control, the dynamic buffer style is removed.

5. The method according to claim 4, characterized in that, When the dynamic buffer style is configured as a compressible buffer space style, the visual rendering of the movable control is controlled based on the interaction state, specifically including: In response to detecting a dragging operation on a movable control, when the displacement offset reaches a preset convergence threshold close to the dragging boundary, the movable control is controlled to enter the boundary compression stage. During the boundary compression phase, the display position of the movable control no longer follows the touch point coordinates; If the touch point is detected to remain within the response area of ​​the movable control, the buffer space of the movable control is compressed by dynamically reducing the visual style parameter value; In response to detecting a release operation on the movable control, the movable control is controlled to bounce back to the drag boundary.

6. The method according to claim 5, characterized in that, The buffer space of the movable control is compressed by dynamically reducing the visual style parameter value, specifically including: The buffer space is compressed according to a preset step-by-step compression rule; the step-by-step compression rule divides the compression process into multiple consecutive compression stages. Within each compression stage, the following steps are performed: Based on the compression rules corresponding to the current compression stage, the buffer space is compressed by reducing the visual style parameter values; Based on the displacement conversion relationship corresponding to the current compression stage, the compression amount of the buffer space is converted into the corresponding buffer displacement amount to control the movement of the display position of the movable control. In at least two consecutive compression stages, the amount of buffer displacement generated per unit compression decreases as the degree of compression increases.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: Based on the operating environment parameters, the baseline design pixel values ​​are adaptively geometrically transformed to obtain the preset displacement threshold parameters, preset convergence threshold parameters, and injected dynamic buffer style parameters in the interactive control process.

8. The method according to claim 1, characterized in that, Based on the interaction state, controlling the visual rendering of the movable control specifically includes: In response to the detection of an initial press operation on the movable control, disable the transition animation properties of the movable control; In response to detecting a release operation on the movable control, restore the transition animation properties of the movable control.

9. The method according to claim 1, characterized in that, Based on the interaction state, controlling the visual rendering of the movable control specifically includes: Responding to detected UI theme parameters; Based on the interface theme parameters and control business logic state parameters, the target visual style parameters corresponding to the movable control are selected from the visual style parameter set.

10. An interactive control device for interface controls, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform an interactive control method for an interface control as described in any one of claims 1-9.

Images