24 ways to impress your friends – 웹 개발에 관련된 다양한 주제의 주옥같은 글들이 모여있다.
웹 개발에 관심을 가진 사람이라면, 여기에 있는 글 하나하나 모두 머리 속에 담아놓고 싶어할 것이다. 이미 2005년도서부터 시작해서 한해에 모두 24개의 방법이 소개되는 듯한데, 올해는 아직 13개의 비법만이 올려져 있다.
나머지의 비법도 마저 공개되길 바래본다.

그런데, 이런 것으로 감명받을 수 있는 친구는 분명 괴짜이어야겠지. 😛

 없음.

Yahoo! User InterfaceBlog의 글에도 나와 있듯이, 웹 브라우져에서 특정 웹 페이지를 읽어드리는데 가장 많은 시간이 소요되는 부분은 html 문서를 생성해서 전달하는 과정보다도 그림 파일들이나 스크립트, 스타일쉬트들과 같은 기타 부분들을 읽어드리는 데에서 대부분의 시간이 소요되는 것으로 알려져 있다.
그렇다면, HTTP의 요청 횟수를 적당한 수준으로 줄일 수 있다면, 여기서 얻어지는 성능의 향상은 서버 튜닝이나 DB 최적화에 의해 얻어지는 성능의 향상보다 훨씬 손쉽게 더 큰 이득을 볼 수도 있다는 얘기가 된다.

하지만, HTTP의 요청 휫수를 줄이고자 무턱대고 멋드러진 웹 유저 인터페이스를 포기할 수도 없는 노릇.
그래서, 불필요한 HTTP 요청들을 즐이면서도 효과적이고 멋진 유저 인터페이스 환경을 제공하기 위한 노력으로서, 관련 자바스크립트나 CSS 파일들을 압축해서 한 데 묶고 캐쉬 기술을 사용하거나 메뉴의 Rollover 이미지들을 하나로 묶는(Pixy rollover) 등의 기법들이 사용되기도 한다.
물론, 여기서 더 나아가 사용자들이 취할 수 있는 조치로, 웹 페이지의 로딩 속도를 단축하기 위해 특정 웹 브라우져의 HTTP의 Pipelining 기능을 커놓는 작업도 할 수 있겠지만, 아직 모든 브라우져들이 이 기능을 지원하지도 않고, 또한 대부분의 서버들은 아직 pipeline된 요청들에 대해 편차가 심한 반응들을 보여주는 것으로 알려지고 있다.

따라서, 적당한 HTTP 요청 횟수를 판단하는 것은 웹 사이트별 사용 환경과 요구 사향에 따라 차이를 보일 수 밖에 없으며, 결국은 개발자 경험에 의한 판단이 중요하다고 말할 수 있다. 여기서 판단의 기초 자료로 사용될 수 있는 도구로 마침 BETA 딱지를 붙이고 새로 갱신되면서 추가된 Firebug의 Network Monitoring 기능을 빼놓을 수 없다.

위에 보이는 창에서처럼 FireBug의 Net 항목을 선택하면, 현재 접속한 웹 페이지를 읽어드리는데 소요된 HTTP 요청들의 횟수와 크기, 시간을 파일별로 한 눈에 살펴볼 수가 있다. 여기서 얻은 자료는 유별나게 웹 페이지 로딩 속도를 지체하게 만드는 불필요한 병목 요인을 끄집어내서, 추가 최적화 작업이 필요한지를 판단하는 중요한 단서가 될 수 있을 것이다.

결국, 웹 개발자들에게 FireBug는 찰떡궁합이라는 얘긴가?

할 수 없이, 설치해도 그만 안 해도 그만인 보안프로그램을 따돌리고, 뒷구멍으로 들어가 보니,

집안이 너무나 엉망이라 당황해서 그랬나보다. 😡
천만이가 아니라서 다행이야.

웹 사이트 개발 과정 중에서 사이트의 기본 틀(wireframes)을 잡는 과정은 전체 웹 사이트의 구조와 전달 형식을 규정짓는 단계로서, 아마도 사이트의 규모가 커질수록 그 중요성은 더욱 커질 것이다.

기본 틀을 잡는다는 것은, 페이지의 헤딩이나 이동 메뉴, 문서의 꾸림 정보, 사이드바 그리고 어플리케이션 인터페이스와 같은 사이트에 포함될 주요 요소들을 추가/정의하고 위치를 잡는 작업이다.
이렇게 계획 단계에서 기본 틀을 제대로 잡는 것이 중요한 이유로는, 웹 개발 팀원들 간의 의견 교환을 통한 기본 개발 지침과 방향을 마련하게 되면서 나중에 발생할 수 있는 여러가지 변경 사항들에 관한 의견 소통을 원활하게 하고, 또 사이트가 포함하게 될 각 요소 간의 관계들을 일목요연하게 나타내면서 훨씬 수월하고 효과적으로 사이트의 동작과 스타일들을 표현할 수가 있기 때문이다.

그런데, 이러한 중요성에도 불구하고 작업의 특성상 하얀 종이 위에 사이트의 기본 틀을 여러 번 그리고 고치기란 번거로운 작업이 아닐 수 없다. 그래서 이런 수작업을 보다 효과적으로 수행하는데 도움을 받을 수 있는 도구로 다양한 도표 제작 어플리케이션인 OmniGraffle를 사용하게 되면 그 기능을 충분히 대신할 수가 있게 된다.
OmniGraffle이 사이트의 기본 틀을 잡는 과정에서 특히 빛을 발하는 기능들 중에는, stencil이라고 불리는 여러 도표들에서 사용될 수 있는 다양한 모양의 기호 형판들의 모음집이라 할 수 있는데, 기본적으로 제공되는 것들 이외에 사용자들이 stencil을 직접 제작해서 올려놓은 사이트도 있다. 물론, 이 곳의 User Interface 항목에는 사이트의 wireframe들에 사용될 수 있는 다양한 기호들의 stencil들을 내려받을 수가 있어서, 이것들을 불러와서 좀 더 사실적이고 유연한 사이트의 틀을 표현할 수가 있다.

앞의 stencil들을 모아놓은 Graffletopia라는 사이트는 Summer of Rails의 여러 프로젝트들 중의 하나로서, 어쩐지 군더더기 하나 없이 산뜻하게 만들어져 있는 모습이다. 8)

새로 덧붙임: 틀을 잡을 때 특히 강조되는 것으로, 중요한 것에 치중하라는 얘기가 있다.
이 말은, 웹 디자인 과정에서 UI(User Interface) 요소들의 중요도에 따라 접근하면서 디자인을 확장하라는 얘기이다. 먼저, 웹 페이지에서 꼭 필요한 요소들은 무엇인지부터 시작해서, 그 중요도에 따라 적용이 가능한 여러 표현 방법들을 고민하는 것이다.
이러한 과정은 웹 사이트의 틀(wireframe)을 잡는 과정과 함께 동반적으로 이루어지는 작업이며, 틀을 잡는 작업의 보조적 장치로서 Page Description Diagrams이 필요해지는 이유이다.

이것은 곁가지들만 치다 몸통을 베어내는 실수를 막으려는 또 하나의 안전장치로 볼 수도 있다.

오래전부터 Safari를 기본 RSS 구독기로 사용하고 있는 사람으로서, SafariDockStatus는 개인적으로 아주 유용하게 사용하고 있는 도구이다. 기능이라면 아주 단순해서, 주기적으로 Safari의 책갈피 막대에 등록되어 있는 RSS/Atom feed들을 확인해서 아직 읽지 않은 새로운 feed들의 갯수를 Dock 위에 떠 있있는 Safari의 아이콘에 표시해준다.

그런데, 어떤 이유인지 버전 1.0.3을 마지막으로 개발이 중지었되고 개발자의 사이트마저 사라지면서 공식적으로 내려받을 수가 없게 되었다.

다행스럽게도, SafariDockStatus를 내려받을 수 있는 여러 미러 사이트들은 아직 건재하다.

현재는 Safari 2.0.4(419.3)에서도 잘 작동하며, 차기 Safari 버전에서도 계속 사용하려면, SIMBL의 Plugins 폴더 속에 위치하는 SafariDockStatus.bundle의 패키지 내용들 중에서, Info.plist 파일의 MaxBundleVersion 키의 값을 버전에 맞게 수정해서 정상 작동여부를 확인해야 한다. 앞으로 Mail에서처럼 기본적으로 추가되었으면 하는 기능이다.