Minicube.kr - 블로그닷컴 Ver 3.03

21세기가 시작된 지 거의 10년이 다 되어가는 2009년에 이르러 네트워크와 인터넷은 놀라운 발전을 이뤄왔습니다. 웹브라우저 시장은 MS의 XX 같은 Internet Explorer가 독점하는 상황을 벗어나서, 지금은 파이어폭스, 사파리, 오페라, 크롬, ... 기타 등등 수많은 브라우저가 서로 웹표준을 향해 경쟁하는 행복한(?) 시대가 되었지요.

하지만, 이런 상황에서도 웹브라우저가 공식적으로 지원하는 이미지 형식은 아직까지는 GIF, JPG, PNG 세 가지 뿐입니다. (BMP는 논외) 그 중에서 가장 돋보이는 포맷은 바로 PNG 인데요...
하지만, 이전에 작성했던 나를 미치게 하는 PNG 라는 포스트에서도 밝혔듯이.. IE6 의 점유율이 10% 이하로 떨어지지 않는 한, PNG의 혜택을 누리기에는 무리가 있습니다.

이런 상황에서 갑자기 8bit PNG 를 활용하자니... 이게 무슨 소린가 하시겠죠? 저도 그랬습니다. IE6 이 버티고 있는 한, png의 p자도 꺼내지 말아야 할 상황이 아닌가! 라고 반문했지요.

png의 포맷은 두가지가 있습니다. 8bit, 24bit 로 나뉘는데요.

1. 8bit : Pallete PNG
   이미지 내의 색상을 index화 하여 256 칼라를 사용할 수 있다는 GIF 와 비슷한 특성을 가지지만, 동일 이미지의 GIF 파일보다 크기가 작습니다. 그 외의 속성은 png와 같습니다. (Alpha Transparency, No Animated)
2. 24bit : Truecolor PNG
   JPG와 같은 1670만 칼라를 지원하며, JPG와 달리 이미지의 손실(열화)이 없습니다. 그래서 이미지의 크기는 JPG보다 크지만, JPG의 최상퀄리티의 파일 크기에 비하면 오히려 작다고 할 수 있습니다. 그외에 역시 Alpha Transparency를 지원하며 애니메이션은 지원되지 않습니다.

PNG 에 대한 자세한 원전은 다음 URL 에서 얻을 수 있습니다.
영어의 압박이 있기에 저도 중간쯤 보다가 말아버렸습니다만, PNG에 대한 모든것이라고 보시면 되겠습니다. ㅠ_ㅠ
http://www.ietf.org/rfc/rfc2083.txt

여기서 주목할 만한 것은 8bit PNG 이미지입니다. GIF와 성질은 거의 비슷한데 GIF보다 파일 크기가 대체로 더 작습니다. 게다가 IE6 에서도 8bit PNG는 GIF와 비슷한 Transparency 를 지원하고 있습니다. 적어도 24bit PNG 처럼 투명 영역이 회색으로 보이는 문제가 없지요. 그래서 8bit PNG를 GIF를 대체하는 웹이미지로 사용할 수 있지 않을까 하는 것이 발상의 전환이죠. ㅎㅎㅎ



물론 이 발상의 전환은 제가 한 게 아닙니다 -_-;;;

다만 PNG 는 이전 포스트에서도 밝혔듯, 각각의 웹브라우저에서 실제 색상은 다르게 표현될 수 있습니다. 직접적인 원인은 PNG 이미지가 자체적으로 감마값을 가지고 있고, 이 값을 해석하는 브라우저가 상이한 결과를 내기 때문인데요...

PNG 파일의 구조는 8bit의 헤더(png이미지라는 것을 알리는 부분)와 여러 개의 chunk 라는 것으로 구성되어 있습니다.
디카로 사진 좀 찍어보신 분들은 아시겠지만 jpg파일도 이미지뷰어로 보면 각종 정보(카메라기종, 조리개, 셔터, WB 등)가 따로 저장되는 것을 볼 수 있는데요, PNG도 실제 이미지 데이터와 별도로 이러한 정보들이 하나의 조각(chunk)으로 저장된다고 보시면 비슷합니다.
색상의 불일치 문제를 일으키는 것은 바로 gAMA chunk 라는 것인데요, 이 값을 제대로 처리하는 웹브라우저가 있고, 이를 잘못 처리하는 웹브라우저가 있기 때문에 색상차이가 보이게 되는 것이지요.

결국, 모든 웹 브라우저에서 같게 표현되게 하려면 gAMA chunk 를 없애는 과정이 필요합니다. 사실 이 chunk를 제거하는 것은 근본적인 해결책은 아닐 겁니다. 근본적으로 해결하기 위해서는, png의 감마 값을 모든 브라우저에서 제대로 지원하고 JPG나 GIF도 이를 지원해야 한다는 뜻인데..... 어렵겠죠? ^^;;;
그래서 조금 우회하여 png 도 다른 이미지와 마찬가지로 하향평준화 시킨다.. 라고 이해하는 것이 좋을 것 같습니다.

이전 포스트에서 새빛 님께서 TweakPNG 라는 프로그램이 있다고 알려주셔서 이 프로그램을 이용하여 샘플 PNG 파일의 정보를 열어보았습니다.



뭔가 굉장히 많죠? IHDR이 png파일의 헤더이며 나머지 bKGD, sRGB, sBIT, pHYs ... 뭔가 못알아볼 데이터들이 많지만 어쨌든 문제가 되는 chunk는 위에 표시한 gAMA chunk입니다.

여기서 gAMA값을 삭제하는 것 만으로 png파일을 웹에서 정상적으로 표기하게 하는 것이 가능합니다. 드디어 문제 해결! 24bit의 트루컬러 PNG는 어쩔 수 없지만 GIF를 대체하여 8bit PNG 를 활용할 수 있어서 상당히 기쁘죠?! ㅠ_ㅠ

but...

웹사이트의 최적화를 위한 길은 정말 멀고도 멉니다. 여기서 우린 당면한 문제 해결에만 급급하지 않고 PNG 파일 자체의 다이어트를 할 수 없을까 고민해볼 수도 있을 것 같네요.
다행히 방법은 있었습니다. gAMA값 외에도 이미지를 표기하는데에 굳이 필요없는 정보들을 삭제하고 데이터영역을 다시 압축하여 최적화시킬 수 있는 툴이 몇가지 존재합니다.

- pngcrush : http://pmt.sourceforge.net/pngcrush/
- pngrewrite : http://entropymine.com/jason/pngrewrite/
- OptiPNG : http://optipng.sourceforge.net/
- PNGOut : http://advsys.net/ken/utils.htm

이것저것 테스트를 해보았는데요, 첫번째 제시된 pngcrush의 경우 명령프롬프트 상에서 실행해야 하는 불편함이 존재했지만 가장 확실할 것 같아 테스트해보았습니다.

실행 방법은 조금 복잡합니다. 간단히 프롬프트 상에서 pngcrush 라고 입력하면 여러가지 옵션이 나오는데 저도 잘 모르겠습니다. ㅠ_ㅠ 아무튼 레퍼런스 코드가 있어서 다음과 같이 입력해보았습니다.

C:\>pngcrush -rem alla -brute -reduce sample.png sample1.png

위 명령을 실행하니 마지막에 나온 정보로 17.16%의 파일 사이즈를 줄일 수 있다고 나오는군요.
그래서 이렇게 나온 파일을 다시 TweakPNG로 열어본 결과 꼭 필요한 헤더와 푸터 chunk(IEND), 그리고 데이터 영역(IDAT)을 제외하고 모든 chunk 가 없어진 것을 확인할 수 있었습니다.



아래 상태표시줄을 확인하면 sample.png 파일의 크기가 13479byte에서 11166byte로 압축되었음을 알 수 있습니다. GIF 에 비해서 PNG 가 용량 면에서 효율적인데도, 덤으로 필요없는 정보를 다이어트 하여 더 크기를 줄일 수 있는 좋은 팁입니다.

이 과정은 조금 복잡하지만, 이 작업을 어느정도 자동화시키면 충분히 실무에도 활용 가능할 것으로 보고 있습니다. 저도 현재 진행중인 모 개편 프로젝트에서 8bit png의 활용과 함께 CSS 스프라이트 등의 최적화 방안을 적용하여 진행하고 있는 중입니다.
적어도 마크업 때문에 사이트 속도가 느리다! 라는 비판을 받으면 자존심 상하지 않나요..?!?! (응?)

pngCrush 프로그램은 다음 URL에서 받으세요.
http://sourceforge.net/project/showfiles.php?group_id=1689&package_id=6641

TweakPNG 프로그램은 다음 URL 에서 받으세요. (Freeware)
http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/TweakPNG.shtml

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

저 자신도 UI개발 일을 하고 있긴 하지만, 오랜 역사를 가진(?) 프로그래밍/개발 분야와는 달리 UI개발 분야는 아직 미개척 분야라고 해도 과언이 아니죠.
확실히 직군으로서도, 개인적으로도 UI개발 직군이 전문성을 가져야 한다는 것을 절실하게 느끼고 있습니다.

마침 다음에서 좋은 행사를 준비하고 있는데요,
개발자가 주축이 되는 DevDay 와는 달리 UI개발 직군이 중심이 되는 UI DevDay 라는 행사를 준비하고 있다고 합니다.



이 분야에 관심있으시고 새로운 분야를 개척하시겠다는 개척 정신을 가지신 분이라면 한번쯤 참가하셔서 견문을 넓혀 보시는 것은 어떨까 싶습니다. ^^
다녀와서 보고서 올려보도록 하겠습니다!

• 일시: 2008년 5월 30일(금) 오후 1시 30분 ~ 오후 6시
• 장소: 삼성동 섬유센터 17층
• 인원: 250명

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

미국 라스베가스에서 현지시간 3월 5일~7일 일정으로 진행되고 있는 MIX08 Conference 에서 Internet Explorer 8 Beta1 버전이 발표되었습니다. 이전 기능을 통합하는 새로운 기능, 웹표준을 지원하는 새로운 렌더링 엔진이 큰 특징이라고 할 수 있습니다.

최근 IE8 에 대한 소식이 잦다는 느낌이 들었는데, MIX08 컨퍼런스를 통해 Beta1 버전을 일반 사용자도 다운받아서 사용해볼 수 있도록 제공하고 있네요.
이번 버전은 개발자와 디자이너들을 위한 Beta1 버전으로, 일반인들까지 대상으로 하는 Beta2 버전은 여름 쯤에 제공하겠다고 밝혔답니다. 개발자와 디자이너들에게는 이번 Beta1 버전을 통해 미리 IE8 이 정식으로 발표될 때를 준비하라는(?) 메세지를 주고 있는 것 같습니다. ^^;;

아직까지는 기존의 IE7 과 거의 비슷한 인터페이스를 보여주고 있습니다만, 베타2와 정식판에서는 어떤 비주얼을 보여줄지 기대되네요.

다운로드 :
http://www.microsoft.com/windows/products/winfamily/ie/ie8/readiness/Install.htm

IE8 의 큰 특징인 동시에 유례없는 관심을 받고있는 이유를 찾아보자면, IE8 에는 기존의 호환 모드 대신 웹표준을 준수하는 표준 렌더링 엔진이 기본 모드로 채택되었다는 것이라고 할 수 있겠습니다.

이전 포스트에서도 밝혔듯이 IE8 이 표준 모드에서 Acid2 테스트를 통과했다고 알려졌는데요, 원래 IE8 에서는 이 표준 렌더링 엔진이 아닌 기존 IE7 까지 쓰이던 호환 모드를 기본 엔진으로 채택하겠다는 입장을 고수하고 있었습니다. 이는 각각 장단점이 존재하는데요, 이때문에 개발자들 사이에서 큰 논쟁이 이루어졌고, 결국 IE 를 개발하던 Microsoft는 이들의 의견을 받아들여 IE8의 기본 모드를 표준 모드로 채택하기로 했다고 합니다.

MSDN 블로그 :
http://blogs.msdn.com/ie/archive/2008/03/03/microsoft-s-interoperability-principles-and-ie8.aspx

Microsoft 가 OS를 독점한 상황에서 독자적인 웹브라우저를 개발하던 이전 상황과는 달리 Mozilla 계열의 Firefox의 놀라운 성장세와 함께 더이상 웹표준을 외면할 수 없는 환경적 영향이 IE 의 개발 방향을 크게 바꾸었다고 생각됩니다.

IE8 이 기존의 정책을 바꾸어 웹표준에 친화적인 웹브라우저로 공개되긴 했지만, 앞날이 그렇게 순탄하지만은 않습니다. Netscape 가 존재하던 시절과는 달리, 강력한 오픈소스를 무기로 한 Firefox 3 가 버티고 있고, IE 외에도 웹표준에 최적화된 수많은 웹브라우저가 존재하기 때문이죠.

차후 웹브라우저 전쟁은 플랫폼에 관계없이 웹표준을 얼마나 잘 지키는지, 사용자를 위한 특화 기능을 얼마나 잘 지원하는지에 따라 승패가 결정될 거라고 생각이 됩니다. 이 상황에서 IE 도 기존의 독점적 자세와 지위를 버리고 정정당당히 다른 웹 브라우저와 경쟁을 벌여 좋은 소프트웨어로 발전하기를 바랍니다.

IE8의 새로운 기능을 살펴보겠습니다.
MIX08 컨퍼런스의 발표에서는 8번째 버전에 맞추어 8가지의 내용으로 IE8의 특징을 소개했습니다.  

• CSS 2.1
  Firefox, Safari, Opera 등의 기존 웹브라우저들과 마찬가지로 CSS2.1을 지원합니다.
• CSS Certification
  CSS2.1 스펙을 테스트하는 Acid2 Test를 통과했습니다.
• Performance
  자바스크립트 개발자라면 누구나 느낄법한 IE의 속도문제와 버그를 해결하여 타 브라우저 만큼의 퍼포먼스를 보여준다고 합니다. 실제 웹을 서핑한 결과 이전보단 체감적으로 빨라졌다는 느낌을 주고 있습니다.
• HTML 5 Start
  HTML5 스펙을 지원합니다. HTML5는 현재 초안(Working Draft) 작업이 진행중인데요, 일부 스펙의 지원을 시작했다고 언급하고 있습니다. (Ajax UI에서 뒤로/앞으로 버튼 액션 지원, 오프라인 후 컨텐츠 임시저장)
• Development Tools
  웹브라우저 내장의 개발툴로는 유명한 Firefox의 firebug가 있는데요, 이와 비슷한 강력한 개발 도구를 내장하였다고 합니다.
• Activities
  웹을 사용할 때 원하는 컨텐츠에 대해 빠르게 외부 서비스로 연결할 수 있는 기능입니다. 보통 필요한 정보가 있다면, 이를 마우스로 드래그하여 다른 서비스에서 붙여넣기 형태로 많이 이용하는데, 이 과정을 매우 쉽게 한 것이라고 합니다. 크게 "Look up" 과 "Send" 기능으로 나뉘는데 Look up은 해당 콘텐츠에 대한 타 서비스의 콘텐츠를 볼 수 있고, Send는 말 그대로 외부 서비스(ex. 블로그)로 보내는 것을 말합니다.
   
• WebSlices
  쉽게 말하면 RSS의 다른 개념이라고 말할 수 있는데요, 해당 웹페이지에서 제공하는 단편적인 정보들을 상단의 Favorite Bar에 등록하여 해당 정보의 최신 업데이트를 실시간으로 받아볼 수 있도록 하는 기능입니다. 마이크로포맷과 비슷하다고 보시면 될 듯 합니다.
   
• Download after keynote?
  특징은 아니지만, 해당 프리젠테이션이 종료된 후부터 IE8을 실제로 다운받을 수 있다고 하는 내용입니다. 실제로 현지시간 3월 5일 오후 12시 30분 즈음부터 다운로드 서비스를 개시했다고 합니다.

이외에도 프리젠테이션에서 언급하지 않은 추가된 기능이 몇 가지 더 있습니다.

• 버전별 렌더링 엔진 지정
  기존 IE8개발정책 때문인지, 베타버전이기 때문에 존재하는 것인지 확실하지는 않지만, 메타태그를 통해 구 버전의 렌더링 엔진으로 웹사이트를 이용할 수 있도록 하고 있습니다. 또한 "Emulate IE7" 버튼을 통해 IE8 베타 버전이 아닌 기존 엔진을 디폴트로 사용할 수 있도록 배려하고 있습니다.
  개인적으로는 정식 IE8이 출시될 때는 이 기능이 사라졌으면 합니다. 만약 이 옵션이 그대로 존재한다면 웹표준에 맞지 않는데도 개선할 의지가 없는 웹페이지들이 IE8 정식 출시 이후에도 계속 존재할 가능성이 높을 것 같습니다. 
• 자동 크래시 복구 기능 (Automatic Crash Recovery)
  웹서핑을 하다보면 웹브라우저가 다운되는(죽는) 경우가 발생하는데요, IE8에서는 크래시가 발생한 탭에서 내용을 복구하여 볼 수 있도록 한 기능입니다. Firefox에서는 이미 지원하는 기능이죠.
  
• Safety Filter
  IE7 에서 지원하던 피싱 필터를 개선하여 "Safety Filter"라는 이름으로 추가되어 보안이 향상되었습니다.
• Favorite Bar
  IE7 에서 쓰였던 즐겨찾기 기능에서 더 확장되어 웹 콘텐츠 뿐만 아니라 링크, RSS피드, WebSlice, 오피스 문서(Word, Excel, Powerpoint)도 배치할 수 있습니다.
  
• URL 강조기능
  현재 접속하고 있는 사이트의 도메인과 경로를 구분하여 보여줍니다.
  

현재 IE8에 대한 프리젠테이션 영상은 Microsoft 사이트에서 실버라이트로 제공하고 있습니다. 앞으로 IE8에 대한 자료가 꾸준히 공개될 듯 하고 IE8에 대해 많은 기술적인 이슈가 존재할 듯 하네요.

프리젠테이션 영상 :
http://www.microsoft.com/presspass/events/mix/default.mspx

이 포스트는 NHN WSG(Web Standardization Guide) 블로그와 네이버의 개인 블로그에 함께 연재되고 있습니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

UI개발자의 역할은 제가 생각하기로는 좁은 의미, 그리고 넓은 의미가 있다고 봅니다.

우선 좁은 의미로 보면, UI개발자의 주 업무는 디자이너가 디자인한 사이트를 구조화 하고 HTML과 CSS를 사용하여 실제로 사용자가 보는 화면을 제작하는 것입니다.
그 과정에서 디자이너와 프로그래머 사이의 의견을 조율하고 협상(?)을 하고, 각각의 브라우저에서 같은 디자인으로 보일 수 있도록 크로스 브라우징에도 신경을 써야 합니다. 또한 퍼포먼스의 하향을 유발하는 비표준 방식을 지양하고, 웹표준을 준수하여 페이지를 제작해야 하죠.
또한 화려하고 동적인 인터페이스를 부여하는 자바스크립트 개발(예. ajax)이나 플래시 개발도 UI개발의 범주에 들어가므로 이 분야까지 할 수 있다면 금상첨화입니다.

따라서 UI개발자가 하는 일은 XHTML/CSS를 통한 화면 제작, 웹표준 준수, 개발단과 디자인단의 조율, ajax와 플래시를 사용한 RIA제작 등이 주 업무라고 볼 수 있겠습니다.

그렇다면 좀더 멀리 미래를 예측하는 마음으로 넓은 의미로써 "UI개발자"가 하는 일을 더 전문화 시킬 수 있을까요?

예전에는 UI개발이라는 영역 자체가 존재하지 않았습니다. 디자인 파트 또는 프로그래밍 파트의 지원역으로서 단순히 psd를 슬라이싱해서 HTML로 코딩한 후 개발단에 넘겨주는 작업만 해왔죠. 그나마 최근에야 웹표준과 크로스 브라우징, Windows Vista라는 이슈에 맞물려서 겨우 'UI개발'이라는 모호한 단어로 표현하면서 발전을 도모하고 있는 상황이지요.
극단적으로 말하자면 웹서비스개발에 있어서 'UI개발'이라는 영역은 있어도 되고 없어도 되는 영역입니다. UI개발자가 가지고 있는 롤은 기획파트, 디자인파트, 개발 파트에서도 다 나눠서 할 수 있는 일들이죠.
또한 웹 기술 중에서는 상당히 진입장벽(?)이 낮은 관계로, 현재로선 웹에 조금 관심이 있는 고등학교/대학교 졸업 출신이 새로 6개월 정도 빡세게(?) 교육을 받는다면 누구나 할 수 있는 그런 일입니다.
가뜩이나 한국은 개발자로서의 생명이 매우 짧은 불운한 나라라는 점은 더욱 UI개발자를 암울하게 하고 있습니다.

이 상황에서 제가 하고 있는 UI개발이라는 新영역의 일을 어떻게 구체화하고 꼭 필요한 영역으로 포지셔닝할 수 있을까 하고 고민을 많이 했습니다.
그래서 막연하게 생각해왔지만, 디자인과 개발 파트의 지식을 동시에 어느정도 알고 있어야 하는 특성상 의외로 테크니컬 컨설턴트의 역할을 할 수 있을 수도 있고, 웹에 있어서의 UI라는 것을 전체적으로 총괄하는 인터페이스 전문가로서의 역할도 있을 수 있다고 생각해왔습니다. 어쨌든 이 고민은 UI개발자로서 계속 진행형(?)입니다만...

제가 이번에 옮긴 회사에서 신규 입사자들과 함께 회사 소개와 팀 소개, UI개발에 대한 좋은 이야기를 듣고 UI개발의 길찾기에 조금은 더 도움이 된 것 같습니다.

UI개발이란 말 그대로 User Interface를 개발하는 것을 말합니다. 사용자는 어떠한 조작 부분을 조작하여 기계를 사용할 수 있게 됩니다. 따라서 사용자는 항상 조작부분에 해당하는 인터페이스를 사용하죠. 이 과정에서 사용자 경험이 발생하게 되는데, 사용자 경험을 만드는 일이 바로 UI개발이라는 거죠.
웹개발을 하는 사람들을 모두 포함하여 모든 사람들은 사용자가 될 수 있습니다. 물론 UI개발자도 이에 포함되는데, 기획 파트를 제외하면 디자인 파트나 프로그래밍 파트에서는 일반적으로 사용자보다는 디자인 또는 기술을 우선하는 경향이 없지않아 있습니다. 일반 사용자의 역할과 개발자 사이의 갭을 연결시켜 줄 수 있는 역할을 바로 UI개발 파트에서 할 수 있지 않을까요?
이 일을 위해서 UI개발자는 사이트를 개발하는 과정에서 사용자경험에서 나오는 피드백을 받거나 직접 자신이 피드백을 하는 일도 맡아야 합니다. 어느정도 기획과 UX파트에서 하는 일을 가져온다고 볼 수 있겠네요.

UI개발 작업에서 가장 중요한 포인트는 사용성, 접근성, 행동유발 입니다.

사용성이란 말 그대로 인터페이스를 통한 조작을 통해 얼마나 잘 사용할 수 있는지를 나타내는 정도입니다. 대표적인 예로 들 수 있는 것이 많이 볼 수 있는 TV나 VTR의 리모콘입니다. 리모콘.. 빡빡한 버튼... 아시죠?
그에 비해 애플의 간결한 인터페이스. 애플이 찬사를 받는 이유는 그 특유의 디자인 때문일 수도 있겠지만, 어떻게 보면 직관적이고 심플한 인터페이스의 힘이 더 크다고 볼 수 있지 않을까요? 다만 사용성과 기능성은 서로 TradeOff 관계에 있기 때문에 둘 간의 조율점을 찾는 것는 고민거리죠.
접근성은 최대한 많은 사용자들이 인터페이스를 사용할 수 있도록 설계하는 것입니다. 모든 사용자를 만족시킬 수 있는 것은 현실적으로 불가능합니다. 유닉스에서 사용하는 linx 브라우저까지 완벽하게 지원해 줄 수 있는 시간과 리소스를 가진 회사는 거의 없다고 보면 됩니다. 구글은 과연 가능할까요..?
또한 접근성 면에서 가장 민감한 부분이 장애인 사용성 부분인데요. 장애인이 접속해서 잘 사용할 수 있는 사이트가 접근성이 좋다는 말과 동일한 의미라고는 볼 수 없습니다. 이건 마치 IE에서 당장 렌더링 문제가 발생하는 것을 해결하기 위해 CSS핵을 사용하는 것과 같은 거죠. 이러한 극도의 접근성을 보장하기 위해서 오히려 99%에 이를 수도 있는 일반 사용자의 접근성을 역차별하는 일은 있으면 안되겠죠? 따라서 접근성이란 모든 사람들을 위한 인터페이스보단 최대한 많은 사용자를 위한 인터페이스를 구현하는 것이 접근성의 의미라고 생각합니다.
행동유발이라는 것은.. 간단하게 해당 인터페이스를 어떻게 사용하는지 미리 인지시키고 이를 그대로 따르게 하는 것을 말합니다. 간단하게 체크박스와 라디오버튼의 예를 볼 수 있는데, 우리들은 말을 따로 하지 않아도 체크박스는 여러 개를 한꺼번에 선택할 수 있고, 라디오버튼은 한 그룹중 하나만 선택할 수 있다는 것을 알고 있으며 이대로 행하는 것을 말합니다.
버튼은 누르라고 있지 빼라고 있는 것은 아니자나요..? ^^;

웹은 아직 발전 중에 있습니다. 데스크탑 애플리케이션도 미약하지만 천천히 웹 애플리케이션으로 진화하고 있는 중이죠. 아시다시피 구글 오피스가 대표적 예라고 볼 수 있는데, 앞으로는 '마이너리티 리포트'에서 등장했던 손가락을 이용한 UI가 실제로 웹으로 등장할 수도 있지 않을까 상상할 수 있지 않나요?
 
(과연 제가 은퇴(?)할 때까지 그러한 인터페이스가 실제로 등장하고 만들 수 있을까요...?)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

ajax나 자바스크립트에 관련된 소식을 많이 알려주는 해외 블로그 중에 ajaxian 이라는 사이트가 있습니다. 시간이 나면 자주 방문해서 글을 읽으면서 영어를 읽는 연습(?)도 하고 있습니다만, UI개발자로서 흥미있는 소식이 업데이트 되어서 스크랩 해봅니다.

ajaxian's article : http://ajaxian.com/archives/xray-your-internet-explorer/
Original Post : http://westciv.com/xray/

XHTML/CSS 개발을 하다 보면 박스 모델이란 난관에 부딪히게 됩니다. HTML의 각각 Element를 감싸는 요소는 margin, padding, border 등이 있는데, 컨텐츠를 박스 형태로 감싸는 이 요소를 더해서 정리한 것을 박스모델이라고 하죠. 그런데 이 박스모델을 렌더링 하는 방법이 각각의 브라우저들 끼리 차이가 발생합니다.
그래서 HTML 개발 시에는 이 박스 모델을 잘 파악하는 것도 일인데요, 이 작업을 도와주는 툴로는 IE의 플러그인인 Developer Toolbar 라던가 Firefox의 FireBug 같은 툴이 유명합니다.
FireBug 는 박스모델 외에도 여러 편리한 점이 많아서 유용하게 사용하는데 아무래도 문제는 IE 였습니다. IE에서 사용할 수 있는 Developer Toolbar 는 파이어폭스의 그것에 비하면 상당히 부실하죠. 그래도 어쨌든 없는 것보단 낫기 때문에 그럭저럭 사용하고 있었는데요...

XRAY 라는 스크립트가 개발되었다고 하네요.
이 툴은 자바스크립트로 되어 있고, 북마크 형태로 제공됩니다. 사용을 하면 아래 화면처럼 XRAY 안내가 뜨는데요.. 이상태에서 어떤 엘리먼트를 클릭하면 해당 엘리먼트의 정보를 상세히 보여줍니다. 엘리먼트의 이름, ID, class 부터 시작해서 position, border, margin, padding 등의 정보를 비쥬얼하게 보여준답니다.

사실 예전에 발표되었을때는 정작 중요한 IE6 이 지원이 안되서 이게 뭐야! 하면서 그냥 넘어갔었는데 (파이어폭스에선 그냥 FireBug를 쓰는게 훨씬 낫죠) 이번 발표된 XRAY 0.91a 버전의 경우엔 IE6 버전도 지원된다고 합니다!! 그래서 현재 저도 북마크해놓고 유용하게 사용중입니다.
정식으로 사용 가능한 브라우저는 IE6 이후, Webkit & Mozilla 계열 브라우저(Safari, Firebox, Camino, Mozilla)를 지원한다고 하는데 아쉽게 오페라를 지원하지 않는군요...

사용방법은 간단합니다. 사이트에서는 북마크렛(bookmarklet) 형태로 지원한다고 하는데요, 위에서 밝혔듯 북마크로 링크를 저장한 후 필요할 때에 클릭해서 사용하면 됩니다.


이렇게 XRAY버튼에서 오른쪽 마우스버튼을 클릭한 후 즐겨찾기에 추가(F) 를 선택하시고 이걸 "연결" 탭에 추가하시면 됩니다. (IE기준)

그 후 아무 사이트나 열어보시고 저 북마크를 클릭하면 가장 위의 그림처럼 안내 메세지가 뜨구요, 그 후부터 XRAY 툴을 사용할 수 있습니다. 그만 사용할 때는 사이트를 리로드(F5)하거나, X버튼을 클릭하시면 됩니다.

ajaxian.com 은 재미있는게 많이 올라와서 좋아요~ ㅋㅋ

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

얼마 전 회사에서 진행했던 세미나 발표자료입니다. 웹페이지 속도를 개선할 수 있는 방법을 UI개발 시점에서 살펴본 것이구요. 이 발표자료의 원본은 2007년 6월 8일 영국 런던에서 있었던 @media 2007 conference 에서 Nate Koechley 라는 분이 High performance for Web sites - 14 Rules for faster pages 라는 주제로 발표하신 자료입니다.
웹페이지의 속도를 빠르게 하고 효율성을 높여줄 수 있는 14가지 룰과 그와 관련된 배경지식을 다루고 있구요. UI개발과 관련이 있지만, 서버사이드 스크립트 차원이나 서버 차원에서 다루어지는 것도 있습니다.

우선 제가 속한 팀이 UI개발 팀이기 때문에 팀 업무영역에 관련된 것들만 추려서 발표자료를 만들어서 발표했었구요, 실제 발표내용은 스크립트로 넣었으니 참조하세요.

여담이지만, 지금 이 발표자료는 국내 포털 내의 관련 팀들도 다 한번씩 리뷰를 거쳤다는 소문이 있군요. ㅋㅋㅋ

제작은 Office 97-2003을 위한 PPT 파일, 그리고 Office 2007을 위한 PPTX 파일로 구분하여 올렸습니다. 몰랐는데, Office 2007의 pptx 문서형은 각종 자료와 xml파일의 압축파일 같은 형태로 되어 있네요;;;

발표자료 - 효율적인 웹페이지 제작을 위한 기법 (97-2003) (1.9MB)
발표자료 - 효율적인 웹페이지 제작을 위한 기법 (2007) (0.6MB)

Nate Koechley's BLOG and current post
High Performance for web sites presentation for PPT (25MB)
High Performance for web sites presentation for PDF (3MB)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

두세달 전 마이크로소프트에서 발표한 새로운 UI환경인 Surface. 철지난 포스팅이지만, 나름 UI나 UX에 관심이 많기 때문에 언젠가 포스팅하려고 했습니다.
자세한 자료는 마이크로소프트 홈페이지에 소개되어 있구요. 영문자료이긴 하지만, 플래시로 잘 꾸며놨네요.

Product name은 Microsoft Surface
애플의 i-Phone을 표절했다느니 하는 소리도 있었고 실제로 멀티터치 부분은 닮은 것도 사실이지만, 2001년부터 시작되어 이제야 결실을 맺게 된 상당히 오래 연구되어 온 프로젝트입니다.

30" Table-like Display 형태의 멀티터치 스크린을 통한 혁신적인 UI 를 제공하는 것이 특징입니다. 전통적인 입력도구인 마우스나 키보드가 존재하지 않죠. 4대 특징은 다음과 같습니다.

1. Direct Interaction(직접 상호작용) : 사용자들은 실제로 디지털 정보를 손으로 "잡을(Grap)" 수 있고, 전통적인 마우스나 키보드를 사용하지 않고, 손동작을 통해 상호작용이 가능.
   
2. Multi-Touch Contract(멀티터치) : 기존의 one point만 입력 가능한 터치스크린과 달리 복수의 입력(Dozens and dozens of Touchs)을 한꺼번에 지속적으로 받을 수 있음.
   
3. Multi-User Experience(다중사용자 경험) : Horizontal Form Factor 는 여러 사람이 동시에 작업을 가능할 수 있도록 함.
   
4. Object Recognition(물체인식) : 스크린 위에 특정 물체를 놓으면 이를 인식하여 Surface 에서 반응할 수 있으며, 디지털 정보를 제어하는 것이 가능함.

Microsoft Surface Computing의 큰 특징은 멀티터치가 가능한 30인치의 평면 형태(Table-like)의 디스플레이이며, 이 스크린은 복수의 입력(Dozens and dozens of Touchs)을 받아들일 수 있습니다. 크기는 높이가 22인치, 테이블은 42" x 21" 이며, 표면 소재는 아크릴, 내부 프레임은 코팅처리된 강철입니다.
커스터마이즈된 Windows Vista 를 OS로 사용하며, 통신환경으로는 Ethernet 10/100, Wireless 802.11b/g, Bluetooth 2.0 이 사용되며, 2007년 말부터는 전국의 호텔이나 레스토랑, 공공장소에 설치될 예정이라고 합니다. (물론 미국 현지 이야기입니다. ㅠㅠ)
여담으로 Surface 개발 프로젝트에서 멀티터치 개발을 총괄한 사람은 한인 2세인 Jefferson Han 으로 알려져 있습니다.

발표 당시 상당히 재미있게 봤습니다. UI나 UX에 관해 상당히 관심이 있기 때문에, 여기에 관련된 자료를 찾아보고 있는데, 예전에 막연히 생각했던 것들 중에 일부가 실제로 구현이 되는 것을 보게 되니 신기하네요.

미래가 배경인 영화중에 "마이너리티 리포트"와 "아일랜드"를 기억하시나요? 마이너리티 리포트에 나왔던 3D UI 라던가, 아일랜드에서 악당 보스가 쓰던 Table-like 컴퓨터... (그거 몇인치인가요? ㅠㅠ 부러워라) 이것들이 실제로 구현될 날도 얼마 남지 않은 것 같습니다.

데모 영상 만으로는 실제로 할 수 있는 일을 냉정히 보자면 미디어(사진,동영상) 정리, 자료교환 등이 고작입니다. 하지만, 앞으로 Microsoft에서 Surface Computing에 관한 SDK와 많은 자료를 공개한다면 훨씬 다양한 용도의 소프트웨어를 통해 이 UI환경을 사용할 수 있을 것 같습니다.

앞으로의 컴퓨팅은 어떻게 변할지, 어떻게 편리하게 될 지 상상하면 참 즐거워집니다 :)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

웹표준이라는 단어가 업계에 이슈화 된 계기는 개인적으로 "FireFox와 Windows Vista의 출현"이라고 생각합니다.

MS에 종속적(?)이던 우리나라에선 디자인과 코딩도 항상 IE 위주, 그리고 IE에서만 동작하는 ActiveX(COM) 위주로 웹사이트를 제작해 왔죠. Mozilla 계열, 또는 Mac의 Safari 같은 웹브라우저를 사용하는 유저는 인터넷 사용자의 0.1%도 안되는 극소수였기 때문에 이들의 불평은 아예 무시되어 온 것이 사실입니다.
하지만 해외에서 급속하게 점유율을 늘려가는 파이어폭스의 존재로 인해, 우리나라도 컴퓨터를 조금 한다는 1~20대부터 파워유저에 이르기까지 파이어폭스를 사용하는 사람이 계속 증가추세에 있고, 제대로 보이지 않는 국내 대다수의 웹사이트로 인한 불평의 목소리도 점점 커졌습니다.

그리고 Windows Vista의 출현... Windows Vista의 강화된 보안 때문에 일반 ActiveX의 경우 Admin(관리자)의 권한이 없으면 설치되지 않습니다. 그래서 2006~7년 초까지 ActiveX에 의존하여 서비스되었던 금융권 웹사이트 쪽이 한바탕 난리가 났었죠? 오죽하면 정부에서 Windows Vista를 쓰는 것을 연기하라고 권고를 할 정도로... 지금은 어느정도 해결이 되었지만, 역시 Windows XP 보다는 불편한 것은 사실이죠.

시장 상황이 이렇게 변해온 가운데 우리나라 관련 업계에서도 "웹 표준"에 대한 논의가 활발히 이루어진 걸로 알고 있습니다. 하지만, 웹표준이 처음 화제가 되었을 때, 왜 웹표준을 지켜서 코딩을 해야하는가 하는 이유는 단순히 TABLE태그의 존재에 있었다고 생각합니다. TABLE태그 때문에 웹표준이 아니라고 하고 단순히 다른 웹 브라우저에서 똑같이 보이는 것(크로스 브라우징)이 웹표준이라고 알려지는 경우가 많았습니다.

뭐 이제까지 경험으로 느낀 개인적인 것들이 대부분이지만, 나름대로 웹표준이 왜 필요한가 생각해 보았습니다.

1. 코딩을 단순화시킬 수 있다.

2. 태그들의 원래 역할을 찾을 수 있다.

3. IE이외에 모든 브라우저에서 같은 화면을 볼 수 있도록 할 수 있다.

4. 구조와 표현이 완전히 분리될 수 있다.

5. SEO (Search Engine Optimization)

뭐랄까.. 상당히 긴 글이 되어버렸습니다. ^^;; 웹표준에 대한 현재로서의 제 생각은 이렇습니다만, 기술은 항상 발전하는 거죠. 앞으로는 어떤 기술이 웹표준이 될 수 있을까요?
그건 차차 제 지식을 업데이트(?) 해야겠지요~

그러니까... 다들 웹표준 지킵시다~!!

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

UI개발이라는 직군은 국내에서 탄생한지 얼마 되지 않은 생소한 직군입니다. 보통 "HTML코더"라고 표현하죠? 이른바 HTML코딩이라는 수단으로 디자인과 개발의 단순 지원 역할을 해주던, 웹개발 프로세스에서는 중요성이 많이 떨어지는 직군... 이었습니다.

하지만 지금은 사정이 많이 틀려졌죠. Web2.0 이라는 패러다임의 등장에 의해 세계의 웹사이트는 과도기에 휘말리게 됩니다. 아시다시피 End-User가 보는 화면은 HTML, 즉 "HTML코더"가 만들어내었던 화면인데, 국내에서는 '대충대충 빨리빨리'의 영향으로 매우 낮은 효율과 품질을 보이는 화면이 양산되어 왔던 거죠.
물론 사이트가 느린건 서버나 프로그램 로직 자체의 비효율성 때문일 수도 있지만, 이러한 Back-end 단의 비효율성 보다는 사용자가 HTML과 이미지, 기타 구성요소를 받아서 표현하는 Front-end 단의 비효율성이 체감적으로 더 느리게 느껴집니다.

Web 2.0 의 7가지 정의 중 "가벼운 프로그래밍 모델" 이라는 것이 있습니다. 사용자의 참여와 공유를 중요시하는 Web2.0 사이트가 복잡한 아키텍쳐와 과다한 구성요소를 가지고 있다면, 빠르게 바뀌는 사용자의 반응에 대응을 할 수 없어 도태되고 말지요. 따라서 사이트를 가볍게 제작하기 위한 방안으로써 UI 개발이라는 직군이 어느때보다도 중요한 포인트가 되었다고 생각합니다.

UI개발자가 하는 일은 아직도 과거와 마찬가지로 디자이너로부터 디자인을 받아서 이를 HTML, CSS, JS 등으로 구조화한 후 이 작업물을 개발 파트에 넘기는 작업이 주요 업무입니다. 디자인 파트와 개발 파트를 자연스럽게 이어주는 작업이죠.
하지만 기존과 달리 퍼포먼스, 웹표준, 접근성의 중요성이 크게 부각되었고, 이것을 바탕으로 실제로 최종 화면을 만들어낼 수 있는 직군이 'UI개발' 이라는 거죠.

어느덧 경력도 따지고 보면 약 5년에 가까워지게 되었고, 대학도 졸업하게 되어 사회에 정식으로 첫발을 내디디려고 하고 있습니다. 그러면서도 남들처럼 대기업이나 일반 기업에 취직하지 않고, 제 소신대로 UI개발의 길을 선택하였음을 후회하지는 않습니다. 오히려 앞으로 웹으로 보는 UI가 어떤 변화를 보여줄 지, 이 변화 속에서 UI개발자, 웹 퍼블리셔로서 어떤 걸 할 수 있을지 생각해보면 즐겁기도 합니다.

아직은 과도기입니다. 대형 포털사이트나 대형 웹에이전시가 아니고서는 사용자경험에 따라 UI를 잘 설계하고 접근성을 극도로 높이는 것보다는 어떻게 하면 예쁘게 표현하느냐를 중요시하는 곳이 많지요.
앞으로 'UI개발' 직군이 예전처럼 단순직으로 도태될지, 아니면 웹개발에 있어서 기획, 디자인, 개발을 전부 포괄할 수 있는 중요한 직군이 될지는 "내 손에 달려있다"는 생각으로 열심히 노력해보려고 합니다.

그 노력의 결과, 성장하면서 느끼게 되는 것들을 이 블로그에서 다뤄보고자 합니다. ^^

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.