YouTube 모바일 웹페이지에서는 동영상이 자동으로 재생된다?

2016.07.09 13:08

모바일 사파리나 크롬 모바일과 같은 모바일 브라우저에서는 동영상이 자동으로 재생되지 않습니다. autoplay 속성을 사용하거나 JavaScript 함수를 이용해서 자동으로 재생시킬 수 없습니다. 이것은 데이터 네트워크에서 사용자가 의도하지 않게 고용량의 동영상을 시청할 때 발생할 수 있는 비용을 막고자 함입니다. (참고) 결과적으로 클릭과 같은 사용자의 행동이 있어야만 동영상이 재생됩니다.


그런데 우연히 유튜브 모바일 웹에서는 자동으로 동영상이 재생된다는 이야기를 들었습니다. 저 또한 모바일 웹에서 자동으로 동영상을 재생시키려다 포기한 적이 있어 그 방법이 궁금해서 잠시 살펴봤는데, 결론은 자동으로 재생되는 것 처럼 보인다는 것입니다.


자동으로 재생되는 것처럼 보이는 이유는 유튜브 모바일 웹이 Single Page Application (SPA) 이기 때문입니다. 첫페이지에서 동영상을 클릭하면 마치 페이지가 이동하는 것처럼 보이지만 실제로는 페이지의 모습이 다른 형태로 변경되는 것을 발견했습니다. 페이지 이동이 아니니 사용자가 동영상 목록에서 특정 동영상을 클릭했을 때 페이지의 모습을 바꾸고 동영상을 바로 재생시킬 수가 있는 것입니다. 시청하던 동영상의 URL을 복사하여 새로운 탭에서 붙여 넣고 유튜브 사이트로 접근하면 동영상이 자동으로 재생하지 않는 것을 알 수 있습니다. 만약 자동재생이 가능했다면 동영상의 URL로 직접 접근하더라도 자동으로 동영상이 재생되어야 할 것입니다.


개발자 도구의 element나 network, timeline 탭을 열고 페이지를 사용해보시면 금방 확인할 수 있습니다.


nundefined ETC autoplay, Chrome, mobile, mobile safari, YouTube, 동영상, 동영상 자동재생, 모바일, 모바일 사파리, 유튜브, 자동재생, 크롬

  1. Blog Icon
    de

    자동재생 되는데요??유튜브 캐시 재거하고 사파리에서도 띄어보고 먼가 다른 방법으로 구현한거같아요

  2. Blog Icon
    de

    아모바일에서 맞네여 흐음 난감하네요 모바일에서 채팅 푸쉬 알람 소리로 구현해야하는데 ㅜ

Bay Area jQuery Conf 2011에서 관심 가는 동영상 몇 개

2011.04.25 23:20
지난 4월 16일부터 17일까지 샌프란시스코에서는 jQuery 컨퍼런스가 열렸습니다. 국내에는 jQuery는 커녕 일반적인 자바스크립트 또는 자바스크립트를 포함한 UI 개발 관련 행사가 하나도 없다는 점을 생각해보면 이런 특정 라이브러리의 컨퍼런스가 열릴 수 있다는 것은 부러운 일입니다.

 jQuery Conf 2011의 세션을 잠시 살펴보면 모바일에 대한 내용, 개발 방법이나 퀄리티 도구를 사용하는 방법, 유닛 테스트, jQuery의 활용, 하이브리드 모바일 앱 등 이제는 단순한 jQuery의 활용을 벗어나 다양한 주제에 대한 내용이 포함되어 있습니다. 점점 대단하다는 생각밖에 들지 않네요.

이 중 몇 개의 세션을 녹화한 동영상이 온라인에 공개되어 있는 것을 우연히 발견했습니다. 동영상 중 제가 관심있는 몇 개에 대한 링크를 걸어봅니다.

Introduction to jQuery Mobile - Raymond Camden

Introduction to jQuery Mobile | Raymond Camden | Bay Area jQuery Conf 2011 from yayQuery on Vimeo.



Mobile Performance - Steve Souders

Mobile Performance | Steve Souders | Bay Area jQuery Conf 2011 from yayQuery on Vimeo.



Integrating Code Quality tools into your jQuery Development Workflow - Anton Kovalyov

Integrating Code Quality tools into your jQuery Development Workflow | Anton Kovalyov | Bay Area jQuery Conf 2011 from yayQuery on Vimeo.



이 외의 동영상에도 관심있는 분들은 이 페이지를 방문해보시기 바랍니다.




 

nundefined HTML5_JS_CSS code quality, JQuery, jquery conf, jquery mobile, mobile, Performance

HTML5 어떻게 대응해야 하는 것일까요?

2010.12.10 09:40
HTML5 가 2010년 웹세상의 핫 키워드 중 하나였던 것 같습니다. 여기저기서 세미나가 열리고, 웹에는 지금 제가 쓸 내용과 비슷한 포스트가 잔뜩 쌓여 있습니다. 서점에서는 책도 벌써 여러권 전시되어 있더군요.

HTML5이라는 것이 나왔는데, 도대체 어떻게 대응해야 하는가? 에 대한 이야기를 할까 합니다.

먼저 HTML5가 무엇인지 짧게 정리를 해볼까요?
HTML5는 웹 개발자가 원하는 욕구에 의하여 출발하여, 공식적인 웹표준을 담당하고 있는 W3C라는 곳에서 표준을 인정하여 워킹그룹으로 진행되고 있는 개선된 웹UI 기술이라고 할 수 있습니다.
HTML5하면 HTML의 히스토리나 역사 이야기가 꼭 나오는데요, 이런 부분은 다른 글에서 쉽게 찾을 수 있을것 같아서 생략합니다.

누구를 위한것인가?
매우 명확합니다. HTML5 는 웹 개발자를 위한 새로운 SPEC입니다.
다시 말해 사용자(end-user)가 얻는 혜택보다는 웹개발자가 얻는 혜택이 많습니다.
사용자에게 제공되는 혜택이 크지 않다는 것은 무슨뜻일까요?
바로 영리를 추가하는 기업에서 HTML5를 활용해서 이익을 창출할만한 기술은 아니라는 점입니다.

HTML5으로 변경되는 스펙은 무엇인가?
크게 2가지로 구분할 수 있습니다.
- 마크업의 요소들과 속성의 변화
- HTML5 JAVASCRIPT API의 추가
추가로 CSS3의 기술이 동시에 변화되고 있으며, HTML5와 같이 언급되는 것은 비슷한 맥락과 비슷한 UI인터랙션을 포함하고 있기 때문입니다. CSS3는 엄연히 HTML5의 스펙이 아닌것으로 알고 있습니다.

실제 웹은 어떻게 변화하나요?
변경되는 스펙을 통해서 확인해 볼까요?
마크업의 구조 변경은 보다 직관적이고 유지보수성을 향상시키는 부분의 변화가 있습니다.
HTML5 JAVASCRIPT API의 경우는 JAVASCRIPT 로 할 수 있는 범위를 확장 시켰으며, 이로 인해 Server-side 에서 가능했던 웹데이터베이스나 다른 브라우저 플러그인에게 부탁했던 그래픽작업등이 가능하게 되었습니다.
또한 브라우저별 호환성 문제가 많은 부분에서 해결될것입니다. 개발자들에게 선물과 같은것이겠죠? ^^
CSS3의 경우도 비슷합니다. Transformation, Transition 등의 변화가 있는데요, 주로 이미지를 자르고, 변경하고 이런류의 작업이 CSS속성으로 가능하게 되었습니다.
다시 말하지만, 이런 것들은 사용자에게는 중요하지 않은 부분의 변화로 볼 수 있습니다.

어떻게 대응해야 하나요?
TO 웹관련 비개발자분들꼐
먼저, 위에서 언급했지만 html5는 돈벌이로서 큰 메리트가 없다고 봅니다. 핵심은 웹개발자들이 수고하고 있는 부분을 덜어주고 웹개발 환경을 개선하는 것이라고 봅니다. 오히려 현재는 과도기적인 웹환경에서 일시적으로 웹개발자들이 더 수고하고 있다고 봅니다. 이런 점을 먼저 이해하셔야 합니다.

HTML5의 도입으로 인해, 기존에 복잡한 비용이 들었던 부분을 일부 개선할 수 있습니다.
이미지 편집이나 CHART같은 그래픽작업을 기존에 어떻게 했는지 볼까요?
- 서버에서 이미지를 생성하여 실시간으로 내려준다.(운용비용이 큽니다)
- ActiveX로 구현하였습니다(IE에서만 동작했겠죠? 물론 국내 IE사용자는 아직도 90%가까이 되는것으로 압니다)
- Flash로 구현하였습니다 (안타깝게도 이제 일부 모바일기기와 태블릿기기에서 플래쉬기술이 보여지지 않습니다)

이런 방법을 적은 비용으로 대체할 수 가 있습니다.
HTML5 의 CANVAS와 SVG와 같은 기술은 브라우저상에서 이미지를 조작하고 변영할 수 있도록 해줍니다.
모든 브라우저와 기기에서 동작이 가능하며, 서버에서 비싼 기기의 장비를 구할필요도 없으며, ActiveX와 같이 결함이 많이 발견되는 플러그인을 사용하지도 않습니다.

물론 이런 것을 가능하게 하는 브라우저는 한정적입니다. (구형브라우저에서는 안된다는 이야기 입니다^^)
하지만 그런 이유로 HTML5와 같은 최신기술을 바라만 보면 절대 안됩니다.

기존기술 --> HTML5 기술로의 변화과정에서 중간에 변환기라고 할 수 있는 다양한 라이브러리와 기술이 등장하고 있습니다. HTML5를 사용할 수 있는데 안타깝게 못쓰는 이유가 있다면 이를 또다른 기술로 풀어나가는 사람들이 있습니다. 대부분 이런 기술을 제공하는 것은 무료 입니다.(오픈소스)

또다른 예로, 모바일의 환경을 들 수가 있습니다.
HTML5의 가장 걸림돌은 구형브라우저에서는 (사실은 Internet Explorer 7미만) 거히 동작하지 않는 다는 것입니다. 그런 브라우저를 대한민국의 PC환경에서는 특히나 많이 가지고 있습니다.
하지만 스마트폰의 등작으로 모바일에서 웹을 언제나 경험할 수 있게 되었습니다.정말이지 1년안에 많은 변화가 생겼죠?  모바일에서도 브라우저라는 놈이 있습니다.  생긴지 얼마 안됬으니 당연히 최신기술을 담고 있습니다. PC에서 겪었던 문제를 다시 경험하지 않기 위해서입니다. 이런 이유에서 플래시와 같은 기술을 애초에 포기한것 일 수 도 있습니다.
다른 이야기이지만, 이런 경험을 많이 경험하지 못한 모바일기기 제조사에서 임의의 웹표준을 중요하지 않게 생각하고 브라우저를 개발하는 경우가 생기고 있는 것 같아서, 너무 안타깝습니다.
다시 돌아와서, 모바일에서는 HTML5가 PC 환경에 비하면 아주 잘 동작합니다^^
모바일에서 몇가지 기능을 볼까요?
- 야후 메인페이지의 내용을 손가락으로 아이폰의 앱들을 조정하듯이 스르륵 움직일수가 있습니다.(슬라이딩)
- 구글 지메일에서는 아이폰의 에어플레인모드(인터넷이 불가능한 환경)에서 메일을 열고 쓸수가 있습니다
- 어떤 서비스에서는 모바일 브라우저에서 내 위치를 감지하여 가장 가까운 곳의 원하는 장소를 찾아줍니다

순서대로 보면 다음과 같은 것들이 사용되었습니다
- CSS3의 Transition을 사용하여 효과를 구현.
 -web storage(cache api)를 사용하여 오프라인 모드에서도 인터넷이 가능하도록 구현
- web geolocation과 같은 기술로 위치기반의 서비스를 사용.

모두 HTML5와 같은 최신 웹기술을 사용하고 있습니다. 이런 부분은 최신 모바일브라우저를 통해서 많은 사용자들에게 멋진 효과와 사용자 경험을 제공하고 있습니다.

HTML5의 몇가지 기술은 아직도 사실상 표준화 된것이라고 할수 없습니다. 하지만 이런 이유로 개발비용을 감소시킬 수 있고, 사용자에게 더 멋진 기능제공을 할 수 있는 것을 지켜만 봐서는 안됩니다.
또 한가지는 여러분들과 함께 일하는 개발자들은 대부분 이러한 최신기술을 이용하여 개발하는 것을 즐겨 한다는 사실입니다. 반드시 그들에게 기회를 주고 많은 부분을 같이 고민하시면 좋겠습니다.

TO 웹 개발자분들께
이미 많은 분들은 HTML5의 스펙을 꽤고 계시고 어떤 기능이 있는지 잘들 아실것 같습니다.
제가 감히 당부 드리고 싶은 부분을 요점화 하여 알려드릴까 합니다.

HTML/CSS개발자 분들은 이제 자바스크립트를 많이 아셔야 합니다. CSS3와 같은 기술과 HTML5 API는 연관관계가 깊고, 서로 상호보완적인 요소가 있습니다. 자바스크립트를 능숙하게 하지 못하더라도 어떤 기능과 스펙이 있는지 이해를 하는 것이 좋습니다. 어떻게 구현해야 할지, 구현가능한지를 판단하기 위해서라도 자바스크립트의 이해는 반드시 필요로 합니다. 최소한 html5 spec을 이해하고 있어야 합니다.

자바스크립트 개발자분들은, 반대로 CSS3를 이해하고 있어야 합니다. 또한 Validator나 forminput관련 기능들은 모두 알고 계셔야 합니다. 말줄임표를 구현하기 위해 자바스크립트로 엄청남 삽질을 고만하고 싶다면^^
개발 영역을 확대하세요. HTML5 API중 현실성과 가깝지는 않지만 엄청난 SPEC이 포함되어 있는것 같습니다.
Web Application을 UI단에서 상당히 구현가능하게 된다는 점입니다. WEB SQL DATABASE등을 통해 서버에서나 했던 db를 클라이언트 브라우저의 제공으로 구현가능하고, Query문법을 통해서 비즈니스처리를 할 수 있습니다. WEB UI Application을 자바스크립트 기술로 가능하게 되었습니다.
이 뿐만이 아닙니다.
- web workers와 같은 기술을 통해 백그라운드로 다른 작업을 동시에 시킬 수도 있습니다.
- web storage를 사용하여 쿠키를 대체하여 http header의 부담을 줄일 수도 있습니다.
- notification API를 통해서 브라우저가 일종의 메신저와 같이 알람기능을 갖도록 할 수 도 있습니다(얼마전 RockMelt가 이 API를 사용한것 같습니다)
AJAX라는 비동기통신방법이나 Comet만의 방법을 이제는, web sockets을 통해서 기존 보다 더 빠른 새로운 방법으로 서버와 통신할 수도 있습니다.
할일이 너무 많이 늘어났네요. 불필요한 query문법을 알아야 하는것 부터, 신경쓰기 싫었던 소켓통신의 원리도 이해할 필요가 있겠군요.
어쩌면 서버사이트 웹개발자가 기존의 지식을 UI단으로 구현하는 형태가 될 수도 있습니다. 하지만 UI에서 서버사이드 작업을 하게 된다고 하여도 역시 자바스크립트 기술이 핵심이며, 이를 전문적으로 알고 있는 자바스크립트 개발자가 HTML5 API를 이해하고 활용하는 것이 더 어울린다고 할 수 있습니다.
다른 말로 가장 적합하다고 할 수 있겠군요.

#별도의 참고내용을 알려드리진 않습니다.
검색창에 html5 api css3등의 키워드만 쓰면 주루룩 끝없이 나오네요 ^^
웹에 무료로 pdf 형식으로된 개발가이드도 있습니다.
이런 부분을 작성해주신 분들께 감사드립니다.









니가요 HTML5_JS_CSS AJAX, CSS3, html5, iphone, javascript, mobile, rockmelt, Web

Google Docs 모바일 에디팅 지원

2010.11.19 01:00
우선 다음의 동영상부터 먼저 보시겠습니다.




위 동영상은 모바일 폰에서 Google Docs의 문서를 편집하는 기능에 대한 것입니다. 동영상을 본 느낌은 어떠신가요?

웹에서의 WYSIWYG 에디터에 대한 이야기를 하려면 먼저 에디터가 기본적으로 동작하는 방식에 대해 이해할 필요가 있습니다. 대부분의 리치 웹 에디터는 브라우저에서 제공하는 contenteditable (IE인 경우 designmode를 사용하는 경우도 있음) 프로퍼티를 설정하여 브라우저에서 특정 엘리먼트를 수정할 수 있는 상태로 만든 후 여기에 JavaScript등을 이용하여 고급 기능을 제공하는 형태로 만들어져 있습니다. contenteditable을 설정하더라도 기본적으로 제공해주는 기능에는 한계가 있기 때문에 이런 한계를 뛰어넘고자 JavaScript를 사용하는 것입니다. FCKEditor나 TinyMCE, SmartEditor basic도 모두 비슷한 방식을 사용하고 있습니다.

모바일 브라우저(정확히는 모바일 사파리입니다. 안드로이드에서는 테스트해보지 못했습니다.)에서는 이런 방법으로 리치 웹 에디터를 구현할 수 없습니다. contenteditable 속성을 사용하는 경우 브라우저에서 적절하게 표현해주지 못하기 때문입니다. 캐럿이 표시되지 않아 현재 위치를 사용자가 확인할 수 없으며 가상 키보드가 적절하게 표현되지 못하는 문제도 있습니다. 그래서 결국 input boxtextarea가 현재 모바일 브라우저상에서 사용자로부터 텍스트를 입력 받을 때 사용할 수 있는 방법입니다.

그런데 Google Docs의 경우 조금 다르게 구현되어 있습니다. 지난 4월 12일. Google에서는 새로운 Docs를 출시하였습니다. 우선 소개 동영상을 보시죠.



위 동영상에서 보는 편집 기능은 contenteditable을 사용하여 만든 경우 구현이 매우 어렵습니다. (사실 불가능할 수도 있지만 시도해보지 않았으니 매우 어렵다로 표현합니다.) 특히 동시 편집 기능은 거의 불가능에 가깝습니다. 실제로 옛 버전의 Google Docs의 경우에도 실시간으로 협업 편집이 불가능했습니다. 구글이 취한 방법은 바로 contenteditable을 사용하지 않는 것입니다. 그리고 일반적인 워드프로세서와 유사하게 사용자가 글자를 입력할 경우 글자의 크기 등을 계산하여 HTML 코드를 만든 후 그 결과를 화면에 표시한 것입니다. 다시 말하면 사용자가 입력할 수 있는 화면으로 생각하고 입력을 하고 있지만 실제로는 사용자가 입력할 수 있는 화면처럼 여기게끔 화면을 구성하고 실제 입력은 브라우저의 도움을 받지 않고 구현한 것입니다. 도움이라고 표현했지만 실제로는 브라우저의 방해를 받지 않게 된 것에 가깝습니다. (물론 이로 인해 전체적인 동작 속도가 느려진 면이 있지만 지속적인 최적화와 브라우저의 발전으로 빠른 시간 내에 해결이 될 것으로 예상됩니다.)

이렇게 구현된 Google Docs의 개념을 모바일에 적용한 것으로 보입니다. 다만 가상 키보드가 출력되어야 하므로 사용자가 입력할 때는 input box를 노출시킨 것으로 생각됩니다. 점점 더 발전하면 input box를 사용자가 볼 수 없는 곳에 위치시킨 채 입력을 받고 화면에는 input box를 노출시키지 않도록 변경될 것입니다. 그렇게 된다면 웹에서의 Google Docs와의 차이점은 더 구별할 수 없을 것입니다. 아직 구현되지 않았다는 것은 구현에 시간이 걸리거나 구현이 불가능하거나 둘 중에 하나일 듯 합니다.

하지만 첫 번째 동영상만 봐서는 아직 리치 모바일 웹 에디터라고 부르기에 부족한 점이 있습니다. 스타일을 지정할 수 없다는 점이 가장 큽니다. 하지만 그 가능성은 엿볼 수 있습니다. 37초 경에 나오는 부분을 유심히 보기 바랍니다. 점목록 중 하나를 일단 클릭한 후 엔터를 입력하여 다음 줄로 넘어갑니다. 그러면 동일한 스타일(점목록)이 유지됩니다. 일반적인 웹 에디터에서의 경험과 동일합니다. 어느 정도 리치 웹 에디터처럼 동작하고 있다는 것이라 볼 수 있습니다. 그렇다면 남은 것은? 다양한 기능을 추가하고 모바일 화면에 적절한 UI를 추가하여 원활한 편집이 되도록 하는 것입니다.

하지만 아직 남은 문제가 있습니다. 리치 웹 에디터의 기본적인 동작 방식은 크게 두 가지로 나뉩니다. 하나는 스타일을 설정하고 글을 입력하는 방식입니다. 다른 하나는 글을 입력하고 특정한 영역의 글을 선택하여 스타일을 설정하는 방식입니다. 두 가지 방식이 모두 사용되나 대체로 뒤쪽의 방식을 많이 사용합니다. 글을 쓰는 작업과 스타일을 적용하는 작업을 명확하게 분리할 수 있기 때문입니다. 그런데 모바일에서는 특정한 영역을 선택하는 일이 쉽지 않습니다. 일단 기기의 크기가 작기도 하거니와 PC의 마우스처럼 세밀하게 포인터를 움직일 수도 없기 때문입니다. 이를 보완하는 방법으로 iOS에서의 선택 영역을 지정하는 방법이 나왔습니다만 빈번하게 영역을 선택해야 하는 경우 이 방법도 편리하기만 한 방법은 아닙니다. 바로 이 부분을 어떻게 해결하느냐가 리치 모바일 웹 에디터에서 해결해야 할 핵심 문제 중 하나가 아닌가 하는 생각입니다.

Google Docs가 앞으로 어떻게 발전할지 - 이미 어지간한 리치 웹 에디터는 넘볼 수 없는 영역에 가있기는 합니다만 - 매우 기대됩니다.


nundefined HTML5_JS_CSS contenteditable, designMode, fckeditor, Google Docs, mobile, smarteditor basic, tinymce, WYSIWYG, 구글, 모바일, 위지윅, 위지윅 에디터