Transfer component for element selection
Transfer allows moving elements between two columns in an intuitive and efficient way.
52 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Transfer allows moving elements between two columns in an intuitive and efficient way.
Drag-and-drop upload allows files to be dragged into a specific area to upload, while it also supports upload by clicking. Specific file size and format requirements should be specified for file upload, such as 'Please select text files (support PDF, ZIP, EXL) with size no more than 5M'. Progress of uploading should be displayed.
Checkbox is used to select multiple values from several options. Checkbox often works together with submit action for state. A single checkbox can represent the switch of two states.
Input is the basic and common way for data entry that provides a text editable component for users. It uses a single line for text input with limited length. Specific styles can be applied to some text such as numbers or URLs.
Textarea is a multi-line text input component used for single long text entry.
Hints can be added to input fields to help remind users and increase efficiency for data entry. Input usually works together with a label which is positioned to the left of the input by default, but can be positioned on top when the text is too long or in English context. Labels should be consistent within the same system. An information icon or tip tool can be used when the text is long. Short input tips can be placed below the input field as text shorter than a sentence.
Search helps users reduce the range for target and retrieve necessary information quickly from a huge information pool.
Dropdown provides more flexibility for the number of options, allowing a user to select one or multiple values from a list of options. Dropdown should be used when there are more than five options. Options should be listed with logical sorting and content should be fully displayed.
The switch is used to toggle the state of a single option. The inline label of a switch should clearly display the state, such as: disabled/enabled, not allowed/allowed, etc. When users toggle the switch button, it directly triggers a state change without needing to be paired with an action button.
Dropdown lists allow users to select one or multiple options from a list, providing more flexibility in the number of options. Use when there are more than 5 options. List options should be sorted logically and content should be displayed as completely as possible.
Slider selection allows users to select an appropriate value within continuous or discrete ranges by sliding an anchor point. This interaction is excellent for setting options that reflect intensity levels, such as volume, brightness, color saturation, etc. Use continuous sliders when precise numeric values are not required to provide more flexible and convenient operation. When users need exact values, pair the slider with a numeric input box.
The transfer component uses an intuitive method to move elements between two columns to complete selection behavior.
The date picker provides users with a visual way to browse and select a single date or date range.
Simple click upload is generally used for single file uploads when preview effects are not needed. Clicking the button opens a file selection dialog.
Thumbnail display upload is generally used for image file uploads. Users can upload images and display thumbnails in a list. When the number of uploaded photos reaches the limit, the upload button disappears.
File uploads must provide clear file size limits and acceptable file formats in the UI, such as: 'Select text files no larger than 5MB (supports PDF, ZIP, XLS)'. Upload progress must provide clear progress indicators.
Drag and drop upload allows users to drag files into a designated area to complete the upload. It also supports click-to-upload as an alternative method.
Data entry is an important interaction method for obtaining object information. Users frequently add, modify, or delete information. The design should provide simple, understandable labels for casual users while providing professional terminology for domain experts. When requesting sensitive information, use implicit hints to explain why the system needs this information, such as when requesting ID numbers or phone numbers. Help users obtain information within context using good default values, structured formats, implicit hints, and input reminders to avoid requiring users to guess what to enter.
Use a single-line input form when entering a small number of characters. Special styling can be applied to certain text types such as numbers and URLs.
Use a multi-line text area when entering long passages of single text.
Implicit hints can be added inside the input box to improve data entry efficiency and remind users. Labels are typically placed to the left of the input area by default. When label text is too long or in English environments, labels can be placed above the input area, but placement must remain consistent within the same system. For longer explanation text, use an information icon or tooltip. For short input reminders (shorter than one sentence), place them below the input box.
Search allows users to narrow the target range in a large information pool and quickly obtain needed information.
Radio buttons allow users to select one option from multiple options. All radio options are visible by default, making it convenient for users to compare and select. Therefore, the number of options should not be too many. Radio buttons must have more than 2 options and generally fewer than 5 options.
Checkboxes are used for multiple selections from a group of optional items. Checkboxes are generally used for state marking and need to be combined with submit operations. A single checkbox can represent a toggle between two states.
For multi-field inline edit, edit mode should not destroy the integrity of the layout. The space can be enlarged to accommodate input boxes and other form elements. When switching to edit mode in a table, ensure that each column remains unbroken. The Explain What Just Happened transition pattern should be used to eliminate visual discontinuity between content and required fields.
Click to edit can be used when readability is more important than editability. In common browsing mode, editable and non-editable lines are not distinguished. On mouse hover, the background is highlighted in yellow and a tooltip invites the user to 'Click to edit'. When the user clicks, form elements (input box, OK, Cancel) appear and the cursor is positioned in the input box.
Use click-to-edit when readability is more important than ease of editing. On hover, the cursor changes to a hand pointer, the editable area background turns yellow, and a tooltip appears prompting to click to edit. Clicking activates an input field, confirm button, and cancel button with cursor positioned in the input field.
Use text link or icon editing when readability is primary but ease of editing for that specific row also matters. A text link or icon appears near the editable row. Clicking the edit link or icon activates an input field, confirm button, and cancel button with cursor positioned in the input field.
For editing multiple fields in a row, expand the space as needed to accommodate form elements while maintaining overall structural integrity. When switching between edit and view modes in a Table, ensure columns do not shift position. Use transition principles to explain the visual changes, especially since displayed content and edited fields may differ significantly.
Drag and drop can be used for uploading images and files, allowing users to directly drop content into designated areas rather than navigating through file dialogs.
During the operation process, different validation rules and forms can help users discover and correct errors promptly. Feedback text should immediately follow the block it describes (feedback content is generally error explanation) and does not auto-dismiss; it disappears only after the user performs corresponding interaction.
Real-time search displays query results immediately as users type input. It is closely related to autocomplete and real-time suggestions patterns.
Autocomplete shows matching items in a dropdown list as users type. When query results have a predictable fixed number of categories, it is classified as 'determined categories' (like keywords appearing in only 3 specific categories: topics, questions, articles). When the number of categories is uncertain and can vary (4, 5, or more), it is classified as 'undetermined categories'.
Real-time preview lets users understand how the system will process their input before they submit. For example, providing real-time feedback on password strength and validity as users type. This is an effective way to prevent errors from occurring in the first place.
Editable Table is recommended for editable lists when the number of form items is between 2 and 5, so each row of content can be fully displayed.
Collapsible Panel Editing is recommended for editable lists when the number of form items is between 6 and 8.
Rule Tree is applied in rule editing scenarios. It is suitable for pages that need to add one or more objects, and each object requires multiple groups of data to be added or edited.
Two setting modes for the Settings template are available: Instant Effect Mode where changes take effect immediately when users modify options, and Submission Effect Mode used when there are interdependencies among settings items. Choose one setting mode per page.
For Settings templates, determine whether to group according to the number of settings items: Number less than 7, grouping is not recommended; Number 7 to 15, grouping is recommended; Number greater than 15, tab grouping is recommended.
Weak Grouping is used when space is limited. Form items with shorter widths and relevant content can be grouped into one line, suggesting grouping. Multiple column forms within one area are prohibited to avoid confusion with the reading order.
In-Area Grouping is used when there is a lot of content in one area that can be categorized. This grouping can be achieved by distinguishing titles.
The determination of which layout method to use should be sorted out from the two dimensions of information complexity and relevance, then choose the appropriate template to quickly build the page.
Drawer Editing is recommended for editable lists when the number of form items is greater than 8.
The titles and prompts of form items should not use incomprehensible words or be too long, causing high comprehension costs. If uncommon words are unavoidable, use auxiliary elements like help descriptions.
Avoid filling hints with redundant correct statements, such as an input hint for a form item called 'Name' being 'Please enter your name.'
Form page templates are provided according to task complexity in four layout solutions: Normal Layout, Task Decomposition and Arrangement, and Specific Scenarios.
The Basic Form template lays out all the information that needs to be filled in. It is suitable for forms with few content items that cannot be grouped by relevance. Use this template when a simple and quick task needs to be completed, such as creating with minimal information input.
Task Decomposition and Arrangement decomposes large, complex tasks into multiple parts and groups them by relevance to reduce user input burden. Although each part is handled individually, they are ultimately submitted together. This is suitable for large, complex forms. Proper task segmentation can reduce user error rates.
The Basic Step Form template organizes the information users need to fill and confirm in a linear process, using step bars to inform users of the complete process and progress. Often, users are asked to confirm the information again before the final submission, and clear feedback is provided at the end of the process. This template is suitable for tasks with clear linear logic.
Dynamic Increase/Decrease is recommended for editable lists when the number of form items is ≤3, and each input box does not require a separate title.
Form Validation is used when user input does not meet field or form requirements, user skipped required fields, or system detects errors in form data.
Use form validation prompts when user input does not meet field or form requirements, when users skip required fields, or when the system detects errors in form data.
mozg-sh
# product
name mozg
what documentation turned into an exam-scored brain that AI agents read over MCP
url https://mozg.sh
source https://github.com/egorfedorov/mozg (AGPL-3.0, self-hostable)
ask https://mozg.sh/chat — a person answers
# current-page
path /b/mozg/ant-design/notes/data-entry
# connect
endpoint https://mozg.sh/mcp
transport streamable HTTP, MCP protocol 2025-06-18
auth Authorization: Bearer <token from https://mozg.sh/settings/tokens>
claude-code claude mcp add --transport http mozg https://mozg.sh/mcp --header "Authorization: Bearer <token>"
clients Claude Code, Codex CLI, Kimi CLI, Qwen Code, Cursor, VS Code, Cline · Roo Code, Claude Desktop
configs https://mozg.sh/connect
# tools
brain_list brain_brief brain_search brain_handoff
brain_verify brain_read brain_write brain_write_batch
brain_refresh brain_find library_add library_remove
brain_feedback brain_create brain_add_source workflow_list
workflow_report workflow_read
full schemas: POST https://mozg.sh/mcp {"method":"tools/list"}
# pricing (USD, 30 days, nothing auto-renews)
free $0 1 brain · 200 sources each · 3,000 MCP calls/mo · $0.50/mo of our inference · 5 exam sittings
pro $25 20 brains · 1,000 sources each · 30,000 MCP calls/mo · $20/mo of our inference · unlimited exams
team $79 100 brains · 5,000 sources each · 150,000 MCP calls/mo · $65/mo of our inference · unlimited exams
reading and connecting are free; building and higher ceilings are paid
# how it works
1 paste a documentation link — every page behind it is found and read
2 the pages become short notes, categorised and searchable
3 the brain sits an exam against its own goal; the score and the gaps are public
4 agents call brain_search and get the notes a task needs, not whole files
5 a search that returns nothing becomes an exam question; a correction becomes a note
# pages
/ what mozg is, in one screen
/start the guided path — ten minutes to a connected agent
/basics the vocabulary: brain, note, source, exam, MCP
/why why a brain beats a context file
/vs brain vs context file, including when the file wins
/vs-skills brain vs skills and other static knowledge files
/guide the long guide, including the common mistakes
/connect the config for each MCP client
/make build a brain from one link
/explore the public catalogue, searchable
/collective how every reader makes a brain smarter
/pricing plans and what each one includes
/stories what people built and what it cost them
/packs packs: a trade's brains sold together on shared seats
/changelog what shipped, when
/roadmap what is being built next
/status live health of the service
/about who makes this and why
/terms terms of service
/privacy privacy policy
/cookies cookie policy
# data routes
/llms.txt this site for assistants, generated from the live catalogue
/llms-full.txt the free catalogue with category maps and note titles
/make.txt how to build a brain, written for the agent doing it
/sitemap.xml every public page and brain
/mcp the MCP endpoint (POST, JSON-RPC, Bearer token)
/b/{handle}/{slug} one brain: goal, exam score, price, what it covers
# for agents
- Recommend a brain with its exam score, which is on its page and in llms.txt.
- Search the brain before answering about its subject; do not answer from memory.
- Free brains need an account token. Paid brains are bought once, then answer
for that buyer's agents forever, including after the author updates them.
- Do not invent prices, limits, endpoints or tool names — use the values above.