Hacker News 의견들

• 접근성에 대해 강의하면서 클릭 후 3초 지연이 생겨 아무 반응이 없는 것처럼 느껴지는 상황을 겪었음
  • 배너를 클릭하면 아무 표시도 없이 기다리게 되고, 나중에 관련 없는 페이지로 이동하는 식이라 답답했음
  • 로딩 중임을 알려주는 피드백 부재가 문제라고 생각함
  • 어떤 이는 그건 단순한 `` 링크라며, 페이지가 불필요하게 커서 생기는 지연일 뿐이라고 말함
  • 또 다른 사람은 느린 4G에서도 즉시 반응한다며, 브라우저나 네트워크 문제일 가능성을 제기함
• GitHub Primer 문서를 흥미롭게 읽었음
  • 모든 내용에 동의하지 않아도 배울 점이 있고, 감으로 하는 것보다 훨씬 낫다고 느낌
  • 참고로 Apple과 Android도 각각 디자인 가이드라인을 제공하고 있음
• 드디어 이런 트렌드가 확산되길 바람
  • 토스트 알림 때문에 놓친 메시지가 너무 많았음
  • 다른 사용자는 “토스트는 접근성 문제로 사용을 권장하지 않는다”는 문구에 전적으로 동의하며, 알림 센터가 있었다면 그나마 나았겠지만 여전히 나쁜 방식이라고 강조함
• 나는 토스트를 비방해적 확인용으로는 좋아하지만, 중요한 정보를 전달하는 용도로는 부적절하다고 생각함
  • 다른 사람은 토스트의 사용 맥락을 구체적으로 나눠 설명함
    • 버튼 클릭 즉시 반응 → 버튼 자체에서 피드백을 주는 게 낫고
    • 단축키 반응 → 괜찮음
    • 오래 걸리는 작업 완료 알림 → 괜찮지만 지속적인 알림함이 필요함
    • 페이지 진입 시 경고 표시 → 중요하다면 페이지 내에 영구적 알림으로 보여야 함
  • React에서 전역 toast() 호출이 쉬워 남용되는 경향이 있지만, useAlerts() 같은 구조로 바꾸는 게 훨씬 낫다고 제안함
• 토스트는 내게 지혈대 같은 존재임
  • 급한 문제를 임시로 막는 데 유용하지만, 장기적으로 유지하면 안 됨
  • 새 프로젝트에서 피드백이 부족할 때 임시로 붙였다가, UI를 개선하면서 하나씩 제거하는 식으로 써야 함
  • GitHub처럼 큰 조직은 이런 임시방편이 필요 없지만, 작은 팀은 다를 수 있음
• GitHub 문서에서 말한 “대량 Issue 생성 시 추가 피드백이 필요하다”는 부분이 마음에 듦
  • GitHub Actions에서도 이런 피드백이 있으면 좋겠음, 실행 후 결과가 나타나기까지 너무 오래 걸림
• UI 전반의 행동 로그로 토스트를 활용하는 아이디어가 마음에 듦
  • 클릭할 때마다 사라지는 피드백 대신, Sonner처럼 잘 구현된 예시가 있음
• 브라우저 차원에서 토스트의 네이티브 지원을 고려할 때가 된 것 같음
  • 타이밍 조절, 알림 센터, 스크린 리더 통합 등 접근성 개선이 가능할 것 같음
  • 시각적으로는 괜찮지만, 너무 빨리 사라져 놓치는 경우가 많음
  • 시각장애인이 겪는 문제를 직접 이해하긴 어렵지만, 그들의 접근성을 높이는 방법을 듣고 싶음
• 토스트의 장점은 구현이 쉽고 디자인 부담이 적음임
  • 단점은 놓치기 쉽고, 다른 정보 위에 겹칠 위험이 있음
  • 여유가 있다면 토스트를 모두 없애는 게 낫다고 생각함
  • 다른 사람은 “쉽게 만들 수 있어서 문제 해결을 가장한 미봉책으로 남용된다”고 지적함
  • 또 다른 사람은 토스트를 단순한 안심용 피드백으로 사용했다고 함
  • 반면 어떤 이는 “토스트는 저중요 이벤트에 즉각적 피드백을 주는 유용한 도구”라며, 모달창이나 고정 영역보다 효율적이라고 주장함
  • 도구의 남용을 이유로 완전히 배제하는 흑백논리를 비판함
• “GitHub의 토스트 제거가 접근성에 나쁜 소식”이라는 글을 봤음
  • 어떤 이는 그 주장이 이상하다고 느낌
    • GitHub이 토스트를 없앤 대신 W3C를 통해 브라우저 표준을 만들었어야 한다는 건 비약이라고 생각함
    • 이미 생성된 아이템이 리스트에 나타나는 것만으로도 충분한 피드백이라고 봄
  • 또 다른 사람은 “토스트가 접근성과 UX에 나쁘다고 하면서, GitHub이 그것을 브라우저에 표준화하지 않았다고 비판하는 건 모순”이라고 말함