Jump to content
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr ×
과거의 기술자료(읽기 전용): https://tech.devgear.co.kr

이 사이트 검색

검색 태그: 'ui/ux'.

  • 태그로 검색

    태그 사이를 쉼표(,)로 구분하세요.
  • 작성자로 검색

콘텐츠 유형


게시판

  • 엠바카데로 (Embarcadero) 개발도구: 델파이 (Delphi), C++빌더 (C++Builder), RAD 스튜디오 (RAD Studio)
    • [기술 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [설치/등록 Q&A 게시판] 델파이, C++빌더, RAD 스튜디오
    • [기술 기고 게시판] 델파이, C++빌더, RAD 스튜디오
    • [포트폴리오 게시판] 내가 참여한 프로젝트/프로그램 소개
    • [구인 게시판] 개발자 채용/프로젝트 의뢰
  • 엠바카데로 (Embarcadero) DBMS: 인터베이스 (InterBase)
    • [기술 Q&A 게시판] 인터베이스
    • [설치/등록 Q&A 게시판] 인터베이스
    • [기술 기고 게시판] 인터베이스
  • 비주얼 스튜디오 (Visual Studio) 관련 도구
    • [기술 Q&A 게시판] 비주얼 어시스트
    • [설치/등록 Q&A 게시판] 비주얼 어시스트
    • [기술 기고 게시판] 비주얼 어시스트
  • 구록 (Gurock) 테스트도구: 테스트레일 (TestRail)
    • [기술 Q&A 게시판] 테스트레일
    • [설치/등록 Q&A 게시판] 테스트레일
    • [기술 기고 게시판] 테스트레일
  • 아이데라 (Idera) 데이터 도구: 아쿠아 데이터 스튜디오 (Aqua Data Studio), ER/Studio 등
    • ER스튜디오 (ER/Studio)
    • 아쿠아 데이터 스튜디오 (Aqua Data Studio)
  • API레이어 (Apilayer) 개발 도구: API레이어 (Apilayer)
    • [Q&A 게시판] API레이어 (Apilayer)
  • 엠바카데로 (Embarcadero) 라이선스 서버: ELC (Enterprise License Center)
    • [게시판] ELC (Enterprise License Center) 라이선스 서버
  • 이 사이트 이용 관련
    • [게시판] 이 사이트 관련 이용 팁과 Q&A

Categories

  • 이달의 기술자료: 엠바카데로
  • 비디오 세미나
    • UX Summit
    • DelphiCon
    • CodeRage
    • 데브기어 세미나
    • Skill Sprint
  • 기술백서(PDF)

Categories

  • 시작하기
  • 설치/등록/라이선스
  • 튜토리얼
  • 도서

Categories

  • RAD 스튜디오 역사관
  • 11 알렉산드리아
  • 10.4 시드니
  • 10.3 리오
  • 10.2 도쿄
  • 10.1 베를린
  • 10.0 시애틀
  • XE8~XE
  • 2010~6.0

...에서 결과 찾기

검색어 일치 조건


최초 작성일

  • Start

    End


최종 변경일

  • Start

    End


개수로 필터링...

가입

  • Start

    End


Group


자주 쓰는 도구

  1. << UX Summit 2021 목록으로 이동 UX Summit 의 2021 시리즈 중, Designing Multi-Threaded UIs - Olaf Monien - Ray Konopka 의 한글 요약본입니다. 발표자 (Ray Konopka)는 CodeSite, Konopka Signature VCL로 유명한 Raize Software의 창업자이며, 월트 디즈니 어트랙션 테크놀러지의 수석 소프트웨어 엔지니어로 일했습니다. 탭 콘트롤 관련 16가지 예를 매우 짧고 명확히 설명하고, 탭 콘트롤 디자인 가이드라인을 제시합니다. 원본 비디오(YouTube) 보기(46 min)를 권장합니다. 목차 1 탭 콘트롤 이해하기 2 탭(Tab)의 갯수와 배치는 어느 정도가 알맞을까? 3 많은 문서를 탭으로 나누어 다루려면 어떻게 하면 좋을까? 4 컨텍스트 유지하기 5 계층 구조는 탭보다는 트리뷰가 직관적이다 6 스타일링 7 메타포(탭이 상징하는 것) 유지하기 8 탭 콘트롤 관련 기타 고려 사항 9 탭 콘트롤 디자인 가이드라인 10 탭의 방향과 배치 변경 등을 시도하여 더 효과적인 사용성을 제공해보ㅈ 1 탭 콘트롤 이해하기 탭(Tab) 콘트롤이 널리 사용되는 주된 이유 3가지 (비디오 0분 55초부터 보기) 시각적으로 분명하다: 해당 탭이 무엇을 하는 곳인지 사용자가 즉시 파악할 수 있다. 공간 효율성이 좋다: 좁은 공간 안에서 여러 그룹이 배치되고 각 그룹별로 공간을 사용할 수 있다. 사용성이 좋다: 시각적으로 분명하기 때문에, 실생활에서도 많이 쓰는 표현 방식이므로 쉽게 사용할 수 있다. 탭(Tab) 콘트롤의 "역할": 해당되는 콘텐츠 관리 (비디오 2분 30초부터 보기) 원하는 콘텐츠로 찾아서 빠르게 이동한다: 엑셀 등 스프레드시트의 탭 관련된 콘텐츠끼리 "따로" 모아놓는다: 옵션 설정 대화상자 (수십년간 사용되고 있다. 하지만 뒤에서 설명하는 것처럼, 잘못 사용하면 사용자에게 혼란을 주기도 한다.) 콘텐츠(문서)를 정돈한다: 웹브라우저, IDE, 그래픽 디자인 도구 등에서도 탭 방식이 많이 사용된다. 탭(Tab) 콘트롤 UX 디자인 시 어려운 점 (비디오 5분 40초부터 보기) 탭의 갯수: 탭이 너무 많으면 복잡하다. 사용자는 종종 탭을 너무 많이 열기도 한다. 컨텍스트 유지하기: 탭과 해당 내용 간에는 컨텍스트가 연결되어야 하고 직관적이고 일관성이 있어야 한다. 탭의 모양 스타일: 탭을 예쁘게만 보이게 하다보면 일관성이 깨지고 의미하는 바가 더 모호해질 수 있다. 메타포(탭이 상징하는 것): 탭이 상징하는 바가 점차 여러 가지가 되다보면, 뒤섞이다보니 사용자의 생각과 단절이 생긴다. 2 탭(Tab)의 갯수와 배치는 어느 정도가 알맞을까? 탭은 10개 이하일 때 매우 효과적이다. (대체로 7개 정도가 알맞다) 탭을 많이 열면 탭의 폭이 좁아지므로 탭 제목이 짧을 수록 사용성이 좋다. 제목이 너무 길면 잘려서 뒷부분이 안보일 수 이거나 너무 길어서 공간을 지나치게 많이 차지할 수 있다. 탭은 한줄에 배치되어야 한다. 불가피하게 여러줄이 꼭 필요할 수도 있지만, 여러줄에 들어있으면 사용자가 혼란을 느끼고 성가시게 생각한다. 사례1. 스크래치패드 에디터의 옵션 화면의 탭 갯수와 배치 (비디오 9분 30초부터 보기) 그림1. 스크래치패드 에디터의 옵션 화면은 그룹이 잘 나누어져 있고, 탭이 한줄로 정리되었고, 직관적이고 사용하기 쉽다. 탭을 7개로 구성했는데, 만약 그룹핑을 보다 세밀하게 10개로 했다면 오히려 복잡해지고, 화면도 더 많이 필요했을 것이다. 사례2. 소스 인사이트 옵션 화면의 탭 갯수와 배치 (비디오 11분 09초부터 보기) 그림2. 소스 인사이트의 옵션 화면은 탭이 여러줄에 배치되어 있다. 더 많은 내용을 담을 수 있지만 사용성은 떨어진다. 위쪽의 탭을 클릭하면 선택한 탭이 아랫 줄로 내려고, 다른 탭들의 위치도 달라지기 때문에 사용자들이 혼란을 느낀다. 요즘은 내용이 많은 경우에 한줄 안에 탭을 모두 넣기 위해 세로로 된 탭을 사용하기도 한다. 아쉽지만 윈도우의 기본 탭 콘트롤은 세로 배치 즉 오른쪽이나 왼쪽 배치를 지원하지 않는다. 3 많은 문서를 탭으로 나누어 다루려면 어떻게 하면 좋을까? 얼마나 많은 탭을 사용할 것인지에 대한 제한은 없다. (여러분도 웹 브라우저에서 탭을 상당히 많이 열지 않는가?) 정답은 없고 다들 조금씩 스타일이 다를 뿐이다. 하지만 어떤 스타일이든 일관성이 있어야 한다. 사례3. 크롬에서 문서를 탭으로 다루는 방법 (비디오 15분 03초부터 보기) 그림3. 크롬에서 탭이 많아지면 탭의 폭이 줄어든다. 탭이 많아지면 탭의 제목이 잘려서 정확히 알 수 없다. 오른쪽의 드롭다운 화살표를 클릭하면, 긴 탭 제목이 수직으로펼쳐진다. 하지만 부가 정보도 있고, 공간을 많이 차지하여 스크롤이 생긴다. 게다가 위쪽 탭과 세로 탭의 순서가 다르고 사용자가 정렬기준을 이해하기도 힘들다. 결국 원하는 탭을 쉽게 찾기가 불편하다. 사례4. 엣지에서 문서를 탭으로 다루는 방법 (비디오 17분 44초부터 보기) 그림4. 엣지에는 크롬에 있는 드롭다운 화살표가 없다. 대신 왼쪽에 수직 탭 (Veritcal Tab) 버튼이 있다. 그다지 탭처럼 보이지는 않기 때문에, 그래서 탭을 사용하던 기존의 경험과 단절된 기분이 든다. 하지만, 크롬보다 수직 탭의 크기가 작아서 탭 수가 같아도 스크롤이 필요없다. 그리고 탭의 배치 순서가 위쪽의 탭과 일치한다. 그렇다고 해도, 원하는 탭을 훨씬 더 빠르게 열 수 있다고 하기는 힘들다. 사례5. 사파리에서 문서를 탭으로 다루는 방법 (비디오 19분 24초부터 보기) 그림5. 사파리는 오쪽에 있는 탭 오버뷰 보기를 클릭하면 화면에 모든 탭의 미리보기가 펼쳐진다. 꽤 좋아보이지만, 여전히 각 탭 제목의 뒷부분이 잘린다. 화면도 많이 차지하므로, 일부 탭은 스크롤을 해야 볼 수 있다. 또한, 탭의 폭이 최소가 되면 글자가 없어지고 아이콘만 표시된다. 이이콘 만으로는 어떤 의미인지 알 수가 없다. 사례6. 스크래치패드에서 문서를 탭으로 다루는 방법 (비디오 21분 01초부터 보기) 그림6. 문서가 많아지면, 오른쪽에 드롭다운 메뉴가 생기고, 클릭하면 알파벳 순서로 모든 탭이 펼쳐진다. 각 탭이 공간을 적게 차지하므로 더 많은 탭을 표시할 수 있다. 그리고 위쪽에 있는 탭은 폭이 줄어들지 않는다. 4 컨텍스트 유지하기 탭이 매우 효과적이려면 다루는 콘텐츠가 너무 많지 않아야 한다. 너무 많은 콘텐츠를 탭으로 다루면, 오히려 더 성가실 수 있다. 탭을 중첩하지 말자: 탭 안에 다른 탭 그룹을 넣으면 찾기가 쉽지 않고, 그 의미도 불분명해진다. 탭과 내용이 어떻게 연결되는 지 한눈에 파악될 수 있도록 컨텍스트의 일관성을 유지한다. 사례7. IsoBuster 옵션 화면 (비디오 23분 26초부터 보기) 그림7. IsoBuster 옵션 화면은 너무 많은 정보를 넣기 위해서 사용하기 불편하게 만든 사례이다. 탭이 3겹으로 중첩되어 있어서 한눈에 들어오지 않는다. 가장 상위의 탭들은 실제로 메인화면의 Options 아래에 있는 메뉴들인데 여기에 또 들어있다. 그리고 상위의 탭을 선택하면, 선택된 상위 탭에 속하는 탭들로 아랫 줄의 탭들이 교체된다. 카테고리 별로 그룹을 나누기 위해 이렇게 했다는 것을 이해할 수 있었다. 5 계층 구조는 탭보다는 트리뷰가 직관적이다 이렇게 카테고리가 계층 구조로 표현되어야 한다면, 탭보다는 트리뷰 형태가 더 적합하다. 트리뷰는 보는 순간 바로 계층 구조라는 것을 명확히 알 수 있고 필요한 곳으로 이동하기가 더 쉽다. 참고로, 트리뷰를 다룰 때는 트리뷰에서 선택된 노드가 그 화면에서 사용자가 작업하는 내용과 연결이 되어 있어야 한다. 자칫 트리뷰의 선택에 해당되는 내용이 나머지 화면에 표현되지 않고 따로 놀면 사용자가 혼란을 느낀다. 사례8. RAD 스튜디오에 내장된 TChart 에디터 (비디오 25분 56초부터 보기) 그림8. TChart 편집창 역시 탭을 남용하여서 사용하기 불편하다. 편집창의 왼쪽에 트리뷰가 계층 구조를 표현하고 있다. 하지만, 오른쪽 화면 안에는 탭이 너무 많고 탭의 계층이 중첩되어 있다. Border 탭 아래에는 Frame, Corners, Callout, Bevel 이라는 4개의 탭이 있는데, 해당 내용은 적다. 차라리 이 4개가 탭이 아니라 그룹 박스라면 한번에 4개 모두를 펼쳐서 보여줄 수 있어서, 탭을 열고 들어갈 필요도 없을 것이다. 즉, 결국 그룹핑이나 계층 구조에서는 계층의 깊이를 줄이는 노력이 필요하다. 6 스타일링 탭은 매우 효과적이다. 하지만, 그러기 위해서는면, 선택되지 않은 탭과 쉽게 구별되어야 한다. 탭이 어떤 내용과 연결되어 있는 지가 명확해야 한다. 탭은 사용자가 보는 순간 바로 탭이라고 알 수 있는 모습이어야 한다. 탭의 방향을 잘 고려해야 한다. 사례9. 워드의 폰트 옵션창과 엑셀의 시트 탭 (비디오 28분 59초부터 보기) 그림9-1.워드의 폰트 옵션창은 선택된 탭과 해당 영역 그리고 그 나머지 영역 간의 명도차가 적어서 그 차이가 "확연하지 않다" 그림9-2.엑셀은 선택된 시트 탭의 제목이 굵고 다른 색이고 강조하는 밑줄이 있어서 선택되지 않은 탭과 그 차이가 "확연하다". 선택되지 않은 영역과 명도차도 워드의 옵션창보다 더 크다. 사례10. RAD 스튜디오에 사용되는 많은 탭 (비디오 30분 50초부터 보기) 그림10. RAD 스튜디오는 탭과 해당 내용 사이에 단절이 있다. 선택된 유닛이 무엇인지는 확연히 눈에 띄지만, 유닛 탭과 유닛의 내용 사이에 굵은 경계선이 있다. Code, Design, History 탭은 탭이 아닌 상자처럼 보인다. 게다가 편집 화면과 연결되어 보이지 않는다. Project, Deta Explorer, Multi-Device Previ..도 그 위의 상자와 연관이 있는 탭인데 상자와 단절된 느낌이든다. 사례11. 마이크로소프트 뉴스 웹사이트 (비디오 32분 52초부터 보기) 그림11. 마이크로소프트 뉴스에서는 보기에는 멋지지만 사용자들은 관심있는 항목을 찾아서 열기가 쉽지 않다. 사용자가 탭을 선택하면, 그 탭이 가장 앞으로 이동하면서 앞에 있던 탭을 밀어낸다. 사용자는 선택하는 영역인 탭들이 움직이기 때문에 위치를 쉽게 찾지 못한다. 사례12. 예전의 원노트 (비디오 34분 30초부터 보기) 그림12-1. 예전의 원노트에 있는 오른쪽 탭은 직관적이고 찾아서 이동하기 좋다. 그림12-2. 예전의 원노트에서 위쪽 탭에서 펼처진 드롭다운 탭과 위쪽에 있는 탭과, 좌측의 탭 모두 순서가 맞지 않는다. (Tutorial 항목의 위치를 잘 살펴보면 알 수 있다) 사례13. 윈도우 10 용 원노트 (비디오 36분 12초부터 보기) 그림13. 윈도우 10 용 원노트에서는 이전 버전에 있던 위쪽 탭을 제거하고, 수직 탭으로 계층을 표현했다. 이전보다 아쉬운 점은 선택된 제목 탭과 본문이 연결되지 않는다는 점이다. (이전 버전의 오른쪽 탭에서는 본문과 같은 하얀색으로 연결되어서 연결성이 명확했다.) 7 메타포(탭이 상징하는 것) 유지하기 윈도우 리본 UI는 탭 콘트롤에 강화된 스타일이 적용된 것이다. 안타깝지만, 리본 UI에는 여러 메타포가 섞여있어서 일관성이 떨어진다. 사례14. 워드패드 리본 UI의 탭 (비디오 37분 40초부터 보기) 그림14-1. 워드패드의 리본 UI의 위쪽 탭 중 File이 눈에 띄는 색상이므로 선택된 것처럼 보이지만, 실제로 선택된 탭은 Home이다. 그림14-2. 워드패드의 리본 UI에서 File도 탭인데, 클릭하면 다른 탭과 달리 팝업이 표시된다. 즉 다른 탭과 메타포가 다르다. 이렇게 메타포가 섞이면 단절이 발생한다. 사례15. 워드 리본 UI의 탭 (비디오 38분 25초부터 보기) 그림15-1. 워드 리본 UI는 탭의 스타일을 마치 탭이 아닌 것처럼 보이도록 한다. 그림15-2. 워드 리본 UI File 탭은 다른 탭과 메타포가 다르다. 이렇게 메타포가 섞이면 역시 단절이 생긴다. 즉 일관성이 깨진다. File 탭을 클릭하면, 다른 탭과 달리 새 창이 표시되고 심지어 다른 탭을 포함하여 화면을 모두 덮어버린다. 게다가, File 화면은 단순히 File이라고 하기에는 너무 많은 것들이 들어가 있다. 8 탭 콘트롤 관련 기타 고려 사항 탭 이동은 이미 널리 사용된다. 웹 브라우저와 웹사이트에서 탭으로 이동하는 방식이 인기있게 된 것은 5~10년 전이다. 웹에서 사용되는 탭의 스타일이 일부 데스크탑 앱에 영향을 끼치고 있다. 마법사도 탭의 일종이다. 마법사는 하나의 영역마다 해당 설정을 하는 일종의 탭이며, 매우 효과적이다. 단, [다음] 버튼을 통해야 다음 내용으로 넘어갈 수 있도록 다른 탭들은 안보여야 한다. 탭은 순서를 의미하지 않는다 "탭의 언제든지 어느 탭이든지 선택하여 열수 있다"는 본연의 메타포를 지키는 것이 중요하다. 내용 비교가 필요한 문서들은 탭을 사용하지 말자. 탭을 선택하면 해당 내용만 볼 수 있어야 하기 때문이다. 탭이 연결된 내용을 사용자가 비교하지 못하고, 탭을 눌러서 내용을 계속 바꿔야 하고 동시에 비교할 수 없다. 9 탭 콘트롤 디자인 가이드라인 탭을 나열할 때 사용자가 이해하기 쉬운 순서로 나열한다. (가장 중요한 것이 가장 앞에 있어야 한다) 탭 제목은 짧게 한두단어로만 만든다. 첫글자만 대문자로 쓴다. (모두 대문자로 쓰지 않는다) 탭을 여러줄로 배치하지 않는다. 탭을 중첩하여 사용하지 않는다. 선택된 탭은 그렇지 않은 탭에 비해 확연히 눈에 띄도록 표시한다. 10 탭의 방향과 배치 변경 등을 시도하여 더 효과적인 사용성을 제공해보자 TRzPageControl 과 TRzTabControl (비디오 43분 04초부터 보기) (겟잇 패키지 매니저에서 받을 수 있는) Konopka Signature VCL 콘트롤 세트에 들어있다. RAD 스튜디오에 내장된 TPageControl 과 TTabControl보다 많은 기능이 추가되어 있다. 그림 16-1. TRzPageControl은 탭의 방향과 위치를 지정할 수 있다. 그림 16-2. Konopka Signature VCL 콘트롤 데모에서 Tabs를 선택하면 많은 기능을 확인할 수 있다. TRzPageControl은 탭이 많아져도 탭의 폭이 줄어들지 않는다. 공간이 부족하면 드롭다운을 통해 모든 탭이 알파벳 순서로 수직으로 정렬된다. << UX Summit 2021 목록으로 이동
  2. << UX Summit 2021 목록으로 이동 UX Summit 의 2021 시리즈 중, Designing Multi-Threaded UIs - Olaf Monien - Ray Konopka 의 한글 요약본입니다. 발표자 (Ray Konopka)는 CodeSite, Konopka Signature VCL로 유명한 Raize Software의 창업자이며, 월트 디즈니 어트랙션 테크놀러지의 수석 소프트웨어 엔지니어로 일했습니다. 탭 콘트롤 관련 16가지 예를 매우 짧고 명확히 설명하고, 탭 콘트롤 디자인 가이드라인을 제시합니다. 원본 비디오(YouTube) 보기(46 min)를 권장합니다. 목차 1 탭 콘트롤 이해하기 2 탭(Tab)의 갯수와 배치는 어느 정도가 알맞을까? 3 많은 문서를 탭으로 나누어 다루려면 어떻게 하면 좋을까? 4 컨텍스트 유지하기 5 계층 구조는 탭보다는 트리뷰가 직관적이다 6 스타일링 7 메타포(탭이 상징하는 것) 유지하기 8 탭 콘트롤 관련 기타 고려 사항 9 탭 콘트롤 디자인 가이드라인 10 탭의 방향과 배치 변경 등을 시도하여 더 효과적인 사용성을 제공해보ㅈ 1 탭 콘트롤 이해하기 탭(Tab) 콘트롤이 널리 사용되는 주된 이유 3가지 (비디오 0분 55초부터 보기) 시각적으로 분명하다: 해당 탭이 무엇을 하는 곳인지 사용자가 즉시 파악할 수 있다. 공간 효율성이 좋다: 좁은 공간 안에서 여러 그룹이 배치되고 각 그룹별로 공간을 사용할 수 있다. 사용성이 좋다: 시각적으로 분명하기 때문에, 실생활에서도 많이 쓰는 표현 방식이므로 쉽게 사용할 수 있다. 탭(Tab) 콘트롤의 "역할": 해당되는 콘텐츠 관리 (비디오 2분 30초부터 보기) 원하는 콘텐츠로 찾아서 빠르게 이동한다: 엑셀 등 스프레드시트의 탭 관련된 콘텐츠끼리 "따로" 모아놓는다: 옵션 설정 대화상자 (수십년간 사용되고 있다. 하지만 뒤에서 설명하는 것처럼, 잘못 사용하면 사용자에게 혼란을 주기도 한다.) 콘텐츠(문서)를 정돈한다: 웹브라우저, IDE, 그래픽 디자인 도구 등에서도 탭 방식이 많이 사용된다. 탭(Tab) 콘트롤 UX 디자인 시 어려운 점 (비디오 5분 40초부터 보기) 탭의 갯수: 탭이 너무 많으면 복잡하다. 사용자는 종종 탭을 너무 많이 열기도 한다. 컨텍스트 유지하기: 탭과 해당 내용 간에는 컨텍스트가 연결되어야 하고 직관적이고 일관성이 있어야 한다. 탭의 모양 스타일: 탭을 예쁘게만 보이게 하다보면 일관성이 깨지고 의미하는 바가 더 모호해질 수 있다. 메타포(탭이 상징하는 것): 탭이 상징하는 바가 점차 여러 가지가 되다보면, 뒤섞이다보니 사용자의 생각과 단절이 생긴다. 2 탭(Tab)의 갯수와 배치는 어느 정도가 알맞을까? 탭은 10개 이하일 때 매우 효과적이다. (대체로 7개 정도가 알맞다) 탭을 많이 열면 탭의 폭이 좁아지므로 탭 제목이 짧을 수록 사용성이 좋다. 제목이 너무 길면 잘려서 뒷부분이 안보일 수 이거나 너무 길어서 공간을 지나치게 많이 차지할 수 있다. 탭은 한줄에 배치되어야 한다. 불가피하게 여러줄이 꼭 필요할 수도 있지만, 여러줄에 들어있으면 사용자가 혼란을 느끼고 성가시게 생각한다. 사례1. 스크래치패드 에디터의 옵션 화면의 탭 갯수와 배치 (비디오 9분 30초부터 보기) 그림1. 스크래치패드 에디터의 옵션 화면은 그룹이 잘 나누어져 있고, 탭이 한줄로 정리되었고, 직관적이고 사용하기 쉽다. 탭을 7개로 구성했는데, 만약 그룹핑을 보다 세밀하게 10개로 했다면 오히려 복잡해지고, 화면도 더 많이 필요했을 것이다. 사례2. 소스 인사이트 옵션 화면의 탭 갯수와 배치 (비디오 11분 09초부터 보기) 그림2. 소스 인사이트의 옵션 화면은 탭이 여러줄에 배치되어 있다. 더 많은 내용을 담을 수 있지만 사용성은 떨어진다. 위쪽의 탭을 클릭하면 선택한 탭이 아랫 줄로 내려고, 다른 탭들의 위치도 달라지기 때문에 사용자들이 혼란을 느낀다. 요즘은 내용이 많은 경우에 한줄 안에 탭을 모두 넣기 위해 세로로 된 탭을 사용하기도 한다. 아쉽지만 윈도우의 기본 탭 콘트롤은 세로 배치 즉 오른쪽이나 왼쪽 배치를 지원하지 않는다. 3 많은 문서를 탭으로 나누어 다루려면 어떻게 하면 좋을까? 얼마나 많은 탭을 사용할 것인지에 대한 제한은 없다. (여러분도 웹 브라우저에서 탭을 상당히 많이 열지 않는가?) 정답은 없고 다들 조금씩 스타일이 다를 뿐이다. 하지만 어떤 스타일이든 일관성이 있어야 한다. 사례3. 크롬에서 문서를 탭으로 다루는 방법 (비디오 15분 03초부터 보기) 그림3. 크롬에서 탭이 많아지면 탭의 폭이 줄어든다. 탭이 많아지면 탭의 제목이 잘려서 정확히 알 수 없다. 오른쪽의 드롭다운 화살표를 클릭하면, 긴 탭 제목이 수직으로펼쳐진다. 하지만 부가 정보도 있고, 공간을 많이 차지하여 스크롤이 생긴다. 게다가 위쪽 탭과 세로 탭의 순서가 다르고 사용자가 정렬기준을 이해하기도 힘들다. 결국 원하는 탭을 쉽게 찾기가 불편하다. 사례4. 엣지에서 문서를 탭으로 다루는 방법 (비디오 17분 44초부터 보기) 그림4. 엣지에는 크롬에 있는 드롭다운 화살표가 없다. 대신 왼쪽에 수직 탭 (Veritcal Tab) 버튼이 있다. 그다지 탭처럼 보이지는 않기 때문에, 그래서 탭을 사용하던 기존의 경험과 단절된 기분이 든다. 하지만, 크롬보다 수직 탭의 크기가 작아서 탭 수가 같아도 스크롤이 필요없다. 그리고 탭의 배치 순서가 위쪽의 탭과 일치한다. 그렇다고 해도, 원하는 탭을 훨씬 더 빠르게 열 수 있다고 하기는 힘들다. 사례5. 사파리에서 문서를 탭으로 다루는 방법 (비디오 19분 24초부터 보기) 그림5. 사파리는 오쪽에 있는 탭 오버뷰 보기를 클릭하면 화면에 모든 탭의 미리보기가 펼쳐진다. 꽤 좋아보이지만, 여전히 각 탭 제목의 뒷부분이 잘린다. 화면도 많이 차지하므로, 일부 탭은 스크롤을 해야 볼 수 있다. 또한, 탭의 폭이 최소가 되면 글자가 없어지고 아이콘만 표시된다. 이이콘 만으로는 어떤 의미인지 알 수가 없다. 사례6. 스크래치패드에서 문서를 탭으로 다루는 방법 (비디오 21분 01초부터 보기) 그림6. 문서가 많아지면, 오른쪽에 드롭다운 메뉴가 생기고, 클릭하면 알파벳 순서로 모든 탭이 펼쳐진다. 각 탭이 공간을 적게 차지하므로 더 많은 탭을 표시할 수 있다. 그리고 위쪽에 있는 탭은 폭이 줄어들지 않는다. 4 컨텍스트 유지하기 탭이 매우 효과적이려면 다루는 콘텐츠가 너무 많지 않아야 한다. 너무 많은 콘텐츠를 탭으로 다루면, 오히려 더 성가실 수 있다. 탭을 중첩하지 말자: 탭 안에 다른 탭 그룹을 넣으면 찾기가 쉽지 않고, 그 의미도 불분명해진다. 탭과 내용이 어떻게 연결되는 지 한눈에 파악될 수 있도록 컨텍스트의 일관성을 유지한다. 사례7. IsoBuster 옵션 화면 (비디오 23분 26초부터 보기) 그림7. IsoBuster 옵션 화면은 너무 많은 정보를 넣기 위해서 사용하기 불편하게 만든 사례이다. 탭이 3겹으로 중첩되어 있어서 한눈에 들어오지 않는다. 가장 상위의 탭들은 실제로 메인화면의 Options 아래에 있는 메뉴들인데 여기에 또 들어있다. 그리고 상위의 탭을 선택하면, 선택된 상위 탭에 속하는 탭들로 아랫 줄의 탭들이 교체된다. 카테고리 별로 그룹을 나누기 위해 이렇게 했다는 것을 이해할 수 있었다. 5 계층 구조는 탭보다는 트리뷰가 직관적이다 이렇게 카테고리가 계층 구조로 표현되어야 한다면, 탭보다는 트리뷰 형태가 더 적합하다. 트리뷰는 보는 순간 바로 계층 구조라는 것을 명확히 알 수 있고 필요한 곳으로 이동하기가 더 쉽다. 참고로, 트리뷰를 다룰 때는 트리뷰에서 선택된 노드가 그 화면에서 사용자가 작업하는 내용과 연결이 되어 있어야 한다. 자칫 트리뷰의 선택에 해당되는 내용이 나머지 화면에 표현되지 않고 따로 놀면 사용자가 혼란을 느낀다. 사례8. RAD 스튜디오에 내장된 TChart 에디터 (비디오 25분 56초부터 보기) 그림8. TChart 편집창 역시 탭을 남용하여서 사용하기 불편하다. 편집창의 왼쪽에 트리뷰가 계층 구조를 표현하고 있다. 하지만, 오른쪽 화면 안에는 탭이 너무 많고 탭의 계층이 중첩되어 있다. Border 탭 아래에는 Frame, Corners, Callout, Bevel 이라는 4개의 탭이 있는데, 해당 내용은 적다. 차라리 이 4개가 탭이 아니라 그룹 박스라면 한번에 4개 모두를 펼쳐서 보여줄 수 있어서, 탭을 열고 들어갈 필요도 없을 것이다. 즉, 결국 그룹핑이나 계층 구조에서는 계층의 깊이를 줄이는 노력이 필요하다. 6 스타일링 탭은 매우 효과적이다. 하지만, 그러기 위해서는면, 선택되지 않은 탭과 쉽게 구별되어야 한다. 탭이 어떤 내용과 연결되어 있는 지가 명확해야 한다. 탭은 사용자가 보는 순간 바로 탭이라고 알 수 있는 모습이어야 한다. 탭의 방향을 잘 고려해야 한다. 사례9. 워드의 폰트 옵션창과 엑셀의 시트 탭 (비디오 28분 59초부터 보기) 그림9-1.워드의 폰트 옵션창은 선택된 탭과 해당 영역 그리고 그 나머지 영역 간의 명도차가 적어서 그 차이가 "확연하지 않다" 그림9-2.엑셀은 선택된 시트 탭의 제목이 굵고 다른 색이고 강조하는 밑줄이 있어서 선택되지 않은 탭과 그 차이가 "확연하다". 선택되지 않은 영역과 명도차도 워드의 옵션창보다 더 크다. 사례10. RAD 스튜디오에 사용되는 많은 탭 (비디오 30분 50초부터 보기) 그림10. RAD 스튜디오는 탭과 해당 내용 사이에 단절이 있다. 선택된 유닛이 무엇인지는 확연히 눈에 띄지만, 유닛 탭과 유닛의 내용 사이에 굵은 경계선이 있다. Code, Design, History 탭은 탭이 아닌 상자처럼 보인다. 게다가 편집 화면과 연결되어 보이지 않는다. Project, Deta Explorer, Multi-Device Previ..도 그 위의 상자와 연관이 있는 탭인데 상자와 단절된 느낌이든다. 사례11. 마이크로소프트 뉴스 웹사이트 (비디오 32분 52초부터 보기) 그림11. 마이크로소프트 뉴스에서는 보기에는 멋지지만 사용자들은 관심있는 항목을 찾아서 열기가 쉽지 않다. 사용자가 탭을 선택하면, 그 탭이 가장 앞으로 이동하면서 앞에 있던 탭을 밀어낸다. 사용자는 선택하는 영역인 탭들이 움직이기 때문에 위치를 쉽게 찾지 못한다. 사례12. 예전의 원노트 (비디오 34분 30초부터 보기) 그림12-1. 예전의 원노트에 있는 오른쪽 탭은 직관적이고 찾아서 이동하기 좋다. 그림12-2. 예전의 원노트에서 위쪽 탭에서 펼처진 드롭다운 탭과 위쪽에 있는 탭과, 좌측의 탭 모두 순서가 맞지 않는다. (Tutorial 항목의 위치를 잘 살펴보면 알 수 있다) 사례13. 윈도우 10 용 원노트 (비디오 36분 12초부터 보기) 그림13. 윈도우 10 용 원노트에서는 이전 버전에 있던 위쪽 탭을 제거하고, 수직 탭으로 계층을 표현했다. 이전보다 아쉬운 점은 선택된 제목 탭과 본문이 연결되지 않는다는 점이다. (이전 버전의 오른쪽 탭에서는 본문과 같은 하얀색으로 연결되어서 연결성이 명확했다.) 7 메타포(탭이 상징하는 것) 유지하기 윈도우 리본 UI는 탭 콘트롤에 강화된 스타일이 적용된 것이다. 안타깝지만, 리본 UI에는 여러 메타포가 섞여있어서 일관성이 떨어진다. 사례14. 워드패드 리본 UI의 탭 (비디오 37분 40초부터 보기) 그림14-1. 워드패드의 리본 UI의 위쪽 탭 중 File이 눈에 띄는 색상이므로 선택된 것처럼 보이지만, 실제로 선택된 탭은 Home이다. 그림14-2. 워드패드의 리본 UI에서 File도 탭인데, 클릭하면 다른 탭과 달리 팝업이 표시된다. 즉 다른 탭과 메타포가 다르다. 이렇게 메타포가 섞이면 단절이 발생한다. 사례15. 워드 리본 UI의 탭 (비디오 38분 25초부터 보기) 그림15-1. 워드 리본 UI는 탭의 스타일을 마치 탭이 아닌 것처럼 보이도록 한다. 그림15-2. 워드 리본 UI File 탭은 다른 탭과 메타포가 다르다. 이렇게 메타포가 섞이면 역시 단절이 생긴다. 즉 일관성이 깨진다. File 탭을 클릭하면, 다른 탭과 달리 새 창이 표시되고 심지어 다른 탭을 포함하여 화면을 모두 덮어버린다. 게다가, File 화면은 단순히 File이라고 하기에는 너무 많은 것들이 들어가 있다. 8 탭 콘트롤 관련 기타 고려 사항 탭 이동은 이미 널리 사용된다. 웹 브라우저와 웹사이트에서 탭으로 이동하는 방식이 인기있게 된 것은 5~10년 전이다. 웹에서 사용되는 탭의 스타일이 일부 데스크탑 앱에 영향을 끼치고 있다. 마법사도 탭의 일종이다. 마법사는 하나의 영역마다 해당 설정을 하는 일종의 탭이며, 매우 효과적이다. 단, [다음] 버튼을 통해야 다음 내용으로 넘어갈 수 있도록 다른 탭들은 안보여야 한다. 탭은 순서를 의미하지 않는다 "탭의 언제든지 어느 탭이든지 선택하여 열수 있다"는 본연의 메타포를 지키는 것이 중요하다. 내용 비교가 필요한 문서들은 탭을 사용하지 말자. 탭을 선택하면 해당 내용만 볼 수 있어야 하기 때문이다. 탭이 연결된 내용을 사용자가 비교하지 못하고, 탭을 눌러서 내용을 계속 바꿔야 하고 동시에 비교할 수 없다. 9 탭 콘트롤 디자인 가이드라인 탭을 나열할 때 사용자가 이해하기 쉬운 순서로 나열한다. (가장 중요한 것이 가장 앞에 있어야 한다) 탭 제목은 짧게 한두단어로만 만든다. 첫글자만 대문자로 쓴다. (모두 대문자로 쓰지 않는다) 탭을 여러줄로 배치하지 않는다. 탭을 중첩하여 사용하지 않는다. 선택된 탭은 그렇지 않은 탭에 비해 확연히 눈에 띄도록 표시한다. 10 탭의 방향과 배치 변경 등을 시도하여 더 효과적인 사용성을 제공해보자 TRzPageControl 과 TRzTabControl (비디오 43분 04초부터 보기) (겟잇 패키지 매니저에서 받을 수 있는) Konopka Signature VCL 콘트롤 세트에 들어있다. RAD 스튜디오에 내장된 TPageControl 과 TTabControl보다 많은 기능이 추가되어 있다. 그림 16-1. TRzPageControl은 탭의 방향과 위치를 지정할 수 있다. 그림 16-2. Konopka Signature VCL 콘트롤 데모에서 Tabs를 선택하면 많은 기능을 확인할 수 있다. TRzPageControl은 탭이 많아져도 탭의 폭이 줄어들지 않는다. 공간이 부족하면 드롭다운을 통해 모든 탭이 알파벳 순서로 수직으로 정렬된다. << UX Summit 2021 목록으로 이동 View full 엠바카데로 기술자료
  3. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Why Desktop First to Develop an Application - Dr. Yılmaz Yörü 의 한글 요약본입니다. 발표자 (Dr. Yılmaz Yörü)는 1988년 이후 다양한 플랫폼에서 개발해 온 엠바카데로 C++ MVP입니다. "Wherever you code, Keep coding…, Cuz We Love Coding!" 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (21 min) 보기 이 세션은, (모바일 앱 보다는) 데스트톱 애플리케이션을 우선해야하는 상황, 고려 대상, 그리고 몇 가지 사례를 제시합니다. 플랫폼 선택 시 고려할 요소들을 여러분의 상황에 적용해보세요. 모바일과 데스크탑 앱 각각 어떤 쪽에 적합한지 사례를 참고하여 여러분의 상황에 적용해보세요. [UX Summit 2020 요약] "어떨 때" 모바일보다 데스크탑을 선택/집중하는 것이 좋을까? 를 함께 보는 것도 좋습니다. (이 글과는 또 다른 시각에서 본 사례 연구입니다.) 데스크탑과 모바일이라는 컴퓨팅 용어 정의는 사실 애매하다. 1940년대의 ENIAC에서부터 지금의 컨테이너형 슈퍼 컴퓨터, PLC시스템 등 다양한 컴퓨팅 장비를 예로 들고, 퍼스널 컴퓨터(PC), 모바일 폰 등등 다양한 용어를 통해 재미있는 화두를 던집니다. 보다 자세한 내용은 원본에서 볼 수 있습니다. 모바일과 데스크탑 점유율 (Statcounter.com 2020 기준) 전 세계적으로는 모바일 점유율이 더 높다. 하지만, 북미 또는 유럽만 보면 모바일보다 데스크탑의 점유율이 더 높다. 목표 시장이 선진국이면 데스크탑을 고려하는 것이 더 좋다. 운영체제 점유율 (Statcounter.com 2020 기준) 안드로이드 > 윈도우 > iOS > 맥 OS 순서 고성능, 고품질 소프트웨어 (예: 개발도구)는 데스크탑에서 작동한다. 비주얼 스튜디오, RAD 스튜디오, 안드로이드 스튜디오, Xcode, 이클립스 등 모바일 앱을 개발할 때조차 데스크탑을 사용한다. 왜 고성능, 고품질 애플리케이션은 데스크탑 중심인지 그 이유를 개발도구 기준으로 알아보자. 하드웨어 파워 CPU 파워 (더 높은 Core 개수와 Frequency) GPU 파워 (더 많은 GPU 지원) 전력 파워 (더 높은 와트와 암페어 = 계산 능력) 냉각 능력 (= 계산 능력) 미디어 용량 (HDD / SSD / M.2 SSD) 키보드와 마우스 기타 하드웨어 옵션: PCI / PCI-e / USB / 7+1 사운드 세상에서 가장 빠른 슈퍼컴들은 ARM기반이지만 모바일은 아니다. 개발 환경은 하드웨어 파워가 좋을 수록 좋다. 한번에 볼 수 있는 코드 라인 수 코드 한 줄이라도 더 보이면 좋다. (나는 한 줄이라도 더 보려고 태스크 바도 왼쪽에 놓는다.) 화면 크기 개발 환경의 화면은 충분히 큰 것이 좋다. 코딩 작업 시 관련 도구를 모두 보고 사용하면 좋다. (Debugger, Watch list, 런타임 앱, 바인딩 등) 앱 런타임, 표, 그래프, 파라미터, 숫자를 모두 보고 비교할 수 있으면 더 좋다. 시뮬레이터를 통해 실행 정보를 개발 환경에서 직접 비교하는 것도 중요하다. 또렷함과 가독성 표, 그래프, 바인딩, 이미지 위의 텍스트가 잘 보여야 한다. (특히 엔지니어링 소프트웨어 개발 시) 파라미터, 숫자의 변화를 이해하기 좋아야 한다. 폰트, 폰트 크기, 색상, 대비를 통해 또렷함과 가독성을 높이면 좋다. 민감도 손가락과 마우스는 선택하는 범위에 차이가 있다. 디자인, 코딩 작업 시 마우스 대신 손가락을 사용할 수는 없다. 소프트웨어 개발 주기 (순환) 계획-설계-컴파일-링킹-디버깅-개발-테스트-업로드(알파, 베타)-배포-업데이트-마케팅 각 단계 모두 데스크탑을 주로 사용한다. (더 효과적이기 때문이다.) 심지어 배포할 때에도 많은 정보를 넣어야 하므로 데스크탑을 사용한다. 분석이나 프로젝트 관리도 역시 데스크탑을 사용한다. 앱은 데이터베이스가 필요 작은 게임을 하나 만들어도 대체로 온라인 DB가 필요하다. 데이터베이스를 다루는 도구와 환경 역시 데스크탑이다. DB 사용 사례 1: AnaBilge1 (짧은 퀴즈 게임) RAD스튜디오에서 C++로 개발된 FMX 앱 구성 윈도우용 데스크탑: 관리 프로그램 (관리자가 퀴즈를 분석하고 임포트) 데스크탑 / 모바일 겸용: 간단한 퀴즈 앱 DB DB 사용 사례 2: AnaBilge2 (오픈 교육용 음성 보조 앱) 관리 프로그램 구성 윈도우용 데스크탑: 관리 프로그램 (관리자가 데이터 입력 및 분석) 윈도우용 데스크탑: 음성 보조 앱 (개발과 테스트를 더 빠르게 할 수 있으므로 윈도우용을 먼저 개발) 안드로이드 모바일: 음성 보조 앱 서버 DB DB 사용 사례 3: AnaKarikka (박물관용 파일 저장 및 3D 서비스) RAD스튜디오에서 C++로 개발된 앱 구성 윈도우용 데스크탑: 관리 프로그램 (관리자가 소장품 사진에 워터마크를 넣고 정보를 추가하여 파일로 저장) 40” 터치스크린: 박물관 방문객에게 가이드를 제공하는 애플리케이션 DB 요약 개발 전 과정에서 데스크탑 애플리케이션은 매우 필요하다. 모바일 앱은 온라인 데이터가 필요한 경우가 많다. 이 데이터를 관리하려면 데스크탑 데이터베이스 앱이 적합하다. 모바일 앱을 위한 데이터 입력 등 일부 관리 목적으로는 데스크탑 앱이 더 효과적이다. << UX Summit 2020 목록으로 이동
  4. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Why Desktop First to Develop an Application - Dr. Yılmaz Yörü 의 한글 요약본입니다. 발표자 (Dr. Yılmaz Yörü)는 1988년 이후 다양한 플랫폼에서 개발해 온 엠바카데로 C++ MVP입니다. "Wherever you code, Keep coding…, Cuz We Love Coding!" 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (21 min) 보기 이 세션은, (모바일 앱 보다는) 데스트톱 애플리케이션을 우선해야하는 상황, 고려 대상, 그리고 몇 가지 사례를 제시합니다. 플랫폼 선택 시 고려할 요소들을 여러분의 상황에 적용해보세요. 모바일과 데스크탑 앱 각각 어떤 쪽에 적합한지 사례를 참고하여 여러분의 상황에 적용해보세요. [UX Summit 2020 요약] "어떨 때" 모바일보다 데스크탑을 선택/집중하는 것이 좋을까? 를 함께 보는 것도 좋습니다. (이 글과는 또 다른 시각에서 본 사례 연구입니다.) 데스크탑과 모바일이라는 컴퓨팅 용어 정의는 사실 애매하다. 1940년대의 ENIAC에서부터 지금의 컨테이너형 슈퍼 컴퓨터, PLC시스템 등 다양한 컴퓨팅 장비를 예로 들고, 퍼스널 컴퓨터(PC), 모바일 폰 등등 다양한 용어를 통해 재미있는 화두를 던집니다. 보다 자세한 내용은 원본에서 볼 수 있습니다. 모바일과 데스크탑 점유율 (Statcounter.com 2020 기준) 전 세계적으로는 모바일 점유율이 더 높다. 하지만, 북미 또는 유럽만 보면 모바일보다 데스크탑의 점유율이 더 높다. 목표 시장이 선진국이면 데스크탑을 고려하는 것이 더 좋다. 운영체제 점유율 (Statcounter.com 2020 기준) 안드로이드 > 윈도우 > iOS > 맥 OS 순서 고성능, 고품질 소프트웨어 (예: 개발도구)는 데스크탑에서 작동한다. 비주얼 스튜디오, RAD 스튜디오, 안드로이드 스튜디오, Xcode, 이클립스 등 모바일 앱을 개발할 때조차 데스크탑을 사용한다. 왜 고성능, 고품질 애플리케이션은 데스크탑 중심인지 그 이유를 개발도구 기준으로 알아보자. 하드웨어 파워 CPU 파워 (더 높은 Core 개수와 Frequency) GPU 파워 (더 많은 GPU 지원) 전력 파워 (더 높은 와트와 암페어 = 계산 능력) 냉각 능력 (= 계산 능력) 미디어 용량 (HDD / SSD / M.2 SSD) 키보드와 마우스 기타 하드웨어 옵션: PCI / PCI-e / USB / 7+1 사운드 세상에서 가장 빠른 슈퍼컴들은 ARM기반이지만 모바일은 아니다. 개발 환경은 하드웨어 파워가 좋을 수록 좋다. 한번에 볼 수 있는 코드 라인 수 코드 한 줄이라도 더 보이면 좋다. (나는 한 줄이라도 더 보려고 태스크 바도 왼쪽에 놓는다.) 화면 크기 개발 환경의 화면은 충분히 큰 것이 좋다. 코딩 작업 시 관련 도구를 모두 보고 사용하면 좋다. (Debugger, Watch list, 런타임 앱, 바인딩 등) 앱 런타임, 표, 그래프, 파라미터, 숫자를 모두 보고 비교할 수 있으면 더 좋다. 시뮬레이터를 통해 실행 정보를 개발 환경에서 직접 비교하는 것도 중요하다. 또렷함과 가독성 표, 그래프, 바인딩, 이미지 위의 텍스트가 잘 보여야 한다. (특히 엔지니어링 소프트웨어 개발 시) 파라미터, 숫자의 변화를 이해하기 좋아야 한다. 폰트, 폰트 크기, 색상, 대비를 통해 또렷함과 가독성을 높이면 좋다. 민감도 손가락과 마우스는 선택하는 범위에 차이가 있다. 디자인, 코딩 작업 시 마우스 대신 손가락을 사용할 수는 없다. 소프트웨어 개발 주기 (순환) 계획-설계-컴파일-링킹-디버깅-개발-테스트-업로드(알파, 베타)-배포-업데이트-마케팅 각 단계 모두 데스크탑을 주로 사용한다. (더 효과적이기 때문이다.) 심지어 배포할 때에도 많은 정보를 넣어야 하므로 데스크탑을 사용한다. 분석이나 프로젝트 관리도 역시 데스크탑을 사용한다. 앱은 데이터베이스가 필요 작은 게임을 하나 만들어도 대체로 온라인 DB가 필요하다. 데이터베이스를 다루는 도구와 환경 역시 데스크탑이다. DB 사용 사례 1: AnaBilge1 (짧은 퀴즈 게임) RAD스튜디오에서 C++로 개발된 FMX 앱 구성 윈도우용 데스크탑: 관리 프로그램 (관리자가 퀴즈를 분석하고 임포트) 데스크탑 / 모바일 겸용: 간단한 퀴즈 앱 DB DB 사용 사례 2: AnaBilge2 (오픈 교육용 음성 보조 앱) 관리 프로그램 구성 윈도우용 데스크탑: 관리 프로그램 (관리자가 데이터 입력 및 분석) 윈도우용 데스크탑: 음성 보조 앱 (개발과 테스트를 더 빠르게 할 수 있으므로 윈도우용을 먼저 개발) 안드로이드 모바일: 음성 보조 앱 서버 DB DB 사용 사례 3: AnaKarikka (박물관용 파일 저장 및 3D 서비스) RAD스튜디오에서 C++로 개발된 앱 구성 윈도우용 데스크탑: 관리 프로그램 (관리자가 소장품 사진에 워터마크를 넣고 정보를 추가하여 파일로 저장) 40” 터치스크린: 박물관 방문객에게 가이드를 제공하는 애플리케이션 DB 요약 개발 전 과정에서 데스크탑 애플리케이션은 매우 필요하다. 모바일 앱은 온라인 데이터가 필요한 경우가 많다. 이 데이터를 관리하려면 데스크탑 데이터베이스 앱이 적합하다. 모바일 앱을 위한 데이터 입력 등 일부 관리 목적으로는 데스크탑 앱이 더 효과적이다. << UX Summit 2020 목록으로 이동 View full 엠바카데로 기술자료
×
×
  • Create New...

중요한 정보

이용약관 개인정보보호정책 이용규칙 이 사이트가 더 잘 작동하기 위해 방문자의 컴퓨터에 쿠키가 배치됩니다. 쿠키 설정 변경에서 원하는 설정을 할 수 있습니다. 변경하지 않으면 쿠키를 허용하는 것으로 이해합니다.