프로젝트 관리와 간트 차트

간트 차트 예시: 영화 제작 프로젝트 (이미지 출처: Wikimedia Commons)

프로젝트 관리를 하면서 소위 간트 차트(Gantt Chart)가 한 번도 제대로 작동한 것을 본 적이 없다. 20세기 초에 건설 프로젝트처럼 터 닦고, 벽 세우고, 지붕 올리는 순서로 작업들이 종속적이고, 순서가 정해지고 별로 변하지 않는 경우는 어느 정도 소용이 있을지 모르겠다. 그러나 요즘 대부분의 사무직/지식 근로자들이 하는 업무가 어디 그런가?

간트 차트의 시각적인 문제점 중에 하나는, 한 행에 하나의 태스크와 하나의 막대(bar)만 넣을 수 있기 때문에, 사실 엄청나게 많은 공간(가로 시간축으로도, 세로 작업 목록축으로도!)  또는 종이가 필요하다는 것이다. 다시 말해, 간트 차트가 원래 의도대로 한 눈에 프로젝트 전체의 흐름을 파악할 수 있는 경우는 거의 없다는 것!

일반 사무직들은 아직도 파워포인트로 간트 차트 비슷한 모양을 만들어 보고하는 경우를 많이 봤다. 그런데, 간트 차트의 결정적인 약점(?)을 알아서 잘 보완(?)하는 것을 봤다. 즉, 대충 한 행의 타임라인에 여러 개의 후속 과제 또는 하위 과제 막대를 연속해서 표현해서 오히려 알아보기 쉽게 하는 것이다.

나는 간트 차트로 표현되는 전통적인 프로젝트 관리 방법이 잘 작동하지 않는 이유가 

1. 내가 일했던 회사들이 한국적인/동양적인 정서가 강해서, 명시적인 프로젝트 일정과 계획의 이면에 암묵적으로 "유연성"에 대한 동의가 있어서인지  [회사/조직 특성]
2. 아니면, 내가 일했던 업무가 소프트웨어 제작이나, 공학적 개발과 달리, 비교적 손에 잡히도록 구체화하기 힘든 소프트한(?) 업무여서 그런 것인지 매우 궁금하다. [업무 특성]

소위 크리티컬 패스(critical path), 또는 크리티컬 패스 방법론(critical path method)을 정교하게 적용해서 프로젝트 일정을 예측한다는 것도, 사실 프로젝트 초기에 디자인 단계에서 하는 대부분의 어림치나 추측(guessing)이 맞다는 가정 하에 작동하는 것이지만, 그것도 현실적으로 그런 경우는 거의 보지 못했다.

어디 현실에서 하나의 작업이 깔끔하게 끝나서 다시 뒤돌아볼 필요 없이 다음 작업이 시작되는 경우가 얼마나 있는가? 계속 반복하고, 검증하고, 돌아가고, 피드백 받고, 보완하고, 그것에 따라 다음 작업이 바뀌고, 건너뛰고, 목표가 바뀌고, 예측하지 못한 혁신도 일어나고, 돌발 사고도 생기기 마련인데... 과연 간트 차트가 그런 것들을 관리하기 위한 효과적인 도구일까?

간트 차트를 쉽게 생성해준다는 Wrike의 광고를 보고 문득 든 생각이었다.

Read more "프로젝트 관리와 간트 차트"

도메인을 잃어버렸다.

지금까지 10년 넘게 개인 홈페이지와 블로그에 사용해오던 gregshin.pe.kr 도메인이 만료되고, 잠시 재등록을 하지 않은 사이에 누군가 도메인을 가로채버렸다. gregshin.pe.kr 도메인을 검색해본 결과는 아래와 같다.

도메인이름 : gregshin.pe.kr
등록인 : 정한
책임자 : 정한
책임자 전자우편 : rmdrk@hanmail.net
등록일 : 2016. 12. 05.
최근 정보 변경일 : 2016. 12. 05.
사용 종료일 : 2017. 12. 05.
정보공개여부 : N
등록대행자 : 메가존(주)(http://HOSTING.KR)
DNSSEC : 미서명

괘씸하게도 내가 예전에 사용하던 무지개 모양의 파비콘을 유지한 채로 실제 사이트는 오픈하지도 않았다. 즉, 도메인 장사를 하려고 선점한 것이다. pe.kr은 개인용 국내 도메인으로 가격도 싸고 가장 인기 없는 도메인이다. 내 홈페이지와 블로그는 최근에 거의 활동이 없었지만, 과거에 축적된 데이터는 꽤 많기 때문에 외부에서 참조하여 들어오는 링크는 상당히 많다. 그래서 함부로 도메인을 포기하는 것은, 인터넷(웹)과 나 자신의 신뢰도를 떨어뜨리는 것이라 꺼려지는 일이다. 그렇다고 도메인 장사꾼에게 웃돈을 주고 도메인을 사오고 싶지도 않았다. 하는 수 없이 기존 도메인을 포기하고, 호스팅 업체에서 제공하는 sshin.cafe24.com을 당분간 유지하기로 했다. 울며 겨자 먹기로 새롭게 gregshin.kr 도메인을 새로 구입했다.

문제는 과거에 내가 스스로 내 홈페이지 내부에서, 또는 소셜 미디어(페이스북, 트위터, 구글플러스, 링크드인 등)에서 과거 도메인으로 참조를 하고 있는 경우가 너무 많고, 대부분 수정도 되지 않았다. 또, 다른 사이트에서 아직도 내 과거 홈페이지 도메인을 참조하고 있는 링크가 꽤 많은데 이것은 내가 직접 고칠 수가 없다. 작은 일이지만 잠깐 소흘히 한 결과의 댓가가 크다는 것을 알았다. 우선 내가 직접 고칠 수 있는 것(내부에서 링크를 하고 있는 것)들부터 하나하나 고쳐나가기로 했다. 우선 절대 참조로 되어 있는 링크는 되도록이면 상대 참조 링크로 바꾸고 있는데, 이미지, 파일과 특정 블로그 포스트를 가리키는 링크 등 생각보다 많아서 시간이 꽤 걸린다. 또 하나하나 수정하는 과정 중에 외부로 나가는 링크도 깨져 있는 것이 다수 있는 것을 발견했다.

사실 gregshin.pe.kr에다가 보안 서버 인증서를 설치하고 싶었는데 할 수 없이 gregshin.kr에 설치했다. https로 바꾸고 나니 할 일이 상당히 많았다. 워드프레스(WordPress)와 기존 엑스프레스엔진(XpressEngine)의 기본 URL을 수정하는 것은 물론이고, http로 들어왔을 때에 https로 리디렉션 하도록 .htaccess 파일을 수정해주는 것, 그리고 곳곳에 숨어있는 내부 링크, 이미지 등에 쓰인 과거 URL들을 바꿔주는 것 등등 끝이 없다. 검색 엔진들은 다른 사이트에서 참조하고 있는 링크들을 중요하게 여기기 때문에 sshin.cafe24.com과 gregshin.pe.kr이 아직도 먼저 노출된다. 그러다 보니 sshin.cafe24.com 도메인에는 인증서가 없어서, 인증서 없이 들어오도록 놔두어야 했다. 아무튼 gregshin.pe.kr의 현재 소유 기간이 만료되면 다시 옛날 주소로 고칠 생각인데, 그 때엔 또 얼마나 많은 작업을 해주어야 하는지…

Read more "도메인을 잃어버렸다."

굴림, 돋움 제거 작전

아직도 많은 곳에서 굴림, 돋움 글꼴이 쓰이고 있다. 윈도우즈 7에서는 사용자가 바꿀 수 없는 기본 UI의 일부로 남아 있고, 많은 웹 페이지들은 기본적인 산스세리프(sans-serif: 세리프가 없는 고딕 계열 글꼴)로 굴림(Gulim)이나 돋움(Dotum)을 아직 많이 쓰고 있다. 굴림은 윈도우즈 3.1 시절에 처음 나왔고, 윈도우즈 95에서 기본 글꼴로 쓰이기 시작했는데, 해상도가 낮은 화면에서 9포인트(pt)에 특별히 디자인된 비트맵 글꼴 이미지가 깔끔하다는 이유로 아직 널리 쓰인다.

문제는 높은 해상도의 화면이 점점 더 많이 보급되면서 낮은 해상도에서 “특별히” 디자인된 굴림이 보기 싫은 경우가 많아졌다는 것이다. 나는 14인치 Full HD (1920 * 1080) 노트북을 쓰고 있는데, 웹 사이트에서 본문에 굴림 또는 돋움이 사용된 경우, 비트맵 글꼴이 너무 얇게 디자인 되어 있어서 보기가 상당히 고약하다. 화면을 확대해서 보기도 하는데, 그래도 큰 크기에 렌더링된 굴림은 힌팅(hinting: 수학적인 방법으로 윤곽선 폰트의 모양을 보완하는 것)이 안 되어 있기 때문에 상당히 못생기고 지저분해 보인다.

과거 윈도우즈 시절엔 대안이 없어서 굴림을 여기 저기 쓰는 것이 어쩔 수 없는 일이었지만, 이제 윈도우즈 사용자에게도 대안은 많이 있다. 윈도우즈 XP에서부터 나온 마이크로소프트의 클리어타입(ClearType: 마이크로소프트 윈도우즈 고유한 방식의 힌팅 기술)이 적용된 “맑은 고딕”이 있고 그 밖에도 대안은 아주 많아졌다. 적어도 세리프(serif: 꺾임이 있는 명조 계열 글꼴)가 아닌 산스세리프 글꼴에서는. 윈도우즈를 제외한 다른 운영체제(맥 OS, iOS, 안드로이드, 크롬 OS, 리눅스 등)에서는 굴림이라는 레거시 폰트가 존재하지 않기 때문에 문제가 없다. 네이버에서 만든 나눔고딕, 애플 산돌 고딕 네오, 구글의 노토 산스, 심지어 윈도우즈 폰에서도 마이크로소프트 네오 고딕이 기본 글꼴로 사용되고, 웹 제작자가 설사 굴림을 썼다고 하더라도 굴림이 OS에 없기 때문에 브라우저에서 정한 기본 산스세리프가 대체 글꼴로 나와서 정말 보기 싫은(ugly) 상황은 연출되지 않는다. 오직 데스크톱 윈도우즈에서만 과거 시대의 유물, 굴림을 봐야 하는 불쾌한 상황이 생긴다.

가장 좋은 것은 웹 페이지를 만드는 사람들이 제발 굴림과 돋움을 기본 글꼴로 안 썼으면 좋겠다. 그래서 과거에는 윈도우즈 시스템에서 굴림/돋움을 아예 물리적으로 다른 글꼴로 바꿔버리거나, 레지스크리를 바꾸어서 굴림/돋움이라는 글꼴명이 다른 글꼴을 가리키도록 하는 방법도 시도해보았다. 상당히 만족스럽다. 그런데, 웹이 아닌 다른 응용 프로그램(application)에서 일부러 굴림을 쓴 경우를 구별하고 싶었다. 그래서 좀 덜 과격한 방법으로 웹에서만, 원하는 경우에, 굴림과 돋움을 안 보기로 했다.

주요 브라우저들이 예전에는 장애인들의 웹 접근성을 높이기 위한 한 방편으로 사용자 스타일 시트(user style sheet)를 불러와서 웹 페이지를 사용자가 원하는 방식으로 볼 수 있도록 편의를 제공했었다. 그런데 굳이 사용자가 스타일시트를 정의해서 불러 쓰는 경우가 많지 않았는지, 언제부턴가 인터넷 익스플로러를 제외하고는 그 기능이 다 사라졌다. 그래서 부득이하게 브라우저 확장 기능을 써서 굴림 글꼴을 내 눈 앞에서 사라지게 했다. 우선 굴림과 돋움이 웹 사이트에 출현하면 그것을 다른 글꼴로 대체하는 CSS (Cascading Style Sheet)를 만들었다. 굴림의 대체 글꼴은 굴림과 모양이 상당히 유사한 나눔고딕을, 돋움의 대체 글꼴은 그냥 윈도우즈에서 기본 제공하는 맑은 고딕을 사용하였다.

@font-face {font-family: Gulim; src: local("NanumGothic");} @font-face {font-family: Dotum; src: local("Malgun Gothic");} @font-face {font-family: 굴림; src: local("NanumGothic");} @font-face {font-family: 돋움; src: local("Malgun Gothic");}

cs

 

이제 브라우저별로 확장 기능을 사용해 위의 스타일을 모든 웹 사이트에 적용하였다. 사용자가 임의로 정의한 스타일시트나 스크립트를 사용하여 웹 페이지를 나만의 방식으로 보여주는 확장 기능은 상당히 많다. 대표적인 것이 초기에 센세이션을 일으켰던 파이어폭스에는 그리스몽키 (Greasemonkey)가 있고, 스타일만 바꿔주는 크롬용 스타일봇(Stylebot), 이와 유사한 스타일리시(Stylish)도 있다. 오페라, 크롬, 파이어폭스에 모두 있는 확장 기능으로는 커스텀 스타일 스크립트(Custom Style Script) (파이어폭스용, 오페라용, 크롬용)가 있다. 마이크로소프트 엣지 브라우저에도 확장 기능이 윈도우즈 스토어를 통해서 제공되는데 아직 사용자 정의 스타일을 쓸 수 있는 확장 기능은 없다. 인터넷 익스플로러는 자체적으로 사용자 정의 스타일을 불러다 쓸 수 있는데, 위와 같은 내용을 CSS로 만들어 로딩하면 이상하게 인터넷 익스플로러가 죽어버린다. 결국 오페라에는 커스텀 스타일 스크립트를, 크롬에는 스타일봇을, 파이어폭스에는 스타일리시를 이용해서 위와 같은 글꼴 대체 스타일을 적용했다. 보기 싫었던 굴림과 돋움을 웹 사이트에서 몰아내고 나니 웹 서핑이 한결 쾌적해졌다.

돋움 글꼴이 여러 곳에 쓰였다. zdnet.co.kr 기사

돋움 글꼴이 맑은 고딕으로 대체되었다.

Read more "굴림, 돋움 제거 작전"

웹호스팅 서비스를 바꾸고 있습니다.

오랫동안 블로그 관리를 하지 않았습니다. 관리를 거의 하지 않았기 때문에 웹호스팅 서비스가 마음에 들지 않은 부분들이 많이 있었지만 그냥 그럭저럭 버티고 있었습니다. 그동안은 아사달 이라는 업체에서 제공하는 호스팅 서비스를 쓰고 있었는데 몇 가지 문제가 있었습니다.

• 언제부턴가 구글 검색 로봇이 들어오질 못했습니다. 호스팅 업체에 물어보니 트래픽이 과하게 들어와서 기본적으로 검색을 막았다고 했습니다. 아니 검색을 못 하게 할 거면, 웹 페이지를 만들고 존재할 이유가 없어서 강하게 항의해서 겨우 검색 로봇이 다시 접근하긴 했는데 간간히 또 막히기도 했습니다. 물론 robots.txt에서는 검색봇을 차단하지 않았습니다.
• 제공되는 DB 용량이 너무 작았습니다. 기본 50MB였던 것을 추가 요금을 내고 100MB로 늘렸는데, 101MB가 되자마자 바로 서비스가 중단되었습니다. phpMyAdmin을 통해 필요없는 스팸 테이블을 지우고 용량을 80MB 정도로 돌리고 나서, 다시 서비스 재개 신청을 해서 서비스가 복구되었습니다. 그러나 DB 용량이 99% 정도 되었을 때 사전 경고도 없었었고, 앞으로도 100MB 이내를 유지하기가 쉽지 않겠다는 생각이 들었습니다.
• 소프트웨어 업데이트가 너무 느렸습니다. 물론 호스팅은 여러 사람이 쓰는 것이기 때문에 함부로 소프트웨어를 확 바꿀 수는 없다고 하지만, 이미 보안 결함이 발견되고 유지보수 기간이 지난 소프트웨어들이 계속 바뀌지 않아서 계속 머물러있고 싶지 않았습니다. 예를 들어 2016년 5월 31일 현재 최신 php 안정화 버전은 7.0.7인데 호스팅 서비스는 버전 5.2.12에 머물러 있었습니다. 문제는 이 버전은 이미 오래 전에 보안 결함 지원 기간이 지났다는 것입니다. 그리고 WordPress Mobile Pack과 같은 일부 워드프레스 플러그인은 구 버전 PHP에서 작동하지 않았습니다. 그래서 모바일에서 웹 페이지에 접근할 수 없었습니다. MySQL, phpMyAdmin, Apache와 같은 다른 소프트웨어도 너무 옛날 버전이었습니다.
• 관리 방법에도 문제가 있었습니다. 저는 보안 전문가가 아니지만, 그래도 웹 페이지를 관리하기 위해 암호화되지 않은 ftp나 위험한 telnet을 쓰고 싶지는 않았습니다.

물론 문제점만 있었던 것은 아닙니다. 주로 게시판을 통해 문제를 제기하면, 주말이든, 새벽 시간이든 번개같은 속도로, 비교적 성실하게 답변이 달렸습니다.

이런 호스팅 서비스의 문제 외에도, 제 개인의 관리 소흘로 인한 문제도 있었습니다. 예전 홈페이지 데이터를 유지 보관(archive)하는 용도로 Express Engine (XE)을 쓰고 있었는데, 이게 아주 오래 전에 제로보드(Zero Board)부터 시작해 몇 번 해킹 사고를 당했었습니다. 우여곡절로 겨우 복구는 했는데, 뭐가 꼬였는지 관리자 로그인도 잘 안 되고, 그냥 버리고 싶지만 버리지는 못하는 상태로 질질 끌어왔습니다.

그래서 몇 군데 국내외 호스팅 업체를 알아보고, 아예 가상적인 서버 관리 환경을 제공해주는 클라우드 서비스 업체도 알아보았습니다. 많이 시장 조사를 한 것은 아니고, 그냥 눈에 띄는 몇 군데만 알아봤습니다. 서비스 결정에 몇 가지를 고려했습니다.

• 그동안 취미로(?) 해왔던 기본적인 시스템 관리나 간단한 코딩, 퍼블리싱에서 오랫동안 손을 놓았기 때문에, 다시 복잡한 서버 관리를 할 자신이 없었습니다. 따라서 현석님이 최근에 옮겼다는 디지털오션과 같은 클라우드 컴퓨팅 환경으로 갈 자신이 없었습니다.
• 국내 업체가 아닌 해외 업체도 알아봤는데, 워드프레스 호스팅으로 유명하다는 블루호스트는 서비스 신청 막판에 한국이 지원 국가로 수용이 안 되었습니다. 제가 무언가를 잘 못 했을 수도 있습니다.
• 국내 업체들을 보니 가격 면에서 일단 카페24가 (특히 개인 사용자에게는) 꽤 저렴했습니다.

결국 카페24의 “10G 광아우토반 Full SSD” “일반형”(월 사용료 1,100원)으로 옮겼는데 이전 호스팅 업체에 비해 불편한 점 몇 가지가 있습니다.

• 호스팅 요금 결재를 하려면 인터넷 익스플로러와 결재용 액티브엑스 플러그인을 깔아야 합니다. 최종 결재는 무통장 입금으로 했는데 이것도 생각보다 까다로웠습니다.
• 로그인, 아이디, 비밀번호 찾는 데, 실명확인, 휴대전화번호 확인 등이 너무 복잡하고 반복적이어서 짜증이 났습니다.
• 기본 하드디스크 용량이 500MB로 좀 작습니다. 대신 스트리밍 (주로 비디오, 오디오 파일 공간)과 CDN 디스크 공간 (주로 이미지와 기타 파일 공간)을 따로 제공해준다고 하는데, 신청을 해야 하고, 개인 사용자가 별도의 서버를 통해 그렇게 관리하는 게 아직은 더 복잡하게만 느껴집니다.

물론 이전 호스팅 업체보다 좋은 점도 있습니다.

• 우선 SFTP와 SSH 를 쓸 수 있습니다.
• 구 버전 MySQL 대신에 성능이 더 좋다는 MariaDB 10.1 로 갈아탔습니다.
• php도 7.0 대로 올라간 덕택에 워드프레스에서 모바일 페이지 지원이 무난하게 됩니다.
• DB 용량이 무한대이므로 용량이 넘칠까봐 걱정하지 않아도 됩니다.

이렇게 이사를 하니 집정리가 아직 좀 남았습니다.

• 옮기면서 기술적으로 서툴기도 하고, 약간 바꾸고 싶은 것도 있고 해서, 게시물 데이터 DB는 옮겼지만, 이전 서버에서 사용하던 디자인, 플러그인, 기타 여러 가지 조정해놓은 환경은 옮기지 않았습니다. 워드프레스와 XE의 버전이 올라가면서 굳이 많은 플러그인을 쓰지 않고, 굳이 프로그램 소스를 거의 수정하지 않아도 예전과 비슷하거나 좀 더 나은 퍼블리싱 결과물을 얻을 수 있기 때문입니다. 그래서 디자인과 환경 설정을 더 해야 하는데 아직 못했습니다.
• 그리고 아직 기존 도메인 gregshin.pe.kr 을 새 서버로 연동하지 않았습니다. 당분간 새 호스팅 환경에서 문제가 될 만한 것들을 다 수정하면 최종적으로 도메인을 연동할 생각입니다.
• 도메인 연동 후에 소위 말하는 제 수준에서 손발로 하는 검색 엔진 최적화(Searcho Engine Optimization) 와 웹 접근성을 높이기 위한 작업들을 좀 해야 합니다.

가장 중요한 것은 새 집에 담을 살림, 즉 콘텐츠와 글인데 얼마나 예전처럼 쓸 수 있을지 모르겠습니다. 아무튼 오랜 공백을 메울 수 있을지, 서서히 조금씩 가동을 해보겠습니다.

Read more "웹호스팅 서비스를 바꾸고 있습니다."

Real time feedback from your audience: PollEverywhere

As a trainer of some corporate training courses, I have been researched how I could make the classroom environment more engaging, interactive, and collaborative. Thanks to the dozens of social web technologies, we have variety of tools available for our classroom training. We have more millennials who are very accustomed to public social web services and it is definitely an opportunity for most of the trainers to enhance the level of audience participation by harnessing the power of social web tools. I would like to introduce a series of my own facilitating experience in the context of several corporate training programs. I learned and observed the live working example of these tools from Social Learning Bootcamp 2010, Social Media for Trainers, and Directory of E-Learning Tools. Of course, I would like to share my own practices which were tested several times in the real classroom situation. The very first one of this series is: How to collect real-time feedback from your audience.

There are some traditional Classroom Performance Systems (CPS) in the market (for example, CPS student response system). Those CPSs require some hardware and software combination to collect the audience feedback. Usually the trainer needs to distribute a remote controller (student response system) to each participant to collect individual feedback to the trainer’s hardware system. There is a much better way! You don’t need any hardware, software installation, no special device for the participants. Poll Everywhere is one of the most famous synchronous response collection services on the web.

You can create your own poll (whether it is a free text poll or multiple choice poll) without signing up. Of course, once you signed up, you can manage your polls and reuse it and have several more options. The best part of PollEverywhere is there are many different ways to send response. Participants in the classroom can send their response by:

• Sending text message to a designated phone number
• Submitting a code in Poll4.com website using their PC or smartphone
• Submit a code mentioning @poll4 in their Twitter account

When Poll Everywhere receives a response, the results are updated on the animated charts (for multiple choice polls) or the text wall (for free text polls). The trainer may decide to project the live results on screen like this:

The free version of Poll Everywhere gives us up to 30 responses quota for each poll. This 30 response limitation is still working well for mid sized class. I used this several times in different classes and different purposes: a mutual evaluation of team presentation, a simple question or quiz, a simple survey of user preference, and a free floating idea collection. It is very powerful for the poll creator and extremely easy for the respondents. Learners and I enjoyed the time when the live chart changes as more participants respond in real time!

Remember that as a trainer and poll creator, you have to go to http://polleverywhere.com and create a poll, and the audience can respond at http://pollev.com. It’s quite simple but quite effective to make your event or class more engaging and fun!

Read more "Real time feedback from your audience: PollEverywhere"

Changing blog design theme

I just replaced my old Gila theme with a new Suffusion theme. I did not thoroughly search for a perfect theme, but I just briefly looked at several themes. I may change to another theme if the Suffusion is not my taste after playing with it for a few days. My own preference, anyway, in selecting a blog design includes:

• It must be fluid width. I don’t want to be fixed with a specific browsing environment, and the width of the site must be flexible as users have different screen resolutions and browser widths. Try to resize your browser window while you keep looking at this page, you will see that the text will reflow and some graphics will be resized.
• I like strong contrast between foreground text and background. I hate faintly colored text or text with similar background color. The purpose of text is to deliver message, then I believe it must be clear at any case. If you print, copy or capture any parts of the text, the strong contrast will benefit more.
• Large fonts: Likewise I prefer large sized fonts by default although most of modern browsers provide some mechanisms to enlarge text or magnify the whole page.
• Standing out links: The link is the very basic but most important element in a hyperlinked web. I prefer to make the link prominent against non-link text in a widely used way: differently colored and underlined.
• Self-clear, descriptive text: A string of numbers such as “010-1234-5678” in Korea could imply a cellphone number. However, without any explicit description of “what it is”, readers are probably disoriented. Expression like “Mobile phone number: 010-1234-5678” is self-clear and context independent information. I try to avoid “implied” expression in the context but pursue direct and self-disclosing information at every part of my blog.

I did not finalized retouching the new blog design yet, it will take time. I will keep the above principles as I fine-tune the new theme. Give me any suggestions on better themes or better ideas to improve readability.

Read more "Changing blog design theme"

Firefox and Internet Explorer user style sheet for better keyboardnavigation

When you tab through a web page with your keyboard, a visual focus will move through all the links and form controls in the page. Modern browsers such as Opera, Safari, and Google Chrome and most of mobile browsers provide a visually distinctive focus. This clear focus dramatically enhances usability and accessibility of keyboard users (eg. people of visually impaired or low vision) as well as general convenience for majority of users. However two widely used browsers, Internet Explorer and Firefox stick to the traditional, not very conspicuous visual focus of gray dotted outline. This faint outline focus often makes me get lost when I use my keyboard for the within-page navigation. Compare the following default visual focus of each browser (for Windows):

Prominent visual focus of three modern browsers

Apple Safari	Google Chrome	Opera

Marginally distinguishable visual focus of two major browsers

Firefox	Internet Explorer 8

To get a clearer visual cue of where I am in a web page, I set the following user style sheet for Firefox and Internet Explorer.

:active, :focus {
	outline-width: 2px !important; 
	/* outline (unlike border) property does not take the space */
	outline-style: solid !important;
	-moz-outline-radius: 4px;
	/* this affects Firefox only, it makes the outline rounded  */
}

Refer to the articles below to get information about how to set your user style sheet in the two browsers:

• How to write a user style sheet for Firefox (Modify userContent.css.)
• Where is my Mozilla profile located? (Find where the userContent.css is located.)
• Write a user style sheet for Internet Explorer for Windows

Once you configured your user style sheet successfully, all the objects (including text links, image links, radio buttons, text input fields, image type buttons, etc) will be clearly outlined and stand out! Now enjoy your keyboard navigation and never get lost within a page!

Improved visual focus of two major browsers

Firefox	Internet Explorer 8

Be careful that the Internet Explorer version 6 and 7 do not support CSS outline property.

Read more "Firefox and Internet Explorer user style sheet for better keyboardnavigation"

Two things to be fixed in next update of Internet Explorer 8

I am quite thrilled to have a standards compliant and decent new version of Internet Explorer 8 produced by Microsoft. It is absolutely different from its predecessors and good enough to be praised by lots of standards devotees. I am sure that all the users who are stick to the old school version 6 or 7 do not have any reason of hesistating to upgrade. Now there would be a very exciting browser war among star browsers: Internet Explorer, Firefox, Chrome, Safari, Opera and some more. With the launch of new Internet Explorer, I tested two things as a keyboard user. The keyboard usability is highly important especially for some group of people including users with screen readers, users with motor disabilities, users with screen magnifiers, and users with mobile devices. The result of the test was unsatisfactory and I hope to see a fix of this soon.

Keyboard navigation within a page problem

This is a well known bug in the previous version of Internet Explorer and I stated this in the other post: The next tab navigation goes wrong after the activation of a skip navigational link within a page. Developers used some work-arounds to avoid this same-page navigation problem. I expected to see an improvement of this troublesome issue in Internet Explorer 8 but it sitll has the same bug. You can identify this problem by yourself at this testing page. Safari and Chrome have the same bug and only some Gecko based browsers (i.e. Firefox, SeaMonkey, etc) work exactly as expected today. Opera works differently according to the viewport size. It works very unique way and its keyboard navigation between links (Shift + arrow keys) is dependent on how much you see within a page. Hopefully I would like to deal with this Opera’s unique problem later.

Keyboard navigation between two frames problem

This is more subtle and has not been issued a lot since framed web pages are not used often in standards friendly web development these days. The problem is like this. When you activate a link in a frame whose target is in the other frame, the focus should be jumped into the other frame. Unfortunately there is no modern visual browser which support this. Although you activate the link in the first frame, you are still in the first frame and by pressing the tab again, you will be directed to the next link in the same frame. Look at this cropped frames sample page from University of North Texas.

The link in the picture, “Links Challenge” has “right” as the target attribute and it causes a change in the right frame. When you navigate this page with keyboard only, it is natural to continue your tab navigation in the “right” frame after selecting the “Links Challenge” link in the left frame. In reality, however, when you press the tab key again after “Links Challenge” is activated, you will be directed to the “Images Challenge” within the same frame not “Skip Navigation” link in the target frame. In short, in the picture, path “a” is wrong way and path “b” is the right way to navigate with the keyboard. Unfortunately there is no visual browsers (at the time of this writing) who support the path “b” and only two screen readers, JAWS and Home Page Reader make up for this and they will lead you to follow path b according to Jim Thatcher.

Read more "Two things to be fixed in next update of Internet Explorer 8"

PDF annotation software as an alternative to trainees' note taking

PDF (Portable Document Format)

Many people misunderstand that PDF is Adobe System’s proprietary format while the truth is it was released as an open standard. Therefore we have dozens of and hundreds of PDF solutions from simple desktop readers to huge and complicated enterprise systems. Everybody agrees that Adobe Reader is definitely one of the most popular PDF readers on various platforms? Actually we have dozens of other simple PDF readers (such as Foxit Reader), of course.

PDF creation

However, it is another common misconception that Adobe Acrobat is the only commercial software which can produce PDF files. I have used several different applications to create PDF in my workplace and home: CutePDF, doPDF, PDFCreator, OpenOffice.org, and our company’s own EDMS. Most of the free software apps have some limitations in accessibility (most of them do not support tagged PDF) but still they are good enough to make a quick PDF file.

PDF editing

It is a bit difficult to find an easy-to-use free PDF editing software app. But we do have. PDFescape, PDFfiller and PDFVue are wonderful but free web based PDF editing, form-filling, and commenting platforms. You don’t need to install any software to edit your PDF files.

Annotation on PDF

Here is my issue as a trainer: I wanted to distribute my presentation materials or trainees’ workbook with an electronic format such as PDF. I fully agree that it is not a good idea to use only electronic format in a typical classroom, for I am not sure if learners are focusing on the training materials and not distracted. People will suffer from pain in their eyes while gazing into the screen for a long time. The biggest problem, however is they cannot enjoy adding their personal notes and writings on the electronic file in a convenient way. I googled and found two free apps: PDF-Xchange viewer and Jarnal. My choice was PDF-Xchagne viewer since Jarnal is too big and requires a tablet PC for easy use. Free version of PDF-Xchange supports most of commenting options: highlighting, typewriting, underlining, sticky note, line drawing, polygon drawing and so much. Moreover, this personalized file can be securely saved, shared, referred, searched and re-distributed thanks to the EDMS in my company.

PDF workbook in the classroom

I have not tested this (PDF annotating) in a real classroom. I expect lots of obstacles, stiff resistance, repeated trials and errors from my coworkers and trainees. This is not a problem of technology but a problem of people’s habit, behavior, and tradition. I never saw any successful case in e-book business except Amazon’s Kindle. I’ll have to be very careful to practice this in the real classroom. At best, it might work in some very limited conditions. Korean government (Ministry of Education and Science) is also testing e-textbook (or digital textbook) for K12 education. We might need smarter hardware and software supporting natural viewing and writing based on intensive human behavior research.

Read more "PDF annotation software as an alternative to trainees' note taking"

옛날 제로보드 홈페이지가 해킹을 당했습니다.

워드프레스를 이용한 블로그를 쓰기 전에 2006년 초까지 제로보드라는 PHP 게시판을 썼습니다. 그런데 그게 상당히 옛날 버전이어서 보안이 매우 취약합니다. 그래서 스팸에 대한 대처도 거의 전무하고, 더욱 문제인 것은 해킹 위협에 그냥 노출되어 있다는 것입니다.

옛날 홈페이지에 악성 코드가 iframe으로 계속 삽입되어 생성되고, 이게 파일에서도 DB에서도 지워지질 않습니다. 한국 정보 보호 진흥원 인터넷 침해 사고 대응 지원 센터(http://www.krcert.or.kr)가 알려준 바로는 이 악성 코드가 홈페이지 방문자의 개인 정보를 가져갈 것으로 의심이 된다고 하는군요. 게시판의 관리자 기능도 먹통이 되어 버렸고, 대략 난감입니다. 어딘가 백도어가 설치되어 보안 취약점이 계속 노출되고 있는 것 같은데... 아무튼 옛날 버전의 게시판을 그냥 그 상태로 남겨놓은 것이 큰 실수였던 것 같습니다. 옛날 버전의 웹 프로그램에 대해서 제 때에 보안 취약점 패치를 하는 것과 평소 보안 관리를 잘 하는 것이 매우 중요하다는 것을 큰 댓가를 치르고 알게 되었습니다.

어쨌든 문제 해결까지 상당히 시간이 걸릴 것 같습니다. 흑흑...

Read more "옛날 제로보드 홈페이지가 해킹을 당했습니다."

웹 접근성 품질 마크 심사 끝

지난 몇 달동안 나를 최대한 괴롭혔던 것이라면, 단연코, 웹 접근성 품질 마크 심사였다. 웹 접근성 품질 마크는 이번이 4회째인데 대상 웹 사이트가 갈수록 늘어나 열 댓 명의 심사위원 한 사람에게 배정된 양이 만만치 않았다. 한 사이트에 대해 세 사람이 심사하고, 세 사람의 의견을 모아서 마지막으로 다시 한 사람이 보고서를 정리한다. 주말이나 저녁에 쉬는 시간이면 품질 마크 귀신이 나를 따라다니며 "네가 지금 이러고 있을 시간이 있어?"라며 괴롭혔다. 평가 기간동안 개선이 일어나면 다시 심사를 반복해야 했는데, 접근성이 개선된 것은 참 반가운 일이지만, 평가하는 사람들에겐 노동이 더 늘어나므로 반가운 소식만은 아니었다. 스물 여섯 개의 지표를 수십 개의 페이지에서 확인하는 일은 상당한 중노동이다. 그런 수십 아니 수백 수천 개의 페이지를 만든 사람의 노고에 비하면 별 것 아니겠지만.

웹 접근성은 모로 가거나 홀로 가도 대충, 빨리 앞으로만 가면 된다는 기술 지상주의나 성장 제일주의에 대해, "올바른 방향으로, 합의된 규칙을 지키며, 다같이 함께 가지 않으면 진보하지 않는 것"이라고 딴지를 거는 제동 장치이며, 기술과 디자인의 바른 길을 제시해주는 항법 장치이다. 다행히 이런 제도 때문인지 거의 바닥에서 출발한 한국 공공 기관의 웹 접근성은 눈에 띄게 좋아지고 있다. 대부분의 일반 기업들의 웹 사이트는 아직도 세계 최하위 수준이지만.

나중에 시간이 나면, 여러 사이트에서 공통적으로 자주 나오는 문제점들을 모아서 사례집으로 만들어도 좋을 것 같다. 키보드 보안 프로그램을 강제로 설치하도록 우기는 사이트들(개인적으로 키보드 보안 프로그램이야말로 과장된 보안 위협에 기반한 사기성 프로그램의 극치라고 생각한다.), 아직도 기본 중의 기본인 URI를 감추거나 페이지 제목을 제대로 안 쓰는 사이트, 뻔한 HTML을 놔두고 정말로 희한한 자바스크립트를 개발하여 적용한 사례 등등... 아무튼 오늘로 나에게 주어진 모든 사이트에 대한 보고서까지 다 마쳤다. 제발 다시 재심이 들어오지 않았으면 좋겠다. 연말을 편하게 보낼 수 있게...

Read more "웹 접근성 품질 마크 심사 끝"

극단적인 환경의 웹 접근성: 크로스브라우징을 넘어서

2008년 11월 3일 행정 안전부와 한국 정보 문화 진흥원에서 개최한 민간 부문의 장애인 웹 접근성 제고 세미나가 있었습니다. 제가 제일 마지막에 하나를 발표했는데, 웹 콘텐츠 접근성과 모바일 웹 접근성의 유사한 점, 그리고 장애인과 모바일 웹 사용자들의 비슷한 사용자 경험 등을 소개하려고 했습니다. 세미나 하면서 이번처럼 벼락치기로 준비한 것도 처음이었습니다. 그래서 원고도 꼴찌로 내고, 발표 시간에 겨우 맞추어 헐레벌떡 도착하고, 발표 하면서도 주제가 왔다 갔다 하면서 시간도 엄청나게 초과하는 우를 범했습니다. 세미나 진행하시는 분들에게는 최고로 미운 사람이 되었을 것입니다. 죄송합니다...

아무튼 모바일 웹은 매우 중요한 유행어(buzzword)가 되었을 뿐만 아니라 앞으로 다양한 모바일 기기와 기술은 웹을 접하는 중요한 플랫폼이 될 것임에는 틀림 없습니다. 발표 자료를 공유합니다.

박스닷넷에서 파워포인트 파일 원본 내려받기 또는 웹에서 보기 | 슬라이드셰어를 통해 웹에서 보기

Read more "극단적인 환경의 웹 접근성: 크로스브라우징을 넘어서"

주 사용 브라우저를 바꿨습니다.

구글 크롬이 나오자마자 블로그 스피어가 떠들썩하네요. 사실 저는 어제 오늘 정신없이 바빠서 프로그램을 볼 겨를도 없었고, 새로 나온 혁신적인 제품을 앞장서서 써보는 얼리 어답터(early adopter)도 아니기에 그냥 바라만 보고 있었습니다. 그런데 오늘 새로운 브라우저와는 전혀 거리가 먼 아버지로부터 문자를 한 통 받았습니다. 형이 개발에 참여한 크롬이라는 새로운 제품이 출시되었다는 내용이었습니다. 이번 여름에 미국 가서 형을 만났을 때에도 새까맣게 비밀로 해서 전혀 눈치 채지 못했었는데. 애플이나 구글이나 깜짝쇼 하면서 제품 내놓는 것이 비슷하네요.

지금까지 저는 집의 컴퓨터에서 오페라를 기본 브라우저로 쓰고 있고, 파이어폭스와 사파리, 그리고 인터넷 익스플로러를 보조적으로 쓰고 있었습니다. 물론 액티브엑스(ActiveX)로 떡칠이 된 한국 정부의 추한 웹 사이트들과 독점을 조장하는 금융결제원의 업무 태만과 법원의 몰상식한 판결로 아직도 앞길이 깜깜하기만 한 한국의 인터넷 뱅킹 사이트, 기타 상업용 사이트들 때문에 어쩔 수 없이 자유로운 선택이 막혀서, 구시대의 인터넷 익스플로러 6을 찜찜한 마음으로 써야 합니다. 오페라를 기본 브라우저로 썼던 이유는 웹 표준을 매우 잘 지원해주고, 탭 브라우징이 가장 완벽하고, 그리고 가볍고 빠르기 때문이었습니다.

회사에서는 사파리가 주 사용 브라우저였습니다. 그 이유는 회사에서 정책적으로(?) 파이어폭스와 오페라를 설치하지 못하도록 막아놨는데, 이상하게 사파리는 아직까지(!) 설치 및 실행이 가능했기 때문입니다. 맥용이 아닌 피씨용 사파리는 사실 별로 썩 편하진 않습니다. 느린 속도와 한글 처리에 있는 약간의 버그, 일반 윈도우즈용 프로그램과는 전혀 다른 방식의 글자 처리 등 때문에.

파일 크기가 474 킬로바이트밖에 안 된다는 말에 혹해 뒤늦게(?) 구글 크롬을 회사 컴퓨터에 받아봤습니다. 다행히 지금까지 다운로드 및 설치를 막아놓진 않았군요. 일단 다운로드 및 설치는 1분이면 끝납니다. 그리고 몇 개 사이트를 띄워봤습니다. 뭐 프로그램이 워낙 가볍고, 탭별로 서로 다른 독립적인 프로세스로 움직이는 점, 자바스크립트 처리 속도가 빠른 점이 일단 마음에 듭니다. 사파리와 컹커러(Konqueror)에서 사용하는 웹킷(Webkit)을 기본 렌더링 엔진으로 사용하기 때문에 새삼 웹 표준 지원에 대해서는 별로 걱정하지 않았고, 다른 사용자들이 이미 시험 결과를 많이 내놓았습니다. 저의 개인 블로그에서는 CSS 2.1의 외곽선(outline) 속성을 쓰고 있고, 일체의 시스템 종속적인 글꼴을 다 빼고, 오로지 범용 글꼴(generic font)만을 쓰고 있는데, 지금까지는 오로지 오페라만이 정확히 의도한 바를 표시했었습니다. 그런데 구글 크롬도 문제 없이 잘 표시해주네요.

운영체제(OS)가 아닌 웹이 플랫폼이 되어가는 시기에서 브라우저는 웹을 열어주는 관문으로서 잘 드러나지 않지만 매우 중요한 프로그램입니다. 사실 제가 하루에 컴퓨터를 쓰는 동안 브라우저를 닫아 놓고 있는 순간은 아마 거의 없을 것입니다. ‘컴퓨터로 하는 일’ = ‘웹에서 하는 일’이 거의 동의어가 된 지 오래되었습니다. 그런 의미에서 바람직한 브라우저는 사용자가 느끼지 못할만큼 투명하고 가볍게 뒤에서 사용자의 웹 작업을 도와주는 것이 시대의 요구였던 것 같습니다. 그런데 그런 요구에 가장 근접한 브라우저가 현재로선 크롬이라는 생각이 듭니다. 그래서 회사 컴퓨터에서 사파리를 대체해 크롬이 저의 제일 브라우저로 설정이 되었습니다. 집의 컴퓨터는 내일로 미루기로…

Read more "주 사용 브라우저를 바꿨습니다."

모든 페이지에 고유한 제목을 넣었습니다.

제가 얼마 전에 블로그에 제목의 중요성에 대한 글을 썼습니다만, 구글 웹마스터 도구로 진단을 하다 보니, 정작 제 자신의 블로그에는 제목이 중복되는 페이지가 꽤 있었습니다!! 특정 카테고리(category)와 태그(tag) 페이지까지는 제목을 구분해주었지만, 검색 결과 페이지가 블로그의 처음 페이지와 제목이 똑같았었고, 특정 카테고리가 여러 페이지로 구성된 경우, 카테고리까지만 구분이 되고 페이지 번호는 구분이 되지 않아, 모든 페이지의 제목이 똑같았습니다!

그래서 모든 페이지에 정말로 고유한(unique 또는 distinctive) 제목을 붙이기 위해 워드프레스의 header.php 파일의 페이지의 제목을 나타내는 부분을 아래와 같이 고쳤습니다.

<title>
 <?php 
  bloginfo('name'); 
  if ( is_home() ) { 
   echo(": ");
   bloginfo('description');
  } 
  if ( is_single() ) { 
 ?>  - Archive
 <?php 
  } 
  if ( is_category() ) {
 ?>  - Category
 <?php
  }
  if ( is_tag() ) {
 ?>  - Tag
 <?php
  }
  if ( is_search() ) {
 ?>  - Search results for 
 <?php 
    the_search_query(); 
  }
  wp_title(' - ',true,'');
  if ( is_paged() ) {
 ?>  - Page <?php echo($paged); } ?>
</title>

이제 현재 보는 페이지가 홈이면 블로그의 제목이, 특정한 글이면 글 제목이, 특정한 카테고리이면 카테고리 제목이, 태그 페이지이면 태그 제목이, 검색 결과이면 검색 결과라고 표시됩니다. 추가로, 카테고리나 태그, 또는 검색 결과가 여러 페이지로 구성된 경우에는 각각의 페이지마다 페이지 번호를 제목에도 넣어주었습니다. 예를 들면 아래와 같이 나옵니다.

첫 페이지:

Greg Shin’s Blog: 신승식의 블로그

특정한 글 하나만 나오는 페이지:

Greg Shin’s Blog – Archive – 한국이 중국인가?

“accessibility” 태그 페이지:

Greg Shin’s Blog – Tag – accessibility

“Review” 카테고리 페이지:

Greg Shin’s Blog – Category – Review

“Review” 카테고리 중 두 번째 페이지:

Greg Shin’s Blog – Category – Review – Page 2

“accessibility”를 넣어 검색한 결과 페이지:

Greg Shin’s Blog – Search results for accessibility

“accessibility”를 넣어 검색한 결과 중 두 번째 페이지:

Greg Shin’s Blog – Search results for accessibility – Page 2

제목은 이렇게 해서 고유해졌는데, 메타 데이터(meta data)가 중복되는 페이지가 있군요. 페이지의 키워드, 설명 등 메타 데이터도 페이지의 특성에 가장 맞게 동적으로 생성해서 넣어야 겠는데, 이것에 대해서는 좀 고민해봐야겠습니다. 현재는 심플 태그(Simple Tags)라는 플러그인을 쓰고 있어서, 태그로 사용된 단어가 페이지의 키워드(<meta name="keywords" ...)로는 들어가게 되어 있습니다만, 페이지의 설명(<meta name="description" ...)이 모두 똑같게 나오는 문제는 여전히 남아있습니다.

Read more "모든 페이지에 고유한 제목을 넣었습니다."

제목의 중요성

최근 여러 개의 웹 사이트들을 자세히 뜯어볼 일이 생겨서 혹 뭐 트집(?)잡을만한 것 없나 의심의 실눈을 뜨고 페이지들을 살펴보았습니다. 그리고 두 가지를 느꼈습니다. 하나는 아마추어인 내가 점점 이해하기 어려운 방식의 코드가 늘어난다는 것이고, 다른 하나는 그럼에도 아주 복잡한 기법을 쓰는 사람들이 정작 기본적인 것을 놓치는 경우도 있다는 것입니다. 그 기본적인 것 중에 하나가 바로 “제목”입니다.

좋은 제목의 조건

이 세상 모든 것에는 제목이 있습니다. 사람에게는 이름이 있고, 컴퓨터의 파일에도 이름이 있고, 웹 페이지에도 이름이 있어야 합니다. 그 이름은 반드시 그 페이지의 내용을 대표할 수 있게 적절하게 지어야 합니다. 10개의 페이지로 이루어진 사이트가 있는데, 첫째도 “환영합니다”, 둘째도, 세째도, 마지막 페이지도 “환영합니다.”라는 똑같은 이름을 가졌다면, 웹 페이지 방문자들은 혼란스러워합니다. 그래서 이름을 짓는 것, 제목을 붙이는 것은 아무리 강조해도 지나치지 않은 매우 중요한 작업입니다. 제목은 다음과 같은 특성을 갖고 있어야 합니다. 아니 갖고 있어야 한다고 저는, 생각합니다.

대표성:

제목은 그 제목이 대변하는 더 많은 내용을 대표할 수 있어야 합니다. 예를 들어 이메일을 작성할 때에도 “아무개 회사 누구입니다.” 라고 모든 메일의 제목을 똑같이 쓰는 사람과 메일을 주고받다 보면 짜증이 납니다. 나중에 제목만으로 어떤 메일이 어떤 메일이었는지 구분이 안 되기 때문입니다. 게시판에 글을 올릴 때에도 “급한 질문입니다.” 이렇게 글을 올리면, 그 질문의 내용이 무엇이었는지 들어가보지 않으면 모릅니다. 나중에 특정한 질문을 찾으려고 검색을 해도 이런 “급한 질문”은 도움이 안 됩니다. 웹 페이지의 제목도 마찬가지입니다. 그 페이지의 내용을 가장 잘 대표하는 단어나 문장, 문구로 이루어져 있어야 합니다.

고유성(uniqueness):

모든 페이지의 제목은 고유해야 합니다. 그래서 페이지의 제목을 붙이는 것은 쉬운 일이 아닙니다. 하다 못해, 게시판에 글이 여러 개 있는데, 어떤 글을 읽을 때, 그 글에 답변을 달 때, 글목록을 볼 때, 글을 지울 때, 다른 글을 읽을 때 모두 각각의 상황에 맞고 다른 것과 구별되는 페이지 제목을 가지고 있어야 합니다. 아주 엄격히 말해서 페이지가 1,000개가 있다면 1,000개가 모두 다른 제목을 가지고 있어야 합니다. 이렇게 페이지의 제목이 다른 것과 구별되게 함으로써, 페이지가 너무 많아져도, 제목만으로 쉽게 구분할 수 있도록 할 수 있습니다. 이렇게 고유한 페이지의 제목은 일반 사용자들은 물론이고, 비시각적인 단서를 이용하는 시각 장애인들에게는 여러 개의 웹 페이지를 왔다갔다 하는 데에 매우 큰 도움이 됩니다.

간결성:

두 말하면 잔소리이지요. 요즘에 많이 줄었지만 페이지 제목에 이상한 문자를 넣는 경우가 있습니다. 예를 들면 “▒▒▒▒ 무슨무슨 기관 홈페이지에 오신 것을 환영합니다. ▒▒▒▒” 이런 식으로 말입니다. 사실 홈페이지 방문자를 정말 환영하고 싶으면, 제목부터 간결하게 쓸 데 없는 특수 문자 다 빼고, 환영한다는 말도 제목에서는 빼는 게 좋습니다. 대신 페이지의 내용에서 환영한다고 뜻을 밝혀도 충분합니다. 그냥 “무슨무슨 기관”만으로도 충분하지요.

합법적인(의미적인) 코드(semantic code):

웹 페이지에 있는 구성 요소들은 지금까지 합의된 합법적인 방법으로 제목을 표시해주어야 합니다. 그렇지 않고, 작성자가 맥락적으로 또는 암묵적인 방법으로 그것이 제목이라고 아무리 우겨도, 합의된 코드를 사용해서 명시적으로 제목을 표시해주지 않으면, 많은 사람들이 제목의 혜택을 얻지 못합니다. 즉, 내용과 제목을 명확하게 짝지어 주어야 합니다(explicit binding, 명확한 짝짓기). 자 이제 합의된 방식으로 제목을 표시하는 HTML의 기본 중의 기본을 한 번 나열해봅니다.

HTML에서 제목을 나타내는 방법

각 요소/속성마다 링크를 걸어놓았으니 모든 HTML 요소나 속성들에 대한 구체적인 사용법은 링크를 따라가서 참조하십시오.

페이지의 제목: <title> 요소

한 사이트 안에서 모든 웹 페이지들이 고유한 제목을 가지고 있어야 한다고 했습니다. HTML에서는 <title> 요소 안에 제목을 표시합니다. 예를 들면 제 블로그 안에서 https://www.gregshin.pe.kr/2008/03-post.html라는 페이지는 <title>신승식의 블로그 – Blog Archive » 청와대여, 기자들이여, 쑈를 하라!</title>와 같이 제목을 표시했습니다. 간혹 이 제목 부분에 자바스크립트를 써서 글자가 움직이게 하는 경우가 있는데, 절대 하면 안 되는 아주 나쁜 제작 습관입니다. 화려함을 자랑하고 싶다면 내용에서 해도 충분합니다.

프레임의 제목: title 속성

요즈음에는 프레임을 잘 사용하지 않지만, 프레임을 혹 사용한다면, 각각의 프레임이 고유하고, 내용이나 기능을 대표하는 제목을 가지고 있어야 합니다. 주의할 것은 프레임 제목을 사람이 알 수 있게 작성해야 한다는 것입니다. 예를 들면 title=”frame1″과 같이 하면 안 되고, title=”뉴스 브리핑”과 같이 해주어야 합니다.

문단의 제목: 헤딩 요소 <h1>, <h2>, <h3>, <h4>, <h5>, <h6>

자바도 아니고, 자바스크립트도 아닌 HTML은 정말 쉽습니다. 그런데 그 쉬운 HTML, 그리고 그 중에서도 정말 쉬운 문단의 헤딩을 빠뜨린 웹 페이지가 정말 많습니다. 많은 양의 텍스트, 그림, 도표 등이 있는 문서를 만들 때에 체계를 만들고, h1을 이용해 보통은 페이지를 대표하는 제목을, h2를 이용해 큰 제목을, h3을 이용해 중간 제목을, h4를 이용해 작은 제목을 달아주면 됩니다. 이렇게 하지 않고, 아무리 큰 글씨로 “이게 제목이야”라고 우겨도, 상당히 많은 사용자들은 그게 제목인지 알지 못하고, 제목만으로 내용 블럭을 구분하지 못합니다.

데이터가 담긴 표의 제목: <caption>

우리 나라 웹 페이지에서 잘 볼 수 있는 특이한 표현 방식 중에 하나는 빤히 데이터가 들어있는 대량의 텍스트나 표를 아예 이미지로 표시한다는 것입니다. 이렇게 이미지로만 표현된 데이터는 기계적으로는 아무 데이터가 아닙니다. 게다가 그것에서 유의미한 텍스트를 재활용한다든지, 추론을 한다든지, 일부를 복사한다든지, 시각적으로 크게 보기 위해 확대한다든지, 또는 줄인다든지, 더 선명한 색깔로 바꾼다든지, 나의 브라우저 환경에 맞게 재구성하거나 다른 감각 양식(modality)으로 바꾸어 전달해 주는 것이 거의 불가능합니다. 그래서 데이터가 담긴 표는 되도록이면 <table>이라는 요소를 이용해서 나타내야 합니다. 그리고 그 표가 무엇을 나타낸 표인지 한 개의 제목으로 압축해서 제목을 붙여주어야 합니다. 그럴 때에 <table> 바로 밑에다가 <caption>을 넣어주면 됩니다.

표 안에서 한 열이나 한 줄을 대표하는 제목: <th>

데이터가 있는 표는 보통 제목줄 또는 제목열과 일반 데이터가 있는 수많은 칸들로 이루어져 있습니다. 이 제목줄과 제목열에 예쁘게 하늘색으로 칠해준다고 제목이 되는 것이 아닙니다. 반드시 제목을 나타내는 요소인 <th>를 사용해야 합니다. 조금 복잡한 표의 경우 사용법이 좀 까다롭기 때문에 여기서는 이 정도만 언급합니다.

사용자 입력을 받는 폼 요소의 제목: <label>

웹의 저자가 일방적으로 무언가를 보여주는 것이 아니고, 사용자로부터 입력을 받는 양식을 폼(form)이라고 합니다. 폼에는 체크 상자, 라디오 버튼, 텍스트 입력 상자, 목록 상자 등 여러 종류가 있습니다. 그런데 이런 폼들이 달랑 폼만 나오면 사람들은 거기에다 무엇을 입력해야 하는지 모릅니다. 그래서 이런 폼에는 반드시 그게 무엇을 입력해야 하는 폼인지 제목을 <label>을 이용해 붙여줘야 합니다. 예를 들어 아이디를 넣어야 하는 입력 상자 앞에 그냥 텍스트로 “아이디”라고 넣어주는 것만으로는 부족합니다. 반드시 <label>을 이용해서 표시해주어야 합니다. 그렇게 해야 맥락을 파악하기 어려운 시각 장애인들이 해당 폼에 갑자기 툭 떨어졌을 때에, 그것이 “아이디”를 넣으라는 폼인지 알 수 있습니다.

유사한 여러 개의 폼 요소를 한 개의 집단으로 묶은 <fieldset>의 제목: <legend>

폼이 너무 많아지면, 폼 안에서 길을 잃을 수 있습니다. 예를 들어 회사 정보와 개인 정보를 각각 10가지씩 입력해야 하는 폼의 경우, 중간쯤 왔는데 “주소”를 넣으라고 하고, “우편번호”를 넣으라고 합니다. 그런데 이게 회사의 주소였는지 개인이 사는 집의 주소였는지 헷깔릴 수 있습니다. 따라서 이런 경우, 회사 정보 입력하는 부분을 묶어서 “회사 정보”라는 제목을 붙여주는 것이 좋습니다. 그럴 때 이용하는 것이 바로 <fieldset>이라는 요소입니다. 이렇게 함으로써 특히 폼을 쓰는 데에 어려움을 겪는 시각 장애인들이나 너무 많은 폼 안에서 이동의 어려움을 겪는 키보드 사용자들은 임의의 묶음으로 건너뛸 수 있어서 도움을 받습니다.

목록 상자에서 여러 개 목록 묶음을 대표하는 제목: <optgroup>

목록 상자(list box)에 목록이 너무 많을 때, 예를 들면, 전국 도시 이름을 목록 상자에 다 집어 넣고, 선택하라고 할 때에 순차적으로 목록을 탐색해야 하는 사람에게는 상당한 고역일 수 있습니다. 그럴 때에 도시들을 강원도, 경기도 등과 같이 지역별로 묶어서 제목을 적절히 붙여준다면 좀 더 쉽게 선택할 수도 있습니다.

용어 설명에 대한 용어 제목: <dt>

어떤 것에 대한 정의, 설명, 정의, 설명이 여러 번 반복된다면, 이것은 정의 목록(definition list, 즉 <dl>)을 이용하는 것이 좋습니다. 그래서 정의 부분은 <dt>로, 설명 부분은 <dd>로 나타냅니다. 이렇게 함으로써 이 설명이 무슨 용어, 또는 무슨 제목에 대한 설명이었는지 알 수 있게 됩니다.

참 다양한 요소에 제목을 붙일 수 있게 되어 있습니다. 꼭 HTML 문서가 아니더라도, 제목이 잘 붙어있어서, 접근하기 쉽고, 데이터로서 가치가 높은 양질의 문서들이 많으면 좋겠습니다.

Read more "제목의 중요성"

비 라틴 계열 문자를 한꺼번에 엔티티 문자로 바꾸기

우리 회사에서는 오라클 사의 아이러닝(iLearning)이라는 학습 관리 시스템을 쓰고 있다. 그 시스템은 비교적 국제화(globalization)가 잘 되어 있어서 지금까지 영어, 한국어, 스페인어, 프랑스어, 네덜란드어, 독일어로 된 하위 시스템을 구축하는 데에 문제가 거의 없었다. (물론 그냥 데이터는 그 밖에 언어인 중국어, 러시아어 등을 쓰는 데에도 문제가 없었다.) 그런데 이번에 중국어(Simplified Chinese) 기반으로 다시 하위 시스템을 만드는 과정에 여러 곳에서 문제가 발견되었다. 중국어쪽 고객이 많지 않아서인지 아예 중국어쪽 메뉴 타이틀에 대한 사전(dictionary)을 만들어놓지 않은 경우도 꽤 있었다.

그 중에 하나가 로컬에서 만든 CJK(중국어, 일본어, 한국어) 문자가 포함된 유니코드 파일을 서버에 업로드하면 문제가 생겼다. 서버는 분명히 유니코드 인코딩 방식의 하나인 UTF-8로 페이지를 보여주고 있었지만… 처음에는 파일을 잘못 만들었나 여러 가지로 검토해보았으나, 문제는 명백히 서버 쪽에 있었다. 그래서 결국에는 원본 파일에서 CJK 문자를 쓰지 않도록 할 수 밖에 없었는데, CJK 문자를 문자열 단위로 HTML의 엔티티 문자(entity character)로 바꾸어주는 사이트를 이용하다가 이건 아무래도 너무 불편해서, HTML 타이디(Tidy)에 인코딩 방식을 자동으로 바꾸어주는 옵션이 있다는 것을 알았다. CJK 문자가 포함된 문서를 ISO-8859-1로 바꾸면서 CJK 문자를 한꺼번에 엔티티 문자로 바꾸려면 아래와 같이 하면 된다.

tidy --input-encoding utf8 --output-encoding latin1 input_file > output_file

Read more "비 라틴 계열 문자를 한꺼번에 엔티티 문자로 바꾸기"

페이지 내 링크와 브라우저 버그

페이지 내 링크(within page link, same page link)란 한 웹 페이지 안에서 이동하는 링크입니다. 많이 쓰는 곳은 FAQ나 법 조항처럼 페이지 위쪽에 목차나 목록이 먼저 나오고 하나를 선택하면 그것과 대응하는 답변이나 상세 내용이 있는 부분으로 이동하기, 시각 장애인이나 키보드 사용자가 페이지 안에서 너무 많거나 복잡한 메뉴를 건너 뛰고 중요한 곳으로 바로 이동하기, 또 페이지 아주 밑으로 갔다가 페이지의 상단부로 다시 돌아오기 정도가 아닐까 생각됩니다. 이 중에 복잡한 메뉴를 건너 뛰는 목적의 링크를 보통은 바로 가기(skip navigation) 링크라고 합니다.

링크와 링크, 양식(form) 요소, 또는 다른 요소들 사이를 이동하는 방법은 브라우저마다 조금씩 다릅니다. 그러나 키보드를 사용했을 때에, 현존하는 브라우저 중에 이런 페이지 내 링크를 정말로 제대로 지원해주는 것을 찾기가 쉽지 않습니다. 우선 윈도우즈에서 자주 사용하는 인터넷 익스플로러 7, 파이어폭스 2, 오페라 9, 사파리 3으로 페이지 내 링크를 시험해보았습니다만 파이어폭스를 제외한 모든 브라우저에서 문제가 발견되었습니다. 이런 브라우저의 특성을 제작자가 다 알아서 꼼수를 써서 해결할 수는 없기 때문에 다음 버전 제품에서는 빨리 이 문제가 개선되면 좋겠습니다.

바로 가기 링크 시험용 예제 페이지 (다운로드 받은 후 로컬 PC에서 시험하세요.)

Read more "페이지 내 링크와 브라우저 버그"

A SMIL practice

SMIL represents Synchronized Multimedia Integration Language recommended by W3C. It is one of the XML applied domains which can control multiple images, videos, sounds, and texts. It is theoretically known as easy to develop, fairly accessible, and web native while it is not accessible in most common environment, only supported partly by a few web agents or players.

I developed a simple SMIL file for practice purpose. I just started to learn its syntax by myself and I am still far from making it highly compatible, standard-compliant, or accessible. I tested this first SMIL presentation with RealOne player and Ambulant Player 1.8. Ambulant Player is the only player who supports SMIL version 2.1 and RealOne supports 2.0 while Apple's QuickTime supports 1.0. Although Internet Explorer 5.5 or higher supports XHTML+SMIL, this combination does not work on other browsers.

Therefore, I tried to embed the SMIL file in my web page using standard <object> HTML element with type="application/smil+xml" attribute but failed because I could not find any browser which supports this MIME type automatically. I had no choice but to include non-standard deprecated <embed> element for non-Internet Explorer browsers with RealPlayer ActiveX for Internet Explorer.

Download the SMIL presentation file: October Trip to Haneul Park with CMHV Befrienders(2007)

Any feedback including comments, suggestions, or critiques for more accessible SMIL and more compatible SMIL embedding in a web page would be welcomed.

The presentation shows a series of photos taken at Haneul Park with my community members in CMHV paralleled with a background musical piece which was composed by me long time ago.

Read more "A SMIL practice"

Feed crashed! Feedburner subscriber disappeared!

오랜만에 피드버너(Feedburner.com)에 들어가서 내 피드 현황을 확인해보니 갑자기 구독자가 0이 되었습니다ㅠㅠ. 그래서 제가 쓰는 RSS 리더를 총 동원해 테스트를 해보았습니다. 피드 버너(feedburner.com), 구글 리더(www.google.com/reader), 블로그라인스(bloglines.com), 한RSS(hanrss.com), 다음의 한메일(daum.net), 마이 야후(my.yahoo.com), 오페라 브라우저에 내장된 구독기, 인터넷 익스플로러에 내장된 구독기, 파이어폭스에 내장된 구독기, 올블로그(allblog.net), 그리고 피드 밸리데이터(feedvalidator.org) 등으로 모두 검사를 해보았는데, 모두 다 안 되고, 오직 브라우저에 내장된 구독기만 작동을 합니다.

워드프레스 피드 부분 소스가 잘못 되었나 몇 번을 봐도 답이 안 나오더군요. 혹시나 하는 마음에 많은 시간을 들여 워드프레스를 2.3으로 업그레이드했는데도...! 여전히 문제가 해결되지 않았습니다. 그래서 워드프레스 문제가 아니라면 아주 옛날 옛적에 홈페이지에 만든 제로보드 게시판에 붙은 RSS 피드는 잘 잡히는지 검사해보았습니다. 음... 제로보드 게시판에 붙은 피드도 작동을 안 하더군요. 아니 옛날 홈페이지는 소스 손보지 않은지가 수만년은 지났는데 어떻게 갑자기 이런 일이...

그렇다면 잠정 결론은 며칠 전에 호스팅 업체가 옮겨준 서버에 문제가 있다고 봐야겠군요. 모든 피드 검사기의 주요 에러 메시지가 대략 피드 URL이 틀린 것 같다., 서버 시간 초과 이런 식으로 나오는 것으로 봐서 호스팅 업체의 PHP 서버에 문제가 있는 것으로 추정됩니다. 혹시 이 문제를 해결하는 방법을 아시는 분 좀 도와주십시오.

Although there seems to be no errors in my feed URL or feeding XML source, both RSS and ATOM feeds are not working properly especially for the users of web-based RSS aggregator. A server misconfiguration or any unknown reason is suspected to cause this feed error and I asked my web hosting provider to check this. If you are a subscriber of my blog, your RSS reader will not update any posts from my blog for the time being. I feel really sorry about this.

October 17, 2007: Some aggregators including Google Reader, Bloglines, Allblog, and Feedburner returned to the normal status although I lost some subscribers. Feed Validator, My Yahoo! still cannot recognize the feed. Plus, the loading speed of the web pages became much slower again. Hosting provider seemed to do something on my request.

Read more "Feed crashed! Feedburner subscriber disappeared!"

우리바탕, 우리돋움 출시에 대한 개인 의견

한글날을 맞아 우리글닷컴에서 개발한 소위 지능형 한글 글꼴이라는 것을 무료로 배포하고 있다고 신문에 보도되었습니다. 글꼴을 만드는 작업은 고도의 기술력과 프로그래밍, 디자인, 노력, 비용의 산물이기 때문에 우리글닷컴에서 개발한 결과물에 대해 감사와 경의를 표합니다. 그런 노력에 꼬투리를 잡으려는 의도는 아니며, 전문가가 아닌 일반 사용자로서 느낀 몇 가지 아쉬움, 신문 기사의 오류에 대해 말하고자 합니다. 제가 틀린 내용을 주장한다면 댓글로 반박해주십시오.

첫째, 서명덕 기자님의 기사에는 약간 오류가 있습니다. 기존에 윈도우즈 사용자들이 쓰던 굴림, 돋움 글꼴은 비트맵 글꼴이 아니라 트루타입 글꼴이지만, 작은 크기에서 트루타입 힌팅(hinting)이나 래스터라이징(rasterizing) 기술이 떨어질 때에 만들었던 글꼴이라 가독성을 임의로 높이기 위해 글꼴 크기마다 비트맵으로 디자인을 해놓은 것 뿐입니다.

둘째, 화면용 글꼴과 인쇄용 글꼴의 이원화는 비단 우리 나라에서만 생긴 문제는 아닙니다. 로마자 알파벳을 쓰는 서구 문화권에서도 아직까지 화면용 글꼴로는 고딕 계열(sans-serif)을 더 많이 사용하고, 인쇄시에는 명조 계열(serif)을 더 많이 사용합니다. 그것은 모니터와 글꼴의 품질이 아무리 발전했다고는 하지만 아직까지도 명조 계열을 종이에서만큼 깨끗하게 표시하는 데에 한계가 있기 때문이지 않을까 싶습니다. 그리고 사람들도 그것을 그냥 당연하거나 익숙하게 생각하기도 하구요.

셋째, 명조 계열 글꼴의 가독성이 더 좋다는 증거는 뚜렷하지 않습니다. 김태진(1991)의 실험 결과에서도 명조 계열 글꼴과 고딕 계열 글꼴의 지각적 반응 속도의 차이는 거의 없었고, 당시 유행하던 탈네모꼴 글꼴보다 네모꼴 글꼴을 더 쉽게 지각할 수 있는 것으로 나타났습니다. 그 이후로 제가 어떤 연구가 되었는지 찾아보지 않아서 추가적인 어떤 증거가 있는지는 모르겠습니다. 다른 증거가 있다면 알려주십시오.

넷째, 인터넷 한글 활자의 공급이 마이크로소프트사에만 의존하고 있다면서 한국인을 위한 한국인에 의한 인터넷 활자의 제작이라는 취지는 좋지만, 하필이면 마이크로소프트사의 인터넷 익스플로러에서만 작동하는 비표준 독점 기술인 액티브 엑스를 사용해야만 글꼴을 볼 수 있다는 것이 아쉽습니다. 다른 브라우저 사용자들은 유료로 돈을 주고 글꼴을 사야 하겠지요.

다섯째, VTT(Visual TrueType)은 마이크로소프트의 폰트 개발 도구로 윈도우즈 XP에서부터 도입된 소위 클리어타입(ClearType)이라는 발전된 힌팅 기술을 적용해 글꼴을 개발할 수 있게 해주는 것입니다. 이 툴을 이용했다는 것과, 한글 글꼴폭을 가변적으로 했다는 것만으로 지능형 한글 시스템이라는 이름을 붙인 것은 좀 과장인 것 같습니다. 가변폭 글꼴은 이미 1990년대에 빨래줄 글꼴이 나오면서 등장을 했고, 글자의 폭이 다르기 때문에 초기에 워드프로세서와 같은 프로그램에서 처리하기가 상당히 까다로웠었지만 옛날의 이야기입니다. 디자인 면에서는 완전히 똑같은 폭에 모든 글자를 가두지는 않고, 그렇다고 기존의 빨래꼴 글꼴처럼 심한 변화를 주지는 않았네요. 그런데 "이" 모음이 있는 글꼴이 "오"나 "우" 모음 글꼴보다 확연하게 좁게 한 것이 개인적으론 아주 자연스러워보이지는 않습니다. 다만, 아직까지 한글 글꼴에서 글꼴의 특성에 따라 시각적으로 간격을 일정하게 조정해주는 커닝(kerning)이 적용된 글꼴이 없었다는 것을 감안하면 아주 반가운 일입니다.

참고: 영문 글꼴들은 보통 글자에 따라 폭이 넓거나 좁은 대신, 글자들 사이의 간격을 일정하게 유지하는 것이 일반적입니다. 글자의 폭을 일정하게 유지해야 하는 특수한 경우(예를 들면 코딩할 때 쓰는 글꼴이나, 구식 타자기 글꼴)에는 글자의 폭을 일정하게 유지하는 대신, 세리프(serif)를 크고 과장되게 그려서 여전히 글자간의 간격을 일정하게 유지하지요.

여섯째, 클리어타입이 모든 모니터에서 다 깨끗하게 잘 나오는 것은 아닙니다. 저같이 구형 LCD 모니터를 쓰는 사람들은 대부분의 힌팅을 적용한 글꼴들이 상당히 많이 퍼져서 흐릿하게 보이거나 색번짐이 나타납니다. 그래서 윈도우즈 비스타에서 기본으로 제공하는 맑은 고딕 글꼴에 똑같이 클리어타입을 적용해서 봐도, 고급 노트북 화면에서 볼 때와 구형 아날로그 연결 방식의 LCD 모니터에서 볼 때 상당히 차이가 납니다. 그래서 구형 모니터에서는 아직도 클리어타입을 비롯한 모든 힌팅 옵션을 다 끄고, 그냥 얇고 또렷한 굴림을 사용합니다. 맑은 고딕을 강제로 적용한데다가 전경과 배경색의 대비도 흐릿하게 해놓은 웹 페이지를 윈도우즈 환경에서 구형 모니터로 보고 있으면 상당히 짜증이 납니다. 마찬가지로, 웹 페이지에서 강제로 클리어타입을 적용하도록 해서 사용자에게 선택권을 빼앗아갈 때에 불편을 느끼는 사용자도 있을 수 있습니다.

일곱째, 웹에서의 여러 가지 글꼴 사용에 앞서, 보편적인 정보 전달 원리를 충실히 지켜야 합니다. 웹을 종이 매체와 똑같이 보는 것에는 무리가 있습니다. 종이 매체에 한 번 찍힌 글자는 그대로 고정되지만, 웹에 찍힌 글자를 모두가 똑같은 환경에서 보지는 않습니다. 사람마다 모니터의 종류도 다르며, 모두가 윈도우즈를 사용하지도, 인터넷 익스플로러를 쓰는 것도 아닙니다. 심지어, 어떤 사람은 글자를 시각적으로 듣는 것이 아니라 음성으로 웹 페이지를 듣습니다. 즉, 모든 사람이 해당 글꼴을 똑같이 볼 수는 없다는 것을 감안한다면 글꼴에 의존적인 디자인은 경계해야 합니다. 우리글닷컴 홈페이지에는 모든 사람이 윈도우즈 환경이며, 인터넷 익스플로러에서 해당 글꼴을 볼 수 있다고 가정하고, 게다가 글꼴을 특별히 키우거나 줄이지 않고 기본값으로만 본다고 가정하고 페이지를 디자인하였습니다. 따라서 위의 조건에서 조금이라도 벗어난 모든 사람들은 이상하게 어긋나거나 해독이 어려운 텍스트들을 보게 됩니다.

이와 같은 현상은 아직도 웹이나 컴퓨터 화면의 특성을 제대로 파악하지 못하고, 고정된 폭을 가진 종이 위에 타자기로 글자를 찍던 시절에 사용하던 줄바꿈 방식을 그대로 사용하기 때문에 일어납니다. 아직도 많은 사람들이 워드프로세서나 프리젠테이션 프로그램이나, 웹 페이지를 작성할 때에 흔히 범하는 실수입니다.

너무 부정적인 의견만 내세운 것 같습니다. 천편일률적이고 멋도 없는 굴림 글꼴 때문에 많은 사람들이 쓸데없이 그래픽으로 글자를 그리던 관행에서 벗어날 수 있는 대안적인 글꼴이 많아지고 보급되는 것은 참 좋은 일입니다. 그러나 그런 글꼴도 보편적인 기술 환경에서 보편적으로 활용 가능하도록 보급했으면 더 좋았을 것 같은 아쉬움이 남습니다. 그리고 새로운 글꼴을 써서 멋스럽게 웹 페이지를 만드는 것보다 더 중요한 것은, 정보 전달이라는 원래의 의도가 어떤 환경에서도 훼손되지 않도록 신경을 쓰는 일일 것입니다.

Read more "우리바탕, 우리돋움 출시에 대한 개인 의견"