2020 년 3 월 30 일, 직원들은 스택 오버플로에서 베타 다크 모드를 선택할 수 있었습니다. 그 작업에 대해 이야기 해 봅시다.

저는 디자인 시스템 분야의 Stack Overflow 수석 제품 디자이너 인 Aaron Shekey입니다. 새로운 기능으로 조립되는 모든 인터페이스 구성 요소를 디자인하는 데 도움을 줍니다.

첫째, 약간의 아이러니. 저는 실제로 어두운 사용자 인터페이스를 선호하지 않습니다.

사용 가능한 대비가 너무 낮은 경우가 많습니다. 다양한 색상을 사용하여 인터페이스를 표현하기는 어렵습니다. 그림자 및 기타 시각적 신호로 깊이를 도입하기가 더 어렵습니다. 어두운 배경의 밝은 텍스트가 눈에 피로합니다. 동시 대비와 같이 밝은 화면에서 관리하기 어려운 것은 어두운 배경에서 관리하기가 훨씬 어렵습니다.

그러나 여기에 마침내 Stack Overflow에서 다크 모드를 선적 한 사람이 있습니다.

제가 이야기 하려고 하는 작업은 셀 수없이 많은 사용자가 요청했지만 암흑 모드에 관한 것이 아닙니다. Stack Overflow는 다크 모드로 가는 모든 것을 해결함으로써 프론트 엔드 코드베이스를 현대화하고 접근성에 민감한 테마를 가능하게 하며 디자인 시스템의 채택을 추진할 것입니다. 

사용자에게 어두운 모드를 제공하고 향후 접근성 모드를 무료로 제공 할 수 있습니까?

https://stackoverflow.blog/2020/03/31/building-dark-mode-on-stack-overflow/ 

색 탐험 

제품의 원래 색상 스케일을 만들 때 아마도 순진하게도 단일 색상 값을 가져와 적은 색상 변환을 사용하여 수정했습니다. 예를 들어 Less 변수를 @red로 정의하고 darken (@red, 10 %)을 사용하여 몇 번 10 % 어둡게 합니다. 그런 다음 스펙트럼의 다른 쪽 끝에서 몇 번 색조 (@ 빨간색, 10 %)를 밝게 하는 색조를 나타 냈습니다. 이로 인해 우리는 @ red-050에서 @ red-900으로 10 % 간격으로 표시되는 컬러 스케일로 이어질 것입니다.

어두운 모드에서 스택 오버플로가 어떻게 보일지에 대한 첫 번째 탐구에서 흰색 배경을 검은 색으로 바꾸고 색상 스케일을 반대로 바꾸는 것을 테스트하고 싶었습니다. 이 방법을 사용하면 @ red-050이 @ red-900이 되어 중간 값이 거의 동일하게 유지됩니다.

이 접근 방식은 모든 것을 사용할 수 없는 대비로 만들었고, 어두운 모드에 대해 내가 싫어하는 것의 함정에 빠졌습니다. 검정색 배경에 대해 가장 어두운 빨간색 값에 주의를 기울이십시오. 거의 구별 할 수 없습니다. 나중에 더 자세히.

우리는 이것보다 더 잘해야 할 것입니다

모형으로 시작 

기술적으로 다이빙을 잘못한 것으로 판명 된 후, 나는 대신 피그마 (Figma)의 디자인 툴에서 색상을 직접 선택했습니다. 원래 색상 값이 어떻게 매핑되는지에 대해 걱정하지 않고 Stack Overflow가 어떻게 보일지 디자인 할 수 있습니다. 

인터페이스의 깊이를 유지하기 위해 전체 대비를 줄이는 것이 중요했습니다. 요소가 그림자를 드리우고 전체 색상 스펙트럼을 표시 할 수 있었습니다.

모형을 시작으로 기술적 요구 사항에 관계없이 미적 목표를 먼저 정의 할 수 있었습니다.

더 나은 알고리즘 선택 

어두운 모드를 위해 더 밝은 배경을 선택한 후 더 깊은 방식으로 컬러 스케일을 탐색 할 수 있습니다. 먼저, 디자인 시스템이 조명 모드에서 상속 한 일부 색상 문제를 해결해야 했습니다. 스펙트럼의 빛 끝에서 우리의 빨간색과 노란색은 내가 원하는 만큼 사용할 수 없었습니다. 일부 색상의 경우 가장 밝은 값이 흰색에 너무 가까운 반면 다른 색상의 경우 가장 어두운 값이 너무 어둡습니다.

원래 가장 밝은 노란색은 흰색과 구분할 수 없었고 가장 어두운 노란색은 검은 색과 구분할 수 없었습니다.

우리는 각 색상에 대한 스펙트럼의 어두운 끝에서 문제가 발생했습니다. @ red-900 및 @ blue-900을 배경에 적용 할 때 이러한 색상은 검은 색과 서로 구분할 수 없었습니다. 

가장 밝은 값과 가장 어두운 값에서 여전히 기본 색조로 읽히는 색상을 제공하는 알고리즘을 필요로 하여 이러한 색상 값으로 구성 요소를 만들 수 있었습니다.

우리 색의 가장 어두운 값은 서로 구분할 수 없었고 검은 색이었습니다.

알림 구성 요소를 만들 때 디자인 시스템의 색상을 사용할 수 없었습니다. 대신, 우리는 커스텀 컬러를 안구해야 했습니다.

스펙트럼의 빛 끝에서 색상 값을 정규화 한 후 색상 스케일 내의 값을 사용하여 알림 구성 요소를 만들 수 있습니다.

어두운 버전 

밝은 버전을 다듬으면 이제 어두운 배경에서 이 색을 탐색 할 수 있습니다. 궁극적으로 알고리즘의 출력을 수동으로 조정하여 오랫동안 사용 된 브랜드 색상을 특정 값으로 유지합니다. 이렇게 하면 너무 교대하지 않고도 새로운 색상을 프로덕션 환경에 적용 할 수 있습니다.

완전 정규화 된 색 영역

스택에 색상 추가 

다크 모드를 Stack Overflow로 배송 할 희망이 있다면 먼저 디자인 시스템 인 Stacks를 샌드 박스로 사용하여 다크 모드를 해결해야 합니다.

변수 

컴파일 되지 않은 정적 16 진수 값을 런타임 사용자 정의 CSS 속성으로 변환해야 했습니다. 이것은 정적 @ red-500 대신 var (-red-500)으로 색상 값을 저장하는 것을 의미했습니다. 이것은 디자인 시스템과 사이트에서 흥미로운 문제였습니다. 우리는 일반적으로 @ red-500과 같은 단일 색상 값을 가져 와서 호버 및 초점 상태와 배경 및 테두리 색상과 같은 것을 밝게 또는 어둡게 합니다.

여러 버튼과 개별 상태는 각각 컴파일 된 단일 색상 값의 변환 세트를 기반으로 했습니다. 빅 쇼트에서 이 장면을 떠올리게 했습니다. "원래 1 천만 달러 투자를 수십억 달러로 전환 할 수 있습니다."물론 모든 것이 폭발합니다.

기본 CSS 변수의 문제점은 어떤 유형의 Less 변환도 적용 할 수 없다는 것입니다. CSS 변수는 런타임에만 평가되므로 darken (var (-red-500), 5 %)은 컴파일러를 중단 시킵니다.

이것은 모든 버튼이 어떻게 만들어 졌는지 리팩토링해야한다는 것을 의미했습니다. 나는 다음에서 옮길 것이다 :

.s-btn {
    color: @white;
    background-color: @blue-600;
    border: 1px solid darken(@blue-600, 5%);
    
    &:hover {
        background-color: darken(@blue-600, 5%);
        border-color: darken(@blue-600, 10%);
    }
}

색상 시스템에서 정의한 대로 보다 명확한 색상 값으로 변환해야 했습니다. 대신, 다음과 같이 보입니다.

.s-btn {
    color: var(--white);
    background-color: var(--blue-600);
    border: 1px solid var(--blue-700);
    
    &:hover {
        background-color: var(--blue-700);
        border-color: var(--blue-800);
    }
}

버튼 뿐만 아니라 모든 스택 구성 요소 에서 이 작업을 수행해야 했습니다. 이러한 동일한 개념은 공지, 팝 오버, 모달, 버튼 및 링크에 적용됩니다.

브라우저 호환성 

아, 잠깐만 기다려 CSS 변수는 Internet Explorer 11에서 지원되지 않습니다. Internet Explorer 11은이 탐색 당시에 많이 지원 한 브라우저입니다. 

궁극적으로, 우리는 IE11에 대한 지원을 중단하고 수년 동안 추가 한 모든 CSS 해킹을 제거하고 IE11 사용자에게 사용 중단 알림을 발송하여 새로운 브라우저를 설치하도록 촉구했습니다. 

이것은 우리가 가볍게 결정한 결정이 아니며,이 전제 조건만으로 몇 주 동안의 리팩토링이 필요했습니다.

조건부 클래스 

IE11이 더 이상 우리를 방해하지 않으면 서 스택 내에서 색상을 사용할 수 있었습니다. .theme-system 클래스를 body 요소에 추가 할 수 있도록 선택했습니다. 그렇게 하기 위해, 우리는 어두운 모드 미디어 쿼리 뒤에 어두운 색상으로 밝은 색상을 바꿨습니다. 

또한 미디어 쿼리를 완전히 건너 뛰고 본문에 .theme-dark를 추가하여 어두운 색상을 강제로 지정할 수 있습니다. 이를 통해 사용자는 시스템 설정에 관계없이 어두운 모드를 볼 수 있습니다. 

내 접근 방식은 다음과 같이 끝났습니다.

body {
    --red-600: #c02d2e;
}

body.theme-system {
    @media (prefers-color-scheme: dark) {
        --red-600: #d25d5d;
    }
}

body.theme-dark {
    --red-600: #d25d5d;
}

완벽한 유연성을 제공하기 위해 Stacks는 어두운 모드가 활성화 된 경우에만 적용되는 원 자색 클래스를 제공합니다. 

내 개인 포트폴리오에서 스택 CSS 디자인 선택에 대해 읽을 수 있습니다. .d : bg-green-100을 요소에 추가함으로써 엔지니어와 디자이너는 "어두운 모드에서 녹색 100의 배경을 적용합니다"라고 말할 수 있습니다. 

추가 조건부 클래스를 사용하면 어두운 모드에서 테두리를 삭제하거나 배경을 바꾸거나 텍스트 색상을 변경할 수 있습니다. Steve Schoger는 어두운 모드에서 때때로 필요한 사용자 정의를 보여주는 멋진 트윗을 받았습니다. 

Tailwind에서 많은 영감을 얻었습니다.

Documenting it 

Stacks가 자체 어두운 모드를 제공 할 위치에 있을 때 사이트 상단에 버튼을 추가하여 빠르게 전환 할 수 있었습니다. 설계 및 엔지니어링 담당자는 가능한 한 빨리 두보기를 전환 할 수 있어야 합니다.

스택 오버플로에 색상 추가 

디자인 시스템 측면에서 이러한 모든 색상 문제를 비교적 쉽게 해결했습니다. 우리의 디자인 시스템은 과거의 실수를 거의받지 않았기 때문에 새로운 미래를 염두에 두고 쉽게 리팩토링 할 수 있습니다. 

스택 오버플로로 배송하려면 이전 버전과의 호환성을 위해 원래의 적은 변수를 유지해야 했습니다. 

이를 통해 인터페이스의 특정 부분에서 점차 어두운 모드를 활성화 할 수 있었습니다.

2018 년 이후에 구축 된 대부분의 인터페이스는 스택을 사용하므로 어두운 모드와 반응 형 레이아웃이 무료로 제공됩니다. 그러나 우리 사이트의 대부분? 별로.

Site chrome 

먼저 Stack Overflow의 기본 라이트 모드를 방해하지 않으면 서 최대한 크게 변경해야 합니다. 이러한 작업은 주로 사이트 전체에서 정적 변수를 CSS 변수로 대체하는 것입니다. 

사이트의 배경에 background-color : var (-white)를 먼저 적용하고 background-color : @white을 바꿨습니다. 이것은 이제 대부분의 페이지를 적절하게 뒤집습니다. 그런 다음 글꼴 색으로 이 작업을 수행했습니다. 

헹구고 반복하십시오. 대부분 부모로부터 상속 받을 수 있을 때 자식 요소의 글꼴 색상을 과도하게 지정했기 때문에 이는 실제로 많은 CSS를 삭제하는 것을 의미했습니다.

Staff shipping 

폭 넓은 스트로크를 밟으면 엔지니어 인 Adam Lear와 Nick Craver에게 의존하여 어두운 모드의 미리보기를 Stack Overflow 직원에게 제공하는 방법을 제공했습니다. 

이를 통해 직원들은 매우 어둡게 깨진 어두운 모드를 선택하여 사람들이 얼마나 많은 전환이 남아 있는지 확인할 수 있지만 사이트의 일부를 가장 많은 트래픽으로 수정하도록 동기를 부여 할 수 있기를 바랍니다. 

이를 통해 사이트의 가장 큰 장벽 인 기존 코드베이스를 수정할 수 있습니다.

Buttons 

작업 중인 뷰가 이미 스택으로 빌드 된 경우 어두운 모드를 수정하기 위해 해야 ​​할 일은 없습니다. 실제로 테두리가 필요하지 않거나 배경에 약간 다른 회색 음영을 선택하려고 할 수 있습니다. 

안타깝게도 대부분의 사이트에서 여전히 스택에 의존하지 않았습니다.

이것이 우리 버튼에 올 때 가장 분명했습니다. 수년에 걸쳐 우리는 다양한 버튼을 구현했습니다. 마지막은 스타일링을 위해 버튼 요소 자체를 대상으로 한 이후 가장 실망스러운 결과였습니다. 

즉, 사이트의 모든 버튼 또는 입력 유형 = "button"은 더 이상 사용되지 않는 스타일 세트에서 기본 슈퍼 스타일이 적용됩니다.

이로 인해 CSS의 버튼에 대한 요소 레벨 참조를 삭제하는 대신 큰 스택 리 팩터를 사용하는 대신 스택과 동등한 것으로 대체했습니다. 

예를 들어, 수백 개의 입력 유형 = "submit"을 <button type = "submit"class = "s-btn s-btn__primary">로 바꿔야 합니다. 문제를 복잡하게 하기 위해 JavaScript 인터랙티브를 이러한 시각적 선택기에 연결하는 경우가 종종 있었습니다. 

비주얼 클래스를 변경하면 버튼이 실제로 한 일을 종종 깨뜨렸습니다. 수천 개의 버튼에서 먼저 js 특정 클래스를 추가하고 연결 한 다음 이전 비주얼을 제거해야 했습니다.

결과적으로 대부분의 레거시 버튼 클래스를 삭제하여 어두운 모드가 활성화되었을 때 버튼이 사이트의 라이트 모드로 거의 회귀하지 않고 색상을 올바르게 전환 할 수 있게 되었습니다.

The site header 

사이트 전체 헤더에는 여러 가지 모드가 있습니다. 밝고 어둡고 테마. 팀과 네트워크 사이트 모두 헤더가 어둡게 나타납니다. 또한 Google 팀에는 팀의 아바타 색상으로 설정된 색상 막대가 있습니다. 

많은 구성 요소와 마찬가지로 사이트 헤더의 CSS는 단일 색상을 사용하여 밝거나 어두운 지 측정 한 다음 복잡한 Less 함수 집합을 통해 해당 색상을 변경했습니다. 그러나 우리는 이것을 디자인 시스템에서 했던 것처럼 이것을 제거하고 미리 구운 CSS 변수로 대체 할 수 없었습니다. 실제로 엔터프라이즈 클라이언트는 단일 색상을 사용하여 모든 사용자 정의 재정의를 생성하여 헤더 전체를 테마로 합니다.

Light header

Dark header

Team header

스택 오버플로에 제공되는 라이트 헤더의 경우 색상이 CSS 변수인지 또는 정적 16 진수 값인지 측정하는 솔루션을 찾아야 했습니다. CSS 변수 인 경우 Less 변환을 완전히 건너 뛰고 어두운 모드를 기반으로 색상을 바꿀 헤더를 만듭니다. 정적 Less 변수를 대신 전달하면 해당 색상의 명암을 측정하고 적절한 헤더를 만듭니다.

우리의 접근 방식은 다음과 같습니다.

 & when ( iscolor(@theme-topbar-background-color) ) {
     @theme-topbar-style: if(luma(@theme-topbar-background-color) >= 50%, light, dark);
 }
 & when not ( iscolor(@theme-topbar-background-color) ) {
     @theme-topbar-style: automatic;
 }

그런 다음 자동, 밝게 또는 어둡게 기반으로 헤더를 적절하게 작성했습니다.

Tags 

구성 요소를 디자인 할 때 조언이 조금이라도 있다면 구성 요소에 레이아웃을 추가하지 마십시오. 다시 말해서, 문맥은 그들 사이의 공간이 얼마나 되는지 정의해야 합니다. 구성 요소에 굽지 마십시오. 스택 오버플로의 초기 반복에서는 태그 후 구성 요소에 외부 여백이 적용되도록 결정되었습니다. 

버튼과 마찬가지로 태그는 동일한 JS- 타겟팅 문제에 부딪쳤다. 더 복잡하게 만들기 위해 대부분의 태그는 애플리케이션에서 단일 도우미 메소드를 사용하여 생성되었습니다.

태그를 리팩토링 한다는 것은 새로운 테마 인식 S- 태그 구성 요소의 포스트 태그 교환을 의미합니다. 

또한 적절한 곳에 js-tag를 타겟팅 하기 위해 JS를 리팩터링 해야 합니다. 또한 임의의 레이아웃 클래스를 허용하도록 태그 생성기 메소드를 변경해야 합니다. 특정 상황에서는 사전에 구운 마진에 의존하지 않고 태그를 유연한 레이아웃으로 래핑 해야 할 수도 있습니다.

Post styling 

스택 오버플로의 대부분은 사용자 생성 게시물입니다. 이 게시물은 Markdown을 원래 질문 본문과 답변 및 의견으로 표시합니다. Stack Overflow가 출시 될 당시 Markdown은 비교적 새롭습니다.

수년에 걸쳐 업계는 헤더 및 블록 따옴표와 같은 것을 표시하는 몇 가지 표준 방법을 통합했습니다. 다크 모드는 논란의 여지가 많은 인용 형식을 어떻게 처리했는지 다시 생각하기에 완벽한시기였습니다.

우리는 원래 견적 자체의 대비를 줄인 강력한 노란색 배경으로 인용구를 구현했습니다. 어두운 배경에 표시 될 때 노란색도 문제가 되었습니다. 궁극적으로 블록 따옴표를 나타내기 위해 업계 표준 단일 회색 막대로 전환했습니다.

Code styling 

스택 오버플로의 경우 표시 할 코드가 매우 많습니다. 구문 강조 표시 색상은 완전히 브랜드화 되지 않은 색상을 사용했습니다. 우리가 해킹 한 원래 구문 강조 표시 라이브러리에서 상속 받은 것 같습니다. 궁극적으로 구문 강조 표시를 다시 디자인했습니다. 대신, 기존 구문을 디자인 시스템의 값에서 색상으로 강조 표시하여 너무 큰 변화를 일으키지 않는 다크 모드와 동등한 것을 발견했습니다.

결과 

Dark mode beta’s debut on March 30, 2020

이러한 리 팩터를 사용하면 회귀를 줄이면서 더 크게 변경할 수 있습니다. 고 대비 접근성 모드를 포함하도록 색상 팔레트를 확장하는 것을 훨씬 쉽게 고려할 수 있습니다.

다크 모드와 같은 기능을 구축하는 것은 스택 오버 플로우에서 시스템 설계로 근본적으로 전환 한 결과입니다. 저는 작년에 제품의 많은 부분을 재건 할 수 있는 기회로 다크 모드를 사용하여 디자인 시스템의 채택을 추진하고 있습니다. 사용자에게 더 많은 접근성을 제공하는 많은 프로젝트 중 첫 번째입니다.

Internet Explorer 11의 지원 중단을 고려하지 않고 2019 년 7 월부터 탐색 풀 요청으로 본격적으로 어두운 모드 작업을 시작했습니다. 그 이전에는 2019 년 4 월에 다크 모드를 구축하는 데 무엇이 필요한지에 대한 공개 토론을 볼 수 있습니다. 프로덕션 코드베이스의 개념 증명은 2019 년 10 월에 해킹되었습니다. 최소 60 개의 후속 풀 요청 후 다크 모드 베타는 2020 년 3 월 30 일에 생방송 되었습니다.

조직 전체의 Adam Lear, Des Darilek, Nick Craver, Kevin Montrose, Brian Nickel, Catija, Ben Popper, Joy Liuzzo, Sara Chipps, Kristina Lustig, Jon Chan 및 Ben Kelly의 도움 덕분에 큰 도움을 받았습니다. ✌️