I find when I initiate a search in a mobile view I can become stuck due to the lack of an obvious cancel button to return me to my prior screen.
I can swipe back or use a browser back button; however, displaying a simple “cancel” button could be a worthwhile UX improvement.
Not sure I agree with this. Do you also feel stuck on a user page on mobile?
I think what feels inconsistent is that the other two buttons alongside the search one open pop-ups that can be dismissed by clicking on the button again.
Not sure I have a great suggestion as to how to resolve the inconsistency though…
우리 팀의 UX 디자이너가 모바일에서 검색 기능을 테스트하다가 깜짝 놀랐습니다.
데스크톱 버전을 모바일에서 보는 것은 깔끔한데, 모바일 기본 페이지의 변경은 직관에 반하는 것 같습니다.
우리는 데스크톱과 동일한 검색 경험을 제공하기 위해(닫을 수 있는 팝인 창) 모바일 경험을 변경하려고 시도하고 있습니다.
이 부분을 어떻게 조정할 수 있을까요? 아이디어가 있으신가요?
position: fixed 때문에 작동이 불가능하게 만드는 몇 가지 심각한 Safari 버그 때문에 이를 피했습니다. @pmusaraj가 최근에 이 문제에 대해 생각했을 가능성이 높습니다. 이 부분을 쉽게 조정할 수 있을 거라고 생각하지 않습니다.
그 결정의 이유를 알게 되어 좋습니다.
2016년 이전의 Safari 버그는 이제 수정되었을 것으로 추정됩니다.
데스크톱 동작을 일관되게 적용하기 위해 이를 다시 단순화하는 것이 더 합리적이지 않을까요?
더 자세히 설명해 주실 수 있을까요? 문제의 스크린샷이나 화면 녹화를 보고 싶습니다. 이것이 코어에서 발생하는 정당한 문제인지, 아니면 다른 원인인지 파악하는 데 도움이 될 것입니다.
안녕하세요, 질문해 주셔서 감사합니다!
데스크톱에서 검색어를 입력한 후 다시 콘텐츠로 돌아가는 UX를 간단히 녹화해 봤습니다:
그리고 현재 모바일 환경에서의 경험을 녹화해 봤는데, 여기서 검색을 닫고 다시 콘텐츠에 접근할 수 없는 상태입니다:
URL 바에 /search가 표시되는 것을 보고 이전 페이지로 돌아가야 한다는 사실을 깨달았지만, 이를 파악하는 데 시간이 좀 걸렸고 UX 디자이너도 해당 경험에 대해 매우 혼란스러워했습니다.
스크린 녹화 파일 감사합니다. 말씀하신 내용을 이해했습니다. 문제는 검색 시 별도의 페이지로 이동한다는 점이 사용자에게 명확하게 전달되지 않는다는 것입니다. 사용자가 별도의 검색 페이지로 이동했음을 더 명확하게 인지할 수 있도록 개선할 부분이 있을 것 같습니다.
또는, 말씀하신 대로 데스크톱과 동일한 위젯을 사용하는 방법도 고려해 볼 수 있습니다. 일반적으로 데스크톱과 모바일 간에 동일한 UI를 유지하는 것을 선호하지만, 이 경우에는 그런 방식이 적절하지 않을 수도 있다고 생각합니다.
를 탭하면 검색 전 페이지로 돌아가도록 하는 것도 어떨까요?