공개된 시안대로라면 환경설정과 북마크가 검색상자 옆으로 배치되고, 탭 영역 좌측에 페이지와 관련된 메뉴가 추가되는 것 같아 보입니다.
Firefox 3.7 Theme / Windows 7
Firefox 3.7 Theme / Windows Vista
Firefox 3.7 Theme / Windows XP
2009년 7월 22일 수요일
Firefox 3.7의 새로운 테마(Mockup)
모질라 위키에 파이어폭스 3.7에 적용될 새로운 테마 시안이 공개되었네요.
공개된 시안대로라면 환경설정과 북마크가 검색상자 옆으로 배치되고, 탭 영역 좌측에 페이지와 관련된 메뉴가 추가되는 것 같아 보입니다.
공개된 시안대로라면 환경설정과 북마크가 검색상자 옆으로 배치되고, 탭 영역 좌측에 페이지와 관련된 메뉴가 추가되는 것 같아 보입니다.
2009년 7월 14일 화요일
자바스크립트 없이 메뉴 만들기
CSS Play에는 여러 가지 메뉴의 예제를 보여주고 있다. 각각의 예제는 대부분 IE6를 비롯한 주요 브라우저와 호환된다. 이번에 'Professional dropline / dropdown / flyout version 2 - hybrid menu'라는 예제를 추가했는데 1. IE6에서도 작동된다는 점, 2. 자바스크립트를 사용하고 있지 않다는 점. 때문에 구현 방식에 호기심을 가지고 소스를 분석해 봤다. 나는 어리석게도 아직까지 자바스크립트를 사용하지 않고서는 IE6에서 이와 같은 메뉴를 구현할 수 없다고 생각했다. 한번 들인 습관(자바스크립트를 이용해서 브라우저 호환성을 맞추는) 때문에 좀 더 나은 방법을 찾아볼 생각까지를 하지 못했던 거다. (이런 멍청한!)
CSS Play의 이 복합 메뉴는 일반적으로 사용되는 2단계 수평 메뉴에 수직으로 떨어지는 드롭다운 메뉴를 붙이고, 다시 4단계 깊이의 메뉴를 플라잉 메뉴로 설계했다. 왠만한 복잡도의 메뉴를 처리할 수 있을만큼인데 이를 CSS만으로 처리했다는 것이 더 멋지다.
CSS Play는 자신들의 예제를 파일로 제공해 주지는 않는다. 개인 웹사이트 사용자들에게는 스타일시트 내에 CSS Play 링크를 유지해 줌으로써 사용을 허락하지만, 상업적인 경우 비용을 지불할 것을 요구하고 있다. HTML과 CSS만으로 만들어진 소스를 돈 내고 써야 하는게 맞는건지는 잘 모르겠지만 그렇게 적혀 있다. 어쨌든 CSS Play에서 다운로드를 제공해주지 않았기 때문에 그저 원본 소스를 열어놓고, 디자인 부분을 제외하고 그대로 재현해 봤다. ID 및 Class 명까지도 새로 작성했고, 스타일시트 역시 원리만 차용하고 내가 직접 다 다시 작성했다. 물론 원본을 따라가다 보니 방식은 동일하다. CSS Play도 다운로드만 제공하지 않을 뿐이지 소스 보기 까지 막아둔 것은 아니기 때문에 문제가 없을 것이라고 생각한다. (이미 출처도 밝혔고!)
아래 소스 부터는 제가 직접 코딩한 내용입니다. 원본가 다를 수 있으니 좀 더 정확히 파악해 보시고 싶으신 분들은 꼭 원본을 확인해 보세요.
기본적인 마크업은 다음과 같다:
골치 아팠던 스타일시트는 아래와 같다:
사실 IE6를 포기한다면 CSS만을 이용해서 위와 같은 메뉴를 만드는 것은 크게 어렵지 않다. 나 역시 거기까진 원본 소스를 보지 않고도 비슷하게 맞출 수 있었다. 역시 난관은 IE6의 호환성 부분이었는데 열쇠는 HTML에 있다. HTML 소스를 확인해 보면 조건부 주석(Conditional Comments)을 이용해서 IE6과 IE7을 처리하는 부분이 있다.
<li>요소의 첫번째 자식 요소인 <a> 요소에 대해서 주건부 주석(IE7 일 때 </a>요소를 적용)이 한 번 쓰이고, 두번째 자식 요소인 <ul>요소를 IE6 이하일 때 <table> 요소로 감싸도록 하고 있다. 즉, 첫번째 자식 요소인 <a>요소의 링크 범위를 설정하기 위한 것과 두번째 자식 요소인 <ul>요소를 IE6에서도 표현하기 위해서 <table>요소를 적용한 것이다.
* 아내 내용부터 약간 보완 수정되었습니다.
하지만 IE6에서 표가 아닌 경우에 <table> 요소를 적용한 방법이 과연 정직한 것인지에 대한 고민을 해 봐야할 것 같다. 표가 아닌 경우에 <table> 요소를 적용함으로써 의미 있는 마크업으로써의 지향을 포기하게 되고, 다시 블록요소인 <ul>요소를 인라인 요소 <a>로 감싸고 있는 형국은 웹표준을 바라던 우리들 가슴을 먹먹하게 만드는 부분이 아닐 수 없다. 또, CSS만으로 처리를 하다 보니 감추어진 하위 메뉴들에 대한 키보드 접근성 문제가 발생(정찬명님께서 지적해 주셨습니다. 감사합니다.)하고 있는 것도 문제가 될 수 있다.
개인적으로는 조건부 주석도 사용하지 않고, 그래서 IE6에서라도 <table>요소를 사용하지 않고, 자바스크립트도 지원하지 않은채 사이트에 적용하는 방법도 최선책은 아니지만 차선책으로 결코 나쁘진 않다고 본다. 즉, IE6사용자들에게는 주메뉴(1단계 메뉴)만 제공하고, IE7이상의 사용자들에게는 모든 기능(4단계 깊이까지 모두 들어가지는 복합 메뉴)을 다 제공하는 것이다. 나로써는 이런 방법도 최소한의 접근성을 보장해 주는 것이라고 생각(주메뉴에서 하위메뉴가 출력되지 않는다고 해서 무조건 접근성이 없다고 보진 않는다. 단, 최종 컨텐츠까지 이동하는데 필요한 네비게이션-메뉴-는 충분히 제공되어야 한다.)하기 때문이다. 반대로 IE6 사용자들이 조금 더 편하게 사이트를 운용하기 위해 스스로 브라우저를 업그래이드 시킬 수 있도록 유도하는 기능까지도 가져볼 수 있지 않을까 싶다.
마지막에 사설이 길었는데 결론을 붙이자면 CSS Play의 이 복합 메뉴 코드는 꽤 인상적이며, 그동안 나 처럼 자바스크립트 없이 절대 IE6까지 호환되는 복합 메뉴를 만들 수 없어!라고 생각했던 사람들이 있다면 좋은 예제 코드가 될 것이라고 생각한다. 하지만 여러분들의 의견을 듣고, 좀 더 생각을 정리한 후에 내린 결론은CSS Play의 원 소스는 '학습용' 이상의 가치를 갖기는 어렵다이다. 위에서 지적된 문제들이 그 이유가 될 것이다. 그렇지만 이 소스를 아주 쓰지 못할 것은 아닌것 같다. 자바스크립트를 적당히 적용할 수 있다면 키보드 접근성 문제를 해결할 수도 있다.
2단 수평 메뉴와 드롭다운 메뉴, 플라잉 메뉴까지 총 4단계 깊이의 복합 메뉴를 구현했다
CSS Play의 이 복합 메뉴는 일반적으로 사용되는 2단계 수평 메뉴에 수직으로 떨어지는 드롭다운 메뉴를 붙이고, 다시 4단계 깊이의 메뉴를 플라잉 메뉴로 설계했다. 왠만한 복잡도의 메뉴를 처리할 수 있을만큼인데 이를 CSS만으로 처리했다는 것이 더 멋지다.
CSS Play는 자신들의 예제를 파일로 제공해 주지는 않는다. 개인 웹사이트 사용자들에게는 스타일시트 내에 CSS Play 링크를 유지해 줌으로써 사용을 허락하지만, 상업적인 경우 비용을 지불할 것을 요구하고 있다. HTML과 CSS만으로 만들어진 소스를 돈 내고 써야 하는게 맞는건지는 잘 모르겠지만 그렇게 적혀 있다. 어쨌든 CSS Play에서 다운로드를 제공해주지 않았기 때문에 그저 원본 소스를 열어놓고, 디자인 부분을 제외하고 그대로 재현해 봤다. ID 및 Class 명까지도 새로 작성했고, 스타일시트 역시 원리만 차용하고 내가 직접 다 다시 작성했다. 물론 원본을 따라가다 보니 방식은 동일하다. CSS Play도 다운로드만 제공하지 않을 뿐이지 소스 보기 까지 막아둔 것은 아니기 때문에 문제가 없을 것이라고 생각한다. (이미 출처도 밝혔고!)
아래 소스 부터는 제가 직접 코딩한 내용입니다. 원본가 다를 수 있으니 좀 더 정확히 파악해 보시고 싶으신 분들은 꼭 원본을 확인해 보세요.
기본적인 마크업은 다음과 같다:
골치 아팠던 스타일시트는 아래와 같다:
디자인이 적용되지 않은 형태이긴 하지만 거의 그대로 재현되었다.
사실 IE6를 포기한다면 CSS만을 이용해서 위와 같은 메뉴를 만드는 것은 크게 어렵지 않다. 나 역시 거기까진 원본 소스를 보지 않고도 비슷하게 맞출 수 있었다. 역시 난관은 IE6의 호환성 부분이었는데 열쇠는 HTML에 있다. HTML 소스를 확인해 보면 조건부 주석(Conditional Comments)을 이용해서 IE6과 IE7을 처리하는 부분이 있다.
<li>요소의 첫번째 자식 요소인 <a> 요소에 대해서 주건부 주석(IE7 일 때 </a>요소를 적용)이 한 번 쓰이고, 두번째 자식 요소인 <ul>요소를 IE6 이하일 때 <table> 요소로 감싸도록 하고 있다. 즉, 첫번째 자식 요소인 <a>요소의 링크 범위를 설정하기 위한 것과 두번째 자식 요소인 <ul>요소를 IE6에서도 표현하기 위해서 <table>요소를 적용한 것이다.
* 아내 내용부터 약간 보완 수정되었습니다.
하지만 IE6에서 표가 아닌 경우에 <table> 요소를 적용한 방법이 과연 정직한 것인지에 대한 고민을 해 봐야할 것 같다. 표가 아닌 경우에 <table> 요소를 적용함으로써 의미 있는 마크업으로써의 지향을 포기하게 되고, 다시 블록요소인 <ul>요소를 인라인 요소 <a>로 감싸고 있는 형국은 웹표준을 바라던 우리들 가슴을 먹먹하게 만드는 부분이 아닐 수 없다. 또, CSS만으로 처리를 하다 보니 감추어진 하위 메뉴들에 대한 키보드 접근성 문제가 발생(정찬명님께서 지적해 주셨습니다. 감사합니다.)하고 있는 것도 문제가 될 수 있다.
개인적으로는 조건부 주석도 사용하지 않고, 그래서 IE6에서라도 <table>요소를 사용하지 않고, 자바스크립트도 지원하지 않은채 사이트에 적용하는 방법도 최선책은 아니지만 차선책으로 결코 나쁘진 않다고 본다. 즉, IE6사용자들에게는 주메뉴(1단계 메뉴)만 제공하고, IE7이상의 사용자들에게는 모든 기능(4단계 깊이까지 모두 들어가지는 복합 메뉴)을 다 제공하는 것이다. 나로써는 이런 방법도 최소한의 접근성을 보장해 주는 것이라고 생각(주메뉴에서 하위메뉴가 출력되지 않는다고 해서 무조건 접근성이 없다고 보진 않는다. 단, 최종 컨텐츠까지 이동하는데 필요한 네비게이션-메뉴-는 충분히 제공되어야 한다.)하기 때문이다. 반대로 IE6 사용자들이 조금 더 편하게 사이트를 운용하기 위해 스스로 브라우저를 업그래이드 시킬 수 있도록 유도하는 기능까지도 가져볼 수 있지 않을까 싶다.
마지막에 사설이 길었는데 결론을 붙이자면 CSS Play의 이 복합 메뉴 코드는 꽤 인상적이며, 그동안 나 처럼 자바스크립트 없이 절대 IE6까지 호환되는 복합 메뉴를 만들 수 없어!라고 생각했던 사람들이 있다면 좋은 예제 코드가 될 것이라고 생각한다. 하지만 여러분들의 의견을 듣고, 좀 더 생각을 정리한 후에 내린 결론은CSS Play의 원 소스는 '학습용' 이상의 가치를 갖기는 어렵다이다. 위에서 지적된 문제들이 그 이유가 될 것이다. 그렇지만 이 소스를 아주 쓰지 못할 것은 아닌것 같다. 자바스크립트를 적당히 적용할 수 있다면 키보드 접근성 문제를 해결할 수도 있다.
HTML, CSS, JavaScript 등 다양한 Quick Reference를 모아둔 곳!
종종 HTML, CSS, JavaScript과 관련된 Quick Reference를 소개하곤 합니다. 하지만 보통은 한 번 보고 잊어버리거나 다시 생각나서 찾아보려고 해도 잘 찾아지지 않는 경우가 많죠. 그런 분들을 위해서 준비하셨는지는 모르겠지만 미남이의 웹터를 운영하고 계신 운영자님께서는 '참고 종이장들'이라는 서비스를 통해서 온 갖 레퍼런스 문서들을 수집, 정리하여 공개하고 계십니다.
다양한 언어와 제품별로 디렉토리를 구분하고 공개된 대다수의 레퍼런스들을 정리해 두셨는데요 정말 그 수고에 감사의 말씀을 전하고 싶습니다. 좀 더 많은 개발자들에게 공유가 된다면 도움이 될 듯 하여 소개해 드립니다.
미남이의 웹터
다양한 레퍼런스 문서들
다양한 언어와 제품별로 디렉토리를 구분하고 공개된 대다수의 레퍼런스들을 정리해 두셨는데요 정말 그 수고에 감사의 말씀을 전하고 싶습니다. 좀 더 많은 개발자들에게 공유가 된다면 도움이 될 듯 하여 소개해 드립니다.
2009년 7월 13일 월요일
나를 즐겁게 하는 에디터! Espresso!!
바탕화면이 투명하게 비치는 Espresso
Espresso는 CODA만큼 미려한 UI를 제공하고 있습니다. 오히려 테마 기능 쪽에서는 조금 더 예쁘게 느껴지더군요. 특히 에디터 바닥을 투명하게 처리할 수 있어 살짝 비춰지는 바탕하면이 인상적입니다. 전 개인적으로 결혼식 사진을 바탕화면으로 두었는데 웹딩드레스를 입고 있는 아내의 모습을 실루엣처럼 볼 수 있어서 좋았습니다.(투명하지 않은 CODA보다도 느리지 않았습니다.)
Theme를 직접 수정할 수
Espresso는 CSS문법으로 테마를 정의할 수 있습니다.
Espresso는 위 그림과 같이 CSS 문법을 이용해서 테마를 정의할 수 있습니다. 배경 속성의 마지막 값으로 '0.8'을 지정함으로서 투명도를 조절할 수도 있었습니다.
또 한가지 Espresso만의 독특한 코딩 방법이 있는데요. HTML 마크업시 태그를 구성하는 꺽쇠를 생략할 수 있다는 점입니다.
태그의 꺽쇠 표시를 생략했다.
Control + ,(콤마) 키를 누르면 꺽쇠를 자동으로 생성하면서 태그를 완성해 준다.
위 그림과 같이 Espresso는 태그를 구성하는 꺽쇠를 생략한채로 마크업을 할 수 있습니다. 태그명과클래스명, 그리고 ID값을 위와 같이 이어 붙인 후 Control + , (콤마)키를 눌러주면 자동으로 꺽쇠와 닫는 태그를 생성하여 요소를 완성시켜 줍니다. 이 때 클래스는 몇 개든 이어서 붙일 수 있으며 ID와의 순서는 상관이 없습니다. 처음에는 조금 낯선 방법이었지만 조금씩 손에 익으면서 확실히 평균보다 빠른 마크업시간을 가질 수 있었습니다.
이 외에도 문자열 목록에 <LI> 태그를 자동으로 생성해주거나, <A>, <P> 태그 등을 자동 완성 시켜주는 단축키들이 제공되고 있어 HTML을 마크업하는데 편리함을 주고 있습니다.
CODA나 Aptana에서 지원하는 버전관리시스템(SVN 등)은 지원하지 않고 있고, 다소 불편한 화면 분할(Split) 기능의 미지원은 아쉬운 부분으로 느껴지지만 반대로 CODA에서는 코드 접기 기능(Code Fold/Unfold)을 지원하지 않고 있어서 서로 아쉽기는 마찬가지였던것 같습니다.
개인적으로는 에디터 자체는 가볍고 빠른 것이 좋습니다. 거기에 예쁘기까지 하면 나쁠것이 없을 것 같았습니다. 딱 필요한 기능들만 갖추고 예쁘기까지 하면 지루하게 느껴질지 모를 이 작업이 조금은 유쾌해지지 않을까 하여 Espresso라는 에디터를 한 번 소개해 드렸습니다.
2009년 7월 12일 일요일
사이트맵을 쉽게 만들어 주는 SlickMap
ASTUTEO에서 의미 있게 작성된 사이트맵(HTML)을 멋진 디자인으로 만들어 주는 간단한 CSS를 제공했습니다.
SlickMap CSS를 적용하면 위처럼 마크업한 HTML이 아래와 같이 멋진 화면으로 만들어진다.
SlickMap CSS를 이용하면 손쉽게 미려한 디자인의 사이트맵 화면을 만들 수 있습니다. 물론 실무에서는 위와 다른 디자인을 위해 새로운 CSS를 작성해야만 할지도 모르겠지만 사이트맵 스타일시트 작성에 어려움을 느끼는 분들에게는 괜찮은 레퍼런스가 되지 않을까 하여 소개해 봅니다.
사이트맵을 의미 있게 작성한HTML
SlickMap CSS를 적용하면 위처럼 마크업한 HTML이 아래와 같이 멋진 화면으로 만들어진다.
SlickMap CSS가 적용된 화면
SlickMap CSS를 이용하면 손쉽게 미려한 디자인의 사이트맵 화면을 만들 수 있습니다. 물론 실무에서는 위와 다른 디자인을 위해 새로운 CSS를 작성해야만 할지도 모르겠지만 사이트맵 스타일시트 작성에 어려움을 느끼는 분들에게는 괜찮은 레퍼런스가 되지 않을까 하여 소개해 봅니다.
HTML5 Validation Service
아직 최종 공고안으로 발표되지는 않았지만 HTML5를 준수하며 만들어진 사이트들이 하나 둘씩 소개되고 있다. 그런데 아직 완벽해지지도 않은 HTML5를 어떻게 적용하고, 검증할까?
validator.nu에서는 HTML5를 위한 유효성 검증 서비스를 제공하고 있어 소개한다. http://html5.validator.nu/ 에 접속하여 HTML5를 준수하여 제작된 웹사이트의 주소를 입력하면 다음과 같이 결과 화면을 볼 수 있다.
이 유효성 검증 서비스에 대한 자세한 설명은 여기에서 볼 수 있다.
HTML5는 아직 완벽하지 않다. 현재의 스펙이 어떻게 바뀌게 될 지 알 수 없다.(그렇게 되지 않길 바라지만) 하지만 마음 급한 개발자들은 벌써부터 HTML5로 자신의 블로그와 웹사이트를 바꾸고 있다. HTML5를 이용해서 멋진 블로그나 웹사이트를 만든 사람이라면 이 유효성 검증 서비스의 도움도 받아 볼 수 있을 것 같다. 하지만 아쉽게도 통과 뱃지를 제공하지는 않는다.
validator.nu에서는 HTML5를 위한 유효성 검증 서비스를 제공하고 있어 소개한다. http://html5.validator.nu/ 에 접속하여 HTML5를 준수하여 제작된 웹사이트의 주소를 입력하면 다음과 같이 결과 화면을 볼 수 있다.
Firejune.com은 유효성 검증을 통과했다.
이 유효성 검증 서비스에 대한 자세한 설명은 여기에서 볼 수 있다.
HTML5는 아직 완벽하지 않다. 현재의 스펙이 어떻게 바뀌게 될 지 알 수 없다.(그렇게 되지 않길 바라지만) 하지만 마음 급한 개발자들은 벌써부터 HTML5로 자신의 블로그와 웹사이트를 바꾸고 있다. HTML5를 이용해서 멋진 블로그나 웹사이트를 만든 사람이라면 이 유효성 검증 서비스의 도움도 받아 볼 수 있을 것 같다. 하지만 아쉽게도 통과 뱃지를 제공하지는 않는다.
2009년 7월 10일 금요일
내가 좋아하는 네이트온, 못 내 아쉬운 뉴스온
네이트온은 내가 가장 많이 이용하는 메신져 서비스이고, 아마도 한국인들이 가장 많이 사용하는 메신져일 것이라고 생각한다. 윈도우나 오피스를 비롯해서 주요 소프트웨어들이 MS등 외국의 주요 소프트웨어 업체에 독점되어 있는 상황이고, 메신져 역시 ICQ나 MSN 메신저와 같은 외산 제품들이 대부분이었던 시절도 있었다. 하지만 국내에서도 버디버디와 네이트온과 같은 국산 제품들이 나타나기 시작했고, 지금은 많은 사람들이 네이트온을 이용하면서 나름 외산을 물리치는(?) 효과를 거두고 있다. 네이트온의 성공 비결에는 한국인이 좋아할 만한 디자인과 편의성이 있겠는데 편의성 중 단연 미니홈피 연동과 무료 문자 보내기는 으뜸이었다. 그리고 또 하나 내가 네이트온을 좋아하게 된 것은 일부러 뉴스를 찾아 보려들지 않는 게으름을 도와주는 '뉴스온' 때문이었다. 시사와 스포츠 등 지난 하룻동안의 주요 뉴스를 작은 팝업창 안에 채워서 보여주는 노력이 처음에는 불편했지만 차차 고맙게 느껴지기까지 했던 것.
그런데 이 뉴스온 서비스는 안탑깝게도 IE에만 최적화 되어 있어서 다른 브라우저를 기본으로 사용하는 경우에는 일그러진 뉴스온을 보게 된다.
네이트온을 제공하는 NATE.COM은 웹표준화 작업을 거치면서 브라우저 호환성은 상당부분 맞춰진 상황인데 메신져 서비스중 하나인 뉴스온은 아직도 저렇게 나타나고 있다는 사실이 못 내 섭섭하다. 내부적으로는 계획이 되어 있을텐데 하루 빨리 저 작은 창 안에 정보들도 깔끔하게 나올 수 있도록 노력해 주셨으면 좋겠다. 아 그리고 네이트온은 맥에서도 사용이 가능한데 뉴스온은 제공되지 않는다. 단지 IE를 띄우고, 뉴스온 사이트를 보여주는 것일 뿐인데 그게 어려운가?
그리고 나야 뉴스온을 지하철 앞에서 나눠주는 무가지 마냥 편하게 받아 보고(?) 있기는 하지만 무조건 강제로 떠 버리는 뉴스온이 주는 것 없이 얄미울 수 있다. 나도 지하철 무가지 읽기 싫은 날은 안 집어 가니까 뉴스온도 가끔은 안 떴으면 하고 바랄때도 있으니까. 당신의 기본 브라우저가 IE라면 아래 화면 우측 상단에 [설정] 버튼을 눌러서 '자동으로 보지 않기'를 선택해 주면 된다. 반대로 다시 보고 싶을 땐 네이트온 좌측의 서비스탭에서 '뉴스온'을 찾아서 추가해 준 후 마찬가지로 아래 화면에서 설정을 선택하고 '자동으로 보지 않기'가 아닌 항목을 선택해 주면 된다.
그런데! 이 설정조차 IE가 아니면 작동하지 않는다. 비IE(Firefox, Safari, Opera, Chrome 확인)에서는 설정 화면이 나타나질 않더라.
네이트온은 윈도우나 맥과 같은 OS에서 실행되는 프로그램이지만 네이트온이 제공하는 뉴스온은 IE와 같은 웹브라우저 안에서 제공되는 웹 서비스다. 그렇다면 최소한 콘텐츠를 비IE에서도 제대로 보여줄 수 있도록 해야 하지는 않을까? NATE.COM의 웹표준화 작업도 상당히 진행되었고, 뉴스온의 이런 비IE 미지원 문제도 꽤 되었음에도 여전히 개선되고 있질 않아서 그냥 저냥 투덜거려 보았다.
뭔가 IE가 아니면 안 될 만한 아주 중요한 이유라도 있는 걸까? 설마 공인인증서가 있어야 뉴스를 보게 하려고 하는 것은 아니겠지!?
그런데 이 뉴스온 서비스는 안탑깝게도 IE에만 최적화 되어 있어서 다른 브라우저를 기본으로 사용하는 경우에는 일그러진 뉴스온을 보게 된다.
기본 브라우저를 윈도우 기본 브라우저로 바꿀 수 있다.
IE를 기본 브라우저로 사용한 경우 깨끗한 뉴스온을 마주할 수 있다.
기본 브라우저가 비IE인 경우에는 이렇게 깨져 보인다.
네이트온을 제공하는 NATE.COM은 웹표준화 작업을 거치면서 브라우저 호환성은 상당부분 맞춰진 상황인데 메신져 서비스중 하나인 뉴스온은 아직도 저렇게 나타나고 있다는 사실이 못 내 섭섭하다. 내부적으로는 계획이 되어 있을텐데 하루 빨리 저 작은 창 안에 정보들도 깔끔하게 나올 수 있도록 노력해 주셨으면 좋겠다. 아 그리고 네이트온은 맥에서도 사용이 가능한데 뉴스온은 제공되지 않는다. 단지 IE를 띄우고, 뉴스온 사이트를 보여주는 것일 뿐인데 그게 어려운가?
그리고 나야 뉴스온을 지하철 앞에서 나눠주는 무가지 마냥 편하게 받아 보고(?) 있기는 하지만 무조건 강제로 떠 버리는 뉴스온이 주는 것 없이 얄미울 수 있다. 나도 지하철 무가지 읽기 싫은 날은 안 집어 가니까 뉴스온도 가끔은 안 떴으면 하고 바랄때도 있으니까. 당신의 기본 브라우저가 IE라면 아래 화면 우측 상단에 [설정] 버튼을 눌러서 '자동으로 보지 않기'를 선택해 주면 된다. 반대로 다시 보고 싶을 땐 네이트온 좌측의 서비스탭에서 '뉴스온'을 찾아서 추가해 준 후 마찬가지로 아래 화면에서 설정을 선택하고 '자동으로 보지 않기'가 아닌 항목을 선택해 주면 된다.
그런데! 이 설정조차 IE가 아니면 작동하지 않는다. 비IE(Firefox, Safari, Opera, Chrome 확인)에서는 설정 화면이 나타나질 않더라.
뭔가 IE가 아니면 안 될 만한 아주 중요한 이유라도 있는 걸까? 설마 공인인증서가 있어야 뉴스를 보게 하려고 하는 것은 아니겠지!?
2009년 7월 9일 목요일
나의 마크업 시간은 얼마나 될까?
요즘 회사일이 많고, 바쁘다는 핑계로 블로그를 소홀히 하고 있었는데 글까지 너무 뜸하면 제가 더 게을러질 것 같아서 간단한 팁 하나를 소개해 드리려고 합니다.
커뮤니티의 게시판을 살펴보다 보면 종종 웹표준 작업을 하는데 얼마만큼의 시간이 걸리는지 물어오는 질문을 보곤 합니다. 대게 2,3년차 정도 이상의 경력이 쌓이면 자신의 업무 처리 시간을 가늠하는 것이 어렵지는 않습니다. 하지만 어디까지나 평균적인 시간이고, 프로젝트에 따라서 차이가 나는 경우가 많죠.
저 역시 일반적인 홈페이지에서부터 기업용 웹어플리케이션까지 여러가지 형태의 웹사이트를 구축하고 있고, 매번 예측과 다른 작업 시간 때문에 일정 관리에 어려움을 느끼곤 합니다. (참고로 일정을 조율할 때 실제로 걸리는 작업의 1.5배의 시간을 요구하는 것을 잊지 마세요! 사이트 오픈이니 개발 일정이니 해서 자신의 업무 시간을 지나치게 타이트하게 잡는 것은 두 번 세 번 작업을 다시 하게 되는 결정적 원인이 되곤 합니다!) 이런 경우에 조금 더 정확한 자신의 업무 처리 시간, 즉 마크업을 하는데 소요되는 시간과 CSS, JavaScript를 작성하는데 걸리는 시간이 어느 정도인지를 보다 정확하게 확인해볼 수 있는 방법이 있습니다.
여러가지 소프트웨어나 웹 서비스가 있겠지만 저는 몇 가지 찾아본 후에 Klok를 사용합니다. Klok는 Adobe AIR 어플리케이션으로 프로젝트 관리를 도와주는 툴입니다. 새로운 프로젝트를 등록하고 하위 프로젝트를 작성한 후 시간을 기록하기 시작하면 위와 같은 멋진 그래프(보고서)를 만들 수 있습니다. 처음에는 다소 귀찮긴 하지만 몇 번 잊어버리거나 제대로 기록하지 않더라도 보름에서 한달 정도 한 개의 프로젝트를 진행하는 동안 관련 업무를 Klok를 통해서 기록해 본다면 자신의 HTML 마크업과 CSS, JavaScript 작성에 드는 시간과 비중을 쉽게 파악할 수 있게 됩니다.
저의 경우를 예로 들자면 CSS와 JavaScript를 작성하는데 가장 많은 비중을 차지한 것을 볼 수 있습니다. 특히 JavaScript 구현에 있어서 처음 일정을 정했던 것에 비해서 과중하게 시간을 할애한 경우였습니다. 다음번 프로젝트에서는 이 부분에 대한 시간을 조금 더 배정하도록 해야 겠고, 보다 빠르게 개발할 수 있는 새로운 방법도 고민해 봐야할 것 같습니다.
Klok은 한글 입력이 되지 않는 문제가 있긴 하지만 실제로 사용해보면 저처럼 UI개발 업무용으로 사용한다면 문장으로 기록을 남기는 일은 많지 않습니다. 사용법도 어렵지 않기 때문에 자신의 업무 처리 능력을 객관적으로 근거를 남기고 정리해보고 싶다면 한번 시도해볼만하지 않을까 해서 이렇게 소개해 드렸습니다.
추신/ 솔직히 개별 단위의 작업을 시작하거나 끝 낼 때마다 Klok의 시작과 정지 버튼을 누르는 일은 여간 귀찮은 일이 아닐 수 없습니다. 그보다 차라리 하루 일과를 마친 시점에 정확하진 않더라도 대략적인 타임라인을 기록하는 것이 보다 편하고 좋습니다.
커뮤니티의 게시판을 살펴보다 보면 종종 웹표준 작업을 하는데 얼마만큼의 시간이 걸리는지 물어오는 질문을 보곤 합니다. 대게 2,3년차 정도 이상의 경력이 쌓이면 자신의 업무 처리 시간을 가늠하는 것이 어렵지는 않습니다. 하지만 어디까지나 평균적인 시간이고, 프로젝트에 따라서 차이가 나는 경우가 많죠.
저 역시 일반적인 홈페이지에서부터 기업용 웹어플리케이션까지 여러가지 형태의 웹사이트를 구축하고 있고, 매번 예측과 다른 작업 시간 때문에 일정 관리에 어려움을 느끼곤 합니다. (참고로 일정을 조율할 때 실제로 걸리는 작업의 1.5배의 시간을 요구하는 것을 잊지 마세요! 사이트 오픈이니 개발 일정이니 해서 자신의 업무 시간을 지나치게 타이트하게 잡는 것은 두 번 세 번 작업을 다시 하게 되는 결정적 원인이 되곤 합니다!) 이런 경우에 조금 더 정확한 자신의 업무 처리 시간, 즉 마크업을 하는데 소요되는 시간과 CSS, JavaScript를 작성하는데 걸리는 시간이 어느 정도인지를 보다 정확하게 확인해볼 수 있는 방법이 있습니다.
프로젝트 일정관리 툴 Klok
여러가지 소프트웨어나 웹 서비스가 있겠지만 저는 몇 가지 찾아본 후에 Klok를 사용합니다. Klok는 Adobe AIR 어플리케이션으로 프로젝트 관리를 도와주는 툴입니다. 새로운 프로젝트를 등록하고 하위 프로젝트를 작성한 후 시간을 기록하기 시작하면 위와 같은 멋진 그래프(보고서)를 만들 수 있습니다. 처음에는 다소 귀찮긴 하지만 몇 번 잊어버리거나 제대로 기록하지 않더라도 보름에서 한달 정도 한 개의 프로젝트를 진행하는 동안 관련 업무를 Klok를 통해서 기록해 본다면 자신의 HTML 마크업과 CSS, JavaScript 작성에 드는 시간과 비중을 쉽게 파악할 수 있게 됩니다.
저의 경우를 예로 들자면 CSS와 JavaScript를 작성하는데 가장 많은 비중을 차지한 것을 볼 수 있습니다. 특히 JavaScript 구현에 있어서 처음 일정을 정했던 것에 비해서 과중하게 시간을 할애한 경우였습니다. 다음번 프로젝트에서는 이 부분에 대한 시간을 조금 더 배정하도록 해야 겠고, 보다 빠르게 개발할 수 있는 새로운 방법도 고민해 봐야할 것 같습니다.
Klok은 한글 입력이 되지 않는 문제가 있긴 하지만 실제로 사용해보면 저처럼 UI개발 업무용으로 사용한다면 문장으로 기록을 남기는 일은 많지 않습니다. 사용법도 어렵지 않기 때문에 자신의 업무 처리 능력을 객관적으로 근거를 남기고 정리해보고 싶다면 한번 시도해볼만하지 않을까 해서 이렇게 소개해 드렸습니다.
추신/ 솔직히 개별 단위의 작업을 시작하거나 끝 낼 때마다 Klok의 시작과 정지 버튼을 누르는 일은 여간 귀찮은 일이 아닐 수 없습니다. 그보다 차라리 하루 일과를 마친 시점에 정확하진 않더라도 대략적인 타임라인을 기록하는 것이 보다 편하고 좋습니다.
피드 구독하기:
글 (Atom)