라디오버튼, 드롭다운 사용 구분

Radio buttons allow users to select one option from a set. – material.io

지인이 페북에 공유한 브런치글(https://brunch.co.kr/@toqha7822/10 中 3. 옵션이 적을 경우 라디오, 옵션이 많을 경우 셀렉트 UI를 활용하자)을 보면서, 예전부터 정리하려고 했던 내용이 떠올랐다. (위 브런치글에서 셀렉트 UI라고 지칭한 것을 아래에서는 ‘드롭다운-dropdown’으로 지칭한다.)

고객사에서 만든 UI Guide Document(굳이 구분한 것은 GUI 작업은 수행사에서 했기 때문)를 전달 받아 화면설계서(스토리보드)를 작성한 적이 있다. 거기는 프로젝트 준비를 오랫동안 준비하면서 UX 전문인력을 채용하여 TF에 있었고, 운영 경험도 많아 세부적인 UI Component까지 사전 정의가 되어 있었다. 물론 서비스 전면개편으로 적용하다 보니 세부 항목들이 수정, 추가되기도 하고, Guide에 정의된 각 Component를 어떤 경우에 사용할 지는 계속 논의를 했는데 그 중 대표적인 것이 선택 UI였다.

체크박스(Checkboxes)는 다중 선택이 가능한 경우, 라디오버튼(Radio buttons)은 단일 선택이 가능한 경우로 하여 기능적인 차이가 명확하여 별 이견이 없었다. 그러나 드롭다운 역시 단일 선택 기능을 제공하므로 라디오버튼과 드롭다운의 경우는 구분이 필요했다.

초기 정리되었던 기본 원칙은 다음과 같다.

  1. 선택 항목이 적고 단답형인 경우 라디오버튼으로 한다. ex) 예/아니오, 남/여, 동의/미동의
  2. 선택 항목이 많은 경우 드롭다운으로 한다. ex) 출생년도, 전화국번, 이메일 목록

그러나 선택사항의 많고 적음으로만 구분하는 경우 몇개까지를 라디오버튼으로 할지에 대한 추가 논의가 필요하다. 또한 선택 항목의 내용이 긴 문장형으로 구성이 필요한 경우 드롭다운 형태로 할 때 문장 길이에 따라 들쭉날쭉하고 보기가 불편한 점이 발생한다(모바일 UI일 때 더욱 그러하다). 하여 선택 항목에 대한 사용자의 인지 여부와 가독성을 두고 다음과 같이 보완을 한다.

선택 항목을 한눈에 파악하고 빠르게 판단이 필요한(가능한) 경우 라디오 버튼으로 한다.

  • 예/아니오, 동의/비동의는 부정(아니오)에 대한 선택이 가능함을 보여주기 위해서 라디오 버튼 형식이 유효하다.
  • 설문 문항과 같이 선택항목의 내용이 긴 문장형으로 구성되거나 항목간 비교가 필요한 경우 라디오 버튼 형식이 효율적이다.
  • ‘예’만 선택 가능한 경우에는 체크박스 형태로 구성한다. ex) 약관동의 UI

선택 항목에 대해 이미 인지하고 있고, 단순 선택하는 경우 드롭다운으로 한다.

  • 전화국번, 이메일주소-도메인, 국적, 은행, 통화 등 항목은 다수이나 선택 내용이 명확하고 무엇을 선택해야 하는지 관습적으로 이미 아는 경우
  • 성별(남/여) 선택과 같이 항목이 적은 경우는 드롭다운 형태도 가능하나 터치(클릭) 액션을 한번 줄이는 효과를 고려하여 라디오 버튼으로 한다.

대략 위와 같이 기준을 정하고 UI 설계를 진행하면서 필요한 경우 개별 논의를 하기로 했으나, 추가 검토는 발생하지 않았던 것으로 기억한다. 이후 다른 프로젝트에서 UI Guide를 논의할 때 위 내용으로 제안하였고 큰 이견들 없이 진행되었다.

정보의 양에 따라 위 기준처럼 각 항목을 단순히 나열(드롭다운)해도 될 것이고, 해당 항목에 대한 보다 자세한 설명을 제공(라디오버튼)할 필요도 있다. PC 또는 모바일 기기별 해상도에 따라 구성이 달라질 수도 있을 것이다. 중요한 것은 기능적인 접근이 아니라 ‘선택(Select)의 순간에 필요한 정보를 어떻게 보여주는 것이 사용자의 결정에 도움이 될까?’라는 질문인 것 같다.

뱀발1: material.io Component에 selection-control(체크박스, 라디오버튼, 스위치)이 별도의 메뉴로 제공되었는데 현재는 사라지고 각각의 메뉴로 제공된다. 다만 구글에서 검색을 하면 다음 url로 접속이 가능하다. https://material.io/components/selection-controls meterial.io 내용이 수시로 바뀌는 것 같으니 가끔 찾아봐야겠다.

뱀발2: select box와 dropdown 의 차이에 대해서도 정리해봐야겠다.

개인화, 맞춤서비스 메모

하나씩 끄집어 내보는 중. Pixabay.com 이미지.

사용자(User), 고객 개인의 목적, 니즈에 맞는(맞춤) 컨텐츠와 서비스를 제공한다는 개념으로 ‘대충’ 이해하고 있다. 대개 프로젝트에 중요한 화두로 제기되어 왔고 예정된(불확실하다는 뜻이다) 다음 프로젝트에서도 주요 꼭지를 이루고 있어 다시 찾아본다.

개인화(personalization)는 상인이 소비자의 이름, 관심사, 과거 구매이력을 기반으로 시장에 전달할 메시지를 조정하여 특정 고객에 맞는 마케팅 메시지를 만들어내는 것을 말한다. 개인 간의 차이를 수용하는 기술로 정의되기도 한다.

https://ko.wikipedia.org/wiki/개인화

한글 위키의 설명이 짧은듯 하여 영문 위키를 찾아보았다. 개인화의 역사와 디지털미디어, 인터넷, 지도, 휴대전화 등 각 영역별 설명과 고객의 역할 참고 문헌 등 좀더 많은 정보가 나온다. https://en.wikipedia.org/wiki/Personalization

이 중 흥미를 끄는 것은 개인화의 역사.

The idea of personalization is rooted in ancient rhetoric as part of the practice of an agent or communicator being responsive to the needs of the audience. When industrialization led to the rise of mass communication, the practice of message personalization diminished for a time. But the significant increase in the number of mass media outlets that use advertising as a primary revenue stream, and as they sought to attract customers through buying space and time in forms of entertainment and information, they made efforts to gain knowledge about the specific demographic and psychographic characteristics of readers and viewers.

https://en.wikipedia.org/wiki/Personalization 중 일부

대충 발번역을 하자면 개인화는 청중의 기대(needs)에 맞는(반응하는, responsive) 메시지를 전달하려는 고대 수사학(ancient rhetoric)에 뿌리를 두고 있고, 산업화 이후 매스커뮤니케이션의 발달로 쇠퇴하였으나 광고를 주요 수익원으로 하는 매스 미디어의 증가로 (광고 게재를 위해 고객을 유치해야 하고 이에 맞는 즐길거리(Entertainment)와 정보를 제공하기 위해) 인구통계학적 특성과 심리적 특성에 대한 지식을 얻기위해 노력했다…

중요한 것은 기대에 반응하는 것(being responsive to the needs of the audience)이다. 인구통계학적 특성과 심리적 특성에 대한 지식은 ‘기대’를 알기 위한 수단으로 보인다. 통계에 의한 인구통계학적 특성은 불확실성을 줄여 주기는 할 것이다. 그러나 30대 미혼 직장인, 1인 가구의 의식주 지출 통계를 이용하여 간편조리식 시장의 확대를 논하는 것과 지금 골목길 편의점 문을 열고 들어서는 사람이 무엇을 살 것인지를 예측하는 것은 다른 문제일 거 같다.

개별 고객의 니즈를 파악하기 위해서는 기존 행위 데이터를 기반으로 할 수 밖에 없는데 이제는 개인화를 넘어선 초개인화를 논하기도 한다. 개인화와 초개인화의 차이점에 대해서는 아래 기사를 참고해보면 좋을 것 같다. (아직 자세히 읽지 못했다. 211208)
https://www.mobiinside.co.kr/2021/02/01/algorithm-personalization/

데이터 기반으로 개인화 추천 UX를 구현하는 사례는 다음 블로그 글을 참고해 보자. (아직 자세히 읽지 못했다. 211208)
https://www.beusable.net/blog/?p=1359

개인화가 상품에 따라 어떤 효과가 있을지에 대해서는 아래 논문을 읽어보려 한다.
이동주. 전자상거래의 수용에서의 개인화의 역할에 대한 연구: 기술 수용 이론과 정보 프라이버시 이론의 통합. NRF KRM(Korean Research Memory), 2008.

관련해서 아래 논문도 참고가 될 듯 하다.
최지은. “고객들은 항상 개인화 제품을 선호하는가?.” 국내박사학위논문 高麗大學校 大學院, 2013. 서울

꼬리에 꼬리를 물다 보니 끝없이 이어진다. 역시 위키는 문제의 시작이지 끝은 아닌 것 같다.

TBD.

하코즈메~ 싸워라! 파출소 여자~ 촬영장소와 출연배우에 대한 메모

나무 위키에서 가져온 이미지.

왓차에서 건졌다.

원작 만화가 있는 일본 드라마이다. 원작만화는 코단샤의 주간만화잡지 ‘모닝’에서 계속 연재 중이다. (그러므로 드라마 역시 앞으로 시즌제로 해서 계속 이어질 가능성이 높아 보인다.)

한적한 소도시 파출소에서 근무하는 여자경찰관들의 이야기다. 대략적인 줄거리와 출연진은 다음 나무위키를 참고하자.
드라마 하코즈메~ 싸워라! 파출소 여자~ 알아보기

원작 만화에 대한 소개는 다음 링크를 참고하자.
만화 하코즈메 ~파출소 여자의 역습~ 알아보기

하코즈메(ハコヅメ)라는 것은 경찰서(ハコ)づめで근무(勤務する)라는 뜻도 있고 토다 에리카가 갖고 있는 박스(ハコ)에 담긴 비밀을 지칭한다고.
https://blog.naver.com/kkoii/222423972586

만화 작가는 실제 전직 경찰이어서 사실성이 높다고 한다. 그러나 내 생각엔 그보다 지방 소도시 교번(한국의 파출소 개념인듯 한대 그보다 규모는 더 작은듯. 상주 인원 2~3명 정도)을 중심으로 일어나는 일상생활을 보여주기에 그런 면이 더 부각되는 듯 하다. 교통딱지를 끊고, 지나가는 아이들과 인사하고, 좀도둑을 잡으러 다니고, 동네 주민 싸움을 말리고, 치매 할아버지 길을 찾아주고…

드라마의 배경 장소는 주인공이 졸업한 경찰학교에 기재된 내용으로 추정하여 사이타마현 내 특정 지역으로 생각하고 마치야마, 마츠야마, 마쓰야마 등으로 검색해 보았으나찾을 수 없었다. 다시 드라마를 돌려보며 한자음을 확인하여 町山를 확인하여 다시 검색해 보았으나 역시 찾을 수 없었다.
다만 아래 사이트와 같이 드라마에 나오는 여러 장소들에 대한 정보. 사이타마현이 아닌 관동지방 여러 현과 도시를 이용하고 있음을 보여준다(마치야마 교번이 가상의 장소라는 것을 확인할 수 있다.).
https://locatv.com/hakodume-location00/#index_id1

보충) 일본판 위키를 보면 만화에서는 ‘오카시마현 마치야마시’로 가상의 ‘현’과 ‘시’로 설정된 것이 확인된다. 드라마에서만 ‘현’을 ‘사이타마’로 표현한 것으로 보인다. 일본판 위키 확인하기

주인공 ‘후지 세이코’역을 맡은 ‘토다 에리카’는 영화 ‘데스노트’에도 출연했던 인물인데 전혀 몰라봤다. 데스노트가 2006년 상영된 것이니 대략 15년의 세월이 흘렀던 탓이기도 한데, 일본 현지에서도 데뷔 때에 비해 모습이 많이 달라졌다는 이야기들이 많다고 하니 딱히 나만의 문제는 아닌 것으로 생각되지만.
데스노트에서의 토다 에리카 모습 보기

또다른 주인공 ‘카와이 마이’ 역을 맡은 ‘나가노 메이’는 지난해 찾아봤던 영화 ‘내 이야기!!’에서 인상 깊었던 ‘야마토 린코’역을 맡았던 배우인데 전혀 알아보지 못했다.
내 이야기!! 에서 나가노 메이 모습 보기

8부 정도에 등장하는 육아휴직 중인 선배경찰관이 잠시 등장하는데, 어디선가 본 기억이 나서 한참을 생각했다. ‘드래곤 사쿠라 2’에 등장했던 ‘하라 겐타’의 담임 역할이었던 배우다. 입술 아래쪽의 작은 점이 있어 일치할 수 있었다(그러고보니 ‘미스터 빈’의 로완 앳킨슨을 좀 닮은 듯도. ^^;;). 나무위키와 구글링 등을 통해 뒤져봤으나 이름은 확인하지 못했다.

일본 드라마는 (편차가 있긴 하지만) 손발이 오그라드는 교훈의 부담에도. 대략 1시간 이내, 10부작 내외로 편성되기에 전개가 빠르고 장르가 다양하여 골라 보는 재미가 있다. 이번에도 괜찮았다. 다음 시즌이 기다려진다.

나는 왜 프로토타입 툴을 쓰는가?

언제나 Why? 를 먼저 생각한다. 그러니 힘들지만 차근차근 한 걸음 한 걸음 나아간다.

이 질문에 대한 답은 프로토타입(prototype)에 대한 정의에서 시작된다.

프로토타입(prototype)은 원래의 형태 또는 전형적인 예, 기초 또는 표준이다. 시제품이 나오기 전의 제품의 원형으로 개발검증과 양산 검증을 거쳐야 시제품이 될 수 있다. 프로토타입은 ‘정보시스템의 미완성 버전 또는 중요한 기능들이 포함되어 있는 시스템의 초기모델’이다. 이 프로토타입은 사용자의 모든 요구사항이 정확하게 반영할 때까지 계속해서 개선/보완 된다. 실제로 많은 애플리케이션들이 지속적인 프로토타입의 확장과 보강을 통해 최종 설계가 승인된다.

https://ko.wikipedia.org/wiki/프로토타입

나는 오랜 동안 SI 프로젝트에서 ‘기획자’로 일해왔다. 그동안 파워포인트로 설계서(스토리보드)를 작성하고 아래와 같은 과정을 거친 후에야 동작하는 실체를 볼 수 있었다.

  1. 디자인 – 그래픽 이미지로 제작되어 시각적인 확인은 되지만 브라우저(또는 앱)에서 어떻게 동작 될 지는 알 수 없다.
  2. 퍼블리싱 – 브라우저에서 화면 단위로 볼 수 있지만 연결될 화면을 하나씩 지정해 주는 것은 별도로 필요하다. 화면 연결과 효과는 별도로 정의를 해줘야 한다.
  3. 개발 – 실제 화면에 보여질 데이터를 연동하고 기능 요건까지 적용한 상태로 볼 수 있다.

내가 만들고 싶은 어떤 것(그것이 하나의 화면이든, 연속된 화면으로 이루어진 서비스 또는 기능, 그리고 이의 합체인 제품이든)이 구체화 되려면 이렇게 여러 사람의 손을 거쳐야 한다.

그리고 짠! 하고 보여주면 여기저기서 말들이 나온다.

“제가 생각한 것과 다른데요…”

이런 말 안 들으려면 프로토타입이 필요하다. 그런데 제한된 시간 내에 개선/보완을 통해 사용자의 요구사항을 정확히 반영하려면 빨리 만들어야 한다. 디자인, 퍼블리싱을 기다릴 시간이 없다.

전통적인 워터폴 방식의 기획-디자인-퍼블-개발로 이어지는 단계적 접근으로 이 문제를 해결할 수 없다. 이제는 UI 기획자가 화면 디자인과 프로토타입까지 제작하는 방식이 필요하다.

이런 생각은 한 스타트업과 일을 준비하며 읽은 글(https://brunch.co.kr/@nyeric/29)이 참고가 되었다. 그리고 실제 원격에서 Figma를 이용해 화면을 디자인하고 개발자들과 논의하며 서비스를 만들어가는 동안 즐거웠다.(이때의 경험으로 Framer에 대한 관심이 좀더 커졌다. 이에 대한 이야기는 다음 기회에.)

SI 프로젝트에서, 외부 접속이 차단된 환경의 문제로 실제 업무에서 사용해볼 기회는 제한적이겠지만. 가능한 계속해서 프로토타입 툴을 써보려고 한다. 계속 진화하기 위해.

새 장난감, Framer 시작

그냥 create code file 을 시도하면 자동으로 제공되는 기본 소스다. 겁먹을 필요 없다. 덜덜..

Framer(https://www.framer.com)를 시작했다.

기존 사용하던 Figma로 UI를 그려내는 데는 별다른 부족함이 없었다. 가끔 아쉬운 점이 있었다면 내가 충분히 활용하지 못해서 일거다. 그럼에도 새로운 툴을 만지작 거린 것은 어디선가 읽은 code 기반으로 interatction을 좀더 효과적(?)으로 구현할 수 있다는 설명 때문일 거다.

전업 개발자로 code를 다룬 것은 오래전이지만 여전히 한두시간 정도는 지치지 않고 가지고 놀 수 있기도 하고. 무엇보다 해보지 않은 거니까.

Figma와 마찬가지로 시작은 무료이다. 어차피 혼자 가지고 놀거니까 굳이 당장 결제할 필요도 없다.

비용이 궁금하다면 여기를 https://www.framer.com/pricing/