글을 읽을 때의 시선의 움직임과 화면의 크기, 거리 등을 고려했을 때 적정한 윈도우의 크기는 대략 한 줄에 10-15 단어가 표시되는 크기다(
TenWordLine에서는 한 줄에 10 단어 정도의 폭을 권한다). 그 이상 길어지게 되면 한 줄을 읽다가 다음 줄로 넘어 갔을 때 시선의 흐름을 잃고 방황하기 쉽다. 직접 실험해 보라. 화면의 가로 크기를 대략 10-15단어가 표시되게 줄여놓고 읽어보라. 훨씬 빠르고 편하게 읽을 수 있다는 것을 느낄 것이다. 불행히도 우리나라 대부분의 게시판, 웹 사이트들은 20-40 단어 사이를 오간다. 그야말로 피로를 강요하는 디자인인 것이다. 물론 한줄당 적당한 단어의 숫자는 사람에 따라 다를 수가 있다. 가장 이상적인 경우는 HTML코드에서 고정폭을 사용하지 않고 유저로 하여금 자신의 웹브라우져 윈도우 크기를 조정할 수 있도록 하는 것일지 모른다.
TenWordLine에서는 한 줄에 10 단어 정도의 폭을 권한다). 그 이상 길어지게 되면 한 줄을 읽다가 다음 줄로 넘어 갔을 때 시선의 흐름을 잃고 방황하기 쉽다. 직접 실험해 보라. 화면의 가로 크기를 대략 10-15단어가 표시되게 줄여놓고 읽어보라. 훨씬 빠르고 편하게 읽을 수 있다는 것을 느낄 것이다. 불행히도 우리나라 대부분의 게시판, 웹 사이트들은 20-40 단어 사이를 오간다. 그야말로 피로를 강요하는 디자인인 것이다. 물론 한줄당 적당한 단어의 숫자는 사람에 따라 다를 수가 있다. 가장 이상적인 경우는 HTML코드에서 고정폭을 사용하지 않고 유저로 하여금 자신의 웹브라우져 윈도우 크기를 조정할 수 있도록 하는 것일지 모른다.이런 이유로 노스모크에선 고정 윈도우폭을 사용하지 않는다. 많은 사람들이 "윈도우 최대화"(모니터 스크린에 현재 윈도우가 전체를 차지하는 경우) 상태에서 노스모크를 보고는 처음 하는 말이 "읽기가 불편하다" "좀 폭을 좁혀줬으면 좋겠다"는 불평부터 시작해서, 심지어는 매 줄을 HardLineBreak를 이용해서 명시적으로 나누는 경우가 있다. 노스모크는 사용자가 직접 자신이 원하는 윈도우의 폭을 맞춰놓고 사용하기에 편하도록 디자인되어 있다. 이것이 위키위키가 추구하는 유연성이기도 하다.
김창준의 16여년 통신 경력에서는 10-12개 정도의 단어가 한줄에 오는 것이 적당했다. (중요한 것은 단어의 숫자보다, 그 개수 만큼의 단어들이 화면에서 형성하는 물리적 길이가 내 눈에 와서 맺히는 영상의 길이와 동시에 그만큼의 양의 글을 읽는데 걸리는 평균적 시간 -- 작은 글씨체로 한 줄에 30단어를 볼 수 있을지라도, 그걸 이해하는데 걸리는 시간이 자신의 "최소 집중 단위 시간"보다 길다면 줄과 줄 사이에서 방황하기 쉽다) 독서의 경우와 직접적으로 비교하기 힘든 것이, 최소한 "눈의 건강"을 고려하는 사람이라면 눈과 모니터의 거리가 최소 50센티는 넘어야 하고 보통 팔 하나를 좌악 뻗은 상태이고, 화면의 특성상 좀 더 많은 눈 깜빡임을 필요(눈의건강을 생각한다면)로 하며 독서물 자체가 발광하는 것 등 그 상황에 차이가 있기 때문이다. 뭐, 자신의 몸이 훨씬 더 많은 단어를 선호한다면 다르겠지만. 물론, 제대로 ListenToYourBody 하기만 했다면... --김창준
윈도우크기를 화면 가득 꽉 차게 해놓았을 때와 작게 줄여놓았을 때, 놀라울 정도로 이 "온라인 세상에 대한 인식"이 -- 물론 온라인상에 있을 때의 순간적인 것이지만 -- 그 윈도우크기에 의해 받는 영향에 차이가 있는 것같다. 이 세계가 마치 전부이거나 절대적인 양 매우 크게 느껴지거나 아님 별로 중요하지않고 현실적인 영향력이 없는 매우 상대적인 것으로 느껴지는 정도, 즉 "상대성의 인식"에 차이를 준달까. --우산
음.. 그런 느낌이 들기도 하군요.. 
지원은 개인적으로 윈도우를 최대화 하는 것을 매우 싫어하며 불안해하기 까지 합니다. (왜 그런지는 잘 모르겠지만요..) 따라서 큰 윈도우가 필요하다면 최대화를 하지 않고 전체 화면의 90%되는 정도의 크기로 윈도 크기를 조정합니다. (노트북을 사용할 때에는 할 수 없이 최대화 기능을 사용하기는 합니다.) .png ";)")
오..그러시군요. 근데 전체 화면의 90%로는 어떻게 조절하는 건가요? 난 그냥 컴터 지가 알아서 크고 작게 해주는 것 밖엔 몰르는데... --우산 지원은 개인적으로 윈도우를 최대화 하는 것을 매우 싫어하며 불안해하기 까지 합니다. (왜 그런지는 잘 모르겠지만요..) 따라서 큰 윈도우가 필요하다면 최대화를 하지 않고 전체 화면의 90%되는 정도의 크기로 윈도 크기를 조정합니다. (노트북을 사용할 때에는 할 수 없이 최대화 기능을 사용하기는 합니다.) 그냥 윈도우 모서리를 끌어서 적당히 90%로 조절하는 거 말한 거에요.. ^^;;; --지원
음.. 해보니까 정말이지 윈도우를 화면 꽉 차게 해놓는 것보다는 90% 정도되는 윈도우크기가 괜찮은 것같네요. --우산MS Windows 특유의 '전체화면' 인터페이스를 만들어낸 장본인은 바로 화면 하단의 '작업표시줄'이다. Windows95 이전의 GUI 인터페이스에서는 '작업표시줄'과 같은 인터페이스가 발달하지 않았다. 화면 전환은 애플리케이션 단위로 이루어지는 것이 일반적이었고, 서로 다른 애플리케이션 사이의 원활한 Copy&Paste를 위해 창의 크기를 전체화면으로 키우지 않았다. Windows95가 널리 쓰이던 무렵, 대부분의 이용자는 800*600의 15인치 모니터를 쓰고 있었고, Windows95는 다른 OS에 비해 서체의 크기가 매우 큰 편이었다. Macintosh의 12point서체가 실제로 12pixel을 차지하는 것과 비교해 보라. 72dpi(dots per inch) 규칙을 지킴으로 WYSIWYG의 표준을 지키던 Mac과는 달리, Windows95는 미려한 화면 서체를 위해 전반적인 해상도를 높이게 되었고, 이용자들은 800*600 화면을 가득 메운 창에서 A4 용지의 가로편집길이를 맞출 수 있었다.
표준적인 오브젝트 지원, 다양한 애플리케이션간의 Copy&Paste, Drag&Drop를 충분히 지원하지 못한 MS Windows는 서로 다른 여러 애플리케이션을 활용하여 하나의 문서를 만드는 방식대신, 하나의 애플리케이션만으로 문서를 완성하도록 유도하게 되었고, 이용자들은 창을 전체화면으로 띄우면서도 불편함이나 어색함을 못 느끼게 되었다.
17", 19" 모니터가 일반화되는 요즘에는 창크기를 전체화면에 맞추는 것보다 800*800 정도의 크기에 맞추는 것이 웹사이트를 예쁘게 보고 문서를 편하게 작성하는데 도움이 된다. --Aragorn
표준적인 오브젝트 지원, 다양한 애플리케이션간의 Copy&Paste, Drag&Drop를 충분히 지원하지 못한 MS Windows는 서로 다른 여러 애플리케이션을 활용하여 하나의 문서를 만드는 방식대신, 하나의 애플리케이션만으로 문서를 완성하도록 유도하게 되었고, 이용자들은 창을 전체화면으로 띄우면서도 불편함이나 어색함을 못 느끼게 되었다.
17", 19" 모니터가 일반화되는 요즘에는 창크기를 전체화면에 맞추는 것보다 800*800 정도의 크기에 맞추는 것이 웹사이트를 예쁘게 보고 문서를 편하게 작성하는데 도움이 된다. --Aragorn
(1) Windows 95에서부터 등장한 작업표시줄은 각 어플리케이션을 전체화면으로 쓸 때 확실히 편리합니다만. 이것이 전체화면 선호의 직접적인 이유라고 보이지는 않습니다. 오히려 Windows 3.1 당시에 전체화면을 선호하는 사용자들이 많이 있었기 때문에 이들을 위한 하나의 편리한 도구로서 고안된 훌륭한 아이디어였다고 봅니다.
'작업표시줄'은 당시로서, 그리고 지금도 상당히 좋은 인터페이스라고 생각합니다. 윈도우크기문제에 있어서는 전체화면을 쓰는데 불편없이 만들어준 일등공신이기도 하고요.
(2) 화면 해상도에 있어서는, 기술의 발달에 따라서 고해상도가 가능해진 것에 불과하며 72dpi가 WYSIWYG의 표준인데 윈도우즈가 이것을 어기기 시작했다고 보는것은 무리가 있다고 봅니다.당시 출판업계의 표준은 Mac의 DTP환경이었다고 생각하기에 그렇게 표현한 것입니다. 해상도가 높아지면서 기준이 바뀌는 건 당연한 것이겠고요.
(3) 표준적인 오브젝트 지원은 의미하신바를 잘 모르겠지만 Windows 3.1 시절부터 등장했던 OLE 라는 개념과 다른것인지요? 또한 Windows 3.1 시절에도 Copy&Paste, Drag&Drop은 매킨토시와 별 차이 없는 수준으로 지원되고 있었다고 봅니다.OLE는 3.1시절부터 있었지만, 실제 여러 애플리케이션의 쓰임새에서 Copy&Paste, Drag&Drop이 매끄러운 건 아니라고 생각합니다. 정도의 문제이긴 하나, 지금의 Win2K에서도 Copy&Paste, Drag&Drop은 상당히 조악한 수준입니다. MS Office에서는 그나마 애플리케이션간에 원활히 데이터를 교환할 수 있지만, 다른 애플리케이션과는 거의 데이터를 공유할 수 없고, Copy&Paste는 대부분 텍스트에 한정됩니다. 심지어 기본 번들로 제공되는 그림판의 클립보드도 많은(MS Office이외의 대부분) 애플리케이션으로 가져갈 수 없습니다. Drag&Drop은 더 못한 수준이고요. 이는 표준을 만들어 놓고 개발자들에게 이것을 유도하고 강요하지 못한 MS의 잘못이라고 생각합니다.
(4) Windows 에서 전체화면이 널리 쓰이게 된 것은 다만, 마이크로소프트가 전체화면 모드를 위한 사용자 인터페이스를 지나치게 (?) 편리하게 만들었기 때문이라고 생각합니다. 윈도우 타이틀바를 더블클릭하거나 전체화면 버튼을 누르기만 하면 전체화면이 되는 것이고, 전체화면모드의 어플리케이션 간 전환은 alt-tab 키이나 작업표시줄을 이용해서 간단하게 할 수 있으니까요. 다른 이유는 없다고 봅니다.전체화면 인터페이스를 유도하지 않는 MacOS에서는 타이틀바를 더블클릭하면 창의 몸통이 말려올라가서 휙 사라지는 인터페이스를 제공하는데 Windows에서는 전체화면으로 커지게 되지요. 제 생각도 아무개? awknn?님과 마찬가지로 전체화면을 위한 지나치게 편리한 인터페이스가 그 장본인이라는 것이고, 그 중 일등공신이 '작업표시줄'이라는 것입니다. 작업표시줄 없이 alt-tab만으로는 실제 쓰는데 문제가 많습니다. 작은 아이콘만으로는 원하는 창을 선택하기 힘들고, 진짜 초보자들은 alt-tab과 같은 단축키 쓰기를 꺼려하지요.
전체화면이란건 사용자 취향의 문제라 할수 있겠습니다만, CopyAndPaste나 DragAndDrop은 확실히 문제가 있습니다. OLE라는 개념을 내놓았지만 그것 역시 엠에스 제품말고는 거의 쓰이질 않았고, 맥에서의 CopyAndPaste 나 DragAndDrop 은 윈도우와는 전혀 다르다고 봅니다. 서로 다른 회사들의 애플리케이션에서 대부분의 프로그램들이 자연스럽게 CopyAndPaste 나 DragAndDrop 이 됩니다. 특히나 그 유연함이란 윈도우와는 비교가 안된다고 생각합니다. OLE라는 것 역시도 맥에서의 '출판'(확실하게 기억이 안나는군요)이라는 것에서 온걸로 알고 있습니다. 맥 광신자도 아니고 추종자도 아니지만 윈도우가 따라오지 못하는 그 무엇때문에 계속 쓰게되는것 같습니다.
CopyAndPaste나 DragAndDrop은 확실히 문제가 있습니다. OLE라는 개념을 내놓았지만 그것 역시 엠에스 제품말고는 거의 쓰이질 않았고, 맥에서의 CopyAndPaste 나 DragAndDrop 은 윈도우와는 전혀 다르다고 봅니다. 서로 다른 회사들의 애플리케이션에서 대부분의 프로그램들이 자연스럽게 CopyAndPaste 나 DragAndDrop 이 됩니다. 특히나 그 유연함이란 윈도우와는 비교가 안된다고 생각합니다. OLE라는 것 역시도 맥에서의 '출판'(확실하게 기억이 안나는군요)이라는 것에서 온걸로 알고 있습니다. 맥 광신자도 아니고 추종자도 아니지만 윈도우가 따라오지 못하는 그 무엇때문에 계속 쓰게되는것 같습니다.{{{ }}} 로 묶인 인용구는 자동 줄바꿈이 되지 않으나, {{| |}} 를 쓰면 자동 줄바꿈을 지원한다.
{{{ {{| {{{ 내용 }}｝|}} }}} 의 경우에는 자동 줄바꿈이 되지 않는다.
{{{ {{{ {{| 내용 |}} }}｝}}} 의 경우에는 {{{ {{| 내용 |}} }}}이 보인다.
{{{ {{| {{{ 내용 }}｝|}} }}} 의 경우에는 자동 줄바꿈이 되지 않는다.
{{{ {{{ {{| 내용 |}} }}｝}}} 의 경우에는 {{{ {{| 내용 |}} }}}이 보인다.
이건 뭐죠?