Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] Custom Notification for Empty Search Field Instead of Browser's Native Modal #302

Open
1 task done
SylviaUzoh1 opened this issue Oct 17, 2024 · 3 comments · May be fixed by #314
Open
1 task done

[Feature] Custom Notification for Empty Search Field Instead of Browser's Native Modal #302

SylviaUzoh1 opened this issue Oct 17, 2024 · 3 comments · May be fixed by #314
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing feature 🟩 priority: low Low priority and doesn't need to be rushed 🧹 status: ticket work required Needs more details before it can be worked on

Comments

@SylviaUzoh1
Copy link
Contributor

Problem

Currently, when the search field is empty and the search button is clicked, the browser shows a default native modal with the message: "search.creativecommons.org says please enter a value." This behavior feels inconsistent with the overall user experience and design of the site. The native modal can be abrupt and less user-friendly, especially since it doesn’t match the site's visual style.

Description

I propose introducing a custom notification or prompt system for situations where a required input field is left empty (like the search field). Instead of relying on the browser’s default modal, we could display a properly styled and branded message within the page itself. This could be a subtle popup, a toast notification, or an inline error message that aligns with the overall UI design, improving user experience.

Alternatives

An alternative solution could be to use a small, inline error message directly below the input field. This would avoid popups and keep the user interface clean and accessible. However, a custom notification or toast would be more visible and engaging, especially on larger screens.

Additional context

This feature would improve the consistency and usability of the search functionality, making error handling smoother and more intuitive. It could also reduce the dependence on browser-specific error handling, which may behave differently across various browsers.

Implementation

  • I would be interested in implementing this feature.
@SylviaUzoh1 SylviaUzoh1 added ✨ goal: improvement Improvement to an existing feature 💻 aspect: code Concerns the software code in the repository 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work 🟩 priority: low Low priority and doesn't need to be rushed labels Oct 17, 2024
@cc-open-source-bot cc-open-source-bot moved this to Triage in WebDev Oct 17, 2024
@possumbilities possumbilities added 🧹 status: ticket work required Needs more details before it can be worked on and removed 🚦 status: awaiting triage Has not been triaged & therefore, not ready for work labels Oct 21, 2024
@possumbilities
Copy link
Contributor

I'd love to see a more specific spec for how this would be implemented. Something inline is likely the best UX. Moving to https://github.com/creativecommons/search/issues?q=state%3Aopen%20label%3A%22%F0%9F%A7%B9%20status%3A%20ticket%20work%20required%22 until there's a more concise direction here.

@possumbilities possumbilities moved this from Triage to Backlog in WebDev Oct 21, 2024
@SylviaUzoh1
Copy link
Contributor Author

@possumbilities thank you for the feedback!
I agree that an inline error message below the search field would offer the best UX. It would appear when the user submits an empty input, styled to match the site's design (e.g., red text). This can be implemented with JavaScript for validation.

Let me know if this approach works, and I can provide more detailed specs.

@Immy-delish
Copy link

Hello @SylviaUzoh1 and @possumbilities . This issue was already opened here #238 and the implementation was agreed. Opening it again duplicates it. I think we can work on it since the status is "Ready for Work" .

@SylviaUzoh1 SylviaUzoh1 linked a pull request Oct 24, 2024 that will close this issue
7 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💻 aspect: code Concerns the software code in the repository ✨ goal: improvement Improvement to an existing feature 🟩 priority: low Low priority and doesn't need to be rushed 🧹 status: ticket work required Needs more details before it can be worked on
Projects
Status: Backlog
Development

Successfully merging a pull request may close this issue.

3 participants