A Beginner Trading Bot UI: Clear Stop Intent and Order Outcomes
TECH INSIGHT / EXPLAINED
A beginner needs three answers from a trading panel: is the information current, what will this action change, and where can its outcome be checked? A screen answering those questions makes mistakes easier to notice than one simply displaying more numbers.
Original screenshots and product images
The screenshots and product images from the original post are retained here alongside the explanation.
Browser captures of the public project
These images were captured directly from the public pages of the project discussed here. The source and capture date are provided for each image.
Keep instrument, account, and action together
Use a consistent card order: instrument name and code, observation time, holdings and orders, then instrument-specific actions. Separate display values from editable fields with labels and units. readonly reduces accidental editing in the UI; it is neither authorization nor server-side validation.
Do not represent zero holdings, missing data, loading, and failures with the same dash. Say “0 shares,” “loading,” “data from 3 minutes ago,” or “lookup failed.” A 400px popup is one design choice; wider history can live on a separate page.
Separate save, enable, order, and stop
Explain whether saving changes settings only or also activates trading. Before enabling, show the account, strategy, and limits. For a direct order, let the user review and correct the instrument, side, quantity, order type, and price conditions. Instead of identical prompts on every routine setting, place meaningful review at requests with financial consequences.
“Liquidate” is ambiguous: does it submit a market sale of everything or a limit order? Name the actual behavior. Buy and sell colors vary by market convention, so use text and icons too.
Preserve stop intent
If the user presses Stop, the desired state is disabled. A toggle that rereads status and then inverts it can become a start when another device changes state. Repeating an explicit stop request should never restart the bot.
Block new orders and enabling while settings load. Design a stop path that does not depend entirely on successful loading of the settings or order screen. If identity or the target account cannot be verified, do not claim success: show a recovery path. Stopping future runs, cancelling open orders, and selling holdings are separate functions.
An ambiguous response means ambiguous status
Defaulting a missing response status to OFF can falsely report that a running bot stopped. Distinguish requesting, accepted, stop confirmed, and unknown. Show last-success and refresh times alongside enabled state. Prevent repeated clicks in the UI and deduplicate request IDs on the server.
For example, with two shares available to sell, requests for one or two shares may pass the quantity check, while three should fail. Testing whether holdings equal exactly one is a different rule. The server must recheck current available quantity, outstanding orders, input format, and authorization. Buy validation needs its own conditions, such as available buying power.
Leave understandable failure information
Saving settings and filling an order need different success messages. Log time, target, request ID, and the next place to check, while redacting secrets. Do not describe popup-only logs as permanent history. When someone is reading older entries, show a new-entry indicator instead of forcibly scrolling to the bottom.
Check keyboard reachability, visible focus, and error text associated with its input. Announce important status changes through appropriate status or live regions without reading every log line as an alert. People using screen readers or unable to distinguish colors need the same understanding of results.
Reproduce failure scenarios before release
Test slow initial loads, stale state, simultaneous devices, double clicks, lost responses, and partial fills. Ask whether the user can accurately explain the outcome, not only whether the button fired. UI review works alongside server-side limits and order validation.
Chrome extension panel lifetime and permission design
References
Content and examples reviewed: 2026-09-29
댓글
댓글 쓰기