MS-SQL에서 ALTER TABLE로 컬럼생성시 위치지정하기

MS-SQL에서는 위치지정 안된단다.

Enterprise Manager에서 직접 열을 추가하는 방법(1)과
임시로 컬럼을 추가한 table을 만들고 기존 데이터 옮긴다음에
기존 table은 drop하고 임시table을 기존 table이름으로 변경하는 방법(2)이 존재.

첫번째 방법으로 해결하는 수 밖에...

'개발' 카테고리의 다른 글

MSXML 6.0 DTD포함 문서 load() 실패문제  (0) 2008.12.18
simpleAdo 20081112b  (0) 2008.11.12
MS-SQL에서 ALTER TABLE로 컬럼생성시 위치지정하기  (0) 2008.11.12
파일 존재여부 확인  (0) 2008.09.11
Doxygen 및 HTML Help workshop 설치  (0) 2008.06.13
RTLS  (0) 2008.05.21

Trackbacks 0 / Comments 0

Leave Comments

파일 존재여부 확인

_access()함수를 이용하면 쉽게 파일 존재여부를 확인할 수 있습니다.









// compile with: /W1 // This example uses _access to check the file named // crt_ACCESS.C to see if it exists and if writing is allowed. #include <io.h> #include <stdio.h> #include <stdlib.h> int main( void ) { // Check for existence. if( (_access( "crt_ACCESS.C", 0 )) != -1 ) { printf_s( "File crt_ACCESS.C exists.\n" ); // Check for write permission. // Assume file is read-only. if( (_access( "crt_ACCESS.C", 2 )) == -1 ) printf_s( "File crt_ACCESS.C does not have write permission.\n" ); } }


'개발' 카테고리의 다른 글

simpleAdo 20081112b  (0) 2008.11.12
MS-SQL에서 ALTER TABLE로 컬럼생성시 위치지정하기  (0) 2008.11.12
파일 존재여부 확인  (0) 2008.09.11
Doxygen 및 HTML Help workshop 설치  (0) 2008.06.13
RTLS  (0) 2008.05.21
문서화 툴 리스트  (0) 2008.05.06

Trackbacks 0 / Comments 0

Leave Comments

Doxygen 및 HTML Help workshop 설치

아래와같은 순서로 설치하면 됩니다~
프로그램은 인터넷 검색하면 쉽게 구할 수 있습니다.

1. doxygen 설치
2. grapphivz 설치
3. HTML help workshop 설치

[HTML]
HHC_LOCATION 설정 : C:/Program Files/HTML Help Workshop/hhc.bat

[DOT]
DOT_PATH 설정 : C:/Program Files/Graphviz2.18/bin

[hhc.bat]
iconv -f UTF-8 -t CP949 index.hhc > index.cp949
del index.hhc
move index.cp949 index.hhc
"C:\Program Files\HTML Help Workshop\hhc.exe" "%1"


[DOXBAR 한글설정]
Tool-> Edit Project's profile
General options -> Doxyfile_encoding = EUC-KR
Input files -> Input_encoding = EUC-KR

'개발' 카테고리의 다른 글

MS-SQL에서 ALTER TABLE로 컬럼생성시 위치지정하기  (0) 2008.11.12
파일 존재여부 확인  (0) 2008.09.11
Doxygen 및 HTML Help workshop 설치  (0) 2008.06.13
RTLS  (0) 2008.05.21
문서화 툴 리스트  (0) 2008.05.06
자원이 사용중이고 NOWAIT...  (0) 2008.03.25

Trackbacks 0 / Comments 0

Leave Comments

RTLS

RFID의 대표적인 장점 중의 하나는 기업들에게 특정 지역과 특정 시간대에 특정 객체의 위치를 파악할 수 있도록 해준다는 것이다. 실시간 위치 추적 시스템인 RTLS(Real-time locating system)은 RFID를 활용하는 것으로, 무선 신호를 사용해서 태그가 부착된 객체에 전파를 보내 수신되는 위치를 실시간으로 제공한다. RTLS는 자산이나 사람들의 위치를 실시간으로 추적할 수 있는 자동화된 방법을 제공할 수 있다는 것이 입증되면서 의료 기관이나 물류 및 제조 등과 같은 업계에서 도입이 활성화되고 있는 추세이다. 미국의 군대에서는 트럭의 출입 등 이동 상황을 모니터링하기 위해 RTLS를 사용하고 있다. 여기에서는 RTLS 제품 도입시 고려해야 할 중요한 요인들을 제시해본다.

이 같은 자동화된 시스템은 추적 대상에 부착되는 RFID 태그(최근 일부 패시브 태그가 포함되어 있지만 일반적으로는 액티브 태그(배터리로 전원이 공급되는 형태))와 창고나 병원 등 특정 지역에 위치해 추적 대상의 위치를 확인하는 RFID 리더(리시버나 액티베이터로도 불림), 추적 애플리케이션 소프트웨어 등으로 구성된다. RTLS를 지지하는 사람들은 이 기술이 적외선이나 바코드, GPS 등 다른 위치 추적 시스템에 비해 장점이 크다고 주장한다. 예를 들어, RTLS는 적외선보다 유지 보수의 필요성이 적고 바코드 시스템처럼 판독 대상이 육안으로 보이지 않아도 된다.

RTLS시장, 2011년에 12억6,000만 달러에 달할 것
RTLS에 대한 개념이 등장한지는 10년이 넘었지만 시스템 상호운용성을 위한 표준화가 아직 확정되지 않고 있다. 이로 인해 기업들은 공급망에 대한 정보를 공유하기가 어려웠다. 물류 센터로 입고되는 전세계 선적 물품 등 공급망 애플리케이션을 위해 RTLS 도입을 고려하고 있다면 다양한 주파수와 프로토콜을 지원하는 하드웨어를 구매해야 하는 이유가 여기에 있다.

자동 신원확인 및 데이터 수집 전문 컨설팅 업체인 하이 테크 에이드(High Tech Aid)의 스티브 할리데이 설립자에 따르면, RTLS와 관련되어 있는 대표적인 업계 표준은 ANSI INCITS 371과 ISO 24730이다. 미국의 표준화 기관인 ANSI가 제정한 ANSI INCITS 371은 무선 인터페이스 프로토콜과 애플리케이션 프로그래밍 인터페이스를 규정하고 있다. 다양한 RTLS 벤더의 제품간 상호운용성을 보장하기 위해 마련된 것이다. 국제 표준화 기구인 ISO가 발표한 ISO 24730의 경우는 RTLS용 무선 인터페이스 프로토콜과 로케이션 알고리즘을 다루고 있다.

또 다른 문제는 RTLS 태그의 비용이다. 아직 너무 고가이기 때문에 저가 상품이나 자산 추적에는 적합하지 않다. 리더 가격의 경우 500달러에서 수천 달러에 달한다. 물류 집하장과 같이 넓고 개방된 지역을 커버해야 하지는 않지만 복도와 사무실이 많은 빌딩을 커버해야 할 경우 설치해야 하는 장비 대수도 만만치 않다.
시장 조사 업체인 프로스트&설리번에 따르면, 이러한 난제에도 불구하고 전세계 RTLS 시장은 2006년 2억4,500만 달러 규모에서 2011년에 이르면 연평균 성장률 30%를 기록하면서 12억6,000만 달러에 달할 것으로 전망된다. 표에서 보듯이 RTLS를 제공하는 업체들마다 다양한 스펙을 보유하고 있어 제품 선택이 쉽지 않다. 여기에서는 RTLS 제품 도입시 고려해야 할 중요한 요인들을 제시해보고자 한다.

RTLS의 작동 방법은?

RTLS는 여러 종류의 액티브 태그와 위치 계산 방법을 사용해 다양한 방식으로 구동한다. 일부 시스템의 경우 몇 초나 몇 분 단위로 신호를 송출하는 비콘(beacon) 태그를 사용한다. 일반적으로, 사용자가 배터리 전원을 보전하거나 자산의 이동 순간마다 가시성을 높이는 등 우선 순위에 따라 간격을 조절할 수 있다. 몇 초 단위로 설정할 경우 상품의 이동에 대한 가시성을 높일 수는 있지만 배터리 수명이 단축된다.
대부분의 RTLS는 자산의 위치를 파악하기 위해 삼각측량(triangulation) 기술을 사용한다. 리더에 신호가 도달하는데 걸린 시간이 객체의 위치를 판단하는데 사용된다. 이러한 시스템 유형은 추적 대상의 위치 오차 범위가 3m 내외로 매우 정확하다.

일부 시스템의 경우, 객체에 태그를 부착할 경우 소프트웨어를 통해 특정 물품의 이동 경로를 추적하는데 효과적으로 사용된다. 몇몇 RTLS는 복도나 천장에 숨겨진 안테나를 통해 구동하기 때문에 장비의 도난이나 훼손으로부터 보호될 수 있다. 이러한 은폐된 안테나는 빌딩 내부의 미학적인 측면에도 도움이 된다.
일부 벤더들은 다양한 요구 사항에 맞출 수 있는 여러 RTLS 제품들을 판매하고 있다. 예를 들어, 아이덴텍 솔루션즈(Identec Solutions)의 한 시스템의 경우 비콘 태그 구조를 도입했으며 특정 객체의 정확한 위치가 필요치 않아도 되는 분야에 맞도록 개발되었다. 또한 이동 속도가 비교적 느린 객체 추적에 적합하다. 아이덴텍은 여러 객체 중 특정한 객체 하나만 위치를 파악할 수 있도록 해주는 반응 태그(response-tag) 구조도 제공한다. 이러한 태그는 농기계나 항공, 자동차, 중장비 등 일부 제조 업체에서 컨테이너와 같이 완제품 및 자산을 추적하고 관리하는데 특히 적합하다.

훨씬 높은 수준의 정확도를 제공하는 시스템도 있다. Parelec의 iLocate RTLS는 추적 대상의 오차 범위가 30cm 내외에 불과하다. 이 태그가 '옵티컬 위치 모드'로 전환될 경우 매우 높은 정확도를 제공할 수 있다. 추적 지역에 설치된 옵티컬 리더에 의해 신호가 수신되며 iLocator 서버가 이를 처리한다.
일부 RTLS 제품은 고정형 리더기가 아닌 위치 인식 모바일 리더를 사용해 데이터를 수집한다. 이러한 형태의 시스템은 필요시 리더를 이동시킬 수 있기 때문에 고정형 시스템보다 훨씬 비용 효과적이라 할 수 있다.
다양한 추적 기능이 필요한 기업이라면 좀더 많은 기능을 제공하는 RTLS를 원하게 될 것이다. RF Code의 RTLS 플랫폼은 지역 추적, 모바일(휴대용) 옵션, 적외선 추적을 비롯해, 객체의 정확한 위치를 계산하기 위해 여러 대의 리더기를 사용해 최고의 해상도를 제공하는 알고리즘적인 추적 등 기업이 요구하는 환경에 따라 선택할 수 있는 네 가지 접근 방식을 채택했다.

업종에 특화된 시스템이 필요한가?

특정 업종의 애플리케이션과 설비를 지원하도록 개발된 소프트웨어를 통해 시스템을 맞춤화한 벤더들도 있다. 선적 회사를 위해 개발된 WhereNet 시스템의 경우 선박 터미널 애플리케이션에 특히 적합한 소프트웨어를 함께 제공하고 있다.
Axcess International은 보안 업계를 위한 소프트웨어 개발에 다년간의 경험을 보유하고 있다. 이 회사의 RTLS용 주요 애플리케이션은 자산 관리와 제어를 위해 사람들과 자산을 연결해준다.
Parco Merged Media의 경우, Precis라는 브랜드 제품을 출시했는데, 이 제품은 의료 분야에 초점을 맞추고 있다. Hospital Grade Wireless 시스템의 경우 병원에서의 데이터 송수신용으로 개발되었다.

시스템이 사용하는 태그 유형은?

상당수 RTLS 제품들은 커버리지의 확대를 위해 액티브 RFID 태그를 사용하고 있지만 객체의 위치 추적을 위해 패시브 태그를 사용하는 비중도 꾸준히 늘어나고 있다. 일반적으로 액티브 태그에 비해 가격이 저렴한 패시브 태그는 넓은 범위의 커버리지가 필요하지 않은 경우에 사용될 수 있다. 패시브 태그를 사용하는 RTLS 중에는 창고와 같은 곳에서 이동이 가능한 모바일 리더를 포함하고 있는 제품도 있다.
일부 시스템의 경우 액티브와 패시브 태그를 둘 다 사용하기도 한다. PanOS 플랫폼이라 불리는 PanGo Networks의 제품에는 2.4GHz 대역의 주파수에서 구동하며 Wi-Fi나 비콘 모드에서 위치와 상태를 추적할 수 있는 액티브 RFID 태그가 포함되어 있다. 또한 PanOS는 패시브 RFID의 '초크(choke)' 포인트와 같은 소스로부터 위치 정보를 수집할 수 있어, 기업의 요구 사항에 따라 액티브와 패시브 위치 기술을 적절히 혼합해 선택할 수 있도록 해준다.

시스템 도입을 고려하는데 있어서 액티브 태그의 수명은 가장 중요하게 생각해야 할 부분이다. 교체할 때까지 얼마나 오랫동안 태그가 운영될 수 있는지, 태그를 자주 교체하는 것이 얼마나 효과적일지 등을 충분히 감안해야 한다. 최대 7년까지도 배터리 수명이 유지되는 액티브 태그 제품도 있지만 대부분은 4년 정도 지속된다.

또 다른 태그 관련 고려 사항은 신호의 주파수이다. 커버리지가 낮은 애플리케이션을 위해 태그가 저대역 신호를 보내는지, 넓은 커버리지를 위해 더 높은 주파수 대역에서 구동하는지 알아야 한다. Parco측은 여러 주파수 대역에서 구동해야 할 경우 '하이브리드' 태그가 적합하다고 언급했다.
기업들은 위치뿐만 아니라 움직임이나 온도 센서 등을 통해 관련 정보를 제공하는 태그를 고려할 수도 있다. 예를 들어, PanGo의 RTLS 제품에 포함된 태그는 움직임이 있을 때 이를 알려주는 움직임 탐지 기능을 보유하고 있으며 객체가 정지해 있을 때나 움직일 때, 또는 움직이다가 정지할 때마다 다른 신호를 보내준다.

필요한 커버리지 범위는 어느 정도인가?

RTLS의 도입을 고려할 때 중요한 또 다른 요인은 추적 대상의 커버리지 범위이다.
다양한 커버리지를 동시에 제공하는 시스템도 있다. Axcess의 ActiveTag RTLS는 사용자들이 이 시스템의 Activator 트랜스미터의 출력을 조절해서 커버리지를 반경 수십 센티미터에서 수백 미터로 확대하거나 줄일 수 있게 해준다.

환경은 어떠한가?

AeroScout와 같은 제품군처럼 일부 시스템의 경우 실내나 실외 환경 모두에서 똑같이 원활하게 구동하도록 개발되었다. 다른 제품들은 실내나 실외 둘 중 한곳에서만 구동하도록 제공된다. 실외용 시스템은 온도나 기후가 변화하더라도 원활하게 작동되어야 한다. 또한 RTLS 기술이 차량의 이동 시에도 성능을 발휘할 수 있는지, 또는 금속성 물체가 있더라도 신호 송수신에 영향을 받지 않는지의 여부를 확인해야 한다.
WhereNet측은 자사의 RTLS가 물이나 금속에 덜 민감하다고 밝히고 있다. 이 시스템은 광역 기술과 더불어 GPS에서 사용되는 방법과 같이 신호의 서로 다른 도착 시간을 사용해 위치를 계산하기 때문에 열악한 환경이나 산업 단지에서도 최적의 성능을 발휘한다는 것이다.

RTLS가 기존의 시스템과 연동하는가?

공급망이나 자산 관리 소프트웨어 등 기존의 기업용 애플리케이션과 RTLS가 얼마나 효과적으로 연동할 수 있는지는 시스템 선택시 고려해야 할 또 다른 중요한 항목이다. RTLS 벤더가 개방형의 표준 기반 아키텍처를 제공한다면 통합 프로세스가 한결 용이해질 수 있다.
특정 업종을 전문으로 하고 있는 일부 벤더들은 RTLS 제품과 업계 애플리케이션을 통합할 수 있도록 지원하는 툴을 제공하고 있다. Parco의 경우 많은 미국 병원에서 사용되고 있는 애플리케이션과 자사의 시스템을 완벽히 통합해주는 소프트웨어를 제공한다.

시스템이 Wi-Fi와 호환되는가?

많은 RTLS 제품들이 Wi-Fi 네트워크로 알려진 802.11 무선랜 통신 표준을 지원하고 있다. 태그가 Wi-Fi 네트워크와 커뮤니케이션할 수 있는 것이다. 이러한 점은 현재 무선랜을 도입했거나 할 계획인 기업들에게는 매우 중요한 고려 사항이다.
Ekahau측은 자사의 RTLS 제품은 벤더와 상관 없이 모든 802.11 네트워크와 완벽히 호환되며 고객의 기존 Wi-Fi 네트워크에서 사용되는 하드웨어에 추가로 장비를 도입할 필요가 없다고 밝혔다.
Wi-Fi 네트워크에서 구동하는 시스템을 선택할 경우, 대역폭 사용량을 검토해보아야 한다. 일부 시스템의 경우 Wi-Fi나 이더넷 백본을 조금만 사용하도록 개발되어 있어 다른 네트워크에 별다른 영향을 끼치지 않는다.

가격은 적당한가?

RTLS 패키지는 가격이 비싼 편이다. 태그 자체의 가격만도 기본 제품의 경우 10달러 선이며 센서가 포함된 정교한 제품의 경우에는 200달러까지 나간다. 또한 리더 가격의 경우에도 500달러 정도에서부터 수천 달러까지 다양하게 가격이 형성되어 있다. 구축 규모나 필요한 태그의 수에 따라, RTLS 구축 비용은 10만 달러 이하일수도, 2백만 달러를 넘을 수도 있다.
일부 벤더들의 경우 프로젝트 규모에 따라 시스템 가격을 책정하고 있다. RF Code의 RTLS 제품은 고객에 따라 가격이 달라진다. 태그를 대량으로 구매할 경우 10달러 이하에서 제공되지만 RTLS의 토털 가격은 고객의 운영 환경과 아키텍처에 따라 결정된다.
또 다른 비용 관련 고려 사항은 유지 보수 및 지원에 대한 연간 비용이다. 제품을 평가할 때에는 벤더에게 소프트웨어와 하드웨어 운영을 효과적으로 유지하는데 얼만큼의 비용을 지불해야 하는지를 물어보아야 한다.

마지막으로, RTLS 도입에 관심을 갖고 있는 기업이라면 향후 요구 사항에 대해서도 고려해야 한다. RTLS 도입을 확장해나갈 계획이라면 시스템의 확장성을 생각해야 한다.

출처 :RFID 저널 코리아
 http://www.rfidjournalkorea.com/news/quickViewArticleView.html?idxno=6977

'개발' 카테고리의 다른 글

파일 존재여부 확인  (0) 2008.09.11
Doxygen 및 HTML Help workshop 설치  (0) 2008.06.13
RTLS  (0) 2008.05.21
문서화 툴 리스트  (0) 2008.05.06
자원이 사용중이고 NOWAIT...  (0) 2008.03.25
응용 프로그램을 위한 최상의 사용자 환경을 만드는 방법  (0) 2008.02.26

Trackbacks 0 / Comments 0

Leave Comments

문서화 툴 리스트

개발된 프로젝트의 문서화를 위한 tool 리스트 입니다.
저는 주로 doxygen을 이용합니다만 상당히 많은 documentation tool이 존재하네요..

Documentation Tools

These tools can be used to generate documentation for your code of interest. For keeping documentation optimally linked with source code, we recommend using CodeAssets.

For a more complete website dealing with summaries of documentation tools, code beautifiers, repositories, website organizers, etc., go to CodeOrganizer.com.

Name

Description and Comments

Output

Platforms Supported

Languages Supported

Formatting Codes

AutoDOC

An application to convert specially formatted documentation embedded into tcl code into a cross-referenced set of HTML pages describing this code

HTML

Any platform that runs Tcl (Windows, Unix, Mac)

Tcl/Tk

 

AutoDuck

Created by Microsoft employee but not a Microsoft supported product.

HTML,RTF

Windows

C++, Visual Basic

 

Cocoon

The Cocoon utilities process C++ include files and produce a net of relocatable web pages that document the libraries, classes, and global functions and types that are found in them. Cocoon relies on a small set of simple formatting conventions in the header files.

HTML w/Frames

 

C++

Classes: /*... */
Keywords like HEADING, KEYWORDS, LOG

CcDoc

Created with idea of using same doc standards with java and C++

HTML

 

C++

like javadoc

Cxref

Produces documentation (in LaTeX, HTML, RTF or SGML) including cross-references from C program source code. No plans for a C++ version.

LaTex, HTML,RTF, SGML

Unix, Windows

C

 

cxxwrap

Produces HTML output, JNI (Java Native Interface) headers.

HTML w/Frames, looks most like javadoc 2.0 output of any C++ doc program

Unix, Windows

C++

like javadoc

Cxx2HTML

Written for the AIPS++ project at the National Radio Astronomy Observatory

HTML

Any platform that runs Perl 5

C++

# in comments, Keywords such as <synopsis>, <srcblock>

C2HTML

C2HTML is a software dedicated to maintain C written programs. It runs with DOS/Windows.

HTML w/Frames

 

 

 

Doc++

DOC++ is a documentation system for C, C++, IDL and Java generating both TeX output for high quality hardcopies and HTML output for sophisticated online browsing of your documentation. The documentation is extracted directly from the C/C++/IDL header/source files or Java class files.

HTML w/Frames, LaTex

Linux, Solaris, FreeBSD, AIX, BeOS, HP/UX Windows 95/98/NT/2000,

C, C++, IDL, Java

 

DOxygen

Doxygen is a documentation system for C++, Java, IDL (Corba, Microsoft and KDE-DCOP flavors) and C. Becoming the standard for many Open Source projects (e.g., Mozilla)

HTML. LaTex, RTF, Postscript, PDF, man pages

Unix, Windows

C,C++,Java,IDL

javadoc or QTdoc styles

gtk-doc

For GNOME documentation (GTK 1.2+)

 

 

 

 

HTMLgen

Generates generic HTML documentation

HTML

 

 

 

Javadoc

Java standard set by Sun Microsystems

HTML w/Frames (2.0)

Any platform that runs Java (Windows, Unix)

Java

 

KDoc

KDOC is a C++ and IDL interface documentation tool, initially written for the specific purpose of generating documentation for the KDE libraries. KDOC extracts specially formatted documentation and information about your classes from the class' header or IDL files, and generates cross-referenced HTML, LaTeX or Man pages from it.

 

 

C++, IDL

 

Object Outline

Formerly commercial product from Bumblebee Software, now Open Source. Also outputs software metrics

HTML w/Frames, RTF WinHelp

Windows

C++

 

Perceps

A Perl script designed to parse C/C++ header files and automatically generate documentation in a variety of formats based on the class definitions, declarations, and comment information found in those files.

Mainly HTML, but Tek, RTF, man pages also possible

 

C,C++

 

ReThree-C++

A Reverse Engineering,  Redocumentation and ReUse tool

HTML, RTF

Windows 3.1, Windows 95

C++

 

RoboDoc

Based on AutoDoc from a while back

HTML, ASCII, AmigaGuide, LaTex, RTF

 

Assembler, C, Perl, LISP, Occam, Tcl/Tk, Pascal, Fortran, Shell scripts, COBOL

Uses Keywords in comments and special markers

ScanDoc

ScanDoc is a Perl script which scans C++ source code for specially-formatted comments and produces attractive, organized, indexed documentation.

HTML

Any platform that supports Perl

C++

 

SDoc

SDoc is a general purpose document generator for programmers. It can process files to produce browsable or printable manuals from source files, which can have the documentation embeded in program comments. SDoc is configurable to fit any programming language (almost), and uses a simple markup which is quite readable in source form. Output formats are HTML, LaTeX and Lout.

 

Unix, Windows

 

 

DocBuilder

DocBuilder detects program structures of the languages C/C++ and Pascal/Delphi and also description texts. The latter can be be present in comments inside the program or in separate text files. All relevant information is analyzed, assembled according to the desired configuration to a document and transformed then into the target formats. The user does not have to know these target formats.

HTML, RTF, WinHelp

 

C/C++,Delphi/Pascal

 

DocJet

DocJet is a tool for generating documentation from comments in source code. The current version, 3.0, works with Java, Visual Basic, C, C++ , and MS IDL. There is a full-featured demonstration version available for download. You will probably also be interested in AltHelp, a plug-in for VB and Visual Studio which can display DocJet-generated HTML just like the built-in documentation.

HTML w/Frames

 

Java, C, C++, Visual Basic, MS IDL

 

Genitor Surveyor

From StarBase, who also sells CodeWright, SpyWright, customizable

HTML w/Frames

Windows

C++

javadoc

ObjectManual

A 'javadoc' Like Tool To Generate HTML, MIF, XML, RTF & UNIX "man" Documentation

HTML, RTF, MIF

Unix, Windows NT/95

C++

javadoc style,

TimeToHelp

Generates 'javadoc' style documentation for Delphi source code

HTML w/Frames

Windows

Delphi, Pascal

javadoc style

Together

Enterprise UML modeling tool from TogetherSoft that generates documentation from UML and source code

HTML w/Frames

Windows, Unix

Java, C++

javadoc style

 

 

'개발' 카테고리의 다른 글

Doxygen 및 HTML Help workshop 설치  (0) 2008.06.13
RTLS  (0) 2008.05.21
문서화 툴 리스트  (0) 2008.05.06
자원이 사용중이고 NOWAIT...  (0) 2008.03.25
응용 프로그램을 위한 최상의 사용자 환경을 만드는 방법  (0) 2008.02.26
simpleAdo 2.10  (0) 2008.02.21

Trackbacks 1 / Comments 0

Leave Comments

자원이 사용중이고 NOWAIT...

1. LOCK이 걸린 테이블의 sid및 serial을 찾는다.
select a.sid, a.serial# from v$session a, v$lock b, dba_objects c where a.sid=b.sid and b.id1=c.object_id and b.type='TM' and c.object_name='MT_JUNGDANG';

2. 해당 세션 KILL
alter system kill session '18, 149';

'개발' 카테고리의 다른 글

RTLS  (0) 2008.05.21
문서화 툴 리스트  (0) 2008.05.06
자원이 사용중이고 NOWAIT...  (0) 2008.03.25
응용 프로그램을 위한 최상의 사용자 환경을 만드는 방법  (0) 2008.02.26
simpleAdo 2.10  (0) 2008.02.21
프로세스의 메모리 사용량가져오기  (2) 2007.09.27

Trackbacks 0 / Comments 0

Leave Comments

응용 프로그램을 위한 최상의 사용자 환경을 만드는 방법

사실 프로그램을 개발하다보면 밋밋한 사용자 UI 때문에 고민이 이만저만이 아닙니다.
그렇다고 UI디자이너가 따로 있는 것도 아니고, 직접 포토샵 띄워놓고 UI 디자인하다보면
예쁘게 잘 될릴가 만무합니다.
하지만 어쩌겠습니까. 이것이 저희 개발환경인것을..ㅠㅠ

그래도 간단한 버튼하나 만들고 위치시키는 것에도 사용자 편의를 위한 몇가지 원칙이 있어보입니다. 그런 환경 디자인 원칙을 준수하여 개발하게 되면 매우 유익할 듯 합니다.





아래는 windows applicaion 을 위한 직관적인 사용자 인터페이스를 구현하는 방법을 자세히 설명하고 있습니다.


http://www.microsoft.com/Korea/MSDN/library/Ko-Kr/dnwui/html/humanux.aspx







Dax Pandhi
Nukeation Studios

2006 4

요약: Dax Pandhi Windows 응용 프로그램을 위한 사용이 쉬운 사용자 인터페이스를 구현하는 방법과 사용자 환경 디자인 원칙에 대해 설명합니다.

목차

소개
적절한 UI 만들기 위한 기본 원칙
   간격 조정 위치 지정
   크기
   그룹화
   사용 편이성
보다 효율적이고 편리한 사용자 환경 조성을 위한 20가지
   1. 표준 준수
   2. 중요 단추에 주의 끌기
   3. 알아보기 쉽도록 아이콘 제공
   4. 알아보기 쉽도록 머리글 작성
   5. 사용자 지정 메시지 상자 사용
   6. 대체 명령 포함
   7. 중요 작업을 처리하는 방법
   8. 라디오 단추 또는 콤보 상자
   9. 사용자를 방해하지 마십시오
   10. 진행 상태 알리기
   11. 마법사로 복잡한 단계를 간단히 수행
   12. 텍스트의 어조를 정확히 전달
   13. 때로는 ListView 효율적
   14. 이동 경로(Breadcrumb) 컨트롤과 세로 막대로 간단한 탐색 지원
   15. 멋진 그래픽 사용
   16. 가급적 크기 조정이 가능한 제공
   17. 세로 막대/작업창으로 보다 다양한 기능 제공
   18. 알림 옵션 제공
   19. 도구 설명 제공
   20. 사소한 부분까지 배려
결론
참조 자료

소개

개발자들은 가지 시각만을 갖는 경우가 흔히 있습니다. 아마도 약간 무미건조할 있겠지만 코드에는 분명히 느낌이 있습니다. 그러나 그뿐입니다. 때로는 기술, 중에서도 특히 '새로운' 기술과 소프트웨어 기능에 자만하여 최종 사용자가 중요시하는 다를 수도 있다는 점을 간과할 수도 있습니다. 아마 지금도 개발자들은 "코드를 보여주세요. 설명은 필요 없습니다!"라고 말할 수도 있습니다. 개발자들은 사용자가 '기대하는 것처럼' 응용 프로그램이 작동하도록 최선을 다합니다. 그러나 사용자들은 단순히 작동하는 이상을 바라게 됩니다. 일반 판매용 소프트웨어를 개발하거나 비전문가들이 사용하는 제품을 개발할 경우에는 특히 그렇습니다. 처음에는 다소 불쾌하다고 느껴질 수도 있지만 사용자는 어디까지나 고객이므로 사용자 환경을 개선할 있는 방법에 대해서 알아보도록 하겠습니다.

만약 사용자가 일주일에 수십 시간을 특정 소프트웨어 응용 프로그램을 보면서 작업하는 보낼 경우 최소한 소프트웨어가 눈에 편안하기를 바랄 것입니다. 또한 되도록 탐색과 사용이 편리하기도 바랄 것입니다. 문제는 소프트웨어가 대량으로 생산되는 상황에서 소프트웨어 응용 프로그램 40% 정도만이 최종 사용자들이 정말 마음에 들어 하고 즉시 편안하게 사용할 있는 매우 우수한 UI 갖추고 있다는 것입니다.

수많은 기업 내부용 소프트웨어가 생산되고 있습니다. 그러나 자체적으로 개발하든 컨설턴트의 도움을 받아 개발하든 보다 나은 UI 만들기 위한 시간, 노력 또는 비용은 거의 투자되지 않고 있는 실정입니다. 개발 과정에서 '디자이너' 역할은 미미하며 특히 Windows 응용 프로그램의 경우에는 더욱 그렇습니다. 현재 개발 중인 UI 형편 없다는 것이 아니며 개발자가 있는 일들이 아주 많다는 점을 말하고 싶습니다. 이젠 이상 " 정도면 괜찮은 수준" 또는 "프로그램을 개발"하는 것만으로 충분하지 않습니다.

보다 외관이 멋지고 기능이 우수한 응용 프로그램용 UI 만들려면 준수해야 하는 가지 기본 규칙이 있습니다. 기본 규칙을 준수하는 있어 시간과 비용이 그다지 많이 드는 것은 아니나 투자수익(ROI) 분명히 향상됩니다.

자세히 설명하기에 앞서 사용자 인터페이스와 사용자 환경을 구분해 보도록 하겠습니다. 사용자 인터페이스(UI) 응용 프로그램의 시각적 측면과 컨트롤을 나타내는 반면, 사용자 환경(UX) UI UI 관련된 응용 프로그램의 동작뿐 아니라 응용 프로그램에서 사용자가 받게 되는 "느낌"까지 포괄합니다. , 단순히 외관이 훌륭한 UI 설계하는 것이 아니라 성능도 우수해야 한다는 것입니다.

여기서는 응용 프로그램 디자인 단계에서 쉽게 적용할 있는 UX 디자인을 위한 20가지 중요한 규칙에 대해서 설명하도록 하겠습니다. 그러면 보다 사용이 쉬운 기능, "휴먼 UX" 갖춘 다양한 응용 프로그램을 개발할 있습니다. 모두 알다시피 Windows Vista 응용 프로그램을 제작할 경우에는 다르게 보고 다르게 행동해야 합니다. 여기서 설명하는 내용이 현재 사용자에게는 미래의 프로그램을 미리 경험해 있는 기회를 제공하면서 개발자에게는 미래의 응용 프로그램을 준비하는 도움이 되기를 바랍니다.

먼저 우수한 UI 디자인의 기본 사항에 대해서 간략하게 설명한 후에 주제에 대해서 자세히 살펴보도록 하겠습니다.

적절한 UI 만들기 위한 기본 원칙

예전에 친구 하나가 자신이 수석 설계자로 참여했던 응용 프로그램을 자랑한 적이 있었습니다. 기능은 정말 우수하더군요. 개발 팀에서 소프트웨어의 핵심 부분을 개발하는 데만도 2 정도가 걸렸지만 수천 달러의 가격으로 판매될 예정이었던 응용 프로그램의 UI 테마별로 되어 있지 않은 일반 Windows 응용 프로그램보다도 단조로웠습니다. 저는 친구에게 UI 개선에는 시간을 들이지 않았는지 물었습니다. 그는 "Windows 응용 프로그램이기 때문이네. 응용 프로그램이었다면 물론 시간을 들였겠지. 하지만 Windows XP 하더라도 응용 프로그램의 외관을 치장하는 이외에 UI 있는 일이 무엇이겠나?"라고 대답했습니다.

그의 말은 일리는 있었으나 만약 당신이 Windows Vista에서 가능한 작업을 염두에 둔다면 그의 말이 전적으로 옳지만은 않다는 것을 있을 것입니다. 창의 모양을 개선하려고 굳이 사용자 지정 스킨을 만들 필요는 없습니다. 진정으로 전문적으로 보이는 UX 만드는 것은 다음 가지 요소에 달려 있습니다.

·                     간격 조정 위치 지정

·                     크기

·                     그룹화

·                     사용 편이성

Visual Studio 8.0 이전 버전에서는 간격 조정과 크기 조정이 매우 어려웠습니다. 4x4 또는 8x8 형태가 항상 맞지는 않았기 때문입니다. 하지만 SnapLines 포함되면서 프로세스는 한층 간단해졌습니다. 점에 있어서는 기능이 매우 만족스러웠으나 레이블 하나를 텍스트 상자에 맞추는 작업이나, 설상가상으로 여러 레이블을 각각 해당 텍스트 상자에 맞추는 작업을 때는 종종 광부와 같은 육체 노동 직종으로 바꾸고 싶다는 생각이 들기도 했습니다. 그러나 이제 그런 어려움은 모두 해소되었습니다. 저는 SnapLines 사용해 것을 권장합니다.

이제 위에서 말한 가지 측면에 대해서 잠시 살펴보도록 하겠습니다.

간격 조정 위치 지정

컨트롤 사이의 간격은 중요합니다. 그림 1에는 간단한 사용자 정보 입력 폼이 나와 있습니다. 폼에서 위의 입력란은 너무 가깝게 붙어있고 아래 목록은 너무 멀리 떨어져 있어서 사용되지 않은 공간이 많습니다.

사용자 삽입 이미지

그림 1. 잘못 설계된

사용자 삽입 이미지

그림 2. 올바르게 설계된

그림 2 경우 대화 상자의 간격이 적절히 조정되어 보다 전문적으로 보입니다. 폼은 그림 1 폼과 동일하지만 SnapLines에서 추천하는 간격을 사용하도록 수정되었습니다. 항상 실제 하단 가장자리가 아닌 입력란의 텍스트 기준선이나 옆의 컨트롤과 레이블을 맞출 것을 권장합니다. 원하는 대로 정렬되면 대개 하단 가장자리에서 픽셀 위의 SnapLines 색상이 바뀝니다.

간격 조정에 대한 정확한 규칙은 없으나 가장 좋은 것은 SnapLines 따르는 것입니다. 적절한 간격을 유지하기 위한 다른 훌륭한 도구로는 컨테이너 도구 상자 그룹 아래의 레이아웃 컨트롤을 있습니다. TableLayoutPanel 입력 스타일 대화 상자 생성에 매우 유용합니다.

크기

크기에도 같은 방식이 적용됩니다. 도구 상자에서 폼으로 단추를 끌어올 높이와 너비는 완벽한 균형을 이룹니다. 모든 중요한 이유는 배제하고 권장되는 최대 너비는 원래 너비의 배입니다. 그렇지 않으면 단추가 두드러져 나와서 팝업 광고와 같이 눈길을 끌게 것입니다. 그러면 되는데 말이죠!

시작 메뉴의 실행 또는 Windows 탐색기 개체의 속성 대화 상자를 살펴보면 단추 크기가 ' 맞음' 있습니다. 최종 사용자에게 반드시 알리고 싶은 매우 중요한 기능이 있는 경우 단추나 평범하지 않은 화려한 색상을 사용하지 않고도 여러 가지 방법을 사용할 있습니다. 이에 대해서는 나중에 설명합니다.

사용자 삽입 이미지

그림 3. 단추 크기 비교

그림 3에는 가지 크기의 단추가 나와 있습니다. 번째 단추는 가장 권장되는 크기로 도구 상자에서 끌거나 클릭하면 기본적으로 생성되는 크기입니다. 텍스트를 추가로 입력하려면 단추를 크게 만들어야 합니다. 번째 단추는 약간 크지만 사용할 있는 크기입니다. 다른 컨트롤의 배치를 방해할 정도로 크지는 않기 때문이죠. 그러나 번째 단추는 사용하기 어려운 크기입니다. 크기의 단추를 사용하면 Windows에서 테마가 적용된 컨트롤을 그릴 사용하는 테마 비트맵까지 흐트러진다는 것을 있습니다. 또한 단추 주변에 다른 컨트롤을 맞추기도 매우 어렵습니다.

위에 나온 그림 1 경우 대화 상자의 크기와 오른쪽의 여백을 감안할 개의 입력란이 너무 작다는 것을 있으며 이에 비해 그림 2 적절히 조정된 크기입니다. SnapLines 크기 조정에도 도움이 됩니다. SnapLines 특정 상황에서 가장 구체적인 크기 또는 위치를 제안하므로 따르는 것이 좋습니다.

그룹화

거의 모든 응용 프로그램에는 수많은 컨트롤이 있습니다. 적절하고 알아보기 쉽게 그룹화해야만 이러한 컨트롤을 사용하기 쉽게 만들 있습니다. 기능에 따른 그룹화 또는 범주별 그룹화를 가장 수행하려면 컨트롤을 사용합니다. 예를 들어 일반적인 비즈니스 응용 프로그램에서는 '계정', '보고서', '직원' '프로젝트' 탭으로 사용하는 것이 가장 좋습니다. 동일한 최종 결과를 가져오도록 제어하는 형제 그룹화를 가장 훌륭히 수행하려면 그룹 컨트롤을 사용합니다. 이러한 그룹화에 테두리가 있는 패널은 사용하지 않는 것이 좋습니다. 그룹 컨트롤을 사용하면 추가적인 레이블 컨트롤을 사용하지 않아도 됩니다. 특히 하위 컨트롤이 자체만으로도 알아보기 쉬운 경우에는 그렇습니다.

그룹 컨트롤 내에 그룹 컨트롤을 배치하는 것은 하나의 그룹 컨트롤 안에 2~3개의 컨트롤만 있는 경우가 아니면 권장되지 않습니다. 그룹 컨트롤 안의 다른 그룹 컨트롤 내에 그룹 컨트롤을 배치하는 것은 더더욱 권장되지 않습니다. 이렇게 쓰는 것조차 이상합니다.

사용 편이성

사용 편이성은 훌륭한 사용자 환경에 있어 실제로 중요한 측면입니다. 이해가 쉬운 UX 경우 설명할 필요가 줄어듭니다. 사용자들이 컨트롤의 기능을 곧바로 알기 때문입니다.

알아보기 쉬운 디자인에서 가장 중요한 것은 구분입니다. 가장 좋은 예는 Windows XP 출시 전에 Microsoft에서 발표한 Windows XP Design Guidelines (영문) 나와 있습니다. Windows XP에서는 테마별 응용 프로그램, 로그오프, 시스템 종료 대화 상자 등에서 탐색과 같은 기능을 위해 모서리가 둥근 새로운 단추를 제공했습니다.

이러한 컨트롤의 색은 해당 단추를 눌렀을 나타나는 결과의 심각도에 따라 결정됩니다. 탐색은 '보행' 신호등과 같이 녹색이고 작업 손실이 야기될 있는 시스템 종료는 경고 신호와 같이 빨간색이며 로그오프나 최대 절전 모드와 같은 심각도가 덜한 단추는 노란색입니다. 도움말과 같이 사용자의 작업 프로세스에 심각한 영향을 미치지 않는 중립적인 단추는 옅은 파랑색입니다. 스킨이 적용된 UI 만들 이러한 구분을 염두에 두어야 합니다.

색으로 콘텐츠를 구분할 있는 가장 좋은 예는 Microsoft Office OneNote입니다. 응용 프로그램의 탭은 전체 Windows XP 스타일 디자인에 무난하게 어울리도록 하면서도 다양한 색으로 설정할 있습니다.

하나의 중요한 측면은 응용 프로그램의 텍스트입니다. 최근 소프트웨어에 작성된 명령에서는 표현이 단순화되었습니다. 소프트웨어 내의 텍스트에 대해서는 나중에 설명하도록 하겠지만 사소하면서도 중요한 가지 세부 사항에 주목해 주시기 바랍니다. 예를 들어 살펴보겠습니다.

MSN Messenger에는 옵션 대화 상자에 "웹캠 기능 공유"라는 확인란이 있었습니다. 물론 개발자나 해박한 기술 지식이 있는 사람들은 기능이 무엇을 의미하는지 압니다. 그러나 초보 사용자는 대화 상대방과 자신의 웹캠을 함께 사용할 있는 기능이라 생각할 있을 것입니다. 혼동을 주는 설명이었죠. 그래서 최신 버전에서는 "웹캠: 웹캠을 통해 다른 사람이 나를 있도록 허용"이라는 옵션으로 변경되었습니다. 메뉴 옵션은 기술적 지식이 없고 단순한 표현에 익숙한 사람들도 완벽하게 이해할 있습니다.

단순한 표현은 이해하기 쉬울 아니라 나중에 살펴보게 되겠지만 다른 이점이 있습니다. 과학적 연구에 따르면 무언가 새로운 것을 이해하려고 단순한 표현은 의미 파악이 쉬운 것으로 나타났습니다. 흔히 인간의 두뇌는 '그것', '~ 대한', '저것' 같은 단어와 기타 일반적인 단어는 매우 빠르고 쉽게 이해하지만 위의 예에서 있듯이 '웹캠' 또는 '다른 사람' 같은 단어를 이해하는 데는 많은 사고 영역을 할당합니다.

메시지 상자 제목, 그룹 상자 캡션 기타 비슷한 종류의 텍스트 블록을 사용하면 단어만으로 최종 사용자에게 많은 컨트롤의 기능을 쉽게 전달할 있습니다.

사용 편이성은 친숙함에서도 나옵니다. 예를 들어 확인/취소 단추를 함께 배치하는 것은 매우 일반적이므로 우리들의 머리 속에 순서대로 각인되어 있어서 만약 어떤 대화 상자에서 확인 다음에 취소 있지 않고 반대 순서로 취소 다음에 확인 있는 경우 취소 누르게 있습니다. Windows 기반 응용 프로그램과 같이 어떤 작업에 대해 특정 표준을 1 이상 사용해 결과 습관으로 자리잡게 되었습니다. 문서화되어 있지는 않지만 이러한 산업 표준을 따르면 소프트웨어를 사용하기 쉽게 만들 있습니다.

다른 예를 살펴보도록 하겠습니다. 초기 Windows Vista 시험판 빌드 하나에서는 창의 최소화, 최대화 닫기 단추의 순서가 달랐습니다. 이전 버전의 Windows에서는 특히 단일 모니터를 사용하는 경우 화면의 오른쪽 상단 모서리에 커서를 "어림짐작으로 가져가서" 무의식적으로 클릭하는 습관이 생기게 되었습니다. 이렇게 하면 항상 창이 닫히게 되었죠. 그러나 위에서 말한 Windows Vista 빌드에서는 닫기 단추와 창의 가장 오른쪽 가장자리 사이에 8픽셀 정도 되는 여백이 있었기 때문에 오랫동안 자리잡은 "어림짐작으로 하는 클릭"으로는 창이 닫히지 않았습니다. 여분의 공간이 있어 외관상으로 좋아 보이는 것은 물론이며 아마도 단추를 누르면 시작되는 화려한 애니메이션에 이러한 공간이 필요할 수도 있었겠지만 창이 닫히지는 않으니 짜증나는 일이었습니다. 습관을 바꾸는 것은 어려운 일이었으니까요. 다행히도 이후 빌드에서는 문제가 해결되었습니다. 아마도 저와 같이 어림짐작으로 클릭했던 많은 사람들이 Microsoft 의견을 보내지 않았을까 싶습니다. 이제 창의 가장자리와 닫기 단추 사이에 공백이 있기는 하지만 공백을 클릭해도 창이 닫힙니다. 문제가 해결된 것이죠.

알아보기 쉬운 디자인에서 매우 중요한 점은 '생각해야 하는 영역' 얼마나 되느냐입니다. , 머리 속에서 무언가를 이해하는 걸리는 시간이 어느 정도냐 하는 것이죠. '사고 영역' 적으면 적을수록 훌륭한 UX라고 있습니다.

소프트웨어 응용 프로그램 사용 "환경" 기여하는 사소한 항목들도 있기는 하겠으나 이론만으로도 충분합니다. 심지어 조차도 "실용적인" 정보를 원하니까요. 그러므로 이제 이론적인 얘기는 접어 두고 실제로 응용 가능한 팁과 트릭을 사용하여 응용 프로그램을 향상시키는 방법에 대해서 알아보도록 하겠습니다.

보다 효율적이고 편리한 사용자 환경 조성을 위한 20가지

보다 나은 UX 구축하는 목적은 외관이 훌륭하면서도 간단하고 알아보기 쉬우며 기능이 뛰어난 UI 얻기 위함입니다. 이제 소프트웨어 응용 프로그램을 사용해 경험이 별로 없고 기술적 지식이 그다지 많지 않은 사용자들의 일상 업무에 초점을 두고 살펴보도록 하겠습니다. 아마도 이런 '유형' 소비자들이 대부분 소프트웨어 응용 프로그램을 사용하겠죠. 아래에 나오는 팁은 보다 효과적인 UI 만드는 도움이 됩니다.

1. 표준 준수

운영 체제 수준, 브랜드 수준 또는 응용 프로그램 수준 어떤 수준에서 수립된 것이든 소프트웨어 환경에서 수립된 기준은 매우 중요합니다. 브랜드와 더불어 이러한 표준은 사용자에게는 일종의 신뢰할 만한 방식으로 여겨집니다. 어떤 소프트웨어 응용 프로그램을 사용하여 오랜 시간을 작업할 경우 해당 사용자는 소프트웨어와 점점 친숙해지면서 생산성이 자동으로 향상될 것입니다. 이것은 마치 근처의 도로를 운전하는 것과 같습니다. 권유하지는 않지만 아마 이런 경우 눈을 감고도 운전할 있을 것입니다.

표준에 대해서 설명하기 전에 먼저 이러한 표준이 정확하게 무엇을 의미하는지 알아보도록 하겠습니다. 앞에서 말했듯이 확인/취소 순서로 단추를 배치하는 것처럼 표준에는 대화 상자의 컨트롤을 특정 방식으로 배치하는 것에서부터 Windows XP 대화 상자의 사용자 인터페이스 상단의 둥그런 모서리, 아이콘 스타일, 기타 그래픽 스타일, 응용 프로그램의 대화식 동작 모든 것이 포함됩니다.

올바른 표준 집합을 선택하려면 응용 프로그램을 간단히 검사해야 합니다. 응용 프로그램을 위한 가장 좋은 표준은 현재 Windows 디자인 지침으로, 당장 사용할 있는 최신 표준으로는 Windows XP 디자인 지침을 있습니다. 응용 프로그램을 디자인하는 중에 다른 운영 체제 버전이 출시될 상황인 경우 이전 버전과의 호환성만 유지된다면 다음 버전용 디자인 지침을 사용하는 것도 무방합니다. 그러면 적어도 최종 사용자에게는 " 앞서간다" 느낌을 있습니다.

만약 응용 프로그램이 일반적인 응용 프로그램이 아닌 경우 다른 표준 집합을 따르는 것이 좋습니다. 일례로 개발 중인 응용 프로그램이 Microsoft Office OneNote 2003 응용 프로그램이나 추가 기능을 지원할 경우 Microsoft Office UI 스타일과 대화형 작업 표준 OneNote 자체의 표준을 따르는 것이 현명합니다. , 시각적, 기능적 면에서 표준 도구 모음이 아닌 Office 스타일 명령 모음을 사용하고 대부분 Office 스타일을 따르는 것을 뜻합니다. 개발 중인 응용 프로그램이 Microsoft Visual Studio .NET 범주에 속할 경우 별도의 표준 집합을 준수해야 합니다. 사실 이러한 추가 기능이나 지원 응용 프로그램을 위해 Microsoft에서는 문서화된 지침을 배포하고 있습니다. 또한 그래픽과 디자인 개념은 종종 보호되는 지적 재산이므로 이러한 디자인을 만들 있는 라이선스가 있는지 항상 해당 설명서를 확인해야 합니다.

표준의 번째 예는 Tablet PC 환경입니다. 이러한 표준은 운영 체제 지침과 응용 프로그램 지침 사이의 경계를 넘나듭니다. Tablet PC SDK documentation(영문)에는 "응용 프로그램 계획" 관한 주제와 관련하여 매우 유용한 가지 정보가 수록되어 있습니다. Office 2003 또는 Visual Studio 지침과는 달리 이러한 디자인 권장 사항은 사용자들이 응용 프로그램을 어떻게 사용하는지, 이에 따라 응용 프로그램이 어떻게 작동해야 하는지에 직접적으로 영향을 미칩니다. 예를 들어 응용 프로그램에 고정 창이 있는 경우 설명서에서는 화면 방향이 변경될 경우 감지할 있는지 확인하고 필요에 따라 가로, 세로 방향으로 고정 창이 적절히 재구성되도록 하라고 권장합니다. Tablet PC용으로 응용 프로그램을 설계하지 않는다 해도 이러한 지침을 준수하라고 다시 한번 당부 드리고 싶습니다. 개발자인 여러분과 여러분이 개발하는 응용 프로그램은 이러한 지침을 준수함으로 인해 보다 향상될 있을 것입니다.

스마트 클라이언트의 출현으로 일반 PC, Tablet PC, 모바일 또는 초소형 모바일 장치, 미디어 센터 PC 서로 다른 하드웨어의 경계를 넘어 응용 프로그램이 사용되고 있습니다. 각각의 상황에 맞추어 서로 다른 또는 추가적인 표준 집합을 준수해야 합니다.

응용 프로그램에서 운영 체제 수준 또는 응용 프로그램 수준 표준을 공유할 경우 사용자들은 배우기 쉽고 사용이 편리한 소프트웨어를 통해 편안함을 느낄 있으며, 이는 생산성 향상에 직접적으로 이어집니다. 더욱이 사용자들은 프로그램의 사용 방법을 배우기보다는 프로그램을 바로 사용하길 원합니다.

2. 중요 단추에 주의 끌기

때로는 주변에 다른 단추가 4~5 있는 경우 가장 중요한 단추에 사용자들의 관심을 집중시켜야 하는 경우가 있습니다. 크기, 색상 또는 글꼴 때문에 혼동스럽다면 표준을 위반해도 되기는 합니다. 그러나 물론 권장되지는 않습니다. 대신 간단한 가지 트릭을 사용할 있습니다.

사용자 삽입 이미지

그림 4. LinkLabel 쌍을 이루어 사용하면 단추에 주의가 집중됩니다.

번째 트릭은 중요하지 않은 단추를 LinkLable 변환하는 것입니다. 이렇게 하면 사용자는 이러한 링크가 작업을 수행하게 된다는 것을 알게 되므로 표준 디자인 지침을 위반하지 않고도 먼저 눈에 띄는 단추로 주의를 돌리게 됩니다.

사용자 삽입 이미지

그림 5. 왼쪽에서 오른쪽으로 읽는 습관으로 인해 왼쪽의 단추가 가장 먼저 눈에 띕니다.

번째 트릭은 단추를 줄의 가장 처음에 배치하는 것입니다. , 가로로 배치된 경우에는 왼쪽에 세로로 배치된 경우에는 위에 배치합니다. 대상 사용자의 습관에 따라 이러한 배치에 변화가 있을 있다는 점을 염두에 두시기 바랍니다. 오른쪽에서 왼쪽으로 읽는 언어로 응용 프로그램의 경우 해당 단추를 가장 오른쪽에 두는 것이 좋습니다.

가장 분명하고 권할 만한 옵션은 기본적으로 관심이 집중되도록 설정하라는 것입니다. 예를 들어 삭제 확인 대화 상자에서는 사용자가 실수로 삭제하는 것을 방지하기 위해 아니오 옵션이 강조 표시되어야 합니다.

3. 알아보기 쉽도록 아이콘 제공

"백문이 불여일견"이라는 말이 있습니다. 아이콘, 중에서도 특히 XP Office 2003 아이콘과 도구 모음 비트맵은 UI 파악하고 사용자가 수행해야 하는 작업을 빨리 알아볼 있게 줍니다.

예를 들어 메시지 상자에서 흔히 있는 느낌표 아이콘이 나타나면 아이콘 옆의 컨트롤과 관련된 위험 수준을 즉각 알아차릴 있습니다. 마찬가지로 응용 프로그램에 컨트롤이 많으면 비록 적절히 배열되어 있다고는 해도 원하는 컨트롤 집합을 찾는 것이 매우 힘들 있습니다.

Windows XP 서비스 2에서는 업데이트된 탭이 "자동 업데이트"라는 시스템 속성 제어판 애플릿에 추가되었습니다. 자동으로 업데이트를 다운로드하는 옵션, 업데이트를 다운로드하기는 하지만 사용자가 설치 시기를 결정할 있도록 하는 옵션, 업데이트가 있는 경우 사용자에게 알리기는 하지만 다운로드를 시작하지는 않는 옵션 그리고 자동 업데이트를 완벽하게 비활성화하는 옵션 4가지 옵션이 있습니다.

초보 PC 사용자인 경우 이러한 업데이트가 무엇을 의미하는지 모르는 것은 물론이며 어떤 옵션을 선택해야 하는지도 모를 있습니다. 그렇기 때문에 Microsoft에서는 "안전한" 옵션을 나타내는 가장 권장되는 옵션 옆에는 커다란 확인 표시가 있는 녹색 방패 아이콘을 표시하고 사용자에게 위험을 초래할 있는 옵션 옆에는 커다랗게 "x" 표시를 빨간색 방패 아이콘을 표시하였습니다. 급박한 상황 특히, 사용자가 너무 많은 설명을 읽을 시간이 없는 경우에 아이콘은 매우 유용합니다.

해당 시스템 속성 애플릿의 탭에는 서로 다른 작업에 대한 다양한 컨트롤이 있는 그룹 상자가 여러 있습니다. 컨트롤 그룹의 작업을 쉽게 나타낼 있도록 그룹의 옆에는 관련이 있는 그래픽이 표시됩니다. 그래픽 코드 유형은 실제 파일이나 주차장의 구분선과 유사합니다. 잡지 기사에 독자의 관심을 있도록 최소한의 그래픽을 넣는 것과 같은 원칙이 적용됩니다.

올바른 아이콘을 선택하는 것도 중요합니다. Microsoft Visual Studio 2005에서 많은 표준 그래픽을 기본으로 제공하므로 그래픽을 선택하는 것이 가장 좋습니다. 사용자 지정 아이콘을 만들 경우 위의 표준 준수 섹션에 나와 있는 그래픽에 대한 운영 체제 수준 또는 응용 프로그램 수준의 표준을 준수하는 것이 좋습니다.

Windows XP Design Guidelines (영문)에는 Windows XP 스타일 32비트 아이콘을 만드는 방법에 대한 유용한 지침이 나와 있습니다. Windows Vista 스타일 아이콘에 대한 새로운 지침은 배포될 예정입니다. 자세한 내용은 기사 부분에 있는 링크를 참조하십시오.

4. 알아보기 쉽도록 머리글 작성

머리글은 문장(필요에 따라 그래픽도 함께 사용할 있음)으로 전체 대화 상자를 설명하는 완벽한 방법입니다. 때로는 머리글 내에 탐색 명령을 포함할 수도 있습니다. 머리글은 대화 상자가 팝업될 가장 먼저 눈에 띄기 때문에 일반적인 설명 레이블보다 더욱 효과적입니다.

Windows Installer 마법사는 아마도 가장 인기 있는 머리글일 것입니다. 오른쪽에 간단한 아이콘이 있고 대화 상자를 설명하는 제목 레이블(: 설치 폴더 선택) 다음에 대화 상자의 목적을 설명하는 하위 머리글(: 소프트웨어 파일을 설치할 폴더 선택) 구성됩니다. 그러나 이러한 원칙은 마법사 이외의 항목에도 적용됩니다.

계정 섹션이 있는 일반적인 업무용 응용 프로그램이 있다고 가정해 봅시다. Windows Vista에서 많이 사용되는 디자인 방식을 따라(그림 6 참조) 머리글 자체(상황에 따라 바닥글) 필수적인 업무 정보와 관련 명령을 제공할 있습니다. 사용자가 "Big Company" 대한 계정 파일을 열면 그림 7 같은 머리글이 나타날 것입니다.

사용자 삽입 이미지

그림 6. 상세한 바닥글이 있는 Windows Vista 탐색기

사용자 삽입 이미지

그림 7. Windows Forms 응용 프로그램의 종합적인 머리글

마찬가지로 가지 명령만 있으면 세로 공간이 많이 낭비되는 Windows XP 스타일 작업창을 추가하지 않아도 되며, 이러한 명령을 머리글로 옮기면 번거로움이 많이 사라집니다.

머리글을 설계할 때는 다음과 같은 사항을 염두에 두어야 합니다.

·                     대화 상자의 배경색과 다르도록 배경색을 설정하십시오. 흔히 흰색 머리글을 기본 Windows 내부 컨트롤 표면 위에 놓으면 됩니다. 그러나 특수 테마나 사용자 지정 색상으로 인해 머리글이 흐려지지 않도록 하려면 ControlLight ControlDark라는 색이 있는 Color.FromKnownColor 사용하여 LinearGradient 그리십시오.

·                     가능하면 머리글의 높이를 150픽셀 미만으로 유지하시기 바랍니다. 일반적으로 100 또는 120픽셀이 적당하며, 전체 높이의 1/4 넘지 않도록 하십시오.

·                     위에 나온 그림 7 Customer Name 같은 머리글 정보를 즉석에서 수정할 있도록 하려면 동적으로 LinkLabel 입력란으로 바꾸고 수정이 완료되면 이를 다시 교체하면 됩니다.

·                     글꼴 크기가 10pt 넘는 제목 레이블이 있는 경우 Arial이나 Franklin Gothic Medium 사용하십시오. MS Sans Serif 너무 들쭉날쭉해서 전문적이지 않게 보입니다. Franklin Gothic Medium Windows XP 디자인 지침 설명서에서 권장되는 글꼴입니다. Windows Vista에서 사용되는 응용 프로그램에는 시스템 기본 글꼴인 Segoe UI 글꼴을 사용하십시오.

5. 사용자 지정 메시지 상자 사용

기본 Windows 메시지 상자에서 사용 가능한 옵션은 매우 제한되어 있습니다. 단순한 /아니오 또는 확인/취소 답할 없는 질문을 해야 경우 문제가 복잡해 집니다. 결국 "~하려면 예를 클릭하십시오 또는 ~하려면 아니오를 클릭하십시오" 같이 설명해야 것입니다.

Windows 응용 프로그램은 비전문적인 사용자들이 많이 사용함에 따라 점차 사용이 단순해지고 있습니다. 때로는 작업을 쉽게 수행할 있도록 하기 위해 친숙한 설명이 있는 단추나 심지어는 LinkLabel 같은 추가 컨트롤을 제공하는 것이 보다 간단할 있습니다.

.NET Framework에서는 사용자 지정 대화 상자를 쉽게 구현할 있습니다. 사용자 지정 대화 상자 폼에 가지 속성만 할당하거나 코드 줄만 할당하면 폼이 기본 메시지 상자와 동일하게 작동합니다. 단추를 클릭할 경우 대화 상자의 DialogResult 속성을 DialogResult.Ok 또는 DialogResult.Cancel 설정하십시오. 상위 폼에서 ShowDialog([OwnerForm]) 메서드를 사용합니다. 그러면 ShowDialog 메서드가 DialogResult 값을 반환합니다.

모든 DialogResult 멤버를 사용할 있습니다. 동일한 옵션이 기본 MessageBox.Show 메서드에 사용됩니다.

또는 대화 상자의 AcceptButton 속성을 btnOK 설정하고 CancelButton 속성을 btnCancel 설정할 수도 있습니다. 그러면 Enter Esc 키가 btnOK btnCancel 단추의 Click 이벤트에 자동으로 매핑됩니다.

다음은 사용자 지정 대화 상자를 꾸미는 필요한 가지 팁입니다.

·                     복잡한 주제의 경우 적절한 텍스트 레이블 아래 "자세한 정보"라는 LinkLable 사용하여 로컬 또는 온라인 도움말에 대한 링크를 제공합니다.

·                     /아니오/취소 단추 대신 단추를 클릭할 경우의 결과를 분명히 나타내는 "파일 저장 종료", "저장하지 않고 종료" "종료하지 않음" 같은 텍스트를 사용합니다. 그러나 가능하면 표준인 /아니오, 확인/취소 기타 표준 단추를 사용하도록 하십시오. 친숙한 단추일수록 작업 효율성이 높아집니다.

·                     왼쪽 또는 대상 문자 환경에 따라 오른쪽에 50픽셀 정도의 여백을 남겨두고 대화 상자를 사용하는 경우를 나타내는 아이콘을 추가합니다. 정보 대화 상자인 경우 표준 메시지 상자에서 사용되는 "i" 아이콘을 사용하고, 보안 대화 상자인 경우 자물쇠 아이콘이나 열쇠 아이콘을 사용할 있습니다. Visual Studio 2005에는 가지 우수한 고품질 그래픽이 기본 제공됩니다.

·                     항상 단추 사이를 키보드에서 편리하게 이동할 있도록 하십시오. 사용자들은 메시지 상자에서 키보드 단축키를 많이 사용합니다(: 확인(Ok) O, (Yes) Y, 취소(Cancel) C). 사용자 지정 대화 상자에서 단축키를 사용할 없으면 사용자들이 불편을 느낄 것입니다.

6. 대체 명령 포함

의욕 저하와 게으름이라는 가지 중요 요인으로 인해 대체 입력 방법이 필요하게 되었습니다. 의욕 저하는 컴퓨터 사용자들에게 자주 나타나는 일입니다. 의욕 저하에 빠졌을 때는 작업을 빨리 끝내고 싶어합니다. 스트레스를 받고 있는 사람의 경우 추가로 클릭해야 한다거나 기다려야 한다면 정말로 화가 나겠죠. 어떤 기분인지 아실 겁니다. 우리는 모두 이런 일을 항상 겪고 있으니까요. 게으름으로 인해 사람들은 시점에 사용 중인 것이 키보드나 마우스 어느 것이든 사용하던 수단으로 작업을 끝내고 싶어합니다. 그러나 가지 요인 이외에도 대체 입력 방법이 있으면 사용자들은 보다 쉽게 작업을 수행할 있게 됩니다.

예를 들어 "추가" "제거"라는 개의 단추가 있는 목록 상자의 경우 어느 쪽이든 이러한 단추와 유사한 메뉴 명령이 있는 상황에 맞는 메뉴를 목록 상자에 추가해야 합니다. 그러면 사용자에게는 자신들이 가장 적합하다고 생각하는 방식을 선택할 있는 기회가 제공됩니다. Windows Vista User Experience Guidelines (영문) 나와 있듯이 초보 사용자는 상황에 맞는 메뉴를 많이 사용하고 마우스 오른쪽 단추로 클릭하면 항상 이러한 메뉴가 나타날 것이라 예상합니다.

이와 비슷하게 텍스트나 숫자 입력에 시각적 컨트롤이 사용됩니다. 대표적인 예로 슬라이더는 정수 지정에 사용되고 Calendar 컨트롤은 날짜 입력에 사용되는 것을 있습니다. 때로는 키보드를 사용하여 입력하는 것이 가장 편안합니다. 슬라이더에 연결된 숫자 Up-Down 컨트롤을 추가하거나 Calendar 컨트롤 대신 DateTimePicker 사용할 경우 사용자는 차이를 느낄 있습니다.

7. 중요 작업을 처리하는 방법

사용자들은 항상 혼란스러워 합니다. 그렇기 때문에 기술 지원 엔지니어들이 생계를 유지할 있습니다. 친절한 사람들의 수입을 갉아먹지 않으면서도 개발자들은 가지 방법을 통해 사용자들의 혼란을 덜어주거나 최소한 치명적 오류가 발생했을 스스로 복구할 있도록 도움을 있습니다.

치명적인 복구