Mark Zuckerberg는 다음과 같이 말했습니다. “회사로서 우리가 저지른 가장 큰 실수는 HTML5가 기본이 아닌 HTML5에 너무 많이 투자한 것입니다. HTML5가 없었기 때문입니다. HTML5가 나쁘다는 것은 아닙니다. 나는 사실, 장기적으로, 그것에 대해 매우 흥분하고 있습니다.” 그리고 누가 여러 플랫폼에서 작동하는 단일 코드 기반 의 전망에 흥분하지 않을 것입니까?

SmashingMag에 대한 추가 정보:

• 프로그레시브 웹 앱 초보자 가이드
• 프로그레시브 웹 앱의 빌딩 블록
• Foundation For Apps에서 완전한 웹 앱 만들기

불행히도, Facebook은 HTML5가 구축하고자 하는 경험을 제공하지 않는다고 느꼈고 이것이 바로 경험에 관한 것입니다. 나는 Mark가 정말로 말하려고 했던 것은 그들의 가장 큰 실수가 사용자 경험 중심의 결정이 아니라 기술 중심의 결정을 내리는 것이라고 생각했습니다. 결국 우리는 고객에게 가치를 제공하는 결정을 내려야 하며 특정 기술을 고수하는 것은 일반적으로 이를 달성하는 최선의 방법이 아닙니다.

온라인 전용 전자 상거래 소매업체인 Beyond The Rack의 고객에게 있어 우리의 주요 목표는 훌륭한 사용자 경험을 제공하는 앱을 구축하는 것이었습니다. Zuckerberg와 마찬가지로 우리도 HTML5 경로를 따르기를 원했습니다. HTML5 웹 인터페이스로 작성된 앱에 대한 "한 번 작성, 모든 곳에서 실행" 접근 방식은 매우 매력적입니다. 그러나 앱이 사용자가 제품과 상호 작용하는 주요 방법이 되고 있는 오늘날의 세계에서 성능은 단순히 좋은 것이 아니라 경쟁 우위입니다.

그러나 앱의 모든 기능을 완전히 기본 인터페이스로 빌드해야 하는 경우는 거의 없습니다. 예를 들어 탐색 애니메이션을 웹에서 기본적으로 느끼도록 하는 것은 어려울 수 있지만 복잡한 애니메이션이 거의 또는 전혀 포함되지 않은 웹 페이지는 기본적으로 느껴지 면서 앱에서 쉽게 사용할 수 있습니다. 이것이 사용자에게 정말 중요한 전부입니다. 그런 다음 필요한 것은 "어쩌면 한 번 작성하고 모든 곳에서 실행될 수 있습니다. 기능에 따라 다릅니다..." 전략입니다.

요컨대, 기본 인터페이스와 웹 인터페이스 중에서 선택하지 마십시오 . 둘 다 사용하십시오.

이 글에서는 네이티브와 웹 콘텐츠를 혼합하여 네이티브 "느낌"이 나는 앱을 만드는 Beyond Rack용 앱을 구축한 경험을 안내해 드리겠습니다.

사례 연구: 랙 너머를 위한 앱 빌드

Beyond the Rack이 자체 앱과 고객을 위해 해결하고자 하는 문제를 결정하는 것이 중요했습니다. 각 기능에 대해 기본 또는 웹으로 전환할지 여부는 여기에서 자연스럽게 선택됩니다.

우리는 훌륭한 앱을 구축하려면 다음 세 가지 모두를 훌륭하게 수행해야 한다는 것을 깨달았습니다.

• 쇼핑 인터페이스
  Beyond the Rack은 온라인 전용 소매업체입니다. 따라서 판매 검색 및 구매를 위한 훌륭한 인터페이스를 갖추는 것이 중요합니다. 우리는 기본 앱을 구축하고 있었기 때문에 웹 경험이 제공할 수 있는 것 이상으로 나아갈 기회가 있었습니다.
• 공유 가능성
  Beyond Rack의 큰 수익 동인은 다양한 판매 품목을 친구들과 공유하는 고객이기 때문에 iOS, Android 및 브라우저 간의 공유가 최대한 원활하게 이루어지도록 해야 했습니다.
• 발견 가능성
  Beyond The Rack은 사용자에게 기간 한정 판매를 제공합니다. 따라서 사용자에게 빠르게 다가갈 수 있는 것이 매우 중요합니다. 푸시 메시지는 충성도가 높은 고객을 참여시키는 가장 좋은 방법을 제공하며 궁극적으로 앱 구축을 결정하는 가장 큰 원동력이 되었습니다.

Beyond Rack iOS 및 Android 앱의 가장 중요한 기능 중 일부를 구축한 방법에 대해 자세히 알아보겠습니다. 웹 기술을 사용하여 구축된 앱 기능, 완전히 기본 제공되는 기능, 모두 함께 작동하는 방식.

쇼핑 인터페이스

네이티브 비트

우리는 태블릿과 모바일용 Beyond Rack용 반응형 웹사이트를 구축했습니다. 그러나 단순히 웹 사이트를 웹 보기에 넣고 하루라고 하는 것만으로는 충분하지 않았습니다. 웹사이트 자체는 네이티브 앱처럼 느껴지지 않습니다. 그 큰 이유는 탐색입니다. 브라우저에는 뒤로 및 앞으로 버튼과 URL 표시줄이 있습니다. iOS 및 Android 앱에서 사용자는 탐색 방법에 대해 매우 다른 기대치를 가지고 있으며, 우리는 이러한 기대치를 일치시켜 앱이 각 플랫폼과 일관되게 느껴지도록 하고 싶었습니다.

AJAX를 통해 콘텐츠를 동적으로 로드하고 웹 언어로 탐색 및 전환을 관리하는 프로토타입을 만들었지만 네이티브 앱에서 볼 수 있는 전환만큼 매끄럽게 느껴지지는 않았습니다. iOS 및 Android의 탐색 애니메이션은 웹 기술을 사용하여 일치시키기가 상당히 어려우며 탐색의 버벅거림으로 인해 앱이 덜 기본적으로 느껴지게 됩니다. 앱이 초당 60프레임으로 실행되고 있지 않으면 사용자가 알 수 있습니다.

우리는 두 세계의 장점을 결합한 접근 방식을 생각해 냈습니다. 웹에서 주요 콘텐츠를 로드하지만 기본 탐색 요소를 사용합니다.

iOS에서 이것을 구현하는 것은 정말 아주 간단했습니다. 뷰 스택을 관리하는 탐색 컨트롤러와 각 뷰 간의 탐색을 제어하기 위한 탐색 모음을 활용했습니다. 우리의 경우 보기 스택은 실제로 웹 보기 스택입니다. 탐색이 발생할 때마다 웹 보기 자체에서 탐색하는 대신 새 웹 보기를 인스턴스화하고 UINavigationController 에 푸시하고 새로운 목적지. 웹 보기 스택을 사용하면 사용자가 돌아갈 때마다 페이지가 다시 로드될 때까지 기다릴 필요가 없으므로 경험에 좋습니다. 미래에 기능을 기본 보기로 교체하기로 결정하면 해당 기능의 웹 보기 버전이 아니라 기본 보기를 스택에 푸시하기만 하면 됩니다.

Android에서 탐색 컨트롤러에 해당하는 것은 활동 스택을 사용하는 것입니다. 우리는 여러 액티비티와 프래그먼트를 사용하지 않기로 결정했습니다. 둘 다 매우 복잡한 수명 주기 관리를 요구하기 때문입니다. 결국 우리는 앱에 대한 자체 웹 보기 스택을 관리하고 각 보기 간에 전환할 사용자 지정 기본 애니메이션을 작성했습니다.

다른 많은 앱은 기본 탐색 요소를 활용하여 OS 디자인 패턴을 따릅니다. 기본 탐색 모음을 활용하는 Basecamp의 Android 앱 이미지를 확인하세요.

또한 Amazon의 앱을 모바일 웹사이트와 비교하십시오.

이 접근 방식을 통해 우리 는 플랫폼에 친숙한 경험을 하는 동시에 웹의 훌륭한 핵심 쇼핑 경험을 활용할 수 있는 최적의 지점을 찾았습니다.

이것은 많은 사람들에게 놀라운 일일 수 있지만 Facebook 앱 개발자는 또한 각 기능에 적합할 때 네이티브 또는 웹을 활용하여 최적의 지점을 지속적으로 찾고 있습니다. Facebook 엔지니어가 작성한 기사에 따르면 "앱 내에서 더 자주 변경이 예상되는 영역의 경우 사람들이 앱의 새 버전을 다운로드하지 않고도 서버 측에서 업데이트를 푸시할 수 있으므로 HTML5 코드를 계속 사용할 것입니다. .” Facebook은 여기에서 옹호하는 것과 동일한 접근 방식을 취하고 있는 것 같습니다. 성능, 필요한 개발 노력 및 출시 속도에 따라 각 기능에 대한 기술을 선택하십시오.

앱의 경우 기능을 기본적으로 구축하거나 웹 콘텐츠를 활용하는 것이 더 적합한지 사례별로 고려합니다. 네이티브처럼 느껴지는 탐색을 구축하는 것이 어렵다는 점을 감안할 때 적어도 네이티브 구성 요소를 사용하여 구축하는 것이 합리적일 것입니다.

웹 비트

오늘날 거의 모든 사람들이 웹사이트를 점진적으로 개선 하는 것이 좋은 아이디어라는 데 동의합니다. 브라우저의 가장 낮은 공통 분모에 대해 하나의 마크업 기반을 사용하고 컨텍스트에 따라 JavaScript 및 CSS를 사용하여 기능 및 개선 사항이 있는 레이어를 사용합니다. 별도의 코드 기반이나 템플릿이 없습니다. 다른 장치가 필요합니다. 모바일 웹과 데스크톱 웹을 위한 별도의 템플릿을 만드는 것이 말이 안 되는 것처럼 우리는 앱 자체 내에서 라이브 웹사이트 템플릿을 사용하고 싶었습니다. 앱은 또 다른 컨텍스트일 뿐입니다.

저는 이 건물 을 "앱 인식" 반응형 웹사이트 라고 부릅니다. 앱의 컨텍스트와 성능을 염두에 두고 웹사이트를 구축함으로써 조만간 다양한 플랫폼의 모든 사용자에게 제공할 준비가 될 것입니다.

웹 사이트는 CSS, JavaScript 및 서버의 세 위치에서 앱 컨텍스트를 감지할 수 있어야 합니다. 조건부 CSS를 작성하기 위한 app 클래스와 조건부 JavaScript를 작성하기 위한 isRunningInApp 메소드를 생성하고 조건부 서버 측 로직을 위해 App 을 사용자 에이전트에 추가했습니다.

앱 내에서 점진적 향상을 사용한 예는 제품 표시 페이지에 있습니다. 앱 전용 고정 위치 "장바구니에 추가" 버튼을 추가하여 최적화했습니다.

브라우저에 고정 위치의 "가방에 추가" 버튼을 추가할 수도 있었지만, Safari에서 하단 근처를 클릭하면 실제로 Safari의 탐색 막대가 열리기 때문에 추가하지 않았습니다. 사용자가 장바구니에 제품을 추가하려고 할 때 실수로 이 표시줄이 열리면 페이지 하단에 지속적으로 "장바구니에 추가" 버튼이 있다는 이점에도 불구하고 용납할 수 없는 사용성 결함이 있습니다.

웹사이트에 대한 앱별 조정을 수행한 또 다른 영역은 장바구니입니다. 장바구니 로직은 일반적으로 모든 전자 상거래 웹사이트에서 가장 까다로운 측면 중 하나이며, 모바일에서의 장바구니 경험에 매우 만족했기 때문에 약간 수정된 모양과 느낌이 있지만 앱에서 이를 재사용하기로 결정했습니다.

공유 가능성

링크를 공유하고 공유 링크를 여는 기능은 Beyond Rack에서 잘 작동해야 하는 중요한 기능입니다. 우리는 원활한 공유를 원했습니다. 누군가 데스크탑에서 링크를 공유하고 친구가 앱에서 링크를 열면 링크가 올바르게 열려야 합니다. 마찬가지로 누군가가 앱에서 제품을 공유하는 경우 데스크탑에서 올바르게 열려야 합니다. 친구가 모바일에 있지만 앱이 설치되어 있지 않으면 브라우저에서 열어야 합니다. 이것은 일반적으로 앱이 약한 부분이기 때문에 우리는 이것을 멋진 경험으로 만들기로 결정했습니다.

웹과 앱 간에 콘텐츠를 공유할 수 있도록 하는 것은 어려울 수 있습니다 . 성공적으로 수행하려면 앱 링크와 웹 링크를 매핑해야 합니다. 이는 리디렉션 등으로 인해 데스크톱 URL을 열면 모바일 URL의 홈 페이지로 이동하는 사전 반응형 시대에는 고통스러웠습니다. 오늘날 우리는 앱에서 똑같은 문제를 보고 있습니다. Safari와 Chrome의 배너는 앱에서 링크를 열도록 요청하지만, 앱은 사용자가 찾고 있는 것을 표시하지 않고 다시 검색해야 합니다. 다행히 Beyond Rack의 앱에서 웹 링크를 처리하는 것은 간단합니다. 웹 보기에서 해당 URL을 로드하기만 하면 되기 때문입니다. 웹 링크가 사용자를 브라우저 대신 앱으로 연결하도록 하기만 하면 됩니다.

Android에서 앱에서 URL을 여는 것은 간단합니다. 사용자가 지정된 URL(이 경우 www.beyondtherack.com )을 로드하려고 할 때마다 앱을 로드하도록 인텐트 필터를 설정하기만 하면 됩니다. 앱이 설치되면 사용자에게 앱이나 브라우저에서 URL을 열 수 있는 옵션이 제공됩니다.

iOS는 웹 URL이 앱에서 직접 열릴 수 있도록 하기 위해 약간 더 험난한 길을 걸었습니다. 이전에 iOS에서는 각 앱에 대한 앱 스키마만 등록할 수 있었습니다(예 beyondtherack:// ). 어떤 앱이 설치되었는지 알 수 없었기 때문에 유일한 선택은 Safari에서 주어진 링크를 열고 거기에서 앱에서 해당 링크를 열려고 시도하는 것이었습니다. 이것은 약간의 성가심과 함께 제공되었습니다. 앱이 설치되지 않은 경우 사용자는 "주소가 잘못되어 Safari에서 페이지를 열 수 없습니다."라는 성가신 오류 메시지를 받게 됩니다. 고맙게도 해킹을 통해 iframe을 사용하여 해당 오류를 억제할 수 있습니다. iOS 8에서 딥링킹을 지원하고 싶다면 이것이 최선의 선택입니다.

고맙게도 iOS 9에는 링크가 Safari를 통과하기 전에 앱이 웹 링크를 가로챌 수 있는 범용 링크가 도입되었습니다. ## 발견 가능성 적시성은 Beyond Rack과 같은 회사에서 매우 중요합니다. 전통적으로 회사가 고객에게 판매에 대해 알리는 주요 방법은 이메일 캠페인을 통한 것이었습니다. 그러나 앱을 사용하면 **판매에 대해 고객과 직접 소통**할 수 있어 매우 강력합니다. (물론 푸시 알림은 [Chrome이 주도적으로] 브라우저에 천천히 도착하고 있습니다.(https://gauntface.com/blog/2014/12/15/push-notifications-service-worker). 하지만 구형 Android 기기의 경우 iOS의 경우 기본 기술을 사용할지 아니면 웹 기술을 사용할지 선택하는 것이 이미 결정되었습니다.) 공유와 마찬가지로 앱에서 직접 웹 콘텐츠를 활용하기로 결정했기 때문에 **푸시 알림**을 설정하기가 훨씬 수월했습니다. 모든 제품과 판매는 웹사이트와 앱 모두에서 동일한 URL로 식별될 수 있으므로 마케팅 담당자에게 고객에게 알림을 푸시하는 방법을 교육하는 것은 간단합니다. 공유하는 데 익숙한 동일한 URL을 공유하기만 하면 됩니다. 이메일 캠페인에서. iOS와 Android의 흥미로운 차이점 중 하나는 푸시 알림에 대한 **권한 시스템**입니다. iOS에서 알림에 대한 권한은 운영 체제에 의해 제어되는 반면 Android에서는 권한이 필요하지 않습니다. 그래도 고객 서비스 측면에서 허가를 요청하는 것이 옳은 일이라고 생각했습니다. 따라서 사용자가 앱에 처음 로그인할 때 알림을 원하는지 묻습니다.

우리는 또한 웹 인터페이스를 사용하여 이러한 **알림 대화 상자**를 구축하기로 결정했습니다. 고급 성능이 필요한 것은 없었으므로 웹 UI로 빌드하고 여러 플랫폼에서 재사용하는 것이 합리적이었습니다. 이것은 웹 사이트를 앱 인식으로 만드는 또 다른 예입니다. 이러한 대화 상자는 웹 사이트의 일부이지만 조건부로 앱에 표시됩니다.

결과

앱 출시 후 성능을 브라우저 경험과 비교하고 싶었습니다. 그들의 분석을 직접 비교하는 것만으로는 충분하지 않았습니다. 경험에 따르면 앱을 설치한 사람은 누구나 충성도가 높은 고객일 가능성이 높으므로 전환율이 더 높기 때문입니다. 선택 편향을 피하기 위해 A/B 테스트를 설정했습니다. 사용자의 절반은 앱에 남아 있었고 나머지 절반은 브라우저로 쫓겨났습니다. 따라서 실험의 유일한 참가자는 앱을 설치한 사용자(충성도가 높은 사용자)뿐이었습니다.

• 순 방문자당 거래는 웹보다 앱 경험에서 76% 더 높았 습니다.
• 앱의 일일 순 사용자는 전환할 가능성이 20% 더 높습니다 .
• 앱 사용자는 웹 사용자보다 브라우징에 63% 더 많은 시간 을 보냈습니다.

빠른 성능 승리

웹 콘텐츠를 로드하고 네이티브 느낌을 주는 앱을 만드는 것은 iOS나 Android에서 바로 나오지 않습니다. 다음은 공유할 가치가 있는 몇 가지 성능 문제입니다.

• iOS에서 웹 보기의 스크롤 모멘텀은 기본 스크롤 보기의 스크롤 모멘텀과 일치하지 않습니다. 이것은 사용자 테스트에서 밝혀졌습니다. 다음은 이를 해결하는 하나의 라이너입니다. webview.scrollView.decelerationRate = UIScrollViewDecelerationRateNormal;
• 웹 보기의 크기를 조정할 때 주의하십시오 . 크기를 조정하면 전체 다시 그리기가 발생하여 구형 장치에서 스크롤 성능이 저하되는 문제가 발생했습니다.
• Android에서 수백 가지의 다양한 웹 보기 구현을 처리하는 것은 고통스러울 수 있습니다. 우리가 겪었던 가장 고통스러운 문제는 Android 4.4.2의 알려진 웹 보기 버그입니다. 이 버그는 Chromium에서 앱 충돌을 일으키는 치명적인 예외를 발생시킵니다. 해당 Android 버전에서 transform: translate3d 를 제거하면 트릭을 수행하는 것 같습니다. 또는 Crosswalk를 사용하여 자신의 컴파일된 웹 런타임을 앱과 함께 제공할 수 있습니다.
• FastClick을 사용하는 이유는 300밀리초의 클릭 지연을 제거할 뿐만 아니라 iOS 8.4.1에서 도입된 웹 보기 클릭 버그를 수정했기 때문입니다. 클릭이 너무 느린 경우 페이지 변경을 허용하지 않음으로써 버그가 나타납니다.
• 스크롤이 놀랍게 느껴지도록 할 수 있는 모든 것을 하십시오. 스크롤 이벤트를 디바운스하고 불필요한 다시 그리기 등을 피할 수 있습니다. 스크롤이 초당 60프레임으로 실행되지 않는 경우 사용자는 웹보다 앱에서 훨씬 더 많이 알 수 있습니다.
• 페이지가 1000밀리초 미만으로 로드되도록 할 수 있는 모든 것을 하십시오.

웹사이트를 활용하여 앱을 구축하는 도구

기존 웹사이트를 활용하는 앱을 구축하기 위한 다양한 옵션이 있습니다. 우리가 취한 접근 방식은 필요할 때마다 웹 보기 또는 기본 보기를 활용하여 각 플랫폼(Xcode 및 Android Studio 사용)에 특정한 앱을 빌드하는 것입니다.

특정 기능에 대한 웹 보기를 로드할 때 iOS 및 Android에서 제공하는 웹 보기 라이브러리를 직접 사용하는 것보다 Cordova 웹 보기를 통합하는 것이 좋습니다. 이렇게 하면 JavaScript에서 네이티브 코드로 또는 그 반대로 통신하기 위한 웹-네이티브 브리지, 수명 주기 이벤트 및 액세스 풍부한 Cordova 플러그인에. 또는 Cordova에 의존하지 않으려면 다양한 플랫폼에 대해 몇 가지 다른 웹-네이티브 브리지를 사용할 수 있습니다.

이러한 방식으로 앱을 빌드하는 데 도움이 되는 몇 가지 프레임워크가 있습니다. 예를 들어 Supersonic 및 Astro는 기본 및 웹 인터페이스를 모두 사용하여 앱 빌드의 복잡성을 보다 쉽게 ​​관리할 수 있도록 빌드 중인 기본 앱 프레임워크입니다.

결론

Beyond the Rack을 통해 경험을 희생하지 않고도 사용자에게 쉽게 가치를 전달할 수 있는 앱을 구축하기 시작했습니다. 기술을 뒷자리에 놓고 작업에 적합한 기술을 사용할 수 있도록 하는 접근 방식을 따르면 우리는 바로 그 목표를 달성했다고 믿습니다. 기능이 변경되거나 도입될 때마다 “사용자의 문제를 가장 잘 해결할 수 있는 어떤 경험을 여기서 디자인하고 싶습니까? 그런 경험을 하려면 고급 성능이나 애니메이션을 사용해야 합니까?”

이 질문에 대한 답은 웹 기술을 사용하여 기능을 빌드하고 브라우저와 Android 및 iOS에서 재사용할지 또는 각 플랫폼에 대해 사용자 정의로 빌드할지 여부를 결정합니다.

궁극적으로 이것이 앱이 구축되어야 하는 방식이라고 생각합니다. 하지만 생각의 전환이 필요할 것입니다. 웹이 네이티브를 능가할 것인지 아니면 과거의 유물이 될 것인지 결정하는 대신 두 가지의 장점을 모두 수용해야 합니다. 각자의 장단점을 인식하고 주어진 기능에 가장 적합한 기술을 사용해야 합니다.