Singleton usage is commonly considered an anti-pattern in the OOP world. Its static factory method means you can reach the one allowed instance of the class from anywhere in your application. Inappropriate usage can turn your code into spaghetti as every class couples itself to the Singleton rather than get what it needs through a more appropriate actor.

대략 해석하면.

싱글톤 패턴의 사용은 일반적으로 OOP 세계에서 안티 패턴으로 간주됨. 싱글톤의 정적인 팩토리 메소드는 어플리케이션의 어느곳에서든 클래스의 한 인스턴스에 접근할 수 있다는 것을 의미. 부적절한 사용은 스파게티 코드를 만들어 낼 수 있음.

라는 이야기.

예전에 as2.0에서 as3.0으로 넘어온 분이 하도 _root를 찾으시길래 Singleton을 보여드리면서 이게 _root 보다 훨씬 기똥찬 거라고 알려드렸던 일이 생각난다. ㅎㅎ

그 분이 작업하신 것은 아니지만 전체 Class들이 다 Singleton으로 되어있는 황당한 소스도 본 적이 있다.

나부터도 도저히 이해가 안가는 신기한 소스를 받아서 손봐야 할때는 애용하기도 했다.

이게 그러니까…

적절하게 한방 놓으면 그보다 좋을 수가 없는데 과하거나 엄한 곳에 쓰면 전체 소스의 신뢰가 땅에 떨어지는. 뭐 그런.

var targetDataGrid:AdvancedDataGrid = this.parent.parent.parent as AdvancedDataGrid;
if (targetDataGrid == null) {
    targetDataGrid = this.parent.parent as AdvancedDataGrid;
}
trace("targetDataGrid"+targetDataGrid);
if (targetDataGrid == null) {
    return;
}

이게 제대로 작동하는지도 잘 모르겠지만..;; 일단 눈에 보기부터 너무 거슬리는 코드다.
itemRenderer에서 AdvancedDataGrid에 접근을 하려는 의도였던 것 같은데.. 이런 식으로 뭐가 떨어질지도 모르는 parent.parent.. 식으로 null체크 하면서 찾아 들어가기 보다는 IDropInListItemRenderer 인터페이스를 구현하는 것을 추천한다.
IDropInListItemRenderer 인터페이스를 찾아보면

public function get listData():BaseListData
public function set listData(value:BaseListData ):void

참고: http://flexdocs.kr/docs/flex2/langref/mx/controls/listClasses/IDropInListItemRenderer.html

인터페이스를 사용하면서 구현해 주어야 할 것은 get/set 메소드 하나밖에 없다.
set함수에서는 BaseListData 타입의 값을 넘겨주고 있다.
BaseListData 클래스에는 4개의 속성이 있다.

label:String 리스트 클래스의 itemToLabel() Methods에 근거한 아이템 데이터의 텍스트 표현입니다.
owner:IUIComponent 이 아이템을 소유하는 리스트 object에의 참조입니다.
rowIndex:int 데이터 프로바이더내의 아이템의 인덱스입니다.
uid:String 이 아이템의 일의의 식별자입니다.

참고: http://flexdocs.kr/docs/flex2/langref/mx/controls/listClasses/BaseListData.html

이 중에 owner속성이 itemRenderer가 속한 AdvancedDataGrid 객체이다.
대략 보면

private var _listData:BaseListData;
private var _dataGrid:AdvancedDataGrid;
private var _dataField:String;
private var _dataProvider:ArrayCollection;

public function get listData():BaseListData
{
    return _listData;
}

public function set listData(value:BaseListData):void
{
    if (value == null) return;

    _listData = value;
    _dataGrid = value.owner as AdvancedDataGrid;
    _dataField = (value as AdvancedDataGridListData).dataField;

    _dataProvider = _dataGrid.dataProvider as ArrayCollection;
}

이런 식으로 사용이 가능하다.
AdvancedDataGrid에 접근한 이후에는 dataProvider라던지 기타 속성에 얼마든지 접근할 수 있다. 특히 자주 쓰이는- AdvancedDataGrid에 CheckBox를 itemRenderer로 사용하는 경우 등등에 매우 유용하다.

What

프로젝트가 수주된 후에 프로젝트 팀과 클라이언트가 처음 만나 팀과 클라이언트의 구성원을 소개하고 각 구성원의 역할을 논의하는 회의를 말한다.

Why

기본 형식은 이해관계자로부터 역할의 정의, 클라이언트를 포함 기타 기본 요소(일정, 상태 보고서)등에 대해 논의한다.

위험과 관련된 문제 -특히 일정에 영향을 미칠 수 있거나, 고객 만족도 감소로 이어질 수 있는 부분-에 대해 이해관계자로부터 명시적으로 언급함으로써 어떤 해결방안이 필요한지 상의할 수 있다.

품질 기준을 유지하기 위해 새로운 팀 구성원에게 설명이 필요할 경우, 프로젝트의 리더가 명료이 설명해 준다.

프로젝트 팀은 프로젝트의 목표, 일정, 프로젝트에 관한 지식 등을 보여줌으로써 고객들의 신뢰를 얻을 수 있다.

Procedure

1) Introduction of meeting participants

팀과 클라이언트의 구성원을 소개한다.

2) Project Review

Purpose of the project

Scope

Major deliverables

Risks

Assumptions

Estimated effort, budget and duration

목표와 범위, 중요한 산출물, 위험요소들 , 가정과 어느정도의 일정들이 포함된다.

3) Roles and responsibilities

역할(이슈, 의사소통의 핵심 역할 등)과  책임(유지보수의 책임 등)에 대해서 이야기한다.

4) Project approach and overall timeline

진행방법과 타임라인에 대해서 이야기한다.

5) Questions

6) Recap / summary

How

1. 사이트의 목적/ 비전에 대한 정의

2. 사이트의 개발 목표

사용자 관점에서의 만족도.

클라이언트 관점에서의 만족도.

3. 대상과 목표에 대한 정의

누가 이 사이트를 이용하는가? (사용자 분석- 나이, 경험, 교육 등…)

왜 이 사이트를 방문하는가? (필요, 흥미, 목적)

언제 어디서 이 사이트에 접속할 것인가? (사용자 환경)

어떻게 이 사이트에 접속할 것인가? (사용자의 컴퓨터 설정-연결속도, 해상도 등…)

4. 수행 작업 분석 및 우선 순위 작업 정의

이 사이트에서 무엇을 할 것인가? (업무, 컨텐츠, 기능…)

어떤 작업이 사용자에게 만족을 주는가?

어떤 작업이 사용자에게 가장 중요한가?

어떤 작업이 가장 많이 이용될 것인가?

어떤 작업이 사용성에 있어 이슈가 있을 수 있는가? (취약점)

얼마나 자주 이용할 것인가?

무엇이 사용자가 이 사이트를 다시 찾게 할 것인가?

5. 사용성의 확인

사용자들이 쉽게 적은 에러로 작업을 완료할 수 있는가?

사용자들이 능률적으로 빠르게 작업을 완료할 수 있는가?

사이트 이용 후에 사용자들은 어느 정도의 만족을 가질 수 있는가?

6. 기대, 요구사항 및 환경 설정에 대한 토론

7. 접근성, 요구사항의 결정

8. 가능한 자원과 요구되는 기술 수준의 정의

사이트를 업데이트 하고 유지하는데 어느정도 수준의 기술인력을 필요로 하는가?

9. 초기 필수 기술의 논의

10. 일정 및 프로젝트 계획

]]> http://www.shallaazm.com/my/uiux/139/feed/ 1 http://www.shallaazm.com/my/uiux/124/ http://www.shallaazm.com/my/uiux/124/#comments Thu, 08 Jul 2010 15:30:58 +0000 shallaa http://www.shallaazm.com/?p=124

What

윈도우 하나로 애플리케이션의 모든 페이지들을 보여준다. 옵션 메뉴나 오브젝트의 세부 내용으로 들어가면 윈도우 전체가 새로운 페이지로 대체된다.

Use When

handheld 디바이스, 휴대폰등의 소형 스크린과 같이 공간적 제한을 가졌거나 마우스가 없기 때문에 한 panel에서 다른 panel로 네비게이션이 어려운 TV와 같은 컨트롤상에 제한이 있는 경우.

복잡함의 정도에 제한을 두어야 하는 경우. 한꺼번에 많은 애플리케이션 윈도우가 열려있는 상황은 능수능란한 사용자에게 마저도 혼란을 야기할 수 있다. 또는 사용자들이 복잡한 스크린이나 미세한 인풋 디바이스를 잘 다루지 못하는 경우도 있다.

Why

One-Window Drilldown은 인터페이스를 단순하게 유지해야 할 때 사용된다. 하나의 윈도우에 모든 내용이 포함되어 있고 각 단계의 옵션들이 명확한 경우에는 사용자들이 다른 곳으로 시선을 돌릴 필요가 없다. 오늘날 모든 사람들이 단일 윈도우 내에서 뒤로가기/앞으로가기 페이지 모델을 통해 웹 브라우저를 사용하는 법에 대해서 알고 있다. 링크나 버튼을 클릭할 때는 현재 보고 있는 페이지가 다른 페이지로 대치될 것을 예상하며, “뒤로가기”를 클릭할 때는 이전에 있었던 페이지로 돌아갈 것을 기대한다.

How

단 하나의 윈도우만을 사용한다. 윈도우에 비해서 컨텐츠가 너무 크지도 너무 작지도 않게 세련되게 들어갈 수 있도록 panel을 구성한다.

panel에서 언더라인 링크, 버튼, 혹은 클릭 가능한 테이블과 같은 요소들이 다른 공간으로 들어갈 수 있는 “출입구”가 된다. 이들 중 하나를 클릭했을 때 현재의 panel은 새로운 내용으로 변경된다. 이렇게 해서 사용자들은 애플리케이션의 컨텐츠 안으로 더 깊이 뚫고 들어갈(drills down) 수 있다.

뒤로가기/앞으로가기 버튼들을 윈도우 내에 고정된 위치에 놓은다. 일반적으로 브라우저들은 이 버튼들을 상단 왼쪽에 둔다. “완료” 혹은 “취소” 버튼은 사용자들이 태스크나 선택을 완료하는 panel에 두어야 한다. 이러한 컨트롤은 사용자에게 “완료된 것을 닫는다.”라는 인식을 심어 준다.

원 윈도우 애플리케이션의 구조는 애플리케이션 구조에 대한 어떠한 그래픽 묘사도, 현재 위치에 대한 정보도 없기 때문에 사용자가 모든 공간을 종합하여 멘탈 그립을 형성해 내는 데 의존하고 있다. 이 패턴은 단순한 연속적 구조 혹은 계층적 구조에서 가장 효과적으로 쓰인다. 보조 장치로 Breadcrumbs와 Sequence Maps 패턴을 사용할 수도 있다.

특히 Hub and Spoke는 웹과 소형 디바이스에서 One-Window Drilldown 방식을 사용하여 구현되는 패턴이다.

Example

맥 OSX 시스템의 모든 속성 툴은 한 윈도우 안에 들어 있다. 왼쪽에 있는 시스템 속성이 메인 panel이고, 오른쪽의 독이 메인 panel에서 독을 선택하여 들어간 드릴다운 panel이다. 여기에는 오직 한 단계의 드릴다운 panel만이 존재한다. 상단 왼쪽의 “모두보기”버튼을 통해 메인 panel로 되돌아갈 수 있다.

맥 OS의 화면은 대게 넓은 공간에서 사용되지만 One-Window Drilldown 접근 방법을 선택하는 이유는 공간을 절약하기 위해서가 아니라 속성의 항목들이 많고 서브 panel의 형태가 다양하기 때문이다. 실제로 이 메인 panel은 많은 공간을 차지하고 있다. 만일 One-Window Drilldown 대신에 타일 형식의 Two-Panel Selector 윈도우를 썼다면 효율적이지 못했을 것이다.

]]> http://www.shallaazm.com/my/uiux/124/feed/ 0 http://www.shallaazm.com/my/example/77/ http://www.shallaazm.com/my/example/77/#comments Tue, 06 Jul 2010 11:17:57 +0000 shallaa http://www.shallaazm.com/?p=77

What

시각 장애가 있는 사용자를 위해 화면 내용을 음성으로 들려주는 스크린 리더와의 통신을 관리하는 클래스.

Use When

웹사이트 이용에 있어 필수인 부분은 필히 Accessibility를 구현해 주어야 하지 않을까? 특히 swf로 제작되는 네비게이션의 경우에는 필수라고 생각됨.

Why

1. 법률상의 이유

2. 윤리상의 이유

3. 공공봉사의 이유

4. 상업적인 이유

5. 공익적인 이유

2008년 4월부터 실행된 장애인 차별 금지법에 의해 웹사이트가 웹접근성에 맞추어 제작되지 않을 경우 처벌함.

2013년 4월 부터는 모든 법인 웹사이트에 장애인 차별 금지법이 적용될 예정.

How

Accessibility를 위해 구현해야 하는 부분은 크게 두가지이다.

키보드만으로 서비스 이용이 가능할 것.

스크린 리더 사용자를 배려할 것.

1. 키보드 만으로 서비스 이용이 가능할 것.

DisplayObjectContainer 에서 상속된 모든 클래스에는 tabIndex 라는 public 속성이 있다.

탭키를 누르면 tabIndex값이 작은 객체부터 큰 객체까지 순서대로 포커스가 이동한다.

경험적으로 tabIndex는 하나의 클래스에서 일괄관리 하는편이 나은 듯. 예를 들면 메뉴의 데이터를 핸들링하는 클래스에서 tabIndex라는 int타입 변수를 하나 두고 메뉴를 생성할 때마다 숫자를 하나씩 올려주는 방식.

마우스의 클릭 이벤트를 받는 객체에는 필히 키보드 이벤트를 같이 걸어주고 enter 키가 눌러진 경우 클릭 이벤트를 dispatch 해주거나 클릭 이벤트와 동일한 기능을 구현해 준다.

그렇게 되면 장애가 있는 유저는 탭키로 이동하여 엔터키로 선택할 수 있다.

탭키로 메뉴를 이동하는 경우 마우스 오버 / 아웃의 경우는 구현이 곤란하게 된다. 예를 들어 마우스를 오버하면 확장되면서 하위메뉴가 나오는 네비의 경우는 구현이 고민 될 수 있다. 하지만 생각을 조금 달리 해보면 오버시 메뉴가 확장되고 하위메뉴를 바로 선택한다는 개념은 눈이 보이는 사람의 경우에는 맞지만 눈이 안보이는 사용자에게는 오히려 혼란이 될 수 있다. 탭키로 대메뉴를 이동하고 선택된 메뉴의 페이지에서만 확장해서 하위 메뉴를 보여주는 것이 맞다.

마찬가지로 혼란을 피하기 위해 선택되지 않는 하위메뉴 객체의 경우는 visible을 확실히 꺼주는게 좋다. visible을 꺼주면 tabIndex 값에 상관없이 포커스를 받지 않는다.

2. 스크린 리더 사용자를 배려할 것.

Accessibility 클래스를 사용한다.

Accessibility가 기능을 하기 전에 Flash Player에서 스크린 리더에 연결할 수 있는 1~2초간의 지연 시간이 필요하다. setTimeout 메소드를 이용해 2초의 딜레이를 준 후에 Accessibility의 active 속성을 이용해 스크린 리더가 사용가능한지 여부를 체크한다. Accessibility의 속성이나 메소드등은 정적이므로 인스턴스를 생성할 필요가 없다. Accessibility.active 속성은 스크린 리더가 사용가능할 경우에 true를 리턴한다. true가 리턴된 경우(스크린 리더 사용가능) Accessibility클래스의 updateProperties 메소드를 호출해 스크린 리더에 엑세스 가능성 변경 사항을 업데이트 해준다. updateProperties 메소드의 경우는 한번만 호출해 주면 된다. 여러번 호출하면 성능이 떨어진다고 함.

스크린 리더에 의해 읽혀질 내용을 객체의 accessibilityProperties 속성에 설정해 주어야 한다. 모든 DisplayObject 에서 상속된 클래스에는 accessibilityProperties라는 AccessibilityProperties타입의 속성이 있다. AccessibilityProperties타입의 객체를 생성한 후에 생성된 객체의 name속성에 스크린 리더에서 읽혀질 내용을 설정해 주고 스크린 리더에 의해 읽혀질 객체의 accessibilityProperties속성에 설정해 준다. 스크린 리더 프로그램을 설치, 실행한 후에 탭키를 이용해 객체에 포커스를 옮기면 스크린 리더가 설정한 name 속성의 글을 읽어주는 것을 볼 수 있다.’

참고로 무료 스크린 리더기를 찾는 것도 쉽지 않았다. (Accessibility 관련해서는 자료가 별로 없는 편인 듯) 검색창에 “소리눈”을 검색하면 관공서 게시판에 올려진 스크린 리더 프로그램(소리눈)을 받을 수 있다. 제작사 사이트는 문을 닫은 듯(?)

덧붙여- swf를 html에 붙일때 wmode param값이 transparent(배경투명)이면 스크린 리더가 작동하지 않는다. 필히 window(default)로 처리할 것.

Example

1. 메인 클래스에서

private function init():void {
    setTimeout(updateAccessibility, 2000);
}

private function updateAccessibility():void {
    if (Accessibility.active)
        Accessibility.updateProperties();
}

2. 데이터를 처리하는 클래스에서

private var _tabIndex:int;

public function getMenuDatas():Array {
    var i:int, len:int = sampleDatas.length();
    var menuData:MenuData;
    var menuDatas:Array = [];

    for (i = 0; i < len; i++) {
        menuData = new MenuData();
        menuData.name = sampleDatas[i]["@name"];
        menuData.tabIndex = _tabIndex++;
        menuDatas.push(menuData);
    }

    return menuDatas;
}

3. 실제 스크린 리더에서 읽혀질 객체의 클래스에서

private function initListener():void {
    addEventListener(KeyboardEvent.KEY_UP, onKeyUpHandler);
}

private function onKeyUpHandler(e:KeyboardEvent):void {
    switch (e.keyCode) {
        case Keyboard.ENTER:
            dispatchEvent(new MouseEvent(MouseEvent.CLICK));
        break;
    }
}

public function set menuData(value:MenuData):void {
    var accessProps:AccessibilityProperties = new AccessibilityProperties();
    accessProps.name = value.name;
    accessProps.description = value.name;
    accessibilityProperties = accessProps;

    tabIndex = value.tabIdx;
}

1. twitter

Home 화면에서 프로필 아래 following 선택.

following 리스트 우측에 리스트 버튼을 클릭하면 위와 같은 창이 나온다.

가장 아래에 New List 를 클릭하여 리스트를 추가하고 추가된 리스트에서 체크박스를 선택하면 리스트에 추가된다.

2. facebook

Home 화면에서 우측 상단에 계정 선택후 친구편집 선택.

좌측의 관계 모두 보기 선택.

친구 리스트 상단에 새 목록 만들기를 선택하면 리스트가 추가된다.

친구 리스트 우측의 목록에 추가를 선택하고 리스트를 체크해 주면 리스트에 추가된다.

What

인터페이스 안에 두개의 panel을 나란히 놓는다. 첫번째 panel에는 선택할 수 있는 아이템들을 나타내고 다른 panel에는 선택된 아이템의 내용을 보여준다.

Use when

사용자에게 리스트의 전체 구조를 보여주는 동시에 스스로 선택한 순서에 따라 사용자의 페이스로 아이템을 보여주기를 원할때.

물리적으로 작업하는 화면은 충분히 넓기 때문에 분리된 두개의 panel을 보여줄 수 있다. 반면 휴대폰처럼 매우 작은 화면은 이 패턴을 사용할 수 없다. 그러나 블랙베리와 같은 화면은 가능하다.

Why

Two-Panel Selector는 이미 학습에 의해서 익숙해져 있다.  -윈도우 탐색기, 이메일 클라이언트, 웹사이트 등

사람들은 한 panel에서 아이템을 선택하고 다른 panel에서는 그에 해당되는 내용을 본다는 개념을 빠르게 이해한다.

두 개의 패널이 나란히 보여지면 시선을 쉽게 이동할 수 있음으로 사용자의 시선이 panel 사이의 긴 거리를 이동하는 물리적인 노력을 줄여준다.

시각적인 인지 부담을 줄여준다. 윈도우 전체가 변하지 않고 대부분의 영역이 고정되어 있음으로 사용자들은 변하는 영역에만 초점을 맞추어 볼 수 있다.

사용자가 기억해야 할 부담을 줄여준다. 이미 목록이 스크린 위에 떠있으며 “당신은 이곳에 있다”라는 이정표로 작용하기 때문에 사용자는 자신이 선택한 목록을 기억을 더듬지 않고도 바로 옆의 panel을 쳐다보기만 함으로써 인지할 수 있다.

How

선택할 수 있는 리스트 panel은 상단이나 왼쪽에 둔다. 왼쪽에서 오른쪽으로 글을 읽고 쓰는 사용자들의 시각적 흐름에 있어서 리스트를 보고 선택된 아이템에 해당하는 내용을 보는 흐름이 유리하다.

사용자들이 아이템을 선택하면 해당하는 내용을 즉시 두번째 panel에 나타낸다. 선택은 단 한번의 클릭으로 완료되어야 한다. 키보드-특히 화살표 키-로 선택을 변경할 수 있도록 해야 한다. 사용자의 물리적인 노력과 브라우징을 위해 소요되는 시간을 줄여주고 키보드의 사용성에도 기여한다.

선택된 아이템을 시각적으로 명확히 만든다. 선택된 아이템과 선택되지 않은 아이템을 명확히 구분지어 주어야 한다.

또한 Tow-Panel Selector에 리스트와 트리 같은 단순한 구성 요소들을 더하여 Sortable Table이나 Tree-Table과 같은 정보 표현 패턴으로 사용할 수 있다. Card Stack과 Overview Plus Detail은 Tow-Panel Selector와 밀접하게 관련되어 있는 패턴이다.

선택하고 보여주기 컨셉이 멀티플 패널을 통해 확장될 때, 계층구조를 통한 내비게이션을 용이하게 하기 위해서 Cascading Lists를 사용할 수 있다.

]]> http://www.shallaazm.com/my/uiux/58/feed/ 0 http://www.shallaazm.com/my/psychology/30/ http://www.shallaazm.com/my/psychology/30/#comments Sun, 27 Jun 2010 14:58:06 +0000 shallaa http://www.shallaazm.com/?p=30

=============

5가지 성격 특성 요소(Big Five personality traits)는 심리학에서 경험적인 조사와 연구를 통하여 정립한 성격 특성의 다섯 가지 주요한 요소 혹은 차원을 말한다. 신경성, 외향성, 친화성, 성실성, 경험에 대한 개방성의 다섯 가지 요소가 있으며, 성격 연구의 모델일 뿐 공식적인 이론은 아니다.

=============

출처: 위키백과

5가지 성격 요소

• Openness to experience (경험에 대한 개방성)
• Conscientiousness (성실성)
• Extraversion (외향성)
• Agreeableness (친화성)
• Neuroticism (신경성)

다섯가지 요소의 영문 스펠링 첫 자를 따서 OCEAN 모델이라고 불리기도 한다.

다섯가지 요소들은 각각 평가되어지고 평가되어진 대상이 모두 다섯가지 성격 요소에 대한 점수를 가진다는 특징이 있으며, 그로 인해 유형별로 분류해내는 분류방식과 구분된다.

1. Openness to experience (경험에 대한 개방성)

상상력과 호기심, 모험심, 예술적 감각 등으로 보수주의에 반대되는 성향.

개방성이 높은 사람들은 창조적이고 상상력이 풍부하며, 추상적이고 호기심이 많다. 사색을 좋아하고 독창적이며, 발명에 재능이 있고 예술적이며, 심미적인 경험을 소중히 여긴다.

개방성이 낮은 사람들은 관습적, 구체적, 전통적이며, 미지의 것을 좋아하기보다는 이미 잘 알고 있는 것을 선호한다.

2. Conscientiousness (성실성)

목표를 성취하기 위해 성실하게 노력하는 성향

성실성이 높은 사람들은 빈틈없고 의지가 되며, 믿음직스럽고 열심히 일하며, 목표 중심적이고 효율적이며 계획성이 뛰어나다.

성실성이 낮은 사람들은 계획성이 없고 지각을 잘하며, 부주의하고 충동적이다.

3. Extraversion (외향성)

다른 사람과의 사교, 자극과 활력을 추구하는 성향

외향성이 높은 사람들은 수다스럽고 에너지가 넘치며, 열정적이고 자기주장이 강하며 사교적이다.

외향성이 낮은 사람들은 말수가 적고 조용하며, 수줍음이 많다.

4. Agreeableness (친화성)

타인에게 반항적이지 않은 협조적인 태도를 보이는 성향

친화성이 높은 사람들은 남에게 도움을 주고, 사심이 없으며, 동정심이 많고, 친절하며, 용서하고, 신뢰하고, 사려 깊으며, 협조적이다.

친화성이 낮은 사람들은 단점이나 잘못된 점을 찾는 데 예리하고, 다투기를 좋아하며, 비판적이고, 가혹하며, 냉담하고, 퉁명스럽다.

5. Neuroticism (신경성)

분노,우울함, 불안감과 같은 불쾌한 정서를 쉽게 느끼는 성향

신경성이 높은 사람들은 불안해하고 쉽게 동요하거나 우울해지며, 걱정이 많고 침울하다.

신경성이 낮은 사람들은 침착하고 편안하며, 스트레스를 잘 다스릴 줄 알고 감정적으로 안정되어 있다.

OCEAN 테스트

평가 항목별로 답변유형을 참고해 점수로 환산해 테스트하고, 아래 계산식으로 채점.

평가 항목

1. Extraverted, enthusiastic.(외향적이며, 열정적이다.)
2. Critical, quarrelsome.(비판적이며, 화를 잘 낸다.)
3. Dependable, self-disciplined.(믿을 만하며, 자기관리를 잘한다.)
4. Anxious, easily upset.(불안하며, 쉽게 우울해진다.)
5. Open to new experiences, complex.(새로운 경험에 개방적이며, 복잡하다.)
6. Reserved, quiet.(수줍어하며, 과묵하다.)
7. Sympathetic, warm.(동정심 많으며, 따뜻하다.)
8. Disorganized, careless.(계획성 없으며, 부주의하다.)
9. Calm, emotionally stable.(침착하며, 감정적으로 안정되어 있다.)
10. Conventional, uncreative.(전통적이며, 창의성이 없다.)

답변 유형

1 = Disagree Strongly(완전히 부정한다.)

2 = Disagree Moderately(다소 부정한다.)

3 = Disagree a little(약간 부정한다.)

4 = Neither agree nor disagree(동의하지도 부정하지도 않는다.)

5 = Agree a little(약간 동의한다.)

6 = Agree moderately(다소 동의한다.)

7 = Agree Strongly(완전히 동의한다.)

계산식

개방성 = ( 8 – 10문항의 점수) + 5문항의 점수

성실성 = ( 8 – 8문항의 점수) + 3문항의 점수

외향성 = ( 8 – 6문항의 점수) + 1문항의 점수

친화성 = ( 8 – 2문항의 점수) + 7문항의 점수

신경성 = ( 8 – 9문항의 점수) + 4문항의 점수

예

개방성 = (8 – 2) + 6

성실성 = (8 – 4) + 5

외향성 = (8 – 5) + 5

친화성 = (8 – 5) + 6

신경성 = (8 – 4) + 5

평균

badge

AC_RunActiveContent.js
AIRBadge.as
badge.fla
badge.swf
default_badge.html
readme.txt
red_badge.html
test.jpg

이 있다.

필요한 파일

AC_RunActiveContent.js : 플래시 플레이어 버젼 확인 및 임베딩
badge.swf : 에어 어플리케이션을 설치해주는 링크를 가진 플래시 파일
default_badge.html : badge.swf를 임베딩하는 html파일 (이름은 바꿔도 됨)

위에 보이는 필요한 파일들을 웹서버에 업로드 해준다. (참고로 그대로 올릴 시 test.jpg를 업로드 하지 않으면 badge.swf에서 파일오류를 일으킨다. AIRBadge.as를 살펴보자.)
그리고 default_badge.html에서 badge.swf으로 넘기는 파라미터(FlashVars)를 수정해 준다.

default_badge.html

'flashvars','appname=HelloAIR&appurl=http://도메인/경로/HelloAIR.air&airversion=1.0&imageurl=test.jpg'

** 파라미터

appname       : 에어 어플리케이션 이름
appurl           : 에어 어플리케이션의 패키지 파일(.air)의 웹 서버 링크
airversion      : 에어 런타임 환경의 버젼
imageurl        : badge에 표시할 설치 아이콘 이미지
buttoncolor     : 설치 버튼의 색을 hex 컬러 값으로 지정
messagecolor : 버튼 밑에 나타나는 설치정보 관련 메시지 폰트 색깔 지정

파라미터 외에도 수정할 부분이 있으면 적당히 수정해 준다.
파라미터를 수정할 때에는 appurl가 중요하다.
파라미터를 받는 badge.swf의 소스파일을 보면

AIRBadge.as

...(생략)
_appURL = validateURL(encodeURI(parameters["appurl"]));

    // Validate URL: only allow HTTP, HTTPS scheme or relative path
    // Return null if not a valid URL
    private static function validateURL(url:String):String {
        if (url && url.length > 0) {
            var schemeMarker:int = url.indexOf(":");
            if (schemeMarker < 0) {
                schemeMarker = url.indexOf("%3a");
            }
            if (schemeMarker < 0) {
                schemeMarker = url.indexOf("%3A");
            }
            if (schemeMarker > 0) {
                var scheme:String = url.substr(0, schemeMarker).toLowerCase();
                if (scheme != "http" && scheme != "https" && scheme != "ftp") {
                    url = null;
                }
            }
        }
        return url;
    }

부분이 있다.
appurl에는 도메인, 경로를 정확히 적어주자.
여기까지가 필수.
필요하다면 badge.fla, AIRBadge.as를 수정해서 다운로드 받는 화면을 더 이쁘게 꾸며줄 수 있다.