- 상호작용의 디자인에 대한 작은 비밀 하나는 사람들이 시각적인 미에 대해 여러분이 생각하는 것만큼 반응하지 않는다는 것. 사용한 색이나 사각형 또는 둥근 모서리, 또는 기울어졌거나 평평한 배경 등이 첫인상 형성을 돕지만, 그것이 사용자의 경험을 향상시키는 데 큰 역할을 하는 것은 아님. 사용자는 좋은 디자인의 가치를 안다. 하지만, 시각적 미에 대해서는 금방 무관심해지고 대신 즉시 배치(인포메이션 디자인)로 관심을 집중함. 이것은 분류체계라고 불려지는 것들이 콘텐츠를 얼마나 쉽게 발견하게 하고 업무수행을 얼마나 직관적이게 하는지에 대한 것이다.
- 모바일 웹은 어떠한 모바일 디바이스에서는 사용가능하고 실제로 동작하는 유일한 플랫폼으로서, 어느 기기에서나 같은 표준과 프로토콜을 따르며, 테스크톱용 웹과도 같은 표준과 프로토콜을 따름. 모바일 웹은 어플리케이션 개발자가 통제할 수 있는 유일한 유통채널임. 모바일 웹은 짧은 컨텍스트 기반의 인터랙션을 더 긴 데스크톱 기반의 작업과 연결시킬 수 있는 가장 좋은 방법임. 모바일 웹은 배우기 쉽고, 만들기도 제일 쉽고, 가장 표준화되어 있으며, 많은 이들에게 열려 있고, 배포하기도 쉬운 플랫폼이다.
- 핵심은 품질이다. 그러나, 이는 수년동안 해결되지 않았다. 이러한 어려움은 조만간 사라질 것이고, 몇년 후에는 대수롭지 않게 될 것이다. 모바일웹은 장치 단편화라는 어려움이 있지만, 최상의 경험을 위해 해결해야 할 일의 복잡도는 네이티브 어플리케이션의 경우보다 훨씬 낮다
- 네이티브 어플리케이션을 만들길 원하는 또 다른 이유 중 하나는 장치에 저장된 데이터를 사용하기 싶기 때문이다. 데이터는 사용자 주소록, 사진, 이메일 메시지 혹은 다른 어플리케이션의 데이터일 수 있음. 파일 시스템에 접근하는 것은 분명 보안 및 프라이버시 차원에서 큰 이슈임. 잘못된 어플리케이션은 잠재적으로 데이터를 바꾸거나, 더 심한 경우 지워버릴 수도 있음. 혹은 바이러스에 감염된 어플리케이션이 저장된 연락처를 이용해 다른 여러 휴대폰에 바이러스를 퍼뜨릴 수도 있음. 이는 모바일 어플리케이션 인증이 보급되기 전에는 꽤 자주 발생하던 일이었음. 모바일 장치는 점점 더 많은 비즈니스 계약, 지인정보, 개인정보를 담고 있는 매우 개인적인 모바일 컴퓨터가 되고 있음. 어플리케이션을 넘나드는 방식으로 정보를 이용한다는 생각은 매우 매력적임. 위험이 전혀 없는 것은 아니지만, 저장된 데이터를 사용하는 것은 사용자에게 컨텍스트와 유관한 정보를 제공하는 가장 강력한 방법임. 개발자들은 저장된 정보를 제한된 수준으로만 사용해야 한다는 것을 염두에 두어야 함. 우리는 어플리케이션으로 유용한 서비스를 제공하려 하였지만 사용자로부터 허가받지 않은 채 사용자의 데이터를 너무 많이 사용해서 피싱, 스팸성 정보를 오해되었던 적도 있음. 어플리케이션을 배포할 때 잘못된 인식은 중대한 영향을 끼칠 수 있음. 이 영향은 매출감소로 나타날 것이며, 통신사가 접수한 불만이 많아지면 아예 어플리케이션 스토어에서 방출되는 일도 일어날 수 있음. 분명한 것은 절대 사용자 동의 없이 사용자 데이터를 사용해서는 안된다는 것. 너무도 많은 모바일 어플리케이션이 사용자의 동의 절차를 무시하고 있음. W3C가 모바일 벤더들이 참조할 수 있는 표준화 API를 정착시키고자 한 노력들이 조금씩 결실을 맺고 있기는 하지만 아직은 미흡한 단계임
- 네이티브 어플리케이션을 만드는 마지막 이유는 사용자들이 오프라인이거나 무선통신망 밖에 있을 가능성이 높다는 것. 도시에 사는 사람들은 그럴 가능성이 높지 않고 농촌지역에서도 네트워크의 사각지대는 점차 감소하고 있음. 그렇지만 접속할 수 없는 환경이 분명 존재하며 어플리케이션은 이것을 고려하여 만들어져야 함. 사용자 컨텍스트와 사용자가 언제 여러분의 어플리케이션을 사용할 가능성이 높은가를 염두에 두어야 함. 비행기에서는 모바일 게임을 할 가능성이 상당히 높음. 산길지도 어플리케이션은 통신이 잘 안잡히는 지역에서 쓰일 가능성이 상당히 높음. 모바일 여행가이드는 외국에서 사용되어 로밍이나 국제통화료가 부과될수도 있을 것임. 이들 각 어플리케이션은 무선통신에 접속되지 않은 상태에서 일반적 기능을 수행할 수 있는 오프라인 모드를 갖추어야 함.
- HTML5를 지원하는 모바일 브라우저는 오프라인 어플리케이션 구현을 가능하게 하지만 사용자들에게는 이점이 아직 분명히 와 닿지 않음. 점점 더 많은 모바일 브라우저에서 오프라인 저장 기능을 지원하자, 모바일 장치가 오프라인일 때에도 모바일 웹 어플리케이션이 작동할 수 있을 때 사용자가 이를 알 수 있도록 하는 메타포어나 규약이 필요하게 되었음. 많은 네이티브 어플리케이션은 쉽게 신뢰성 잇는 네트워크 접속환경을 가정하고 있음. 어플리케이션은 최적의 무선신호 및 빠른 네트워크 환경이 갖추어진 폐쇄적 여건안에서 최상의 환경을 기준으로 디자인되는 경우가 많음. 태생적으로 모바일 장치는 최적의 환경에서 순식간에 최악의 환경으로 이동함. 네이티브 어플리케이션은 최악의 환경에서 테스트되어야 함
- 자바스크립트와 Ajax사용은 보통 때에 비해 휴대폰 배터리를 4~5배 정도 더 소모시키기 때문에 제외되어 왔음. 똑똑한 모바일 하드웨어 개발자들은 그이유를 다음 두가지라고 설명함
* 자바스크립트는 프로세스를 많이 사용하기 때문에 배터리를 더 많이 소모한다
* Ajax는 통신망으로부터 더 많은 데이터를 가져오기 때문에 전파, 배터리를 더 많이 소모한다
여러분이 여분의 배터리를 갖고 다니지 않는다면, 최신 모바일 웹에 접속하는 대가로 한두시간마다 충전을 해야할 것임. 애플사나 다른 오픈소스 웹킷 브라우저는 모바일 디바이스에서 믿을 수 없을 정도로 효율적인 자바스크립트를 릴리즈함으로써 엄청난 발전을 이루어냄. 모바일 브라우저가 개선되고 배터리도 나아지고 기기도 더욱 강력해지면서 이 문제는 빠르게 해결되고 있음
- 마크업은 모바일 브라우저에서 콘텐츠를 읽을 수 있게 만들기 위해 사용됨. 보통 마크업이라 하면 웹언어인 HTML을 떠올림. 모바일에서 우리는 기기나 프로젝트의 크기, 범위에 따라 약간 다른 마크업 언어를 사용. 과거로 거슬러 올라가, 96년에 HDML이 모바일 웹의 초기선구자 중 하나인 오픈웨이브에 의해 만들어졌음. 곧이어 노키아의 TTML과 다른 제조사 독점적인 마크업 언어가 나왔고, 뒤이어 WAP(wireless application protocol)포럼이 WML(wireless markup language)을 98년 만들었으며 이것은 WAP 1.0에 포함되었음. 웹분야에서 온 많은 사람들이 모바일 웹이 데스크톱 웹과 똑같이 동작하고 같은 프로토콜에서 작동할 것이라 추측하지만, 실제는 그렇지 않음. 모바일 웹이 작동하는 스택이 WAP이며 자체적인 프로토콜이다. WAP와 웹이 동일하다고 말하는 것은 여자와 남자가 같다는 말이나 마찬가지임. 남녀 모두 인간이고 기수적으로 그들이 작동하는 원리는 서로 비슷함. 그러나 그들은 근본적으로 명백한 차이점이 있음. 요즘 모바일 디바이스들은 데스크톱 컴퓨터와 점점 비슷해지고 있음. 그러나 통신사업자가 제공하는 모바일 웹에서는 WAP의 잔재가 많이 남아있음. WML은 콘텐츠에 대한 마크업을 위해 엄격한 형식을 적용하고 있으며, 카드 즉 페이지로 구성되어 있어서, HTML보다는 XML과 비슷. 개별 페이지를 카드로 부르기 때문에 이것들이 모여서 완성된 WML사이트는 데크라고 불리며, 이는 오늘날 모바일 웹사이트를 부르는 말이기도 함. 그러면서 마크업 언어는 XML문법으로부터는 멀어지고 NTT도코모의 아이모드폰에서 처음 사용된 Chtml 그리고 Ihtml처럼 HTML문법에 가까워진다. 그 다음 XHTML 그리고 XHTML Basic이 나오게 됨. 그리고 이는 XHTML-MP로 진화. 이것은 모바일 분야를 제외한 다른 분야에서는 우리 모두가 잘 알고 선호하는 XHTML을 모듈화 시킨 것임. Open Mobile Alliance9OMA)사에서 XHTML-MP를 WAP2.0프로토콜의 주요 언어로 지정함에 따라 이 마크업은 02년부터 휴대폰에서 많이 사용되게 되었음
- Server side includes : 일반적인 HTML태그 외에 웹 서버에서 제공하는 특별히 확장된 기능들로, HTML을 보완하려는 의미에서 개발됨. HTML문서는 서버에서 브라우저로 리퀘스트를 보내면, 그 브라우저가 전달받은 HTML문서의 각 태그를 해석해서 화면을 출력하지만, SSI는 서버에서 먼저 해석한 후 브라우저로 보내짐. 따라서 HTML의 태그 외에 SSI에서 별도로 제공하는 태그들을 사용할 수 있음.
'IT' 카테고리의 다른 글
| 플랫폼이란 무엇인가 (0) | 2014.10.03 |
|---|---|
| 핸드폰 연대기 (0) | 2014.10.03 |
| 소셜 미디어 바이블 (0) | 2014.10.03 |
| 모르면 손해보는 IT 이야기 (0) | 2014.10.03 |
| 빅데이터@워크 (0) | 2014.09.20 |
