<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>한날의 낙서 &#187; 네이버</title>
	<atom:link href="http://www.hannal.net/blog/tag/%eb%84%a4%ec%9d%b4%eb%b2%84/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.hannal.net/blog</link>
	<description>가볍거나 혹은 얕은 낙서</description>
	<lastBuildDate>Thu, 03 Jun 2010 06:26:21 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>어제 날씨에 따른 오늘 날씨, 내일 날씨</title>
		<link>http://www.hannal.net/blog/weather_forecasting_ui_with_yesterday_weather/</link>
		<comments>http://www.hannal.net/blog/weather_forecasting_ui_with_yesterday_weather/#comments</comments>
		<pubDate>Thu, 14 May 2009 00:43:09 +0000</pubDate>
		<dc:creator>Hannal</dc:creator>
				<category><![CDATA[생각 잡기]]></category>
		<category><![CDATA[daum]]></category>
		<category><![CDATA[naver]]></category>
		<category><![CDATA[ui]]></category>
		<category><![CDATA[ux]]></category>
		<category><![CDATA[날씨]]></category>
		<category><![CDATA[네이버]]></category>
		<category><![CDATA[다음]]></category>
		<category><![CDATA[일기예보]]></category>

		<guid isPermaLink="false">http://www.hannal.net/blog/?p=1781</guid>
		<description><![CDATA[왜 다음이나 네이버 같은 포털 웹서비스들은 일기예보 정보를 제공할 때, 어제 날씨를 함께 볼 수 있게 하지 않을까?
아침에 잠자리에서 일어나기 힘들거나 관절이 뻑뻑하거나 하늘이 수상쩍으면 웹에서 날씨를 확인하곤 한다. 내 몸이 날씨를 느끼는 것보다 기상청에서 날씨 예측하는 게 더 많이 틀려서 자주 확인하진 않는다. 예를 들어, 기상청에서 비 올 확률이 30%라고 한다면 이 말은 비가 [...]]]></description>
			<content:encoded><![CDATA[<p>왜 다음이나 네이버 같은 포털 웹서비스들은 일기예보 정보를 제공할 때, 어제 날씨를 함께 볼 수 있게 하지 않을까?</p>
<p>아침에 잠자리에서 일어나기 힘들거나 관절이 뻑뻑하거나 하늘이 수상쩍으면 웹에서 날씨를 확인하곤 한다. 내 몸이 날씨를 느끼는 것보다 기상청에서 날씨 예측하는 게 더 많이 틀려서 자주 확인하진 않는다. 예를 들어, 기상청에서 비 올 확률이 30%라고 한다면 이 말은 비가 오지 않을 확률이 70%라고 억지 부릴 수 있기 때문이며, 반대로 비 올 확률이 70%라면 굳이 기상청 예보가 아니더라도 하늘을 올려다보거나 내 혈압 상태와 관절만 확인해도 비 올 확률이 아주 높다는 걸 알 수 있기 때문이다.</p>
<p>요즘처럼 기온이 그날 그날 많이 다를 때 더 그렇다. 기온이 그다지 높을 것 같지 않아 얇지만 긴 팔을 입었는데 햇볕이 쨍쨍해서 땀냄새 풍기고 다닐 수 있고, 더울 것 같아 반팔 입었는데 쌀쌀해서 아침 저녁으로 <a href="http://me2day.net/-_-/2009/03/23#17:51:16">고른 살결</a>을 가진 팔뚝에 닭살을 달고 다닐 수 있다. 아침에 일어나 집을 나서기 전에 이런 상황을 피할 적절한 판단을 5~10분 사이에 내려야 하는데, 영 아리송할 때엔 기상청 일기예보를 확인한다.</p>
<p>기상청 일기예보라고는 해도 <a href="http://www.kma.go.kr">기상청 누리집</a>에 가는 건 아니고, 주로 다음이나 네이버 같은 포털에 가서 날씨를 확인한다. 웹 브라우저 주소 입력란에 kma.go.kr 이라고 치는 것보다 daum.net 이라고 치고 검색란에 “날씨”라고 입력하는 게 더 손에 익고 편하기 때문이다. 근데 참 불편한 점은 다음이나 네이버 모두 오늘부터 며칠 후까지 일기예보 정보를 제공할 뿐, 어제 날씨 정보를 제공하지 않거나 확인하기 무척 어렵게 해놨다.</p>
<p>오늘 최고 기온은 24도이고 최저 기온은 14도라고 한다. 근데 23도는 쬐금 덥고 24도는 쬐금보다 쬐금 더 덥고, 25도는 쬐금보다 쬐금 더 더운 것에서 아주 쬐금 더 더운 것일까? 14도일 때 반팔을 입으면 닭살이 5제곱 센티미터만큼 돋고, 13도이면 6제곱 센티미터만큼 돋는 것일까? 알 수 없는 노릇이다. 30도 이상이면 덥겠고 10도 정도라면 쌀쌀하겠고 0도 정도라면 춥겠거니 하고 만다. 비가 올 지 안 올 지는 여부를 그다지 믿지 않는데, 기온도 그다지 공감을 일으키질 못하니 다음이나 네이버에서 제공하는 일기예보 정보는 내게 시덥잖은 정보가 되고 말았다. 절대음감도 아니고 절대냉온감을 지녀 기온 수치를 보고 그 정도를 미리 알 수 있을 리 만무하다. 절대냉온감<small>(이런 말이 있긴 있나?)</small>을 갖지 못한 사람한테 절대 값을 주는 꼴이다.</p>
<p>하지만, 어제 날씨를 함께 제공하면 이 건조하고 불친절한 기온이나 비 올 확률은 더 많은 정보를 알 수 있다. 어제 날씨를 경험해보니 좀 쌀쌀했는데 낮 기온이 17도였고, 오늘 낮 기온이 19도라면 19만큼 쌀쌀하거나 따뜻하다고 생각하는 게 아니라 어제보다 좀 더 따뜻하게 입으면 되겠다는 생각을 할 수 있기 때문이다. 어제 비 올 확률이 30%였는데 하늘이 배탈난 마냥 꾸룩거리기만 했을 뿐 결국 비가 오지 않았다면, 오늘 비 올 확률 40%는 비가 안 올 확률이 60%라고 느껴지기보다는 비 올 40% 확률을 좀 더 신경 쓸 것이다.</p>
<p>일기<strong>예보</strong>이니 지나간 어제 날씨를 제공하지 않는 것일까? 함께 보면 더 정보전달력이 좋을텐데.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.hannal.net/blog/weather_forecasting_ui_with_yesterday_weather/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>네이버 블로그 시즌 2 에피소드 2 편집기를 만져보고.</title>
		<link>http://www.hannal.net/blog/thinking_about_naver_blog_s2_ep2/</link>
		<comments>http://www.hannal.net/blog/thinking_about_naver_blog_s2_ep2/#comments</comments>
		<pubDate>Sun, 29 Jul 2007 14:52:13 +0000</pubDate>
		<dc:creator>Hannal</dc:creator>
				<category><![CDATA[나른한 오후에 써봄직한 가벼움]]></category>
		<category><![CDATA[ui]]></category>
		<category><![CDATA[ux]]></category>
		<category><![CDATA[네이버]]></category>
		<category><![CDATA[네이버블로그]]></category>
		<category><![CDATA[블로그]]></category>
		<category><![CDATA[편집기]]></category>

		<guid isPermaLink="false">http://www.hannal.net/blog/thinking_about_naver_blog_s2_ep2/</guid>
		<description><![CDATA[아따, 이름 한 번 어렵다. 시즌 2에 에피소드 2라니. 참 뜬금 없고 구분 안되는 version 2.2 이런 것보다야 낫지만 “대중성”을 가장 큰 무기로 삼는 곳 치고는 참으로 불친절한 이름이다.
아무튼 이름은 제끼고, 이번 판올림에서 겉으로 가장 크게 드러난 부분인 글 편집기를 들여다 봤다. 얼핏 보면 Mac OS용 무른모(software)인 iWeb을 떠올리게 하는데, 더 시간을 들여 만지작거리니 사뭇 [...]]]></description>
			<content:encoded><![CDATA[<p>아따, 이름 한 번 어렵다. 시즌 2에 에피소드 2라니. 참 뜬금 없고 구분 안되는 version 2.2 이런 것보다야 낫지만 “대중성”을 가장 큰 무기로 삼는 곳 치고는 참으로 불친절한 이름이다.</p>
<p>아무튼 이름은 제끼고, 이번 판올림에서 겉으로 가장 크게 드러난 부분인 글 편집기를 들여다 봤다. 얼핏 보면 Mac OS용 무른모(software)인 <a href="http://www.apple.co.kr/ilife/iweb/">iWeb</a>을 떠올리게 하는데, 더 시간을 들여 만지작거리니 사뭇 달랐다. 결론부터 말하자면 “<strong>참 잘 만들었다</strong>”.</p>
<p>화면이 좁니, 느리니, 왜 이 아이콘이 여기 붙어있다느니 하는 얘기는 그다지 중요하지 않다. 처음에 에피소드 2를 열었던 날에 본 편집기 화면과 오늘 본 편집기 화면이 또 다르듯이(물론, 지금이 더 낫다) 앞으로 이용자 경험 분석을 통해 계속해서 고쳐나갈 것이기 때문이다. 중요한 건 어떤 식으로 고쳐나가건 어떤 기준에 따를 것인데 그게 무엇이냐는 것이다.</p>
<p>내가 봤을 때 에피소드 2에서 핵심은 <strong>주제나 목적에 잘 맞는 도구를 제시</strong>하는 것이다.</p>
<p>잠시 네이버 블로그를 떠나서 기존 블로그 도구나 서비스에 있는 글 편집기를 보자. 차이야 있지만 글 쓰는 데야 별 문제 없다고는 해도 어떤 주제나 생각을 표현하는 데 잘 맞춰져 있진 않다.</p>
<p><a href="http://hannal.net/blog/wp-content/uploads/2007/07/iweb_screenshot1.png" title="iWeb 화면 갈무리 사진"><img src="http://hannal.net/blog/wp-content/uploads/2007/07/iweb_screenshot1-150x150.png" alt="iWeb 화면 갈무리 사진" /><br />
::: 사진을 누르면 원래 크기로 볼 수 있음 :::</a></p>
<p>위와 같은 화면 구성을 가진 글을 쓴다고 가정했을 때, 기존 글 편집기들로는 쉽지 않았다. HTML 직접 수정 기능이 있고 HTML 을 아는 사람이라면 이리 저리 공간을 쪼개고 각  공간에 내용을 채우겠지만, 대다수 사람들은 HTML을 모른다. 그나마 쓰는 대로 수식 결과를 바로 볼 수 있는 편집기(위지윅)니까 글 사이 사이에 색도 넣고 굵게 꾸미기도 하고 사진도 넣는 것이다. 하지만, 글 꾸미기는 여기에 그치는 경우가 대부분이며 화면 구성은 그냥 위에서 아래로 주욱 늘어 뜨린 글이 거의 전부이다. 왼쪽, 오른쪽 공간을 활용하고 싶지만 <strong>그렇게 할 줄 모르거나 아주 귀찮기 때문</strong>이다.</p>
<p>정보 신뢰성을 크게 떨어뜨리는 제 3 자인 “아는 사람” 얘기를 꺼내자면, 그는 자신의 컴퓨터에 글을 <a href="http://www.apple.co.kr/ilife/iweb/">iWeb</a>으로 작성해서 기록해둔다. iWeb 안에 있는 각종 서식 중 쓰임새에 맞는 것을 골라 글을 기록해둔다. 찾는 것이야 Mac OS X에 내장된 검색 기능(spotlight)로 하고, 웹에 올릴 때는 별 다른 수정 없이 작성한 글 그대로를 그냥 올린다. 여행기나 요리법, 인터뷰 등 주제는 다양하고 각 글 모양새도 각 주제에 맞게 적절하게 구성되어 있다.</p>
<p>이번 네이버 블로그 편집기에 있는 “<strong>레이아웃</strong>”은 이제 블로그를 어떻게 갖고 노는 지 알아서 더 멋진 글을 쓰고 싶은 사람들에게 좋은 기능이다. 사람들이 많이 쓸 법한 레이아웃 중 하나를 고른 뒤 그 안에다 사진이나 글 내용을 담으면 끝이다. 위에서 아래로 주욱 글을 늘어뜨려야 했던 예전과 비교하면 조금 더 직관성 높은 글을 쉽게 쓸 수 있도록 한 것이다.</p>
<p>두 번째 봐야 하는 부분은 DB첨부이다. 이건 앞서 언급한 글 편집기와 맞물려서 더 힘을 발휘하는 부분이다. 글을 주제나 생각에 어울리는 겉모양새를 입힌 데에 <strong>신뢰성까지 더하는 것</strong>이다.</p>
<p>“슈퍼 중이야”라는 가수 떼(어감이 어째 이상하다)에 대해 글을 쓸 때, 13명이나 되는 구성원 얼굴 사진을 이리 저리 잘 배치하고 그 옆에 이름 등을 다룬 뒤 “인물DB”에서 관련 정보를 연동하면 좀 더 그럴 듯해 보일 것이다.</p>
<p>물론, 이전에도 이런 DB 연동하는 기능을 다른 곳에서 볼 수 있었다. 하지만, 이런 기능들은 찾고자 하는 관련 정보를 좀 더 편하게 퍼오는 정도에 그쳤지, 대체로 내가 원하는 글 화면 구성(layout)을 망가뜨리는 귀찮은 놈이 되기 일쑤였다. 왜냐하면 내가 표현할 수 있는 화면 구성은 기껏해야 위에서 아래로 깔끔하게 나열하는 정도인데, 크기도 작지 않은 왠 상자가 떡하니 공간을 차지하면 그다지 화면과 어울리지도 않는다. 어떤 곳은 그 상자를 이용자가 원하는 곳에 옮길 수도 없더라.</p>
<p>&#8230;</p>
<p>블로그 안에 있는 글 편집기를 보며 나는 망치를 떠올리곤 했다. 망치는 기본 도구로 집을 짓거나 고치는 데 없어서는 안된다. 하지만, 망치는 뭔가를 두드리는 데 특화된 도구이지 자르거나 맨질 맨질하게 다듬는 도구는 아니다. 대단히 솜씨 좋은 누군가는 망치 하나로 아주 멋진 호텔을 지어낼 수도 있겠지만, 사람들 대부분은 망치로 못질만 한다. 애초 망치는 딱 그 정도 쓰임새에 맞춘 도구이다.</p>
<p>어떤 쓰임새에 잘 맞는 도구는 그 쓰임새에 대해 적절한 기능과 성능을 낸다. 글자를 써넣는 데 적절한 편집기라면 나처럼 글자 위주로 글을 채울 것이고(워드프레스 기본 편집기는 불친절하다), 사진을 담고 말을 덧붙이는 데 적절한 편집기라면 자연스레 사진 중심으로 글을 채울 것이다. 여태껏 네이버 블로그는 <a href="http://www.hannal.net/think/글의-가치와-글들의-가치/">맛있는 칼국수 글만 가득 모여 여론을 형성하는 데 그쳤었다</a>면, 앞으로는 서울에 있는 어떤 칼국수 집에서 칼국수 먹은 사진을 예쁜 화면 구성으로 담고 글 아래에 그 칼국수 집 찾아가는 약도도 아주 생동감 있게 첨부한 글이 많아질 것이다.</p>
<p>좋은 도구가 생각 질을 올리진 않겠지만, 글의 질은 기본 수준을 올리는 데에는 큰 역할을 한다. 네이버 블로그에서 행한 이번 판올림은 그런 점에서 아주 꼼꼼하고 수준 높은 기획, 그리고 그 기획을 구현한 기술을 볼 수 있다.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.hannal.net/blog/thinking_about_naver_blog_s2_ep2/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>
