본문 바로가기

100 to the future8

[8/100] table 8번째는 table(이하 테이블)입니다. 데이터 시트 형태의 인터페이스인데, 데이터 시트와는 조금 다르게 간단한 기능을 수행하는 부분도 있습니다. 단순하게 정보를 나열만 한다면 굉장히 간단한 형태의 인터페이스지만, 서비스의 성격에 따라 보여주는 정보 및 제공하는 기능이 다양하기 때문에 설계 및 구현 난이도가 높아지는 성격이 있습니다. 테이블에는 크게 헤더와 컨텐츠가 있는데, 헤더는 테이블 상단에 위치해서 보이는 콘텐츠의 제목을 표시하는 기능을 합니다. 경우에 따라서는 생략되는데, 이유로는 콘텐츠의 정보가 간단해서 파악하는데 굳이 추가적인 명시를 하지 않아도 되는 경우입니다. 콘텐츠의 형태는 다양하며, 위의 예제에는 체크박스, 아바타, 텍스트, 드롭다운, 칩(혹은 배지), 버튼 등이 있습니다. 물론 훨씬 .. 2022. 9. 23.
[7/100] sidebar 7번째는 sidebar(이하 사이드바)입니다. 사이드바는 주로 대시보드 형태의 레이아웃에서 내비게이션의 기능을 담당합니다. 대시보드에서는 염두를 해야 하는 게 많은 기능으로 인해서 메뉴가 많이 들어갈 수 있어야 하고, 추후 확장성도 고려해야 하기 때문에 좌측에 세로로 메뉴가 정렬되는 사이드바가 많이 사용됩니다. 가로로 정렬되어 있는 메뉴들은 심미적으로는 좋아 보일 수 있지만, 메뉴가 많이 들어가기 힘들고, 확장성도 제한이 됩니다. 가장 기본적인 사이드바의 형태인데, 메뉴 상단에 있는 홀더에는 서비스의 로고 혹은 로그인된 사용자의 간략한 정보가 포함될수 있지만, 이런 것들은 만약 상단에 GNB가 있다면 거기에도 포함될 수 있습니다. 사이드바의 특징이 유연하고, 확장성이 좋기 때문에 서비스의 구조에 따라 형.. 2022. 9. 22.
[6/100] appbar 6번째는 appbar(이하 앱바)입니다. 앱바는 앱을 사용하면 가장 상단에 고정되어 있는 영역을 의미합니다. 여기에 주로 홈 화면 기준으로 프로덕트의 로고와 BNB에 넣기에는 애매한 기능이나 메뉴들을 위치시키게 됩니다. 화면에 따라서 포함되는 기능도 다르며, 기능보다는 내비게이션만 포함되는 경우도 있습니다. 위를 보시면 대략 4가지 유형의 앱바가 예제로 있는데, 원래는 훨씬 다양하며, 서비스의 구조마다 다를수 있습니다. 앱바를 구성하는 영역을 나누면, leading, title, function으로 나눌 수 있습니다. leading - 앱바 좌측에 있는 영역이며, 생략될수 있습니다. 생략될 경우에는 title이 위치할 수도 있으며, 주로 햄버거 메뉴, 뒤로 가기 등의 내비게이션 관련 기능이 들어가는 영역.. 2022. 9. 16.
[5/100] button 5번째는 버튼입니다. 디자인 시스템을 구축하다 보면 가장 기본적이면서도 복잡하다면 복잡한 컴포넌트인데요. 프로덕트를 디자인하다 보면 앱, 웹을 모두 같이 하는 경우가 있습니다. 그럼 아무래도 앱, 웹의 사용자 인터페이스의 환경이 조금은 다르다 보니, 마우스를 사용하는 환경, 단순히 탭을 하는 환경, 이렇게 다르다 보니 버튼도 상태 혹은 이벤트에 대해 신경을 써야 하지만 간단하게 처리하자면, 앱에서는 mouse-hover 상태만 없다고 생각하면 편합니다. 그리고 버튼은 보통 스타일이 있는데, 주로 많이 사용되는 스타일은 위의 3가지가 있습니다. 부르는 명칭이 좀 제각각인 경우가 많아서 저같은 경우에는 왼쪽부터, primary, secondary, ghost라고 부르고 있습니다. primary가 가장 많이 .. 2022. 9. 14.
[4/100] input-number 4번째는 숫자 전용 인풋입니다. 다른 디자인 시스템 문서를 찾아보다가 괜찮아 보여서 작업해보았습니다. 형태는 인풋 우측에 '-','+' 버튼이 위치한 형태입니다. 아래는 개인적으로 분석한 장점 및 단점입니다. 장점 입력된 수치의 변동이 적다는 가정에서는 간단하게 수정이 용이하다 '-', '+' 사이의 거리가 짧아서 인터랙션이 용이하며, 한 손으로도 쉽게 가능하다 단점 인풋마다 '-', '+'가 계속 보여서 한 화면에 많은 인풋이 있다면 시각적으로 아름답지 않다 date-picker, time-picker를 사용해야 할 경우 굳이 사용할 필요가 없다 특정 데이터에 사용되는 전용 인풋말고는 사용하기에 나쁘지 않아 보입니다. 숫자를 많이 사용하는 서비스나 프로덕트에는 생각해볼 만한 인풋이라고 생각합니다. 하위.. 2022. 9. 13.
[3/100] modal 세 번째는 확인 및 경고에 많이 쓰이는 모달 창입니다. 용도는 중요한 결정 및 삭제할 때 사용되며, 그렇기 때문에 사용자가 집중할 필요가 있습니다. 그래서 모달을 제외한 배경을 어둡게 처리해서 대비를 강하게 하는 게 기본입니다. 모달 창이 나올 때 빠르게 애니메이션을 적용하는 것도 방법입니다. 단순 확인만 하는 모달 창이라면 버튼이 하나만 있으면 되며, 경우에 따라서는 간단한 인풋도 들어가는 경우가 있지만 지금은 가장 기본 형태만 작업을 하였습니다. 하위 컴포넌트 목록 및 상태 button/item - 기본 버튼 형태 button/container - 버튼 컨테이너이며, single, vertical, horizontal로 구분 contents - 모달의 타이틀, 이미지(옵션), 내용을 포함 modal .. 2022. 9. 10.
[2/100] BNB 두 번째는 앱 하단에 위치한 BNB입니다. 이번에는 약간의 시나리오를 가정해서 작업을 했습니다. 앱은 어느정도 기능 중심 디자인의 형태를 가지고 있다. 그래서 핵심적인 기능보다는 다양한 기능을 제공하고 있다. 사용자들에게는 자신에게 필요한 기능에 빠르게 접근하기 위해 개인화가 필요한 상황이다. 프로덕트 초기에는 극단적인 사용자 중심의 디자인을 가지고 있는 게 대부분입니다. 사용자들의 요구를 빠르게 파악해서 거기에 집중하는 건데요. 프로덕트가 규모가 커지고, 기타 대외적인 이유 때문에 기능들이 점점 붙는 경우가 많습니다. 대략 이런 시나리오를 가정하고 작업을 하였습니다. BNB메뉴에 타이틀 혹은 라벨이 있는 타입과 없는 타입으로 구분은 했는데 당장은 좀 불필요해보입니다. 우측에 더보기를 탭 하게 되면 BN.. 2022. 9. 9.
[1/100] date-picker 가능하면 날마다 UI 컴포넌트 하나씩 만들면서 100개를 목표로 정리하는 챌린지 "100 to the future"의 첫 번째입니다. 원래 이런 챌린지는 매일 꾸준히 1개씩 하는 거지만 제가 일하는 거 말고는 게으른 편이라 안 하는 날도 있고, 하루에 여러 개 하는 날도 있을듯합니다. 그리고 너무 간단한 컴포넌트보다는 다소 복잡한 컴포넌트나 간단하더라도 해석하면서 정리하려고 합니다. 아무래도 시각적 위계 및 비주얼의 퀄리티를 올리는 게 궁극적인 목표입니다. 하위 컴포넌트 목록 및 상태 weekdays - 요일 표시 days - 일자 표시 default - 기본 상태 disable - 선택 불가 상태 selected - 선택된 상태 single - 하루만 선택됨 start - 범위 선택 중에 시작일 ran.. 2022. 9. 7.