langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-08-26 18:36:52 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

[Chore/Refactor] Fix layout overlap and inconsistent description character limits in App/Dataset cards #15974

New Issue
Closed
opened 2026-02-21 19:24:11 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 19:24:11 -05:00
Owner
Copy Link
Copy Source

Originally created by @lyzno1 on GitHub (Aug 7, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for refactoring, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Description

This refactor addresses two critical UI/UX issues identified in PR #23515:

  1. Layout overlap issue in App Card: The current implementation causes description text to overlap with the "Add tags" placeholder text when no tags are present, creating a poor user experience.

  2. Inconsistent description character limits: Dataset creation has a backend 400-character limit that shows "Description cannot exceed 400 characters" error on save, while App creation has no such limit. This creates inconsistent user expectations and experiences.

Motivation

Related to PR #23515 which improved mobile accessibility by making tag selectors always visible, but introduced layout overlap issues.

Current Problems:

  1. Visual Overlap: In App Card, when no tags exist, the 4-line description text overlaps with the bottom "Add tags" placeholder text (42px height), making content unreadable.

  2. UX Inconsistency:

    • Dataset description: Backend enforces 400-character limit, but frontend provides no validation or character counter
    • App description: No character limits at all
    • Users get unexpected validation errors only on save for datasets

  3. Mobile Accessibility vs Visual Design: While PR #23515 correctly solved the mobile accessibility issue, it needs refinement to maintain visual polish.

Additional Context

Technical Details:

App Card Layout Structure:

  • Description area: Dynamic height (2-4 lines based on tags presence)
  • Tag area: Always visible 42px absolute positioned bottom area
  • Problem: 4-line description + 42px tag area = overlap

Backend Validation Inconsistency:

  • Dataset API: 400-character limit enforced
  • App API: No character limit enforced
  • Frontend: No validation or user feedback for either

Questions for Discussion:

Should we synchronize the character limits? If so:

  • Option A: Apply 400-character limit to both (with frontend validation)
  • Option B: Increase/remove Dataset description limit to match App behavior
  • Option C: Keep different limits but add proper frontend validation and user feedback

Proposed Solutions:

  1. Fix overlap: Adjust App Card description line limits to prevent overlap with tag area
  2. Unify validation: Implement consistent character limits and frontend validation for both components
  3. Improve UX: Add character counters and real-time validation feedback

This refactor will improve consistency, usability, and visual polish across the platform.

Originally created by @lyzno1 on GitHub (Aug 7, 2025). ## Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for refactoring, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ## Description This refactor addresses two critical UI/UX issues identified in PR #23515: 1. **Layout overlap issue in App Card**: The current implementation causes description text to overlap with the "Add tags" placeholder text when no tags are present, creating a poor user experience. 2. **Inconsistent description character limits**: Dataset creation has a backend 400-character limit that shows "Description cannot exceed 400 characters" error on save, while App creation has no such limit. This creates inconsistent user expectations and experiences. ## Motivation **Related to PR #23515** which improved mobile accessibility by making tag selectors always visible, but introduced layout overlap issues. ### Current Problems: 1. **Visual Overlap**: In App Card, when no tags exist, the 4-line description text overlaps with the bottom "Add tags" placeholder text (42px height), making content unreadable. 2. **UX Inconsistency**: - Dataset description: Backend enforces 400-character limit, but frontend provides no validation or character counter - App description: No character limits at all - Users get unexpected validation errors only on save for datasets 3. **Mobile Accessibility vs Visual Design**: While PR #23515 correctly solved the mobile accessibility issue, it needs refinement to maintain visual polish. ## Additional Context ### Technical Details: **App Card Layout Structure:** - Description area: Dynamic height (2-4 lines based on tags presence) - Tag area: Always visible 42px absolute positioned bottom area - **Problem**: 4-line description + 42px tag area = overlap **Backend Validation Inconsistency:** - Dataset API: 400-character limit enforced - App API: No character limit enforced - Frontend: No validation or user feedback for either ### Questions for Discussion: Should we **synchronize the character limits**? If so: - Option A: Apply 400-character limit to both (with frontend validation) - Option B: Increase/remove Dataset description limit to match App behavior - Option C: Keep different limits but add proper frontend validation and user feedback ### Proposed Solutions: 1. **Fix overlap**: Adjust App Card description line limits to prevent overlap with tag area 2. **Unify validation**: Implement consistent character limits and frontend validation for both components 3. **Improve UX**: Add character counters and real-time validation feedback This refactor will improve consistency, usability, and visual polish across the platform.
yindo closed this issue 2026-02-21 19:24:11 -05:00
yindo commented 2026-02-21 19:24:11 -05:00
Author
Owner
Copy Link
Copy Source

@lyzno1 commented on GitHub (Aug 7, 2025):

@dosubot please review this issue and provide actionable suggestions or solutions.

@lyzno1 commented on GitHub (Aug 7, 2025): @dosubot please review this issue and provide actionable suggestions or solutions.
yindo commented 2026-02-21 19:24:12 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 7, 2025):

Here are actionable suggestions to address the layout overlap and inconsistent description character limits:

  1. To fix the App Card layout overlap, dynamically restrict the description area to 2 or 3 lines (instead of 4) when no tags are present, or reduce the fixed height of the description container so it never collides with the 42px tag area. This prevents the description text from running into the tag selector, especially on mobile and when the tag area is empty but still visible. You may also consider making the tag area relatively positioned or adjusting padding/margins to ensure clear separation between description and tags. See the relevant code structure and overlap issue here.

  2. For character limit consistency, apply a 400-character limit to both App and Dataset descriptions. This matches backend enforcement for datasets and creates a predictable experience for users. Implement frontend validation and a live character counter in both creation/edit forms, so users get immediate feedback and can't exceed the limit before submitting. This will prevent unexpected backend errors and improve UX. There is precedent for this approach in the dataset API and UI, but it is missing for apps—see the discussion of discrepancies here.

  3. Synchronize validation logic by defining the character limit as a shared constant in both frontend and backend code. This ensures future changes remain consistent and reduces the risk of drift between UI and API validation.

  4. If the backend for App descriptions does not currently enforce a limit, update the relevant API endpoint to match the 400-character rule, or document the intended difference if there is a product reason for it.

  5. Consider updating documentation and design guidelines to reflect the new standards for description length and layout, so future contributors follow the same rules.

These changes will improve visual consistency, prevent layout bugs, and provide a smoother, more predictable experience for users across both App and Dataset cards.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 7, 2025): <!-- Answer --> Here are actionable suggestions to address the layout overlap and inconsistent description character limits: 1. To fix the App Card layout overlap, dynamically restrict the description area to 2 or 3 lines (instead of 4) when no tags are present, or reduce the fixed height of the description container so it never collides with the 42px tag area. This prevents the description text from running into the tag selector, especially on mobile and when the tag area is empty but still visible. You may also consider making the tag area relatively positioned or adjusting padding/margins to ensure clear separation between description and tags. See the relevant code structure and overlap issue [here](https://github.com/langgenius/dify/blob/d98071a088c46f61f2608415bb23f9aa5f40f737/web/app/components/explore/app-card/index.tsx). 2. For character limit consistency, apply a 400-character limit to both App and Dataset descriptions. This matches backend enforcement for datasets and creates a predictable experience for users. Implement frontend validation and a live character counter in both creation/edit forms, so users get immediate feedback and can't exceed the limit before submitting. This will prevent unexpected backend errors and improve UX. There is precedent for this approach in the dataset API and UI, but it is missing for apps—see the discussion of discrepancies [here](https://github.com/langgenius/dify/issues/13503). 3. Synchronize validation logic by defining the character limit as a shared constant in both frontend and backend code. This ensures future changes remain consistent and reduces the risk of drift between UI and API validation. 4. If the backend for App descriptions does not currently enforce a limit, update the relevant API endpoint to match the 400-character rule, or document the intended difference if there is a product reason for it. 5. Consider updating documentation and design guidelines to reflect the new standards for description length and layout, so future contributors follow the same rules. These changes will improve visual consistency, prevent layout bugs, and provide a smoother, more predictable experience for users across both App and Dataset cards. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/cf292c2f-d21c-476d-a862-5a111755eb22?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/cf292c2f-d21c-476d-a862-5a111755eb22?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/cf292c2f-d21c-476d-a862-5a111755eb22?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/cf292c2f-d21c-476d-a862-5a111755eb22?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/cf292c2f-d21c-476d-a862-5a111755eb22?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/cf292c2f-d21c-476d-a862-5a111755eb22?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/cf292c2f-d21c-476d-a862-5a111755eb22?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23583)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15974
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?