[소팅]문제는 '오름차순'버튼이 아니라, 라벨명이야.

https://github.com/itsgoingd/clockwork-chrome/issues/75

테이블헤더TableHeader에 정렬 조작버튼을 끼얹기

복잡한 테이블에는 테이블헤더TableHeader에 정렬 조작버튼을 쏙 끼워넣는 것으로 통제에 대한 부담을 덜고 싶어진다.

버튼을 보자마자 기능을 알아차리기 쉽기 때문이다. "요 열에 대해서는 내림/오름차순 정렬하면 되겠구나"

((애매함 존 발생)) "기왕 붙이는 거 모든 열에 다 갖다 붙이자."

백오피스 테이블이 지저분한 이유는 기능을 빼고 더할지 의사결정할 때에, 애매하면 일단 다 넣었기 때문이다.

 

ㄱㄴㄷ/ABC순 정렬이나 끼얹을까? 삑! 게으릅니다

Alphabetical Order는 누구나 알고 '직관적'이라는 이유로 끼워 넣는다면, 정작 우리 서비스 도메인에서 중요하게 봐야 하는 배열논리가 잘 안보이게 된다. 실제 사용성에 입각해서 정렬을 구성해야 한다.

 

소팅의 사용 맥락을 고려하기

또한 소팅은 대체로 걸러내기 위해 사용되지만, 간혹 소팅에 의한 모든 순서값이 중요한 경우도 있다.

예로 쇼핑몰에서 고객은 소팅으로 사용자의 짤주머니이다. 앞페이지에 높은 순위의 결과값을 몰아놓고 취하려 하지, 중간에 있는 것들을 포커싱하려는 게 아니다. 하지만 데이터를 다루는 서비스에서는, 소팅으로 매겨진 순서값이 연산의 결과값이고, 그 매겨진 순서값을 활용하는 경우도 있으므로 모든 순서의 배열이 중요하다.

 

그러므로 데이터 목록을 잘 통제하게 도우려는 목적이라면 이름순 소팅은 의도에 맞을 때만 허용해야 한다.

주소값에 알파벳 오름/내림차순은 아무에게도 의미없을 것이다. 혹시나 알파벳 오름차순에 다른 의미를 부여한 데이터를 복합해서 패턴을 찾는 연구라면 모를까.

 

1.소팅하여 앞페이지에 나온 것이 의미있거나

2.데이터합성할 때 소팅으로 매긴 순서를 가지고 뭔가 해보려 할때

가 아니면 모든 열에 소팅컨트롤 버튼을 남용하지 말자.

 

• 모델명 - Beoplay, Level, Acton, JBC, Yamaha등등을 알파벳 내림차순으로 정렬했다. 몇개의 카테고리가 있다면 필터가 더 적격임을 알 수 있다.
• 사람의 이름 - 고유한 이름값이 대량으로 있는 데이터면, 오름/내림차순이 의미있을 수 있다.

 

인더스트리와 업무 목적에 맞게 서치 방식을 적용하자.

 

 

라벨명

이건 소팅을 붙여야돼 말아야돼? 헷갈리는 게 있다.

모든 화근은 라벨명으로부터 시작된다.

• 프로모션(라고 해놓고 프로모션명이 나오는 필드) -> 프로모션명(O)으로 고치고 필터링 제공
• 차정명(자동차산업에서 기준정보 중에 차량정보라는 문서단위로 취급상품을 관리하는데, 그 단위를 대표하는 title) -> 차정명 자체의 룰이 연식+모델명+프로모션명 상품의 등급을 나눌 수 있는 카테고리 정보를 포함하고 있다면, 연식에는 소팅을 넣어야할 수도 있다.
• 예약일(이라고 해놓고 일시가 다 나오는 필드) -> 예약일시(O)로 고치고 소팅 제공

 

그러므로 어떤 서치방식을 줄 지 결정하기 전에, 라벨명 규칙을 잘 만들고 교정해야한다.

라벨명이 의미하는 행위가 포괄적이거나 정확하지 않아서, 소팅을 어떻게 해준다는 것인지 모호해지는 문제가 생긴다.

데이터 전문가분들은 라벨명 만들 때 어떻게 하시는지 들여다 봐야겠다고 생각하는 요즘.

 

데이터 다루는 분이 속성명에 대해 고민한 에세이인데, 일부 공감가서 올려봅니다.
https://dataprofessional.tistory.com/172?category=729688
https://dataprofessional.tistory.com/167
-‘누가 무엇을 ~한 도메인’ 식으로 의미가 통하도록 정한다는 게 핵심입니다.
-간혹 ‘주+채무‘와 ‘주채무‘를 둘 다 허용하기도 하는데, 이는 매우 느슨한 표준화 정책입니다. 해당하는 대상이 많아질 때는 표준화를 안 한 것과 비슷한 상태가 됩니다. 가능한 엄격한 원칙을 정해야 하는 게 표준화입니다. 사소한 예외가 쌓이지 않도록 하는 게 표준화의 가장 중요한 원칙입니다. 한 글자 단어를 표준 단어로 허용하지 않으면 ‘주+채무‘는 원천적으로 사용하지 못하게 되죠. 생각할 필요도 없습니다.비(費) 또한 유사한데요. ‘비’를 허용하면 ‘비용‘과 혼용해서 사용할 수 있습니다. ‘사업+비‘와 ‘사업+비용‘이 같이 사용되는 것이죠. ‘관리+비‘와 ‘관리+비용‘, ‘감가+상각+비‘와 ‘감가+상각+비용’ 등 많이 발생할 수 있습니다. 이런 현상도 ‘비(費)‘를 단독으로 사용하지 못하게 하면 다소 해소됩니다. 대신 ‘관리비’라는 복합어를 등록해야 됩니다.