6월14일 COEX에서 열린 정보처리학회의 IT 21 Conference에서 발표한 내용입니다.
스마트 기기의 확산과 함께 웹 기술의 진화는 빠르게 이루어지고 있다. 오늘날 웹 기술은 HTML5와 단말 API 등을 통해 단말의 HW을 제어하고 비동기적으로 원격 데이터베이스를 연동하며 다양한 응용 로직을 처리할 뿐아니라 웹 운영체제(OS)로까지 진화하고 있다. 그러나 웹 기술을 활용한 응용과 서비스가 많아짐에 따라 시스템의 복잡도가 높아지고 새로운 사용자 인터페이스에 대한 요구들도 높아지고 있다. 더불어 PC뿐 아니라 모바일, TV 등 다양한 단말 환경에서 웹 응용이 활용됨에 따라 단말과 플랫폼에 상관없이 보편적 서비스 환경으로 웹 UI/UX에 대한 관심들이 높아지고 있다. 이에 본 발표에서는 이처럼 변화되는 서비스 환경을 중심으로 보다 나은 웹 사용성을 제공하기 위해 진행되고 있는 다양한 모바일/멀티디바이스 웹 UI/UX 관련 이슈 및 기술 표준 동향에 대해 살피고, 향후 웹 사용자 편의와 사용자 경험 개선 극대화를 위해 나아갈 방향들에 대해 고찰해보고자 한다
웹 UI/UX에 관심 있는 분들은 참고해보시길 바랍니다.
6월14일 COEX에서 열린 정보처리학회의 IT 21 Conference에서 발표한 내용입니다.
스마트 기기의 확산과 함께 웹 기술의 진화는 빠르게 이루어지고 있다. 오늘날 웹 기술은 HTML5와 단말 API 등을 통해 단말의 HW을 제어하고 비동기적으로 원격 데이터베이스를 연동하며 다양한 응용 로직을 처리할 뿐아니라 웹 운영체제(OS)로까지 진화하고 있다. 그러나 웹 기술을 활용한 응용과 서비스가 많아짐에 따라 시스템의 복잡도가 높아지고 새로운 사용자 인터페이스에 대한 요구들도 높아지고 있다. 더불어 PC뿐 아니라 모바일, TV 등 다양한 단말 환경에서 웹 응용이 활용됨에 따라 단말과 플랫폼에 상관없이 보편적 서비스 환경으로 웹 UI/UX에 대한 관심들이 높아지고 있다. 이에 본 발표에서는 이처럼 변화되는 서비스 환경을 중심으로 보다 나은 웹 사용성을 제공하기 위해 진행되고 있는 다양한 모바일/멀티디바이스 웹 UI/UX 관련 이슈 및 기술 표준 동향에 대해 살피고, 향후 웹 사용자 편의와 사용자 경험 개선 극대화를 위해 나아갈 방향들에 대해 고찰해보고자 한다
웹 UI/UX에 관심 있는 분들은 참고해보시길 바랍니다.
2022년 11월 18일 코엑스에서 개최한 공공솔루션마켓에서 발표한 강연 자료입니다.
디지털 전환이 가속화됨에 따라 더욱 중요해진 디지털 경험 모니터링과 장애 및 병목 등 성능을 개선한 실 사례를 공유드립니다.
생생한 강연 영상으로 확인해 보세요!
https://youtu.be/_Cdms2TxO3M
3. Responsive Web Design 스터디
1일차 8월 25일 (12:00 ~ 14:00)
• 자기소개
• 반응형 웹의 기본개념 (동영상 + 자료준비 : Wise)
• 과제 : 반응형 웹 사이트 인당 최소 25개씩 찾아오기 !!
(각 사이트별 반응형 웹을 만든 방법 분석 포함)
2일차 9월 1일 (12:00 ~ 15:00)
• 과제공유 : 각자 찾은 사이트 25개 발표 및 토론
(각 사이트별 만든 방법 및 특징 포함)
• 과제 : 사이트 직접 만들기
3일차 9월 15일 (12:00 ~ 14:00)
• 과제공유 : 각자의 결과물, 만든 방법, 작업시 느낀점 공유
• 반응형 웹을 작업해 본 디자이너/기획자 입장에서의 느낀점 공유
• 총평
( 출처 : http://cafe.naver.com/webmarkup/2389 )
7. 동영상 보기
2011년 H3 컨퍼런스에서 신현석님이 발표한
“반응형 웹디자인, 진짜 할 만 한가?” 동영상을 시청했습니다.
http://h3.paran.com/2011/session/responsive-web-design-in-action.html
반응형 웹의 기본 개념을 잡는데 많은 도움이 되었습니다.
8. “왜 반응형 웹일까”를 한번 고민해 보다.
• 시대가 빠르게 변하고 있다. (다양한 해상도의 디바이스 증가)
• 운영 리소스가 감소한다. (?)
• …
여러분의 생각은??
사람들이 왜 반응형 웹에 관심이 많을까요??
9. N – Screen ??
C-P-N-T (Contents, Platform, Network, Terminal)로 구분되는 산업
계 체계 상에서 보다 진보된 스마트 체계를 통해 언제 어디서나 다
중 콘텐츠를 공유하고 실행할 수 있으며, 끊김없는 이어보기가 가능
한 사용자 중심적인 서비스를 의미한다.
N-스크린이라고 부르기전에는 웹, 모바일, TV 간의 연결로 한정하
여 3-스크린이라고도 부르기도 했다.
(출처 : http://ko.wikipedia.org/wiki/N-%EC%8A%A4%ED%81%AC%EB%A6%B0)
10. 클라우드 컴퓨팅 ??
클라우드 컴퓨팅(cloud
computing)은 인터넷 기반
(cloud)의 컴퓨팅(computing) 기
술을 의미한다.
인터넷 상의 유틸리티 데이터
서버에 프로그램을 두고 그때
그때 컴퓨터나 휴대폰 등에 불
러와서 사용하는 웹에 기반한
소프트웨어 서비스이다.
(출처 : http://ko.wikipedia.org/wiki/%ED%81%B4%EB%9D%BC%EC%9A%B0%EB%93%9C_%EC%BB%B4%ED%93%A8%ED%8C%85)
11. 실제로 반응형 웹 할만 할까요??
H3 영상에서 언급되었듯
이, 많은 테스트를 직
접 해보고 느껴봐야 한다고
생각합니다.
기존에 작업했던 프로젝트 :
다음 어학사전
(출처 :http://dic.daum.net/)
12.
13. http://www.webactually.co.kr/
Media query 방식 (CSS로 수정)
장점 : 브라우저의 움직임에 따라 완벽 대응한다.
(크롬의 경우)
단점 : 소스 별로 수정해야 하는 문제점이 생김.
소스가 너무 길다.
IE에서도 되는 소스도 첨가 하였지만 엄청난 느림현상
으로 인해 닫게 만들어 버린다. (스크립트)
14. http://www.smashingmagazine.com/
Media query 방식 (CSS로 수정)
장점 : 모든 기기에서 완벽한 레이아웃이
구현되는 엄청난 레이아웃 효과
5번의 변화로 어떤 기기든 전부 변화가
되지 않나 싶다.
단점 : 외국 사이트라 그런지 IE는 완전
버렸다
IE6에서 보면 렉걸린 것 처럼 엄청 버벅거림
Css보면 답답함…….
15. http://colly.com/
Media query 및 Adaptive Layout Technique 방식
장점 : 심플한 레이아웃으로 인해 css 양이 짧아 져
서 수정 하기가 쉬워 졌다.
브라우저 별 느림현상이 없다.
단점 : ie 버전별로 css를 부르지만 바뀐 게 없다.
포트폴리오 용으로 만들면 좋을 꺼 같다.
16. http://iam.beyonce.com/
Jquery API Mansonry 사용
http://masonry.desandro.com/
장점 : 애니메이션 효과로 인해 화
려한 퍼포먼스가 가능하다
IE등 모든 브라우저가 전부 작동함
단점 : 이 반응형으로 인해 Jquery
Api를 불러야 한다. (무거워지지 않
을까)
사이즈 조절이 힘들다.
강제로 css를 수정 하면 레이아웃이
깨지므로 js로 수정을 해야 함
디자인이 한정되어 있다.
18. http://www.amwayon.co.kr/
Media Query 및 Jquery Vgrid 사용
http://blog.xlune.com/2009/09/vgrid/
레이아웃은 Media Query 로 짜고
리스트 쪽은 Jquery로 작업
지금까지 몇 개의 사이트를 찾아 다녀서 느낀 건 미디어쿼
리를 쓰는 대부분 사이트는
이걸씀… 테스트 해본 결과 ie브라우저는 css3 가 안먹기
때문에 따로 작업을 해줘야 하는 어려움이 있다.
19. 장점과 단점
장점
1. 확실히 둘을 같이 쓰니 생각보다 깔끔하고 효과가 많아서 유저 입장에 선 눈
을 호강 시킨다.
2. 레이아웃이 단순하여 한눈에 다 들어온다.
단점
1. 우리나라 사이트인데도 ie는 버렸다….과연 우리나라에선 얼마나 컴플레인
이 올지…..
2. 도대체 ie 6,7,8 별 id를 왜 추가 했는지 모르겠다….;;; 다 깨지는걸…
3. 처음 url 치고 들어가면 레이아웃이 다 깨지고 제이쿼리는 ie에서 반응도 안한
다.. Ie에서 반응안하는 제이쿼리 인줄 알았지만 확인해 본 결과 ie에서도 다
반응하는 제이쿼리다…. 귀찮아서 그런 건지…;;;
4. 뭔가 굉장히 아쉽다..
20. http://mediaqueri.es/
Media Query의 대표적인 회사
포트폴리오를 보면 전부다 미디어 쿼리
로 제작 되었다.
장점 : 사이트 제작이 100개가 넘는 미디어
쿼리를 지향하는 사이트
단점 : Media query의 우리가 알고있는 부분
말고 새로운 부분을 선보여 주었음 좋겠다.
미디어 쿼리만 사용해서 그런지 디자인이 단
순한 부분이 많다.
21. http://www.seoul.go.kr/main/index.html
하나의 HTML 안에 모바일코딩 따로
웹코딩 따로 하여 js로 none block 시킨 방식
Fluid Grids 효과와 암튼 js로 이런 방식이 도입
될꺼 란 생각은 안해봤다.
또한 모바일로 보았을때 하단부 PC화면을 보
기를 누르면 Jquery.cookie 스크립트로 인해
#m_wrapper 를 안보이게 하는 기술을 집어 넣
었다.
22. 장점과 단점
장점
1. 현존하는 우리나라 사이트 중 제일 좋은 방법이라 생각한다.
2. Ie 하위버전에서도 완벽 적용이 되고 있다.
3. 여기에 미디어 쿼리 까지 적용시켜 모바일로 보았을 때 폰트부분까지 완벽하
게 처리하였다.
단점
1. 하나의 HTML안에 두개의 코딩을 해야 해서 방대한 양이 예상 된다.
2. 역시나 어쩔 수 없는 ie의 느림 현상….
25. http://www.astrum.co.kr/
Media Query로 사이즈를 줄이고
Jquery Mansonry로 레이어를 조율하였다.
http://masonry.desandro.com/
Respond.js로 ie 하위버전에서도 적용할수 있
게 만들었다.
미디어 쿼리로 인해 사이즈를 조율하면 제이쿼
리 애니메이션 효과로 밑으로 서서히 내려가
는 구현을 하였다.
장점 : respond.js 로 인해 ie하위 버전에서도 미
디어 쿼리가 적용된다.
단점 : ie에서 확인한 바로는 익스가 키기 싫어
윈도우 창이 960px일때 width 값이 반응하여 제이쿼리
진다… 제이쿼리 api 너무 많은 관계로 인해 렉
api가 발동한다. 현상이 너무 심하다.
27. http://teamtreehouse.com/blog/beginners-guide-to-
responsive-web-design
Media Query css 방식
장점
Ie별 id값을 추가 해서 깨지지 않게 만들
었으며..
Respond.js로 ie에서도 media Query가
대응되도록 작업 하였다.
단점
Ie6에 깨지면서 기달리다 지친다….
엄청난 렉 현상때문에 ie는 두려워서 넣
기 싫다.
28. http://m.naver.com/
네이버 모바일에서 반응형웹을 적용 시켰다.
그렇게 많은 변화는 없지만, Media Query로 창
을 줄였을때 오른쪽 컨텐츠가 하단으로 내려 가
는 방식을 만들었다. 안드로이드
단말기의 화소와 실제 화면의 pixel간의 비율)
29. 분석후 느낀점
25개 사이트를 분석해본 결과 대부분 80%정도 미디어쿼리를 중점으로 쓰고 나머
진 제이쿼리 api와 class변경 스크립트로 반응형을 선보였습니다.
다만 80% ~ 85%는 미디어 쿼리를 중점으로 쓰고 있습니다.
당분간은 미디어쿼리의 독점시대 일것 같습니다.
하지만 우리나라의 단점은 미디어 쿼리를 ie에서 확인할수가 없습니다. 물론 크롬
이 2012년에 들어서 ie사용자랑 비슷해 지는 추세 입니다.
향후 2013년에서 2014년 이 지나면
아마 고대하던 크롬의 독주시대(?)가
올 부분 같습니다.
미디어 쿼리 아직은 우리나라에서 쓰긴 무
리가 있지만,
향후를 위해 미디어쿼리를 대비해 놓는 방
법도 중요하다고 생각 합니다.
30.
31. Liquid layouts
레이아웃의 크기를 상대적(%단위등)으로 지정하여 브라우저의 크기에 따라
유동적으로 변화하게 하는 레이아웃 기법
An Adaptive Layout Technique
자바스크립트로 사용자화면 폭을 감지해서 적절한 레이아웃이 나오도록
CSS 클래스명을 교체하는기법
Fluid Grids
디자인 그리드를 가변폭으로 변환하는기법 (Liqid layouts 과 비슷)
CSS3 Media Queries
CSS2 미디어타입에 미디어상태(mediafeature)를 추가하여 다양한 단말기에
서의 표현양식을 제어할 수 있게 고안된 기능
Responsive Web Design
유동형그리드(fluid grids), 가변폭이미지(flexible images), 미디어쿼리
(media queries) 개념을 하나로 묶고 체계화시킨 용어
(출처 : http://h3.paran.com/2011/session/responsive-web-design-in-action.html)
32. http://dic.daum.net/
1. HTML에서 미디어쿼리를 적용.
2. 미디어 쿼리가 적용되지 않는 IE
6~8 대응하지 않음.
3. Viewport 사용.
4. 유동적인 레이아웃.
5. 사전 서비스 특성을 잘 파악해
서 반응형 웹을 적용한 사례라
고 생각함.
46. http://naomiatkinson.com/
1. CSS에서 미디어 쿼리를 적용.
2. Viewport 사용.
3. jquery.masonry을 사용.
4. jquery.retina을 사용. (jQuery plugin for
replacing images in the HTML with @2x
versions)
55. http://ribot.co.uk/
1. CSS에서 미디어 쿼리를 사용.
2. Viewport 사용
3. 유동적인 레이아웃, 이미지 사용.
4. 축소 시 일부 기능을 사용하지 못함.
5. css3-mediaqueries.js 을 활용하여 IE대응
56. 분석후 느낀점
적용된 사이트들을 분석하니 반응형 웹이 이슈가 된지 얼마 안된 것을 다시 느낄
수 있었다. 그렇게 느낀 가장 큰 그 이유는 HTML5
DTD, CSS3(transition, transform, animation, background-origin, border-
radius 등…)를 사용한 사이트가 많았다.
모바일을 고려한 viewport는 모든 사이트에서 사용했다.
다소 아쉬운 점은 내가 찾은 사이트들이 국내 사이트들이 아닌 해외 사이트의 사
례가 많았다. 국내 서비스 적용사례를 좀 더 찾지 않은 것이 스스로 아쉬웠다.
총 24개의 사이트를 분석했으며, 국내 3건, 해외 21건의 사이트를 분석했다.
DTD가 HTML 5인 경우 : 21개 ( 21/24 = 87.5% )
IE를 대응한 사이트 : 10개 ( 10/24 = 41.7% )
미디어 쿼리를 HTML에 적용한 사이트 : 2개 ( 2/24 = 8.3% )
미디어 쿼리를 CSS에 적용한 사이트 : 22개 ( 22/24 = 91.7% )
자바스크립트로 레이아웃을 제어한 사이트 : 2개 ( 2/24 = 8.3% )
Viewport를 사용한 사이트 : 24개 ( 24/24 = 100% )
Jquery.masonry를 사용한 사이트 : 3개 ( 3/24 = 12.5% )
57.
58. http://pr.hyundai.com/#/pages/main.aspx
1. An Adaptive Layout Technique 기법
(사용자 화면 폭을 감지해서 css 클래스명을
교체하는 기법)
2. IE에서 버벅거림이 심함.
클래스명을 교체 하는 기법을 사용하여,
그에 따른 css가 많아지는 점이 좋지 않은 것 같
다.
더 적은 소스의 css가 될 수 있을텐데...
유지보수 시 클래스명에 따른 css가 변경 될 때,
일부 누락 시키는 실수를 할 가능성이 높다.
59. http://leeum.samsungfoundation.org/html/global/main.asp
1. An Adaptive Layout Technique 기법
(사용자 화면 폭을 감지해서 css 클래스명을
교체하는 기법)
2. IE6 지원 안 됨.
클래스명을 교체 하는 기법을 사용하여,
그에 따른 css가 많아지는 점이 좋지 않은 것 같
다.
더 적은 소스의 css가 될 수 있을텐데...
유지보수 시 클래스명에 따른 css가 변경 될 때,
일부 누락 시키는 실수를 할 가능성이 높다.
js 파일이 소스 중간에 있어서 찾는데 어려웠음...
60. http://www.bluewaves.co.kr/main.do
1. IE9 이하 브라우저에서 지원 안 됨.
(조건부주석을 사용하여 페이지 상단에 안내
문구 제공)
2. CSS에 미디어쿼리 사용
브라우저 사이즈 변경 시,
배경과 텍스트가 겹치게 보이는 부분과,
브라우저가 일정 사이즈가 되었을 때 레이아웃이
안 좋게 보인다.
61. http://walking.kgc.or.kr/
1. CSS에 미디어쿼리 사용.
2. IE6,7,8 지원 안 됨.
(브라우저 사이즈 조절 시 레이아웃 깨짐)
브라우저 사이즈 변경 시 컨텐츠가 정리 되지 않
은 채 자리를 잡아 가는 모습이 보기 안 좋다.
조금만 신경 썼으면 좀 더 좋았을텐데..
63. http://www.sony.com/
1. CSS에 미디어쿼리 사용.
2. IE6,7,8에서 브라우저 비정상 종료 됨.
3. Modernizr 라이브러리 사용.
4. 조건부주석을 사용하여 IE 브라우저
별로 <html>에 클래스를 주어 CSS를
사용.
<html>에 클래스를 주어 브라우저별로 css를 다
르게 주는 부분이 있는데.. 핵과 큰 차이가 없다고
생각 된다.
크로스브라우징을 위해서 사용 되었다면,
다른 방법이 충분히 있다고 생각 한다.
66. http://2011.dconstruct.org/
1. Liquid layouts 기법
(레이아웃의 크기를 상대적으로 지정하여 브
라우저의 크기에 따라 유동적으로 변화하게
하는 레이아웃 기법)
2. HTML/CSS에 미디어쿼리 사용.
3. IE6,7,8에서 일부 스크립트와 미디어
쿼리가 적용 안 됨.
Liquid layouts 기법을 사용하여, 미디어쿼리가
IE6,7,8에서 적용되지 않지만, 브라우저 사이즈
변경 시 유동적인 레이아웃을 보여준다.
68. http://viljamis.com
1. Liquid layouts 기법
(레이아웃의 크기를 상대적으로 지정하여 브
라우저의 크기에 따라 유동적으로 변화하게
하는 레이아웃 기법)
2. CSS에서 미디어쿼리 사용.
Liquid layouts 기법을 사용하여, 미디어쿼리가
IE6,7,8에서 적용되지 않지만, 브라우저 사이즈
변경 시 유동적인 레이아웃을 보여준다.
71. 분석후 느낀점
오랜만에 스터디를 하게되서 기분이 새록새록..
준비를 많이 못해서 아쉬운 점이 남는 스터디였다.
- DTD, 뷰포트, CSS3 등 다양한 부분에서 분석 부족.
- 해외에 비해 알려진 국내 적용사례가 적음.
72.
73. 다음 어학사전을 기획한 기획자가 본 반응형 웹
장점
1. 확실히 기획 및 운영 리소스가 적게 든다는 것.
2. 어학사전은 무엇보다 일정상의 부담이 컸었는데, 반응형 웹
이 아니었다면 일정 내에 PC와 모바일을 동시 개편하는 것
은 불가능했다는 생각입니다.
3. 요소가 통일되다 보니 디바이스 별로 제어해야 할 기능이 없
어 운영 리소스도 많이 줄었습니다.
4. 서비스 오픈 이후 투입되는 유지/보수 비용이 결코 작지 않다
는 측면에서 보면 디바이스 별로 일일이 대응하지 않아도 된
다는 건, 확실히 매력적인 요소인 것 같아요.
74. 다음 어학사전을 기획한 기획자가 본 반응형 웹
단점
1. 디바이스 별 특성이 다름에도 통일하다 보니, 포기해야 할 요
소가 의외로 많았습니다. (디자인과 기능 면에서 모두)
2. 사전은 그나마 기능이 적고 텍스트 위주의 서비스라 포기가
쉬운 부분이 있었지만, 다른 서비스였다면 조율이 힘들겠다
싶기는 했었습니다.
3. 확실히 효율적이긴 한데, 서비스 측면에서 보면 사용성이나
가독성 측면에서 포기해야 할 부분이 적지 않은 듯 합니다.
75. 프로젝트 전 기획자가 고려해야 할 부분은 ??
답변
“PC 웹을 기준으로 하되, 디바이스별로 불필요한 요소만 빼면 된다라
고 단순하게 생각했었는데, 생각보다 훨씬 고려해야 할 사안이 많았습
니다.
디바이스 특성별로 다르게 처리되어야 할 부분들이 적지 않았습니다.
이를테면, 모바일을 기준으로 폰트 크기를 맞춰 놓으니 PC웹에서는 가
독성이 떨어지고, 모바일에서는 필요한 기능인데 pc 웹에서는 필요하
지 않아 불가피하게 포기해야 하는 등등의…
브라우저 별 특성을 좀 더 세심하게 살펴서, 중요한 기능과 포기해야 할
기능을 명확히 정리할 필요가 있다고 생각합니다.”
76. 다음 어학사전을 기획한 디자이너가 본 반응형 웹
답변
“다양한 해상도의 스마트기기들이 등장하고 있으므로 사용성 측면으로
본다면 반응형 웹이 곧 많은 서비스들에 적용이 될 것이라 생각합니다.
하나의 룩앤필을 가지고 다양한 디바이스에서 서비스를 보여주는게 사
용자들에게도 브랜드 인지도를 높여줄 듯 싶습니다.
반응형 웹을 적용하기 위해서는 우선 기획적 기능 정의가 잘 정리되어
야 할 듯 싶습니다.
해상도별로 메뉴처리, 이미지, 텍스트, 인터렉션(마우스오버라든지..)
이런 부분의 정의가 우선 필요할 것 같습니다.” - 이어서 -
77. 다음 어학사전을 기획한 디자이너가 본 반응형 웹
답변
“그리고 하나의 소스로 작업되는 것이 원칙이겠지만, 디자인의 입장에
서 보면 해상도 별로 화면을 다르게 보여주기 때문에 화면별로 디자인
시안을 작업해야 하고, 디바이스별로 구성을 통일성있게 구성하고 일
관된 사용성을 경험하게 고민해야 하는 측면의 노력이 필요하게 되죠
~^^
해상도별로 최적화된 디자인을 뽑아내려면 화면별로 CSS를 다르게 가
야하는 부분도 고려가 되어야 해서 이 부분에 대한 개발자와의 논의도
필요할듯해요”
78. 프로젝트 전 디자이너가 고려해야 할 부분은 ??
답변
“처음 시작하는 웹 디자이너라면 우선 서비스를 제작하는 목적이 무엇
인지 그리고 서비스의 흐름등의 전반적인 이해!!
(너무 당연하고 모든 프로젝트에 해당되는 얘기네요.그런데 중요한 얘
기라서 적어보아요^^.)
다음으로 “반응형 웹 프로젝트를 진행하겠다” 라고 하면 우선 디바이스
별 해상도, 폰트, 기능구현에 대한 이해가 필요할 듯 하네요.
(폰트타입과 자간이라든지, 해상도별 이미지 사이즈라든지, 기능구현
이 되는 것과 안되는 것등에 대한 이해가 부족해서 필터링에 시간이 많
이 들어간 부분도 있었던 것 같아요)”