abulaphiaa

Progressive enhancement는 어떤 웹 브라우저에서든지 그것의 성능과 상관없이 당신의 컨텐트에 대한 접근을 보장해 주기 위해 웹 테크닉들을 Layered Fashion으로 사용하는 방법입니다. 이것은 “우아한 후퇴 (Graceful Degradation)”이라고도 하는데, 당신이 한가지 상황에서 이상적인 경험(one ideal experience) 뿐만 아니라 누가 컨텐트를 보느냐에 따라  다양한 환경에서 덜 이상적일 수도 있는 경험을 창조해 낸다는 것을 의미합니다.

Progress Enhancement는 브라우저에서 렌더링했을 때 어떤 스타일도 정의되지 않았거나 markup된 것만 보이는 경험이 중심에 있습니다. 여기에서 기본 가정은 어떤 단말에서든지 이 정도 수준의 Presentation은 보여줄 수 있다는 것입니다. 그러나 이것이 잘 동작하려면

• markup이 시맨틱(symantic)하게 짜여져야 한다는 점, 다른 말로 하면 presentation이 없는 환경에서도 markup이 쓸모있는 상태를 유지해야 한다는 점입니다.
• 다음 단계에서 우리의 markup과 가장 기본적인 스타일링 테크닉을 지원하는 최저 사양의 단말( lowest common denominator devices)에 적용하기 위해 기본적인 스타일링 테크닉을 추가합니다.
• 우리는 외부에서 최상의 가능한 경험에 도달할 때까지 계속해서 layer를 추가합니다.  나는

나는 가능한 한 컨텐트의 수정 (content adaptation)없이 여러분의 프로젝트를 시작하라고 항상 권고하지만, 어떤 경우 컨텐트의 수정이 필요할 때도 있습니다. 갑작스럽게 하나의 사이트의 Multiple Version을 만드는 것보다는 우아하게 후퇴할 수 있는 One Code Base로 시작하는 것이 훨씬 쉽고 빠릅니다.

Progressive Enhancement 방식을 사용해서 개발하면 당신의 사이트에 데스크탑 레이어를 추가할 수 있다는 점도 덧붙이고 싶습니다.  모바일 컨텍스트용으로 설계된 Layer 위에 데스크 탑 레이어를 구축할 수 있기 때문에 이러한 접근방식에는 아무런 문제도 없습니다.  이것은 사실 아래 그림에서 보듯이 내가 오리지날 Mobile 2.0 이벤트 사이트 개발시 적용한 방식입니다. 일단 유용한 Mobile Experience를 창조한 후 서로 다른 Viewing Context를 지원하기 위해 multiple layer를 쌓아가면서 데스크탑에서 끝나게 됩니다.

Progressive Enhancement Case

만약에 당신이 데스크탑에서 먼저 시작한 후 그로부터 유용한 모바일 Experience를 만들어 내는 방식으로 거꾸로 일을 진행하면 문제가 발생할 것입니다. 이렇게 하면 열에 아홉은 어색하고 거의 쓸모없는 사이트의 버전이 탄생하여 로딩하는데 속도도 느려지고 비용도 많이 소요되게 될 것입니다.

Mobile Progressive Enhancement

모바일 웹 초기 개발시부터 내가 사용해 왔던 팁과 트릭에 대해 좀더 말씀 드리면,

• 당신의 markup을 항상 Symantic하게 짜세요. 나는 코딩한 대로 페이지가 렌더링되는지 내가 직접 눈으로 확인하기 위해 live preview window를 항상 열어놓고 작업합니다. 나는 이런 방식으로 스타일쉬트가 전혀 적용되지 않았을 때에도 페이지가 항상 usable한지 확인합니다.
• Device 계획을 수립하세요. 코딩을 시작하기 전에 어떤 device class들을 지원하고 싶은지 정확히 인지하고 있어야 합니다. Device Plan에 따라 당신이 페이지를 코딩하는 방식이 달라질 수 있습니다.
• 당신이 코딩을 시작하기 전에 최저 사양과 최고 사양의 단말에 적합하게 미리 설계하고, One Code Base로 두가지 버전을 만들어 내는 방식을 Visualize해보세요.
• 서로 다른 모바일 단말에서 시작부터 끝까지 테스트하는 방식으로 당신의 단계적으로 작업 (incremental work)이 의도된 단말에서 정확하게 디스플레이되는지를 확인하세요.
• 데스크 탑 레이어를 추가할 계획이라면 항상 모바일 버전을 먼저 만드세요.

The Javascript

JavaScript의 구조

좋습니다. 이제 가장 중요한 부분이 Javascript에 대해 살펴봅시다. 내가 몇년 전 “Mobile Design and Development“라는 책을 썼을 때만 하더라도 cross-platform Javascript에 관해서는 거의 논의가 이루어지지 않았습니다. 이것은 HTML5도 마찬가지 입니다.  그 이후 많은 일이 벌어졌는데, 불과 2년만 해도 Javascript는 (iPhone 이외의) 모바일 단말 지원시 사용되는 대수롭지 않은 툴에 불과했으나 (spotty mobile support) 지금은 User에게 데이타와 로직, interaction을 제공하기 위해 우리가 사용하는 일차적인 수단(primary means)이 되었습니다.

이러한 상전벽해는 HTML5로의 이행과 동시에 이루어졌습니다. 다른 말로 하면 HTML5는 많은 새로운 기능들을 가지고 있으나 JavaScript가 없다면 사용할 것이 거의 없습니다.  User의 물리적 위치를 look up하고 싶나요? JavaScript로 할 수 있습니다. 오프라인 스토리지에 데이타를 저장하고 싶은가요? Javascript로 하십시요.

어떤 사람들은 이러한 구별(distinction)이 별것 아니라고 생각하지만 나는 큰 의미가 있다고 믿습니다. Scriptaculous, Prototype, MooTools. 그리고 jQuery와 같은 Javascript 프레임워크가 없었던 시절을 생각해 보세요. 나는 JavaScript 짜는 일을 좋아하는 사람을 본 적이 거의 없습니다. 그것은 허드렛일이었습니다. 이러한 프레임워크들로 인해 우리의 삶은 의심할 여지 없이 훨씬 쉬워졌으며  Web의 얼굴 자체도 변화되었습니다. 반면 이러한 프레임워크들의 도움없이 Javascript를 짤 수 없는 개발자들도 많아 졌습니다 (can’t write Javascript without the aid of these frameworks).

모바일 세계에서 이것은 문제입니다. 모바일 web app 개발에서 가장 어렵고 시간이 많이 소요되는 일은 테스트하는 것입니다.  당신이 사용한 모든 테크놀로지 하나하나를 테스트할 수 있게 만들어야 합니다. 무엇이 어떻게 동작하는지를 잘 모른다면 단순한 버그를 발견하는데 수백줄의 코드를 들여다 봐야하는 등 당신의 시간과 노력을 잡아먹는 블랙홀을 만들게 됩니다.

만약 당신이 하나의 플랫폼만 지원할 계획이라면 이것은 그럭저럭 참아 낼 수 있지만 다양한 플랫폼을 지원하려면 복잡성으로 인해 개발과 테스트에 훨씬 더 많은 시간(order of magnitude)이 소요됩니다.

나는 Murphy의 법칙이 모바일 개발과 테스트에 적용되는 원칙이라고 절대적으로 확신하고 있습니다. pinch/zoom에서 우리는 모바일 테스팅에 관한 사실상의 규칙을 가볍게 생각한 적이 없습니다 – 만약에 우리가 무엇인가를 사용하기로 했다면 만약 그것에 문제가 생겼을 때 그것을 고치는데도 그만큼 헌신해야만 했습니다.

이제 Javascript 스택의 3가지 파트를 살펴 보겠습니다.

Hybrid Scripts

이 스크립트들은 코어 스크립트와 Device SDK간 갭을 줄여 줍니다 (bridge the gap between core scripts and device SDK). 하이브리드 스크립트는 당신이  HTML5 App을  UIWebView나 PhoneGap같은 네이티브 래퍼(native wrapper)로 싸려 할 때 필요한 스텝입니다.  당신은 하이브리드 스크립트를 당신이 지원하고자 하는 각각의 플랫폼에 최적화시킬 필요가 있습니다. 내가 아는 한 이와 같은 하이브리드 컨텍스트에서 phonegap.js는  다양한 플랫폼에서 동작을 지원하는 유일한 일반적인 스크립트입니다.

Core Scripts

코어 스크립트는 당신의 앱중에서 모든 플랫폼에서 사용되는 공통의 컴포넌트(common component of you app available in every platform)입니다.  웹브라우저를 통해 App에 접근했을 때 코어 스크립트는 native SDK가 해야할 Function까지 수행하는 이중의 역할을 하게 됩니다(serve double duty). 이것은 당신의 App.이 HTML5 페이지들을 어셈블하고 렌더링하는데 필요한  내부의 로직(internal logic)같은 것이라고 생각하면 됩니다. 이때 jQuery같은 풀 프레임워크를 편리하게 사용할 수 있으나 대개의 경우(tyupically) 우리는 대부분의 job을 수행함에 있어  micro frameworks의 사용을 추천드립니다.

Device Scripts

마지막으로 Device Script는 Device Native Behaviour를  Javascript로 에뮬레이션하는 일을 합니다.  Device Script의 가장 좋은 사례로  jQTouch가 내 머리 속에 떠오르는데, 이것은 jQuery를 사용하여  iPhone의 native behaviour와 애니메이션을 흉내 냅니다.  jQTouch는 Device를 구별하지 않으므로 iOS의 메소드를 안드로이드를 비롯한 다른 모바일 플랫폼에도 그대로 사용하는데, 다른 플랫폼의 User들은 이것을 별로 좋아하지 않습니다. 그러므로 우리가 지원하고자 하는 각각의 플랫폼별로 unique하게 device script를 짤 필요가 있는지를 사전에 판단해야 합니다.

The CSS

Presentation Layer로서 CSS의 구조

CSS는 당신의 App의 Presentation Layer입니다. 개발자들은 CSS를 컴퓨터 랩의 art student들과 같이 어플리케이션 개발시 디자이너들이 생성해야 할 허드렛일 정도로 생각합니다. 그러나 Presentation은 HTML5 모바일 App.에서 가장 중요한 부분입니다. Apple, Nokia, Miscrosoft와 같은 회사들은 뛰어난 모바일 User Experience를 창조해 내기 위해 수백만달러를 쏟아 붙습니다. 물론 우리는 이렇게까지 할 필요는 없지만 어떤 사람들은 의도적으로 이것을 건너 뛰기도 합니다. 이것은 HTML5 모바일 App 개발시  당신은 자신만의 Experience를 맨땅에 헤딩하면서 창조해낼 필요가 있다는 것을 의미합니다.

오늘날 Mobile Experience에 대한 고객의 요구를 수용하는 것은 그렇게 사소한 문제가 아닙니다. CSS는 이러한 고객의 높은 기대를 충족시키기 위해 당신이 사용하는 코드입니다.

만약 당신이 만드는 HTML5 App.을 차에 비유한다면, CSS는 외관, 모델, 칼러 그 이상이며 인테리어 디테일까지도 포함합니다.  당신이 차에 타면 패브릭이냐 가죽이냐만 눈에 띄지 않을 것입니다. 우리는 디테일에도 주목하게 됩니다. 운전대가 손에 잡히는 느낌, 대쉬보드의 디자인, 스테레오 컨트롤을 위한 거리 등을 알아채게 됩니다. 이 모든 것들이 우리의 driving experience에 영향을 줍니다.

Javascript는 결정적으로 우리의 App. Experience에 영향을 주지만 그것은 우리의 눈으로는 보이지 않는 방식으로 정교하게 동작합니다. 우리는 Javascript가 절대로 필요하지만 Top Gear Fan들의 말처럼 후드 밑에 감춰져 있는 파워가 우리의 Powerful Experience와 항상 동일한 것은 아닙니다 (Jeremy’sreview of the Ferrari 599 GTO).

Performance와 Presentation은 상호 조화롭게 동작해야만 합니다.

jQTouch, Sencha Touch 또는 jQuery Mobile과 같은 툴의 사용에 관심있는 사람들에게 나는 이러한 프레임워크들로부터 무엇을 정확하게 얻을 계획인지 질문하곤 합니다.  그러면 실제로는 주로 iOS의 미학을 에뮬레이션하는 “Device Theme” Stylesheet에 불과한 때가 많으며 기껏해야 여기에 Javascript 몇줄을 추가해서 iOS transition을 흉내내는 CSS Transforms을 수행하면 끝인 경우가 많습니다. 다른 Device aesthetic을 에뮬레이션할 때 CSS의 사용에 관심이 있는 사람은 거의 없습니다 (try finding a  CSS template for Android).

그러나 당신 App.이 다른 App.들과 구별되기를 원할 때가 있을 것입니다. 이때 default aesthetic과 단절하고 당신 자신만의 브랜드 스타일 가이드를 충족시킬 수 있도록 툴을 수정하고 싶다면, 당신의 App.을 처음 설계할 때부터 full CSS stack의 사용을 고려해 보세요.

Device Themes

위에서 언급했듯이 CSS는 플랫폼의 aesthetic을 에뮬레이션하는데 필요합니다. 이것은 User가 익숙해져 있는 Visual Language입니다. User들은 당신이 만든 App.의 인터페이스를 학습하는 대신 이러한 언어를 사용하여 태스크를 수행합니다. 최근에 세어본 바에 따르면 각 플랫폼마다 unique한 인터페이스 요소들이 100여개가 넘습니다. 당신이 무엇을 하고 있는지 정확히 알고 있지 않다면 당신 자신만의 언어를 새로 만들지 말라고 권유드립니다 ( I wouldn’t recommend inventing your own language unless you know what you are doing).

Sencha Touch, jQuery Mobile 등의 툴을 사용하면 이런 일을 할 수 있습니다. 이경우 당신의 App.은 플랫폼과 비슷하게 보이긴 하겠지만 당신 자신만의 look처럼 보이지는 않을 것입니다. 그러나 시작할 때 이런 툴을 사용하는 것이야 말로 당신 자신만의 언어를 만들기 위한 가장 좋은 방법이 될 수 있습니다 (using these tools as a starter can be the best route if you plan to construnct your own language).

Core Theme

Core Theme은 당신의 애플리케이션에서 재사용이 가능한 “가구”와 유사합니다. 이것은 당신이 필요로 하지만 보통은 눈에 잘 띄지 않는 특징이 있습니다. 나는 reset, layouts, typography, color 또는 image handling과 같은 presentation essential을 unique한 stylesheet로 분리시켜 놓고, 그것을 나의 코어 또는 브랜드 테마로 이용하는 것을 좋아합니다. 이러한 요소들은 당신이 어떤 플랫폼을 사용하든지 상관없이 항상 동일해야 합니다.  간단한 예를 들어 보면,  당신의 로고는 항상 동일한 방식으로 presentation되어야 합니다. 아마 당신의 툴바 칼라는 브랜드 칼라를 따라갈 것입니다. 브랜드와 툴바의 칼라 모두 당신의 Core Theme에 정의되어 있어야 합니다. 그러나 Device Theme에서 iOS용으로 툴바에 gradient effect를 추가했는데 이것이 안드로이드에서는 없는 효과일 수도 있다는 점에 대해 주의를 기울여야 합니다.

App Theme

마지막으로 App Theme은 당신의 App.에만 존재하는 presentation element를 의미합니다. 많은 프로젝트에서 이러한 요소들을 하나의 스타일쉬트에 통합시킵니다. 좋긴 합니다만 나는 당신의 Core와 App. element를 적어도개념적으로는 분리해서 유지하라고 추천드립니다. 이렇게 하면 나중에 디버깅할 때 편리합니다.

Conclusion

HTML5는 일을 할 수 있나요? 물론입니다. 나는 그것에 대해 논쟁하고 싶지 않습니다. HTML5로 일을 할 수 있나요 ? 당근입니다. 그러나…

• 시간이 필요합니다. 당신이 이전에 해왔던 어떤 프로젝트들보다 많은 시간이 걸린다고 보시면 됩니다.
• 그에 따라 더 많은 예산이 소요됩니다. 이것은 웹사이트가 아닙니다. 훨씬 더 많은 비용이 소요됩니다.
• 회사 내부에서 이것을 할 수 있는 개발인력이 존재하는지 먼저 확인하세요. 세상에서 이것을 매일매일 하는 노련한 전문가들에게도 이것이 어려운 문제라면, 당신의 팀도 당연히 어려울 것입니다.
• 툴들이 항상 존재하진 않습니다.  당신 자신의 툴을 스스로 만들어야 할 때가 꽤 자주 있습니다.
• 모든 옵션을 검토하세요. 테크놀로지에 대해 도그마적으로 접근할 경우 돈을 불필요하게 낭비하게 됩니다. 모바일에는 정답이 없습니다. 오픈 마인드를 유지하고 당신의 고객이 무엇을 원하는지에 집중하세요.