맥은 메뉴바로 풀었고, 그러면서 윈도우와 맥의 코드가 나뉘었습니다

처음부터 윈도우 PC에서 윈도우용으로 만들었습니다. 윈도우판을 먼저 주변 사람들에게 전달해 써 보게 하고, 쓰면서 나온 문제를 고친 뒤에 맥북에서 처음 빌드했습니다. 그때 윈도우에서는 드러나지 않던 문제가 여러 개 나왔습니다.

첫 클릭. 다른 앱을 쓰다가 위젯을 처음 누르면, 그 클릭이 위젯을 선택하는 데만 쓰이고 위젯의 버튼까지 전달되지 않았습니다. 첫 클릭이 바로 위젯에 전달되도록 창 설정을 바꿨습니다.
오른쪽 클릭 메뉴와 입력 창. 아예 뜨지 않았습니다. 맥에서는 창이 화면에 나타나기 전에는 그 안의 내용을 보여 주지 않는데, 윈도우에는 이런 제한이 없어서 드러나지 않았습니다. 창을 먼저 띄우고 그다음에 내용을 보여 주는 순서로 바꿨습니다.
브라우저에서 끌어온 링크. 브라우저의 주소를 위젯 위로 끌어다 놓으면, 기본 방식으로는 파일 경로만 받고 링크는 받지 못했습니다. 끌어다 놓는 순간 맥이 끌어온 내용을 담아 두는 곳을 직접 열어 링크를 읽게 했습니다.
고치지 못한 것. Dock(맥 화면 아래의 앱 모음)에 있는 앱 아이콘을 위젯으로 끌어다 놓는 것은 되지 않습니다. 맥이 위젯 창을 놓을 수 있는 곳으로 알아보지 못합니다. 파인더(맥의 파일 탐색기)에서 끌어다 놓거나 주소를 직접 입력해야 합니다.

맥 조사에서 나온 가장 큰 발견

윈도우에서 Peekle이 성립한 이유는 작업 표시줄이 창을 많이 띄우면 고정 항목이 밀리기 때문이었습니다. 맥의 Dock은 고정한 앱이 밀리지 않습니다. 다섯 칸에 바로가기를 고정하는 기본 기능은 맥에서 Dock이 이미 더 잘합니다. 그대로 옮기면 Dock 옆에 Dock을 하나 더 두는 물건이 됩니다.

Dock이 못 하는 것은 세 가지였습니다.

여러 개를 한 번에 열기
웹 주소를 바로 담기
아이콘 하나에 여러 개를 묶기

맥에서 Peekle이 쓸모 있는 것은 이 셋뿐이라고 정리했습니다. 이 결론이 맥에서는 메뉴바 방식으로 가는 판단으로 이어졌습니다.

모르고 진행할 때와 알고 진행할 때

이전조사 전에는 윈도우에서 성립한 문제 정의를 그대로 두고 윈도우판을 맥으로 옮기는 것으로 시작했습니다. 소개에 쓸 용어도 짐작으로 골랐습니다.

지금조사 후에는 맥에서 Dock이 이미 더 잘하는 일은 빼고, Dock이 못 하는 세 가지에 집중하는 방향으로 바꿨습니다. 소개에 쓸 키워드는 검색 조사로 다시 골랐습니다.

모르고 옮겼다면 맥에는 Dock 옆에 Dock이 하나 더 생겼을 것입니다. 알고 나서는 맥에서 무엇을 가져가고 무엇을 버릴지 먼저 정할 수 있었습니다.

모양을 바꿨습니다

이전맥에서도 윈도우와 같은 가장자리 위젯이었습니다.

지금1.1.0부터 처음 설치한 맥은 메뉴바 아이콘 아래에 목록으로 뜹니다. ⌥Space로 열고, 파일을 아이콘 위로 끌어 멈추면 목록이 열립니다. 점 세 개 메뉴에서 가장자리 방식으로 바꿀 수 있습니다.

맥 메뉴바의 Peekle 아래에 열린 목록. 앱, 묶음, 웹 주소가 줄로 나열되어 있다

맥의 사용성을 살피다가, 윈도우처럼 오른쪽 클릭 메뉴에 기능을 두는 방식으로는 풀 수 없다는 것을 알게 됐습니다. 오른쪽 클릭이 윈도우만큼 널리 쓰이지 않기 때문입니다. 그래서 맥에서는 우클릭에 기대지 않는 다른 길로 풀었습니다. 메뉴바 아이콘 아래 목록이 그 답이고, 설정으로 가는 길도 메뉴바에 하나 더 두었습니다.

맥에서는 Safari 탭과 파인더 폴더를 목록에 보여 주려고 첫 실행 때 다른 앱을 조작해도 되는지 허락을 요청합니다. 허락하지 않아도 나머지 기능은 그대로 씁니다.

메뉴바에는 캐릭터를 두 종만 넣었습니다

가장자리 위젯에는 캐릭터가 다섯 종 있지만, 메뉴바에는 얼룩 고양이와 엎드린 악어 두 종만 들어갑니다. 좁은 패널을 끌어안는 그림은 넓게 뜬 목록에 맞지 않기 때문입니다.

메뉴바 아이콘은 캐릭터의 머리 모양이고, 묶음을 여는 동안만 움직입니다. 메뉴바에서 저절로 움직이면 알림으로 읽히기 때문입니다.

같은 것을 OS마다 다르게 부릅니다

한국어와 영어를 지원하고 맥을 넣으면서, 같은 것을 OS와 언어마다 다르게 부른다는 것을 알았습니다. 위젯, 셸프, 트레이처럼 공식 명칭과 사람들이 실제로 떠올리는 이름이 서로 달랐습니다. 화면 문구를 그에 맞춰 많이 고쳤습니다. 파일 경로를 입력하는 칸의 예시도 윈도우는 C:\Windows\notepad.exe, 맥은 /Applications/Safari.app처럼 운영체제마다 다르게 보여 줍니다.

이전맥에서도 "컴퓨터 켤 때 자동 실행"이라고 적었고, 아이콘을 "칸"이라고 불렀습니다.

지금맥은 시스템 설정의 관례를 따라 "로그인 시 자동 실행"이라고 적습니다. 아이콘은 "아이콘"이라고 부르고, 메뉴바에서는 "줄"이라고 부릅니다.

코드가 나뉘기 시작했습니다

맥을 넣으면서 윈도우와 맥의 코드가 서로 나뉘었습니다.

플랫폼별 코드. 맥에서만 쓰는 부분은 따로 표시해 두어, 윈도우용 설치 파일을 만들 때는 들어가지 않게 했습니다. 맥 전용 파일이 따로 생겼습니다.
플랫폼별 설정 파일. 맥 전용 설정을 처음 만들 때 창 설정이 통째로 갈아 치워져서, 맥에 기본 타이틀바와 테두리가 생기고 손잡이가 가려진 일이 있었습니다.

지금 쓰는 관리 방법

윈도우와 맥의 코드는 한곳에 두고, 운영체제마다 다른 부분은 파일을 따로 두거나 만들 때 걸러내는 방식으로 나눕니다. 화면 코드는 파일 하나를 같이 쓰고, 맥에서만 달라지는 곳은 분기합니다. 설정 파일은 공통 하나와 맥용 하나를 두고, 맥용이 공통을 덮어씁니다.

공통 코드는 윈도우 PC에서 고치고 윈도우용 설치 파일을 만들어 확인합니다. 맥북에서는 그 코드를 받아 맥용 설치 파일만 만듭니다. 윈도우에서 맥용을, 맥에서 윈도우용을 만들 수 없어서 한쪽에서 고친 공통 코드가 다른 쪽에서 어긋난 일이 두 번 있었습니다. 맥 글꼴로 잡은 메뉴 크기가 윈도우 글꼴에서 잘린 일, 윈도우 트레이 코드를 확인하지 못하고 넘어간 일입니다.

이렇게 나누는 방식은 AI에게 맡겨 두었고, 제가 따로 정한 기준은 아직 없습니다.

앞으로 풀어야 할 것

지금은 공통 코드 영역과 OS별 코드 영역으로 나눠서 보고 있습니다.

설치 파일 크기와 속도. 기능이 많아질수록 빌드한 설치 파일이 커지고 느려질지 아직 확인하지 않았습니다.
관리가 어려워지는 부분. 공통 코드와 OS별 코드를 나눠 두면 어디서 관리가 어려워지는지 먼저 따져 보고 진행하려고 합니다.
스토어용 빌드. 스토어에 올릴 때는 그 OS에서 쓰는 코드만 담아야 하지 않을까 생각하고 있습니다.