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

이 사이트 검색

검색 태그: 'ux/ui'.

  • 태그로 검색

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

콘텐츠 유형


게시판

  • 엠바카데로 (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 시리즈 중, Find leaks without leaving RAD Studio - Artem Razin 의 한국어 더빙 비디오입니다. 발표자(Artem Razin)는 Softanics의 창업자이며, Deleaker, ArmDot, BoxedApp 등을 개발했다. 이 세션은 델파이와 C++빌더에서 Deleaker를 이용하여 메모리 누수를 찾고 해당 소스로 이동하는 방법을 짧고 명확히 시연한다. 이 짧은 비디오는 한국어로 더빙이 되어 있습니다: YouTube 비디오 보기 (11 min, 한국어 더빙) Deleaker는 델파이와 C++빌더에서 사용되는 메모리 누수 (Memory Leak) 탐지 도구들 중에서 전용 도구 중 유일한 전용 도구이다. 이 제품이 유료인 이유는 사용해보면 알 수 있다. 메모리 누수 감지를 위한 정말 좋은 기능들이 제공된다. Delphi 시연 부분 보기 C++빌더 시연 부분 (7분 32초 부터) 보기 참고: RAD 스튜디오 안에서 메모리 누수 탐지하기(한국어 더빙) 시 사용한 스크립트 [00:18] Deleaker는 RAD 스튜디오에 플러그인 되어 메모리 누수를 탐지하고 리소스 사용을 효율적으로 최적화합니다. [00:27] 이 비디오에서는 Deleaker가 RAD 스튜디오 10.4 시드니에 어떻게 통합되는지 그리고, 개발자가 어떻게 메모리 누수를 찾고 해소하는 지를 보여줍니다. [00:36] Deleaker 설치파일을 실행합니다. [00:50] 설치되어 있는 RAD 스튜디오의 버전이 표시됩니다. 여기에 Deleaker가 통합됩니다. [01:06] RAD 스튜디오 10.4 시드니에 Deleaker를 통합하겠습니다. [01:17] 준비되었습니다. [01:21] 이제 RAD 스튜디오를 시작하겠습니다. [01:55] Deleaker 창은 언제든 RAD 스튜디오의 Deleaker 메뉴에서 열 수 있습니다. [02:09] 새 윈도우 VCL 애플리케이션을 만들겠습니다. [02:32] 프로젝트를 빌드하고 실행합니다. [03:02] RAD 스튜디오로 돌아와서 Deleaker 창을 열고 [Snapshot]을 클릭합니다. [03:22] 현재 살아있는 오브젝트를 보겠습니다. 클래스 이름별로 그룹핑 되어 있습니다. [03:36] 여기에 MainForm과 다른 오브젝트들이 보입니다. [03:42] 각 오브젝트마다 해당 크기, 소스파일, 호출 스택이 표시됩니다. [03:58] 이제 애플리케이션를 종료하겠습니다. [04:01] 애플리케이션 프로세스가 종료되면 Deleaker는 스냅샵을 찍기 시작합니다. [04:08] 누수가 없습니다. 예상대로입니다. [04:21] 누수를 만들어보겠습니다. [04:25] 폼에 버튼을 추가합니다. [04:33] 이름을 적습니다. [04:54] 버튼을 더블 클릭하여 이벤트 핸들러를 추가합니다. [04:58] 메모리를 하나 할당하고, TStringList 오브젝트도 하나 생성하겠습니다. [05:31] 지금 만든 누수를 Deleaker가 찾아낼 것입니다. [05:43] 빌드하고 실행합니다. [05:58] 누수가 생기도록 버튼을 몇번 클릭합니다. [06:05] 애플리케이션을 종료하겠습니다. 그러면 Deleaker가 스냅샷을 준비합니다. [06:13] Deleaker가 메모리 누수를 발견했습니다. 각 누수마다 발생 횟수, 크기, 소스 파일명, 호출 스택이 표시됩니다. [06:27] 누수되는 오브젝트를 찾기 위해 [Delphi Objects]를 클릭합니다. [06:31] Deleaker가 해당 TStringList 오브젝트를 찾아냈습니다. [06:37] 여기에 호출 스택이 표시됩니다. [06:42] 해당 소스 코드로 이동하려면 호출 스택에서 마우스 오른쪽을 클릭하고 Show Source Code를 선택합니다. [06:50] Deleaker에 의해 소스 파일이 열리고, 누수되는 오브젝트가 있는 줄에 커서가 위치합니다. [06:56] Deleaker로 돌아와 Allocation에서 메모리 할당 중 하나를 선택해 보겠습니다. [07:00] 메모리를 할당하는 GetMem 함수가 있는 줄로 찾아갑니다. [07:06] 최종 스냅샷에는 누수된 메모리와 해당 오브젝트의 크기, Hit Count, 횟수, 값과 모듈 정보가 모두 들어있습니다. 소스코드에서 할당된 리소스의 위치를 찾아가기도 쉽습니다. [07:30] Deleaker와 프로젝트를 모두 종료하겠습니다. [07:32] 이번에는 C++빌더로 비슷한 애플리케이션을 만들겠습니다. [07:50] 프로젝트가 준비되었습니다. 빌드하고 실행합니다. [08:25] 애플리케이션을 종료하지 않은 상태에서 개발툴로 가서, Deleaker창을 열고 [Snapshot]을 클릭하겠습니다. [08:38] 메모리 할당이 많이 표시됩니다. [08:42] 현재 살아있는 오브젝트들도 보입니다. [08:45] 오브젝트들은 클래스 이름 별로 그룹핑되어 있습니다 [08:49] 각 오브젝트 마다 호출 스택을 살펴볼 수 있습니다. [08:54] Deleaker와 애플리케이션을 종료합니다. [09:02] Deleaker가 글로벌 오브젝트 2개를 찾았네요. 좋아요. [09:13] 메모리 누수를 만들어보겠습니다. [09:16] 화면에 버튼을 놓고 이름을 줍니다. [09:27] 버튼을 더블클릭하여 이벤트 핸들러를 엽니다. [09:32] 메모리 누수 두개를 만들겠습니다. [09:57] 디버깅을 시작하겠습니다. [10:12] 버튼을 몇번 클릭하여 누수를 만듭니다. [10:16] 화면을 종료하면 Deleaker가 스냅샷을 찍습니다. [10:23] 스냅샷이 준비되었습니다. [10:26] Deleaker는 누수되는 오브젝트를 찾았습니다. [10:32] 여기에 해당 호출 스택이 있습니다. [10:34] 이 호출 스택에서 마우스 오른쪽을 클릭하고, Show Source Code 를 선택하여 누수가 발생하는 소스로 이동합니다. [10:40] 코드 편집기가 열리고 정확한 위치에 커서가 놓여있습니다. 좋네요. [10:44] Allocations를 열어보면 new 연산자에서 누수가 생긴 다는 것을 알게 됩니다. [10:51] Allocations에서 오른쪽 클릭을 하고, Show Source Code를 선택하여 소스 코드로 이동합니다. [10:58] 네, 정확한 코드 위치로 이동하였습니다. [11:02] Deleaker는 델파이와 C++빌더에서 사용할 수 있는 메모리 프로파일러입니다. [11:06] 개발자는 메모리 손실을 고칠 수 있고 윈도우 핸들과 기타 리소스의 누수 역시 고칠 수 있습니다. [11:10] RAD 스튜디오에 밀접하게 통합되기 때문에,개발 환경을 벗어날 필요없이 누수가 있는 코드로 바로 이동할 수 있습니다. [11:18] 행복한 코딩을 하시기 바랍니다. << UX Summit 2021 목록으로 이동
  2. << UX Summit으로 이동 엠바카데로 UX Summit의 2021 시리즈를 소개합니다. 테마: Desktop First UX (데스크톱 애플리케이션 개발자를 위한 UX/UI 구축 세미나) (한글 제목은 한글 요약본이 제공됩니다. 한글 요약본이 필요한 세션 또는 기타 의견이 있으면 댓글을 남기세요) 탭(Tab) 콘트롤은 데스크탑 UX를 어떻게 망가뜨리는가? - Ray Konopka (46 min) 탭 콘트롤 관련 16가지 예를 매우 짧고 명확히 설명하고 탭 콘트롤 디자인 가이드라인을 제시한다. RAD 스튜디오 안에서 메모리 누수 탐지하기 - Artem Razin (11 min, 한국어 더빙) 한국어 더빙 비디오 제공. 델파이와 C++빌더 안에서 메모리 누수가 있는 소스를 찾는 방법을 짧고 명확히 시연한다. Designing Multi-Threaded UIs - Olaf Monien RAD Studio 11 Preview - Marco Cantu Introduction to Data Abstract for Delphi - Marc Hoffman Introduction to Data Abstract for .NET - Marc Hoffman Introduction to Remoting SDK for Delphi - Marc Hoffman Introduction to Remoting SDK for .NET - Marc Hoffman Rubicon Full Text Search - Ann Lynnworth Improving User Experience with Effective Feedback Gathering - Kevin McCoy Delphi and the System of Laboratories, Analysis and Medical Management - Ziad Allaghi Creating Project Using EhLib - Dmitriy Bolshakov Native Response Design: Laying out Component for Dynamic Screen Sizing - Stephen Ball Vector Graphics: Lottie and SVG with Skia - Jim McKeeth Building Maintainable UIs with FLUX - Jason Southwell Achieve Best User Experience in Desktop Database Applications with FireDAC - Miguel Angel Moreno Rich and Lite IDE: UltraEdit and RAD Studio - David Millington, Ben Schwenk, Kyle Wheeler Case Studies on the Artificial Intelligence Integrated Desktop Engineering Applications - Dr. Yilmaz Yoru How Artificial Intelligence can improve UI/UX - Wagner Landgraf REST Client applications techniques with TMS XData - Wagner Landgraf Dashboard Systems: Design, Concept, and Coding Tips - Diego Souza The Evolution of the Windows UI to Fluent UI and Windows 11 - Abdullah Leghari Creating Cross Platform Desktop Applications with Web Technology from Delphi - Bruno Fierens Windows 11 Panel Session - David Millington & Matteo Pagani Visual Assist and Game Development - Chris Gardner, David Millington, Kyle Wheeler Building Your Own Design System: The Why and How - Jason Beres Desktop Databases: Options and Best Practices - Sriram Balasubramanian & Mary Kelly Design to Code : Go from Desktop to Web in Seconds! - Jason Beres (53 min) Utility & Design: The Desktop IDE - David Millington No Code + RPA to Optimize the Desktop UX - Dr. Setrag Khoshafian Learning C++ on the Desktop - Dr. Yilmaz Yoru Business of Desktop UI Components - Bruno Fierens & Atanas Popov Revamp your VCL App with DevExpress - Don Wibier Eight Questions I Had Every Day As A Dev Team Lead - Nick Hodges Building modern, High-DPI-ready, responsive user-interfaces with the VCL and TMS VCL UI Pack - Dr. Holger Flick Monday Panel with Live Q&A - Ian Barker MVP, Nick Hodges, marc hoffman & Ray Konopka Rubicon Full Text Search - Recap with Q&A - Ann Lynnworth Day 1 Overview Day 2 Overview Day 3 Overview Day 4 Overview Day 5 Overview << UX Summit으로 이동
  3. << UX Summit으로 이동 엠바카데로 UX Summit의 2021 시리즈를 소개합니다. 테마: Desktop First UX (데스크톱 애플리케이션 개발자를 위한 UX/UI 구축 세미나) (한글 제목은 한글 요약본이 제공됩니다. 한글 요약본이 필요한 세션 또는 기타 의견이 있으면 댓글을 남기세요) 탭(Tab) 콘트롤은 데스크탑 UX를 어떻게 망가뜨리는가? - Ray Konopka (46 min) 탭 콘트롤 관련 16가지 예를 매우 짧고 명확히 설명하고 탭 콘트롤 디자인 가이드라인을 제시한다. RAD 스튜디오 안에서 메모리 누수 탐지하기 - Artem Razin (11 min, 한국어 더빙) 한국어 더빙 비디오 제공. 델파이와 C++빌더 안에서 메모리 누수가 있는 소스를 찾는 방법을 짧고 명확히 시연한다. Designing Multi-Threaded UIs - Olaf Monien RAD Studio 11 Preview - Marco Cantu Introduction to Data Abstract for Delphi - Marc Hoffman Introduction to Data Abstract for .NET - Marc Hoffman Introduction to Remoting SDK for Delphi - Marc Hoffman Introduction to Remoting SDK for .NET - Marc Hoffman Rubicon Full Text Search - Ann Lynnworth Improving User Experience with Effective Feedback Gathering - Kevin McCoy Delphi and the System of Laboratories, Analysis and Medical Management - Ziad Allaghi Creating Project Using EhLib - Dmitriy Bolshakov Native Response Design: Laying out Component for Dynamic Screen Sizing - Stephen Ball Vector Graphics: Lottie and SVG with Skia - Jim McKeeth Building Maintainable UIs with FLUX - Jason Southwell Achieve Best User Experience in Desktop Database Applications with FireDAC - Miguel Angel Moreno Rich and Lite IDE: UltraEdit and RAD Studio - David Millington, Ben Schwenk, Kyle Wheeler Case Studies on the Artificial Intelligence Integrated Desktop Engineering Applications - Dr. Yilmaz Yoru How Artificial Intelligence can improve UI/UX - Wagner Landgraf REST Client applications techniques with TMS XData - Wagner Landgraf Dashboard Systems: Design, Concept, and Coding Tips - Diego Souza The Evolution of the Windows UI to Fluent UI and Windows 11 - Abdullah Leghari Creating Cross Platform Desktop Applications with Web Technology from Delphi - Bruno Fierens Windows 11 Panel Session - David Millington & Matteo Pagani Visual Assist and Game Development - Chris Gardner, David Millington, Kyle Wheeler Building Your Own Design System: The Why and How - Jason Beres Desktop Databases: Options and Best Practices - Sriram Balasubramanian & Mary Kelly Design to Code : Go from Desktop to Web in Seconds! - Jason Beres (53 min) Utility & Design: The Desktop IDE - David Millington No Code + RPA to Optimize the Desktop UX - Dr. Setrag Khoshafian Learning C++ on the Desktop - Dr. Yilmaz Yoru Business of Desktop UI Components - Bruno Fierens & Atanas Popov Revamp your VCL App with DevExpress - Don Wibier Eight Questions I Had Every Day As A Dev Team Lead - Nick Hodges Building modern, High-DPI-ready, responsive user-interfaces with the VCL and TMS VCL UI Pack - Dr. Holger Flick Monday Panel with Live Q&A - Ian Barker MVP, Nick Hodges, marc hoffman & Ray Konopka Rubicon Full Text Search - Recap with Q&A - Ann Lynnworth Day 1 Overview Day 2 Overview Day 3 Overview Day 4 Overview Day 5 Overview << UX Summit으로 이동 View full 엠바카데로 기술자료
  4. << UX Summit 2021 목록으로 이동 UX Summit 의 2021 시리즈 중, Find leaks without leaving RAD Studio - Artem Razin 의 한국어 더빙 비디오입니다. 발표자(Artem Razin)는 Softanics의 창업자이며, Deleaker, ArmDot, BoxedApp 등을 개발했다. 이 세션은 델파이와 C++빌더에서 Deleaker를 이용하여 메모리 누수를 찾고 해당 소스로 이동하는 방법을 짧고 명확히 시연한다. 이 짧은 비디오는 한국어로 더빙이 되어 있습니다: YouTube 비디오 보기 (11 min, 한국어 더빙) Deleaker는 델파이와 C++빌더에서 사용되는 메모리 누수 (Memory Leak) 탐지 도구들 중에서 전용 도구 중 유일한 전용 도구이다. 이 제품이 유료인 이유는 사용해보면 알 수 있다. 메모리 누수 감지를 위한 정말 좋은 기능들이 제공된다. Delphi 시연 부분 보기 C++빌더 시연 부분 (7분 32초 부터) 보기 참고: RAD 스튜디오 안에서 메모리 누수 탐지하기(한국어 더빙) 시 사용한 스크립트 [00:18] Deleaker는 RAD 스튜디오에 플러그인 되어 메모리 누수를 탐지하고 리소스 사용을 효율적으로 최적화합니다. [00:27] 이 비디오에서는 Deleaker가 RAD 스튜디오 10.4 시드니에 어떻게 통합되는지 그리고, 개발자가 어떻게 메모리 누수를 찾고 해소하는 지를 보여줍니다. [00:36] Deleaker 설치파일을 실행합니다. [00:50] 설치되어 있는 RAD 스튜디오의 버전이 표시됩니다. 여기에 Deleaker가 통합됩니다. [01:06] RAD 스튜디오 10.4 시드니에 Deleaker를 통합하겠습니다. [01:17] 준비되었습니다. [01:21] 이제 RAD 스튜디오를 시작하겠습니다. [01:55] Deleaker 창은 언제든 RAD 스튜디오의 Deleaker 메뉴에서 열 수 있습니다. [02:09] 새 윈도우 VCL 애플리케이션을 만들겠습니다. [02:32] 프로젝트를 빌드하고 실행합니다. [03:02] RAD 스튜디오로 돌아와서 Deleaker 창을 열고 [Snapshot]을 클릭합니다. [03:22] 현재 살아있는 오브젝트를 보겠습니다. 클래스 이름별로 그룹핑 되어 있습니다. [03:36] 여기에 MainForm과 다른 오브젝트들이 보입니다. [03:42] 각 오브젝트마다 해당 크기, 소스파일, 호출 스택이 표시됩니다. [03:58] 이제 애플리케이션를 종료하겠습니다. [04:01] 애플리케이션 프로세스가 종료되면 Deleaker는 스냅샵을 찍기 시작합니다. [04:08] 누수가 없습니다. 예상대로입니다. [04:21] 누수를 만들어보겠습니다. [04:25] 폼에 버튼을 추가합니다. [04:33] 이름을 적습니다. [04:54] 버튼을 더블 클릭하여 이벤트 핸들러를 추가합니다. [04:58] 메모리를 하나 할당하고, TStringList 오브젝트도 하나 생성하겠습니다. [05:31] 지금 만든 누수를 Deleaker가 찾아낼 것입니다. [05:43] 빌드하고 실행합니다. [05:58] 누수가 생기도록 버튼을 몇번 클릭합니다. [06:05] 애플리케이션을 종료하겠습니다. 그러면 Deleaker가 스냅샷을 준비합니다. [06:13] Deleaker가 메모리 누수를 발견했습니다. 각 누수마다 발생 횟수, 크기, 소스 파일명, 호출 스택이 표시됩니다. [06:27] 누수되는 오브젝트를 찾기 위해 [Delphi Objects]를 클릭합니다. [06:31] Deleaker가 해당 TStringList 오브젝트를 찾아냈습니다. [06:37] 여기에 호출 스택이 표시됩니다. [06:42] 해당 소스 코드로 이동하려면 호출 스택에서 마우스 오른쪽을 클릭하고 Show Source Code를 선택합니다. [06:50] Deleaker에 의해 소스 파일이 열리고, 누수되는 오브젝트가 있는 줄에 커서가 위치합니다. [06:56] Deleaker로 돌아와 Allocation에서 메모리 할당 중 하나를 선택해 보겠습니다. [07:00] 메모리를 할당하는 GetMem 함수가 있는 줄로 찾아갑니다. [07:06] 최종 스냅샷에는 누수된 메모리와 해당 오브젝트의 크기, Hit Count, 횟수, 값과 모듈 정보가 모두 들어있습니다. 소스코드에서 할당된 리소스의 위치를 찾아가기도 쉽습니다. [07:30] Deleaker와 프로젝트를 모두 종료하겠습니다. [07:32] 이번에는 C++빌더로 비슷한 애플리케이션을 만들겠습니다. [07:50] 프로젝트가 준비되었습니다. 빌드하고 실행합니다. [08:25] 애플리케이션을 종료하지 않은 상태에서 개발툴로 가서, Deleaker창을 열고 [Snapshot]을 클릭하겠습니다. [08:38] 메모리 할당이 많이 표시됩니다. [08:42] 현재 살아있는 오브젝트들도 보입니다. [08:45] 오브젝트들은 클래스 이름 별로 그룹핑되어 있습니다 [08:49] 각 오브젝트 마다 호출 스택을 살펴볼 수 있습니다. [08:54] Deleaker와 애플리케이션을 종료합니다. [09:02] Deleaker가 글로벌 오브젝트 2개를 찾았네요. 좋아요. [09:13] 메모리 누수를 만들어보겠습니다. [09:16] 화면에 버튼을 놓고 이름을 줍니다. [09:27] 버튼을 더블클릭하여 이벤트 핸들러를 엽니다. [09:32] 메모리 누수 두개를 만들겠습니다. [09:57] 디버깅을 시작하겠습니다. [10:12] 버튼을 몇번 클릭하여 누수를 만듭니다. [10:16] 화면을 종료하면 Deleaker가 스냅샷을 찍습니다. [10:23] 스냅샷이 준비되었습니다. [10:26] Deleaker는 누수되는 오브젝트를 찾았습니다. [10:32] 여기에 해당 호출 스택이 있습니다. [10:34] 이 호출 스택에서 마우스 오른쪽을 클릭하고, Show Source Code 를 선택하여 누수가 발생하는 소스로 이동합니다. [10:40] 코드 편집기가 열리고 정확한 위치에 커서가 놓여있습니다. 좋네요. [10:44] Allocations를 열어보면 new 연산자에서 누수가 생긴 다는 것을 알게 됩니다. [10:51] Allocations에서 오른쪽 클릭을 하고, Show Source Code를 선택하여 소스 코드로 이동합니다. [10:58] 네, 정확한 코드 위치로 이동하였습니다. [11:02] Deleaker는 델파이와 C++빌더에서 사용할 수 있는 메모리 프로파일러입니다. [11:06] 개발자는 메모리 손실을 고칠 수 있고 윈도우 핸들과 기타 리소스의 누수 역시 고칠 수 있습니다. [11:10] RAD 스튜디오에 밀접하게 통합되기 때문에,개발 환경을 벗어날 필요없이 누수가 있는 코드로 바로 이동할 수 있습니다. [11:18] 행복한 코딩을 하시기 바랍니다. << UX Summit 2021 목록으로 이동 View full 엠바카데로 기술자료
  5. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Mobile Second: When to Focus on Desktop First - Paul Shustak 의 한글 요약본입니다. 발표자 (Paul Shustak)는 20년 경력의 소프트웨어 제품 관리와 설계 전문가 입니다. 마이크로소프트, 어도비 등 큰 기업과 창업 등을 거쳤고, 지금은 최초의 길거리 예술 온라인 시장 플랫폼인 Beautify Earth 제품의 총 책임자입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (10 min) 보기 이 세션에서는 다음 주제를 다룹니다. 소프트웨어 시장 진출시, 모바일과 데스크탑 중 “내 상황에서는” 무엇부터 시작하는 것이 좋은지 판단하는 방법 “발표자의 상황에서는” 왜 데스트탑으로 시작하는 것이 유리했고 어떤 장점이 있었는지 사례를 공유 Karen.care 치매 환자의 삶과 재정, 건강, 법률 문제를 가족들이 함께 종합적으로 돌볼 수 있도록 돕는 소프트웨어 서비스를 최초로 제공한 스타트업이다. 데스크톱부터 먼저 시작했고, 성공 후 네이티브 모바일로도 확대했다. Karen.care 사용자의 작업흐름 3단계 가입 설문 참여: 돌봄 대상 정보, 재정 상황, 스트레스 수준 등 활동 목록 도출과 계획 수립: 알고리즘을 통해 설문 내용에 기반한 알맞은 가이드가 제시된다. 사용자는 이 가이드를 이용해 활동 목록을 검토하고 확정한다. 돌봄 활동을 함께 수행: 각자에게 할당된 활동을 수행한다. 전문가가 함께 참여할 수도 있다. (일종의 프로젝트 관리 방식) 스타트업으로서 Karen.care가 정한 제품 출시 원칙 3가지 최소 비용으로 구축: 시장 기대 수준에 도달하기까지 반복 개발을 얼마나 해야할지 모르니까 최대한 아끼자. 최단 시간에 반복: 초기에는 지식이 부족하다. 시간 역시 중요한 요소이므로 빠르고 빈번하게 향상시키자. 데이터 기반 의사 결정: 잘못된 결정으로 인한 낭비가 없도록 의사 결정 전에 데이터로 검증하자. 소프트웨어 개발에 대한 일반적인 의견 모바일부터 먼저 설계하라. 그렇지 않으면 모바일 UX가 나빠진다. 모바일 앱이 가장 중요하다. 우리의 의견 장기적으로는 어느 시점 이후에 모바일이 매우 중요해질 것이다. 하지만, 데스크톱만 먼저 시작하자. 데스크톱 앱으로 고객의 니즈를 충족한 후에 모바일 앱을 개발하면 모바일 앱 개발에만 집중하기가 더 좋다. Karen.care가 시장에 안착한 과정 - 데스크톱으로 시작부터 네이티브 모바일 앱 추가까지 1단계: 고객 파악: 인터뷰, 설문을 통해 잠재 고객의 고충과 해소 방안을 파악 3가지 기본 개념 검증: 알고리즘을 통한 돌봄 활동 목록 추천, 돌봄 활동을 함께 수행할 수 있도록 지원, 전문가 조언 연결 하지만, 사용자의 작업흐름과 사용법을 구현하려면 여전히 많은 질문을 던지고 피드백을 반영해야 했다. PoC (Proof of Concept)와 알고리즘 검증을 가능한 신속하게 반복하면서 점차 명확해졌다. 그 결과, 신속하게 반복하려면 데스크톱 하나만 집중하는 것이 옳다고 판단하였다. 2단계: 가설과 검증: 고객 파악 결과와 시장 데이터를 활용하여 검증 목표 고객 40~50대가 주목표고객 (틱톡, 인스타 등 모바일이 필수인 Z세대는 2차 고객) 모바일 앱은 초기 사업에서 필수가 아니라고 판단했다. 사용 패턴 Karen.care는 크게 계획 모드와 일상관리 모드로 사용되었다. 계획 모드에서는 사용자가 전략적인 생각을 해야했고, 시간도 많이 걸렸다. 오랫동안 사용하고 생각하기에는 데스크톱이 더 알맞다고 판단했다. 돌봄은 24x7 활동 돌봄 상황에서 사용자는 주로 컴퓨터 또는 노트북을 사용한다. 누워서 잠시 모바일로 사용하는 용도가 아니므로 모바일을 우선할 필요가 없다고 판단했다. 반응형 모바일 웹으로도 충분 GPS, 자이로스코프 등 스마트폰에 내장된 장비를 사용할 필요가 없다. 모바일은 네이티브 앱까지는 필요없고, 반응형 모바일 웹만으로도 충분하다고 판단했다. 다양한 운영체제(OS)를 사용 가족들은 서로 다른 운영체제를 사용한다. 네이티브 앱으로 제공하려면 각 플랫폼별로 프로그램을 따로 만들어야 한다. 비싸고 시간이 많이 든다. 데스크톱 웹으로만 시작하기로 결정했다. 3단계: 반복을 통한 개선과 사용자 피드백 반영 충분한 반복 후 우리가 만든 상품이 시장에 맞아들어가는 조짐을 보았다. 데스크톱으로만 먼저 시작한 것이 빠르게 시장에 안착하기에 옳았다는 것이 검증되었다. 4단계: 모바일 앱 추가 반응형 웹으로 모바일 서비스를 하면서 모바일 사용자로부터 충분한 의견을 받았다. 모바일 앱 착수 전에 이미 사용자에 대한 충분한 지식과 우리의 설계에 대해 자신이 생겼다. 이를 기반으로, 모바일 앱 개발에 착수했다. 앱의 기능과 작업흐름, 사용 방식에 대해 내부 토의가 많이 필요하고 쉽지 않았지만, 데스크톱 구현을 통해 확보한 노하우는 네이티브 앱을 만들 때 훨씬 더 쉽고 자신있게 결단하는데 큰 도움이 되었다. 데스크톱 우선 개발의 장점 더 빠르게 훨씬 적은 비용으로 반복 개발 웹 개발이 네이티브 앱 개발보다 훨씬 빠르고 저렴하다. 더 쉽게 사용, 더 쉽게 접근 웹에서 바로 사용하는 것이 앱스토어로 가서 다운로드 받아서 쓰기보다 간편하다. 다양한 운영체제 커버 다양한 운영체제에서 작동하려면 웹 애플리케이션이 각 플랫폼별로 네이티브 앱을 만드는 것보다 더 쉽다. SEO(검색 엔진 최적화) 더 많은 고객에게 노출 (네이티브 모바일 앱으로는 쉽지 않다.) SEO는 페이지에 태그를 정확히 달고 활용한다. 더 많은 사용자 확보, 더 빠른 의견 수렴을 통해 사업화 하기 좋다. 데스크톱으로 시작할 지 모바일로 시작하기에 알맞은 것인지를 파악하는 5가지 질문 사용자가 2/3가 넘는 시간을 모바일에서 시간을 보내는가? 처음 또는 두 번째 버전만으로 훌륭한 UX를 사용자에게 제공할 수 있는가? 핵심 기능 중 네이티브 모바일 앱이 반드시 있어야 가능한 것이 있는가? 네이티브 안드로이드와 네이티브 iOS앱이 반드시 있어야 시장에 안착할 수 있는가? 반복과 버전 향상을 충분히 할 수 있는 환경인가? 모두 NO 라면: 데스크톱을 먼저 고려 하나라도 YES 라면: 모바일을 먼저 고려 그림 1. Decision Tree << UX Summit 2020 목록으로 이동
  6. << UX Summit으로 이동 엠바카데로 UX Summit의 첫번째 시리즈인 UX Summit 2020을 소개합니다. 테마: Desktop First UX (데스크톱 애플리케이션 개발자를 위한 UX/UI 구축 세미나) (한글 제목은 한글 요약본이 제공됩니다. 한글 요약본이 필요한 세션 또는 기타 의견이 있으면 댓글을 남기세요) Keynote: How Mobile First Ruined Desktop UX - Ray Konopka (56 min) 모바일 우선이 데스크탑 UX에 어떤 영향을 끼쳤는지, 데스크탑 UX에는 왜 데스크탑 우선이 알맞은지 등 관련된 재미있는 사례와 유익한 정보들을 제공한다. 훌륭한 UI에 적용된 과학 (25 min) | Science of Great UI - Mark Miller of DevExpress 사람의 생물학적 인지 능력을 바탕으로 과학적으로 UI를 접근하여 훌륭한 UI 설계의 방향을 제시한다. 구체적인 사례로, 버튼의 형태나 색상 등을 어떻게 디자인하면, 사용자가 보다 쉽고 편하게 사용하고 인지하는 지를 분석한다. 멀티플랫폼 앱에 가장 효과적인 UX 디자인 (24 min) | Effective UX Design for Multiplatform Apps - Miguel Angel Moreno 오른쪽 클릭은 옳다! (24 min) | Right Click is Right! - Roger Swann 오른쪽 클릭을 왜 해야하고,어떻게 구현하는 지를 명쾌하게 설명한다. 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편 52 min, 2편 47 min) 마이크로소프트의 새 표준 디자인 컨셉인 플루언트 UI의 핵심을 정리 및 시연 하고(1편), 윈도우10 데스크톱 UX를 델파이 만으로 구현하는 기술을 시연한다(2편). 레거시 데스크탑 앱 UI/UX 현대화 – 이론부터 실제까지 (67 min) | Legacy desktop apps UI & UX modernization - Serge Pilko 15년 전에는 괜찮은 UI였는데, 이제는 구식으로 보이는 앱이 있나요? 어떤 전략과 방안을 선택을 할 수 있고, UI 현대화 절차, 팁, 위험 관리 방안을 사례를 들어 설명한다. 데스크탑용 UX 구축/최적화 전략 (13 min) | Strategies for Building and Optimizing the Desktop UX - Mary Kelly 데스트탑 전용 UX 구축 전략을 위한 수립 절차, 방법, 기본틀, 진행 팁을 공유한다. 터치스크린 POS 화면 디자인하기 (55 min) | Point of Sale Screen Concept - Diego Souza 식당용 POS 화면 하나를 그대로 따라하면 완성할 수 있도록 처음부터 하나씩 빠짐없이 시연한다. 애플리케이션을 개발할 때 데스크탑부터 개발해야 하는 이유 (20 min) | Why Desktop First to Develop an Application - Yılmaz Yörü 데스크탑 전용, 모바일 전용, 데스크탑-모바일 겸용 중 하나를 선택을 해야할 때의 판단 기준을 제시하고 각 사례를 제시한다. 감지와 응답: 우리의 방식을 지속적으로 파악하여 더 좋은 성과에 도달하기 (29 min) | Sense & Respond: Continuously Learning Our Way to Better Outcomes - Jeff Gothelf (사용자들은 소프트웨어를 계획된 대로만 사용하지는 않는다는 사실을 인정하고) 더 좋은 소프트웨어 UX를 제공하기 위한 근본적인 접근 방식을 제시한다. "어떨 때" 모바일보다 데스크톱을 선택/집중하는 것이 좋을까? (10 min) | Mobile Second: When to Focus on Desktop First - Paul Shustak (10 min) 새 소프트웨어를 출시하고 초기 시장에 안착하기 위해, 데스트탑과 모바일 중 “상황 맞는 선택"을 하기 위한 기준을 제시하고, 데스크탑을 우선하여 좋은 결과를 낸 사례를 분석한다. UNTOLD AI by Chris Noessel (18 min) Speed redesigns are the future - Michał Malewicz (21 min) Redesigning a Modern Developer IDE - Antonio Gomez (35 min) Lost Art Tweaking the OS - Bruno Sonnino (44 min) Building Consistent UI - Holger Flick (29 min) Build amazing applications with the Fluent Design System - Matteo Pagani (34 min) Building a Health Services Desktop Application in Delphi VCL - Ziad Allaghi (33 min) How to Terrify Your Users (& Look Cool at Parties) - Ian Barker (76 min) Desktop Native or Web on Windows? - Marco Cantu (25 min) Using Adobe XD for UI Wireframes - Nabanita Das (20 min) Leveraging Users' Visual System - Billy Hollis (75 min) Automation & Industrial User Interfaces - Zach Briggs (30 min) Desktop UX Panel #1: 데스트톱 UX (88 min) Desktop UX Panel #2: 데스트톱 UX (95 min) Desktop UX Panel #3: 데스트톱 UX (85 min) << UX Summit으로 이동
  7. << UX Summit으로 이동 엠바카데로 UX Summit의 첫번째 시리즈인 UX Summit 2020을 소개합니다. 테마: Desktop First UX (데스크톱 애플리케이션 개발자를 위한 UX/UI 구축 세미나) (한글 제목은 한글 요약본이 제공됩니다. 한글 요약본이 필요한 세션 또는 기타 의견이 있으면 댓글을 남기세요) Keynote: How Mobile First Ruined Desktop UX - Ray Konopka (56 min) 모바일 우선이 데스크탑 UX에 어떤 영향을 끼쳤는지, 데스크탑 UX에는 왜 데스크탑 우선이 알맞은지 등 관련된 재미있는 사례와 유익한 정보들을 제공한다. 훌륭한 UI에 적용된 과학 (25 min) | Science of Great UI - Mark Miller of DevExpress 사람의 생물학적 인지 능력을 바탕으로 과학적으로 UI를 접근하여 훌륭한 UI 설계의 방향을 제시한다. 구체적인 사례로, 버튼의 형태나 색상 등을 어떻게 디자인하면, 사용자가 보다 쉽고 편하게 사용하고 인지하는 지를 분석한다. 멀티플랫폼 앱에 가장 효과적인 UX 디자인 (24 min) | Effective UX Design for Multiplatform Apps - Miguel Angel Moreno 오른쪽 클릭은 옳다! (24 min) | Right Click is Right! - Roger Swann 오른쪽 클릭을 왜 해야하고,어떻게 구현하는 지를 명쾌하게 설명한다. 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편 52 min, 2편 47 min) 마이크로소프트의 새 표준 디자인 컨셉인 플루언트 UI의 핵심을 정리 및 시연 하고(1편), 윈도우10 데스크톱 UX를 델파이 만으로 구현하는 기술을 시연한다(2편). 레거시 데스크탑 앱 UI/UX 현대화 – 이론부터 실제까지 (67 min) | Legacy desktop apps UI & UX modernization - Serge Pilko 15년 전에는 괜찮은 UI였는데, 이제는 구식으로 보이는 앱이 있나요? 어떤 전략과 방안을 선택을 할 수 있고, UI 현대화 절차, 팁, 위험 관리 방안을 사례를 들어 설명한다. 데스크탑용 UX 구축/최적화 전략 (13 min) | Strategies for Building and Optimizing the Desktop UX - Mary Kelly 데스트탑 전용 UX 구축 전략을 위한 수립 절차, 방법, 기본틀, 진행 팁을 공유한다. 터치스크린 POS 화면 디자인하기 (55 min) | Point of Sale Screen Concept - Diego Souza 식당용 POS 화면 하나를 그대로 따라하면 완성할 수 있도록 처음부터 하나씩 빠짐없이 시연한다. 애플리케이션을 개발할 때 데스크탑부터 개발해야 하는 이유 (20 min) | Why Desktop First to Develop an Application - Yılmaz Yörü 데스크탑 전용, 모바일 전용, 데스크탑-모바일 겸용 중 하나를 선택을 해야할 때의 판단 기준을 제시하고 각 사례를 제시한다. 감지와 응답: 우리의 방식을 지속적으로 파악하여 더 좋은 성과에 도달하기 (29 min) | Sense & Respond: Continuously Learning Our Way to Better Outcomes - Jeff Gothelf (사용자들은 소프트웨어를 계획된 대로만 사용하지는 않는다는 사실을 인정하고) 더 좋은 소프트웨어 UX를 제공하기 위한 근본적인 접근 방식을 제시한다. "어떨 때" 모바일보다 데스크톱을 선택/집중하는 것이 좋을까? (10 min) | Mobile Second: When to Focus on Desktop First - Paul Shustak (10 min) 새 소프트웨어를 출시하고 초기 시장에 안착하기 위해, 데스트탑과 모바일 중 “상황 맞는 선택"을 하기 위한 기준을 제시하고, 데스크탑을 우선하여 좋은 결과를 낸 사례를 분석한다. UNTOLD AI by Chris Noessel (18 min) Speed redesigns are the future - Michał Malewicz (21 min) Redesigning a Modern Developer IDE - Antonio Gomez (35 min) Lost Art Tweaking the OS - Bruno Sonnino (44 min) Building Consistent UI - Holger Flick (29 min) Build amazing applications with the Fluent Design System - Matteo Pagani (34 min) Building a Health Services Desktop Application in Delphi VCL - Ziad Allaghi (33 min) How to Terrify Your Users (& Look Cool at Parties) - Ian Barker (76 min) Desktop Native or Web on Windows? - Marco Cantu (25 min) Using Adobe XD for UI Wireframes - Nabanita Das (20 min) Leveraging Users' Visual System - Billy Hollis (75 min) Automation & Industrial User Interfaces - Zach Briggs (30 min) Desktop UX Panel #1: 데스트톱 UX (88 min) Desktop UX Panel #2: 데스트톱 UX (95 min) Desktop UX Panel #3: 데스트톱 UX (85 min) << UX Summit으로 이동 View full 엠바카데로 기술자료
  8. UX Summit 2020> 중, 을(를) 요약/번역 했습니다. 발표자 ()는 . 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (총 56분) 보기 이 세션을 통해서 우리는, View full 아티클
  9. Kori

    [UX Summit 2020 요약] 훌륭한 UI에 적용된 과학

    << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Science of Great UI - Mark Miller 의 한글 요약본입니다. 발표자 (Mark Miller)는 16년간 훌륭한 UI를 연구해 오고 있으며, DevIQ에서 비디오 교육 과정도 제공하고 있습니다. 비디오 시청을 권장합니다. 쉽고 명확한 예시를 통해 좋은 화면과 그렇지 않은 것의 차이를 눈으로 쉽게 확인할 수 있습니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (25 min) 보기 이 세션에서는 매우 유용한 UI에 적용되는 과학적 원리와 응용된 팁을 배울 수 있습니다. 저는 개발 뿐만 아니라 문서 작성에도 이 원리를 적용하려고 합니다. 소개된 팁들 역시 바로 사용할 것입니다. 과학적 원리와 응용된 팁 과학적 원리 응용된 팁 중요도와 강조 대비가 클수록 강조도 커진다. 강조가 커지면, 구분도 명확해진다. 화면의 모든 요소가 정보이다. 하지만, 각 요소마다 중요도는 다르다 . 각 화면 요소에서 강조의 정도와 중요도를 일치시키자. 내용(주목적)을 강조하자. 형식(보조 수단)을 강조하지 말자. 대비와 가독성 명도 대비가 클 수록 가독성이 높다. 색상 대비는 가독성 향상 효과가 낮다. 가독성을 파악하려면, 흑백 필터를 적용하여 Brightness (밝기)를 비교한다. 글 상자의 여백 정답은 없지만, 알맞은 수준은 있다. 인간이 글을 인식하는 방식에 대한 실험 결과를 바탕으로 한다. 여백은 단어 사이 간격의 1.5배가 적당하다. 상자의 테두리 테두리는 선이 얇고 명도 대비가 낮을 때, 상자 안의 글자 인식을 덜 방해한다. 상자의 테두리 선은 명도 대비를 낮추고 얇은 선을 사용하자. (그러면, 여백을 충분히 줄여도 테두리가 내용을 방해하지 않는다.) 모서리 사람은 뾰족한 곳이 중요하다고 생각한다. 뾰족한 모서리는 시선을 끈다. 아이콘 등 작은 도형은 끝을 둥글게 만들자. 이유는, 같은 크기의 뾰족한 도형보다 더 많은 픽셀이 들어가므로 멀리서도 더 잘보이고, 더 커보인다. 뾰족한 지점이 만드는 불필요한 강조가 없어진다. 강조하고 싶은 곳만 뾰족한 모서리를 사용하자. 예: 연필 모양을 사용할 때, 연필 모양 끝 지점에 중요한 의미가 없다면, 그 지점도 둥글게 처리하자. 도형 안쪽 비우기 vs 채우기 (다음 표 참조)* 버튼을 강조하려면 버튼 색상을 채우자. 도형 안쪽 비우기와 채우기 비교 (사각형 버튼을 비교하기) 안쪽이 비어있고 테두리로 그려진 버튼 안쪽이 모두 채워진 버튼 (글자를 제외하고) 표시되는 픽셀수 1,000 개 10,000 개 사용된 사각형 개수 2개 (테두리 바깥쪽 사각형, 안쪽 사각형) 1개 모서리의 개수 8개 (테두리 바깥과 안) 4개 선명하지 않을 때의 전달력 시선을 끌지 못한다. 시선을 끈다. 시각적 메시지 강조되는 것은 테두리이다. (테두리에 뾰족한 모서리가 8개나 있다.) 강조되는 것은 도형 자체이다. UI 향상해보기 그림1. 왼쪽의 UI 보다 오른쪽 UI가 전달력이 높다. 위 그림의 왼쪽 UI를 오른쪽 UI로 바꾸기 위한 작업 각 도형의 불필요한 뾰족한 모서리 제거 그래프의 명도 대비를 확대 불필요하게 대문자로만 된 글자를 소문자로 변경 (모든 글자가 강조되어 서로 자기가 중요하다고 하는 것은 좋지 않다. 중요한 것만 강조하자.) 의미 없고 불필요한 색상을 제거하고 명도 변화만 살짝 적용 (중요하지 않은 곳이 시선을 끌지 않도록 하자.) (더 자세한 내용은 원본 비디오 참고) 기타 참고 스크린샷 (원본 비디오에는 더 많은 예시가 있습니다.) 그림2. 표의 테두리가 배경과 명도 대비가 낮고 얇을 수록 내용이 더 잘 들어온다. (표의 불필요한 여백도 줄일 수 있게 된다.) 그림3. 크기가 같은 도형이라도 모서리가 둥글면 도형에 사용되는 픽셀이 더 많아져서 더 커보이고 더 잘보인다. 그림4. 뾰족한 곳은 시선을 끈다. 중요한 곳을 강조하려면 상자에서 중요한 곳만 뾰족하게 하고 다른 모서리는 둥글게 처리한다. 그림5. 버튼 이미지는 채우는 것이 더 좋다. 그림6. 버튼의 모서리는 둥근 것이 더 좋다. << UX Summit 2020 목록으로 이동
  10. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Science of Great UI - Mark Miller 의 한글 요약본입니다. 발표자 (Mark Miller)는 16년간 훌륭한 UI를 연구해 오고 있으며, DevIQ에서 비디오 교육 과정도 제공하고 있습니다. 비디오 시청을 권장합니다. 쉽고 명확한 예시를 통해 좋은 화면과 그렇지 않은 것의 차이를 눈으로 쉽게 확인할 수 있습니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (25 min) 보기 이 세션에서는 매우 유용한 UI에 적용되는 과학적 원리와 응용된 팁을 배울 수 있습니다. 저는 개발 뿐만 아니라 문서 작성에도 이 원리를 적용하려고 합니다. 소개된 팁들 역시 바로 사용할 것입니다. 과학적 원리와 응용된 팁 과학적 원리 응용된 팁 중요도와 강조 대비가 클수록 강조도 커진다. 강조가 커지면, 구분도 명확해진다. 화면의 모든 요소가 정보이다. 하지만, 각 요소마다 중요도는 다르다 . 각 화면 요소에서 강조의 정도와 중요도를 일치시키자. 내용(주목적)을 강조하자. 형식(보조 수단)을 강조하지 말자. 대비와 가독성 명도 대비가 클 수록 가독성이 높다. 색상 대비는 가독성 향상 효과가 낮다. 가독성을 파악하려면, 흑백 필터를 적용하여 Brightness (밝기)를 비교한다. 글 상자의 여백 정답은 없지만, 알맞은 수준은 있다. 인간이 글을 인식하는 방식에 대한 실험 결과를 바탕으로 한다. 여백은 단어 사이 간격의 1.5배가 적당하다. 상자의 테두리 테두리는 선이 얇고 명도 대비가 낮을 때, 상자 안의 글자 인식을 덜 방해한다. 상자의 테두리 선은 명도 대비를 낮추고 얇은 선을 사용하자. (그러면, 여백을 충분히 줄여도 테두리가 내용을 방해하지 않는다.) 모서리 사람은 뾰족한 곳이 중요하다고 생각한다. 뾰족한 모서리는 시선을 끈다. 아이콘 등 작은 도형은 끝을 둥글게 만들자. 이유는, 같은 크기의 뾰족한 도형보다 더 많은 픽셀이 들어가므로 멀리서도 더 잘보이고, 더 커보인다. 뾰족한 지점이 만드는 불필요한 강조가 없어진다. 강조하고 싶은 곳만 뾰족한 모서리를 사용하자. 예: 연필 모양을 사용할 때, 연필 모양 끝 지점에 중요한 의미가 없다면, 그 지점도 둥글게 처리하자. 도형 안쪽 비우기 vs 채우기 (다음 표 참조)* 버튼을 강조하려면 버튼 색상을 채우자. 도형 안쪽 비우기와 채우기 비교 (사각형 버튼을 비교하기) 안쪽이 비어있고 테두리로 그려진 버튼 안쪽이 모두 채워진 버튼 (글자를 제외하고) 표시되는 픽셀수 1,000 개 10,000 개 사용된 사각형 개수 2개 (테두리 바깥쪽 사각형, 안쪽 사각형) 1개 모서리의 개수 8개 (테두리 바깥과 안) 4개 선명하지 않을 때의 전달력 시선을 끌지 못한다. 시선을 끈다. 시각적 메시지 강조되는 것은 테두리이다. (테두리에 뾰족한 모서리가 8개나 있다.) 강조되는 것은 도형 자체이다. UI 향상해보기 그림1. 왼쪽의 UI 보다 오른쪽 UI가 전달력이 높다. 위 그림의 왼쪽 UI를 오른쪽 UI로 바꾸기 위한 작업 각 도형의 불필요한 뾰족한 모서리 제거 그래프의 명도 대비를 확대 불필요하게 대문자로만 된 글자를 소문자로 변경 (모든 글자가 강조되어 서로 자기가 중요하다고 하는 것은 좋지 않다. 중요한 것만 강조하자.) 의미 없고 불필요한 색상을 제거하고 명도 변화만 살짝 적용 (중요하지 않은 곳이 시선을 끌지 않도록 하자.) (더 자세한 내용은 원본 비디오 참고) 기타 참고 스크린샷 (원본 비디오에는 더 많은 예시가 있습니다.) 그림2. 표의 테두리가 배경과 명도 대비가 낮고 얇을 수록 내용이 더 잘 들어온다. (표의 불필요한 여백도 줄일 수 있게 된다.) 그림3. 크기가 같은 도형이라도 모서리가 둥글면 도형에 사용되는 픽셀이 더 많아져서 더 커보이고 더 잘보인다. 그림4. 뾰족한 곳은 시선을 끈다. 중요한 곳을 강조하려면 상자에서 중요한 곳만 뾰족하게 하고 다른 모서리는 둥글게 처리한다. 그림5. 버튼 이미지는 채우는 것이 더 좋다. 그림6. 버튼의 모서리는 둥근 것이 더 좋다. << UX Summit 2020 목록으로 이동 View full 아티클
  11. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Effective UX Design for Multiplatform Apps - Miguel Angel Moreno 의 한글 요약본입니다. 발표자 (Miguel Angel Moreno)는 매우 넓고 풍부한 경험을 가진 엠바카데로 MVP 입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (24 min) 보기 이 세션은 델파이 개발자가 데스크탑 앱을 개발할 때 유용한 UX 구현 가이드라인을 제시합니다. 이 세션을 통해 우리는, 모바일 UX와 데스크탑 UX가 어떻게 달라야 하는지 알 수 있고, UX와 UI를 더 이상 혼동하지 않을 수 있습니다. 목차 UI vs UX: 역설 내 UI는 이미 좋다. 그런데 왜 UX를 고려해야 하나? “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 데스크탑은 리소스가 더 많다 데스크탑 UX 향상하기 1: 애플리케이션 설치 경험을 향상 데스크탑 UX 향상하기 2: 애플리케이션 시작 경험을 향상 데스크탑 UX 향상하기 3: 애플리케이션 안에서 화면 이동 경험을 향상 데스크탑 UX 향상하기 4: 다중 작업 능력을 활용 데스크탑 UX 향상하기 5: 데이터 확보 능력을 활용 데스크탑 UX 향상하기 6: 사용자 지원 능력을 향상 요약: 좋은 UX의 기본 요소 관련 추천 자료 UI vs UX: 역설 많은 개발자들이 UI와 UX를 바꿔쓰거나 부정확하게 사용한다. UX는 사용성(usability)이 아니다. 사용성은 UX의 일부일 뿐이다. 사용성은 UI의 성질 중의 하나로서 시스템이 배우기 쉬운지, 효율적으로 사용할 수 있는지, 사용할 때 즐거운지 등을 커버하는 UX의 한 부분이다. 소프트웨어 UX란 사용자가 소프트웨어를 고르고, 확보하고, 설치하고, 사용하고, 고객 지원을 받는 전 과정의 모든 것을 의미한다. UX란? UX(User eXperience) 라는 용어를 만든 Don Norman의 정의 (비디오 2분 08초부터의 내용) “사용자 경험 (UX, User Experience)는 최종 사용자가 "회사", "그 회사의 서비스", "그 회사의 제품"과 상호작용하는 모든 요소를 아우른다.” - Don Norman 그림1. Don Norman이 UX라는 용어를 만든 계기 - 그는 산업 디자인, 그래픽, 접점(Interface), 물리적 상호작용, 설명서 등 사람이 어느 시스템을 대하면서 경험하게 되는 모든 요소를 커버하는 용어를 원했는데 인간 접점(Human interface)이나 사용성(Usability)는 너무 좁은 의미만 담을 수 있었다. UX는 그 용어가 생기기 전부터 이미 있었다. (비디오 2분 30초부터의 내용) 그림2. UX는 그 용어가 생기기 전부터 이미 있었다. “디즈니 월드는 언제나 사람의 생활을 향상시킬 수 있는 최신 기술들이 모여있는 곳” - 월트 디즈니 명심할 점: 사용자들이 당신의 제품을 사용하면서 어떻게 느끼는가에 관한 것이 바로 UX이다. 내 UI는 이미 좋다. 그런데 왜 UX를 고려해야 하나? (비디오 3분 00초 부터의 내용) UI UX 대상 UI는 최종 사용자가 제품과 상호작용하는 성질을 대상으로 한다. UX는 제품의 목적과 기능을 대상으로 한다. 작업 UI 디자인은 최종 사용자가 보고, 듣고, 느끼는 것에 영향을 주는 작업이다. 제품의 디자인과 인터페이스에 연결된 미적인 구성 요소를 다룬다. UX 디자인은 시장 조사, 고객 니즈 파악을 위한 고객과의 커뮤니케이션 등 사회적인 구성 요소를 다루는 작업이다. 초점 UI는 최종 제품에 집중한다. (디자인 구성 요소를 이루는 기술 구성 요소를 주로 다룬다.) UX는 관리와 분석에 집중한다. (아이디어 창출, 개발, 전달까지 모든 프로젝트 단계를 다룬다.) 그림3. (완성된 제품인) 숟가락이 UI라면, (식사를 즐긴다는 과정, 즉) 숟가락을 사용하는 것은 UX 프로세스의 일부이다. 그림4. 더 좋은 UX를 제공하면 더 많은 고객이 관심을 가진다. (똑같은 케찹이지만, 사용 방식이 다르면 UX가 달라진다.) 그림5. 공사해서 만든 보도가 UI라면, 실제로 지나다니는 사람들이 만든 지름길은 UX이다. (보도가 지름길보다 보기에 더 멋지다. 즉, UI가 더 좋다. 하지만, 사용자에게 최고의 UX는 아니었기 때문에 사람들은 자신들의 UX를 만들었다.) 스마트폰이 널리 보급됨에 따라, “모바일 우선”현상이 심해지고 데스크탑의 UX는 지금 나쁘게 변해가고 있다. 사례 1: “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 - 구글앱스 (단일화된 UI만 추구) (비디오 5분 23초부터의 내용) 그림6. 구글앱스의 데스크탑 UX는 "모바일 우선"이라는 원칙을 지키기 위해 데스크탑이 제공할 수 있는 장점을 희생했다. (구글의 결정에 따라) 구글앱스에서 작업을 시작하려면, 일단 "햄버거 아이콘"을 사용하여 서랍 메뉴를 열어야 한다. (그 결과 데스크탑에서도 클릭을 2회 이상 해야한다.) 메뉴와 기능이 항상 보인다면 클릭을 1회만 하는게 더 좋은 UX가 아닐까? 참고. 구글 CEO 에릭 슈미트의 모바일 퍼스트 철학: “모든 것에서 모바일 우선, 애플리케이션도 모바일 우선, 사람들이 사물을 사용하는 방식도 모바일 우선” 사례 2: “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 - 윈도우 8 (비디오 6분 51초부터의 내용) 그림7. 윈도우 8 데스크탑 UX는 "터치 장비 사용자를 고려"했는데, 키보드와 마우스 사용자에게는 어색했다. 윈도우 8은 데스크탑의 커서 방식과 태블릿의 터치 방식을 모두 지원하도록 UI를 구현하였다. The Verge의 평가: “윈도우 8을 되돌아보면, 마이크로소프트가 당시에 잘못된 길을 선택했음을 쉽게 알 수 있다. 터치 기반 컴퓨팅에 크게 배팅했지만 결국 PC의 키보드와 마우스 사용이 어색하고, 불편하고 혼란스럽게 만들어버렸다.” 사례 3: “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 - 웹사이트의 미니멀리즘 (비디오 7분 35초부터의 내용) 그림8. 미니멀리즘은 화면이 작은 모바일에서는 실용적이지만, 화면이 큰 데스크탑에서는 효율적이지 않다. 웹사이트가 점점 “모바일 미니멀리즘”에 맞추기 위해 새로 디자인된다. 그 결과 데스크탑의 장점을 희생한다. 데스크탑에서는 더 많은 내용을 한번에 표현할 수 있는데도 미니멀리즘을 추구하느라 많은 내용을 숨긴다. (예, 요소와 메뉴를 아이콘 안에 숨기기, 내용의 앞부분만 보여주기) 모바일 디자인이 미니멀리즘에 기초하는 이유는 모바일에서 잘 사용하기 위해 꼭 필요하기 때문이다. (데스크탑에서 사용할 때는 굳이 필요하지 않을 수도 있다.) 데스크탑은 모바일과 달리 리소스가 더 풍부하기 때문에, 더 수준 높은 것들을 해낼 능력이 있다. 데스크탑 컴퓨터는 모바일 장비보다 리소스가 풍부하다. 스크린의 면적이 넓고 해상도가 높다: 많은 그래픽 요소를 한번에 표현할 수 있다. 메모리와 저장공간이 크다: 방대한 데이터 덩어리를 빠르고 효율적으로 다룰 수 있다. 데스크탑 UX 향상하기 1: 애플리케이션 설치 경험을 향상 “앱스토어”를 사용하자. 앱스토어는 모바일 앱 배포 방식에서 성공했고, 이제 데스크탑 소프트웨어에서도 제공된다. 최종 사용자는 앱스토어에서 매우 편하고 효과적으로 애플리케이션을 찾아서 설치한다. 설치 미디어 제공과 관련된 불필요한 부담이 없어진다. (강력하고 안전한 디지털 서명은 악성 프로그램이나 앱 변조를 제거하므로) 앱스토어에서 앱을 획득하는 것이 더 안전하다. RAD 스튜디오는 (윈도우 스토어와 맥 앱스토어) 데스크탑용 양대 앱스토어 배포를 지원한다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 2: 애플리케이션 시작 경험을 향상 애플리케이션을 작동시키는 경험은 누구나 가장 성가시게 느끼는 데스크탑 UX이다. 시간이 많이 걸리는 FormCreate 프로시저의 코드가 있으면, 시작되기 전에 대체로 모래시계를 표시한다. 최종 사용자는 혼란한 마음에 앱을 수차례 기동하고, 이로 인해 데이터가 꼬이기도 한다. (모래시계만 보이면, 데이터 로딩 중인지, 초기화 작업 중인지 등 앱이 실제로 무슨 작업을 하는 지 알 수 없기 때문이다.)
 이 문제를 해소하는 몇가지 코딩 패턴 스플래쉬 화면을 애플리케이션에 추가하기 (적어도 프로그램이 시작되고 있다는 것을 사용자가 알 수 있다.) 초기화 코드를 별도의 프로시저 안으로 옮기고, 기본 화면이 표시된 다음에 호출되도록 하기 그리고 화면에서 각 초기화 작업의 내용을 알려주기 (예: 데이터 로딩 현황 등을 표시하여 기다릴 수 있도록 안내한다.) 폼 생성 처리를 최소화하기 (폼이 많다면 기본 폼을 제외한 나머지 폼은 실제 사용될 때 생성하도록 한다.) 
 RAD스튜디오의 기본 설정(구동 시 모든 폼 생성)을 그대로 사용하면 폼이 많은 경우 구동 시간이 지연된다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 3: 애플리케이션 안에서 화면 이동 경험을 향상 화면 이동은 데스크탑 앱에서 가장 중요한 UX 특성 중 하나이다. 가능하면 관련된 개체들을 한 화면에서 모두 볼 수 있도록, 화면 공간을 활용하자. (그리드, 리스트, 트리 등) 주의: 많은 것을 한번에 보여주려면 그만큼 화면 구성을 잘 해야 한다. 잘못하면 오히려 혼란에 빠지는 역효과가 날 수 있다. 정보를 파악하기 쉽도록, 서로 관련된 개체들은 페이지나 탭에 모아두고, 각 페이지와 탭은 명확히 분리하자. 이동 버튼과 이동 보조 기능이 언제나 제공되어야 한다. 버튼 뿐만 아니라 키보드로도 쉽게 이동할 수도 있도록 하자. (모바일 UX에는 없는 데스크탑 UX 만의 장점이다.) VCL과 FMX 모두 폼 디자이너와 컴포넌트를 통해 좋은 화면을 구성할 수 있다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 4: 다중 작업 능력을 활용 데스크탑 앱은 멀티-코어 CPU와 풍부한 메모리를 사용한다. 대용량 데이터 로딩이나 집약된 수학 계산 등이 백그라운드에서 실행되도록 멀티 쓰레드와 병렬 처리 사용하자. UX를 훨씬 자연스럽게 해준다. RAD스튜디오의 기능 활용 작업 진행과 종료에 대한 명확한 시각적 표현과 공지를 제공할 수 있도록 다양한 시각적 컴포넌트가 제공된다. (데스크탑이기 때문에 제공할 수 있는 좋은 UX이다.) 멀티태스킹과 병렬 처리를 위한 라이브러리가 제공된다. 익명 메소드(Anonymous method)를 사용하면 멀티 태스킹 프로시저를 더 쉽게 작성하고 관리할 수 있다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 5: 데이터 확보 능력을 활용 데스크탑 앱은 모바일 앱에 비해 훨씬 큰 메모리를 사용할 수 있다. 사용자가 데이터를 읽거나 계층형으로 관련 데이터를 파악할 때 화면 이동이 자연스럽고 즉각 반응하는 것이 좋은 UX이다. 데스크탑에서는, 필요한 기준 데이터를 앱 구동 시 한번에 모두 로딩해 둘 수 있기 때문에 느리게 반응하는 문제를 해소할 수 있다. 반면에 모바일 앱의 경우, 데이터를 보관할 메모리가 충분하지 않으므로, 필요할 때 필요한 것만 가져오고 다 사용하면 버리는 방식이다. (데이터 가져오기는 시간이 많이 걸리는 작업인데 필요할 때마다 가져와야 한다.) SQL 클라이언트가 없기 때문에 대체로 REST 클라이언트가 SOA(Service Oriented Architecture) 서비스 서버에서 데이터를 받아오는 방식 등 제한된 방식으로 데이터를 다루게 된다. RAD 스튜디오의 FireDAC (데이터 엔진 클라이언트 라이브러리) 활용 로컬과 원격 데이터를 모두 빠르고 효율적으로 로드할 수 있다. 데이터 집약적인 상황에서는, 사용자가 이동하는 레코드에 따라 데이터가 순차적으로 로딩할 수 있다. FireDAC은 데이터를 필요한 것부터 로드한다. 한번 로드한 데이터는 버리지 않고 증분 방식으로 계속 새 데이터를 읽어들일 수 있다. 모바일 앱보다 훨씬 부드러운 UX를 제공하기에 적합하다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상 6: 사용자 지원 능력을 향상 데스크탑 앱은 화면 공간이 충분하므로 메시지 창을 제공하여도 주요 화면을 가리지 않는다. 슬랙 등 원하는 메시징 플랫폼을 사용하여 고객이 원할 때 즉시, 실시간 고객 지원을 하도록 구현한다. 필요시 원격 데스크탑 기능 등을 연결하면 사용자의 화면을 직접 보면서 사용자의 문제를 바로 해결하도록 구현한다. 사용자가 전화하고, 기다릴 필요가 없다. 이메일이나 화면 스크린샷 등도 필요없다. 이와 같은 불필요한 과정을 제거하면 현격하게 훌륭한 UX를 제공한다. “온라인 지원” 요청 버튼을 언제든 쉽게 찾을 수 있도록 애플리케이션 안에 구현한다. 그러면 사용자들은 쉽게 그 자리에서 서비스를 받을 수 있다. RAD 스튜디오의 기능 활용 TCP 또는 UDP 프로토콜을 직접 사용하는 간단한 메시징 솔루션을 구현할 수 있도록 컴포넌트가 제공된다. 슬랙 등 널리 사용되는 메시징 플랫폼의 REST API에 쉽게 연결할 수 있도록 REST 클라이언트 컴포넌트가 제공된다. (깃허브에 예제 코드 제공 예정) 요약: 좋은 UX의 기본 요소 사용자를 이해하자 사업의 타겟 고객을 명확히하고, 그들이 원하는 것과 필요로 하는 것을 이해하는 것이 목표이다. UX에 가장 필요한 능력은 공감 능력이다. UX 디자이너는 최종 사용자들이 필요로 하는 것과 그들의 감정을 이해하는 능력이 뛰어나야 한다. 디자인 전략을 수립하자 디자인 전략 안에는 제품의 목적을 이해하고 논리적인 사용 흐름의 맵을 만드는 과정이 들어가야 한다. 상호작용 설계를 분석하자 사용자들이 제품을 어떻게 사용하는 지 분석 사용 습관, 개인적 선호도 분석 UI와 상호작용하면서 어떤 지름길(바로가기)를 사용하는지 분석 와이어 프레임이나 프로토타입을 작성하자 UX 디자이너는 디자인 팀에게 아이디어와 그 목적을 전달하기 위해 와이어 프레임이나 프로토타입을 작성한다. 델파이는 프로토타입을 빠르게 만들 수 있다. (델파이 사용자라면 누구나 아는 사실) 관련 추천 자료 “UX” 용어 이해 - Don Norman (영문 비디오, 2min) The Design of Everyday Things - Don Norman (도서) 비전부터 UX 디자인까지 (From Vision to UX Design) with RAD Studio - S.듀폰트, C.자브로키스 (영문 비디오, 23min) (훌륭한 UX를 갖춘) 훌륭한 UI를 디자인 하는 방법 - D.밀링턴 (영문 아티클, 3부작) 코드 예제 (추후 업로드 예정) UX라는 용어가 생기기 전의 역사 (짧은 블로그와 비디오, 역자 추천) << UX Summit 2020 목록으로 이동
  12. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Effective UX Design for Multiplatform Apps - Miguel Angel Moreno 의 한글 요약본입니다. 발표자 (Miguel Angel Moreno)는 매우 넓고 풍부한 경험을 가진 엠바카데로 MVP 입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (24 min) 보기 이 세션은 델파이 개발자가 데스크탑 앱을 개발할 때 유용한 UX 구현 가이드라인을 제시합니다. 이 세션을 통해 우리는, 모바일 UX와 데스크탑 UX가 어떻게 달라야 하는지 알 수 있고, UX와 UI를 더 이상 혼동하지 않을 수 있습니다. 목차 UI vs UX: 역설 내 UI는 이미 좋다. 그런데 왜 UX를 고려해야 하나? “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 데스크탑은 리소스가 더 많다 데스크탑 UX 향상하기 1: 애플리케이션 설치 경험을 향상 데스크탑 UX 향상하기 2: 애플리케이션 시작 경험을 향상 데스크탑 UX 향상하기 3: 애플리케이션 안에서 화면 이동 경험을 향상 데스크탑 UX 향상하기 4: 다중 작업 능력을 활용 데스크탑 UX 향상하기 5: 데이터 확보 능력을 활용 데스크탑 UX 향상하기 6: 사용자 지원 능력을 향상 요약: 좋은 UX의 기본 요소 관련 추천 자료 UI vs UX: 역설 많은 개발자들이 UI와 UX를 바꿔쓰거나 부정확하게 사용한다. UX는 사용성(usability)이 아니다. 사용성은 UX의 일부일 뿐이다. 사용성은 UI의 성질 중의 하나로서 시스템이 배우기 쉬운지, 효율적으로 사용할 수 있는지, 사용할 때 즐거운지 등을 커버하는 UX의 한 부분이다. 소프트웨어 UX란 사용자가 소프트웨어를 고르고, 확보하고, 설치하고, 사용하고, 고객 지원을 받는 전 과정의 모든 것을 의미한다. UX란? UX(User eXperience) 라는 용어를 만든 Don Norman의 정의 (비디오 2분 08초부터의 내용) “사용자 경험 (UX, User Experience)는 최종 사용자가 "회사", "그 회사의 서비스", "그 회사의 제품"과 상호작용하는 모든 요소를 아우른다.” - Don Norman 그림1. Don Norman이 UX라는 용어를 만든 계기 - 그는 산업 디자인, 그래픽, 접점(Interface), 물리적 상호작용, 설명서 등 사람이 어느 시스템을 대하면서 경험하게 되는 모든 요소를 커버하는 용어를 원했는데 인간 접점(Human interface)이나 사용성(Usability)는 너무 좁은 의미만 담을 수 있었다. UX는 그 용어가 생기기 전부터 이미 있었다. (비디오 2분 30초부터의 내용) 그림2. UX는 그 용어가 생기기 전부터 이미 있었다. “디즈니 월드는 언제나 사람의 생활을 향상시킬 수 있는 최신 기술들이 모여있는 곳” - 월트 디즈니 명심할 점: 사용자들이 당신의 제품을 사용하면서 어떻게 느끼는가에 관한 것이 바로 UX이다. 내 UI는 이미 좋다. 그런데 왜 UX를 고려해야 하나? (비디오 3분 00초 부터의 내용) UI UX 대상 UI는 최종 사용자가 제품과 상호작용하는 성질을 대상으로 한다. UX는 제품의 목적과 기능을 대상으로 한다. 작업 UI 디자인은 최종 사용자가 보고, 듣고, 느끼는 것에 영향을 주는 작업이다. 제품의 디자인과 인터페이스에 연결된 미적인 구성 요소를 다룬다. UX 디자인은 시장 조사, 고객 니즈 파악을 위한 고객과의 커뮤니케이션 등 사회적인 구성 요소를 다루는 작업이다. 초점 UI는 최종 제품에 집중한다. (디자인 구성 요소를 이루는 기술 구성 요소를 주로 다룬다.) UX는 관리와 분석에 집중한다. (아이디어 창출, 개발, 전달까지 모든 프로젝트 단계를 다룬다.) 그림3. (완성된 제품인) 숟가락이 UI라면, (식사를 즐긴다는 과정, 즉) 숟가락을 사용하는 것은 UX 프로세스의 일부이다. 그림4. 더 좋은 UX를 제공하면 더 많은 고객이 관심을 가진다. (똑같은 케찹이지만, 사용 방식이 다르면 UX가 달라진다.) 그림5. 공사해서 만든 보도가 UI라면, 실제로 지나다니는 사람들이 만든 지름길은 UX이다. (보도가 지름길보다 보기에 더 멋지다. 즉, UI가 더 좋다. 하지만, 사용자에게 최고의 UX는 아니었기 때문에 사람들은 자신들의 UX를 만들었다.) 스마트폰이 널리 보급됨에 따라, “모바일 우선”현상이 심해지고 데스크탑의 UX는 지금 나쁘게 변해가고 있다. 사례 1: “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 - 구글앱스 (단일화된 UI만 추구) (비디오 5분 23초부터의 내용) 그림6. 구글앱스의 데스크탑 UX는 "모바일 우선"이라는 원칙을 지키기 위해 데스크탑이 제공할 수 있는 장점을 희생했다. (구글의 결정에 따라) 구글앱스에서 작업을 시작하려면, 일단 "햄버거 아이콘"을 사용하여 서랍 메뉴를 열어야 한다. (그 결과 데스크탑에서도 클릭을 2회 이상 해야한다.) 메뉴와 기능이 항상 보인다면 클릭을 1회만 하는게 더 좋은 UX가 아닐까? 참고. 구글 CEO 에릭 슈미트의 모바일 퍼스트 철학: “모든 것에서 모바일 우선, 애플리케이션도 모바일 우선, 사람들이 사물을 사용하는 방식도 모바일 우선” 사례 2: “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 - 윈도우 8 (비디오 6분 51초부터의 내용) 그림7. 윈도우 8 데스크탑 UX는 "터치 장비 사용자를 고려"했는데, 키보드와 마우스 사용자에게는 어색했다. 윈도우 8은 데스크탑의 커서 방식과 태블릿의 터치 방식을 모두 지원하도록 UI를 구현하였다. The Verge의 평가: “윈도우 8을 되돌아보면, 마이크로소프트가 당시에 잘못된 길을 선택했음을 쉽게 알 수 있다. 터치 기반 컴퓨팅에 크게 배팅했지만 결국 PC의 키보드와 마우스 사용이 어색하고, 불편하고 혼란스럽게 만들어버렸다.” 사례 3: “모바일 우선” 접근 방식이 “데스크탑에는 최악”이 되는 경우 - 웹사이트의 미니멀리즘 (비디오 7분 35초부터의 내용) 그림8. 미니멀리즘은 화면이 작은 모바일에서는 실용적이지만, 화면이 큰 데스크탑에서는 효율적이지 않다. 웹사이트가 점점 “모바일 미니멀리즘”에 맞추기 위해 새로 디자인된다. 그 결과 데스크탑의 장점을 희생한다. 데스크탑에서는 더 많은 내용을 한번에 표현할 수 있는데도 미니멀리즘을 추구하느라 많은 내용을 숨긴다. (예, 요소와 메뉴를 아이콘 안에 숨기기, 내용의 앞부분만 보여주기) 모바일 디자인이 미니멀리즘에 기초하는 이유는 모바일에서 잘 사용하기 위해 꼭 필요하기 때문이다. (데스크탑에서 사용할 때는 굳이 필요하지 않을 수도 있다.) 데스크탑은 모바일과 달리 리소스가 더 풍부하기 때문에, 더 수준 높은 것들을 해낼 능력이 있다. 데스크탑 컴퓨터는 모바일 장비보다 리소스가 풍부하다. 스크린의 면적이 넓고 해상도가 높다: 많은 그래픽 요소를 한번에 표현할 수 있다. 메모리와 저장공간이 크다: 방대한 데이터 덩어리를 빠르고 효율적으로 다룰 수 있다. 데스크탑 UX 향상하기 1: 애플리케이션 설치 경험을 향상 “앱스토어”를 사용하자. 앱스토어는 모바일 앱 배포 방식에서 성공했고, 이제 데스크탑 소프트웨어에서도 제공된다. 최종 사용자는 앱스토어에서 매우 편하고 효과적으로 애플리케이션을 찾아서 설치한다. 설치 미디어 제공과 관련된 불필요한 부담이 없어진다. (강력하고 안전한 디지털 서명은 악성 프로그램이나 앱 변조를 제거하므로) 앱스토어에서 앱을 획득하는 것이 더 안전하다. RAD 스튜디오는 (윈도우 스토어와 맥 앱스토어) 데스크탑용 양대 앱스토어 배포를 지원한다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 2: 애플리케이션 시작 경험을 향상 애플리케이션을 작동시키는 경험은 누구나 가장 성가시게 느끼는 데스크탑 UX이다. 시간이 많이 걸리는 FormCreate 프로시저의 코드가 있으면, 시작되기 전에 대체로 모래시계를 표시한다. 최종 사용자는 혼란한 마음에 앱을 수차례 기동하고, 이로 인해 데이터가 꼬이기도 한다. (모래시계만 보이면, 데이터 로딩 중인지, 초기화 작업 중인지 등 앱이 실제로 무슨 작업을 하는 지 알 수 없기 때문이다.)
 이 문제를 해소하는 몇가지 코딩 패턴 스플래쉬 화면을 애플리케이션에 추가하기 (적어도 프로그램이 시작되고 있다는 것을 사용자가 알 수 있다.) 초기화 코드를 별도의 프로시저 안으로 옮기고, 기본 화면이 표시된 다음에 호출되도록 하기 그리고 화면에서 각 초기화 작업의 내용을 알려주기 (예: 데이터 로딩 현황 등을 표시하여 기다릴 수 있도록 안내한다.) 폼 생성 처리를 최소화하기 (폼이 많다면 기본 폼을 제외한 나머지 폼은 실제 사용될 때 생성하도록 한다.) 
 RAD스튜디오의 기본 설정(구동 시 모든 폼 생성)을 그대로 사용하면 폼이 많은 경우 구동 시간이 지연된다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 3: 애플리케이션 안에서 화면 이동 경험을 향상 화면 이동은 데스크탑 앱에서 가장 중요한 UX 특성 중 하나이다. 가능하면 관련된 개체들을 한 화면에서 모두 볼 수 있도록, 화면 공간을 활용하자. (그리드, 리스트, 트리 등) 주의: 많은 것을 한번에 보여주려면 그만큼 화면 구성을 잘 해야 한다. 잘못하면 오히려 혼란에 빠지는 역효과가 날 수 있다. 정보를 파악하기 쉽도록, 서로 관련된 개체들은 페이지나 탭에 모아두고, 각 페이지와 탭은 명확히 분리하자. 이동 버튼과 이동 보조 기능이 언제나 제공되어야 한다. 버튼 뿐만 아니라 키보드로도 쉽게 이동할 수도 있도록 하자. (모바일 UX에는 없는 데스크탑 UX 만의 장점이다.) VCL과 FMX 모두 폼 디자이너와 컴포넌트를 통해 좋은 화면을 구성할 수 있다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 4: 다중 작업 능력을 활용 데스크탑 앱은 멀티-코어 CPU와 풍부한 메모리를 사용한다. 대용량 데이터 로딩이나 집약된 수학 계산 등이 백그라운드에서 실행되도록 멀티 쓰레드와 병렬 처리 사용하자. UX를 훨씬 자연스럽게 해준다. RAD스튜디오의 기능 활용 작업 진행과 종료에 대한 명확한 시각적 표현과 공지를 제공할 수 있도록 다양한 시각적 컴포넌트가 제공된다. (데스크탑이기 때문에 제공할 수 있는 좋은 UX이다.) 멀티태스킹과 병렬 처리를 위한 라이브러리가 제공된다. 익명 메소드(Anonymous method)를 사용하면 멀티 태스킹 프로시저를 더 쉽게 작성하고 관리할 수 있다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상하기 5: 데이터 확보 능력을 활용 데스크탑 앱은 모바일 앱에 비해 훨씬 큰 메모리를 사용할 수 있다. 사용자가 데이터를 읽거나 계층형으로 관련 데이터를 파악할 때 화면 이동이 자연스럽고 즉각 반응하는 것이 좋은 UX이다. 데스크탑에서는, 필요한 기준 데이터를 앱 구동 시 한번에 모두 로딩해 둘 수 있기 때문에 느리게 반응하는 문제를 해소할 수 있다. 반면에 모바일 앱의 경우, 데이터를 보관할 메모리가 충분하지 않으므로, 필요할 때 필요한 것만 가져오고 다 사용하면 버리는 방식이다. (데이터 가져오기는 시간이 많이 걸리는 작업인데 필요할 때마다 가져와야 한다.) SQL 클라이언트가 없기 때문에 대체로 REST 클라이언트가 SOA(Service Oriented Architecture) 서비스 서버에서 데이터를 받아오는 방식 등 제한된 방식으로 데이터를 다루게 된다. RAD 스튜디오의 FireDAC (데이터 엔진 클라이언트 라이브러리) 활용 로컬과 원격 데이터를 모두 빠르고 효율적으로 로드할 수 있다. 데이터 집약적인 상황에서는, 사용자가 이동하는 레코드에 따라 데이터가 순차적으로 로딩할 수 있다. FireDAC은 데이터를 필요한 것부터 로드한다. 한번 로드한 데이터는 버리지 않고 증분 방식으로 계속 새 데이터를 읽어들일 수 있다. 모바일 앱보다 훨씬 부드러운 UX를 제공하기에 적합하다. (깃허브에 예제 코드 제공 예정) 데스크탑 UX 향상 6: 사용자 지원 능력을 향상 데스크탑 앱은 화면 공간이 충분하므로 메시지 창을 제공하여도 주요 화면을 가리지 않는다. 슬랙 등 원하는 메시징 플랫폼을 사용하여 고객이 원할 때 즉시, 실시간 고객 지원을 하도록 구현한다. 필요시 원격 데스크탑 기능 등을 연결하면 사용자의 화면을 직접 보면서 사용자의 문제를 바로 해결하도록 구현한다. 사용자가 전화하고, 기다릴 필요가 없다. 이메일이나 화면 스크린샷 등도 필요없다. 이와 같은 불필요한 과정을 제거하면 현격하게 훌륭한 UX를 제공한다. “온라인 지원” 요청 버튼을 언제든 쉽게 찾을 수 있도록 애플리케이션 안에 구현한다. 그러면 사용자들은 쉽게 그 자리에서 서비스를 받을 수 있다. RAD 스튜디오의 기능 활용 TCP 또는 UDP 프로토콜을 직접 사용하는 간단한 메시징 솔루션을 구현할 수 있도록 컴포넌트가 제공된다. 슬랙 등 널리 사용되는 메시징 플랫폼의 REST API에 쉽게 연결할 수 있도록 REST 클라이언트 컴포넌트가 제공된다. (깃허브에 예제 코드 제공 예정) 요약: 좋은 UX의 기본 요소 사용자를 이해하자 사업의 타겟 고객을 명확히하고, 그들이 원하는 것과 필요로 하는 것을 이해하는 것이 목표이다. UX에 가장 필요한 능력은 공감 능력이다. UX 디자이너는 최종 사용자들이 필요로 하는 것과 그들의 감정을 이해하는 능력이 뛰어나야 한다. 디자인 전략을 수립하자 디자인 전략 안에는 제품의 목적을 이해하고 논리적인 사용 흐름의 맵을 만드는 과정이 들어가야 한다. 상호작용 설계를 분석하자 사용자들이 제품을 어떻게 사용하는 지 분석 사용 습관, 개인적 선호도 분석 UI와 상호작용하면서 어떤 지름길(바로가기)를 사용하는지 분석 와이어 프레임이나 프로토타입을 작성하자 UX 디자이너는 디자인 팀에게 아이디어와 그 목적을 전달하기 위해 와이어 프레임이나 프로토타입을 작성한다. 델파이는 프로토타입을 빠르게 만들 수 있다. (델파이 사용자라면 누구나 아는 사실) 관련 추천 자료 “UX” 용어 이해 - Don Norman (영문 비디오, 2min) The Design of Everyday Things - Don Norman (도서) 비전부터 UX 디자인까지 (From Vision to UX Design) with RAD Studio - S.듀폰트, C.자브로키스 (영문 비디오, 23min) (훌륭한 UX를 갖춘) 훌륭한 UI를 디자인 하는 방법 - D.밀링턴 (영문 아티클, 3부작) 코드 예제 (추후 업로드 예정) UX라는 용어가 생기기 전의 역사 (짧은 블로그와 비디오, 역자 추천) << UX Summit 2020 목록으로 이동 View full 아티클
  13. Kori

    [UX Summit 2020 요약] 오른쪽 클릭은 옳다!

    << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Right Click is Right - Roger Swann 의 한글 요약본입니다. 발표자 (Roger Swann)는 1981년 씨골 콘트롤즈 창업 이래, 모토롤라 8비트 칩 기반 소프트웨어 제작을 시작으로 지금까지 장비와 윈도우 소프트웨어를 개발해오고 있는 엠바카데로 C++ MVP입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (24 min) 보기, 소스코드 다운로드 이 세션에서 우리는, 오른쪽 클릭을 왜 해야하는지와 어떻게 구현하는지를 모두 명쾌하게 정리할 수 있습니다. 데스크톱 애플리케이션 화면 구성 시 꼭 생각해야 할 점들 (2 min) 왜 오른쪽 클릭이 좋은 UX를 제공하는가? (5 min) FMX와 VCL에서 오른쪽 클릭 구현 코드 작성하기 (Sample 코드 포함) VCL로 오른쪽 클릭 구현하기 Sample 코드 (8 min) FMX로 오른쪽 클릭 구현하기 Sample 코드 (2 min) 데스크톱 애플리케이션 화면 구성 전에 반드시 생각할 사항 이 소프트웨어의 목적이 무엇인가? 누가 무엇을 하기 위해 이 소프트웨어를 사용하는가? 화면은 사용하기에 쉽고 직관적이어야 한다. 대체로 소프트웨어의 목적은 사용자가 컴퓨터를 도구로 사용하여 원하는 작업을 쉽게 빠르고 정확히 처리하도록 하는 것이다. 화면은 사용하기에 쉽고 직관적이어야 한다. 일반 사용자는 프로그래머만큼 컴퓨터를 잘 알지 못한다. 일반 사용자들이 당신이 만든 소프트웨어를 선택할 수 있고 빠르게 배워서 잘 활용할 수 있어야 한다. 기업은 새로 들어온 직원도 쉽게 배워서 사용할 수 있는 소프트웨어를 선호한다. 디자인은 단순함을 유지하는 것이 중요하다. 마이크로소프트 윈도우와 오른쪽 클릭의 역사 DOS 시절 메뉴 DOS 시절에는 프로그램 화면 위쪽에 표현된 메뉴를 보고 사용했다. 당시에는 매뉴얼을 읽을 필요가 없었다. 그저 메뉴를 하나씩 살펴 보면 이해할 수 있었다. 윈도우 시절 메뉴 윈도우 시절에는 DOS 방식을 유지하면서 팝업 메뉴 방식이 새로 나왔다. 초창기 거의 모든 윈도우 프로그램이 이 방식을 지켰다. 팝업 메뉴 방식은 사용자가 특정 요소를 선택하고 오른쪽 클릭을 하면 그 요소로 할 수 있는 모든 메뉴가 나타나는 방식이다. 사용자는 원하는 요소에서 일단 오른쪽 클릭만 하고 나면 쉽게 사용할 수 있었다. 오른쪽 클릭이 옳은 이유 내가 소프트웨어 개발을 막 시작하던 시절에는, "이 컴퓨터 프로그램은 어떻게 사용하나요?" 라는 질문을 자주 받았는데, 그 당시 내 첫 대답은 항상 같았다. “사용하려는 요소를 선택하고 오른쪽 클릭을 하세요. 좋은 윈도우 프로그램이라면 당신이 원하는 것이 팝업으로 표시될 거예요.” 세상이 바뀌고 웹이 대두되면서, 소프트웨어 개발도 많은 다른 방식이 사용되었고 개발 방법에 대한 훈련이 부족한 개발자들이 많아졌다. 다양한 배경을 가진 사람들이 프로그래밍을 하거나 웹 사이트를 설계하기 시작했는데, 당시에는 정형화된 표준이 없다보니 목적이 같은 경우에서도 서로 다른 여러가지 방식이 사용되었다. 그리고 오른쪽 클릭을 해도 알맞은 메뉴가 나타지 않는 프로그램이 점차 많아졌다. 그 후 모바일 시대가 되면서, 다양한 모바일 플랫폼은 각자 오른쪽 마우스 클릭을 구현하는 방식이 제각각이어서 오른쪽 메뉴를 구현할 방법을 찾기도 더 어려워졌고 오른쪽 메뉴 구현도 더 줄어들었다. 요즘에 누군가 나에게 프로그램을 어떻게 사용하는지 물어보면, 나도 그 사람과 마찬가지로 일단 장비를 들고 처음부터 일일이 눌러본다. 이제는 질문을 한 일반 사용자와 내가 크게 다르지 않다. 나와 그 사람의 유일한 차이점은 화면에서 뭐든 눌러 볼 때 걱정하지 않고 필요한 기능을 찾아간다는 것이다. 우리는 지금 질서가 무너진 혼동 속에 있다. 데스크톱 애플리케이션은 윈도우 본연의 접근법을 지켜야 한다고 나는 주장한다. 즉, 어떤 항목에서든 사용자가 오른쪽 클릭을 하면 원하는 작업을 할 수 있도록 메뉴가 팝업으로 표시되는 방식이 지켜지면 좋다. 그러면, 사용자는 소프트웨어를 매우 빠르게 배울 수 있고, 신속하고 효과적으로 사용할 수 있다. 오른쪽 마우스 클릭을 구현할 때에는 창의적으로 디자인을 고려하자. (하지만, 애플리케이션의 본질적 기능을 늘 염두에 두자.) 사용 일관성을 유지하도록 디자인하자. 오른쪽 클릭으로 팝업 메뉴를 표시하는 시연(과 코드) 팝업 메뉴를 직접 만든 후, 화면에 이미지를 넣고 그 위에서 오른쪽 클릭을 하면, 제작한 팝업 메뉴가 나타나면서 증가와 감소 메뉴가 표시된다. 아래의 간단한 코드 작성 비디오를 따라하면, 텍스트 박스의 숫자를 증가 / 감소시킬 수 있는 오른쪽 클릭 기능을 구현할 수 있다. (시연과 Sample 코드를 보기 전 참고 사항: 시연은 32-bit CLang 컴파일러에서 작동시키지만, 이 코드는 64-bit CLang이나 기존 볼랜드 32-bit 컴파일러에서도 모두 작동한다. 시연 코드는 C++이지만, 델파이 개발자는 몇 줄 안되는 이 C++ 코드를 델파이로 쉽게 바꿀 수 있다.) VCL 시연부터 유튜브에서 보기 (8 min) FMX 시연부터 유튜브에서 보기 (2 min) 소스코드 다운로드 << UX Summit 2020 목록으로 이동
  14. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Right Click is Right - Roger Swann 의 한글 요약본입니다. 발표자 (Roger Swann)는 1981년 씨골 콘트롤즈 창업 이래, 모토롤라 8비트 칩 기반 소프트웨어 제작을 시작으로 지금까지 장비와 윈도우 소프트웨어를 개발해오고 있는 엠바카데로 C++ MVP입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (24 min) 보기, 소스코드 다운로드 이 세션에서 우리는, 오른쪽 클릭을 왜 해야하는지와 어떻게 구현하는지를 모두 명쾌하게 정리할 수 있습니다. 데스크톱 애플리케이션 화면 구성 시 꼭 생각해야 할 점들 (2 min) 왜 오른쪽 클릭이 좋은 UX를 제공하는가? (5 min) FMX와 VCL에서 오른쪽 클릭 구현 코드 작성하기 (Sample 코드 포함) VCL로 오른쪽 클릭 구현하기 Sample 코드 (8 min) FMX로 오른쪽 클릭 구현하기 Sample 코드 (2 min) 데스크톱 애플리케이션 화면 구성 전에 반드시 생각할 사항 이 소프트웨어의 목적이 무엇인가? 누가 무엇을 하기 위해 이 소프트웨어를 사용하는가? 화면은 사용하기에 쉽고 직관적이어야 한다. 대체로 소프트웨어의 목적은 사용자가 컴퓨터를 도구로 사용하여 원하는 작업을 쉽게 빠르고 정확히 처리하도록 하는 것이다. 화면은 사용하기에 쉽고 직관적이어야 한다. 일반 사용자는 프로그래머만큼 컴퓨터를 잘 알지 못한다. 일반 사용자들이 당신이 만든 소프트웨어를 선택할 수 있고 빠르게 배워서 잘 활용할 수 있어야 한다. 기업은 새로 들어온 직원도 쉽게 배워서 사용할 수 있는 소프트웨어를 선호한다. 디자인은 단순함을 유지하는 것이 중요하다. 마이크로소프트 윈도우와 오른쪽 클릭의 역사 DOS 시절 메뉴 DOS 시절에는 프로그램 화면 위쪽에 표현된 메뉴를 보고 사용했다. 당시에는 매뉴얼을 읽을 필요가 없었다. 그저 메뉴를 하나씩 살펴 보면 이해할 수 있었다. 윈도우 시절 메뉴 윈도우 시절에는 DOS 방식을 유지하면서 팝업 메뉴 방식이 새로 나왔다. 초창기 거의 모든 윈도우 프로그램이 이 방식을 지켰다. 팝업 메뉴 방식은 사용자가 특정 요소를 선택하고 오른쪽 클릭을 하면 그 요소로 할 수 있는 모든 메뉴가 나타나는 방식이다. 사용자는 원하는 요소에서 일단 오른쪽 클릭만 하고 나면 쉽게 사용할 수 있었다. 오른쪽 클릭이 옳은 이유 내가 소프트웨어 개발을 막 시작하던 시절에는, "이 컴퓨터 프로그램은 어떻게 사용하나요?" 라는 질문을 자주 받았는데, 그 당시 내 첫 대답은 항상 같았다. “사용하려는 요소를 선택하고 오른쪽 클릭을 하세요. 좋은 윈도우 프로그램이라면 당신이 원하는 것이 팝업으로 표시될 거예요.” 세상이 바뀌고 웹이 대두되면서, 소프트웨어 개발도 많은 다른 방식이 사용되었고 개발 방법에 대한 훈련이 부족한 개발자들이 많아졌다. 다양한 배경을 가진 사람들이 프로그래밍을 하거나 웹 사이트를 설계하기 시작했는데, 당시에는 정형화된 표준이 없다보니 목적이 같은 경우에서도 서로 다른 여러가지 방식이 사용되었다. 그리고 오른쪽 클릭을 해도 알맞은 메뉴가 나타지 않는 프로그램이 점차 많아졌다. 그 후 모바일 시대가 되면서, 다양한 모바일 플랫폼은 각자 오른쪽 마우스 클릭을 구현하는 방식이 제각각이어서 오른쪽 메뉴를 구현할 방법을 찾기도 더 어려워졌고 오른쪽 메뉴 구현도 더 줄어들었다. 요즘에 누군가 나에게 프로그램을 어떻게 사용하는지 물어보면, 나도 그 사람과 마찬가지로 일단 장비를 들고 처음부터 일일이 눌러본다. 이제는 질문을 한 일반 사용자와 내가 크게 다르지 않다. 나와 그 사람의 유일한 차이점은 화면에서 뭐든 눌러 볼 때 걱정하지 않고 필요한 기능을 찾아간다는 것이다. 우리는 지금 질서가 무너진 혼동 속에 있다. 데스크톱 애플리케이션은 윈도우 본연의 접근법을 지켜야 한다고 나는 주장한다. 즉, 어떤 항목에서든 사용자가 오른쪽 클릭을 하면 원하는 작업을 할 수 있도록 메뉴가 팝업으로 표시되는 방식이 지켜지면 좋다. 그러면, 사용자는 소프트웨어를 매우 빠르게 배울 수 있고, 신속하고 효과적으로 사용할 수 있다. 오른쪽 마우스 클릭을 구현할 때에는 창의적으로 디자인을 고려하자. (하지만, 애플리케이션의 본질적 기능을 늘 염두에 두자.) 사용 일관성을 유지하도록 디자인하자. 오른쪽 클릭으로 팝업 메뉴를 표시하는 시연(과 코드) 팝업 메뉴를 직접 만든 후, 화면에 이미지를 넣고 그 위에서 오른쪽 클릭을 하면, 제작한 팝업 메뉴가 나타나면서 증가와 감소 메뉴가 표시된다. 아래의 간단한 코드 작성 비디오를 따라하면, 텍스트 박스의 숫자를 증가 / 감소시킬 수 있는 오른쪽 클릭 기능을 구현할 수 있다. (시연과 Sample 코드를 보기 전 참고 사항: 시연은 32-bit CLang 컴파일러에서 작동시키지만, 이 코드는 64-bit CLang이나 기존 볼랜드 32-bit 컴파일러에서도 모두 작동한다. 시연 코드는 C++이지만, 델파이 개발자는 몇 줄 안되는 이 C++ 코드를 델파이로 쉽게 바꿀 수 있다.) VCL 시연부터 유튜브에서 보기 (8 min) FMX 시연부터 유튜브에서 보기 (2 min) 소스코드 다운로드 << UX Summit 2020 목록으로 이동 View full 아티클
  15. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Giving your Apps the Fluent UI Look and Feel with Delphi - Ian Barker 의 한글 요약본입니다. 발표자 (Ian Barker)는 델파이 개발자에게 잘 알려진 엠바카데로 MVP입니다. “Git과 Github를 사용해야하는 이유와 델파이 개발자가 꼭 필요한만큼만 사용하기”도 많은 관심을 받았습니다. 발표자 이안 바커(Ian Barker) 웹사이트 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 보기 (1편: 52분, 2편: 47분) 이 문서는 핵심 정리에 초점을 맞추었습니다. 비디오와 함께 보기를 권합니다. 1편에서는 (윈도우 개발자를 위한 일반적인 세션), 마이크로소프트의 새 표준 디자인 컨셉인 플루언트 UI의 핵심 개념을 정리하고, 윈도우10에서 실제로 어떻게 반영되었는지 살펴봅니다. 더 세련되어진 윈도우 10의 룩앤필과 UX를 적용하기 위해, 윈도우 애플리케이션 개발자에게 필요한 기술을 정리합니다. 2편에서는 (델파이 개발자를 위한 델파이 코드 중심 세션), 델파이 개발자들이 플루언트 UI를 구현하는 방법을 데모와 함께 설명합니다. (서드파티를 사용할 수도 있고, 순수 델파이 코드만으로도 가능합니다.) 소스 코드는 깃허브에서 무료로 볼 수 있습니다. 비디오에서 소스 코드 작성을 볼 수 있는데, 일반 UI 코드 작성 시에도 도움이 될 것입니다. 목차 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) (1편 비디오 보기) 플루언트 UI란? 마이크로소프트 디자인 요소를 정의한 디자인 언어의 최신판 이미 윈도우 10, 오피스 365 등 마이크로소프트 최신 제품들에 적용되어 있다. 마이크로소프트가 수많은 UX연구를 통해 실현한 미적인 새 디자인 (윈도우 96, 98, Me, 비스타를 거치면서 실패했거나 성공한 경험이 반영되었다.) 이미 멋지다고 알려졌던 바로 그 네온 프로젝트이다. 마이크로소프트 디자인 공식 웹페이지에서 무엇을 염두에 두었는지, 왜 그랬는지를 포함한 정확한 정보를 볼 수 있다. 한글 Wiki (플루언트 디자인 시스템) (다소 부정확한 내용도 있으므로 공식 웹사이트를 권장한다.) 플루언트 UI가 중요한 이유? 윈도우 애플리케이션 개발자라면 윈도우다운 룩앤필에 익숙해져야 한다. 사용자 입장에서, 윈도우 사용 경험과 여러분이 만든 윈도우 앱 경험이 일치해야 혼란을 느끼지 않는다. 이 디자인 표준을 벗어난 윈도우 애플리케이션은 구식으로 보이거나 윈도우와 충돌이 나서 사용자에게 불편을 줄 수 있다. 마이크로소프트가 잡는 디자인 방향이 주류가 되므로, 윈도우에서 작동되는 애플리케이션이라면 따를 수 밖에 없다. 윈도우 뿐만 아니라 마이크로소프트가 만드는 많은 개발 도구, API, SDK 등에서도 이 방향이 적용된다. 플루언트 디자인의 실제 모습: “윈도우10 설정 화면”에 잘 반영되어 있음 라이트모드, 다크모드가 제공된다. 마우스가 올라갔을 때 상자 테두리가 나타나는 곳은 기능이 있음을 의미한다. (마우스가 위치를 벗어나면 상자 테두리가 사라진다.) 포커스를 받은 윈도우는 테두리가 강조 표시된다. (기본 강조 색상: 빨강) 플루언트 UI의 기본 사상 마이크로소프트 디자인 언어 2 (MDL2)를 향상 메트로 UI로 알려진 마이크로소프트 디자인 언어 1 (MDL1)에서 시작되어 진화됨 오래전, 윈도우폰에 적용되었던 당시 통일된 UI를 시도했었다. 마이크로소프트는 메트로에서 폰과 윈도우 8 전체에 통일된 UI를 적용하고자 했으나 결국은 하드웨어 지원 문제 등의 이유로 실패했다. (자세한 내용은 관련글 참조) 예전에 이상하게 컸던 윈도우 버튼이 기억나는가? 플루언트 UI는 윈도우폰과 윈도우8에서 벗어난 후 새롭게 구축 한글 Wiki (메트로 디자인 언어) 마이크로소프트 플루언트 디자인 시스템 마이크로소프트 디자인 언어를 구현 2017년 10월, Window 10 업데이트에서 공식 데뷔 수많은 다양한 장비에서 윈도우가 이용되고 있으므로 단계적으로 안전하게 변화해오면서 이제는 상당히 정착됨 윈도우 7 디자인에서 윈도우 10 디자인으로 거의 옮겨감 (윈도우 8은 잠시 거쳐가는 정도였음) 윈도우10은 실제로 많은 서브 버전들이 있지만 모두 플루언트 UI가 일관적으로 적용됨 플루언트 UI의 핵심 개념 핵심 요소: Light, Depth, Motion, Fonts and Icons, Material 대부분 이미 MDL1 즉, 메트로 구현 시에 이미 있었지만, MDL2 즉, 플루언트 디자인에서 더 구체화되고 통일성이 갖추어졌다. 오피스 365 현재 버전에 그 특징이 잘 나타났다. (역자주: 아래 내용은 비디오를 보면 보다 명확히 이해할 수 있습니다.) 핵심 요소 주요 사항 Light (빛) 다크 모드 / 라이트 모드 Reveal Focus: (버튼, 윈도우 등) 클릭할 수 있는 요소가 포커스를 받으면 (마우스가 위치하거나 탭키로 포커스를 받으면) 그 테두리가 드러난다. Reveal Highlight: 마우스가 가리키고 있는 곳이 가장 밝고, 옆으로 가면서 점차 미세하게 옅어진다. (테두리 색상도 마찬가지로 미세하게 옅어지는 효과가 적용된다.) Depth (깊이) Z축을 이용하여 튀어나오게 만들어 내용을 차별화한다. 그림자가 다시 도입 - 여전히 기본적으로 평평한 디자인을 유지하지만, 깊이를 이용해 원하는 곳을 강조한다. Motion (움직임) 애니메이션 효과를 통해 사용자가 전환 내용을 이해할 수 있도록 한다. Fonts / Icons (폰트와 아이콘) Segoe* UI 폰트로 통일됨 Segoe 아이콘이 윈도우 10에 내장됨 아이콘은 윈도우에 맞게 통일감있게 사용하는 것이 좋다. 사람들은 이미 학습된 아이콘 모습을 보면 자동으로 기존 학습대로 인식한다. 따라서 윈도우의 아이콘을 다른 용도로 사용하면 사용자에게 혼란을 준다. (Font-Awesome 프로젝트에도 유사한 것들이 많이 있다.) Material (재질) 반투명한 시스루 룩을 윈도우 10에서 많이 경험했을 것이다. 이것이 대표적 재질인 아크릴 재질이다. 아크릴 재질은 뿌연 효과를 주기 위해 알파 투명도를 사용한다. 데모: 윈도우10 개인설정을 통해 플루언트 UI를 경험해보자. (20분 05초부터 데모 보기) 윈도우 바탕화면에서 오른쪽 마우스 후 가장 아래 항목인 “개인설정”을 선택해보자. Material (아크릴): 설정 창이 표시되고, 이 창 뒤에 가려진 화면은 반투명으로 비친다. Light (Reveal Highlight): 설정 창 왼쪽 메뉴 부분에서 마우스를 좌우로 움직이면 살짝 더 밝은 부분이 마우스를 따라다닌다. 즉, 미세한 그라데이션 효과가 생긴다. Light (다크 모드 / 화이트 모드): 설정 창 왼쪽 메뉴에서 “색”을 선택하면 다크 모드와 화이트 모드를 선택할 수 있다. Light (Reveal Focus): 설정 창 바깥을 클릭하면 설정 창의 테두리의 강조색이 사라지지만, 다시 설정 창 안쪽을 클릭하면 설정 창의 테두리에 강조색이 표시된다. Fonts와 Icons: 설정 창의 모든 글자와 아이콘은 Segoe UI 폰트와 Segoe 아이콘이다. 데모: 하나는 윈도우10의 설정 창과 모양과 방식이 똑같은 창을 델파이로 만들기 데모 (20분 54초부터 데모 보기) 델파이로 Material (아크릴), Light (하이라이트, 포커스) 등 플루언트 UI를 모두 구현할 수 있다. 이 데모는 델파이 10.4에서 AlMediaDev 라는 써드파티 컨트롤 세트를 사용했으므로 손쉽게 만들었다. (써드파티를 사용하지 않은 구현은 2편에 소개한다) AlMediaDev 컨트롤은 많은 프로퍼티를 통해 플루언트 UI를 반영 수 있도록 한다. 가격도 상당히 저렴하다. 예를 들어, FluentUIBackground 프로퍼티에서 Acrylic을 선택하면 Material에서 아크릴 효과를 줄 수 있다. FluentUIBorder, FluentUIInactiveAcrylicColorOpaq 등 플루언트 UI 구현 관련 속성이 많이 있다. 이 세션은 델파이 세션이기에 앞서 플루언트 UI에 대한 일반 세션이므로 델파이 부분은 생략한다 하지만, 내 블로그에는 다크 모드 / 화이트 모드를 탐지하는 법, 화면 해상도에 맞게 크기 변경 등 여러 코드와 안내가 있다. 델파이 코드 구현 보기: (24분 33초부터 데모 보기) 1편의 관련 자료와 링크 1편 발표 자료 및 원본 아티클 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) (2편 비디오 보기) 목차 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 데모: 델파이로 구현한 플루언트 UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 12분 50초부터 재생하기) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 데모: Almedia 컴포넌트로 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 그림1. 플루언트 UI가 적용된 윈도우 10 개인 설정 창 빛 (Light) 포커스 표현(Reveal Focus): 포커스를 받은 요소의 테두리를 눈에 띄도록 표시 강조 표현(Reveal Highlight): 마우스가 위치한 곳을 더 밝게 표시 깊이 (Depth) 오피스 2019 앱을 실행하면 나타나는 첫 화면에 잘 나타남 클릭할 수 있는 요소 역시 평소에는 평면이지만, 포커스를 받으면 그림자와 함께 3차원으로 튀어나와 보임 모션 (Motion) 윈도우 10 메일 앱을 열면 나타나는 화면에서 잘 나타남 앱의 배경인 구름이 흘러가는 것이 표현되어 생동감을 줌 폰트와 아이콘 (Font & Icon) Segoe UI 폰트 (평소에는 Segue UI의 light 폰트) 와 아이콘으로 통일됨 재질 (Material) 아크릴 바탕(Acrylic), 뒤에 있는 화면을 완전히 가리지 않고 반투명으로 표현, 투명도 적용 데모: 델파이로 구현한 플루언트UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 19분 51초부터 재생하기) 그림2. 플루언트UI가 적용된 Almedia에서 제공하는 데모 앱 그림3. 이 세션에서 사용한 플루언트 UI의 핵심 요소들을 구현한 앱 (델파이만으로 만든 앱과 Almedia를 사용한 앱 모두 깃허브에 소스 코드가 공개되어 있음) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 플루언트 UI의 빛(Light) - 포커스를 버튼에 표현하기: 우측 상단의 최소화 버튼 (비디오 20분 43초부터 재생하기) TRectangle [최소화 버튼] 이미지를 넣고, 그 안에 TFillRGBEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. 플루언트 UI의 깊이(Depth)를 버튼에 표현하기: 섹션 카드 (비디오 21분 28초부터 재생하기) TRoundRectangle 안에 TLabel과 TShadowEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. (TShadowEffect의 Enabled 속성이 True 이면 그림자가 표시된다.) 플루언트 UI의 재질(Material)을 버튼에 표현하기: 화면의 왼쪽 영역 (비디오 22분 42초부터 재생하기) 투명도 구현은 생각보다 쉽다 (의외로 많은 사람들이 어렵거나 불편한 방법을 사용하고 있다.) VCL에서는 TForm의 (AlphaBlend속성이 True이고) AlphaBlendValue가 255이면 불투명이다. 값이 0으로 가까이 갈 수록 더 투명해진다. FMX는 화면 그리기 방식이 VCL과 다르다. TForm의 Transparency 속성을 True로 주면 투명해진다. 그리고 나서 각 섹션에서 Opacity 속성을 사용해 투명도를 정한다. 이 데모의 FXM 폼에서는 BorderStyle 속성을 None으로 주어 테두리가 평소에 보이지 않도록 했다. 그리고 나서 화면 왼쪽의 TPanel의 Opacity 속성을 0~1 사이 값으로 설정하여 조절한다. (1 이면 완전히 불투명하다.) 이 데모의 TPanel의 투명도를 설정하는 부분은 우측 본 화면의 아래 쪽에 있다. TSpinBox를 통해 값을 받는다. // TSpinBox의 OnChange 이벤트를 처리하는 코드 // 0˜10까지 값을 받으면, 해당하는 Opacity(0~1)가 반영되도록 한다. procedure TForm1.SpinBox1Change(Sender: TObject); begin if SameText(Spinbox1.Text, '10') then Panel1.Opacity := 1 else Panel1.Opacity := StrToFloat('0.' + Spinbox1.Text); end; '플루언트 UI의 빛(Light) - 포커스를 폼 자체에 표현하기 (비디오 25분 19초부터 재생하기) 멀티플랫폼용인 FMX에서는 TForm의 OnActivate와 OnDeactivate 이벤트에서 포커스를 받았는지를 알 수 있다. 참고로, 윈도우 전용인 VCL에서는 TApplication의 이벤트을 사용해야 포커스를 받았는지를 알 수 있다. // ‘플루언트UI의 빛(Light)-포커스’를 OnActivate에서 강조, OnDeactivate에서 해제하는 코드 // [참고]윈도우 전용인 VCL에서는 TApplication을 사용해야 포커스를 받았는지를 알 수 있지만, // 멀티플랫폼용인 FMX에서는 TForm에서 가능하다 procedure TForm1.FormActivate(Sender: TObject); begin UpdateFocus(True); end; procedure TForm1.FormDeactivate(Sender: TObject); begin UpdateFocus(False); end; procedure TForm1.UpdateFocus(const IsFocussed: Boolean); begin // 창이 선택된 상태이고 AND 창이 최대화되지 않은 상태라면 // 창의 테두리 선을 표시하여 강조한다. if IsFocussed and (WindowState <> TWindowState.wsMaximized) then begin Line1.Stroke.Color := GetAccentColor(claRed); FillRGBEffect2.Color := Line1.Stroke.Color; FillRGBEffect3.Color := Line1.Stroke.Color; UpdateTransparency; end else begin Line1.Stroke.Color := claWhite; UpdateTransparency; // 창이 최대화된 경우, 투명도가 적용되지 않아야 한다. end; Line2.Stroke.Color := Line1.Stroke.Color; Line3.Stroke.Color := Line1.Stroke.Color; Line4.Stroke.Color := Line1.Stroke.Color; end; 가장 위쪽 툴바에서 마우스를 누른 상태로 창의 위치를 옮기도록 구현 하기 (비디오 26분 57초부터 재생하기) Mousedown 이벤트를 사용한다. // 창에 Title Bar가 없는 경우, 가장 윗쪽 툴바를 마우스로 누른 상태로 창의 위치를 옮길 수 있도록 하는 코드 // Mousedown 이벤트를 사용한다. procedure TForm1.Panel7MouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); begin if (Button = TMouseButton.mbLeft) then if WindowState <> TWindowState.wsMaximized then StartWindowDrag; end; 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내기 (비디오 27분 59초부터 재생하기) // 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내는 코드 function GetAccentColor(const TheDefault: TColor): TColor; const TheKey = 'SOFTWARE\Microsoft\Windows\DWM\'; TheValue = 'AccentColor'; var Reg: TRegistry; AccentCol: DWord; sStr: string; begin // 데스크톱 윈도우 관리자에 없는 값을 아래 레지스트리에서 가져올 수 있다: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\ // // 이 레지스트리에서 "AccentColor"의 DWORD 값을 찾는다. 이값은 창 테두리, 엣지 브라우저의 텝 등등에 적용된다. // // 해당 키의 전체 경로: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\AccentColor // Result := TheDefault; Reg := TRegistry.Create(KEY_READ); try Reg.RootKey := HKEY_CURRENT_USER; if Reg.KeyExists(TheKey) then if Reg.OpenKey(TheKey, False) then try if Reg.ValueExists(TheValue) then begin AccentCol := Reg.ReadInteger(TheValue); // AccentColor를 읽어서 8자리 헥사(Hex) 숫자로 변환 sStr := IntToHex(AccentCol, 8); // (Hex 값임을 표시하는) 첫 2자리 0x를 제거 sStr := Copy(sStr, 3, Length(sStr) - 2); // 이제, "$FF"를 앞에 놓고 RGB값을 뒤에서부터 떼어내어 델파이의 TColor에 맞추기 // // [참고] 델파이의 TColor에 맞추는 방법으로 GetRValue(), GetGValue() 등 훨씬 좋은 것들이 있다. // 이 방법을 쓰는 이유는, 편한 함수를 제공하는 유닛을 포함하지 않아도 되기 때문일 뿐이다. Result := TColor(StrToIntDef('$ff' + Copy(sStr, 5, 2) + Copy(sStr, 3, 2) + Copy(sStr, 1, 2), TheDefault)); end; finally Reg.CloseKey; end; finally Reg.Free; end; end; 그림4. 윈도우 레지스트리에 있는 강조색 (Accent Color) 값 데모: Almedia 컴포넌트를 사용하여 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) Almedia 컴포넌트는 플루언트 UI를 미리 반영해 두었으므로, 바로 사용하면 된다. 예를 들어, TscStyledForm에는 FluentUIAcrylicColor, FluentUIBackground, FluentUIBorder…의 속성이 이미있다. 라이선스 가격은 US$99 이며, 업데이트가 평생 무료로 제공된다. (다른 소프트웨어와 매우 다른 경우이다.) 참고로, 발표자(Ian Barker)는 Almedia 컴포넌트와 아무 관련이 없고, 단지 좋아해서 소개하는 것일 뿐이다. 윈도우 10 테마에 사용할 수 있는 델파이 테마 델파이의 'Windows 10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 Almedia 컴포넌트는 속성과 메소드가 매우 많아서 처음에 혼란스러울 수 있다. 하지만, 일단 한번 하고 나면 훨씬 쉬울 것이고, 매우 유용한 컴포넌트임을 알 수 있을 것이다. 이와 별개로, FMX 역시 UI구현이 매우 유연하고 강력하므로 FMX만 가지고 (소스 코드를 쓰지 않고) 플루언트UI를 구현하는 것도 매우 쉬웠다. 플루언트 UI는 훨씬 더 많은 것들이 있다. 이 세션의 간단한 데모는 플루언트 UI의 핵심을 중심으로 다루었으므로 좋은 시작점이 될 것이다. 이 세션에는 없지만 모션(Motion)을 구현하려면 Animation을 사용하면 된다. // AlmediaDev 컴포넌트로 개발하는 경우에도, 윈도우 테마를 맞춰주는 코드가 필요하다 procedure TVCLCalculatorForm.FormCreate(Sender: TObject); begin MatchWindowsTheme; ... end; // 윈도우 테마를 맞춰주는 코드 // [참고] Font.Color는 clWindows로, Font.Name은 Segoe로 되어 있어야 한다. procedure TVCLCalculatorForm.MatchWindowsTheme; var GoDark: Boolean; iInt: Integer; AButton: TComponent; begin // 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 // 델파이의 'Windows10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 SetAppropriateThemeMode('Tablet Dark', 'Windows10'); GoDark := DarkModeIsEnabled; // 이 코드는 Carbon 테마가, 윈도우 다크 테마와 잘 맞지 않기 때문임 for iInt in cNumberButtons do begin AButton := FindComponent('scGPButton' + IntToStr(iInt)); if (AButton <> Nil) then if (AButton is TscGPButton) then if GoDark then TscGPButton(AButton).Options.NormalColor := clBackground else TscGPButton(AButton).Options.NormalColor := clWindow; end; end; procedure SetAppropriateThemeMode(const DarkModeThemeName, LightModeThemeName: string); begin SetSpecificThemeMode(DarkModeIsEnabled, DarkModeThemeName, LightModeThemeName); end; procedure SetSpecificThemeMode(const AsDarkMode: Boolean; const DarkModeThemeName, LightModeThemeName: string); var ChosenTheme: string; begin if AsDarkMode then ChosenTheme := DarkModeThemeName else ChosenTheme := LightModeThemeName; TStyleManager.TrySetStyle(ChosenTheme, False); end; 2편의 관련 자료와 링크 2편 발표 자료 및 원본 아티클 사용된 Fluent UI 구현 소스 코드 다운로드 (깃허브) 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) << UX Summit 2020 목록으로 이동
  16. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Giving your Apps the Fluent UI Look and Feel with Delphi - Ian Barker 의 한글 요약본입니다. 발표자 (Ian Barker)는 델파이 개발자에게 잘 알려진 엠바카데로 MVP입니다. “Git과 Github를 사용해야하는 이유와 델파이 개발자가 꼭 필요한만큼만 사용하기”도 많은 관심을 받았습니다. 발표자 이안 바커(Ian Barker) 웹사이트 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 보기 (1편: 52분, 2편: 47분) 이 문서는 핵심 정리에 초점을 맞추었습니다. 비디오와 함께 보기를 권합니다. 1편에서는 (윈도우 개발자를 위한 일반적인 세션), 마이크로소프트의 새 표준 디자인 컨셉인 플루언트 UI의 핵심 개념을 정리하고, 윈도우10에서 실제로 어떻게 반영되었는지 살펴봅니다. 더 세련되어진 윈도우 10의 룩앤필과 UX를 적용하기 위해, 윈도우 애플리케이션 개발자에게 필요한 기술을 정리합니다. 2편에서는 (델파이 개발자를 위한 델파이 코드 중심 세션), 델파이 개발자들이 플루언트 UI를 구현하는 방법을 데모와 함께 설명합니다. (서드파티를 사용할 수도 있고, 순수 델파이 코드만으로도 가능합니다.) 소스 코드는 깃허브에서 무료로 볼 수 있습니다. 비디오에서 소스 코드 작성을 볼 수 있는데, 일반 UI 코드 작성 시에도 도움이 될 것입니다. 목차 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (1편) (1편 비디오 보기) 플루언트 UI란? 마이크로소프트 디자인 요소를 정의한 디자인 언어의 최신판 이미 윈도우 10, 오피스 365 등 마이크로소프트 최신 제품들에 적용되어 있다. 마이크로소프트가 수많은 UX연구를 통해 실현한 미적인 새 디자인 (윈도우 96, 98, Me, 비스타를 거치면서 실패했거나 성공한 경험이 반영되었다.) 이미 멋지다고 알려졌던 바로 그 네온 프로젝트이다. 마이크로소프트 디자인 공식 웹페이지에서 무엇을 염두에 두었는지, 왜 그랬는지를 포함한 정확한 정보를 볼 수 있다. 한글 Wiki (플루언트 디자인 시스템) (다소 부정확한 내용도 있으므로 공식 웹사이트를 권장한다.) 플루언트 UI가 중요한 이유? 윈도우 애플리케이션 개발자라면 윈도우다운 룩앤필에 익숙해져야 한다. 사용자 입장에서, 윈도우 사용 경험과 여러분이 만든 윈도우 앱 경험이 일치해야 혼란을 느끼지 않는다. 이 디자인 표준을 벗어난 윈도우 애플리케이션은 구식으로 보이거나 윈도우와 충돌이 나서 사용자에게 불편을 줄 수 있다. 마이크로소프트가 잡는 디자인 방향이 주류가 되므로, 윈도우에서 작동되는 애플리케이션이라면 따를 수 밖에 없다. 윈도우 뿐만 아니라 마이크로소프트가 만드는 많은 개발 도구, API, SDK 등에서도 이 방향이 적용된다. 플루언트 디자인의 실제 모습: “윈도우10 설정 화면”에 잘 반영되어 있음 라이트모드, 다크모드가 제공된다. 마우스가 올라갔을 때 상자 테두리가 나타나는 곳은 기능이 있음을 의미한다. (마우스가 위치를 벗어나면 상자 테두리가 사라진다.) 포커스를 받은 윈도우는 테두리가 강조 표시된다. (기본 강조 색상: 빨강) 플루언트 UI의 기본 사상 마이크로소프트 디자인 언어 2 (MDL2)를 향상 메트로 UI로 알려진 마이크로소프트 디자인 언어 1 (MDL1)에서 시작되어 진화됨 오래전, 윈도우폰에 적용되었던 당시 통일된 UI를 시도했었다. 마이크로소프트는 메트로에서 폰과 윈도우 8 전체에 통일된 UI를 적용하고자 했으나 결국은 하드웨어 지원 문제 등의 이유로 실패했다. (자세한 내용은 관련글 참조) 예전에 이상하게 컸던 윈도우 버튼이 기억나는가? 플루언트 UI는 윈도우폰과 윈도우8에서 벗어난 후 새롭게 구축 한글 Wiki (메트로 디자인 언어) 마이크로소프트 플루언트 디자인 시스템 마이크로소프트 디자인 언어를 구현 2017년 10월, Window 10 업데이트에서 공식 데뷔 수많은 다양한 장비에서 윈도우가 이용되고 있으므로 단계적으로 안전하게 변화해오면서 이제는 상당히 정착됨 윈도우 7 디자인에서 윈도우 10 디자인으로 거의 옮겨감 (윈도우 8은 잠시 거쳐가는 정도였음) 윈도우10은 실제로 많은 서브 버전들이 있지만 모두 플루언트 UI가 일관적으로 적용됨 플루언트 UI의 핵심 개념 핵심 요소: Light, Depth, Motion, Fonts and Icons, Material 대부분 이미 MDL1 즉, 메트로 구현 시에 이미 있었지만, MDL2 즉, 플루언트 디자인에서 더 구체화되고 통일성이 갖추어졌다. 오피스 365 현재 버전에 그 특징이 잘 나타났다. (역자주: 아래 내용은 비디오를 보면 보다 명확히 이해할 수 있습니다.) 핵심 요소 주요 사항 Light (빛) 다크 모드 / 라이트 모드 Reveal Focus: (버튼, 윈도우 등) 클릭할 수 있는 요소가 포커스를 받으면 (마우스가 위치하거나 탭키로 포커스를 받으면) 그 테두리가 드러난다. Reveal Highlight: 마우스가 가리키고 있는 곳이 가장 밝고, 옆으로 가면서 점차 미세하게 옅어진다. (테두리 색상도 마찬가지로 미세하게 옅어지는 효과가 적용된다.) Depth (깊이) Z축을 이용하여 튀어나오게 만들어 내용을 차별화한다. 그림자가 다시 도입 - 여전히 기본적으로 평평한 디자인을 유지하지만, 깊이를 이용해 원하는 곳을 강조한다. Motion (움직임) 애니메이션 효과를 통해 사용자가 전환 내용을 이해할 수 있도록 한다. Fonts / Icons (폰트와 아이콘) Segoe* UI 폰트로 통일됨 Segoe 아이콘이 윈도우 10에 내장됨 아이콘은 윈도우에 맞게 통일감있게 사용하는 것이 좋다. 사람들은 이미 학습된 아이콘 모습을 보면 자동으로 기존 학습대로 인식한다. 따라서 윈도우의 아이콘을 다른 용도로 사용하면 사용자에게 혼란을 준다. (Font-Awesome 프로젝트에도 유사한 것들이 많이 있다.) Material (재질) 반투명한 시스루 룩을 윈도우 10에서 많이 경험했을 것이다. 이것이 대표적 재질인 아크릴 재질이다. 아크릴 재질은 뿌연 효과를 주기 위해 알파 투명도를 사용한다. 데모: 윈도우10 개인설정을 통해 플루언트 UI를 경험해보자. (20분 05초부터 데모 보기) 윈도우 바탕화면에서 오른쪽 마우스 후 가장 아래 항목인 “개인설정”을 선택해보자. Material (아크릴): 설정 창이 표시되고, 이 창 뒤에 가려진 화면은 반투명으로 비친다. Light (Reveal Highlight): 설정 창 왼쪽 메뉴 부분에서 마우스를 좌우로 움직이면 살짝 더 밝은 부분이 마우스를 따라다닌다. 즉, 미세한 그라데이션 효과가 생긴다. Light (다크 모드 / 화이트 모드): 설정 창 왼쪽 메뉴에서 “색”을 선택하면 다크 모드와 화이트 모드를 선택할 수 있다. Light (Reveal Focus): 설정 창 바깥을 클릭하면 설정 창의 테두리의 강조색이 사라지지만, 다시 설정 창 안쪽을 클릭하면 설정 창의 테두리에 강조색이 표시된다. Fonts와 Icons: 설정 창의 모든 글자와 아이콘은 Segoe UI 폰트와 Segoe 아이콘이다. 데모: 하나는 윈도우10의 설정 창과 모양과 방식이 똑같은 창을 델파이로 만들기 데모 (20분 54초부터 데모 보기) 델파이로 Material (아크릴), Light (하이라이트, 포커스) 등 플루언트 UI를 모두 구현할 수 있다. 이 데모는 델파이 10.4에서 AlMediaDev 라는 써드파티 컨트롤 세트를 사용했으므로 손쉽게 만들었다. (써드파티를 사용하지 않은 구현은 2편에 소개한다) AlMediaDev 컨트롤은 많은 프로퍼티를 통해 플루언트 UI를 반영 수 있도록 한다. 가격도 상당히 저렴하다. 예를 들어, FluentUIBackground 프로퍼티에서 Acrylic을 선택하면 Material에서 아크릴 효과를 줄 수 있다. FluentUIBorder, FluentUIInactiveAcrylicColorOpaq 등 플루언트 UI 구현 관련 속성이 많이 있다. 이 세션은 델파이 세션이기에 앞서 플루언트 UI에 대한 일반 세션이므로 델파이 부분은 생략한다 하지만, 내 블로그에는 다크 모드 / 화이트 모드를 탐지하는 법, 화면 해상도에 맞게 크기 변경 등 여러 코드와 안내가 있다. 델파이 코드 구현 보기: (24분 33초부터 데모 보기) 1편의 관련 자료와 링크 1편 발표 자료 및 원본 아티클 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) 정말 멋진 윈도우 10 플루언트 UI를 델파이로 구현하기 (2편) (2편 비디오 보기) 목차 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 데모: 델파이로 구현한 플루언트 UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 12분 50초부터 재생하기) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 데모: Almedia 컴포넌트로 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) 마이크로소프트 플루언트 UI의 핵심 요소 5가지 (1편 내용 재정리) 그림1. 플루언트 UI가 적용된 윈도우 10 개인 설정 창 빛 (Light) 포커스 표현(Reveal Focus): 포커스를 받은 요소의 테두리를 눈에 띄도록 표시 강조 표현(Reveal Highlight): 마우스가 위치한 곳을 더 밝게 표시 깊이 (Depth) 오피스 2019 앱을 실행하면 나타나는 첫 화면에 잘 나타남 클릭할 수 있는 요소 역시 평소에는 평면이지만, 포커스를 받으면 그림자와 함께 3차원으로 튀어나와 보임 모션 (Motion) 윈도우 10 메일 앱을 열면 나타나는 화면에서 잘 나타남 앱의 배경인 구름이 흘러가는 것이 표현되어 생동감을 줌 폰트와 아이콘 (Font & Icon) Segoe UI 폰트 (평소에는 Segue UI의 light 폰트) 와 아이콘으로 통일됨 재질 (Material) 아크릴 바탕(Acrylic), 뒤에 있는 화면을 완전히 가리지 않고 반투명으로 표현, 투명도 적용 데모: 델파이로 구현한 플루언트UI를 델파이로 구현한 앱 실행 화면 보기 (비디오 19분 51초부터 재생하기) 그림2. 플루언트UI가 적용된 Almedia에서 제공하는 데모 앱 그림3. 이 세션에서 사용한 플루언트 UI의 핵심 요소들을 구현한 앱 (델파이만으로 만든 앱과 Almedia를 사용한 앱 모두 깃허브에 소스 코드가 공개되어 있음) 데모: 델파이 내장 컴포넌트로만 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 19분 49초부터 재생하기) 플루언트 UI의 빛(Light) - 포커스를 버튼에 표현하기: 우측 상단의 최소화 버튼 (비디오 20분 43초부터 재생하기) TRectangle [최소화 버튼] 이미지를 넣고, 그 안에 TFillRGBEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. 플루언트 UI의 깊이(Depth)를 버튼에 표현하기: 섹션 카드 (비디오 21분 28초부터 재생하기) TRoundRectangle 안에 TLabel과 TShadowEffect를 넣고 마우스 오버일 때 작동하도록 설정한다. (TShadowEffect의 Enabled 속성이 True 이면 그림자가 표시된다.) 플루언트 UI의 재질(Material)을 버튼에 표현하기: 화면의 왼쪽 영역 (비디오 22분 42초부터 재생하기) 투명도 구현은 생각보다 쉽다 (의외로 많은 사람들이 어렵거나 불편한 방법을 사용하고 있다.) VCL에서는 TForm의 (AlphaBlend속성이 True이고) AlphaBlendValue가 255이면 불투명이다. 값이 0으로 가까이 갈 수록 더 투명해진다. FMX는 화면 그리기 방식이 VCL과 다르다. TForm의 Transparency 속성을 True로 주면 투명해진다. 그리고 나서 각 섹션에서 Opacity 속성을 사용해 투명도를 정한다. 이 데모의 FXM 폼에서는 BorderStyle 속성을 None으로 주어 테두리가 평소에 보이지 않도록 했다. 그리고 나서 화면 왼쪽의 TPanel의 Opacity 속성을 0~1 사이 값으로 설정하여 조절한다. (1 이면 완전히 불투명하다.) 이 데모의 TPanel의 투명도를 설정하는 부분은 우측 본 화면의 아래 쪽에 있다. TSpinBox를 통해 값을 받는다. // TSpinBox의 OnChange 이벤트를 처리하는 코드 // 0˜10까지 값을 받으면, 해당하는 Opacity(0~1)가 반영되도록 한다. procedure TForm1.SpinBox1Change(Sender: TObject); begin if SameText(Spinbox1.Text, '10') then Panel1.Opacity := 1 else Panel1.Opacity := StrToFloat('0.' + Spinbox1.Text); end; '플루언트 UI의 빛(Light) - 포커스를 폼 자체에 표현하기 (비디오 25분 19초부터 재생하기) 멀티플랫폼용인 FMX에서는 TForm의 OnActivate와 OnDeactivate 이벤트에서 포커스를 받았는지를 알 수 있다. 참고로, 윈도우 전용인 VCL에서는 TApplication의 이벤트을 사용해야 포커스를 받았는지를 알 수 있다. // ‘플루언트UI의 빛(Light)-포커스’를 OnActivate에서 강조, OnDeactivate에서 해제하는 코드 // [참고]윈도우 전용인 VCL에서는 TApplication을 사용해야 포커스를 받았는지를 알 수 있지만, // 멀티플랫폼용인 FMX에서는 TForm에서 가능하다 procedure TForm1.FormActivate(Sender: TObject); begin UpdateFocus(True); end; procedure TForm1.FormDeactivate(Sender: TObject); begin UpdateFocus(False); end; procedure TForm1.UpdateFocus(const IsFocussed: Boolean); begin // 창이 선택된 상태이고 AND 창이 최대화되지 않은 상태라면 // 창의 테두리 선을 표시하여 강조한다. if IsFocussed and (WindowState <> TWindowState.wsMaximized) then begin Line1.Stroke.Color := GetAccentColor(claRed); FillRGBEffect2.Color := Line1.Stroke.Color; FillRGBEffect3.Color := Line1.Stroke.Color; UpdateTransparency; end else begin Line1.Stroke.Color := claWhite; UpdateTransparency; // 창이 최대화된 경우, 투명도가 적용되지 않아야 한다. end; Line2.Stroke.Color := Line1.Stroke.Color; Line3.Stroke.Color := Line1.Stroke.Color; Line4.Stroke.Color := Line1.Stroke.Color; end; 가장 위쪽 툴바에서 마우스를 누른 상태로 창의 위치를 옮기도록 구현 하기 (비디오 26분 57초부터 재생하기) Mousedown 이벤트를 사용한다. // 창에 Title Bar가 없는 경우, 가장 윗쪽 툴바를 마우스로 누른 상태로 창의 위치를 옮길 수 있도록 하는 코드 // Mousedown 이벤트를 사용한다. procedure TForm1.Panel7MouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, Y: Single); begin if (Button = TMouseButton.mbLeft) then if WindowState <> TWindowState.wsMaximized then StartWindowDrag; end; 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내기 (비디오 27분 59초부터 재생하기) // 사용자가 윈도우에서 설정한 ‘강조색(Accent Color)’ 알아내는 코드 function GetAccentColor(const TheDefault: TColor): TColor; const TheKey = 'SOFTWARE\Microsoft\Windows\DWM\'; TheValue = 'AccentColor'; var Reg: TRegistry; AccentCol: DWord; sStr: string; begin // 데스크톱 윈도우 관리자에 없는 값을 아래 레지스트리에서 가져올 수 있다: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\ // // 이 레지스트리에서 "AccentColor"의 DWORD 값을 찾는다. 이값은 창 테두리, 엣지 브라우저의 텝 등등에 적용된다. // // 해당 키의 전체 경로: // \\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM\AccentColor // Result := TheDefault; Reg := TRegistry.Create(KEY_READ); try Reg.RootKey := HKEY_CURRENT_USER; if Reg.KeyExists(TheKey) then if Reg.OpenKey(TheKey, False) then try if Reg.ValueExists(TheValue) then begin AccentCol := Reg.ReadInteger(TheValue); // AccentColor를 읽어서 8자리 헥사(Hex) 숫자로 변환 sStr := IntToHex(AccentCol, 8); // (Hex 값임을 표시하는) 첫 2자리 0x를 제거 sStr := Copy(sStr, 3, Length(sStr) - 2); // 이제, "$FF"를 앞에 놓고 RGB값을 뒤에서부터 떼어내어 델파이의 TColor에 맞추기 // // [참고] 델파이의 TColor에 맞추는 방법으로 GetRValue(), GetGValue() 등 훨씬 좋은 것들이 있다. // 이 방법을 쓰는 이유는, 편한 함수를 제공하는 유닛을 포함하지 않아도 되기 때문일 뿐이다. Result := TColor(StrToIntDef('$ff' + Copy(sStr, 5, 2) + Copy(sStr, 3, 2) + Copy(sStr, 1, 2), TheDefault)); end; finally Reg.CloseKey; end; finally Reg.Free; end; end; 그림4. 윈도우 레지스트리에 있는 강조색 (Accent Color) 값 데모: Almedia 컴포넌트를 사용하여 플루언트 UI를 구현한 앱 작동 및 구현 방법 설명 (비디오 30분 55초부터 재생하기) Almedia 컴포넌트는 플루언트 UI를 미리 반영해 두었으므로, 바로 사용하면 된다. 예를 들어, TscStyledForm에는 FluentUIAcrylicColor, FluentUIBackground, FluentUIBorder…의 속성이 이미있다. 라이선스 가격은 US$99 이며, 업데이트가 평생 무료로 제공된다. (다른 소프트웨어와 매우 다른 경우이다.) 참고로, 발표자(Ian Barker)는 Almedia 컴포넌트와 아무 관련이 없고, 단지 좋아해서 소개하는 것일 뿐이다. 윈도우 10 테마에 사용할 수 있는 델파이 테마 델파이의 'Windows 10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 Almedia 컴포넌트는 속성과 메소드가 매우 많아서 처음에 혼란스러울 수 있다. 하지만, 일단 한번 하고 나면 훨씬 쉬울 것이고, 매우 유용한 컴포넌트임을 알 수 있을 것이다. 이와 별개로, FMX 역시 UI구현이 매우 유연하고 강력하므로 FMX만 가지고 (소스 코드를 쓰지 않고) 플루언트UI를 구현하는 것도 매우 쉬웠다. 플루언트 UI는 훨씬 더 많은 것들이 있다. 이 세션의 간단한 데모는 플루언트 UI의 핵심을 중심으로 다루었으므로 좋은 시작점이 될 것이다. 이 세션에는 없지만 모션(Motion)을 구현하려면 Animation을 사용하면 된다. // AlmediaDev 컴포넌트로 개발하는 경우에도, 윈도우 테마를 맞춰주는 코드가 필요하다 procedure TVCLCalculatorForm.FormCreate(Sender: TObject); begin MatchWindowsTheme; ... end; // 윈도우 테마를 맞춰주는 코드 // [참고] Font.Color는 clWindows로, Font.Name은 Segoe로 되어 있어야 한다. procedure TVCLCalculatorForm.MatchWindowsTheme; var GoDark: Boolean; iInt: Integer; AButton: TComponent; begin // 델파이의 'Tablet Dark' VCL 테마는 윈도우10 다크 모드에 가장 잘 맞음 // 델파이의 'Windows10' VCL 테마는 윈도우10 라이트 모드에 가장 잘 맞음 SetAppropriateThemeMode('Tablet Dark', 'Windows10'); GoDark := DarkModeIsEnabled; // 이 코드는 Carbon 테마가, 윈도우 다크 테마와 잘 맞지 않기 때문임 for iInt in cNumberButtons do begin AButton := FindComponent('scGPButton' + IntToStr(iInt)); if (AButton <> Nil) then if (AButton is TscGPButton) then if GoDark then TscGPButton(AButton).Options.NormalColor := clBackground else TscGPButton(AButton).Options.NormalColor := clWindow; end; end; procedure SetAppropriateThemeMode(const DarkModeThemeName, LightModeThemeName: string); begin SetSpecificThemeMode(DarkModeIsEnabled, DarkModeThemeName, LightModeThemeName); end; procedure SetSpecificThemeMode(const AsDarkMode: Boolean; const DarkModeThemeName, LightModeThemeName: string); var ChosenTheme: string; begin if AsDarkMode then ChosenTheme := DarkModeThemeName else ChosenTheme := LightModeThemeName; TStyleManager.TrySetStyle(ChosenTheme, False); end; 2편의 관련 자료와 링크 2편 발표 자료 및 원본 아티클 사용된 Fluent UI 구현 소스 코드 다운로드 (깃허브) 마이크로소프트 공식 플루언트 UI 사이트 잘 정리된 블로그 Almedia Dev Style Controls 한글 Wiki (Segoe UI) << UX Summit 2020 목록으로 이동 View full 엠바카데로 기술자료
  17. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Legacy desktop apps UI & UX modernization - Serge Pilko 의 한글 요약본입니다. 발표자 (Serge Pilko)는 Softacom의 창업자이자 엠바카데로 MVP이며, 오래된 델파이 시스템 마이그레이션 전문가입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (총 67분) 보기 레거시 데스크톱 앱 UI/UX 현대화를 주제로 선정한 이유 이제는 앱의 생존 조건으로 UI가 너무나 중요하기 때문에 실제로 어려움이 있기 때문에 델파이 개발자들이 도움을 필요로 하는 주제이기 때문에 회사들이 요청을 하기 때문에 목차 전형적인 상황: “15년된 데스크톱 앱이 있는데 못생겼습니다. 애플 같은 UI를 가진 앱으로 바꾸고 싶은데 어떻게 해야 하나요?” 가능한 모든 것을 쉽게 진행해야 한다. 하지만, 쉽게 하는 방법을 찾는 것이 쉽지 않다. [방향 선택] 첫번째 질문: 윈도우용 데스크톱 유지? 재설계? [기반 기술 선택] 전형적인 윈도우 데스크톱 앱? 웹 기반 데스크톱 앱? 크로스-플랫폼 앱? [구현 기술 선택] 사용할 수 있는 데스크톱 앱 개발 기술: VCL, FMX, PWA 등 [위험 관리] 마이그레이션 시 주의해야 할 함정 [절차와 시연] 발표자가 현대화 프로젝트를 수행하는 기본 절차 사전 분석 및 결정: 기존 앱을 마이그레이션? 새로 개발? 프로토타입 제작: 도구와 기술 소개 및 시연 디자인: 디자이너가 필요한가? UI와 컴포넌트 구현: 자체 개발 또는 써드 파티 컴포넌트 사용 [실제 사례 전달] 사례 1. UI 마이그레이션 프로젝트 [실제 사례 전달] 사례 2. (하이브리드, 웹, 크로스-플랫폼이 아니라) 네이티브 윈도우 데스크톱을 유지하기로 결정한 프로젝트 당신의 앱 vs 애플 스타일 앱 (비디오 7분 49초부터 보기) 애플 스타일 앱은 사용자에게는 쉽고 단순하다. 하지만, 이런 수준의 UX를 구현하려면 개발 능력 뿐만 아니라 풍부한 경험, 통찰력, 최신 트렌드와 고객에 대한 이해력까지 갖추어야 한다. 당신의 앱이 못생기고 퇴물 같은 모습이라고 느껴지는가? 당신 잘못이 아니다. 10~20년 전에는 다들 앱을 그렇게 만들었다. 10년전에 나온 자동차를 보면 지금 자동차에 비해 디자인이 훨씬 뒤떨어져 보이지 않는가? 모든 것은 계속 바뀐다! 새 표준, 새 장비, 새 기능, 시간, 새 사용자의 선호도, 유행 등 UI/UX 관련 용어 (비디오 6분 57초부터 보기) 그림1. UI 전문가가 필요한지 아니면 UX 전문가가 필요한지를 알려면 관련된 용어들이 어디에 속하는지 알아야 한다. UI 에만 해당되는 용어: 사용자 눈에 어떻게 보이는가와 관련 (스타일, 가독성, 색상 등) UX 에만 해당되는 용어: 각 사용자가 목적을 어떻게 이루는가와 관련 (화면 이동, 반응 등) UI와 UX 모두에 걸쳐진 매우 중요한 용어: 매력, 경험, 느낌 등 프로젝트를 진행할 때, UI와 UX 전문가가 따로 있는 것보다 한 사람이 모두 할 수 있으면 더 좋다고 생각한다. 10년이 훌쩍넘은 데스크톱 앱의 전형적인 상황 (비디오 8분 54초부터 보기) 델파이, 비주얼 스튜디오, 이클립스 등으로 만든 오래된 데스크톱 소프트웨어 대부분이 가지고 있는 문제 100개가 넘는 화면 서로 다른 개발자, 서로 다른 컴포넌트, 서로 다른 스타일 복잡하고 어색한 화면 이동 모든 것이 다 작게 표현된다. (고해상도 DPI 지원 안 됨) 못생긴 UI (구식 화면, 업계 표준을 못 따라간다.) 텍스트 읽기가 어렵다. 이 세션은 델파이와 C++빌더로 만든 앱들만 다룬다. 그 이유는? 네이티브 데스크톱 앱 개발 시 내가 가장 좋아하는 도구가 델파이이다. 오래된 훌륭한 앱들 중 델파이로 개발된 것들이 널리 사용되고 있다. 성능이 중요한 윈도우 데스크톱 앱을 빠르게 개발할 때, 델파이보다 좋은 도구를 아직 본 적이 없다. 앱의 UI/UX 현대화 시 “나누어” 고려할 (이 세션의 주제에 해당되는) 계층 (비디오 11분 37초부터 보기) 그림2. 현대화 프로젝트를 계획하려면, 애플리케이션의 각 계층과 그 범위를 먼저 이해하고, 세부 작업이 어느 계층에 포함되는지를 결정할 수 있어야 한다. 플랫폼: 윈도우 운영체제 아키텍처: 데스크톱 애플리케이션의 아키텍처 프레임워크와 개발 도구 :델파이 VCL 프레임워크 사용자의 상호 작용과 화면 이동 스타일과 디자인 기본 전략 선택 비용, 리스크, 최종 결과를 종합적으로 고려하여 전략을 선택하자. 32-bit VCL 앱의 UI/UX를 현대화할 때는 다음 전략 중 하나를 선택할 수 있다 델파이 버전을 유지: 색상 변경 등 UI와 UX만 현대화하고 나머지는 손대지 않기 델파이를 업그레이드 최신 VCL로 마이그레이션: 고해상도, 유니코드, 64-bit 모두 지원 최신 FMX로 마이그레이션 고해상도, 유니코드, 64-bit 모두 지원 뿐만 아니라, 필요시 맥OS와 리눅스 등 다른 플랫폼까지 지원 가능 단, FMX와 VCL은 서로 독립된 UI 프레임워크이므로, FMX에 대한 이해가 필요하다. UI를 제외하고, 기능 로직, RTL 등 나머지 코드는 재사용할 수 있다. PWA / Electron / 데스크톱 웹 웹 앱 모바일 앱 구현 방안 선택 (새 구성 vs 업데이트) 애플리케이션의 UI / UX를 현대화 할 구현 방안을 결정하자. 화면 기본 구성이 훌륭하다면, 그대로 유지하고 모양만 현대식으로 바꾸기 (이 경우, UI는 멋지게 바꿀 수 있지만, 화면 이동 등 UX에는 손대지 못한다.) 모든 폼 화면을 완전히 새로 현대화 하고 새 UX를 적용하기 메인 폼 화면만 현대화 하기 스타일만 적용하기 (주의: 스타일이 적용되지 않는 써드파티 컴포넌트들도 있다.) 컴포넌트를 업데이트하기 (예: 일반 버튼을 멋진 스타일 기반 버튼으로 업데이트) 위험 관리 리스크 발생 가능성과 실패 확률은 정비례한다는 점을 명심하자. 비즈니스 분석 단계에서 위험 관리 항목을 아래와 같이 나열하고 각 영역별 해당 요소를 적고 일일이 검토하자. 위험 관리 영역 예산 인적 자원과 역량 시간 버그 (기존 앱에는 수많은 버그를 해소한 경험이 녹아있다. 버그가 새로 만들어질 여지를 살피자.) 컴포넌트 마이그레이션 잘못된 결정 기대치 잘못된 프로젝트 일정 기술적 데드락 커뮤니케이션 리스크 병렬 개발 (기존 앱을 유지보수 하면서 고쳐간다면 코드 브랜치와 병합의 위험 고려가 필요하다.) 수행 절차(와 시연): 발표자가 현대화 프로젝트를 수행하는 기본 절차 (비디오 20분 46초부터 보기) 비즈니스 분석 와이어 프레임 작성 (생략 또는 간략 수행도 가능) 디자이너의 작업 (생략 또는 간략 수행도 가능) 구현 1. 비즈니스 분석 목표, 전략, 위험 관리 등 계획 수립 단계 (비디오 23분 01초부터 보기) 마이그레이션 전략 선택 리스크 관리 수행 네비게이션 맵 작성 (계층도, 마인드 맵 등) 
 폼이름을 서로 연결하여 현재의 계층과 흐름을 작성한 후 더 사용하기 쉬운 흐름으로 개선 
 같은 수준의 폼은 같은 모양의 글상자로 표현하여 흐름 뿐만 아니라 계층도 명확히 할 것
 (팀원들과 공유하기 좋은 도구인) Mind Meister로 시연 (이외에도 비지오 등 다른 도구 사용 가능) 브레인스토밍 도구를 활용하여, 안 쓰는 폼을 모두 찾아서 제거 개발 당시에는 분명히 필요하다고 믿었지만, 정작 개발 후에는 전혀 안쓰는 폼들이 반드시 있다. 어쩌면 많을 수도 있다. 유용한 도구: Mind Meister, 비지오, draw.io 등 컴포넌트 마이그레이션 표 작성 매우 중요하다! 각 컴포넌트가 델파이 최신 버전에서 작동하는지 미리 확인해야한다. 프로젝트 관리 절차 확정 이 시점부터는 프로젝트 관리가 중요해진다. Mind Meister를 브레인스토밍 도구로 활용하기 데모 (비디오 25분 05초부터 보기) 그림3. Mind Meister를 이용하여 기존 애플리케이션의 폼과 그 계층과 관계를 표현한 후에, 내부에 공유하고 브레인스토밍을 진행하고 향상된 구성을 새로 그릴 수 있다. 컴포넌트 마이그레이션 표 기존에 사용 중인 컴포넌트를 빠짐없이 나열하고 각 컴포넌트의 현황을 명확히 파악하기는 반드시 전략 수립 단계에서 진행해야 한다. 아래의 마이그레이션 관련 항목을 표로 정리하고 확인하자. (실제 프로젝트 중에 필요한 항목이 더 있으면 추가하도록 한다.) 컴포넌트명 최신 델파이 지원 패키지 유무 최신 델파이 지원 컴포넌트 유무 라이선스 정보, 라이선스 비용 최신 델파이 지원이 안될 경우 선택할 수 있는 대체품 대체품의 라이선스 정보 대체품의 라이선스 비용 무료 컴포넌트 여부 그림4. 컴포넌트 마이그레이션를 통해 기존에 사용 중인 컴포넌트를 철저히 분석하고 마이그레이션 방법을 찾는 것은 계획 수립 단계에 미리 진행해야 한다. 2. 와이어 프레임 작성 (생략 또는 간략 수행도 가능) 작업 범위, 변경할 영역을 내부 의견이 반영되는 단계 (비디오 30분 10초부터 보기) 20~30개 주요 화면을 선정하여 와이어 프레임을 작성
 사용자가 애플리케이션을 실제로 어떻게 사용하고, 이에 대해 앱이 어떻게 반응하는 지를 빠르게 구현한다. 기존 애플리케이션의 와이어 프레임을 먼저 만들어서 브레인스토밍을 진행하고, 새 애플리케이션의 와이어 프레임을 만드는 것도 좋다. 와이어 프레임과 프로토타입 작성 도구 HotGloo.io, inVisionApp.com, Axure RP, 비지오, 포토샵 등 다른 도구 사용 가능 내부 시연 및 의견 수렴 HotGloo.io로 와이어 프레임 작성하기 데모 (비디오 31분 20초부터 보기) HotGloo.io 델파이처럼 UI 컨트롤이 제공되며, 폼 전환, 액션 등을 넣을 수 있다. 팝업 윈도우를 만들 수도 있고, 모든 폼에 공통으로 표시되는 영역도 설정 가능
하다. 그림5. HotGloo를 활용하면 와이어 프레임이나 프로토타입을 쉽고 빠르게 작성할 수 있다. inVisionApp.com으로 와이어 프레임 작성하기 데모 (비디오 42분 15초부터 보기) inVisionApp.com 이미지 파일 안의 버튼 등의 부분에 화면 전환, 액션 연결 등 기능을 연결할 수 있다. 화면 이미지나 디자인 시안이 있을 때 활용하기 좋다. 그림6. InVision.com은 화면 이미지를 사용한다. 화면 이미지(스크린샷)을 사용하여 마치 동작을 하는 애플리케이션인 것 처럼 보이게 할 수 있어서 더 사실적인 와이어 프레임을 만들 수 있다. 3. 디자이너의 작업: 앱을 예쁘게 만들려면 필요함(생략 또는 간략 수행도 가능) 디자인 작업 절차 (비디오 49분 35초부터 보기) 15~25개 주요 폼 화면에 대한 UI와 스타일 요청 디자이너는 포토샵, 피그마 등을 사용하여 화면을 디자인한다. 디자인 검토 회의 및 승인 기존 사용자의 의견 청취가 중요하다. 브랜드북 작성 버튼 등 UI 컨트롤의 스타일, 화면 이동 규칙 등을 정의한다. 승인을 받은 화면 디자인 컨셉을 기반으로 작성한다. 브랜드북 그림7. 브랜드북은 승인을 받은 화면 디자인 컨셉을 각 요소별로 정의하고 표현한다. 4. 구현 마이그레이션 구현 절차 (비디오 51분 20초부터 보기) 컴포넌트 마이그레이션 (필요시 자체 구현) 폼 마이그레이션 (또는 구현) 소스 코드 리팩토링 UI 테스트 자동화 고려 마이그레이션 프로젝트에서 주의할 점: 현대화 시 함정 UI / UX 현대화 = 완전히 작동하는 앱 마이그레이션 = 시간과 인력 필요 마이그레이션 해야하는 컴포넌트가 델파이 최신 버전에 맞지 않거나 아예 없어졌을 수 있다. 일정 계획을 확정하기 어렵다. 단계적으로 하는 것이 좋다. 완전히 작동하는 애플리케이션으로 전환하지 못한 채 길게 지연되면 프로젝트가 중단되는 결과로 이어질 수 있다. [실제 사례 전달] 사례 1. UI 마이그레이션 프로젝트 뷰티 산업의 앱이므로 첫인상이 매우 중요했던 프로젝트 사례 (비디오 55분 09초부터 보기) 현대화 전의 상황 (UI 현대화와 재설계가 필요) 델파이 7로 개발된 데스크톱 앱 (폼 개수: 65개 이상) 비즈니스 로직이 폼 파일 안에 구현됨 (MVC 패턴이 필요) OOP 아님 (리팩토링 필요) 요즘엔 안쓰는 UI (현대화가 필요) 사용되지 않는 폼이 많고 유지 보수가 어려움 (안쓰는 폼 제거가 필요) 시장 점유율 하락 중 (브랜드 이미지 향상이 필요) 마이그레이션 프로젝트 내용 및 순서 코드 분석 기존 UI를 재사용하는 방식으로는 멋진 UI로 변경할 수가 없는 상황이었음 핵심 폼 화면은 완전히 새로운 UI로 설계하기로 결정함 네비게이션 맵 작성 (도구: Visio) 새 폼과 새 네비게이션, 새 컴포넌트를 프로토타입으로 구현, 새 검색 필드 등 향상된 새 UI가 어떻게 사용될 수 있는지를 검증 (도구: HotGloo.io) 폼 20개와 브랜드 북(Brand Book)을 디자이너가 작성 (FMX 스타일 엔진을 쓰기로 결정했으므로) FMX 애플리케이션을 하나 만듦 FMX 애플리케이션이지만 그 안에는 기존 VCL폼을 모두 추가 (VCL과 FMX는 섞어 쓰기가 가능함) 그 후 기존 VCL 폼을 대체할 새 FMX폼으로 만들어 교체하는 작업을 하나씩 진행, 완료되기 전까지는 VCL 폼이 FMX폼을 호출하거나 FMX 폼이 VCL폼을 호출하면서 작동함 요약 UX 현대화 결과 기존 20개 폼은 45개 이상으로 나누어짐 기존에는 확인, 알림 등 여러 윈도우 팝업이 일관성이 없고, 현대적인 UI가 아니라는 고객의 의견을 바탕으로 진행했다. 폼을 나누고 표준화한 결과 폼의 개수가 증가되었다. 전체 기간 11개월 풀타임은 아니지만 참여한 전문가: 프로젝트 관리자, 비즈니스 분석가, 디자이너, 델파이 FMX 고급 개발자, 델파이 FMX 중급 개발자 발주처에서는 UI 프로토타입만 가지고 영업을 시작했고 잠재 고객 세 곳을 확보할 수 있었다. [실제 사례 전달] 사례 2. 네이티브 윈도우 데스크톱을 유지하기로 결정한 프로젝트 개발 플랫폼 전환을 검토하기 위해 하이브리드, 웹, 크로스-플랫폼, 델파이 네이티브를 비교 테스트 (비디오 60분 04초부터 보기) 외부 전문가들이 고객에게 델파이를 걷어내고 다른 기술로 재구축하면 성능이 2배 이상 좋아진다 등의 설득을 하고 있었다. 현대화 전의 상황: 델파이 2006으로 개발된 데스크톱 앱 UI 요소가 풍부하고, 계산과 화면 처리 작업이 많음 처리 성능이 매우 중요한 애플리케이션 수행 내용 및 순서 고객 의견을 경청하고, 고객의 우려를 객관적으로 접근 (매우 중요했음!) 비즈니스 분석 후 분석된 현대 기술을 제안 닷넷 WPF (C#), 엘렉트론(Javascript) 벤치마크 테스트를 위해 동일한 기능을 구현하는 PoC(Proof of Concept)를 각 세 가지 기술로 구현 각 기술 (닷넷, 자바스크립트) 별 해당 외부 전문가가 코드를 검증하여 효율성과 전문성을 보증받음 요약 고객은 델파이를 유지하기로 결정 고객은 더이상 기술 선택을 고민하지 않음 (이미 객관적인 비교 결과로 검증되었기 때문) 실제 프로젝트에서는 PoC에서는 사용하지 않았던 델파이 병렬 라이브러리를 사용하여 최종 결과는 더욱 향상됨 비교 결과 UX 성능 평가 총점에서 델파이가 가장 우수: 델파이(9점) > 닷넷 WPF (7점) > Electron 자바스크립트 (6점) 순 그리드 안에 그리드가 들어가는 매우 복잡한 그리드에 1,000개 행을 표시할 때 WPF나 Electron은 가끔 엄청 느렸다. (참고, 엘렉트론과 델파이를 비교한 결과는 예전에 이미 발표한 적이 있다.) 일반 계산 능력 면에서는 어느 기술이나 별 차이가 없었다. 일반 계산 능력은 이미 일반적인 처리 기술이 되었다. UI 렌더링 면에서 델파이가 속도에서 현격하게 속도가 빨랐다. 각 기술이 독자적인 방식으로 처리하고 있었다. 닷넷과 델파이는 모두 다이렉트X 기반 렌더링을 하였으나, 속도 차이가 컸다는 점이 흥미로웠다. 그림8. 비교 결과 요약표에서 UX 성능 평가 총점과 요소 기능별 결과를 볼 수 있다. 델파이가 9점으로 가장 성능이 좋았다. 이 세션 요약 및 권장 사항 성능이 중요하다면, 네이티브 데스크톱 애플리케이션이 최고의 선택이다. 한번에 마이그레이션을 하려고 하지 말자. (지속적이고 안전하게 프로젝트를 진행하자.) FMX와 VCL을 섞어서 진행하는 것을 고려하자. (한번에 FMX로만 가는 건 위험할 수 있다.) FMX로 결정할 때는 FMX 중 무엇 때문인지 그 이유를 분명히 하자. 윈도우 전용이라면 VCL도 이미 매우 훌륭하다. 델파이 스타일(Styles)을 미리 사용해 본 후에 전체 UI / UX를 현대화 하자. 원한다면 기본 스타일에서 일부만 바꿀 수도 있으므로 알맞은 스타일을 찾아보자. 마이그레이션을 위한 마이그레이션 작업은 하지 말자. 뭔가 작업을 하고 싶다면 차라리 기능을 확장하자. 각 목적에 알맞은 도구를 사용하자. Serge Pilko의 마이그레이션 세션 더보기: Softacom의 레거시 소프트웨어 마이그레이션 전략 유튜브 << UX Summit 2020 목록으로 이동
  18. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Legacy desktop apps UI & UX modernization - Serge Pilko 의 한글 요약본입니다. 발표자 (Serge Pilko)는 Softacom의 창업자이자 엠바카데로 MVP이며, 오래된 델파이 시스템 마이그레이션 전문가입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (총 67분) 보기 레거시 데스크톱 앱 UI/UX 현대화를 주제로 선정한 이유 이제는 앱의 생존 조건으로 UI가 너무나 중요하기 때문에 실제로 어려움이 있기 때문에 델파이 개발자들이 도움을 필요로 하는 주제이기 때문에 회사들이 요청을 하기 때문에 목차 전형적인 상황: “15년된 데스크톱 앱이 있는데 못생겼습니다. 애플 같은 UI를 가진 앱으로 바꾸고 싶은데 어떻게 해야 하나요?” 가능한 모든 것을 쉽게 진행해야 한다. 하지만, 쉽게 하는 방법을 찾는 것이 쉽지 않다. [방향 선택] 첫번째 질문: 윈도우용 데스크톱 유지? 재설계? [기반 기술 선택] 전형적인 윈도우 데스크톱 앱? 웹 기반 데스크톱 앱? 크로스-플랫폼 앱? [구현 기술 선택] 사용할 수 있는 데스크톱 앱 개발 기술: VCL, FMX, PWA 등 [위험 관리] 마이그레이션 시 주의해야 할 함정 [절차와 시연] 발표자가 현대화 프로젝트를 수행하는 기본 절차 사전 분석 및 결정: 기존 앱을 마이그레이션? 새로 개발? 프로토타입 제작: 도구와 기술 소개 및 시연 디자인: 디자이너가 필요한가? UI와 컴포넌트 구현: 자체 개발 또는 써드 파티 컴포넌트 사용 [실제 사례 전달] 사례 1. UI 마이그레이션 프로젝트 [실제 사례 전달] 사례 2. (하이브리드, 웹, 크로스-플랫폼이 아니라) 네이티브 윈도우 데스크톱을 유지하기로 결정한 프로젝트 당신의 앱 vs 애플 스타일 앱 (비디오 7분 49초부터 보기) 애플 스타일 앱은 사용자에게는 쉽고 단순하다. 하지만, 이런 수준의 UX를 구현하려면 개발 능력 뿐만 아니라 풍부한 경험, 통찰력, 최신 트렌드와 고객에 대한 이해력까지 갖추어야 한다. 당신의 앱이 못생기고 퇴물 같은 모습이라고 느껴지는가? 당신 잘못이 아니다. 10~20년 전에는 다들 앱을 그렇게 만들었다. 10년전에 나온 자동차를 보면 지금 자동차에 비해 디자인이 훨씬 뒤떨어져 보이지 않는가? 모든 것은 계속 바뀐다! 새 표준, 새 장비, 새 기능, 시간, 새 사용자의 선호도, 유행 등 UI/UX 관련 용어 (비디오 6분 57초부터 보기) 그림1. UI 전문가가 필요한지 아니면 UX 전문가가 필요한지를 알려면 관련된 용어들이 어디에 속하는지 알아야 한다. UI 에만 해당되는 용어: 사용자 눈에 어떻게 보이는가와 관련 (스타일, 가독성, 색상 등) UX 에만 해당되는 용어: 각 사용자가 목적을 어떻게 이루는가와 관련 (화면 이동, 반응 등) UI와 UX 모두에 걸쳐진 매우 중요한 용어: 매력, 경험, 느낌 등 프로젝트를 진행할 때, UI와 UX 전문가가 따로 있는 것보다 한 사람이 모두 할 수 있으면 더 좋다고 생각한다. 10년이 훌쩍넘은 데스크톱 앱의 전형적인 상황 (비디오 8분 54초부터 보기) 델파이, 비주얼 스튜디오, 이클립스 등으로 만든 오래된 데스크톱 소프트웨어 대부분이 가지고 있는 문제 100개가 넘는 화면 서로 다른 개발자, 서로 다른 컴포넌트, 서로 다른 스타일 복잡하고 어색한 화면 이동 모든 것이 다 작게 표현된다. (고해상도 DPI 지원 안 됨) 못생긴 UI (구식 화면, 업계 표준을 못 따라간다.) 텍스트 읽기가 어렵다. 이 세션은 델파이와 C++빌더로 만든 앱들만 다룬다. 그 이유는? 네이티브 데스크톱 앱 개발 시 내가 가장 좋아하는 도구가 델파이이다. 오래된 훌륭한 앱들 중 델파이로 개발된 것들이 널리 사용되고 있다. 성능이 중요한 윈도우 데스크톱 앱을 빠르게 개발할 때, 델파이보다 좋은 도구를 아직 본 적이 없다. 앱의 UI/UX 현대화 시 “나누어” 고려할 (이 세션의 주제에 해당되는) 계층 (비디오 11분 37초부터 보기) 그림2. 현대화 프로젝트를 계획하려면, 애플리케이션의 각 계층과 그 범위를 먼저 이해하고, 세부 작업이 어느 계층에 포함되는지를 결정할 수 있어야 한다. 플랫폼: 윈도우 운영체제 아키텍처: 데스크톱 애플리케이션의 아키텍처 프레임워크와 개발 도구 :델파이 VCL 프레임워크 사용자의 상호 작용과 화면 이동 스타일과 디자인 기본 전략 선택 비용, 리스크, 최종 결과를 종합적으로 고려하여 전략을 선택하자. 32-bit VCL 앱의 UI/UX를 현대화할 때는 다음 전략 중 하나를 선택할 수 있다 델파이 버전을 유지: 색상 변경 등 UI와 UX만 현대화하고 나머지는 손대지 않기 델파이를 업그레이드 최신 VCL로 마이그레이션: 고해상도, 유니코드, 64-bit 모두 지원 최신 FMX로 마이그레이션 고해상도, 유니코드, 64-bit 모두 지원 뿐만 아니라, 필요시 맥OS와 리눅스 등 다른 플랫폼까지 지원 가능 단, FMX와 VCL은 서로 독립된 UI 프레임워크이므로, FMX에 대한 이해가 필요하다. UI를 제외하고, 기능 로직, RTL 등 나머지 코드는 재사용할 수 있다. PWA / Electron / 데스크톱 웹 웹 앱 모바일 앱 구현 방안 선택 (새 구성 vs 업데이트) 애플리케이션의 UI / UX를 현대화 할 구현 방안을 결정하자. 화면 기본 구성이 훌륭하다면, 그대로 유지하고 모양만 현대식으로 바꾸기 (이 경우, UI는 멋지게 바꿀 수 있지만, 화면 이동 등 UX에는 손대지 못한다.) 모든 폼 화면을 완전히 새로 현대화 하고 새 UX를 적용하기 메인 폼 화면만 현대화 하기 스타일만 적용하기 (주의: 스타일이 적용되지 않는 써드파티 컴포넌트들도 있다.) 컴포넌트를 업데이트하기 (예: 일반 버튼을 멋진 스타일 기반 버튼으로 업데이트) 위험 관리 리스크 발생 가능성과 실패 확률은 정비례한다는 점을 명심하자. 비즈니스 분석 단계에서 위험 관리 항목을 아래와 같이 나열하고 각 영역별 해당 요소를 적고 일일이 검토하자. 위험 관리 영역 예산 인적 자원과 역량 시간 버그 (기존 앱에는 수많은 버그를 해소한 경험이 녹아있다. 버그가 새로 만들어질 여지를 살피자.) 컴포넌트 마이그레이션 잘못된 결정 기대치 잘못된 프로젝트 일정 기술적 데드락 커뮤니케이션 리스크 병렬 개발 (기존 앱을 유지보수 하면서 고쳐간다면 코드 브랜치와 병합의 위험 고려가 필요하다.) 수행 절차(와 시연): 발표자가 현대화 프로젝트를 수행하는 기본 절차 (비디오 20분 46초부터 보기) 비즈니스 분석 와이어 프레임 작성 (생략 또는 간략 수행도 가능) 디자이너의 작업 (생략 또는 간략 수행도 가능) 구현 1. 비즈니스 분석 목표, 전략, 위험 관리 등 계획 수립 단계 (비디오 23분 01초부터 보기) 마이그레이션 전략 선택 리스크 관리 수행 네비게이션 맵 작성 (계층도, 마인드 맵 등) 
 폼이름을 서로 연결하여 현재의 계층과 흐름을 작성한 후 더 사용하기 쉬운 흐름으로 개선 
 같은 수준의 폼은 같은 모양의 글상자로 표현하여 흐름 뿐만 아니라 계층도 명확히 할 것
 (팀원들과 공유하기 좋은 도구인) Mind Meister로 시연 (이외에도 비지오 등 다른 도구 사용 가능) 브레인스토밍 도구를 활용하여, 안 쓰는 폼을 모두 찾아서 제거 개발 당시에는 분명히 필요하다고 믿었지만, 정작 개발 후에는 전혀 안쓰는 폼들이 반드시 있다. 어쩌면 많을 수도 있다. 유용한 도구: Mind Meister, 비지오, draw.io 등 컴포넌트 마이그레이션 표 작성 매우 중요하다! 각 컴포넌트가 델파이 최신 버전에서 작동하는지 미리 확인해야한다. 프로젝트 관리 절차 확정 이 시점부터는 프로젝트 관리가 중요해진다. Mind Meister를 브레인스토밍 도구로 활용하기 데모 (비디오 25분 05초부터 보기) 그림3. Mind Meister를 이용하여 기존 애플리케이션의 폼과 그 계층과 관계를 표현한 후에, 내부에 공유하고 브레인스토밍을 진행하고 향상된 구성을 새로 그릴 수 있다. 컴포넌트 마이그레이션 표 기존에 사용 중인 컴포넌트를 빠짐없이 나열하고 각 컴포넌트의 현황을 명확히 파악하기는 반드시 전략 수립 단계에서 진행해야 한다. 아래의 마이그레이션 관련 항목을 표로 정리하고 확인하자. (실제 프로젝트 중에 필요한 항목이 더 있으면 추가하도록 한다.) 컴포넌트명 최신 델파이 지원 패키지 유무 최신 델파이 지원 컴포넌트 유무 라이선스 정보, 라이선스 비용 최신 델파이 지원이 안될 경우 선택할 수 있는 대체품 대체품의 라이선스 정보 대체품의 라이선스 비용 무료 컴포넌트 여부 그림4. 컴포넌트 마이그레이션를 통해 기존에 사용 중인 컴포넌트를 철저히 분석하고 마이그레이션 방법을 찾는 것은 계획 수립 단계에 미리 진행해야 한다. 2. 와이어 프레임 작성 (생략 또는 간략 수행도 가능) 작업 범위, 변경할 영역을 내부 의견이 반영되는 단계 (비디오 30분 10초부터 보기) 20~30개 주요 화면을 선정하여 와이어 프레임을 작성
 사용자가 애플리케이션을 실제로 어떻게 사용하고, 이에 대해 앱이 어떻게 반응하는 지를 빠르게 구현한다. 기존 애플리케이션의 와이어 프레임을 먼저 만들어서 브레인스토밍을 진행하고, 새 애플리케이션의 와이어 프레임을 만드는 것도 좋다. 와이어 프레임과 프로토타입 작성 도구 HotGloo.io, inVisionApp.com, Axure RP, 비지오, 포토샵 등 다른 도구 사용 가능 내부 시연 및 의견 수렴 HotGloo.io로 와이어 프레임 작성하기 데모 (비디오 31분 20초부터 보기) HotGloo.io 델파이처럼 UI 컨트롤이 제공되며, 폼 전환, 액션 등을 넣을 수 있다. 팝업 윈도우를 만들 수도 있고, 모든 폼에 공통으로 표시되는 영역도 설정 가능
하다. 그림5. HotGloo를 활용하면 와이어 프레임이나 프로토타입을 쉽고 빠르게 작성할 수 있다. inVisionApp.com으로 와이어 프레임 작성하기 데모 (비디오 42분 15초부터 보기) inVisionApp.com 이미지 파일 안의 버튼 등의 부분에 화면 전환, 액션 연결 등 기능을 연결할 수 있다. 화면 이미지나 디자인 시안이 있을 때 활용하기 좋다. 그림6. InVision.com은 화면 이미지를 사용한다. 화면 이미지(스크린샷)을 사용하여 마치 동작을 하는 애플리케이션인 것 처럼 보이게 할 수 있어서 더 사실적인 와이어 프레임을 만들 수 있다. 3. 디자이너의 작업: 앱을 예쁘게 만들려면 필요함(생략 또는 간략 수행도 가능) 디자인 작업 절차 (비디오 49분 35초부터 보기) 15~25개 주요 폼 화면에 대한 UI와 스타일 요청 디자이너는 포토샵, 피그마 등을 사용하여 화면을 디자인한다. 디자인 검토 회의 및 승인 기존 사용자의 의견 청취가 중요하다. 브랜드북 작성 버튼 등 UI 컨트롤의 스타일, 화면 이동 규칙 등을 정의한다. 승인을 받은 화면 디자인 컨셉을 기반으로 작성한다. 브랜드북 그림7. 브랜드북은 승인을 받은 화면 디자인 컨셉을 각 요소별로 정의하고 표현한다. 4. 구현 마이그레이션 구현 절차 (비디오 51분 20초부터 보기) 컴포넌트 마이그레이션 (필요시 자체 구현) 폼 마이그레이션 (또는 구현) 소스 코드 리팩토링 UI 테스트 자동화 고려 마이그레이션 프로젝트에서 주의할 점: 현대화 시 함정 UI / UX 현대화 = 완전히 작동하는 앱 마이그레이션 = 시간과 인력 필요 마이그레이션 해야하는 컴포넌트가 델파이 최신 버전에 맞지 않거나 아예 없어졌을 수 있다. 일정 계획을 확정하기 어렵다. 단계적으로 하는 것이 좋다. 완전히 작동하는 애플리케이션으로 전환하지 못한 채 길게 지연되면 프로젝트가 중단되는 결과로 이어질 수 있다. [실제 사례 전달] 사례 1. UI 마이그레이션 프로젝트 뷰티 산업의 앱이므로 첫인상이 매우 중요했던 프로젝트 사례 (비디오 55분 09초부터 보기) 현대화 전의 상황 (UI 현대화와 재설계가 필요) 델파이 7로 개발된 데스크톱 앱 (폼 개수: 65개 이상) 비즈니스 로직이 폼 파일 안에 구현됨 (MVC 패턴이 필요) OOP 아님 (리팩토링 필요) 요즘엔 안쓰는 UI (현대화가 필요) 사용되지 않는 폼이 많고 유지 보수가 어려움 (안쓰는 폼 제거가 필요) 시장 점유율 하락 중 (브랜드 이미지 향상이 필요) 마이그레이션 프로젝트 내용 및 순서 코드 분석 기존 UI를 재사용하는 방식으로는 멋진 UI로 변경할 수가 없는 상황이었음 핵심 폼 화면은 완전히 새로운 UI로 설계하기로 결정함 네비게이션 맵 작성 (도구: Visio) 새 폼과 새 네비게이션, 새 컴포넌트를 프로토타입으로 구현, 새 검색 필드 등 향상된 새 UI가 어떻게 사용될 수 있는지를 검증 (도구: HotGloo.io) 폼 20개와 브랜드 북(Brand Book)을 디자이너가 작성 (FMX 스타일 엔진을 쓰기로 결정했으므로) FMX 애플리케이션을 하나 만듦 FMX 애플리케이션이지만 그 안에는 기존 VCL폼을 모두 추가 (VCL과 FMX는 섞어 쓰기가 가능함) 그 후 기존 VCL 폼을 대체할 새 FMX폼으로 만들어 교체하는 작업을 하나씩 진행, 완료되기 전까지는 VCL 폼이 FMX폼을 호출하거나 FMX 폼이 VCL폼을 호출하면서 작동함 요약 UX 현대화 결과 기존 20개 폼은 45개 이상으로 나누어짐 기존에는 확인, 알림 등 여러 윈도우 팝업이 일관성이 없고, 현대적인 UI가 아니라는 고객의 의견을 바탕으로 진행했다. 폼을 나누고 표준화한 결과 폼의 개수가 증가되었다. 전체 기간 11개월 풀타임은 아니지만 참여한 전문가: 프로젝트 관리자, 비즈니스 분석가, 디자이너, 델파이 FMX 고급 개발자, 델파이 FMX 중급 개발자 발주처에서는 UI 프로토타입만 가지고 영업을 시작했고 잠재 고객 세 곳을 확보할 수 있었다. [실제 사례 전달] 사례 2. 네이티브 윈도우 데스크톱을 유지하기로 결정한 프로젝트 개발 플랫폼 전환을 검토하기 위해 하이브리드, 웹, 크로스-플랫폼, 델파이 네이티브를 비교 테스트 (비디오 60분 04초부터 보기) 외부 전문가들이 고객에게 델파이를 걷어내고 다른 기술로 재구축하면 성능이 2배 이상 좋아진다 등의 설득을 하고 있었다. 현대화 전의 상황: 델파이 2006으로 개발된 데스크톱 앱 UI 요소가 풍부하고, 계산과 화면 처리 작업이 많음 처리 성능이 매우 중요한 애플리케이션 수행 내용 및 순서 고객 의견을 경청하고, 고객의 우려를 객관적으로 접근 (매우 중요했음!) 비즈니스 분석 후 분석된 현대 기술을 제안 닷넷 WPF (C#), 엘렉트론(Javascript) 벤치마크 테스트를 위해 동일한 기능을 구현하는 PoC(Proof of Concept)를 각 세 가지 기술로 구현 각 기술 (닷넷, 자바스크립트) 별 해당 외부 전문가가 코드를 검증하여 효율성과 전문성을 보증받음 요약 고객은 델파이를 유지하기로 결정 고객은 더이상 기술 선택을 고민하지 않음 (이미 객관적인 비교 결과로 검증되었기 때문) 실제 프로젝트에서는 PoC에서는 사용하지 않았던 델파이 병렬 라이브러리를 사용하여 최종 결과는 더욱 향상됨 비교 결과 UX 성능 평가 총점에서 델파이가 가장 우수: 델파이(9점) > 닷넷 WPF (7점) > Electron 자바스크립트 (6점) 순 그리드 안에 그리드가 들어가는 매우 복잡한 그리드에 1,000개 행을 표시할 때 WPF나 Electron은 가끔 엄청 느렸다. (참고, 엘렉트론과 델파이를 비교한 결과는 예전에 이미 발표한 적이 있다.) 일반 계산 능력 면에서는 어느 기술이나 별 차이가 없었다. 일반 계산 능력은 이미 일반적인 처리 기술이 되었다. UI 렌더링 면에서 델파이가 속도에서 현격하게 속도가 빨랐다. 각 기술이 독자적인 방식으로 처리하고 있었다. 닷넷과 델파이는 모두 다이렉트X 기반 렌더링을 하였으나, 속도 차이가 컸다는 점이 흥미로웠다. 그림8. 비교 결과 요약표에서 UX 성능 평가 총점과 요소 기능별 결과를 볼 수 있다. 델파이가 9점으로 가장 성능이 좋았다. 이 세션 요약 및 권장 사항 성능이 중요하다면, 네이티브 데스크톱 애플리케이션이 최고의 선택이다. 한번에 마이그레이션을 하려고 하지 말자. (지속적이고 안전하게 프로젝트를 진행하자.) FMX와 VCL을 섞어서 진행하는 것을 고려하자. (한번에 FMX로만 가는 건 위험할 수 있다.) FMX로 결정할 때는 FMX 중 무엇 때문인지 그 이유를 분명히 하자. 윈도우 전용이라면 VCL도 이미 매우 훌륭하다. 델파이 스타일(Styles)을 미리 사용해 본 후에 전체 UI / UX를 현대화 하자. 원한다면 기본 스타일에서 일부만 바꿀 수도 있으므로 알맞은 스타일을 찾아보자. 마이그레이션을 위한 마이그레이션 작업은 하지 말자. 뭔가 작업을 하고 싶다면 차라리 기능을 확장하자. 각 목적에 알맞은 도구를 사용하자. Serge Pilko의 마이그레이션 세션 더보기: Softacom의 레거시 소프트웨어 마이그레이션 전략 유튜브 << UX Summit 2020 목록으로 이동 View full 아티클
  19. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Strategies for building and optimizing the desktop UX - Mary Kelly 의 한글 요약본입니다. 발표자 (Mary Kelly)는, 다양한 분야에서 프로젝트 경험이 많은 엠바카데로 컨설턴트입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (13 min) 보기 델파이 마이그레이션 요구사항 Top 5와 해당 팁을 설명한 세션도 개발자가 좋아했습니다. 이 세션에서는 업무용 데스크톱을 위한 UX 구축 전략을 위한 수립 절차, 방법, 기본틀, 진행 팁을 공유합니다. 이 비디오는 슬라이드 10장과 구두 설명으로 진행되었습니다. 요약본이지만 발표자가 한 말을 가급적 많이 담고자 했습니다. UX 디자인과 UX 전략 UX (사용자 경험, User eXperience) 디자인이란, 사용자가 제품(소프트웨어)을 이용할 때 나타내는 행동(감정, 사용 패턴 등)을 사용성과 유용성을 통해서 통합하는 과정이다. UX 디자인 전략이란, UX 디자인을 위한 계획이다. 기술적 노하우, 비즈니스 전략, 고객의 니즈, 사용자가 어떻게 사용하면 좋을지에 대한 아이디어 등이 반영된다. UI 디자인 자체 보다 더 큰 그림이다. 최고의 사용자 경험 제공이라는 목표를 달성하기 위한 디자인 과정을 정하는 로드맵이다. 끝없는 반복 작업이다. (사용자들의 변화하는 니즈가 지속적으로 반영되도록 함께 변화한다.) UI 디자인을 대하는 관점과 자세이다. 무엇을 개발하든 올바른 UX 전략을 가지고 있으면, 사용자와의 관계가 향상되고, 개발된 제품이 널리 알려지고, 매출이 증가하는데 크게 도움이 된다. UX 전략 수립 전 사전 고려 사항 UX 전략 수립을 하기에 앞서, 목표하는 시장과 고객을 이해하고 있고 폭넓고 충분한 연구를 선행하였는지를 점검할 필요가 있다. 예를 들어, 다음 질문에 대해 어렵지 않게 답변할 수 있는지 생각해보자. 핵심 고객은 누구인가? 경쟁자는 누구인가? 만들고자 하는 애플리케이션은 정확히 누구를 위한 것인가? (목표 대상이 없는 전략은 효과가 약하다.) 어떤 사용자 경험을 제공할 것인가? 당신이 생각하는 사용자 경험을 제공하고 있는 경쟁자가 있는가? (유사한 소프트웨어가 이미 시장에 있는가?) 사용자 경험을 보다 향상시키기 위해 무엇을 할 수 있는가? 이 6가지 질문을 활용하자. (답변을 작성하는 과정을 통해, 시장에서 우리는 어떤 위치에 있는지 그리고 우리가 목표로 하는 사용자들은 무엇을 중요하게 생각하는지를 이해하게 될 것이다.) 우리가 만들고자 하는 소프트웨어는 무엇을 하기 위한 것인가? 우리의 핵심 고객은 누구인가? 우리의 사업 목표는 무엇인가? 우리의 사업 목표가 우리 제품 사용자의 목표를 지원하는가? 우리 개발자와 디자이너는 무슨 도구를 사용하여 제품을 만드는가? 경쟁사의 UX 디자인 전략으로 성공한 것은 무엇인가? 데스크톱 UX와 관련된 현 상황에 대한 고찰 UX 전략에 영향을 미칠 수 있는 요소들을 살펴보았다. (데스크톱 뿐만 아니라 모바일에서도 적용될 수 있다.) 현 시장에서 데스크톱의 위치 (증가하는 분야와 이유) 비즈니스는 여전히 데스크톱에서 시작된다. 모바일만큼 급격한 확장은 없지만 비즈니스에서는 여전히 중심이고 판매도 증가하고 있다. (주변 장비 등 좋은 하드웨어가 향상되는 것에 맞추어) 노트북과 데스크톱 판매 역시 지속적 증가 추세이다. 터치스크린 보급이 커지고 있다. (뒤집어서 사용할 수 있는 노트북, 태블릿 등) 모바일 위주 추세에 밀려, 수준 높은 데스크톱 애플리케이션이 많이 줄어들고 있다. 하지만, 업무 생산성 분야, 기업용 프로그램, 게임 등에서는 데스크톱 애플리케이션이 확장되고 있다. 더 창의적이고 생산적인 활동에 있어서, 사용자는 과업 수행을 신속하게 할 수 있게 하는 애플리케이션을 선호한다. 클라우드 일반 데스크톱 애플리케이션 세상은 클라우드 기반으로 크게 바뀌었다. 하지만, 클라우드 사용자는 주로 모바일보다는 일반 컴퓨터를 사용한다. 컴퓨터에서 일반 웹브라우저를 사용하거나, 웹 기술을 활용하는 클라우드 네이티브 애플리케이션을 사용한다. 수준 높은 네이티브 클라우드 애플리케이션은 더 높은 가치를 제공한다. (안전한 환경이라면) 기존 클라우드 서비스를 네이티브 앱에 연결하여 사용한다. 그 결과, 이동성이 중요해졌다. 즉 여러 플랫폼을 넘나들면서 사용하고자 하고, 다른 장비에서도 사용할 수 있기를 바란다. 품질 기대 수준 많은 기대가 있지만, 여전히 가장 중요한 핵심은 “잘 작동하는가?”이다. 그렇지 않으면 외면받는다. 배포 전, 사용자 테스트가 더 중요해 졌다. 요즘 사용자는, 원하는 기능을 잘 수행하고, 사용하기 쉽고, 딱 보기에도 정말 좋은 소프트웨어를 원한다. 품질이 낮으면 사용하지 않는다. 언제나 신나는 소프트웨어를 찾아다닌다. 사용자의 기본 요구사항 실현이 중요하다. 기본 요구사항 신뢰성(reliable), 안정성(stable), 사용편의성(easy to use / easy to download), 신뢰받는 브랜드 제품일 것 소프트웨어에서 UX 관련 표준이 기하급수적으로 늘어났다. 이제 UX의 비중은 매우 크다 . 정해진 방법론과 절차를 지키면서 개발해야 표준이 지속적으로 향상될 수 있다. UX 전략의 기본틀 명확하게 정의해야 한다. 애플리케이션 최초 디자인 작업이나 웹사이트나 앱 재디자인 작업 모두 복잡한 작업이고, 많은 생각이 필요하다. 그럴수록 더욱 명확히 정의해야 한다. 올바른 접근이 중요하다. 그렇지 않으면 프로젝트는 뒤집히거나, 필요 없는 기능을 구현하느라 디자인과 개발 시간이 늘어난다. 기반이 작업 중요하다. 이것이 잘되어야 계획 초안이 견고해진다. (비즈니스 목표와 사용자 니즈 모두를 충족하는 솔루션을 설계의 중심에 둘 것) 전략을 정의하고, 목표를 분명히 한다. (각 목표가 구체적일수록 실현 가능성은 높아진다.) 우리의 UX 디자인은 누구를 위한 것인가? (목표 고객을 분명히 하자.) 어떤 방법으로 UX 디자인 할 것인가? 왜 그 방법을 택했는가? 실현하고자 하는 것이 무엇인가? 그리고 실현 여부를 어떻게 평가할 것인가? 프로젝트 시작과 완료 시점은? 프로젝트의 각 단계별 주요 작업이 무엇이고, 각 완료와 성공 여부를 평가할 시점은? UI 보다는 기능을 중요시한다. UI는 사용자들이 애플리케이션을 눈으로 보면서 사용하는데 큰 역할을 한다. 하지만, 디자인을 시작하기에 앞서 우리는 사용자들이 필요로 하는 것이 무엇인지를 이해해야하고, 그것을 기능과 흐름에 반영해야 한다. 광고한 기능이 안되거나 버그가 많아서 제대로 작동하지 않으면 아무리 겉모습이 멋지고 매력적이라도 금새 잊혀진다. 사용자를 잡으려면, 사용자들이 기능을 사용하도록 해야 한다. 프로젝트를 시작하기 전에 누가, 무엇을, 왜 하는지를 정의하면 설계 또는 재설계 중에 부딪히는 문제를 어떻게 해결할 지를 이해하는데 도움이 된다. 각 요소를 정렬하고 프로젝트 팀원 모두가 설계 절차에 맞추도록 하면, 진행 중 애매모호한 커뮤니케이션을 방지할 수 있고, 뒤의 단계에서 크게 또는 예상치 못하게 변경 작업을 해야 할 가능성이 낮아진다. 문제점을 빠르게 진단하고, 계획이 더 견고하고 명확해지도록 하는 알맞은 해법을 빠르게 찾자. 열린 대화를 사용자들과 더 많이 하자. (최고의 결과를 만들고, 프로젝트 성공 확률이 높아진다.) 애플리케이션 디자인의 핵심은 안에 들어있는 내용들이다. 화면 요소가 올바른 위치에 있도록 하자. 그래야 최상의 사용성과 접근성을 실현할 수 있고 업계 표준과 회사의 가이드라인을 맞출 수 있다. 이제 시각적 디자인을 시작하자. 디자이너들은 사용자를 연구한 결과와 비즈니스 가이드라인에 기반하여 스타일 가이드, UI 패턴, 표준 템플릿을 만든다. 애플리케이션 디자인의 핵심 목표는 사용자 경험이 최고가 되도록 하는 것이다. 사용자 테스트가 중요하다. 디자인 전략이 좋고 잘 반영됐는지를 알 수 있는 유일한 방법은 사용자 테스트를 통해 많은 의견을 모으는 것이다. UX 전략을 유연하고 지속적으로 업데이트한다. (그래야 변하는 고객의 요구사항을 흔들림없이 충족할 수 있다.) 사용자의 니즈와 기대는 늘 변한다. (지금 최첨단이라도 몇년 후면 구식이 된다.) UX 전략에는 UX 테스트가 포함되도록 처음부터 고려하자. 그러면, UX 전략은 훨씬 더 많은 상황에서 활용가능하다. 완성된 애플리케이션을 향후에 완전히 새로 디자인해야하는 상황이 줄어든다. UX 전략 구축 및 최적화 팁 어떤 플랫폼에서든 지금까지 경험한 최고의 애플리케이션과 최악의 애플리케이션을 참고하자. 내 애플리케이션 중에서 가장 뛰어난 것을 골라서 핵심 요소를 반영하자. 뛰어난 UX를 제공하여 비즈니스 목적을 달성하고 사용자들에게 도움이 된 앱이 있다면, 그 앱이 특별했던 이유를 파악하고, 그 UX의 특징을 당신 회사의 UX 전략에 반영하자. 그러면, 집중할 영역이 좁혀지고 성공적인 UX 계획에 좀 더 가까워진다. 경쟁 애플리케이션 중에서 뛰어난 것들만 몇개 추려서 목록을 추리고 특징을 담아내자. 시중에는 수천가지 데스크톱 애플리케이션이 있다. 즉, 우리가 개발하는 새 앱에 영향을 끼칠 수 있는 것들이 그만큼 많다. 추려진 목록에서 몇가지 핵심 특징을 취하여 당신의 UX 전략에 담을 수 있을 것이다. 더 오래 사용할 수 있도록 데스크톱 애플리케이션을 디자인하자. 사용자들은 시간이 오래 걸리는 작업일수록 데스크톱 애플리케이션을 더 선호하는 경향이 있다. 사용자가 편하게 느끼는 것이 중요하다. 그래야 긴 시간동안 사용할 수 있다. 다크 모드와 라이트 모드를 선택할 수 있도록 하거나, 애플리케이션의 글자 크기를 알맞게 바꿀 수 있도록 하는 등 그 무엇이든 사용자가 편하게 느끼는 UX를 제공하자. UX 전략에 사용자 테스트가 들어 있으면 좋다. 애플리케이션의 약점과 강점을 개발 진행 과정에 미리 파악할 수 있다. 알맞은 평가표를 갖춘 테스트를 준비한 후, 정기적인 테스트 일정을 정하고 지키는 것이 좋다. 당신의 비즈니스에 집중하여 앱의 약점을 강점으로 바꾸고 UX를 최적화할 수 있다. 애플리케이션 개선을 반복하자. 사용자들이 언제나 충분히 지원받을 수 있도록 하기 위해서는 애플리케이션을 끊임없이 업데이트 해야한다. UX를 중요하게 여기는 회사에서는 앱이 일정 수준의 UX에 도달하는지를 확인하기 때문에 피드백 수집이 매우 중요하다. 사용자의 피드백 수집 방식은 다양하다: 고객과의 통화, 사용자 설문조사 SNS, 제품 소개 비디오 등 애플리케이션을 출시한 후에도 소프트웨어 요구사항으로 인해서 변경을 해야 하는 경우가 종종 있다. 원인: 원하는 수준이 안되거나, 사용자 니즈가 더 높아졌거나, 하드웨어 또는 기타 소트프웨어를 지원해야 하는 상황 등이 발생할 수 있다. 결과: 애플리케이션 변경, 새 기능 추가, 그에 따른 버그 리포트가 발생한다. 유연하면서 적응성이 좋은 계획을 유지하자. 언제든 사용자 분석 연구로 되돌아가서, 어떤 점을 향상할 수 있는지를 빠르게 찾도록 하자. 핵심 요약 UX는 UI보다 훨씬 큰 개념이다. UX는 사용자가 애플리케이션을 사용하면서 경험하는 모든 것을 의미한다. UX 전략을 수립하려면 “우선순위” 문제에 답할 수 있어야 한다. 디자인과 개발 중심을 어디에 집중할 지를 결정할 때, 가장 큰 영향을 끼치는 요소에 대해 높은 수준의 관점에서 결정하고 리소스를 할당하고 방향을 제시할 수 있어야 한다. 질문과 답변을 충분히 하자. (앞에 나온 목표와 질문들이 도움이 된다.) 여러 선택지를 펼쳐놓고 선택할 수 있다. 틀에 박힌 생각에서 벗어나고, “이럴 수 있다면 어떨까?(What-If)” 질문 할 수 있다. 내가 지금 무엇을 하고 있는지, 결국 무엇을 하게 되는지에 대한 명확한 이미지를 가질 수 있다. UX의 최종 목표는 결국 고객 만족이다. << UX Summit 2020 목록으로 이동
  20. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Strategies for building and optimizing the desktop UX - Mary Kelly 의 한글 요약본입니다. 발표자 (Mary Kelly)는, 다양한 분야에서 프로젝트 경험이 많은 엠바카데로 컨설턴트입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (13 min) 보기 델파이 마이그레이션 요구사항 Top 5와 해당 팁을 설명한 세션도 개발자가 좋아했습니다. 이 세션에서는 업무용 데스크톱을 위한 UX 구축 전략을 위한 수립 절차, 방법, 기본틀, 진행 팁을 공유합니다. 이 비디오는 슬라이드 10장과 구두 설명으로 진행되었습니다. 요약본이지만 발표자가 한 말을 가급적 많이 담고자 했습니다. UX 디자인과 UX 전략 UX (사용자 경험, User eXperience) 디자인이란, 사용자가 제품(소프트웨어)을 이용할 때 나타내는 행동(감정, 사용 패턴 등)을 사용성과 유용성을 통해서 통합하는 과정이다. UX 디자인 전략이란, UX 디자인을 위한 계획이다. 기술적 노하우, 비즈니스 전략, 고객의 니즈, 사용자가 어떻게 사용하면 좋을지에 대한 아이디어 등이 반영된다. UI 디자인 자체 보다 더 큰 그림이다. 최고의 사용자 경험 제공이라는 목표를 달성하기 위한 디자인 과정을 정하는 로드맵이다. 끝없는 반복 작업이다. (사용자들의 변화하는 니즈가 지속적으로 반영되도록 함께 변화한다.) UI 디자인을 대하는 관점과 자세이다. 무엇을 개발하든 올바른 UX 전략을 가지고 있으면, 사용자와의 관계가 향상되고, 개발된 제품이 널리 알려지고, 매출이 증가하는데 크게 도움이 된다. UX 전략 수립 전 사전 고려 사항 UX 전략 수립을 하기에 앞서, 목표하는 시장과 고객을 이해하고 있고 폭넓고 충분한 연구를 선행하였는지를 점검할 필요가 있다. 예를 들어, 다음 질문에 대해 어렵지 않게 답변할 수 있는지 생각해보자. 핵심 고객은 누구인가? 경쟁자는 누구인가? 만들고자 하는 애플리케이션은 정확히 누구를 위한 것인가? (목표 대상이 없는 전략은 효과가 약하다.) 어떤 사용자 경험을 제공할 것인가? 당신이 생각하는 사용자 경험을 제공하고 있는 경쟁자가 있는가? (유사한 소프트웨어가 이미 시장에 있는가?) 사용자 경험을 보다 향상시키기 위해 무엇을 할 수 있는가? 이 6가지 질문을 활용하자. (답변을 작성하는 과정을 통해, 시장에서 우리는 어떤 위치에 있는지 그리고 우리가 목표로 하는 사용자들은 무엇을 중요하게 생각하는지를 이해하게 될 것이다.) 우리가 만들고자 하는 소프트웨어는 무엇을 하기 위한 것인가? 우리의 핵심 고객은 누구인가? 우리의 사업 목표는 무엇인가? 우리의 사업 목표가 우리 제품 사용자의 목표를 지원하는가? 우리 개발자와 디자이너는 무슨 도구를 사용하여 제품을 만드는가? 경쟁사의 UX 디자인 전략으로 성공한 것은 무엇인가? 데스크톱 UX와 관련된 현 상황에 대한 고찰 UX 전략에 영향을 미칠 수 있는 요소들을 살펴보았다. (데스크톱 뿐만 아니라 모바일에서도 적용될 수 있다.) 현 시장에서 데스크톱의 위치 (증가하는 분야와 이유) 비즈니스는 여전히 데스크톱에서 시작된다. 모바일만큼 급격한 확장은 없지만 비즈니스에서는 여전히 중심이고 판매도 증가하고 있다. (주변 장비 등 좋은 하드웨어가 향상되는 것에 맞추어) 노트북과 데스크톱 판매 역시 지속적 증가 추세이다. 터치스크린 보급이 커지고 있다. (뒤집어서 사용할 수 있는 노트북, 태블릿 등) 모바일 위주 추세에 밀려, 수준 높은 데스크톱 애플리케이션이 많이 줄어들고 있다. 하지만, 업무 생산성 분야, 기업용 프로그램, 게임 등에서는 데스크톱 애플리케이션이 확장되고 있다. 더 창의적이고 생산적인 활동에 있어서, 사용자는 과업 수행을 신속하게 할 수 있게 하는 애플리케이션을 선호한다. 클라우드 일반 데스크톱 애플리케이션 세상은 클라우드 기반으로 크게 바뀌었다. 하지만, 클라우드 사용자는 주로 모바일보다는 일반 컴퓨터를 사용한다. 컴퓨터에서 일반 웹브라우저를 사용하거나, 웹 기술을 활용하는 클라우드 네이티브 애플리케이션을 사용한다. 수준 높은 네이티브 클라우드 애플리케이션은 더 높은 가치를 제공한다. (안전한 환경이라면) 기존 클라우드 서비스를 네이티브 앱에 연결하여 사용한다. 그 결과, 이동성이 중요해졌다. 즉 여러 플랫폼을 넘나들면서 사용하고자 하고, 다른 장비에서도 사용할 수 있기를 바란다. 품질 기대 수준 많은 기대가 있지만, 여전히 가장 중요한 핵심은 “잘 작동하는가?”이다. 그렇지 않으면 외면받는다. 배포 전, 사용자 테스트가 더 중요해 졌다. 요즘 사용자는, 원하는 기능을 잘 수행하고, 사용하기 쉽고, 딱 보기에도 정말 좋은 소프트웨어를 원한다. 품질이 낮으면 사용하지 않는다. 언제나 신나는 소프트웨어를 찾아다닌다. 사용자의 기본 요구사항 실현이 중요하다. 기본 요구사항 신뢰성(reliable), 안정성(stable), 사용편의성(easy to use / easy to download), 신뢰받는 브랜드 제품일 것 소프트웨어에서 UX 관련 표준이 기하급수적으로 늘어났다. 이제 UX의 비중은 매우 크다 . 정해진 방법론과 절차를 지키면서 개발해야 표준이 지속적으로 향상될 수 있다. UX 전략의 기본틀 명확하게 정의해야 한다. 애플리케이션 최초 디자인 작업이나 웹사이트나 앱 재디자인 작업 모두 복잡한 작업이고, 많은 생각이 필요하다. 그럴수록 더욱 명확히 정의해야 한다. 올바른 접근이 중요하다. 그렇지 않으면 프로젝트는 뒤집히거나, 필요 없는 기능을 구현하느라 디자인과 개발 시간이 늘어난다. 기반이 작업 중요하다. 이것이 잘되어야 계획 초안이 견고해진다. (비즈니스 목표와 사용자 니즈 모두를 충족하는 솔루션을 설계의 중심에 둘 것) 전략을 정의하고, 목표를 분명히 한다. (각 목표가 구체적일수록 실현 가능성은 높아진다.) 우리의 UX 디자인은 누구를 위한 것인가? (목표 고객을 분명히 하자.) 어떤 방법으로 UX 디자인 할 것인가? 왜 그 방법을 택했는가? 실현하고자 하는 것이 무엇인가? 그리고 실현 여부를 어떻게 평가할 것인가? 프로젝트 시작과 완료 시점은? 프로젝트의 각 단계별 주요 작업이 무엇이고, 각 완료와 성공 여부를 평가할 시점은? UI 보다는 기능을 중요시한다. UI는 사용자들이 애플리케이션을 눈으로 보면서 사용하는데 큰 역할을 한다. 하지만, 디자인을 시작하기에 앞서 우리는 사용자들이 필요로 하는 것이 무엇인지를 이해해야하고, 그것을 기능과 흐름에 반영해야 한다. 광고한 기능이 안되거나 버그가 많아서 제대로 작동하지 않으면 아무리 겉모습이 멋지고 매력적이라도 금새 잊혀진다. 사용자를 잡으려면, 사용자들이 기능을 사용하도록 해야 한다. 프로젝트를 시작하기 전에 누가, 무엇을, 왜 하는지를 정의하면 설계 또는 재설계 중에 부딪히는 문제를 어떻게 해결할 지를 이해하는데 도움이 된다. 각 요소를 정렬하고 프로젝트 팀원 모두가 설계 절차에 맞추도록 하면, 진행 중 애매모호한 커뮤니케이션을 방지할 수 있고, 뒤의 단계에서 크게 또는 예상치 못하게 변경 작업을 해야 할 가능성이 낮아진다. 문제점을 빠르게 진단하고, 계획이 더 견고하고 명확해지도록 하는 알맞은 해법을 빠르게 찾자. 열린 대화를 사용자들과 더 많이 하자. (최고의 결과를 만들고, 프로젝트 성공 확률이 높아진다.) 애플리케이션 디자인의 핵심은 안에 들어있는 내용들이다. 화면 요소가 올바른 위치에 있도록 하자. 그래야 최상의 사용성과 접근성을 실현할 수 있고 업계 표준과 회사의 가이드라인을 맞출 수 있다. 이제 시각적 디자인을 시작하자. 디자이너들은 사용자를 연구한 결과와 비즈니스 가이드라인에 기반하여 스타일 가이드, UI 패턴, 표준 템플릿을 만든다. 애플리케이션 디자인의 핵심 목표는 사용자 경험이 최고가 되도록 하는 것이다. 사용자 테스트가 중요하다. 디자인 전략이 좋고 잘 반영됐는지를 알 수 있는 유일한 방법은 사용자 테스트를 통해 많은 의견을 모으는 것이다. UX 전략을 유연하고 지속적으로 업데이트한다. (그래야 변하는 고객의 요구사항을 흔들림없이 충족할 수 있다.) 사용자의 니즈와 기대는 늘 변한다. (지금 최첨단이라도 몇년 후면 구식이 된다.) UX 전략에는 UX 테스트가 포함되도록 처음부터 고려하자. 그러면, UX 전략은 훨씬 더 많은 상황에서 활용가능하다. 완성된 애플리케이션을 향후에 완전히 새로 디자인해야하는 상황이 줄어든다. UX 전략 구축 및 최적화 팁 어떤 플랫폼에서든 지금까지 경험한 최고의 애플리케이션과 최악의 애플리케이션을 참고하자. 내 애플리케이션 중에서 가장 뛰어난 것을 골라서 핵심 요소를 반영하자. 뛰어난 UX를 제공하여 비즈니스 목적을 달성하고 사용자들에게 도움이 된 앱이 있다면, 그 앱이 특별했던 이유를 파악하고, 그 UX의 특징을 당신 회사의 UX 전략에 반영하자. 그러면, 집중할 영역이 좁혀지고 성공적인 UX 계획에 좀 더 가까워진다. 경쟁 애플리케이션 중에서 뛰어난 것들만 몇개 추려서 목록을 추리고 특징을 담아내자. 시중에는 수천가지 데스크톱 애플리케이션이 있다. 즉, 우리가 개발하는 새 앱에 영향을 끼칠 수 있는 것들이 그만큼 많다. 추려진 목록에서 몇가지 핵심 특징을 취하여 당신의 UX 전략에 담을 수 있을 것이다. 더 오래 사용할 수 있도록 데스크톱 애플리케이션을 디자인하자. 사용자들은 시간이 오래 걸리는 작업일수록 데스크톱 애플리케이션을 더 선호하는 경향이 있다. 사용자가 편하게 느끼는 것이 중요하다. 그래야 긴 시간동안 사용할 수 있다. 다크 모드와 라이트 모드를 선택할 수 있도록 하거나, 애플리케이션의 글자 크기를 알맞게 바꿀 수 있도록 하는 등 그 무엇이든 사용자가 편하게 느끼는 UX를 제공하자. UX 전략에 사용자 테스트가 들어 있으면 좋다. 애플리케이션의 약점과 강점을 개발 진행 과정에 미리 파악할 수 있다. 알맞은 평가표를 갖춘 테스트를 준비한 후, 정기적인 테스트 일정을 정하고 지키는 것이 좋다. 당신의 비즈니스에 집중하여 앱의 약점을 강점으로 바꾸고 UX를 최적화할 수 있다. 애플리케이션 개선을 반복하자. 사용자들이 언제나 충분히 지원받을 수 있도록 하기 위해서는 애플리케이션을 끊임없이 업데이트 해야한다. UX를 중요하게 여기는 회사에서는 앱이 일정 수준의 UX에 도달하는지를 확인하기 때문에 피드백 수집이 매우 중요하다. 사용자의 피드백 수집 방식은 다양하다: 고객과의 통화, 사용자 설문조사 SNS, 제품 소개 비디오 등 애플리케이션을 출시한 후에도 소프트웨어 요구사항으로 인해서 변경을 해야 하는 경우가 종종 있다. 원인: 원하는 수준이 안되거나, 사용자 니즈가 더 높아졌거나, 하드웨어 또는 기타 소트프웨어를 지원해야 하는 상황 등이 발생할 수 있다. 결과: 애플리케이션 변경, 새 기능 추가, 그에 따른 버그 리포트가 발생한다. 유연하면서 적응성이 좋은 계획을 유지하자. 언제든 사용자 분석 연구로 되돌아가서, 어떤 점을 향상할 수 있는지를 빠르게 찾도록 하자. 핵심 요약 UX는 UI보다 훨씬 큰 개념이다. UX는 사용자가 애플리케이션을 사용하면서 경험하는 모든 것을 의미한다. UX 전략을 수립하려면 “우선순위” 문제에 답할 수 있어야 한다. 디자인과 개발 중심을 어디에 집중할 지를 결정할 때, 가장 큰 영향을 끼치는 요소에 대해 높은 수준의 관점에서 결정하고 리소스를 할당하고 방향을 제시할 수 있어야 한다. 질문과 답변을 충분히 하자. (앞에 나온 목표와 질문들이 도움이 된다.) 여러 선택지를 펼쳐놓고 선택할 수 있다. 틀에 박힌 생각에서 벗어나고, “이럴 수 있다면 어떨까?(What-If)” 질문 할 수 있다. 내가 지금 무엇을 하고 있는지, 결국 무엇을 하게 되는지에 대한 명확한 이미지를 가질 수 있다. UX의 최종 목표는 결국 고객 만족이다. << UX Summit 2020 목록으로 이동 View full 아티클
  21. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Point of Sale Screen Concept - Diego Souza 입니다. 이 세션은 다른 UX 서밋의 세션과 달리 따라하기 실습 비디오이다. YouTube 비디오 보기 (55 min) 식당용 POS 화면 하나를 그대로 따라하면 완성할 수 있도록 처음부터 하나씩 빠짐없이 시연한다. 음성 듣지 않고 화면만으로도 사용자가 전 과정을 따라할 수 있다. 이 비디오를 따라서 똑같이 만들다보면, 델파이로 멋진 화면을 만드는 실무 능력도 향상된다. 그림 1. 함께 완성할 식당용 POS 화면 << UX Summit 2020 목록으로 이동
  22. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Point of Sale Screen Concept - Diego Souza 입니다. 이 세션은 다른 UX 서밋의 세션과 달리 따라하기 실습 비디오이다. YouTube 비디오 보기 (55 min) 식당용 POS 화면 하나를 그대로 따라하면 완성할 수 있도록 처음부터 하나씩 빠짐없이 시연한다. 음성 듣지 않고 화면만으로도 사용자가 전 과정을 따라할 수 있다. 이 비디오를 따라서 똑같이 만들다보면, 델파이로 멋진 화면을 만드는 실무 능력도 향상된다. 그림 1. 함께 완성할 식당용 POS 화면 << UX Summit 2020 목록으로 이동 View full 엠바카데로 기술자료
  23. << UX Summit 으로 이동 UX Summit 의 2020 시리즈 중, Sense & Respond: Continuously Learning Our Way to Better Outcomes - Jeff Gothelf 의 한글 번역본입니다. 발표자 (Jeff Gothelf)는 애자일 UX와 린 UX 분야에서 매우 인기가 높은 전문가로서 “Forever Employable”, “Lean UX”, “Lean, Agile & Design Thinking”등을 저술한 Gothelf.co의 대표입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (총 20분) 보기 이 세션을 통해서 우리는, 오늘날 우리가 만드는 소프트웨어가 세상을 어떻게 바꾸고 있고 얼마나 영향력이 큰지를 알 수 있습니다. 이에 맞게 소프트웨어 개발자는 어떤 자세를 가져야 하는지를 생각할 수 있습니다. (사람들은 소프트웨어를 의도된 대로 사용하지 않는다는 사실을 인정하고) 더 좋은 소프트웨어 UX를 제공하기 위한 근본적인 접근 방식을 배울 수 있습니다. 20-30년 전의 소프트웨어 세상은, 학습이 오래 걸렸다: 만들 수 있는 소프트웨어가 무엇인지조차 알기 어려웠다. 소프트웨어 도입이 느렸다: 설치 미디어를 한 박스 사서 설치해야 했다. 영향(Impact)은 기술 전문가들에게만 끼쳤다: 소프트웨어를 사서 쓸 수 있는 사람이 제한적이었다. 설계한 대로 작동하는 것이 목표였다: 약속한 기능이 작동하는 가가 중요했다. 소프트웨어 출시는 성공을 의미했다: 정해진 시간과 예산 안에 출시가 곧 성공이었다. 지금 소프트웨어는 이미 세상을 삼켰다. 2011년, 마크 앤드리슨은 “소프트웨어가 세상을 삼키고 있다”는 유명한 말을 남겼다. 지금은 소프트웨어가 핸드폰 뿐만 아니라 커피머신, 소금통 등 수많은 것을 인터넷에 연결하고 있다. 소프트웨어의 근본적인 속성은 20~30년 전에 비해 완전히 달라졌다. 예전에는 하드웨어에 들어있는 정적인 것이었다. 이제는 계속해서 학습하면서 진화하는 일종의 지속적인 시스템이다. 예전과 같은 정해진 계획에 따라 소프트웨어를 제작 배포하는 예전 방식이 아니라, 이제는 지속적인 시스템을 만들어 간다. 결승점이 따로 없고 우리는 이 시스템이 어떻게 사용되는 지를 살피고 지속적으로 새로운 길을 모색한다. "우리는 지금 빅데이터 기술이 부상하는 것을 목격하고 있다. 사물인터넷이 뜨고 있고, 인공지능이 여전히 초기 단계이다. 따라서 우리는 결승선이 없고 전례도 없는 경주에서 경쟁하고 있다. 규칙 역시 전혀 없다.” - 프란치스코 곤잘레스 지금의 자동차 산업을 보면 예전의 소프트웨어 산업을 보는 것 같다. 지금 가진 차보다 더 빠르고, 더 연비가 좋고, 더 음향이 좋은 자동차를 가지려면 새 모델을 사는 것이 당연하다는 믿음이 100년째 이어지고 있다. 사실 이것은 100년전 GM에서 만든 마케팅을 우리가 받아들인 결과일 뿐, 당연해야 할 이유는 없다. 소프트웨어도 예전에는 마찬가지였다. 심지어 윈도우 95, 98, 2000처럼 제품에 연도를 붙이기도 했다. 소프트웨어 업계의 사람들이 자동차를 만들기 시작하자, 자동차 산업에서 사용자 경험과 가치를 만들고 제공하는 방식이 근본적으로 변했다. 테슬라 차는 자고나면 향상된다. 자고나면 자동차가 향상되어 스스로 운행할 수 있고, 또 자고 나면 자동차가 내가 있는 곳을 찾아오는 기능이 추가된다. 사실 향상되는 것은 자동차 자체라기 보다는, 지속적으로 그 차를 지원하는 시스템이 향상되는 것이다. 테슬라의 업데이트 사례 일론 머스크는 고객 의견을 트위터에서 인식하고, 응답했다. 그리고 6일 만에 해결책이 반영되었다. 테슬라가 기존 자동차 회사처럼 일하는 조직이었으면 시도조차 하지 않았을 것이다. 소프트웨어 방식으로 일하기 때문에 가능했다. (기사 보기, Opinion: One day, All Companies might be in the Software Business, 2017년 2월) (고객의) 의견: 충전이 완료되어도 충전소에 계속 머무는 운전자 때문에 충전기를 사용하지 못한다. (일론 머스크의) 응답: 맞다. 충전소는 충전하는 곳이지 주차하는 곳이 아니다. (6일 후 반영된) 조치: "충전이 완료된 시점 이후 분당 사용료가 추가되도록" 테슬라 앱이 업데이트 되었다. (기사 보기, 2014년 2월: 테슬라의 무선 정비: 현존하는 최고의 사물인터넷 사례인가?) 테슬라는 판매한 자동차에 대한 지속적인 향상을 무상으로 제공하는 세계에서 유일한 자동차 회사이다. 살짝 바뀐 새 모델을 출시하고 가격을 올리는 다른 자동차 회사들과 비교된다. 테슬라 자동차의 하드웨어는 소프트웨어 무선 업데이트를 통해 거의 끊임없이 개선될 수 있도록 세심하게 설계되어 있다. 간단한 하드웨어 보정도 포함된다. 이로 인해 테슬라 중고차의 가격이 경쟁사의 새 차 가격과 차이가 없다면 테슬라에게 유리하다. 요컨데, 하드웨어 개선과 소프트웨어가 개선, 이 모두가 무료로 제공된다. 지속적인 피드백 루프 - 고객과 대화하면서 향상시키는 능력을 갖추자. 엄청한 기회가 온다. 그림1. 지속적 피드백 루프: 감지-응답-배포 Ship(배포, 사용자에게 배포) - Sense(감지, 사용자의 변화된 행위 파악) - “Respond(응답, 파악된 것에 대응) - Ship(배포) - ... Ship(배포): 작고 빠르게 배포함으로써 투자를 최소화 하자. 그러려면, 이것을 가능하도록 만드는 체계에 투자하자. Sense(감지): 새 배포에 대해 고객이 어떻게 행동하는 지를 파악하자. 그러려면, 연구 분석에 투자하자. Respond(응답😞 고객으로부터 알게 된 것을 바탕으로 우리가 해야할 것을 하자. 그러려면, 조직 문화가 변해야 한다. 이 주기를 매우 빠르고 빈번하게 하자. 한 바퀴 돌 때마다 뭔가를 배우게 된다. 빨리 배울 수록 빨리 조치할 수 있고, 투자는 더 작아진다. 그러면 실패하더라도 손실 역시 더 적다. 잘못된 것을 알게 되기까지 6일 걸리는 체계와 6달 걸리는 체계는 그 차이가 크다. 피드백 루프를 빠르게 돌려서 가능한 빠르게 학습 하고 반복하는 문화를 구축해야 소프트웨어가 가진 지금의 속성을 십분 활용할 수 있다. 조직 문화가 “근본적으로” 변해야 한다. 고객 피드백에 대해 걱정없이 내부 논의를 할 수 있는 문화가 중요하다. 예: “이번에 배포한 기능이 효과가 매우 클 것으로 예상했는데 실제로는 효과가 없네요. 뭔가 다른 시도를 해야겠어요”라는 말을 걱정없이 할 수 있어야 한다. 그리고 매우 빠르게 대응하고, 마음 편히 반복할 수 있는 문화가 중요하다. 그래야 잘못된 아이디어도 쉽게 파악된다. 새로운 아이디어로 인해 피해가 생기는 경우에도 피해 규모가 작아진다. 소프트웨어 회사라면 사고 방식을 바꾸자. 소프트웨어 공장처럼 일하지 말자: 소프트웨어를 더 많이 만든다고 더 좋은 회사가 된다는 생각을 버리자. 코드가 더 많아진다고, 고객이나 사업의 가치가 더 높아지지 않는다: 코드가 많아지는 경우, 늘어났다고 확신할 수 있는 것은 코드 자체 뿐이다. 코드가 늘어나면 잠재적인 기술적 부채는 더 커진다. 회사의 성공을 측정하는 방법을 바꾸자: 오로지 고객에게만 집중하는 업무 방식과 감각이 필요하다. 우리가 만들 수 있는 기능이라는 이유로 그저 만들기만 한다면, 우리 능력으로 만들 수 있는 기능들을 빠르게 배포할 수 있다. 하지만, 기능이 많다고 해서 위대한 소프트웨어가 되는 것이 아니다. 오히려 아무도 바라지 않고, 아무도 사용하지 못하는 기능들로 가득차게 될 수 있다. 회사의 성공 척도는 실제 결과(Outcome)여야 한다. 코드, 기능, 생산 자체를 가지고 성공을 측정하면 안된다. 실제 변화된 사용자 행위가 곧 결과(Outcome)이다. 우리가 사용자에게 실제로 가치를 제공했는지는 그 결과를 통해 알 수 있다. 실제 결과를 보면, 우리가 언제 고객에게 가치를 제공했는지를 알 수 있다. 제품을 제공하는 체계가 구축되면, 초기 버전부터 고객과의 대화가 시작되고 실제 결과를 볼 수 있다. 피드백 반복을 지속하면서 고객의 행위가 향상되도록 지속적으로 소프트웨어를 개선할 수 있다. 문제(Problem): 우리는 사용자의 행위를 예상할 수 없다. 기능을 생각하는 것은 쉽다. 고객이 어떻게 사용할 지를 알고 있다고 믿는 것도 쉽다. 하지만, “우리가 사용자의 행위를 예상할 수 없다”는 것이 사실이고 현실이다. 삼거리에서 불법 좌회전을 방지하기 도로 바닥에 “우회전만 됨” 표시가 있지만, 실제로는 좌회전하는 차량이 많았다. 이 도로의 안전을 향상시키려면? 그림2. 생산(Output) 대 결과(Outcome) 조치(우리가 생산한 것, 즉 Output): 좌회전 금지 교통 표지판을 붙인다. 의도한 결과: 운전자들이 이 표지판을 보고 좌회전을 하지 않을 것이라고 생각했다. 실제 결과(Outcome): 이후에도 주민들은 계속 좌회전을 하기를 원했고, 실제로 계속 좌회전했다. 생산(Output) vs 결과(Outcome)를 구분하자. Output (부착한 교통표지판) 자체가 문제였을까? 표지판은 아무 문제없다. (소프트웨어라면 약속된 스펙에 맞게 기능이 제공된다.) Outcome (운전자 행위 변화) 결과는 생겼는가? 아니다. (소프트웨어로 치자면 Outcome이 없는 Output이다. 아무리 멋져보여도 쓸모가 없다.) 우리의 목표는 사용자 행위를 변화시키는 Outcome을 만드는 것이다. 소프트웨어는 이 삼거리보다 훨씬 더 복잡하고 예측하기 힘들다. 사람들은 본질적으로 다양하고 예측불가하고 고집스럽기도 하다. 사람들은 과거의 경험, 문화적 기준 등 수많은 요인에 다양하게 행동한다. 우리가 제공한 기능을 그저 장애물로 여길 수도 있다. 우리가 사용자의 행위를 파악했다고 하더라고, 변하기 마련이다. 변하는 속도는 점점 빨라진다. 사용자는 우리가 만든 시스템을 사용하는 동안 새로운 행위를 하기 시작하기도 한다. (사례) 인스타그램 고객은 인스타그램에 올릴 완벽한 사진을 위해 찍고 편집 하는 과정 때문에 스트레스를 받았다. 특히 10대 소녀들에게 이 스트레스가 더 심했다. 10대 소녀들은 이 스트레스에서 벗어나기 위해, 인스타그램에서 예상하지 못했던 다른 행동을 하기 시작했다. 핀스타(Finsta) 현상: 인스타그램에서 10대 소녀들이 친한 친구들끼리만 소통하는 용도로 가짜 계정을 만들고 솔직하고 사실적인 사진을 공유하는 현상. 핀스타를 통해 10대 소녀들은 완벽한 사진에 대한 집착과 스트레스에서 벗어날 수 있었다. 인스타그램은 인스타그램 사용자들의 이런 사용을 주의깊게 보기 시작했다: 인스타그램 밖에서도 이런 현상이 있다는 것을 파악했다. 예를 들면 스냅챗에서는 24시간이 지나면 포스팅이 없어지는 기능이 많이 사용되고 있었다. 인스타그램은 스토리 서비스를 만들었다: 이것은 현재 가장 성공적인 인스타그램 기능이다. 인스타그램 스토리는 앞에서 파악된 사용자의 니즈를 충족했다. 이처럼 인스타그램은 지속적으로 관찰하고 반영하여 진화하는 시스템이다. 또 다른 문제(Problem): 우리는 미래를 예측하지 못한다. 그렇기 때문에 우리는 지속적이고 작은 피드백 루프를 통해 사용자가 더 성공할 수 있도록 돕는 능력을 강화해야 한다. 피드백 루프 (배포-감지-응답)를 통해 사업을 기민(Agile)하게 운영하는 것이 중요한 이유는, 애자일(Agile, 기민한) 사업은 방향 전환을 신속하게 할 수 있다. 그 결과, 어떤 상황에서도 생존할 수 있다. 사례: 미국의 모 증류주 회사에서는 이미 보유한 알콜을 사용하여 소독제를 만들어서 무상 배포하고 있다. (기사 보기) 예전에 성공한 방식이나 기존의 유명 브랜드가 계속 성공할 것이라는 보장을 할 수 없는 세상이 되었다. 새 기능을 잔뜩 만들고 마케팅 예산을 많이 투입해도 성공한다는 확신이 없는 세상이 되었다. 사례: 퀴비(Quibi)의 화려한 출발과 6개월만의 몰락 이 모바일 전용 온라인 동영상 서비스는 영화사와 유명 테크 기업의 유능한 임원들이 모여 막대한 자금을 투자하고도 6개월만에 문을 닫았다. (기사 보기) 사소한 기능이 (긍정적이든 부정적이든) 예상치 못한 엄청난 결과를 초래할 수도 한다. 따라서, 우리는 우리가 실제로 세상에 끼치는 결과(Outcome)를 측정하는 것에 집중해야 한다. (세상에 끼치는 결과에 대한 고려가 없이) 무작정 개선하면 위험을 자초한다. 최악의 경우 범죄가 되기도 한다. 사례1: 참여(Engagement)라는 이름 하에 반인륜적 범죄에 도움이 되기도 한다. 페이스북은 월 활성 사용자수(MAU)와 일 활성 사용자수(DAU) 라는 개념을 전세계에 확산했다. 이 두가지 지표에만 집중한다. 이 지표만 높일 수 있으면, 사용자들이 실제로 무슨 일을 하건 (학살을 장려하건, 정치 선동을 하건) 신경쓰지 않는다. 페이스북은 미얀마에서 로힝야족의 위치를 찾고 학살하는데 활용되었다. (기사 보기) 페이스북은 정치인들이 사회적 기준을 위반하는 발언을 페이스북에 올리는 것을 금지하지 않기로 했다. (트위터 보기) 유튜브는 사용자가 동영상을 보면 같은 내용을 담은 동영상 50개를 목록에 보여준다. 유튜브는 사용자가 무엇을 보는 지에는 관심이 없고, 얼마나 많이 보는가에만 집중하고 더 많이 보도록 노력한다. 예를 들어, 백인 우월주의 청년이 유튜브를 보다보면 점점 더 확신에 빠지고, 테러까지 하게 되는 결과로 이어질 수 있다. 머신러닝과 AI의 도덕적 해이의 사례: 어떤 대상에 대해서도 강력하게 최적화된 알고리즘을 만들 수 있지만, 그 어느 알고리즘도 그것이 최적화할 가치 있는 대상인지에 대해서 말하지 않는다. (트위터 보기, "유튜브 인공지능 Reinforce은 사용자가 훨씬 더 많은 동영상을 보도록 하는데 성공했다") 사례2: “판매”라는 이름 하에 인간 관계 문제를 만들기도 한다. 소매점은 데이터 마이닝(Data Mining)을 통해 판매 흐름을 최적화하고 고객의 니즈를 예측하는 능력을 강화하기를 원한다. 타겟(미국의 소매점)은 여기에 매우 능하다. 고객이 어디에서 무엇을 샀는지, 매장을 방문하는지 온라인 쇼핑을 하는지 등을 파악하고 그 정보를 활용한다. 심지어 고객의 임신유무도 알고 임신/출산용품 관련 할인 쿠폰을 보내기도 한다. 타겟은 한 여고생이 임신한 사실을 파악하고, 그 소녀가 부모에게 직접 말하기도 전에, 부모에게 알렸다. (기사 보기: "타겟은 어떻게 한 10대 소녀가 임신한 사실을 아버지보다도 먼저 알았을까?") 사례3: “효율성”이라는 이름 하에 성차별이 발생할 수 있다. 아마존은 지원자의 이력서를 효율적으로 처리하기 위해 AI를 적용했다. 이 AI에는 편향된 알고리즘이 들어 있었다. Women's라는 단어가 들어 있으면 감점을 했는데 그 결과 여대를 졸업한 지원자 모두에게 감점이 반영되었다. 아마존은 곧 이 문제를 수정했다. 아마존은 AI를 통해 효율성을 높였지만, 실제 결과는 차별이 발생했다. (기사 보기) 우리는 이 사례를 통해 Outcome에 집중해야 한다는 점을 배울 수 있다. 사례4: “편리함”이라는 이름 하에 - 사람을 위협할 수도 있다. (온도 조절기, 잠금 장치, 조명 등) 스마트홈 기술은 정말 편리하다. 스마트홈 기술을 이용하여 헤어진 배우자를 위협하는 사람들도 있다. (기사 보기) 우리의 사업 성공의 척도에는 사람들이 어떻게 사용하는 가? 나쁜 용도로 사용되지는 않는가? 등의 Outcome이 들어가야 한다. 사례5: “뉴스”라는 이름 하에 - 우리에게 가장 나쁜 것들을 전한다. 뉴스를 예로 들면, 일상적이지 않은 가장 나쁜 사건을 널리 전한다. 우리가 고객의 니즈를 해소해주던지, 오히려 망치던지, 두 경우 모두 매출이 발생한다. 우리는 피드백 루프를 반복하면서, 매출 뿐만 아니라 우리가 실제로 제공하는 가치에 대해 끊임없이 살펴야 한다. 이것은 최고경영진 이슈다. (Alan Pao, Wired 기고 보기) SNS 회사와 임원들은 사용자들이 얼마나 많고 얼마나 참여하는 지에 따라 보상을 받는다. 이들은 긍정적인 영향을 미치는지, 위험 요소로부터 보호하는지 등에는 신경쓰지 않게 된다. 소프트웨어 사업자/설계자/개발자는 Outcome을 잘 살펴야 한다. 하지만, 개발자들 대부분의 대답은 "난 제품 책임자를 믿어요”: 제품 책임자를 믿는 것은 좋지만, 검증하라! 지금 만들고 있는 것이 전략에 맞는지, 왜 만드는지, 어떻게 돈을 벌 것인지를 질문하자. 만약 책임자도 잘 모른다면 함께 대답을 찾자. “난 그저 코드를 작성하고 싶어요. 고객이나, Outcome 같은 것은 신경쓰기 싫어요”: 20-30년 전만해도 작성된 코드는 전문 기술자들에게만 영향을 끼쳤다. 하지만, 이제는 너무나 많은 사람들에게 영향을 끼친다. 이제는 더이상 그냥 코드만 작성하는 것만 즐기는 시대가 아니다. 사람을 존중하는 결과를 가져오는지도 고려해야 한다. 당신의 코드가 무엇을 하는 데 사용되는 지에 대해 책임을 져야 한다. "새로운 기술은 기본적으로, (더 넓은 사회의 윤리적 흔적이 아니라) 그 기술을 만든 사람의 윤리적 흔적을 담고 있다." - Cennydd, ‘Future Ethics’ 폭스바겐의 소프트웨어 엔지니어가 디젤 엔진 조작으로 징역 4년형을 받았다. (기사 보기) 그는 자신이 만든 소프트웨어의 사용자가 좋은 의도로 사용할 것이라고 생각하지는 않았을 것이다. 그리고 감옥에 갔다. 폭스바겐 CEO는 감옥에 가지 않았다. 어떤 개발자는 사표를 내기도 한다 (기사보기: 페이스북 엔지니어 또 한명이 역겨움에 회사를 그만두었다. 페이스북은 역사상 잘못된 편에 서있는 회사라고 말했다.) 고객 중심적인 피드백 루프 (배포-감지-응답)을 바탕으로 훌륭한 UX를 만드는 방법 "목표를 향하고, 가치를 통해 길을 잡고, 두가지 모두 측정하라" - Kim Goodwin 목표(Goal): 실제 결과(Outcome)와 그 측정 지표 가치(Value): 목표 때문에 희생하고 싶지는 않은 것들 측정: 목표와 가치를 각각 명확히 하고, 이 둘 간의 경계도 명확히 하자. 경계가 침범되면 의견을 제시하자. 우리가 무엇을 할 수 있을까? (당신의 사업 모델 즉 회사가 어떻게 돈을 버는 지를) 이해하라. 예) 수집된 데이터는 어떻게 수익에 기여하는가? (고객 안에 들어 있는) 관심을 파악하라. 예) 고객은 무엇을 하려고 하는가? 고객이 그 목적을 이루고 있는가? 새로운 행동을 하고 있는가? (고객의 행동을 인지하기 위해) 당신이 만들고 있는 소프트웨어를 직접 사용하라. (당신의 일이 끼치는 영향을) 측정하라. (어쩌다 발생할 수 있는 위험에 대해) 논의하라. (사람에게 위해한 일은) 거부하라. “너희 과학자들은 자신들이 할 수 있는가 아닌가에만 빠져서 멈춰서서 하는 것이 옳은가 아닌가를 생각하지 않았어.” - 영화 쥬라기공원 중에서 << UX Summit 으로 이동
  24. << UX Summit 으로 이동 UX Summit 의 2020 시리즈 중, Sense & Respond: Continuously Learning Our Way to Better Outcomes - Jeff Gothelf 의 한글 번역본입니다. 발표자 (Jeff Gothelf)는 애자일 UX와 린 UX 분야에서 매우 인기가 높은 전문가로서 “Forever Employable”, “Lean UX”, “Lean, Agile & Design Thinking”등을 저술한 Gothelf.co의 대표입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (총 20분) 보기 이 세션을 통해서 우리는, 오늘날 우리가 만드는 소프트웨어가 세상을 어떻게 바꾸고 있고 얼마나 영향력이 큰지를 알 수 있습니다. 이에 맞게 소프트웨어 개발자는 어떤 자세를 가져야 하는지를 생각할 수 있습니다. (사람들은 소프트웨어를 의도된 대로 사용하지 않는다는 사실을 인정하고) 더 좋은 소프트웨어 UX를 제공하기 위한 근본적인 접근 방식을 배울 수 있습니다. 20-30년 전의 소프트웨어 세상은, 학습이 오래 걸렸다: 만들 수 있는 소프트웨어가 무엇인지조차 알기 어려웠다. 소프트웨어 도입이 느렸다: 설치 미디어를 한 박스 사서 설치해야 했다. 영향(Impact)은 기술 전문가들에게만 끼쳤다: 소프트웨어를 사서 쓸 수 있는 사람이 제한적이었다. 설계한 대로 작동하는 것이 목표였다: 약속한 기능이 작동하는 가가 중요했다. 소프트웨어 출시는 성공을 의미했다: 정해진 시간과 예산 안에 출시가 곧 성공이었다. 지금 소프트웨어는 이미 세상을 삼켰다. 2011년, 마크 앤드리슨은 “소프트웨어가 세상을 삼키고 있다”는 유명한 말을 남겼다. 지금은 소프트웨어가 핸드폰 뿐만 아니라 커피머신, 소금통 등 수많은 것을 인터넷에 연결하고 있다. 소프트웨어의 근본적인 속성은 20~30년 전에 비해 완전히 달라졌다. 예전에는 하드웨어에 들어있는 정적인 것이었다. 이제는 계속해서 학습하면서 진화하는 일종의 지속적인 시스템이다. 예전과 같은 정해진 계획에 따라 소프트웨어를 제작 배포하는 예전 방식이 아니라, 이제는 지속적인 시스템을 만들어 간다. 결승점이 따로 없고 우리는 이 시스템이 어떻게 사용되는 지를 살피고 지속적으로 새로운 길을 모색한다. "우리는 지금 빅데이터 기술이 부상하는 것을 목격하고 있다. 사물인터넷이 뜨고 있고, 인공지능이 여전히 초기 단계이다. 따라서 우리는 결승선이 없고 전례도 없는 경주에서 경쟁하고 있다. 규칙 역시 전혀 없다.” - 프란치스코 곤잘레스 지금의 자동차 산업을 보면 예전의 소프트웨어 산업을 보는 것 같다. 지금 가진 차보다 더 빠르고, 더 연비가 좋고, 더 음향이 좋은 자동차를 가지려면 새 모델을 사는 것이 당연하다는 믿음이 100년째 이어지고 있다. 사실 이것은 100년전 GM에서 만든 마케팅을 우리가 받아들인 결과일 뿐, 당연해야 할 이유는 없다. 소프트웨어도 예전에는 마찬가지였다. 심지어 윈도우 95, 98, 2000처럼 제품에 연도를 붙이기도 했다. 소프트웨어 업계의 사람들이 자동차를 만들기 시작하자, 자동차 산업에서 사용자 경험과 가치를 만들고 제공하는 방식이 근본적으로 변했다. 테슬라 차는 자고나면 향상된다. 자고나면 자동차가 향상되어 스스로 운행할 수 있고, 또 자고 나면 자동차가 내가 있는 곳을 찾아오는 기능이 추가된다. 사실 향상되는 것은 자동차 자체라기 보다는, 지속적으로 그 차를 지원하는 시스템이 향상되는 것이다. 테슬라의 업데이트 사례 일론 머스크는 고객 의견을 트위터에서 인식하고, 응답했다. 그리고 6일 만에 해결책이 반영되었다. 테슬라가 기존 자동차 회사처럼 일하는 조직이었으면 시도조차 하지 않았을 것이다. 소프트웨어 방식으로 일하기 때문에 가능했다. (기사 보기, Opinion: One day, All Companies might be in the Software Business, 2017년 2월) (고객의) 의견: 충전이 완료되어도 충전소에 계속 머무는 운전자 때문에 충전기를 사용하지 못한다. (일론 머스크의) 응답: 맞다. 충전소는 충전하는 곳이지 주차하는 곳이 아니다. (6일 후 반영된) 조치: "충전이 완료된 시점 이후 분당 사용료가 추가되도록" 테슬라 앱이 업데이트 되었다. (기사 보기, 2014년 2월: 테슬라의 무선 정비: 현존하는 최고의 사물인터넷 사례인가?) 테슬라는 판매한 자동차에 대한 지속적인 향상을 무상으로 제공하는 세계에서 유일한 자동차 회사이다. 살짝 바뀐 새 모델을 출시하고 가격을 올리는 다른 자동차 회사들과 비교된다. 테슬라 자동차의 하드웨어는 소프트웨어 무선 업데이트를 통해 거의 끊임없이 개선될 수 있도록 세심하게 설계되어 있다. 간단한 하드웨어 보정도 포함된다. 이로 인해 테슬라 중고차의 가격이 경쟁사의 새 차 가격과 차이가 없다면 테슬라에게 유리하다. 요컨데, 하드웨어 개선과 소프트웨어가 개선, 이 모두가 무료로 제공된다. 지속적인 피드백 루프 - 고객과 대화하면서 향상시키는 능력을 갖추자. 엄청한 기회가 온다. 그림1. 지속적 피드백 루프: 감지-응답-배포 Ship(배포, 사용자에게 배포) - Sense(감지, 사용자의 변화된 행위 파악) - “Respond(응답, 파악된 것에 대응) - Ship(배포) - ... Ship(배포): 작고 빠르게 배포함으로써 투자를 최소화 하자. 그러려면, 이것을 가능하도록 만드는 체계에 투자하자. Sense(감지): 새 배포에 대해 고객이 어떻게 행동하는 지를 파악하자. 그러려면, 연구 분석에 투자하자. Respond(응답😞 고객으로부터 알게 된 것을 바탕으로 우리가 해야할 것을 하자. 그러려면, 조직 문화가 변해야 한다. 이 주기를 매우 빠르고 빈번하게 하자. 한 바퀴 돌 때마다 뭔가를 배우게 된다. 빨리 배울 수록 빨리 조치할 수 있고, 투자는 더 작아진다. 그러면 실패하더라도 손실 역시 더 적다. 잘못된 것을 알게 되기까지 6일 걸리는 체계와 6달 걸리는 체계는 그 차이가 크다. 피드백 루프를 빠르게 돌려서 가능한 빠르게 학습 하고 반복하는 문화를 구축해야 소프트웨어가 가진 지금의 속성을 십분 활용할 수 있다. 조직 문화가 “근본적으로” 변해야 한다. 고객 피드백에 대해 걱정없이 내부 논의를 할 수 있는 문화가 중요하다. 예: “이번에 배포한 기능이 효과가 매우 클 것으로 예상했는데 실제로는 효과가 없네요. 뭔가 다른 시도를 해야겠어요”라는 말을 걱정없이 할 수 있어야 한다. 그리고 매우 빠르게 대응하고, 마음 편히 반복할 수 있는 문화가 중요하다. 그래야 잘못된 아이디어도 쉽게 파악된다. 새로운 아이디어로 인해 피해가 생기는 경우에도 피해 규모가 작아진다. 소프트웨어 회사라면 사고 방식을 바꾸자. 소프트웨어 공장처럼 일하지 말자: 소프트웨어를 더 많이 만든다고 더 좋은 회사가 된다는 생각을 버리자. 코드가 더 많아진다고, 고객이나 사업의 가치가 더 높아지지 않는다: 코드가 많아지는 경우, 늘어났다고 확신할 수 있는 것은 코드 자체 뿐이다. 코드가 늘어나면 잠재적인 기술적 부채는 더 커진다. 회사의 성공을 측정하는 방법을 바꾸자: 오로지 고객에게만 집중하는 업무 방식과 감각이 필요하다. 우리가 만들 수 있는 기능이라는 이유로 그저 만들기만 한다면, 우리 능력으로 만들 수 있는 기능들을 빠르게 배포할 수 있다. 하지만, 기능이 많다고 해서 위대한 소프트웨어가 되는 것이 아니다. 오히려 아무도 바라지 않고, 아무도 사용하지 못하는 기능들로 가득차게 될 수 있다. 회사의 성공 척도는 실제 결과(Outcome)여야 한다. 코드, 기능, 생산 자체를 가지고 성공을 측정하면 안된다. 실제 변화된 사용자 행위가 곧 결과(Outcome)이다. 우리가 사용자에게 실제로 가치를 제공했는지는 그 결과를 통해 알 수 있다. 실제 결과를 보면, 우리가 언제 고객에게 가치를 제공했는지를 알 수 있다. 제품을 제공하는 체계가 구축되면, 초기 버전부터 고객과의 대화가 시작되고 실제 결과를 볼 수 있다. 피드백 반복을 지속하면서 고객의 행위가 향상되도록 지속적으로 소프트웨어를 개선할 수 있다. 문제(Problem): 우리는 사용자의 행위를 예상할 수 없다. 기능을 생각하는 것은 쉽다. 고객이 어떻게 사용할 지를 알고 있다고 믿는 것도 쉽다. 하지만, “우리가 사용자의 행위를 예상할 수 없다”는 것이 사실이고 현실이다. 삼거리에서 불법 좌회전을 방지하기 도로 바닥에 “우회전만 됨” 표시가 있지만, 실제로는 좌회전하는 차량이 많았다. 이 도로의 안전을 향상시키려면? 그림2. 생산(Output) 대 결과(Outcome) 조치(우리가 생산한 것, 즉 Output): 좌회전 금지 교통 표지판을 붙인다. 의도한 결과: 운전자들이 이 표지판을 보고 좌회전을 하지 않을 것이라고 생각했다. 실제 결과(Outcome): 이후에도 주민들은 계속 좌회전을 하기를 원했고, 실제로 계속 좌회전했다. 생산(Output) vs 결과(Outcome)를 구분하자. Output (부착한 교통표지판) 자체가 문제였을까? 표지판은 아무 문제없다. (소프트웨어라면 약속된 스펙에 맞게 기능이 제공된다.) Outcome (운전자 행위 변화) 결과는 생겼는가? 아니다. (소프트웨어로 치자면 Outcome이 없는 Output이다. 아무리 멋져보여도 쓸모가 없다.) 우리의 목표는 사용자 행위를 변화시키는 Outcome을 만드는 것이다. 소프트웨어는 이 삼거리보다 훨씬 더 복잡하고 예측하기 힘들다. 사람들은 본질적으로 다양하고 예측불가하고 고집스럽기도 하다. 사람들은 과거의 경험, 문화적 기준 등 수많은 요인에 다양하게 행동한다. 우리가 제공한 기능을 그저 장애물로 여길 수도 있다. 우리가 사용자의 행위를 파악했다고 하더라고, 변하기 마련이다. 변하는 속도는 점점 빨라진다. 사용자는 우리가 만든 시스템을 사용하는 동안 새로운 행위를 하기 시작하기도 한다. (사례) 인스타그램 고객은 인스타그램에 올릴 완벽한 사진을 위해 찍고 편집 하는 과정 때문에 스트레스를 받았다. 특히 10대 소녀들에게 이 스트레스가 더 심했다. 10대 소녀들은 이 스트레스에서 벗어나기 위해, 인스타그램에서 예상하지 못했던 다른 행동을 하기 시작했다. 핀스타(Finsta) 현상: 인스타그램에서 10대 소녀들이 친한 친구들끼리만 소통하는 용도로 가짜 계정을 만들고 솔직하고 사실적인 사진을 공유하는 현상. 핀스타를 통해 10대 소녀들은 완벽한 사진에 대한 집착과 스트레스에서 벗어날 수 있었다. 인스타그램은 인스타그램 사용자들의 이런 사용을 주의깊게 보기 시작했다: 인스타그램 밖에서도 이런 현상이 있다는 것을 파악했다. 예를 들면 스냅챗에서는 24시간이 지나면 포스팅이 없어지는 기능이 많이 사용되고 있었다. 인스타그램은 스토리 서비스를 만들었다: 이것은 현재 가장 성공적인 인스타그램 기능이다. 인스타그램 스토리는 앞에서 파악된 사용자의 니즈를 충족했다. 이처럼 인스타그램은 지속적으로 관찰하고 반영하여 진화하는 시스템이다. 또 다른 문제(Problem): 우리는 미래를 예측하지 못한다. 그렇기 때문에 우리는 지속적이고 작은 피드백 루프를 통해 사용자가 더 성공할 수 있도록 돕는 능력을 강화해야 한다. 피드백 루프 (배포-감지-응답)를 통해 사업을 기민(Agile)하게 운영하는 것이 중요한 이유는, 애자일(Agile, 기민한) 사업은 방향 전환을 신속하게 할 수 있다. 그 결과, 어떤 상황에서도 생존할 수 있다. 사례: 미국의 모 증류주 회사에서는 이미 보유한 알콜을 사용하여 소독제를 만들어서 무상 배포하고 있다. (기사 보기) 예전에 성공한 방식이나 기존의 유명 브랜드가 계속 성공할 것이라는 보장을 할 수 없는 세상이 되었다. 새 기능을 잔뜩 만들고 마케팅 예산을 많이 투입해도 성공한다는 확신이 없는 세상이 되었다. 사례: 퀴비(Quibi)의 화려한 출발과 6개월만의 몰락 이 모바일 전용 온라인 동영상 서비스는 영화사와 유명 테크 기업의 유능한 임원들이 모여 막대한 자금을 투자하고도 6개월만에 문을 닫았다. (기사 보기) 사소한 기능이 (긍정적이든 부정적이든) 예상치 못한 엄청난 결과를 초래할 수도 한다. 따라서, 우리는 우리가 실제로 세상에 끼치는 결과(Outcome)를 측정하는 것에 집중해야 한다. (세상에 끼치는 결과에 대한 고려가 없이) 무작정 개선하면 위험을 자초한다. 최악의 경우 범죄가 되기도 한다. 사례1: 참여(Engagement)라는 이름 하에 반인륜적 범죄에 도움이 되기도 한다. 페이스북은 월 활성 사용자수(MAU)와 일 활성 사용자수(DAU) 라는 개념을 전세계에 확산했다. 이 두가지 지표에만 집중한다. 이 지표만 높일 수 있으면, 사용자들이 실제로 무슨 일을 하건 (학살을 장려하건, 정치 선동을 하건) 신경쓰지 않는다. 페이스북은 미얀마에서 로힝야족의 위치를 찾고 학살하는데 활용되었다. (기사 보기) 페이스북은 정치인들이 사회적 기준을 위반하는 발언을 페이스북에 올리는 것을 금지하지 않기로 했다. (트위터 보기) 유튜브는 사용자가 동영상을 보면 같은 내용을 담은 동영상 50개를 목록에 보여준다. 유튜브는 사용자가 무엇을 보는 지에는 관심이 없고, 얼마나 많이 보는가에만 집중하고 더 많이 보도록 노력한다. 예를 들어, 백인 우월주의 청년이 유튜브를 보다보면 점점 더 확신에 빠지고, 테러까지 하게 되는 결과로 이어질 수 있다. 머신러닝과 AI의 도덕적 해이의 사례: 어떤 대상에 대해서도 강력하게 최적화된 알고리즘을 만들 수 있지만, 그 어느 알고리즘도 그것이 최적화할 가치 있는 대상인지에 대해서 말하지 않는다. (트위터 보기, "유튜브 인공지능 Reinforce은 사용자가 훨씬 더 많은 동영상을 보도록 하는데 성공했다") 사례2: “판매”라는 이름 하에 인간 관계 문제를 만들기도 한다. 소매점은 데이터 마이닝(Data Mining)을 통해 판매 흐름을 최적화하고 고객의 니즈를 예측하는 능력을 강화하기를 원한다. 타겟(미국의 소매점)은 여기에 매우 능하다. 고객이 어디에서 무엇을 샀는지, 매장을 방문하는지 온라인 쇼핑을 하는지 등을 파악하고 그 정보를 활용한다. 심지어 고객의 임신유무도 알고 임신/출산용품 관련 할인 쿠폰을 보내기도 한다. 타겟은 한 여고생이 임신한 사실을 파악하고, 그 소녀가 부모에게 직접 말하기도 전에, 부모에게 알렸다. (기사 보기: "타겟은 어떻게 한 10대 소녀가 임신한 사실을 아버지보다도 먼저 알았을까?") 사례3: “효율성”이라는 이름 하에 성차별이 발생할 수 있다. 아마존은 지원자의 이력서를 효율적으로 처리하기 위해 AI를 적용했다. 이 AI에는 편향된 알고리즘이 들어 있었다. Women's라는 단어가 들어 있으면 감점을 했는데 그 결과 여대를 졸업한 지원자 모두에게 감점이 반영되었다. 아마존은 곧 이 문제를 수정했다. 아마존은 AI를 통해 효율성을 높였지만, 실제 결과는 차별이 발생했다. (기사 보기) 우리는 이 사례를 통해 Outcome에 집중해야 한다는 점을 배울 수 있다. 사례4: “편리함”이라는 이름 하에 - 사람을 위협할 수도 있다. (온도 조절기, 잠금 장치, 조명 등) 스마트홈 기술은 정말 편리하다. 스마트홈 기술을 이용하여 헤어진 배우자를 위협하는 사람들도 있다. (기사 보기) 우리의 사업 성공의 척도에는 사람들이 어떻게 사용하는 가? 나쁜 용도로 사용되지는 않는가? 등의 Outcome이 들어가야 한다. 사례5: “뉴스”라는 이름 하에 - 우리에게 가장 나쁜 것들을 전한다. 뉴스를 예로 들면, 일상적이지 않은 가장 나쁜 사건을 널리 전한다. 우리가 고객의 니즈를 해소해주던지, 오히려 망치던지, 두 경우 모두 매출이 발생한다. 우리는 피드백 루프를 반복하면서, 매출 뿐만 아니라 우리가 실제로 제공하는 가치에 대해 끊임없이 살펴야 한다. 이것은 최고경영진 이슈다. (Alan Pao, Wired 기고 보기) SNS 회사와 임원들은 사용자들이 얼마나 많고 얼마나 참여하는 지에 따라 보상을 받는다. 이들은 긍정적인 영향을 미치는지, 위험 요소로부터 보호하는지 등에는 신경쓰지 않게 된다. 소프트웨어 사업자/설계자/개발자는 Outcome을 잘 살펴야 한다. 하지만, 개발자들 대부분의 대답은 "난 제품 책임자를 믿어요”: 제품 책임자를 믿는 것은 좋지만, 검증하라! 지금 만들고 있는 것이 전략에 맞는지, 왜 만드는지, 어떻게 돈을 벌 것인지를 질문하자. 만약 책임자도 잘 모른다면 함께 대답을 찾자. “난 그저 코드를 작성하고 싶어요. 고객이나, Outcome 같은 것은 신경쓰기 싫어요”: 20-30년 전만해도 작성된 코드는 전문 기술자들에게만 영향을 끼쳤다. 하지만, 이제는 너무나 많은 사람들에게 영향을 끼친다. 이제는 더이상 그냥 코드만 작성하는 것만 즐기는 시대가 아니다. 사람을 존중하는 결과를 가져오는지도 고려해야 한다. 당신의 코드가 무엇을 하는 데 사용되는 지에 대해 책임을 져야 한다. "새로운 기술은 기본적으로, (더 넓은 사회의 윤리적 흔적이 아니라) 그 기술을 만든 사람의 윤리적 흔적을 담고 있다." - Cennydd, ‘Future Ethics’ 폭스바겐의 소프트웨어 엔지니어가 디젤 엔진 조작으로 징역 4년형을 받았다. (기사 보기) 그는 자신이 만든 소프트웨어의 사용자가 좋은 의도로 사용할 것이라고 생각하지는 않았을 것이다. 그리고 감옥에 갔다. 폭스바겐 CEO는 감옥에 가지 않았다. 어떤 개발자는 사표를 내기도 한다 (기사보기: 페이스북 엔지니어 또 한명이 역겨움에 회사를 그만두었다. 페이스북은 역사상 잘못된 편에 서있는 회사라고 말했다.) 고객 중심적인 피드백 루프 (배포-감지-응답)을 바탕으로 훌륭한 UX를 만드는 방법 "목표를 향하고, 가치를 통해 길을 잡고, 두가지 모두 측정하라" - Kim Goodwin 목표(Goal): 실제 결과(Outcome)와 그 측정 지표 가치(Value): 목표 때문에 희생하고 싶지는 않은 것들 측정: 목표와 가치를 각각 명확히 하고, 이 둘 간의 경계도 명확히 하자. 경계가 침범되면 의견을 제시하자. 우리가 무엇을 할 수 있을까? (당신의 사업 모델 즉 회사가 어떻게 돈을 버는 지를) 이해하라. 예) 수집된 데이터는 어떻게 수익에 기여하는가? (고객 안에 들어 있는) 관심을 파악하라. 예) 고객은 무엇을 하려고 하는가? 고객이 그 목적을 이루고 있는가? 새로운 행동을 하고 있는가? (고객의 행동을 인지하기 위해) 당신이 만들고 있는 소프트웨어를 직접 사용하라. (당신의 일이 끼치는 영향을) 측정하라. (어쩌다 발생할 수 있는 위험에 대해) 논의하라. (사람에게 위해한 일은) 거부하라. “너희 과학자들은 자신들이 할 수 있는가 아닌가에만 빠져서 멈춰서서 하는 것이 옳은가 아닌가를 생각하지 않았어.” - 영화 쥬라기공원 중에서 << UX Summit 으로 이동 View full 아티클
  25. << UX Summit 2020 목록으로 이동 UX Summit 의 2020 시리즈 중, Mobile Second: When to Focus on Desktop First - Paul Shustak 의 한글 요약본입니다. 발표자 (Paul Shustak)는 20년 경력의 소프트웨어 제품 관리와 설계 전문가 입니다. 마이크로소프트, 어도비 등 큰 기업과 창업 등을 거쳤고, 지금은 최초의 길거리 예술 온라인 시장 플랫폼인 Beautify Earth 제품의 총 책임자입니다. 이 요약에 미처 담지 못한 좋은 내용은 원본을 보세요: YouTube 비디오 (10 min) 보기 이 세션에서는 다음 주제를 다룹니다. 소프트웨어 시장 진출시, 모바일과 데스크탑 중 “내 상황에서는” 무엇부터 시작하는 것이 좋은지 판단하는 방법 “발표자의 상황에서는” 왜 데스트탑으로 시작하는 것이 유리했고 어떤 장점이 있었는지 사례를 공유 Karen.care 치매 환자의 삶과 재정, 건강, 법률 문제를 가족들이 함께 종합적으로 돌볼 수 있도록 돕는 소프트웨어 서비스를 최초로 제공한 스타트업이다. 데스크톱부터 먼저 시작했고, 성공 후 네이티브 모바일로도 확대했다. Karen.care 사용자의 작업흐름 3단계 가입 설문 참여: 돌봄 대상 정보, 재정 상황, 스트레스 수준 등 활동 목록 도출과 계획 수립: 알고리즘을 통해 설문 내용에 기반한 알맞은 가이드가 제시된다. 사용자는 이 가이드를 이용해 활동 목록을 검토하고 확정한다. 돌봄 활동을 함께 수행: 각자에게 할당된 활동을 수행한다. 전문가가 함께 참여할 수도 있다. (일종의 프로젝트 관리 방식) 스타트업으로서 Karen.care가 정한 제품 출시 원칙 3가지 최소 비용으로 구축: 시장 기대 수준에 도달하기까지 반복 개발을 얼마나 해야할지 모르니까 최대한 아끼자. 최단 시간에 반복: 초기에는 지식이 부족하다. 시간 역시 중요한 요소이므로 빠르고 빈번하게 향상시키자. 데이터 기반 의사 결정: 잘못된 결정으로 인한 낭비가 없도록 의사 결정 전에 데이터로 검증하자. 소프트웨어 개발에 대한 일반적인 의견 모바일부터 먼저 설계하라. 그렇지 않으면 모바일 UX가 나빠진다. 모바일 앱이 가장 중요하다. 우리의 의견 장기적으로는 어느 시점 이후에 모바일이 매우 중요해질 것이다. 하지만, 데스크톱만 먼저 시작하자. 데스크톱 앱으로 고객의 니즈를 충족한 후에 모바일 앱을 개발하면 모바일 앱 개발에만 집중하기가 더 좋다. Karen.care가 시장에 안착한 과정 - 데스크톱으로 시작부터 네이티브 모바일 앱 추가까지 1단계: 고객 파악: 인터뷰, 설문을 통해 잠재 고객의 고충과 해소 방안을 파악 3가지 기본 개념 검증: 알고리즘을 통한 돌봄 활동 목록 추천, 돌봄 활동을 함께 수행할 수 있도록 지원, 전문가 조언 연결 하지만, 사용자의 작업흐름과 사용법을 구현하려면 여전히 많은 질문을 던지고 피드백을 반영해야 했다. PoC (Proof of Concept)와 알고리즘 검증을 가능한 신속하게 반복하면서 점차 명확해졌다. 그 결과, 신속하게 반복하려면 데스크톱 하나만 집중하는 것이 옳다고 판단하였다. 2단계: 가설과 검증: 고객 파악 결과와 시장 데이터를 활용하여 검증 목표 고객 40~50대가 주목표고객 (틱톡, 인스타 등 모바일이 필수인 Z세대는 2차 고객) 모바일 앱은 초기 사업에서 필수가 아니라고 판단했다. 사용 패턴 Karen.care는 크게 계획 모드와 일상관리 모드로 사용되었다. 계획 모드에서는 사용자가 전략적인 생각을 해야했고, 시간도 많이 걸렸다. 오랫동안 사용하고 생각하기에는 데스크톱이 더 알맞다고 판단했다. 돌봄은 24x7 활동 돌봄 상황에서 사용자는 주로 컴퓨터 또는 노트북을 사용한다. 누워서 잠시 모바일로 사용하는 용도가 아니므로 모바일을 우선할 필요가 없다고 판단했다. 반응형 모바일 웹으로도 충분 GPS, 자이로스코프 등 스마트폰에 내장된 장비를 사용할 필요가 없다. 모바일은 네이티브 앱까지는 필요없고, 반응형 모바일 웹만으로도 충분하다고 판단했다. 다양한 운영체제(OS)를 사용 가족들은 서로 다른 운영체제를 사용한다. 네이티브 앱으로 제공하려면 각 플랫폼별로 프로그램을 따로 만들어야 한다. 비싸고 시간이 많이 든다. 데스크톱 웹으로만 시작하기로 결정했다. 3단계: 반복을 통한 개선과 사용자 피드백 반영 충분한 반복 후 우리가 만든 상품이 시장에 맞아들어가는 조짐을 보았다. 데스크톱으로만 먼저 시작한 것이 빠르게 시장에 안착하기에 옳았다는 것이 검증되었다. 4단계: 모바일 앱 추가 반응형 웹으로 모바일 서비스를 하면서 모바일 사용자로부터 충분한 의견을 받았다. 모바일 앱 착수 전에 이미 사용자에 대한 충분한 지식과 우리의 설계에 대해 자신이 생겼다. 이를 기반으로, 모바일 앱 개발에 착수했다. 앱의 기능과 작업흐름, 사용 방식에 대해 내부 토의가 많이 필요하고 쉽지 않았지만, 데스크톱 구현을 통해 확보한 노하우는 네이티브 앱을 만들 때 훨씬 더 쉽고 자신있게 결단하는데 큰 도움이 되었다. 데스크톱 우선 개발의 장점 더 빠르게 훨씬 적은 비용으로 반복 개발 웹 개발이 네이티브 앱 개발보다 훨씬 빠르고 저렴하다. 더 쉽게 사용, 더 쉽게 접근 웹에서 바로 사용하는 것이 앱스토어로 가서 다운로드 받아서 쓰기보다 간편하다. 다양한 운영체제 커버 다양한 운영체제에서 작동하려면 웹 애플리케이션이 각 플랫폼별로 네이티브 앱을 만드는 것보다 더 쉽다. SEO(검색 엔진 최적화) 더 많은 고객에게 노출 (네이티브 모바일 앱으로는 쉽지 않다.) SEO는 페이지에 태그를 정확히 달고 활용한다. 더 많은 사용자 확보, 더 빠른 의견 수렴을 통해 사업화 하기 좋다. 데스크톱으로 시작할 지 모바일로 시작하기에 알맞은 것인지를 파악하는 5가지 질문 사용자가 2/3가 넘는 시간을 모바일에서 시간을 보내는가? 처음 또는 두 번째 버전만으로 훌륭한 UX를 사용자에게 제공할 수 있는가? 핵심 기능 중 네이티브 모바일 앱이 반드시 있어야 가능한 것이 있는가? 네이티브 안드로이드와 네이티브 iOS앱이 반드시 있어야 시장에 안착할 수 있는가? 반복과 버전 향상을 충분히 할 수 있는 환경인가? 모두 NO 라면: 데스크톱을 먼저 고려 하나라도 YES 라면: 모바일을 먼저 고려 그림 1. Decision Tree << UX Summit 2020 목록으로 이동 View full 아티클
×
×
  • Create New...

중요한 정보

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