지금까지 PD Layer에 집중했는데, 이 글에선 HCI Layer, 특히 그 중에 GUI에 대해 집중적으로 알아본다.
초반에 Analysis 단계에서 Use-Case Diagram에서 actor와 use-case 사이에 그려졌던 선들은 System의 Interface를 의미한다.
User actor와 연결된건 user-Interface를 의미하고, 외부 system actor와 연결된건 system-interface를 의미한다.
Use Case를 사용하려면 PD와 User 사이에 interface가 필요하다는 말이다.
Interface Design은 우리가 만드는 system이 어떻게 외부와 어떻게 상호작용할지를 정의한다.
머신간의 interface인 (1)System Interface와 머신-사람 interface인 (2)User interface로 나뉜다.
user의 입장에선 Interface만 보이기때문에, user에겐 user interface가 system 그 자체이다.
(↑ HCI 설계시 명심해야함 ↑)
HCI Layer는 DM Layer와는 independent하지만, PD Layer와 physical architecture Layer와는 dependent하다.
GUI의 기초는 다음과 같다.
1. Navigation Mechanism
2. Input Mechanism
3. Output Mechanism
User Interface Design을 할때 지켜줘야할 원칙(?)은 다음과 같다. (이건 GUI든 CLI든 적용됨)
1. screen, form, report의 Layout은 이해하기 좋게 배치해야한다. 비슷한 items들은 같은 group에 배치한다.
직관적으로 딱 이해되도록 두는게 좋은데, 이건 나라/문화마다 다르다.(글자를 우->좌로 읽는 나라도 있음)
2. 표시되는 contents들은 이해하기 좋아야한다.
subarea로 논리적으로 보기좋게 잘 나눠줘야하고, 각각의 interface에는 제목을 포함시켜야한다.
또 현재 위치도 알려주면 줘야하고(ex. 회원가입(1/3)), 어떻게 그곳에 갔는지, 어떻게 그곳을 빠져나갈지도 보여줘야한다.
3. Aesthetics(미적)도 고려해야한다.
당연히 사용자는 조잡하게 생긴 것 보단 깔끔하고 예쁘게 생긴 것을 더 사용하고 싶어한다. Text design이나 색조합을 잘 고려해야한다.
대게 간단한 minimalist design을 선호한다. information density는 Novice일 수록 낮은 것을 선호하고, Expert일 수록 높은 것을 선호한다.
4. User가 사용하기 편해야한다.
user를 많이 모으려면 일단 사용법을 배우기 쉬워야한다. ← 신규유저를 모으려면 중요
사용하기 쉬워야한다. ← 전문 user에게 중요
5. 다른 영역이더라도 표현하는 것에 있어서 일관성이 있어야한다.
일관성은 (system을 간단하게 만들기위해) 아주 중요하다.
일관성이 있는 system은 모든 part가 같은 방식으로 동작하므로 사용자가 동작을 예측하기 쉽다. 따라서 사용법을 배우기 쉬워진다.
특히 nevigation control 부분과 용어는 일관성이 꼭 지켜져야한다.
nevigation control 부분의 위치나 모양이 매번 제각각이거나, 용어 의미가 같다고 매번 다른 용어를 사용하는 것은 좋지않다.
예를들어 아래 그림처럼 프로그램 종료 버튼이 어떤 단계에선 왼쪽 위에있고 어떤 단계에선 오른쪽 아래에 있다거나, 종료 버튼에 적힌 글씨가 어떨땐 그냥 "X" 였다가 어떨땐 "EXIT"인 것도 좋지 않다.
6. task들이 복잡하지 않고 적은 노력으로도 빠르게 수행되도록 interface를 제공해야한다.
개발자는 User의 노력을 최소화하려고 노력해야한다.
"three-clicks rule"이란 자주 쓰이는 rule이 있다. 말 그대로 어떤 작업이든 3번의 클릭 안에 완수돼야 한다는 것이다.
Usability Principles
1. user가 현 단계에서 무엇을 할 수 있는지, 다음 단계에서 무엇을 해야하는지 항상 본인이 알도록 하라.
2. feedback을 잘해주고, error message도 효과적으로 잘 줘야한다.(feedback이란 성공, 대기 같은 상태를 알려주는 것을 말한다.)
3. 유저가 항상 해당 단계에서 빠져나가고, 뒤 단계로 돌아가고, 되돌리기를 할 수 있도록 하라.
4. response time이 적절해야한다. (너무 느리면 안된다.)
<실제 design을 보고 판단해보는 예제 ppt ch10 p.15에 있으니 한번 볼 것>
User Interface Design Process
UI Design은 use-case driven, incremental, and iterative한 proccess이다.
따라서 이 과정들은 use-case D와 sequence D와 연관된다.
위에서 말한 GUI의 세가지 기초 요소인 Nevigation, Input, Output이 함께 design되어 나간다.
보통 아래의 각 단계들이 incremental하고 iterative하게 진행된다.
1. Use scenario Development
실제 use case를 UI를 이용해 한 path로 사용해보는 시나리오를 간단하게 만드는 것이다. 특정 task를 완수하기 위해 어떤 단계가 필요한지 간단하게 알아볼 수 있다.
가장 흔한 case들을 document해둬서 UI를 통해 그런 흔한 scenario를 쉽게 사용할 수 있도록 한다.
2. Navigation Structure Design
interface의 기본 구성 요소들과 그들이 어떻게 상호작용해서 user에게 기능을 제공할지 정의한다.
nevigation structure을 디자인할때, Windows Navigation Diagrams(WND) 을 이용해 디자인 하면 편리하다.
WND란?
: behavioral state machine과 유사하다. system 내 모든 screens, forms 같은 애들 사이 관계를 표현한다.
state machine처럼 각 화면이나 폼 들을 쭉 나열해두고, 한 곳에서 다른 곳으로 어떻게 해야 전이가 되는지도 기술한다.
박스는 components를 나타내고, 화살표는 state간의 transitions을 나타낸다. streotypes은 interface의 type을 보여준다.
아래 그림이 WND의 예시인데, <<>>로 표시된게 Steroetype이다. 어떤 type일지는 개발자가 정하기 나름이다.
3. Interface Standards Design
Interface Standard를 정하는 것이다. 기본적인 디자인 요소들을 미리 정해둠으로써 일관성을 준다.
예를들어 지금 만드는 system에서 장바구니는 항상 특정 모양의 쇼핑카트 아이콘을 사용하도록 미리 표준을 정해둘 수 있다.
4. Interface Design Prototyping
Design대로 한번 모형을 만들어 시뮬레이션을 돌려보는 것이다. 이때는 작동할 필요가 없다.
주로 아래 방식들을 이용해 Interface design prototyping을 진행한다.
1) Wireframe Diagram : user가 receive하게 될 실제 user interface와 유사한 형태의 사진/그림으로 표현 (실제로 어떤 버튼을 눌러서 어떻게 되는지 이런 것까지 진짜 화면이 띄워진 것처럼 다 표현하는 듯)
2) Storyboard : screen이 어떻게 생겼으며 한 screen에서 다른 screen으로 어떻게 넘어가는지를 손으로 기술한다. (Wireframe은 진짜 어떻게 생겼는지 그대로 보여주는 거라면, 얘는 그냥 어떤 정보가 포함되고 뭐 이런 것만 기술해주는 정도인듯)
3) User Interface prototype : 실행가능한 프로그램형태의 프로토타입
Q. Navigation Structure Design 이랑 Interface Design Prototyping 이랑 크게 다를게 없어보이는데?
A. 전자는 좀 더 상세하게 어떤 구조로 어떤 상태일때 전이되는지가 나와있지만, 후자는 그렇지 않다. 후자는 간략하게 어떤 식으로 작동되는지, 내부 구조보다는 실제 화면과 비슷하게 표현하는 프로토타입이다.
위에서 살펴봤듯 GUI 구성요소는 크게 3가지가 있다.
위에까진 좀 general한 디자인 방법이었고, 여기부턴 각 파트를 어떻게 디자인할지, 어떤 부분을 신경써야할지 자세히 알아본다.
Navigation Design
Nevigation의 각 요소를 통해 우리는 명령어를 입력하고, 정보를 보고, 메시지도 받아볼 수 있다.
PD Layer에서 일어나는 일들과 소통하는 창구인 셈이다.
Navigation Design의 목표는 "as simple as possible"이다.(SW 설계 전반의 목표도 마찬가지로 as simple as possible이다)
좋은 navigation 구성요소는 user가 알아차리지 못할 정도로 간단해야한다.
> Navigation Design의 기본 원리
- 실수를 막는다.
- 실수를 하더라도 간단하게 recovery 할 수 있도록 한다.
- 일관된 규칙을 따른다.
> Message (Navigation 구성 요소 중 하나, 이거 말고 메뉴도 있고.. 자세한건 책 p.384부터)
system의 현재 상태를 user에게 어떻게 알려줄지에 대한 것이다.
1) Error message → ex)허용되지 않은 작업을 시도할때, 에러메시지 출력
2) Confirmation message → ex)Are you sure?
3) Acknowledgment message → ex)요청 작업을 완료했을때 완료했다고 메시지
4) Delay message → ex)system이 제대로 작동하고있다고 퍼센테이지 등으로 표시해주는 것
5) Help message → ex)user를 돕기위해 추가 정보를 제공
위 다섯가지 종류의 메시지는 기본적으로 꼭 있어야 한다.
Input Design
input받는 data는 크게 두 종류가 있다.
(1)날짜나 이름처럼 구조가 짜여져있는 데이터, (2)그냥 comment처럼 아무 구조가 없는 데이터
input 받을때의 기본 원리 세가지이다.
1) Online vs Batch processing
: Online으로 input을 받으면 매번 save를 한다, batch는 마지막에 save를 눌러야 그제서야 save가 된다. 아이디 오류 이런게 떠서 save에 실패하면 batch인 경우 데이터가 다 날아가서 다시 작성해야 할 수 있음.
2) Capture data at the source
: source로부터 데이터를 잘 읽어와야한다. 여러번 거쳐서 데이터가 오게되면 변형이 될 수 있다. 특히 사람이 중간에 끼면 실수가 발생할 수도 있다.(자세한건 책p.389)
3) Minimize keystrokes
: list에서 선택할 수 있다면 굳이 typing을 받을 필요가 없다. 자주 사용되는 공통 정보(ex.전화번호 앞에 010)는 미리 입력해두는 식으로 키 입력을 줄일 수도 있다. 키 입력이 너무 잦으면 그것도 결국 시간/돈 낭비이므로 줄이는게 좋다.
> Inputs 유형
1) Free form controls
자유 형식이더라도 빈박스만 넣는게 아니라 어느 정도 제약은 필요하다.
Text box라면 문자를 입력받도록 해야하고, Number box라면 숫자를 입력받도록 해야할 것이다. 그냥 숫자만 쳤을때 형식에 맞게 auto formatting이 될 수 있도록 해줄 수도 있다.
password box라면 입력하는 것들을 별표로 가려주면 좋고, cutting이나 copying을 허용하면 안된다.
2) Selection boxes
여러 아이템을 선택할 수 있는 check box, mutually exclusive하게 선택할 수 있는 Radio button,
list box(프로그램 설치시 언어선택할때 쭉 리스트형태로 주로 나오는거), slider(볼륨 조절할때 있는거), 등등.. 종류는 다양하다.
> Input Validation
data가 유효한지 여기서 거르고 입력을 받아야한다. invalid data를 받아들여선 안된다.
완전한데이터인지, 포맷, 범위, 일관성, 등등... UI에서 인풋을 받을때 체크를 한다.
Output Design
system에서 생성된 data를 report하는 것이 output이다.
기본 원리
1) output report는 layout에 영향을 미친다.
2) 필요한 정보만 보여주고, 중요한건 윗쪽에 배치
3) Minimize bias (특히 그래픽으로 표현할 시) : 막대그래프 y축을 이상하게 배치하거나, 원형그래프를 3D로 보여줄경우 bias가 생길 수 있다.
> Outputs 유형
Detail report, Summary report, exception report, graph, media, hard copy(종이에 프린트) 등등 유형은 다양하다.
어떤 output을 줄지는 requirements에 따라 판단하면 된다.
HCI Layer는 Nonfunctional Requirements에 영향을 많이 받는다.
특히 Operational/Performance/Security/Cutural&Political Requirements가 영향을 많이 준다.
(operational은 H/W S/W 플랫폼 고르는데 영향을 줌)
'수업 > Software Design' 카테고리의 다른 글
| [Software Design] Physical Architecture Layer Design (0) | 2022.12.13 |
|---|---|
| [Software Design] Class and Method Design (0) | 2022.12.12 |
| [Software Design] Moving to Design (0) | 2022.11.12 |
| [Software Design] Behavioral Modeling (0) | 2022.10.19 |
| [Software Design] Structural Modeling (0) | 2022.09.27 |