"풍부한"응용 프로그램에서 뒤로 단추를 분리하는 것이 점점 일반적입니다. 나는 항상 이것이 나쁜 형식이라고 생각했지만 아마도 그 견해는 구식일까요?
뒤로 단추를 깰 수 있습니까? 그렇다면 어떤 기준이 있습니까?
편집 : 뒤로 버튼을 클릭하면 기본적으로 원래 위치로 돌아가는 응용 프로그램을 더 많이 언급하고 있음을 분명히합니다. 효과적으로 비활성화되지만 프레스에 유해하지는 않습니다.
"풍부한"응용 프로그램에서 뒤로 단추를 분리하는 것이 점점 일반적입니다. 나는 항상 이것이 나쁜 형식이라고 생각했지만 아마도 그 견해는 구식일까요?
뒤로 단추를 깰 수 있습니까? 그렇다면 어떤 기준이 있습니까?
답변:
뒤로 버튼이 예상되는 경우에만 웹 사이트에서 이벤트가 끝난 후 뒤로 돌아 가지 않는 것이 좋습니다.
Mozilla는 사람들이 브라우저를 사용하는 방법에 대해 연구했으며 뒤로 버튼의 결과가 인상적입니다.
뒤로 단추는 다른 탐색 요소 (뒤로, 앞으로, 새로 고침, 중지 및 홈 단추를 의미)보다 훨씬 자주 사용됩니다. 연구 참가자의 93.1 %가 뒤로 버튼을 한 번 이상 사용했으며 평균적으로 각 사용자가 5 일 동안 뒤로 66.2 번 클릭했습니다. 즉, 새로 고침 버튼보다 3 배 더 많고 홈 버튼보다 10 배, 홈 버튼보다 30 배 이상 전진 및 정지 버튼!
나는 뒤로 버튼을 많이 사용하고 그것을 사용할 수 없을 때 나는 싫어.
경우에 따라 뒤로 버튼을 해제해도 문제는 없지만 거의 항상 불필요합니다. 한 페이지에서 다음 페이지로 게시하는 다단계 양식으로 많이 보았습니다. 이 인스턴스에서해야 할 일은 양식 페이지 (1)에서 시작하고 다른 페이지 (2)에 게시하여 (예 : 세션에 물건을 저장 한 후 다른 페이지로 다시 리디렉션) (3)입니다. 사용자가 뒤로 버튼을 누르면 (3)에서 (1)로 돌아갑니다.
RIA에서도 URL 해시 / 앵커 (예 :)를 사용 page.html#section
하여 변경 사항을 모니터링 할 수 있습니다. Gmail은받은 편지함, 작성, 설정 등과 같은 다른 '페이지'에 대해이 작업을 수행합니다. 스택 오버플로에 대한이 질문은 구현하려는 경우 도움이됩니다.
"가장 흔하게 발생하는"주된 이유는 일부 RIA 프레임 워크가 뒤로 단추를 지원하지 않거나 사용을 응용 프로그램에 통합하는 방법에 대해 적극적으로 생각해야하기 때문입니다. 대부분의 프레임 워크는 프레임 및 페이지 컨트롤에 대한 Silverlight 3의 지원과 같이 탐색에 대한 약간의 지원을 제공하지만 효과적으로 사용하는 방법을 알아야합니다. Windows Phone 7 응용 프로그램에서 동일한 탐색 프레임 워크가 사용됩니다.
내 경험은 브라우저의 컨텍스트 (위에서 언급 한 silverlight와 같은) 내에서 응용 프로그램과 같은 포함 된 프레임 워크를 사용하지 않고 명확하고 적절한 탐색 기능을 갖추고 있지 않으면 원숭이를 시작하는 것이 좋지 않습니다. 기본 기능. 내가 사용한 것을 보았을 때, 다른 브라우저가 자바 스크립트와 호환되지 않거나 세션이 항상 올바르게 저장되지 않는 문제가 거의 있었으며 누군가가 실수로 버튼을 눌렀을 때 예상대로 계속 진행되지 않는 경향이 있습니다.
"빈번한"사용자가 뒤로 단추를 누르는 방법을 할인하지 않거나 단순히 "깨기"하는 것이 "좋은 생각"이 아니라는 다른 제안을 제안합니다. 뒤로 단추는 사용자를 사용자 앞에 놓아야합니다. 그들이 지금있는 곳에 도착했다. 많은 경우에 한 번의 링크 클릭으로 되 돌리지 않는 것이 더 의미가 있고 더 유용합니다 (구현하기가 훨씬 쉬울 수 있습니다). 예를 들어 사진 앨범을 찾아보십시오. 사용자가 한 번의 클릭으로 앨범을 선택하면 축소판 그림이 표시됩니다. 썸네일을 다시 클릭하면 다음 / 이전 링크가있는 사진이 표시됩니다. 이 시점에서 사용자는 앨범을 탐색합니다. 완료되면 다시 클릭합니다. 이 시점에서 이전 그림보다 축소판 그림으로 돌아가는 것이 더 편리하고 직관적입니다.
요컨대, 뒤로 버튼은 무언가를 수행해야하지만 정확히 수행 해야하는 것은 응용 프로그램에 따라 다릅니다.