User Interface :
{{|
인간과 기계의 중첩 현상을 인식하기 위해 사회적 지형을 뒤져보는 또 하나의 유력한 전략은 '인터페이스Interface'라는 개념을 검토하는 것이다. 잠정적으로 우리는 인터페이스가 인간과 기계 사이에 위치하는, 이질적이고 독립적인 두 세계를 서로 분할하면서 동시에 연결시켜주는 일종의 막이라고 할 수 있을 것이다. DOS 인터페이스의 이용자들이 불평하듯이 인터페이스는 특성상 기계에서 나왔을 수도 있으며, 매킨토시 인터페이스의 지지자들이 주장하듯이 인간 쪽에서 나왔을 수도 있으며, 또는 양쪽 모두에서 똑같은 비율로 흘러나왔을 수도 있다. 기계의 인터페이스는 (냉장고의 경우처럼) 누구에게나 분명할 수도 있으며, (전기공구의 경우처럼) 초심자들에게는 불명료할 수도 있다. 컴퓨터와 같은 재현 기계가 등장함에 따라 인터페이스의 문제가 부각되기 시작했다. 왜냐하면 그와 함께 인간/기계의 분할선 바깥에 있는 양쪽이 모두 자신의 고유한 리얼리티를 주장하기 시작했기 때문이다. 스크린의 한 쪽은 뉴튼적 공간이며, 다른 쪽은 사이버공간Cyberspace인 것이다. 고품질 인터페이스는 두 세계를 꿰맨 흔적도 없이 봉합시키며, 그로써 둘 사이의 결합 유형을 바꾸는 것은 물론이고, 그 차이의 소멸을 촉진시킨다. 인터페이스란 인간과 기계 사이의 새로운 관계축일 뿐만 아니라 인간과 기계 사이의 협상이 벌어지는 민감한 경계 영역이다.
|}}
비행 시뮬레이션과 오락실게임 에뮬레이터는 그 좋은 예라고 볼 수 있습니다. --독거총각
{{|
인간과 기계의 중첩 현상을 인식하기 위해 사회적 지형을 뒤져보는 또 하나의 유력한 전략은 '인터페이스Interface'라는 개념을 검토하는 것이다. 잠정적으로 우리는 인터페이스가 인간과 기계 사이에 위치하는, 이질적이고 독립적인 두 세계를 서로 분할하면서 동시에 연결시켜주는 일종의 막이라고 할 수 있을 것이다. DOS 인터페이스의 이용자들이 불평하듯이 인터페이스는 특성상 기계에서 나왔을 수도 있으며, 매킨토시 인터페이스의 지지자들이 주장하듯이 인간 쪽에서 나왔을 수도 있으며, 또는 양쪽 모두에서 똑같은 비율로 흘러나왔을 수도 있다. 기계의 인터페이스는 (냉장고의 경우처럼) 누구에게나 분명할 수도 있으며, (전기공구의 경우처럼) 초심자들에게는 불명료할 수도 있다. 컴퓨터와 같은 재현 기계가 등장함에 따라 인터페이스의 문제가 부각되기 시작했다. 왜냐하면 그와 함께 인간/기계의 분할선 바깥에 있는 양쪽이 모두 자신의 고유한 리얼리티를 주장하기 시작했기 때문이다. 스크린의 한 쪽은 뉴튼적 공간이며, 다른 쪽은 사이버공간Cyberspace인 것이다. 고품질 인터페이스는 두 세계를 꿰맨 흔적도 없이 봉합시키며, 그로써 둘 사이의 결합 유형을 바꾸는 것은 물론이고, 그 차이의 소멸을 촉진시킨다. 인터페이스란 인간과 기계 사이의 새로운 관계축일 뿐만 아니라 인간과 기계 사이의 협상이 벌어지는 민감한 경계 영역이다.
|}}
-『제2미디어 시대』, 마크 포스터, 민음사
재현 기계가 simulation(혹은 시물라르크 어쩌구)인지 emulation인지 궁금해지네요.
구분하기가 모호하지만, Simulation과 Emulation 둘 다 현실세계에선 이룰 수 없거나, 막대한 비용과 시간이 드는 것을 가상의 세계에서 재현한다는 점에서는 일치한다고 봅니다. 사전적 의미로도 동의어로 분류되어 있습니다. 그러나, 프로그래머의 시각에서 보면 둘은 분명한 다른 점이 있습니다. Simulation은 현실세계를 가상의 세계에 반영하는 것에 중점을 두고 있으며, 이는 조금 더 인간과 밀접한 인터페이스의 개발이 중요하다고 봅니다. 반면에, Emulation은 가상의 세계의 것을 가상 공간에 다시 구현하는 것이라고 보시면 됩니다. 따라서, 인간과의 인터페이스는 이미 정의되어 있으며 중심이 되는 것은 기계와의 인터페이스를 어떻게 거의 같은 기능을 구현할 수 있는가에 중점을 둔다고 생각이 듭니다.재현 기계가 simulation(혹은 시물라르크 어쩌구)인지 emulation인지 궁금해지네요.
엄밀한 정의라고 할 수는 없겠지만, 시뮬레이션이라고 하면 실재를 흉내내는 허구이고, 에뮬레이션이라 하면 허구를 통해 실재에 영향을 미치는 것으로 이해했습니다. 비행 시뮬레이션은 단지 비행 경험을 흉내내지만, 터미널 에뮬레이션은 터미널이 아니면서 터미널이 수행하는 그것을 정확히 수행하지 않습니까. 예를 들어 플래시 장난으로 윈도 터미널을 만들어 속인다면 그것은 시뮬레이션이 되는 것일테고, Wine, VirtualPC 등과 같이 OS가 하는 모든 일을 정확히 한다면 에뮬레이션이 되는 그런 차이 아닐까 싶습니다. 이런 구분이 어원이나 권위있는 참조물을 통해 나온 것이 아니라, 유추에 의해 얻어진 것이라는 문제가 있군요. --nohmad
비행 시뮬레이션과 오락실게임 에뮬레이터는 그 좋은 예라고 볼 수 있습니다. --독거총각
UI의 본과 말 ¶
본인은 겉으로만 그럴싸한 GUI 프로그래밍(GUIP)을 두고, GUIP ,즉 "그래도 우린 이쁘잖아요"(Great Until Into Practice사용하기 이전까지는 멋져 보이는)라는 표현을 쓴다. 요즘의 UI는 한마디로 유저에 대한 강압이고 심미적 고문이다. 그야말로 현란한 이미지들이 춤을 추는 시각 박물관이 되어 버린 것이다. 우리는 또 그 "눈을 위한 축제" 속에서 허영과 춤을 추며 자기 기만을 반복하고 있다.
도대체 UI란 무엇이고 어떠해야 하는가는 생각을 해보았는가. "큰 배움"이라는 책, 《大學》의 "물건에는 근본(本)과 끝(末)이 있고, 일에는 처음(始)과 끝(終)이 있으니 먼저 하고 나중 할 바를 알면 곧 도에 가까운 것이다"는 말을 되새기자. 우리는 너무도 근본에 대한 고찰을 잊고 그 말엽에만 매달리고 있는 것은 아닐까.
알록달록한 색상과 우아한 곡선들이 빚어내는 기하학적인 도형의 심미감은 그 디자인을 직접 사용하는 순간 혐오감으로 바뀌어 버린다. 마음과 행동까지 이뻐야 미인인 것이다.
유저 인터페이스의 베스트셀러 작가 중 하나인 에버릿 맥케이의 말을 빌리자면, UI란 "프로그램을 사용하는 유저가 거치는 경험의 총체"를 말한다. 화면에 떠있는 다이알로그 박스나 아이콘의 그래픽 등 정적이고 고정되어 있는 외부실체가 아니다.
유저 인터페이스의 베스트셀러 작가 중 하나인 에버릿 맥케이의 말을 빌리자면, UI란 "프로그램을 사용하는 유저가 거치는 경험의 총체"를 말한다. 화면에 떠있는 다이알로그 박스나 아이콘의 그래픽 등 정적이고 고정되어 있는 외부실체가 아니다.
갑자기 눈앞에 나타나는 베르사유 궁전과 아홉 번의 궁궐을 거쳐야 나타나는 자금성은 단순히 그 형태만 다른 것이 아니고, 우리 느낌의 총체를 변화시키고 그 곳에 사는 사람을 성격을 변화시킨다. 우리가 어떤 건물을 경험하는 것은 단순히 건물 하나 하나의 존재적 가치를 경험하는 것이 아니고, 그곳에 가기 위해 길을 걷고, 건물에 들어가고 또 다시 그 건물을 돌아 나오는 일련의 전체, 그 변화를 체험하는 것이다. 그것은 하나의 스토리를 형성한다.
참고자료 ¶
UI와 GUI에 관한 구체적이고 실질적인 논의는 다음의 자료들을 참고하라:
먼저 실용주의적인 자료를 꼽아보자.
『Developing User Interfaces for Microsoft Windows』, Everett N. McKay, MS Press는 꼭 윈도우즈 환경에서만이 아니고 모든 플랫폼에 적용될 수 있는 실질적인 원칙들을 친절하게 설명하고 있다. 윈도우즈에서 GUI를 설계하는 사람들에게 꼭 추천한다.
매킨토시 GUI에 관련된 문서로는 Macintosh Human Interface Guidelines가 있다. 최근 출시된 Mac OS Ⅹ 관련 인터페이스 정보는 Mac OS X Human Interface Guidelines를 참고한다.
『GUI Bloopers』, Jeff Johnson, Morgan Kaufmann은 GUI에서의 실수(blooper)들을 실례들과 함께 설명하고 이유를 분석해 준다. 실질적인 GUI 가이드로 항상 추천되는 베스트셀러이다. 이 책의 홈페이지(http://www.gui-bloopers.com/ )에서도 많은 정보를 얻을 수 있다. 인터넷 치욕의 전당(Internet Hall of Shame, http://www.iarchitect.com/mshame.htm) 도 비슷한 내용을 다루지만 접근법은 약간 다르다. 시간이 날 때마다 가서 보고 느껴서 디자인 감수성을 살려 놓을 필요가 있다.
조금 이론적이고 사변적인, 그러나 아카데믹하진 않은 책으로는 애플 매킨토시 디자인 팀의 한명이었던 제프 라스킨의 『인간적인 디자인』, Jeff Raskin, Addison Wesley이 탁월하다. 이론만 나열하는 따분한 책은 절대 아니다. 이 책을 읽고 나면 UI를 보는 시야가 바뀔 정도로 매우 계발적인 책이다. 필자는 UI 전문가로 앞서의 라스킨과 제이콥 닐슨, 앨런 쿠퍼를 꼽는데 주저하지 않는다. 제이콥 닐슨은 최근 『Designing Web Usability』, Jakob Nielson, New Riders을 출판했다. 그이의 주장에 모두 찬동하는 것은 아니지만 인터넷의 UI에 대한 한 이만큼의 역작은 드물다고 본다. 그의 『Usability Engineering』, Jakob Nielson, Morgan Kaufmann은 좀 오래되긴 했지만 함께 짝을 이뤄 읽어볼만 하다. 전자가 웹에 관해 쓴 책이라면 후자는 UI 전반에 대한 책으로 유저빌리티 테스트 등에 대한 폭넓은 지식을 얻을 수 있다. 닐슨 역시 자신의 홈페이지(http://www.useit.com/ )에 자신이 쓴 기사를 주기적으로 업데이트하고 있다.
이 외의 분야에서는 도날드 노먼 박사의 책들을 추천한다. 어포던스 개념을 디자인에 처음 응용한 사람이다. 노먼 박사의 책들을 거의 대부분이 번역되어 있는데, 『디자인과 인간심리』(TheDesignOfEverydayThings), 『생각있는 디자인』 두권은 꼭 읽어보아야 할 책이다. 물론 재미도 있어서 밤을 새우게 만드는 책이다. 디자인 쪽에서는 에드워드 터프트의 연작이 필독도서이다. 정보를 어떻게 하면 더 효율적으로 시각화할 수 있는가에 대한 책으로 미국에서는 이미 고전이 된 베스트셀러들이다. 『TheVisualDisplayOfQuantitativeInformation』과 『Envisioning Information』, Edward R. Tufte, Graphics을 우선 읽어보길 권한다. 마지막으로, HCI(Human-Computer Interaction/Interface) 학계의 흐름을 알고 싶어하는 아카데믹한 사람들에게는 ACM의 인터액션즈 저널(http://www.acm.org/interactions/ )을 살펴보길 권한다.
"TheVisualDisplayOfQuantitativeInformation"는 웹디자인하는 분들에게 뿐만 아니라 quantitative analysis를 통한 경험적 연구를 하는 인문사회계열 공부하시는 분들에게도 큰 도움이 됩니다. 강추입니다. --우산
"Visual Explanations - Images and quantities, evidence and narrative(by Edward R. Tufte) 역시 다양한 분야의 디자이너 뿐만 아니라 효율적이고 신뢰로운 정보전달을 고민하는 분들에게 반드시 있어야할 책입니다. -- SJKim
Why is it that everything has to be embeded inside of everything else?를 보면 한 도큐먼트 안에 전혀 다른 형식의 도큐먼트를 박아놓는 것은 사용자가 프로그램의 기능을 쓰는데 혼란을 초래할 수 있다고 말하며 임베딩에 부정적인 입장을 취합니다. 사용자에게 혼란을 주지 않아야 한다는 관점에서는 현재의 임베딩이 잘못됐지만, 그저 '프로그램을 제대로 만들지 않아서' 혼란이 생기는 것일 수도 있을 거란 생각에 확신할 수가 없습니다.
이를 확장해보면, Macintosh에서 화면 맨위에 칸을 두어 활성화된 프로그램의 메뉴를 거기에 보이고 그 외에는 메뉴를 전혀 보이지 않는 것도 Integration을 살려서 사용자의 혼란을 줄이기 위한 방책일까요?
이 부분에 대해 권할 만한 책은 어떤게 있나요? AnswerMe --kz
이를 확장해보면, Macintosh에서 화면 맨위에 칸을 두어 활성화된 프로그램의 메뉴를 거기에 보이고 그 외에는 메뉴를 전혀 보이지 않는 것도 Integration을 살려서 사용자의 혼란을 줄이기 위한 방책일까요?
이 부분에 대해 권할 만한 책은 어떤게 있나요? AnswerMe --kz
Integration을 살려서 사용자의 혼란을 줄이기 위한 것이라고 맥 프로그래머들은 이야기합니다. 클래식 맥 OS의 툴박스나 Mac OS 10의 카본, 코코아 프레임워크에서 메뉴의 틀(이름, 순서, 배치 등)을 제공하기 때문에 응용 프로그램 개발자가 임의로 비틀지 않는 이상 사용자는 일관된 메뉴를 사용할 수 있게 됩니다.--아무개
MacOS의 화면 맨 위에 고정된 메뉴바가 나타나는 것을 두고 해석하기 나름이겠지만, Aragorn은 MacOS의 역사에서 비롯된 전통이라고 봅니다.
1984년 처음 출시된 초기의 MacOS는 동시에 여러 애플리케이션을 실행시킬 수 없었고, 여러 애플리케이션을 실행시킬 메모리 공간도 부족했습니다(128KB 정도의 메모리를 사용했으니 말입니다). 유저는 한번에 하나의 애플리케이션을 실행시켰고, 애플리케이션을 종료시키면 Finder라는 기본 데스크탑 화면으로 되돌아가는 방식이었습니다. Desktop Accessory라는 제한된 특수한 애플리케이션만 다른 애플리케이션의 실행 도중에 실행시킬 수 있었습니다. 이 때의 인터페이스도 지금과 비슷하게 화면 상단에 메뉴바가 나타나고 메뉴바의 제일 왼쪽에 애플메뉴라는 특수메뉴가 위치했습니다.
그러다 87년경(정확한 기억이..) MacOS 4,5 정도에서 처음으로 MultiFinder라는 개념이 소개되었습니다. MultiFinder에서부터 동시에 여러 애플리케이션을 실행시킬 수 있게 되었습니다. 그러나 한번에 하나의 애플리케이션만이 전면에 나타나고, 나머지 애플리케이션의 창은 모두 뒤에 감추어져 앞에 보이지 않는 방식이었습니다. MultiFinder가 쓰이게 되면서 clipboard가 더욱 중요해졌고, 애플리케이션을 전환하며 작업한 결과물을 잘라 붙이는 것이 가능해졌습니다. 그러나 기본적으로 MultiFinder의 장점은 덩치 큰 애플리케이션을 반복하여 실행,종료하지 않아도 된다는 점, 업무시간에 잠시 딴 짓을 할 수 있다는 점 정도였습니다.
92년경 MacOS 7이 출시되면서 많은 변화가 있었습니다. 이전에는 MultiFinder가 기본 설정이 아니었지만, MacOS 7부터는 MultiFinder만이 제공되었고(한번에 하나의 애플리케이션을 실행시킬 수 있는 예전 Finder는 사라졌습니다), 실행된 여러 애플리케이션의 창이 겹쳐져서 화면에 나타나게 바뀌었습니다. MacOS7 이전의 MultiFinder는 유저가 오른쪽 상단의 전환메뉴를 통해 foreground application을 직접 선택해야 하지만, MacOS7 부터는 뒤에 겹쳐서 나타나는 창을 선택하기만 하면 곧바로 애플리케이션 전환이 가능하게 된 것입니다.
이러한 변화의 와중에도 MacOS의 기본틀은 늘 변하지 않았고, 메뉴바는 항상 화면 상단 위치에 고정되어 나타납니다. MacOS에서는 MultiFinder라는 것이 수년간 사용되면서 메뉴바가 항상 같은 위치에 나타나는 것이 당연하게 생각되었고, 그 이후로도 이 전통이 굳어진 것이라고 생각됩니다. 이러한 고정위치 메뉴바가 항상 편리한 것은 아닙니다. 모니터 화면이 커지고, 다큐먼트 창을 여러개 띄워 동시에 작업을 진행하는 경우 실제 다큐먼트 창과 메뉴바가 너무 멀리 떨어져서 쓰기에 불편한 경우가 많습니다. 1280x1024 정도의 해상도에서 MacOS를 사용해보면 메뉴바가 멀어서 상당히 불편하다는 것을 금새 느낄 수 있습니다. 일반적인 맥유저들은 단축키를 모조리 외워서 이 문제를 해결합니다. MacOS의 큰 장점이 여러 애플리케이션의 단축키가 잘 통일되어 있어 외우기 좋다는 것이죠. --Aragorn
MacOS의 화면 맨 위에 고정된 메뉴바가 나타나는 것을 두고 해석하기 나름이겠지만, Aragorn은 MacOS의 역사에서 비롯된 전통이라고 봅니다.
1984년 처음 출시된 초기의 MacOS는 동시에 여러 애플리케이션을 실행시킬 수 없었고, 여러 애플리케이션을 실행시킬 메모리 공간도 부족했습니다(128KB 정도의 메모리를 사용했으니 말입니다). 유저는 한번에 하나의 애플리케이션을 실행시켰고, 애플리케이션을 종료시키면 Finder라는 기본 데스크탑 화면으로 되돌아가는 방식이었습니다. Desktop Accessory라는 제한된 특수한 애플리케이션만 다른 애플리케이션의 실행 도중에 실행시킬 수 있었습니다. 이 때의 인터페이스도 지금과 비슷하게 화면 상단에 메뉴바가 나타나고 메뉴바의 제일 왼쪽에 애플메뉴라는 특수메뉴가 위치했습니다.
그러다 87년경(정확한 기억이..) MacOS 4,5 정도에서 처음으로 MultiFinder라는 개념이 소개되었습니다. MultiFinder에서부터 동시에 여러 애플리케이션을 실행시킬 수 있게 되었습니다. 그러나 한번에 하나의 애플리케이션만이 전면에 나타나고, 나머지 애플리케이션의 창은 모두 뒤에 감추어져 앞에 보이지 않는 방식이었습니다. MultiFinder가 쓰이게 되면서 clipboard가 더욱 중요해졌고, 애플리케이션을 전환하며 작업한 결과물을 잘라 붙이는 것이 가능해졌습니다. 그러나 기본적으로 MultiFinder의 장점은 덩치 큰 애플리케이션을 반복하여 실행,종료하지 않아도 된다는 점, 업무시간에 잠시 딴 짓을 할 수 있다는 점 정도였습니다.
92년경 MacOS 7이 출시되면서 많은 변화가 있었습니다. 이전에는 MultiFinder가 기본 설정이 아니었지만, MacOS 7부터는 MultiFinder만이 제공되었고(한번에 하나의 애플리케이션을 실행시킬 수 있는 예전 Finder는 사라졌습니다), 실행된 여러 애플리케이션의 창이 겹쳐져서 화면에 나타나게 바뀌었습니다. MacOS7 이전의 MultiFinder는 유저가 오른쪽 상단의 전환메뉴를 통해 foreground application을 직접 선택해야 하지만, MacOS7 부터는 뒤에 겹쳐서 나타나는 창을 선택하기만 하면 곧바로 애플리케이션 전환이 가능하게 된 것입니다.
이러한 변화의 와중에도 MacOS의 기본틀은 늘 변하지 않았고, 메뉴바는 항상 화면 상단 위치에 고정되어 나타납니다. MacOS에서는 MultiFinder라는 것이 수년간 사용되면서 메뉴바가 항상 같은 위치에 나타나는 것이 당연하게 생각되었고, 그 이후로도 이 전통이 굳어진 것이라고 생각됩니다. 이러한 고정위치 메뉴바가 항상 편리한 것은 아닙니다. 모니터 화면이 커지고, 다큐먼트 창을 여러개 띄워 동시에 작업을 진행하는 경우 실제 다큐먼트 창과 메뉴바가 너무 멀리 떨어져서 쓰기에 불편한 경우가 많습니다. 1280x1024 정도의 해상도에서 MacOS를 사용해보면 메뉴바가 멀어서 상당히 불편하다는 것을 금새 느낄 수 있습니다. 일반적인 맥유저들은 단축키를 모조리 외워서 이 문제를 해결합니다. MacOS의 큰 장점이 여러 애플리케이션의 단축키가 잘 통일되어 있어 외우기 좋다는 것이죠. --Aragorn
User Interface 는 향후 10년간 유망한 분야라고 합니다 --yaliza
일할곳이 없는 분야다. --ripiki