히어로콘텐츠 6期 인터랙티브 記事에는 讀者가 直接 인터랙션을 할 수 있는 要素들을 많이 넣었다. < 그들이 救急車를 탔던 날 > 記事에서는 患者가 移送되는 데 걸린 時間을 讀者들이 推測해보도록 時計바늘을 돌려보게 한다든지, 受話器 아이콘을 클릭해 119救急隊가 病院에 電話를 돌린 回數를 맞춰보도록 했다. < ’漂流’ 속으로 > 記事에는 讀者가 畵面을 돌려볼 수 있는 360度 映像을 活用했다.

이와 같은 인터랙티브 記事를 만들 때 마주하는 問題가 있다. PC를 利用하는 讀者와 모바일을 利用하는 讀者가 똑같은 經驗을 하게 하려면 어떻게 해야 할까. 이番 히어로콘텐츠 記事를 製作하며 作業했던 內容을 한 番에 整理해보고자 한다.

웹디자인 方式은 反應型과 適應型 두 가지가 있다. 反應型 作業은 웹 페이지의 디자인과 레이아웃이 畵面 크기에 따라 自動으로 맞춰지게 하는 作業이고, 適應型 作業은 感知된 機器를 基盤으로 미리 만들어진 디자인과 레이아웃을 가져오는 作業이다. 둘 다 長短點이 있지만, 筆者는 適應型으로 作業했다. 記事의 特性上 멀티미디어 資料가 많이 들어가기 때문에 追後에 생길 수 있는 로딩이슈를 防止할 수도 있고, 機器에 따라 맞춰진 UI를 통해 웹사이트의 機能도 向上 시킬 수 있었기 때문이다. 또한 自社의 홈페이지에 미리 짜여져 있는 UI와도 簡便하게 맞춤 作業을 할 수 있게 해준다. 反應型 作業으로 作業을 할 詩에는, 畵面의 크기에 맞추어 UI가 바뀌기 때문에 웹사이트의 機能이 低下될 뿐만 아니라 더 많은 機器에서의 테스트가 必要하다.

適應型 作業은 위에서 敍述했다시피 모바일과 PC 디자인이 다르기 때문에 基本的으로는 css의 미디어 쿼리를 使用한다.

이때 max-width는 畵面의 너비를 뜻하는데, 1300px과 1024px은 PC의 다양한 모니터들을 위해, 그리고 876px과 480px은 태블릿과 모바일을 위한 너비다. 디자인은 모바일과 PC 두 種類뿐이지만, 너비마다 보이는 差異가 있기 때문에 若干의 사이즈 調整을 위해 저렇게 다양한 미디어 쿼리 作業이 이루어진다.

미디어쿼리 作業 後, 디자인대로 잘 보이는가 싶던 畵面은 <그들이 救急車를 탔던 날> 技士의 모바일 버전에서 아래가 잘려나가고 있었다. css에서 使用한 vh라는 單位 때문이었었다. vh는 viewport height의 略字로, 보이는 部分의 높이를 單位로 設定해준다. 하지만 모바일에서는 viewport(보이는 畵面) 안에 url 住所窓과 下端 내비게이션 바가 들어가기 때문에 디자인대로 나오지 않게 된다. 그렇기 때문에 JavaScript를 使用하여 vh라는 單位를 다시 設定해주어야 한다.

위에서 보다시피 window.innerHeight라는 函數로 畵面의 높이를 다시 計算해서 vh를 設定해주는 作業을 하면 된다. 그 後 文書 內에서 vh를 使用할 때 呼出하여 使用할 수 있도록 setProperty로 ‘--vh’를 計算된 vh 값으로 再設定해준다. 以後 css에서 1vh를 calc(var(--vh), 1vh)로 바꿔주면 모바일에서도 제대로 作動하는 것을 確認해 줄 수 있다.

위에 나온 iOS는 애플 製品에 들어가 있는 運營體制다. 該當 運營體制는 webkit이라는 브라우저 엔진을 利用하는데, 이 webkit에 맞게끔 css가 適用되기 위해 -webkit- 이라는 接頭語가 存在한다. 以外에도 firefox 브라우저를 위한 -ms- 接頭語나 오페라 브라우저를 위한 -o- 接頭語 等이 存在한다. 브라우저마다 다른 렌더링 엔진을 맞추기 위한 크로스 브라雨徵을 위해서는 이러한 接頭語가 必須다.

하지만 이렇게 接頭語를 붙이더라도 適用이 안 되는 屬性들이 있는데, 이런 屬性들은 事前에 can i use 라는 사이트를 利用해 該當 屬性이 어디까지 支援되고 있는지를 確認해야 한다.

以外에도 브라우저 內部 事情으로 인해 제대로 作動하지 않는 屬性들도 存在한다. 바로 position의 sticky라는 屬性이다. 元來 sticky 屬性은 스크롤 詩에도 該當 要素가 viewport 內에 固定되어야 할 때 쓰는 屬性인데, iOS에서 이 屬性을 使用할 時에 z-index가 제대로 適用되지 않는 問題가 發生한다.

위 問題를 解決하기 위해, 指導 部分에 transform의 translateZ(0) 屬性을 追加하고, 텍스트 박스 部分에 transform의 translate3d(0, 0, 0) 屬性을 追加해 各 要素들이 쌓이는 順序를 再整備 해주었다.

위 過程을 거쳐 結局 제대로 된 畵面을 얻을 수 있었다. 이처럼 다른 브라우저 內의 事情으로 畵面이 設定한 디자인과 레이아웃처럼 나오지 않을 수 있기 때문에, 크로스 브라雨徵 作業과 最大限 다양한 브라우저에서의 테스트 作業은 必須다.

몇몇 이슈들을 除外하면, 大部分 모바일과 pc 相關없이 css 內部 作業을 통해 無理없이 모든 讀者들이 같은 經驗을 할 수 있다. 하지만 JavaScript를 통한 機能 作業은 다르다. PC에서 제대로 作動하던 機能이 모바일에서 動作하지 않을 수도 있기 때문이다.

그 理由는 모바일과 PC의 가장 큰 差異인 “마우스”의 有無 때문이다. PC에서 잘만 클릭이 되던 것들이 모바일에서는 클릭이 안 되는 現象이 일어나는 것이다. 特히 <그들이 救急車를 탔던 날> 記事에서 인터랙션 要素를 많이 넣다 보니 테스트를 할 때 삐걱거리는 部分이 많았다.

問題를 解決하기 위해 于先 모바일과 PC를 區分하는 코드를 짜야겠다고 생각하고 實行에 옮겼다. 모바일로 쓰이는 機器들을 한곳에 모아 user Agent(使用者의 機器 情報를 包含한 內臟 函數) 內에 그 機器의 이름이 包含되어 있다면 모바일로 認識하게 하는 것이 첫 試圖였다.

하지만 위 方法으로는 모바일을 全部 區分해 낼 수 없었다. 世上에 存在하는 모든 모바일 機器들을 다 적을 수 없기 때문이었다. 그래서 찾은 다른 方法은 바로 터치포인트의 個數로 모바일을 區分하는 것이다.

位 코드처럼 터치되는 포인트의 個數가 0보다 크다면 모바일로 認識하게 코드를 고쳐놓았다. 勿論 위 方法도 터치가 되는 노트북이나 태블릿__ 機器를 듀얼모니터로 쓰는 境遇를 모바일로 認識해서 問題가 생기긴 한다. 하지만 PC에서 생기는 問題이기도 하고, 元來의 目的인 모바일을 區分해내기에는 最適의 方法이었다.

위에서도 言及했다시피 모바일에서는 마우스가 없다. 그렇기 때문에 마우스와 關聯된 이벤트들을 모바일이냐 아니냐에 따라 區分해주어야 했다. 例를 들어 마우스가 클릭된 後 移動할 때 PC에서는 mousemove 이벤트를 써야하지만 모바일에서는 touchmove 이벤트를 써야 한다.

따라서 위에서 適用한 isMobile 코드를 使用해 各各의 이벤트를 하나의 變數로 管理하도록 코드를 作成했다. 하지만 여기서 그친다면 如前히 모바일에서는 願하는대로 動作하지 않게 된다. 畵面 內에서 使用者가 클릭 또는 터치한 位置를 設定할 때도 差異가 存在하기 때문이다.

처음에는 터치가 안되길래 뭘 잘못했는지 알아내느라 時間이 많이 걸렸는데, console 窓을 통해 어디서 안 되는 건지 變數들을 全部 確認하다 보니 모바일에서 pageX라는 값을 認識하지 못하는 것을 알 수 있었다. 그래서 該當 內容을 모바일에서 認識할 수 있게끔 changedTouches[0].clientX로 바꿔 주었고, 페이지가 正常的으로 作動하는 것을 確認할 수 있었다.

위와 같이 PC에서는 正常的으로 認識 되지만, 모바일에서는 認識이 되지 않는 코드들이 間或 存在한다. 이런 코드들을 걸러내기 위해 事前 모바일 테스트 作業은 必須다. 또한 똑같은 일이 反復되지 않도록 記錄하여 다음 프로젝트에도 對備하고 있다.

모든 讀者가 PC, 모바일에서 同一한 經驗을 할 수 있도록 힘쓰고 있지만, 아직도 모자란 部分이 많다. 每番 프로젝트를 할 때마다 어떻게 하면 이러한 問題들을 解決할 수 있을지 苦悶하고, 會議하고, 適用시키는 一連의 過程들을 通해 成長하고 있다. 다음 프로젝트에서는 좀 더 成長한 모습을 보여주도록 關聯 內容을 더 學習하고자 한다.