1부에 이어 계속.....
그렇다면 이러한 Labeling은 어느 부분에 적용할 수 있을 것인가. 적용은 다음과 같이 할 수 있다.
- 메뉴명(한글, 영문)
- 파일명(HTML, Image, CSS, JS, Include 등)
- DB 구성명
1. 메뉴명
메뉴명은 고객들이 처음 접하는 명칭이다. 이때 메뉴명은 바로 고객이 접하는 단어로 구성이 되게 된다. 거의 많은 기획자들은 이러한 메뉴명을 작명하기 위해서 엄청난 고생을 한 것으로 알 고 있다. 특히 일부 업체에서는 영문과 한글의 메뉴별로 구성을 다르게 하거나 하나만 사용하거나 아니면 모든 것을 한글화 하거나…. 하지만 메뉴명을 작성시 다음의 사항은 반드시 중요하다.
- 타겟 고객이 사용하는 언어는?
- 한글만? 영어만?, 한글, 영문 혼용? 영어도 한글식 표시?
- 단어수 제한은 몇자까지?
메뉴명 작명시에는 이러한 원칙을 가지고 논해야 한다. 브래인스토밍시에는 이러한 제약을 두지 않고 논의하고 어느정도 정리를 시작할때는 위 조건을 걸고 해야 보다 축약적인 형태로 접근할 수 있다.
타겟 고객의 언어는 가장 중요한 요소이다. 이것을 지키지 않고 나머지 두가지로 메뉴를 선정하면 결국 특징없는 것이 되고 말것이다. 먼저 고객이 사용하는 언어가 무엇인지 고객의 입장에서 언어를 이해하는 것이 중요하다. 실버사이트를 제작하는데 전문적인 기획자의 언어를 가지고 메뉴를 적용할 경우 어떻게 될 것인가!! 영문표현보다는 보다 고객이 이해하기 쉬운 단어로 적용해야 한다는 것은 쉽게 알 수 있다.
영문표현은 우리가 흔히 쓰는 단어들이 다 영문표현이다. 메뉴, 사이트맵, 링크, 로그인 등 우리는 간단하다고 생각되는 언어들이 다른 고객층에는 어려울 수 있다는 점을 반드시 이해해야 한다. 또한 언어를 선택할 때 중요한 것은 바로 글씨크기이다. 현재 웹사이트의 표준 크기는 9pt다. 궁금하면 웹페이지의 소스보기에서 상단이나 중간에 스트립트로 정의한 것이나 아니면 css링크를 보면 쉽게 알 수 있다.
그런데 아직도 많은 기획자나 디자이너들은 9pt가 이쁘다고 아무런 고민없이 만들기도 한다. 문제는 바로 이때도 고객이다. 고객이 사용하는 언어가 큰가 작은가도 바로 고민을 해야 하는 것이다. 또한 9pt는 좋을 수 있지만 요즘처럼 모니터의 해상도가 높아지는 경우 이러한 글씨크기의 선택은 보다 신중하게 고객의 입장으로 접근해야 한다.
그리고 한글과 영어에 대한 선택은 고객의 특성에 대한 언어가 정해지면 거의 결정이 된다. 하지만 이때 중요한 점은 바로 한글과 영어의 혼용이다.
- 목차 – Menu – 메뉴
- 도움말 – Help – 헬프
자 위 3가지가 바로 한글과 영어에 대한 혼용 예이다. 한글로 할것인지 영어로 할 것인지 아니면 영어를 한글표현으로 할 것인지 이것이 일된적 정책으로 정해져야 한다. 그래야 이후 하위 메뉴나 페이지에 사용되는 Labeling에 모두 동일하게 적용하게 되는 것이다.
이렇게 정해지면 이제 축약을 해야한다. 마냥 좋은 단어라고 모두다 메뉴명으로 적용할 수 없다. 디자인적 관점과 Navigation에서 정의한 해상도, 영역, 메뉴위치등을 고려해서 메뉴명을 확정해야 한다. 이럴때 사용하는 것이 바로 단어수 제한이다.
이것은 디자인적 요소 및 이해도를 고려하는 어려운 작업이라 할 수 있다. 단정된 느낌의 일정한 단어수를 유지할 것인지 아니면 이해를 쉽게 할 수 있게 단어수를 어느정도 러프하게 가져갈 것인지 선택을 해야하기 때문이다. 그렇다고 1024*768 베이스의 좌측 메뉴를 사용하는데 10자가 넘어간다거나 무조건 풀어서 쓰는 것은 바람직하지 않다.
그렇기 위해서 단어수는 이러한 고려를 통해서 정의를 하는 것이 좋다. 정의를 하게 되면 이후 모든 하위 메뉴에 적용하여 사용할 수 있게된다.
2. 파일명
메뉴명은 고객적 접근이라면 파일명은 바로 내부적 접근이라 할 수 있다. 명명된 메뉴명에 따라서 모든 파일에 대한 일정한 규칙으로 Labeling 작업을 진행하게 된다.
왜 이러한 작업을 해야 하는가. 그것은 바로 당신이 없다고 생각되었을 때 당신의 업무를 하는 사람이 효율적으로 관리할 수 있는 요소를 제공하기 위한 작업이기 때문이다.
어쩌면 이러한 파일명에 대한 Labeling 규칙이 없는 경우 사이트의 구축이후 유지보수에 있어서 사람에 의존하게 되는 경향이 크게 된다. 왜냐하면 개발자나, 디자이너만이 알고 있는 경우가 많기 때문이다. 어디에 어떤파일을 저장했고 그 저장명은 어떤것이다!! 이것은 만든 사람만이 알게 되지만 결국 시간이 지나가면 이러한 만든 사람도 그것을 잊어버려 유지보수시에 시간이 계속 소요되게 된다.
파일명은 다음과 같이 접근한다.
- Directory 구성도(Directory Navigation)
- Directory 영역 정의
- Directory Labeling
- File Labeling
Directory 구성도는 내부 관리가능한 형태의 서버 Directory 구조도를 정의하는 작업이다. 메뉴별 Directory를 구성할 것인지 아니면 다른 규칙 예를들면 HTML 파일, Image 파일, 개발관련 파일을 따로 관리하는 형태로 구성할 것인지에 대한 정의를 한다.
이것은 개발자 역할이 아니냐고 할 수 있다. 하지만 어디까지나 설계는 기획자의 몫이다. 개발자는 참여를 하고 기획자와 논의 하여 정의를 하는 것이다.
Directory 구성도는 다음과 같이 할 수 있다. (메뉴별 구성의 예)
위와 같이 정의를 하게 된다. 이런 방식으로 초기 정의를 하고 이에 따라서 이후 생성되는 파일들을 해당 Directory에 맞게 저장하게 된다.
이때 중요한 것이 바로 Directory 영역 정의 이다. 위의 그림에서도 보듯이 이미지 영역이 두개로 나누어져 있으며 안의 내용에는 공통과 업무별 이미지로 나누어져 있음을 알 수 있다. 이것은 하나의 Directory에 저장되기 위한 영역의 정의라 할 수 있다.
만약 위와 같이 하지 않고 Image Directory안에서 업무별로 나눌 수 있다. 하지만 이 경우 필자의 경험에 비추어보면 이후 변경시에 혼동으로 인해서 간혹 문제가 발생할 수 있는 점이 있다.
위와 같이 영역정의를 하면 그 장점은 다음과 같다.
- 작업자는 자신의 작업되는 Directory만 접근하여 작업 효율성 증대
- 업무별 혼동을 최소화 하여 유지보수 또는 변경시에 빠르게 작업가능
- 담당자 변경시 담당자와 상관없이 위 문서를 통해서 작업 범위를 빠르게 습득
- 문제된 사항에 대한 변경시 빠른 대처가 가능하다.
하지만 이것은 권장이지 기획자가 더 좋은 Directory 구성과 정의를 할 수 있을 것이다. 기획은 정해진 것이 아니니 이것은 독자들의 생각을 넓히는 계기로 하여 더욱 좋은 형태를 만들어 보도록 하자.
이렇게 구성과 정의가 끝나면 이제 본격적인 Directory의 Labeling을 시작해야 한다. 이때 중요한 것은 위 구성도에 따라서 Labeling이 달라질 수 있다는 점이다.
대개 내부적 Directory Labeling은 그냥 직관적으로 접근할 수도 있겠지만 일단 중요한 것은 각각의 Directory의 소속을 명확히 해주는 것이 중요하다. 즉 1 Depth – 2 Depth – 3 Depth에 대한 정의를 의미하는 것이다. 동일한 Image Directory를 쓴다면 어디 소속인지는 알게끔 하는 것이다.
예를 들면
1 Depth Directory – Love, Image
Love 2 Depth Directory – Love, Image
이렇게 두개가 동일하게 존재할 경우는 다음과 같이 할 수 있을 것이다.
1. Love > Love, Love > Image
2. Love > Love_L, Love > Image_L
이처럼 두가지의 Directory명을 정의할 수 있다. 이것은 기획자가 초기 Directory Labeling을 할 때 정의하면 좋지만 필자는 2번을 선호하는 편이다. 이것은 1 Depth에 소속된 2 Depth의 Directory를 명확히 나타내 주게 되어서 작업자는 작업시에 Directory명에 따라서 해당 위치를 쉽게 알 수 있다.
이렇게 Directory Labeling을 하면 이에 따른 파일명도 같이 해주면 된다. 문제는 파일명에 있는데 소속된 곳을 표시하느냐에 따라서 파일명이 무리하게 길어지는 경우도 발생을 한다. 즉 깊이가 4 Depth 이상으로 갈 경우 이러한 Directory 구성도에 따른 파일 명명에 어려움이 따르게 된다.
하지만 가급적 파일명에 대한 Labeling은 Directory에 대한 정보를 어느정도 고려하여 작성한다면 이후 관리측면의 강점으로 작용할 수 있게 된다. 일단 Directory 구성도에서 각각의 파일별 분류를 통해서 나누어 놓았기 때문에 이러한 파일명은 가급적 서비스를 직관적으로 알 수 있도록 한다.
단 이때 주의할 사항은 바로 파일명을 정의할때는 영문으로 사용한다. 예전 개발자가 파일명을 한글을 영문으로 표기(sarang – 사랑)으로 해서 고생한 적이 있는데 반드시 보편적이고 명시적인 단어로 본인만이 아는 단어는 반드시 배제하여 적용해야 한다.
3. DB 구성명
파일명까지 Labeling이 완료되면 이때 이에 대한 정의문서를 토대로 DB 요소 정의에 대한 Labeling을 진행하게 된다. 이때는 가급적 해당 Labeling은 기존의 Directory나 파일명과 연관된 정의를 하는 것이 좋다.
이것 또한 내부적 Labeling이기 때문에 고객이 아닌 이후 작업자들을 위한 문서이기 때문에 모호한 표현보다는 작업자들이 쉽게 이해할 수 있는 문서로 정의하는 것이 중요하기 때문이다.
그리고 DB에 대한 정의 문서는 다른 개발자들이 DB 요소를 사용하여 개발할 때 보다 빠르게 이해하고 에러를 최소화 하기 위한 수단으로 제공된다. 이러한 정의를 통해서 개발에 참여하는 모든 팀원들에게 위 사항에 대한 교육을 진행하면 보다 효율적인 프로젝트 운영이 가능할 것이다.
이처럼 IA의 Labeling에 대해서 중점적으로 들추어 보았다. 사실 IA에 있어서 중요한 것은 바로 아는 것이 아닐까 한다. 시시각각 만들어지는 사이트들은 어느순간에 이전 것이 되거나 사라지는 경우가 다반사다. 물론 분석단계의 어려움도 있지만 이러한 체계적인 IA에 대한 고객과 내부 관리자 그리고 이후 유지보수에 이르기까지 고민하여 작업된 문서의 부재도 한몫을 했을 것이라 생각한다.
참.. 가장 중요한 것!!
그것은 바로 IA 작업은 모든 팀원들이 같이 하거나 아니면 최소 각 분야별 담당자들이 모여서 같이 논의해야 한다는 점이다. 이것은 기획자의 롤이기도 하지만 이후 디자인과 개발파트에서 이해하고 진행해야할 요소기이기 때문이다.
이러한 것을 할 때 기획자 단독으로 하면 자신이 만족할지 모르지만 이해당사자들이 이해할 수 있는 수준으로 가지 못하면 결국 쓰래기가 되고 만다. 아니면 그냥 이해하지 않고 준대로 만들어 이후에 문제요소가 발생할 수도 있게 된다.
일단 IA 설계는 바로 고객의 언어이자 내부 팀원들의 언어가 되어야 한다. 모두 같은 목소리와 같은 말로 프로젝트중의 커뮤니케이션의 문제를 최대한 줄일 수 있는 요소이고 이후 작업시에 일정한 룰에 의해서 체계적으로 진행하고 완료된 이후에도 사람 즉 담당자의 변경과 상관없이 안정적으로 사이트를 운영 관리할 수 있는 힘이 실리게 되는 것이다.
경력이 많든 적든 만약 이러한 IA에 대해서 부족한 점이 있다면 반드시 자신을 체계화 시키기 바란다. 지금처럼 단명하는 사이트를 줄줄이 만들지 말고 오래오래 묵묵히 자라는 나무들 처럼 꾸준히 성장하는 사이트를 만들기 바란다.
