페북이나 트위터가 일상화되면서 웹페이지의 모바일 접근성이 많이 중요해졌는데, 아직 많은 웹사이트들이 대응을 잘 못하고 있는 듯 하다.
1단계 : IE에서만 잘 보이는(?) 홈페이지
2단계 : 크로스 브라우징 처리가 된 홈페이지. 하지만 여전히 PC기반
3단계 : 모바일용 사이트를 따로 제공하지만 컨텐트는 동기화되지 않음. 내용 업데이트를 따로따로.
4단계 : PC와 모바일 모두 컨텐트가 동기화된 사이트. 하지만 별도의 URL
5단계 : 하나의 URL로 어떠한 기기에서도 모두 접근 가능하며 기기별로 맞춰진 컨텐트와 디스플레이 제공(하나의 URL이 아니더라도, 해당 플랫폼용 페이지로 리다이렉트/리렌더링해주는 것까지 포함)
4단계까지 못오는 경우도 많거니와 4단계에서 끝내는 경우도 많음. 얼마전까지는 이 정도만 해도 충분했을 텐데…
페북, 카톡, 트위터 등 크로스플랫폼상에서 링크가 유통되는 서비스들이 많아지다보니, 모바일용 링크를 PC에서 본다든가, PC용 링크를 모바일에서 보는 경우가 많아지게 됨.
아까 어느 페친의 포스트를 보다가, ‘위클리비즈’ 링크가 걸려있었는데, 이게 모바일용 페이지였음. PC에서 클릭하니, 스마트폰 전용 페이지라는 안내만 덜렁. PC용 페이지로 갈 수 있는 링크를 제공해주는 센스가 아쉬웠음. 좀 더 친절했다면, 디바이스와 브라우저를 인식해서 그에 맞는 페이지로 리다이렉팅해주거나. (하나의 HTML로 크로스플랫폼 만드는 건 기대도 안함.)
그럼, 어떻게 하면 모바일 접근성을 갖추는 사이트를 만들 수 있을 것인가…
처음부터 잘 만들면 됨. <= 정답이긴 한데, 이렇게 이야기하면, 개발자는 기획자 탓을 하고, 기획자는 개발자 탓을 하겠지.
1) 브라우저 단에서 수습해보기
어느정도 제대로 구조화된 HTML로 짜여진 페이지라면, CSS와 JS를 플랫폼별로 별도로 만든 후, HTTP 헤더에 따라 선택적으로 로딩되게 하면 대략 가능하다. 여기에서 중요한 건 선택과 집중인데, 과감하게 모바일에서는 필요없는 것들을 “안보이게” 가려버리는 것. 물론 이러려면 HTML단에서 이미 구조적으로 짰어야 했다는 동어반복의 문제가…
이에 대해 아주 간단한 꼼수를 부려보자면, 모바일 페이지에서 보여야 하는 부분들만 div 태그로 감싸주고 클래스 이름으로 “mobile”을 넣어주자. (내용때문이 아닌 표시를 위한 div태그를 추가한다는게 불만이고, 기존의 의미론적 클래스 구조이름에 mobile을 덧붙여 넣어주는 방법이 정석이겠지만, 그렇게 코딩했으면 이 문제가 발생하지도 않겠지.)
그리고 모바일용 CSS등에서는 모든 태그를 display:none; 해버린 후, mobile 클래스만 모바일 환경에 맞게 재정의해주면 됨.
2) 서버 단에서 수습해보기
첫번째 방법은 다 좋은데, 회선대역 낭비가 발생하므로, 서버단에서 HTTP 리퀘스트가 들어올 때, 리퀘스트 정보에 따라, 아예 HTML 출력을 선별적으로 해주면 됨. 페이지를 새로 만들어도 좋고.. 사실 더 좋은 방법은, 뿌려줄 컨텐트 모듈 단위를 플랫폼 별로 분리해두면 됨. 예를 들어 배너광고 1번 영역은 모바일에서는 출력하지 않는다든가, 플래시사이드메뉴는 모바일용 링크메뉴로 대체출력한다… 하는 식으로.
통짜코딩으로는 힘들고, 모듈별 템플릿을 쓰던가, 프레임워크를 사용하면 좀 쉬워지겠지… 사실 이것도 애초에 이런 걸 이용하지 않았을 때에는 할 말 없지만.
3) 이런 걸 기획자가 결정(?)해야 하는가, 개발자가 결정(?)해야 하는가 하는 부분이 남을텐데…. 한국에서는 기획자가 기술을 모르는게 당연한거니까.. 그냥 포기하고 개발자들이 하세요. 발주시방서가 존재하고 그대로 만들면 땡인 에이전시나 SI용역이라면 그려준 대로 만드는 걸로 충분하겠지만, 제3자에게 서비스하는 것을 목표로 하는 자사 서비스라면, 왜 이런 거 처음부터 이야기안했냐고 궁시렁대봤자 아무 소용없음. 한국의 기획직군은 기술설계가 아닌 화면디자인과 고객응대에 특화되어 있는 제품디자이너이니까 인사이드 설계는 개발직군이 해야 함. 사용자의 불평 한마디는 기획자의 철학이나 개발자의 노고 따위보다 더 소중한 정언명령이니까 받아들일 수 밖에.
0개의 댓글