흥미로운 아이디어 @melchoyce.

저의 첫 번째 반응은 그것들을 바닥으로 옮기면 어떻게 블록을 더 '뭉툭하게'만드는지였습니다. 이것은 말하기는 이상하지만 이것이 나를 느끼게하는 것입니다. 클릭 또는 마우스 오버시 테두리가 표시됩니까? 나는 그것이 마우스 오버보다 클릭시 문제가 적다고 생각합니다. 또 다른 흥미로운 비주얼은 적어도 당신의 예제를 폴라로이드 이미지처럼 보이게합니다.

그것이 저의 첫 번째 반응입니다. 조금 더 파고 들면 블록의 상호 작용 아이콘에 대해 다른 위치를 탐색하는 것이 장점이라고 생각합니다. 나는 그녀가 얻은 것은 절대적으로 모든 화면에서 더 잘 작동하는 방법이라고 생각합니다. 우리는 더 많은 탐험이 일어날 때 가이드로 유지해야합니다.

나는 우리가 상호 작용에 대해 약간의 맥락을 잃어버린 것 같아요. 예를 들어, 더 큰 자리 표시자가있는 블록에는 이러한 상호 작용이 직접 표시되지 않습니다. 검색 가능성이 낮아질 수있는 장애가 될 것 같습니다.

이 모든 것은 우리가 지금 가지고있는 것이 앞으로 나아가 야한다는 것을 절대적으로 말하는 것이 아닙니다. 반복하고 더 많은 것을 탐색하고 있습니까? 정말 그러길 바랍니다.

시각적으로 이것은 좋은 것 같아요. 기본적으로 데스크톱 중단 점의 모바일 UI이며 사이드 UI가 작동하지 않는 경우 계획 B로 간주하거나 중첩 된 컨텍스트에 대해 둘 다 고려했습니다.

그 이후로 우리는 가장 최근에 https://github.com/WordPress/gutenberg/pull/6141 에서 측면 UI로 진전을 이루 었으며 중첩 된 컨텍스트에서도 제대로 작동하도록했습니다. 측면은 여전히 ​​약간의 사랑이 필요합니다.

이 UI를 측면에 두는 것의 주요 이점은 다음과 같습니다.

1. 마우스 오버시 나타날 수 있음
2. 그들은 블록의 발자국을 확장하지 않습니다

드래그 앤 드롭이 블록 배치, 재정렬 및 ​​정렬과의 주요 상호 작용 형식이 아닌 _additive_인지 확인하는 것이 처음부터 명시적인 목표 였으므로 1은 특히 중요합니다. 블록 아래에 배치하면 아마도 클릭시 표시 될 것이므로 항상 마우스 오버시 작동하는 드래그 앤 드롭이 보조가됩니다.

2는 중첩 컨텍스트에서 사이드 UI를 처리하는 방법에 따라 중요 할 수 있습니다. 현재 우리는 https://github.com/WordPress/gutenberg/pull/5452#issuecomment -380721863에서 몇 가지 문제에 직면하고 있습니다. 물론이 문제를 해결할 수있을 것이라고 확신하지만 발자국이 변경하지 마십시오.

이 모든 것은 "작동 할 수 없다"는 말이 아니라 매우 잘 작동 할 수 있습니다. waaaay 오래된 모형에는 모서리에 오버레이로이 UI가 있습니다.

그래서 대체로, 좋은 아이디어, 그리고 우리가 릴리스하기 위해받는 피드백에 따라 탐색 할 수있는 길로 그들을 국수에 유지하는 것이 좋습니다!

클릭 또는 마우스 오버시 테두리가 표시됩니까?

클릭 만하면됩니다. Hover는 지금 작동하는 방식과 유사합니다.

반복하고 더 많은 것을 탐색하고 있습니까? 정말 그러길 바랍니다.

항상 👍

그들은 블록의 발자국을 확장하지 않습니다

네, 확실히이 아이디어의 문제입니다. 이 프로토 타입 에서도 크기 변경으로 인해 일부 점프를 볼 수 있습니다.

그래서 대체로, 좋은 아이디어, 그리고 우리가 릴리스하기 위해받는 피드백에 따라 탐색 할 수있는 길로 그들을 국수에 유지하는 것이 좋습니다!

👍 👍

나는 우리가 상호 작용에 대해 약간의 맥락을 잃어버린 것 같아요. 예를 들어, 더 큰 자리 표시자가있는 블록에는 이러한 상호 작용이 직접 표시되지 않습니다. 검색 가능성이 낮아질 수있는 장애가 될 것 같습니다.

이 UI를 측면에 두는 것의 주요 이점은 다음과 같습니다.

1. 마우스 오버시 나타날 수 있음
2. 그들은 블록의 발자국을 확장하지 않습니다

이러한 문제를 해결하는 한 가지 방법은 블록 도구 도구 모음을 아래 블록 위에 표시하고 블록이 실제로 편집기에서 차지하는 공간을 늘리지 않는 것입니다. 긴 블록의 검색 가능성에 관해서는 도구 모음이 고정되어 위로 스크롤하면 도구 모음이 화면에서 벗어나지 않습니다. (물론 블록 위로 마우스를 가져 가지 않으면 여전히 사라지고 현재 보이는 블록의 아래쪽 부분을 가리킬 때만 나타날 수 있습니다. 현재 측면 컨트롤이 작동하는 방식과 비슷합니다.) 모든 버튼을 표시하는 데 필요한만큼의 공간을 확보하고, 이번 호의 주요 게시물에있는 모형 에서처럼 두 세트의 컨트롤 사이에 빈 공간의 전체 행을 차지하지 않습니다.

+1 이것은 블록 주변의 UI 컨트롤의 탭 순서를 개선하는데도 도움이 될 수 있습니다. https://github.com/WordPress/gutenberg/issues/5694#issuecomment -386645531에서 언급했듯이 모바일 UI에는보다 논리적으로 배치 된 "사이드 컨트롤"이 있습니다. 탭 순서를 보여주는 애니메이션 GIF를 참조하십시오. 이전 주석 https://github.com/WordPress/gutenberg/issues/5694#issuecomment -384619052에서 데스크톱보기의 탭 순서와 이전 GIF를 비교할 수 있습니다.

또한 고려해야 할 사항 :

3976은 블록 아래에 블록 도구 모음 (포맷 도구 모음)을 배치하는 세 번째 옵션을 제안합니다. 블록 도구 모음 _ 및 _ 블록 아래에있는 측면 컨트롤이 모두 작동하는지 확인하기 위해 디자인을 고려하는 것이 좋습니다.

탭 순서의 일관성에 대한 일반적인 문제로 1934 년

이것은 또한 # 6272에서 제기 된 일부 문제를 해결하는 데 영향을 미칠 수 있습니다.

긴 블록의 검색 가능성에 관해서는 도구 모음이 고정되어 위로 스크롤하면 도구 모음이 화면에서 벗어나지 않습니다.

네, 상단 서식 도구 모음에서도 마찬가지입니다.

여기에서 모든 멋진 피드백을 읽어 보면 접근성과 관련하여 앞으로 그리고 오늘날의 여러 문제가 해결되는 것 같습니다. 이 점을 염두에두고 여기서 몇 번 반복 작업 한 다음 PR로 이동하여 프로토 타입을 만들어야한다고 생각합니다. @melchoyce를 해주시겠습니까?

네, 다시 한번 볼 수 있습니다.

이것을 시도하면 +10.

브라우저 창의 너비를 줄 였을 때 블록 UI가 이렇게 생겼습니다. (좀 더 축소하면 블록 도구 모음이 블록 아래로 이동하지만 제안하는 내용과는 관련이 없습니다.)

블록 삽입 기가 위 / 아래 이동 컨트롤 옆에 나타납니다. 이러한 종류의 UI가이 문제가 제안하는 것과 같이 모든 화면 크기에 사용 되었다면 아마도 현재 블록 어 펜더를 중첩 된 블록 컨텍스트에서 제거하여 추가 된 항상 존재하는 여분의 공간을 제거하여 편집기를 프런트 엔드처럼 보이게 만들 수 있습니다. 각 중첩 수준에 대한 모든 블록 추가 자에 의해. (나는 또한 # 6834에서 appender-eating-up-space 문제에 대한 대체 솔루션을 제안했습니다.)

또한 이것은 참고 사항이지만 제거 버튼이 추가 옵션 버튼의 오른쪽에 있어야합니까, 아니면 왼쪽에 있어야합니까? 대부분의 UI 디자인에서 줄임표 메뉴는 맨 오른쪽에 있습니다.

또 다른 아이디어 :

이 블록 컨트롤을 마우스 오버시 하단에 표시하지만이 상태에서는 페이지의 공간을 차지하지 않고 대신 마우스 오버 한 블록 아래에있는 모든 항목 위에 표시됩니다 (블록 도구 모음이 현재 블록 위의 블록에 대해 수행하는 것과 동일). 하나) 또는 마우스를 올려 놓은 블록 위에있을 수 있습니다. 하단의 블록 컨트롤도 마우스 오버시 중단되지 않는 흰색 막대가 아니어야하며 컨트롤이 공간을 덜 차지하고 많이 가리지 않도록 블록 도구 모음과 비슷하게 양쪽에 2 개의 작은 막대가 있어야합니다.

블록을 선택하면 하단의 블록 컨트롤이 공간을 차지하여 블록의 시각적 공간을 늘리고 이미지 블록을 선택하면 캡션 자리 표시자가 나타나는 방식과 같이 아래 블록을 밀어냅니다. 이렇게하면 한 줄의 단락 블록과 같이 세로로 짧은 블록 인 경우 아래 블록을 더 쉽게 선택할 수 있습니다.

이 접근 방식을 사용하면 현재 마우스 오버 컨트롤의 이점을 유지하여 블록을 먼저 선택하지 않고도 쉽게 이동 / 삭제할 수 있으며, 블록이 편집 될 때 컨트롤이 아무것도 가리지 않도록 할 수 있습니다. 다른 블록을 선택하는 것이 더 쉽습니다.

또 하나의 아이디어 :

전체 블록 제어 막대 (및 블록 도구 모음)가 드래그 핸들 (GTK 헤더 막대 작동 방식과 같은 버튼 포함)으로 두 배가되도록합니다. 나는 이것이 드래그 앤 드롭 발견 가능성 문제를 거의 해결할 것이라고 생각합니다. 특히 하단 컨트롤 막대가 초기 게시물의 모형에서 블록의 일부인 것처럼 보이는 선택된 블록의 맥락에서, 따라서 사용자는 아마도 드래그 핸들로 사용하려고 생각할 가능성이 더 높습니다.

블록의 측면이 블록의 일부인 것처럼 보이지 않는 현재 상황과 대조되어 드래그 핸들 역할을 할 수 있는지 명확하지 않으며 단일 행 단락 블록이 발생하는 문제도 있습니다. 측면에 드래그 할 빈 공간이 거의 없습니다. (그리고 측면 제어 버튼은 비활성화되지 않는 한 현재 드래그 핸들로 사용할 수 없기 때문에 문제는 더욱 악화됩니다.)

이것에 대한 멋진 토론이 많이 있습니다. @melchoyce로 반복 할 수있는 무언가를 제공하기 위해 요약 피드백을 줄 수 있는지 살펴 보겠습니다.

전반적으로 나는 프로토 타입에서 이것을 느낄 필요가 있다고 생각하며 많은 생각을 완화 할 수 있다고 생각합니다. 그러나 모의로 작업하고 싶은 몇 가지 고려 사항이 있습니다.

• 키가 큰 블록을위한 솔루션.
• 덜 '뭉툭한'느낌 : 이것은 단지 모의에 자리 표시 자 상태를 보여주는 것일 수 있습니다. 저는 이러한 변화를 통해 더 분명하게 읽고 있습니다.
• 이것이 중첩과 어떻게 작동하는지 보여줍니다.

나는 이것이 또한 다른 장치에 어떻게 적응하는지보고 싶습니다. 제 생각에는 변화가 적고 그것은 좋은 일이 될 수 있다는 것입니다.

@SuperGeniusZeb 당신이 거기에 가지고있는 몇 가지 흥미로운 생각. 나는 Mel이 위의 반복으로 어디에서 오는지보고 싶습니다. 핸들을 끌기 위해 UI를 두 배로 늘리는 것은 지금은 피해야 할 일이라고 생각합니다. 작업중인 중첩 변경 사항이 있습니다. 반복하지 않겠다는 말은 아니지만이 UI는 특별히 그것을위한 것이 아닙니다. 또한 시각적으로 명시 적이 지 않고 소속감을 추론 할 수 있다고 생각합니다. 너무 분명 해지면 블록의 부정적인 느낌이 들어옵니다. 가깝고 너무 제한적이라고 느껴집니다.

나는 # 7211에 대해 고민하고 있었고 그 작업의 맥락에서 # 7646을 발견했고,이 아이디어로 다시 돌아 왔는데, 이것은 정말 많은 문제에 대한 최고의 해결책처럼 느껴졌습니다.

이 티켓은 직접 또는 간접적으로 모든 것을 수정합니다.

• # 7646 → 컨트롤이 위 / 아래에 위치하므로 측면 UI 수용에 대해 걱정할 필요가 없습니다.
• # 7182 →이 티켓의 모형에있는 것과 같은 컨트롤은 블록에 직접 연결되며 중첩 수준에 관계없이 일관된 UI를 갖습니다.
• # 6451 → 위쪽 / 아래쪽 도구 모음에 단색 배경이 있으면 어두운 배경에서 컨트롤을 표시하는 방법에 대해 걱정할 필요가 없습니다.
• # 7114 / # 6265 → 위의 일부 모형과 같이 전체 너비 도구 모음을 사용하는 경우 빈 영역을 사용하여 드래그 / 드롭 할 수 있습니다.

이 모든 것은 구텐베르크에이 큰 변화가있을 가능성이 여전히 있다면 많은 문제를 해결할 수 있고 많은 일을 더 쉽게 만들 수 있다고 생각합니다. :) 저는이 재미에 동참하고 작업 할 것입니다. 이번 주말에 몇 가지 모형 / 개념이 있기를 바랍니다.

@chrisvanpatten 은 관점을 추가하기 위해 툴바가 아닌 컨트롤에 관한 것입니다. 그것은 훨씬 더 많은 사용성 문제를 일으킬 것입니다. 링크하는 몇 가지 문제가 도구 모음 주변에있는 것처럼 확인하는 것뿐입니다.

탭 순서가 많이 향상되므로 이것을 시도하는 데 전적으로 찬성합니다. 빠른 업데이트 : "휴지통"제거 버튼이 줄임표 메뉴 내에서 이동되었습니다. 또한 컨트롤 의

@afercia 는 다른 컨트롤

키가 큰 블록을위한 솔루션.
덜 '뭉툭한'느낌 : 이것은 단지 모의에 자리 표시 자 상태를 보여주는 것일 수 있습니다. 저는 이러한 변화를 통해 더 분명하게 읽고 있습니다.
이것이 중첩과 어떻게 작동하는지 보여줍니다.

이 유망한 지점에서 경로를 결정하려면 이러한 지점을 탐색해야합니다.

@karmatosed 나는 헷갈리는 용어를 사용하고 있었다-나는 툴바가 아니라 컨트롤을 의미했다. 툴바는 이미 맨 위에 있습니다. 변경할 사항이 없습니다. :)

방금 블록 아래에 놓으면 블록 도구가 어떻게 보일지 상상하는 모형을 만들었습니다. 이 모형에서 블록 도구는 공간을 차지하지 않으며 데스크톱의 블록 도구 모음과 같은 오버레이 역할 만합니다. 블록은이 모형에서도 선택됩니다. 블록 위로 마우스를 가져 가면 맨 위에있는 블록 도구 모음이 표시되지 않습니다. 또한 하단 컨트롤은 현재 측면 컨트롤과 같이 근처에 마우스를 올려 놓을 때만 표시 될 수 있습니다.

표준:

블록 맨 아래가 화면에 표시되지 않는 경우 :

(참고 : 이미지 블록 도구 모음은 블록 도구 모음에 다른 옵션이 있으므로이 모형의 도구 모음과 일치하지 않습니다.)

블록 도구가 측면에있는 문제와이를 바닥에 두는 몇 가지 이점을 고려할 때 이제는 블록 도구를 바닥에 두는 것이 갈 길이라고 확신합니다.

@SuperGeniusZeb 그것은 기본적으로 내가 생각했던 것과 정확히 일치합니다. 단, 조합 된 도구 모음으로 오른쪽이 아닌 위쪽 / 아래쪽 화살표가있는 더 많은 옵션 버튼을 배치 할 것입니다.

@chrisvanpatten 네, 컨트롤이 분리되어

다음은 몇 가지 모형입니다.

호버 :

모바일 에서처럼 공간을 차지하고 (오버레이가 아닌) 전체 너비 막대로 선택되며 드래그 핸들로 두 배가 될 수 있습니다.

나는 우리가 이것을 너무 뭉툭하게 될 위험에 처해 있다고 생각한다. 이것은 이것을 설명하는 이상한 방법이지만 그것과 함께 진행된다. 저는 Mel이 테두리가 하나 더 적은 첫 번째 이미지에서 보여준 것을 더 많이 봐야한다고 생각합니다.

나는 첫 번째 모의를 가져다가 쓰레기통을 제거하여 진행하기에 가장 좋을 것이라고 생각하는 것을 얻었습니다.

우리는 추가 테두리가 필요하지 않으며 무게를 추가 할 필요가 없습니다. 이렇게하면 특이한 호버링 외곽선없이 쉽게 드래그 할 수 있습니다.

@karmatosed 블록 위로 마우스를 가져 갔을 때 어떻게 보이는지 보여주기 위해 모형을 수정했습니다.

여기에는 블록이 선택되고 블록 도구 모음이 표시됩니다.

(또한 구텐베르크의 현재 위치와 일치하도록 이미지 블록 자리 표시자를 업데이트했습니다.)

컨트롤에 위쪽 테두리가 없어서 혼란스러워하는 것 : 컨트롤이 여전히 흰색 배경에 있습니까? 이것은 전체 블록 뒤에 흰색 배경이 있음을 의미합니까? 블록이 어두운 배경을 가진 컨테이너에 중첩 된 중첩 컨텍스트에서 문제가 발생하는 것처럼 들리는데, 선택 (및 / 또는 호버링)하면 블록의 배경이 변경되어 상당히 혼란스러워 보일 수 있습니다.

컨트롤에 위쪽 테두리가 없어서 혼란스러워하는 것 : 컨트롤이 여전히 흰색 배경에 있습니까? 이것은 전체 블록 뒤에 흰색 배경이 있음을 의미합니까?

하지만 컨트롤에는 타겟이 있습니다. 나는 그것을 보여줄 가치가 있다고 생각하고 블록 시각적 문제를 피할 수 있습니다. 이것은 절대적으로 중첩 탐색이 필요하지만 배경이 없으면 시각적으로 중첩이 더 나빠질 것입니다.

하지만 컨트롤에는 타겟이 있습니다. 나는 그것을 보여줄 가치가 있다고 생각하고 블록 시각적 문제를 피할 수 있습니다. 이것은 절대적으로 중첩 탐색이 필요하지만 배경이 없으면 시각적으로 중첩이 더 나빠질 것입니다.

동의하고 배경이 있으면 # 6451도 해결됩니다.

나는 마지막 모형에서 호버에 큰 빈 막대가 표시되는 것을 좋아하지 않습니다. 이상적으로는 호버링시 주변 블록을 가능한 한 적게 가리고 싶지만 아래의 블록을 상당히 많이 덮습니다. 이런 건 어때?

이전에 제안했듯이 화살표 이동기와 줄임표는 드래그 핸들로 두 배가 될 수 있고 / 또는 호버 제목이 드래그 핸들이 될 수 있습니다. (# 7114 참조.)

@SuperGeniusZeb 이 경우 귀하의 요점을 이해하는 동안 블록을 윤곽선으로 표시하는 것은 시각적으로 훌륭하지 않습니다. Mel의 굉장한 작업을 기반으로 만든 mock을 고수하여 프로토 타입으로 보겠습니다.

선택한 블록 뒤에 흰색 배경을 표시하는 것에 대해 방금 깨달은 것 : 흰색 (또는 밝은 색상) 텍스트 색상이있는 블록은 어두운 색상 영역 (컨테이너 블록과 같은 것에서 제공됨)에서 볼 수 있다는 의미입니까? 이 경우 전체 블록에 흰색 배경이 있으면 작동하지 않습니다.

배경은 항상 해당 컨트롤이있는 도구 모음 주위에 있습니다.

@SuperGeniusZeb 예, 흰색 배경이 블록 자체에 영향을주는 것이 아니라 컨트롤에만 영향을 미치는 것을 볼 수 있습니다. 실제로 다음과 같을 수 있습니다.

또는 패딩을 잠재적으로 제거 할 수 있습니다 (이 접근 방식은 정말 마음에 들지만 드래그 앤 드롭과 관련이있는 더 큰 질문입니다. 여전히 고려할 가치가 있다고 생각합니다).

@chrisvanpatten 나는 그 마지막 모형을 좋아한다. 하단 바가 드래그 핸들이 될 수 있기 때문에 드래그 앤 드롭이 문제가되지 않는다고 생각합니다 (잠재적으로 바의 버튼도 마찬가지로 작동 할 것입니다). 마우스 오버시 하단 막대에 드래그 핸들 아이콘을 추가하거나 항상 해당 아이콘을 사용하여 블록을 드래그 할 수 있음을 표시 할 수 있습니다.

이 접근 방식을 사용하면 드래그 가능한 영역을 블록 경계 근처에 유지할 이유가 없습니다. 해당 패딩을 제거하면 블록 호버 / 선택된 윤곽선이 블록의 실제 경계에 더 가깝게 만드는 데 도움이 될 수 있습니다. 상위 블록을 더 쉽게 선택할 수 있도록 중첩의 경우. (# 6459 의이 주석 에있는 모형과 같은 항목이 구현 된 경우 부모 블록을 선택하는 것은 문제가되지 않습니다.)

안녕하세요.

마우스 오버시 하단 막대에 드래그 핸들 아이콘을 추가하거나 항상 해당 아이콘을 사용하여 블록을 드래그 할 수 있음을 표시 할 수 있습니다.

좋은 아이디어 💡

드래그 가능한 영역을 한쪽으로두고이를 구현해 보겠습니다. 이 문제를 먼저 해결하는 데 집중하는 것이 중요합니다. 나는 아이콘이 올바른 접근 방식인지 확실하지 않다고 말해야하는데, 우리가 이것을 구현 한 후에 다시 살펴 보자.

뿡 빵뀨

드래그 가능한 영역을 한쪽으로두고이를 구현해 보겠습니다.

이것이 무엇을 의미하는지 잘 모르겠습니까? 어느 쪽?

이런 일이 일어나게되어 기쁩니다. 시각적 배치에 관한 것이 아니라는 점을 간단히 상기시켜드립니다. a11y의 경우 시각적 순서와 탭 순서 (DOM 순서)가 일치해야 이러한 "블록 도구"가 실제로 마크 업의 블록 편집 가능 영역 이후로 이동해야합니다.

블록 아래의 컨트롤로 전환 할 때의 한 가지 좋은 이점은 현재 디자인에 문제가 발생하는 경우 형제 삽입기를 Squarespace의 것과 같은 것으로 다시 디자인 할 수 있도록 측면 공간을 열 수 있다는 것입니다. 현재 측면 컨트롤은 이러한 종류의 삽입 기와 겹치고 복잡해 보이지만 컨트롤이 맨 아래로 이동하면 더 이상 문제가되지 않습니다.

https://support.squarespace.com/hc/en-us/articles/206991377-Adding-blocks#toc -insert-points

# 7500에 대해 방금 댓글을 달았습니다. 이 디자인에서 연속적인 단락이 어떻게 보일지 궁금합니다. 하단에 막대가 있으면 단락 사이에 상당한 간격이 생길 것이라고 생각합니다.

@talldan # 7500에서 자신을 인용 :

블록 컨트롤은 마우스 오버시 공간을 차지하지 않으며 (그들과 블록 도구 모음이 지금 공간을 차지하지 않는 것처럼), 내가 알 수있는 한 선택한 블록에서 공간을 차지할지 여부는 아직 결정되지 않았습니다. 물론 컨트롤은 선택되거나 마우스를 올려 놓은 블록에 대해서만 표시됩니다. 블록 간의 표준 거리는 변경의 영향을받지 않아야합니다. 선택한 블록 만 영향을받을 수 있습니다.

이건 정말 맛있어 보여요.

이것에 대해 우리가 전에 고려하지 않은 한 가지. 긴 블록은 어떻습니까? 블록이있는 편집기 화면의 맨 아래에는 어떻게됩니까?

블록이 너무 길면 스크롤이 안 나와요? 나는 그것이 일어나기 전에 사람들이 그것이 어떻게 작동하는지 보았고 그것을 어디에서 찾을 수 있는지 알 것이라고 말하고 싶습니다. 작은 화면에 긴 문단을 많이 쓰면 짜증나는지 테스트해야합니다. 하지만 모바일 경험을 더 잘 반영한다는 점이 마음에 듭니다. 게시물의 마지막 블록에 대해 어떤 우려 사항이 있습니까?

첫 번째 블록이 정말 긴 블록인지 어떻게 알 수 있습니까?

적어도 그것에 대한 NUX 팁을 추가해야합니다;)하지만 당신이 걱정하는 것은 누군가가 하나의 긴 단락이거나 블록으로 올바르게 변환되지 않은 기존 게시물을 여는 경우입니까? 가능합니다 ... 새 게시물을 시작하면 거의 확실하게 첫 번째 자리 표시 자 블록에서 볼 수 있습니다. 맞죠?

이것에 대해 생각해 보면, 컨트롤을 블록 맨 위에 놓는 것에 대한 탐색이 보이지 않습니다. 옵션이 될 수 있습니다. 그것에 대한 간단한 모형을 만들었습니다. ( 바 조합도 여기에서 언급 )

블록이 너무 높으면 상단 컨트롤이 상단에 고정되거나 모바일에서 작동하는 방식과 같이 하단 컨트롤이 화면 하단에 고정되지 않을까요?

@hedgefield 나는 그것을 많이 좋아하지만 좁은 컨텍스트 (열 블록과 같은) 또는 긴 도구 모음에서는 잘 작동하지 않습니다.

@hedgefield @chrisvanpatten 너비가 더 얇은 경우 화살표 / 줄임표 컨트롤이 서식 컨트롤 아래 (또는 위쪽)로 이동할 수 있습니까?

@karmatosed 나는 컨트롤이 끈적 거리고 화면 하단에 계속 표시 될 수 있다고 말하고 싶습니다. 그러나 이로 인해 쓰기를 시작할 때마다 단락에 쓰려는 줄을 덮는 컨트롤 문제가 발생합니다 (아마도 지금 작동하는 것처럼 입력하는 동안 숨겨 질 것입니다). 그러나 어쨌든 그 해결책은 의심스러워 보입니다.

그러나 @hedgefield 의 모형으로 돌아 가면 컨트롤이 방해받지 않고 서식 도구처럼 고정 될 수 있습니다. 물론, 툴바는 반응해야하고 화살표 이동기와 줄임표는 얇은 블록의 경우 이상적으로 아래 / 위 / 어딘가로 이동해야합니다.

접근성에 대한 우려도 있습니다. @hedgefield 의 모형에는 시각적으로 블록 앞에 오는 모든 컨트롤이 있습니다. 이상적으로는 마크 업의 블록 뒤에 와야합니다. 이론적으로는 CSS를 사용하여 컨트롤이 마크 업의 블록 뒤에 나오지만 시각적으로 그 위에 표시되도록 할 수 있습니다. 그러나 실제로 구현하는 것이 얼마나 어려운지 잘 모르겠고, 시각적 인 모양과 소스 순서 사이에 불일치가 발생해야하는지 알 수 없습니다. 마크 업의 블록 뒤에 모든 블록 컨트롤이 표시되면 뒤로 이동하지 않고 앞으로 탭할 수 있기 때문에 키보드를 통해 컨트롤을 훨씬 더 직관적으로 찾을 수 있으므로 개인적으로 신경 쓰지 않습니다.

시각적 인 모양과 소스 순서가 일치하지 않는 것이 바람직한 지 모르겠습니다.

특정 WCAG 성공 기준이있는 시점에서는 바람직하지 않습니다.
https://www.w3.org/TR/WCAG21/#focus -order

컨트롤이 고정되어 화면 하단에 계속 표시 될 수 있습니다. 그러나 이로 인해 쓰기를 시작할 때마다 단락에 쓰려는 줄을 덮는 컨트롤 문제가 발생합니다 (아마도 지금 작동하는 것처럼 입력하는 동안 숨겨 질 것입니다). 그러나 어쨌든 그 해결책은 의심스러워 보입니다.

사실, 좀 더 생각해 보면, 단락이 화면 하단 바로 옆에 있지 않으면 컨트롤이 실제로 단락의 마지막 줄을 가리지 않을 것이므로 # 353이 문제가되지 않을 수 있습니다. 그리고 # 353이 없어도 여전히 아래로 스크롤 할 수 있으며 (대부분의 사람들이 어쨌든하는 일입니다), 앞에서 언급했듯이 컨트롤은 마우스를 움직일 때만 표시됩니다. 마음이 바뀌 었습니다. 이것은 작동 할 수 있습니다!

넓은 블록의 경우 :

얇은 블록의 경우 :

더 얇은 블록 (8 개 열 등) :

이 디자인이 정말 마음에 들어요. 더 넓은 블록의 경우 화살표 이동 컨트롤이 서식 컨트롤의 왼쪽 또는 오른쪽으로 이동해야하는지 확실하지 않습니다.

탐색 해주셔서 감사합니다. 그러나 모든 것을 한 줄로 결합하면 다른 작업이 한 곳으로 병합됩니다. 그게 말이되는지 잘 모르겠습니다. 우리는 또한 누군가가 툴바를 맨 위에 붙일 때 어떤 일이 일어나는지에 대한 고려를합니다. 툴바에서 블록 컨트롤을 사용할 수 없기 때문에 경험이 부족한 것처럼 느껴집니다. 경험하기 매우 이상 할 것입니다.

그러나 모든 것을 한 줄로 결합하는 것은 다른 작업을 한 곳으로 병합하는 것입니다.

악마의 옹호자 역할을하는 것은 정의상 툴바의 목적이 아닙니까?

추가로, 특정 컨트롤을 분리하는 아이디어를 이해할 수 있지만이 경우에 대해 충분히 설득력있는 주장이 있는지 확신 할 수 없습니다. 도구 모음은 도구 모음입니다. 특정 도구가 특정 위치에 속하는 반면 다른 도구가 플러그인이 어차피 무시할 수있는 다른 위치에 속하는 이유가 모호한 이유를 제시하는 것보다 주어진 블록에 대한 모든 컨트롤을 한 곳에 두는 것이 논리적으로 합리적입니다.

@karmatosed 색상을 통해 컨트롤을 분리하는 것은 어떻습니까?

@SuperGeniusZeb 불행히도 다른 점을 해결하지 못하며 작동하는지 확신하지 못합니다.

이 경우는 효과가있는 디자인을 얻는 것보다 작업 할 것으로 생각되는 디자인에 맞추려고 노력하는 경우라고 생각합니다. 뒤로 물러서서 내가 제기 한 다른 포인트를 고려하는 것은 어떻습니까?

@chrisvanpatten 도구 모음은 정의에 따라 모든 것을 넣을 수있는 장소가 아닙니다. 도구 모음이 컨텍스트와 순서를 가져야하므로 유용합니다. 사용자는 올바른 옵션이 무엇인지 기대해야합니다. 한동안 단수 단어의 의미가 무엇인지 토론 할 수 있지만, 그렇게하는 것은 재미 있습니다. 한 번에 너무 많은 것을 결합하고 더 많은 사람들에게 문제가 될 것이라는 사실을 놓칠 수는 없습니다.

@karmatosed 좋아요. 다시 편집 도구 모음을 맨 위에 표시해 보겠습니다.

(바 위의 파란색 선이 있는지 여부는 확실하지 않습니다.)

이 디자인에 문제가 있습니까? 편집 도구 모음은 접근성을 위해 소스 순서에서 블록 뒤에 나타나도록 만들 수 있습니다. 이상적이지는 않지만 편집 도구 모음을 블록 아래에 두는 것이 실행 가능한 옵션이 아닌 것 같아서 우리가 할 수있는 유일한 방법 인 것 같습니다.

또한 방금 아이디어가 생겼습니다. 하단의 막대가 호버링시 부분적으로 투명하면 어떻게 될까요? 그러면 더 가벼워 질까요?

@SuperGeniusZeb 그냥 조회수를 얻기 위해 우리가 덜 다채로운 모의를 제안 할 수 있습니까? 나는 제안되는 것을 이해하지만 인터페이스를 자체적으로 세우는 것이 시각적 복잡성없이 더 쉬울 것입니다.

다음 단계 모의를 얻으려면. @SuperGeniusZeb 화면 (일반 데스크톱 크기)과 매우 긴 블록의 맥락에서 위의 모습은 어떻습니까? 맨 아래에 블록이 있으면 어떻게 생겼습니까? 이상적으로는 약간의 투명성을 고려하고 이번에는 색상이 아닌 UI에 초점을 맞추는 것에 대한 제 의견을 고려해 보겠습니다. 우리 모두에게 도움이 될 것입니다.

일부 모형 :

컨트롤 막대 상단에 테두리 포함

컨트롤 막대 상단에 테두리 없음

도구 모음은 마우스 오버시 공간을 차지하지 않지만 블록을 선택하면 공간을 차지합니다.

이 모형을 만드는 동안 나는 무언가를 발견했습니다 : 이와 같은 상황에서 무엇을해야합니까?

여기에서 선택한 블록의 서식 도구 모음과 마우스 커서가있는 블록의 맨 아래 컨트롤을 모두 표시하는 데 충돌이 있습니다. 서식 도구 모음이 맨 아래에있는 경우 (또는 블록 컨트롤이 모두 맨 위에 있으면) 문제가되지 않지만 아래에 표시된 컨트롤과 위에 표시된 컨트롤의 조합이 문제를 일으 킵니다.

내가 생각할 수있는 가장 좋은 해결책은 마우스 커서가있는 블록과 도구 모음의 Z- 색인이 더 높고 아래 블록과 서식 도구 모음의 맨 위에 표시되도록하는 것입니다. 그래도 이것이 올바른 접근 방식인지는 모르겠습니다. 다음은 이것이 어떻게 생겼는지에 대한 모형입니다.

다시 말하지만, 하단 막대와 블록 콘텐츠 사이의 경계선없이 :

나는 선택된 블록과 겹치는 호버 블록의 아이디어를 정말로 좋아하지 않지만, 그렇지 않으면 선택된 블록 바로 위에 호버 된 블록의 하단 막대를 사용할 방법이 없습니다. 최소한 바탕 화면에서 상단 또는 하단의 단일 막대에 모든 컨트롤을 포함하는 것이 더 좋지 않을 것이라고 확신하십니까? 확실히 이와 같은 문제를 방지 할 것입니다.

@SuperGeniusZeb 나는 어떻게 든 그 모형을 놓쳤습니다. 만들어 주셔서 감사합니다!

이것은 내가 생각하지 못했던 정말 좋은 점입니다 (선택된 블록 위의 블록을 호버링). 그것은 확실히 문제입니다. 상주 페이지 빌더 전문가로서 이와 같은 계층화 된 도구 모음을 사용하여 다른 페이지 빌더에 유사한 패턴이 있습니까?

또한, 그만한 가치를 위해 도구 모음은 항상 마우스 오버하거나 선택하거나 선택하지 않아야한다고 생각합니다. _ 때때로 _ 공간을 차지하는 것은 전반적으로 더 어색한 경험 인 불안정한 콘텐츠로 이어질 것입니다.

@chrisvanpatten 내가 본 모든 페이지 빌더에는 모듈 / 위젯의 맨 위에 표시되는 컨트롤 (동위 삽입 기 제외) 만 있습니다. Divi는 제 생각에 가장 좋은 예 중 하나입니다.

https://supergeniuszeb.com/wp-content/uploads/2018/06/Divi-Visual-Builder-add-button-responsiveness-demonstration.webm

비디오에 표시되지 않은 Divi의 서식 지정 도구 모음은 모듈에서 텍스트를 클릭하면 나타나고 작성중인 줄 위에 작은 팝업에 나타납니다.

Elementor는 거의 같은 일을합니다.

Beaver Builder에서 위젯의 텍스트를 클릭하면 마우스가 위젯 테두리 밖으로 이동할 때까지 블록 컨트롤 도구 모음이 서식 도구 모음으로 대체되어 다음에 위젯을 가리킬 때 표준 블록 컨트롤이 나타납니다. , 위젯에 계속 입력 할 수 있습니다. 텍스트를 다시 클릭하면 서식 도구 모음이 표준 도구 모음을 다시 대체합니다.

또한, 그만한 가치를 위해 도구 모음은 항상 마우스 오버하거나 선택하거나 선택하지 않아야한다고 생각합니다. 때때로 공간을 차지하는 것은 전반적으로 더 어색한 경험 인 급격한 콘텐츠로 이어질 것입니다.

사실이지만 이것이 깨끗한 UI를 갖는 데 미치는 영향에 대해 걱정합니다. 위의 일부 내용과 겹치는 서식 도구 모음이 있으면 괜찮습니다. 그러나 블록 하단에 전체 너비 막대를 추가하면 이제 많은 다른 콘텐츠와 겹칩니다.

이상적으로는 모든 컨트롤이 블록의 맨 위 또는 맨 아래에 있어야합니다. 이렇게하면 대부분의 경우 도구 모음이 서로 겹치는 것을 방지 할 수 있습니다. 접근성을 위해 컨트롤을 하단에 두는 것이 이상적입니다. 그러나 도구 모음이 단락 블록과 같이 작성중인 내용과 겹치는 문제가 발생할 수 있습니다. 그러나 화살표 이동자와 줄임표는 거의 자주 사용되는 것이 아니기 때문에 서식 도구 모음 만 항상 표시되어야한다는 점에 유의해야합니다. 또한 현재 편집중인 블록 콘텐츠의 일부가 화면 하단에서 충분히 멀리 떨어져 있으면 서식 도구 모음이 겹치지 않아도됩니다.

컨트롤을 맨 아래에 두는 것이 너무 어색하다면 차선책은 모든 컨트롤을 맨 위에 놓는 것 같습니다. 물론 얇은 블록에 대해 어색해 보이는 컨트롤의 잠재적 인 문제가 있습니다.

데스크톱과 모바일의 경우 일반적으로 도구 모음의 위치를 ​​변경하면됩니다. 현재 서식 도구 모음 및 기타 컨트롤은 모두 현재 선택한 블록 아래에 표시되며 모바일에서 공간을 차지합니다.

그러나 넓은 블록과 얇은 블록의 경우 더 얇은 블록에 대한 컨트롤을 이동하는 것이 어색 할 수 있습니다. 가장 일관된 모양은 상단에 서식 도구 모음이 있고 하단에 다른 컨트롤이있는 것입니다. 그러나 이는 툴바가 겹치는 문제와 콘텐츠 겹침이 증가하는 문제로 돌아 가게합니다.

구텐베르크는 선택한 블록의 모양이 편집에 최적화되어 있다는 생각을 바탕으로 설계 되었기 때문에 도구 모음이 물리적 공간을 차지하는 것이 그렇게 나쁘지 않다고 생각합니다. 블록을 선택하면 블록 주변의 물건 만 이동하고 이동하지 않는 한 선택한 블록 자체.

결국 이 모형 은 여전히 ​​좋은 옵션이라고 생각합니다. 완벽하지는 않지만 접근성 측면에서 보면 너무 어색하지 않고 모바일과 일치하며 툴바가 겹치는 경우가 거의 없습니다.

작동 방식에 대한 몇 가지 참고 사항 :

컨트롤은 마우스 오버시 공간을 차지하지 않지만 블록을 선택하면 공간을 차지합니다. 블록을 가리키면 화살표 이동기 및 줄임표 만 표시되지만 블록을 선택하면 서식 도구 모음이 나타나고 다른 컨트롤이 아래쪽으로 밀립니다. 이것은 아마도이 디자인의 가장 큰 문제 일 것입니다. 이 작업을 가장 잘 수행하려면 이동자 / 줄임표 도구 모음을 클릭하여 블록을 선택할 때 블록의 내용이 위로 밀려나 가기를 원하지만 내용 영역을 클릭하여 블록을 선택하면 도구 모음이 이동되기를 원할 것입니다.

블록이 콘텐츠 영역 아래로 늘어 나면 화살표 이동기와 줄임표가 화면에서 사라지지만 서식 지정 도구 모음은 화면 하단 (또는 콘텐츠 편집기 영역)에 고정되어 계속 표시됩니다.

이것이 최선의 해결책이 아니라면 기본적으로 동일한 작업을 수행하지만 컨트롤이 모두 맨 위에 있고 이동자 / 줄임표가 얇은 블록에 대한 서식 도구 모음 위에 나타나고 아마도 서식 컨트롤의 왼쪽에 나타납니다. 넓은 블록. 모바일은 여전히 ​​지금처럼 보일 수 있습니다.

또 다른 생각 : 단순히 마우스 오버시 컨트롤을 표시하지 않으면 컨트롤 이동 문제와 서로 겹치는 도구 모음 문제를 모두 제거 할 수 있습니다. 그러면 블록의 맨 위와 맨 아래에 도구 모음이 표시되는 것이 훨씬 덜 문제가됩니다. 그러나 물론 마우스 오버시 컨트롤이 표시되는 이점을 잃게됩니다. 누구가 가고 싶은 방향인지는 잘 모르겠지만, 필요한지 궁금합니다.

나는 호버 블록이 겹치는 아이디어가 내가 좋아하는 아이디어가 아니라고 말해야합니다. 이것은 내가 생각하는 더 많은 생각이 필요합니다. 호버링시 잠재적으로 다른 공간을 차지하는 컨트롤에 대한 아이디어는 약간 어색합니다.

컨트롤은 마우스 오버시 공간을 차지하지 않지만 블록을 선택하면 공간을 차지합니다. 블록을 가리키면 화살표 이동기 및 줄임표 만 표시되지만 블록을 선택하면 서식 도구 모음이 나타나고 다른 컨트롤이 아래쪽으로 밀립니다. 이것은 아마도이 디자인의 가장 큰 문제 일 것입니다.

나는 이것이 모의에게 큰 문제라고 생각한다. 또 어떤 일이 일어날 수 있습니까?

페이지 빌더를 보는 것도 한 측면이지만 다른 앱과 제품은 어떻습니까? 다른 곳에서 해결 되었습니까?

뿡 빵뀨

페이지 빌더를 보는 것도 한 측면이지만 다른 앱과 제품은 어떻습니까? 다른 곳에서 해결 되었습니까?

구텐베르크가 사용할 수있는 유사한 UI 예제를 찾는 것은 어렵습니다. 구텐베르크가하는 모든 일을 설명 할 필요가 거의 없기 때문입니다.

더 간단하고 오래된 페이지 빌더 플러그인은 모든 콘텐츠 편집이 모달 또는 사이드 바에서 이루어지기 때문에 블록에 해당하는 콘텐츠를 가리는 것에 대해 걱정할 필요가 없습니다. 이렇게하면 모듈 컨트롤이 콘텐츠와 겹칠 수 있습니다.

모달 / 사이드 바를 열지 않고도 텍스트를 편집 할 수있는 Divi 또는 Beaver Builder와 같은 경우에도 모달 / 사이드 바가 여전히 기본 편집 방법입니다. Divi와 Beaver Builder는 모두 텍스트 편집기로 사용하거나 주요 블록 콘텐츠의 대부분을 인라인으로 편집 할 수 있는지 확인하는 등의 작업을 최적화 할 필요없이 기본적으로 프런트 엔드의 완벽한 복제본을 보여줍니다. 블록.

또한 페이지 빌더 및 기타 빌더 UI 모두에서 중첩 될 수있는 항목에 대한 제한으로 인해 중첩이 훨씬 덜 문제가되는 경향이 있습니다. Divi에는 엄격한 섹션 → 행 (열이 내장되어 있음) → 모듈 설정이 있습니다 (일부 공통 중첩 열 위치를 위해 고안된 일부 특수 섹션이 있음). Beaver Builder는 Elementor와 마찬가지로 열이 열에 중첩되도록 허용합니다. 여러 계층의 중첩을 가질 수있는 유일한 종류의 개체를 제어합니다. 모든 것은 기본적으로 단일 행이있는 섹션에 있습니다. 다양한 목적과 Gutenberg가 허용하는 것과 같은 다양한 스타일을 위해 중첩을 사용하는 사용자 정의 블록의 조합에 대한 잠재력을 가진 중첩 된 블록의 무제한 레이어는 없습니다.

Divi는 엄격한 구조를 가지고 있고 섹션이나 행을 작동하는 사용자 정의 모듈이있을 수 없기 때문에 섹션, 행 및 모듈에 대한 컨트롤에 색상을 지정할 수 있습니다. (이렇게하면 동일한 행에 여러 삽입 기 단추를 표시 할 수 있지만 각각의 기능을 구분하기 위해 다른 색상으로 표시 할 수 있습니다.) 대부분의 빌더에서 모듈은 레이아웃 요소와 분리되어 있습니다. Beaver Builder는 모듈과 레이아웃 요소의 분리로 인해 유사한 작업을 수행 할 수 있습니다.

텍스트 편집기와 같이 페이지 빌더가 아닌 것을 살펴보면 페이지 빌더가 처리해야하는 모든 것에 대해 걱정할 필요가 없음을 알 수 있습니다. 대부분의 페이지 빌더를 보면 직접 인라인 WYSIWYG 컨트롤을 통해 텍스트 편집기를 처리하지 않습니다.

구텐베르크가하려는 것은 독특합니다. 전체 텍스트 편집기이기도 한 편집을 위해 최적화 된 선택 블록을 제외하고 WYSIWYG가 되려고하고 있으며 섹션에서 열, 위젯에 이르는 모든 것이 모두 동일한 종류입니다. 개체 : 블록.

기본적으로 이것은 복잡한 문제입니다. 구텐베르크가 다른 작업은 시도하지 않는 것처럼 보이는 동시에 여러 가지 작업을 시도하기 때문입니다. : stuck_out_tongue :

어쨌든 다음은 블록 / 모듈 / 위젯 UI를 처리하는 방법을보기 위해 살펴볼 수있는 항목 목록입니다.

WordPress 플러그인 / 테마

• Avada (Fusion Builder)
• BeTheme (머핀 빌더)
• 비버 빌더
• Divi (Divi Builder)
• Elementor
• 산소
• SiteOrigin 페이지 빌더
• 번창하는 건축가
• 비주얼 컴포저
• Themeco의 X & Pro

WordPress 외부의 웹 사이트 빌더

• 드루팔
• Squarespace
• Weebly
• Wix

페이지 빌더는 아니지만 비슷한 것

• MailChimp
• 개념

지금 내가 아는 전부입니다.

형제 삽입 자에 문제가 있습니다. 항상 선택한 블록의 내용과 겹칩니다. 이 문제는 구텐베르크를 더 WYSIWYG로 만들기 위해 각 블록의 자동 여백과 같은 것들을 제거하려고 할 때 더욱 악화됩니다.

해결책? 글쎄, 우리가 블록의 맨 아래에 막대를 추가하려는 경우 형제 삽입기를 그 막대에도 던지지 않는 이유는 무엇입니까?

또한 호버링 된 변형의 테두리를 조금 덜 거슬리게 만드는 방법을 생각해 냈습니다. 하단 바에서 블록 내용을 나누는 테두리 색상 만 변경하면됩니다!

혜택은 다음과 같습니다.

• 형제 삽입자는 선택한 블록의 내용과 겹치지 않습니다. 즉, 위쪽으로 스크롤하거나 입력 만하고 마우스를 움직이지 않는 경우 콘텐츠를 덮지 않는 고정 서식 도구 모음을 제외하고 선택한 블록의 콘텐츠와 겹치는 UI가 없어야합니다.
• 이제 형제 삽입 기가 HTML 탭 순서와 동일한 순서로 표시되므로 접근성에 좋습니다.
• 형제 삽입 기가 이제 위가 아닌 블록 아래에 나타납니다. 제 생각에는 이것이 더 의미가 있습니다.
• 선택한 블록에 대해 형제 삽입 기가 항상 표시됩니다 (컨트롤이 지금처럼 보이지 않는 경우 입력 할 때 제외).
• 모바일 UI와의 일관성.
• 모든 여백과 블록의 내부 패딩을 제거 할 수 있으며, 블록 UI가 블록의 콘텐츠를 방해하지 않고 블록 테두리를 블록의 실제 크기로 다시 변경할 수 있습니다.

빈 단락 블록을 삽입하는 대신 형제 삽입 기가 삽입 기 메뉴를 직접 열도록 변경하면 (# 7271에서 설명 됨) 보너스 포인트가 제공됩니다.

물론 선택한 블록 위로 블록을 가리키면 어떻게되는지에 대한 질문은 여전히 ​​문제입니다. 그러나 나는 이것이 정말로 나를 괴롭히지 않는다고 생각합니다. 블록을 클릭하여 선택하고 컨트롤을 확인하기 만하면됩니다. 현재 선택된 블록 아래에 마우스 오버 컨트롤이 표시되면 선택한 블록이 포커스가되어야하므로 괜찮습니다.

앞으로 나아갈 좋은 디자인이라고 생각합니다. 모든 긍정이 부정적인 것보다 중요하다고 생각하며 지금 현재 존재하는 것보다 확실히 낫다고 생각합니다. 여러분은 어떻게 생각하십니까?

위쪽 및 아래쪽 도구 모음이 모두 겹치는 경우 어떻게 보이는지, 그리고 마우스 커서가있는 블록이 선택한 블록에서 항상 가장 높은 Z- 색인을 사용하는 경우 어떻게 보이는지 모의했습니다.

나는 이것을 많이 좋아하지만 한 가지 작은 문제가 있습니다. 단일 라인 블록은 하단 제어 막대 아래에 거의 완전히 숨겨져 있기 때문에 운이 좋지 않습니다.

@chrisvanpatten 블록을 선택하면 하단 막대가 실제로 공간을 차지할 것이라고 생각했습니다. 한 줄 블록 문제를 해결할 것이라고 생각합니다. 어떻게 생겼는지 보여주는 모형을 만들 수 있습니까? 또한 호버 된 블록이 선택한 블록과 겹치지 않으면 어떻게됩니까?

또한 무언가와 겹칠 때 하단 막대 아래에 그림자가 있어야합니다.

@SuperGeniusZeb 저는 하단 막대가 공간을 차지하는 것을 강력히 반대합니다. 이는 UI 점프로 이어집니다. 재사용 가능한 블록은 당신이 그들을 선택하면 이제 그렇게하고 그것은 나를 미치게 만듭니다.

(편집 : 정교하게 말하면, 한 순간부터 다른 순간까지 같은 위치에있는 것에 실제로 의존 할 수 없기 때문에 마우스 사용자에게는 일이 정말 힘들어집니다. 그것은 많은 어색함을 유발합니다.)

안녕하세요.

나는 주로 글을 쓰는 맥락에서 당신이 입력하고있는 문단 아래의 문단을 은폐하고 싶지 않을 것이라고 생각합니다. 지금은 선택된 문단 아래의 문단 블록에 첫 줄이 누락 된 것 같습니다. 현재 편집중인 블록 다음에 블록의 상단이 보이지 않는 것보다 하나를 선택할 때 주변 블록이 조금 튀어 나오는 것을 선호한다고 생각합니다. 개인적으로 뛰어 다니는 것은 나를별로 괴롭히지 않습니다.

구텐베르크에서는 이미지 캡션 자리 표시 자, 인용 인용 자리 표시 자, 갤러리의 자리 표시 자 / 삽입 자, 언급했듯이 재사용 가능한 블록 등 선택시 크기가 변경되는 것이 매우 일반적입니다. 구텐베르크는 일반적으로 블록의 모양이 선택 될 때 편집을 위해 최적화되어야한다는 아이디어를 중심으로 설계되었습니다. 바닥 막대가 공간을 차지하기 때문에 블록 높이를 높이는 것이 좋습니다.

또는 하단 막대를 반투명으로 만들어 그 아래에 블록이 있음을 좀 더 명확하게 할 수 있습니까? 어떻게 들리나요? 괜찮을 것 같아요.

유일한 문제는 구텐베르크 UI의 다른 곳에서는 투명성이 사용되지 않는다는 것입니다. 그렇다고해서 사용해서는 안된다는 말이 아니라 기존 예제가 없기 때문에 UI 디자인 불일치를 도입 할 수 있습니다.

왼쪽과 오른쪽에있는 컨트롤 사이의 빈 공간을 없애는 아이디어도 있지만, UI가 너무 "고르지 않게"보이게했기 때문에 티켓의 앞부분에서 중단되었습니다.

@chrisvanpatten 즉, 나는 지금 현재 존재하는 것보다 당신의 모형을 여전히 선호 한다고 생각

@SuperGeniusZeb 이 경우 특히 어색하게 만드는 것은

나는 호버 / 선택 / 점프 / 단선 단락 문제 때문에 포기할 가치가 없다고 생각하지만 확실히 조금 더 생각할 필요가 있습니다.

나는 여전히 여기 어딘가에 해결책이 있다고 확신합니다. 계속 반복하면됩니다!

안녕하세요.

이 경우 특히 어색한 점은 마우스를 가져갈 때 컨트롤이 있다는 것입니다. 점프 컨트롤의 다른 모든 예를 사용하면 적어도 마우스를 가져갈 때 표시되지 않고 선택시에만 표시됩니다.

글쎄 ... 당신은 호버에 어떤 컨트롤도 보여줄 수는 없지만, 아무도 그것을 원하지 않는다고 가정하는 것이 안전하다고 생각합니다. 나는 확실히 호버에서 사용할 수있는 컨트롤을 좋아한다는 것을 알고 있습니다.

어쨌든 투명성은 어떻습니까?

그리고 약간의 꿈을 꾸고 모든 주요 브라우저에서 backdrop-filter 가 구현되기를 원하면 약간의 흐림 효과를 추가 할 수 있습니다.

그건 그렇고, 이것은 60 % 불투명도입니다.

불투명도는 확실히 도움이되지만 방정식에 불투명도를 도입하는 것은 확실하지 않습니다. 속임수처럼 느껴집니다.

@chrisvanpatten 사실, 속임수 같은 느낌이 들지만 ... 우리가 가진 다른 옵션은 무엇입니까?

컨트롤을 측면에 둘 수 없으므로이 문제는 처음에 존재합니다.

콘텐츠를 가리기 때문에 블록 내에 컨트롤을 넣을 수 없습니다.

이미 서식 지정 막대가 있고 얇은 블록으로 인해 발생할 수있는 문제 때문에 컨트롤을 맨 위에 놓을 수 없습니다.

컨트롤을 하단에 배치하는 것은 접근성을 위해 더 잘 작동하고 형제 삽입 기와 드래그 핸들을 모두 넣고 관련 문제를 해결할 수있는 편리한 위치를 제공하고 모바일과 더 일관성이 있으며 씬에 가장 적합하기 때문에 가장 합리적입니다. 블록.

하단 막대가 차지하는 공간을 줄이기 위해 실제로 할 수있는 작업은 몇 가지뿐입니다.

• 바의 높이를 줄입니다.
• 삽입 기 / 이동기 / 끌기 핸들과 줄임표 사이의 빈 공간을 제거합니다.
• 줄임표를 왼쪽으로 밀고 오른쪽의 추가 공간을 제거합니다.
• 선택하면 공간을 차지합니다. (하지만 당신은 이것을 원하지 않습니다.)

그 외에 할 수있는 일은 반투명으로 만들어 시각적으로 더 가볍게 느끼고 그 아래에있는 것을 더 쉽게 볼 수 있도록하는 것입니다.

또 다른 생각 : _both_ 도구 모음이 맨 아래에있는 것이 아니라 투명하다면 투명성 문제가 속임수처럼 느껴지지 않을 수도 있습니다.

위에서 언급 한 것들 중 일부를 시도하기 위해 더 많은 모형을 만들었습니다.

투명한 도구 모음 :

투명성 없음 :

사실 투명성이 없는 것을 선호한다고 생각합니다. 어떻게 생각해? 하단 막대의 너비를 줄이면 겹치는 다음 블록 시작 문제가 해결되었다고 생각합니다. 물론, 여전히 더 작은 너비에서 발생하지만 ... 어쨌든 서식 도구 모음에서 이미 발생하므로 여기서는 실제로 문제가되지 않는다고 생각합니다.

또한 드래그 핸들을위한 약간의 공간을 남겨 두었습니다. 드래그 핸들을 나타 내기 위해 앱에서 자주 사용되는 회색으로 표시된 작은 점이 있거나 마우스 오버시 또는 항상 드래그 아이콘이 표시 될 수 있습니다. 아니면 그냥 비워 둘 수도 있습니다. 기술적으로는 약간 더 얇을 수도 있지만 편안함을 위해 버튼 너비를 그대로 두었습니다.

이것이 될 수 있습니까? 이것이 현재 반복을 대체하기에 충분히 좋은 반복 일 수 있습니까? _ ( "예"라고 말 해주세요. : stuck_out_tongue :) _

여기에서 만든 모든 탐험에 감사드립니다. 반투명도가 이상적이지 않은 이유를 하나 더 추가하기 위해 뛰어 들었습니다. 배경과의 아이콘 대비 비율은 4.5 : 1이어야합니다. 반투명도를 사용하면 불가능합니다. 어두운 색상이 널리 퍼진 이미지, 어두운 배경이있는 단락 또는 어두운 배경이있는 테마를 생각하면됩니다.

여기에서 훌륭한 토론에 감사드립니다. 이 도전에 대한 열정을 보는 것은 가슴이 뛰고 즐겁습니다.

고정 된 도구 모음, 측면의 위쪽 / 아래쪽 화살표, 그리고 결국 오른쪽의 줄임표를 사용하여 블록의 초기 구성을 디자인하면서 멀리서 조금 지켜 봤습니다. 나는 재료를 추가했기 때문에 무버는 항상 자신의 행동을 예측할 수있는 반면, 종종 어리 석고 오류가 발생하기 쉬운 드래그 앤 드롭의 대안으로 무버에게 최고의 부동산을 제공하는 것이 매우 유용하다고 느꼈기 때문입니다.

저는 이것이 중첩 된 블록에 대해 제기하는 문제를 완전히 인식하고 있으며, 최고의 솔루션이 무엇인지 오랫동안 생각했습니다. 마스터에있는 것 (중첩 된 경우에도 왼쪽과 오른쪽으로 겹치는)은 작동하지만 훌륭하지도 않습니다. 또 다른 옵션은 모바일 UI를 사용하는 것입니다. 선택하면 블록 아래에 UI를 표시합니다. 여기에서 다양한 변형으로 모의 된 UI가 특히 모바일에서 작동합니다. 그러나 데스크탑에서는 단락을 선택하여 작은 편집을하고 모든 것이 이리저리 이동할 때 매우 혼란스럽고 불안정해질 수 있습니다. 마찬가지로 도구 모음이 최신 버전 에서처럼 겹쳐지면 쓰기 환경에서 레이아웃 환경으로 너무 멀리 기울어 진 것처럼 느껴집니다. 이것이 우리가 달성하려고 노력한 지속적인 균형입니다.

두 번째 옵션은 내가 가지고 있던 이전 모형으로 돌아가는 것입니다.

아마도 약간의 조정으로 다음과 같을 수 있습니다.

그러나 나는 그것을 좋아하지 않는다. 그리고 _ 둘 다 _ 이것은 블록이 호버링되었을 때만 무버가 보이도록 만들거나, 처리를 약간 조정하고 싶을 것입니다. 또한 버튼 히트 영역을 몇 픽셀 더 작게 만들어 사용성에 좋지 않습니다.

따라서 이러한 변종은 우리가 가진 것보다 우월하다고 느끼지 않았기 때문에 지금까지 고려되지 않았습니다. 그러나 그들이 작동하도록 치료에 영감을 줄 수 있는지 여부에 관계없이 여기에 게시하십시오.

블록 도구를 호버 레이블과 결합 할 때 가장 큰 문제는 선택한 블록의 레이블을 표시하기 시작하지 않는 한 선택한 블록과 호버 된 블록 사이에 불일치를 생성한다는 것입니다. 그렇게한다면 라벨은 블록 경계 안에있는 것이 아니라 바깥쪽에 있어야합니다.

하지만 그렇게하더라도 블록 맨 위에 너무 많은 컨트롤이 있고 넓고 얇은 블록 모두에 대해 일관성을 유지하는 방법을 알아 내야하는 문제에 직면하게됩니다.

화면에 표시되는 고정 도구 모음을 제외하고는 표준 선택된 블록 UI가 해당 블록의 어떤 부분도 가려서는 안된다고 굳게 생각합니다.

맨 아래에 블록 도구가 있으면 형제 삽입기를 배치 할 수있는 좋은 위치를 제공합니다.이 둘은 모두 위의 겹침 없음 목표를 달성하는 데 도움이되는 동시에 형제 삽입기를 더 잘 보이게 만들고 자체 중복 문제를 해결하는 데 도움이됩니다. (나는 중첩 된 블록이 겹치는 형제 삽입 자로 인해 아직 Quote 블록에 업데이트되지 않은 것으로 생각합니다.)

형제 삽입 기와 접근성 이점 때문에 블록 도구를 놓을 수있는 가장 좋은 장소는 블록 아래에있는 것입니다.

이제 컨트롤을 훨씬 작게 만드는 것이 테이블 위에 있다고 생각하지 않았습니다. 물론 컨트롤을 작게 만들면 사용하기가 더 어려워 질 수 있기 때문입니다. 그러나 당신은 그것에 반대하지 않는 것 같으므로 시도해 보지 않겠습니까?

방법이있다?

하단 바의 버튼 (아이콘은 아님)의 크기가 38px에서 32px로 줄어들었고 이전 모형의 무버 컨트롤 사이의 간격이 일치하지 않는 문제를 수정했습니다. 줄임표 버튼이 다른 버튼보다 얇 으면 (편집기 상단 표시 줄에있는 것과 같이) 가로로 조금 더 작게 만들 수 있습니다.

막대가 더 적은 공간을 차지하도록 빈 드래그 핸들 영역의 크기를 줄일 수도 있습니다. GNOME에서 창의 상단 막대가 작동하는 방식과 같이 막대의 모든 컨트롤이 드래그 핸들로 두 배가된다면 훨씬 더 실용적 일 것입니다.

모바일에서 컨트롤은 master 에서와 거의 똑같이 보일 것입니다. 여기서 막대는 공간을 차지하므로 더 크게 만드는 것은 문제가되지 않습니다. 이 크기 축소는 데스크톱 사용자에게만 영향을 미치며 컨트롤은이 크기로 터치하여 계속 사용할 수 있습니다.

또한 컨트롤을 상단 도구 모음으로 이동하여 작은 탐색을 수행하여 문제 집합을 해결했습니다.하지만 블록을 선택하면 좁은 컨텍스트에서 작동하지 않는 Everything 도구 모음을 갖게됩니다. 처음에이 탐사에 대한 중요한 이유입니다.

나는 여전히 마지막 모형에 대해 어떻게 생각하는지 알아 내려고 노력하고 있습니다. 바닥에 매달려있는 컨트롤은 나에게 다소 어색하다. 더 나은 아이디어가 있는지 잘 모르겠습니다. @karmatosed 가 피하고 싶었던 그런 종류의 뭉툭한 / 조각난 느낌으로 뿐입니다 .

모든 작업에 감사드립니다. 피드백을 제공하려고 노력하고 있지만 지금 당장은 이것이 프로토 타입으로 이동할 준비가되지 않았다고 생각합니다. 나는 여전히 네 스팅과 해결해야 할 다른 장치에 문제가 있다고 생각하지만 이전 의견에서 언급했듯이 현재 트랙이 옳지 않다고 생각합니다. 나는 우리가 이미 우리가 이것을 피하도록 제안한 영역으로 다시 향하고 있다고 느낍니다.

탐색을 중단하고 싶지는 않지만 지금 당장은 대안 제안을 고려할 것을 제안합니다. 큰 문제는 하단에 절반의 탭을 추가하면 이득없이 시각적 밀도가 증가한다는 것입니다. 여기서 해결하려는 것이 무엇인지 생각해 봅시다.

• 다른 장치에서 일어나는 일.
• 형제 삽입 (다른 문제에서 수정 될 수 있음) 또는 적어도 상호 작용 방식.
• 중첩 가시성 및 상호 작용 용이성.

이 모든 것의 기본 드라이브는 응답 방식과 중첩 방식이었습니다.

유용성을 높이거나 낮추는 경우 우리가 만드는 것을 고려해 봅시다. 예를 들어, 정상적인 시력을 가진 사람에게는 괜찮은 반면 투명 필름이나 레이어 같은 것을 사용하는 것은 다른 많은 사람에게는 좋지 않습니다. 비디오와 이미지가 많은 복잡한 레이아웃을 생각해보십시오. 이 밀집된 정보 구조에서는 제안 된 것이 유지되지 않습니다.

비디오와 이미지가 많은 복잡한 레이아웃을 생각해보십시오. 이 밀집된 정보 구조에서는 제안 된 것이 유지되지 않습니다.

네, 저는 이것이 가장 큰 포인트라고 생각합니다. 그리고 저는 그 밀도를 더 작은 공간에 추가 할 것입니다. 이것은 또 다른 도전입니다. 중첩 된 블록은 일반적으로 중첩되지 않은 블록이 필요로하는 모든 동일한 제어를 필요로하지만 공간의 일부로, 이상적으로는 고유하지 않은 방식으로 수행해야합니다 (예 : 중첩 된 블록은 일반적으로 중첩되지 않은 블록과 유사해야합니다. 일관성이 발생합니다. 유용성).

드로잉 보드로 돌아 가기… 🙂

내 목업이 현재 UI보다 낫다고 생각하는 이유

나는 뭉툭한 모양을 피하려는 욕구를 이해하지만, 뭉툭 해 보이지는 않지만 여전히 기능적인 것을 찾지 못했습니다. 문제는 작업중인 블록의 가장자리를 알아야하고 컨트롤이 블록의 내용을 가리지 않고 블록 외부를 거의 가리지 않도록해야한다는 것입니다. 그것은 다소 고르지 않은 모습을 보장합니다.

이 문제의 상단에있는 스크린 샷을 보면 구텐베르크가 한 시점에서 블록이 매우 차단되지 않은 UI를 사용하는 방법을 알 수 있습니다. 하지만 그 UI의 문제점은 블록의 가장자리가 어디에 있는지 알기가 어렵다는 것입니다. 그것이 우리가 현재 가지고있는 UI를 가진 이유입니다.

그리고 형제 삽입기에 문제를 던질 때 형제 삽입 기 단추를 블록의 콘텐츠 테두리 밖에 있어야한다는 것을 깨달았습니다. 이를 이전이 아닌 현재 블록 뒤에 삽입하려는 점과 접근성 향상에 대한 욕구를 결합하면 내 최신 모형과 같은 것이 있어야합니다.

개인적으로 나는 첫 번째 모형처럼 보이는 것보다이 블록 UI를 선호합니다. 첫 번째 모형은 콘텐츠와 컨트롤 사이의 경계가 없기 때문에 혼란스러워 보이며 막대는 불필요한 공간을 많이 차지합니다. UI 점프를 원하지 않기 때문에 하단 바는 선택한 블록 외부의 콘텐츠 위에 오버레이되어야하므로 가능한 한 작아야합니다.

또한 내 목업은 현재보다 중첩 된 컨텍스트에서 확실히 더 낫다고 생각합니다. 아래에서 설명 하겠지만 겹치는 툴바 / 컨텐츠 상황은 이전 UI보다이 UI에서 더 좋습니다. 중첩 된 컨텍스트에서는 블록의 경계를 더 많이 알아야하므로 다소 뭉툭한 모양이 실제로이 상황에서 도움이됩니다.

겹치는 도구 모음은 혼란이 적고 문제 가 될 가능성이 적습니다. 작은 화면 에서는

중첩 된 컨텍스트에서 현재 블록 위의 블록 위로 마우스를 가져 가면 아래 블록의 모든 내용을 거의 덮지 않을 것입니다. 그 이유는 블록이 아래쪽 막대가 모든 것을 덮지 않을만큼 충분히 넓거나 그렇지 않으면 블록이 상당히 넓기 때문입니다. 키가 커서 선택할 수있는 여지가 있습니다.

당신이 블록을 가져 가면 또한, 블록의 맨 아래 줄에만 표시해야하고, 단지 마우스가 근처에있을 때. 블록 측면의 이상한 보이지 않는 드래그 핸들로 인해 현재 UI에서는 그렇지 않습니다.

위의 점에 추가하려면 현재 블록 위의 블록 만 선택한 블록의 모든 것을 덮을 수 있습니다. 수평으로 인접한 블록을 가리키면 현재 블록에서 아무것도 가려지지 않으며, 호버링 된 블록은 그 위에 UI가 없으므로 다른 3면은 완전히 괜찮습니다. 따라서 선택한 블록 아래에 블록을 가져가도 괜찮습니다.

또한, 호버링 된 블록이 현재 선택된 블록을 덮지 않도록 선택하면 중첩 된 컨텍스트에서 선택한 블록과 문자 그대로 겹치는 문제가 발생하지 않습니다. 호버 된 블록은 맨 아래에 막대 만 있으므로 현재 블록 아래에있는 블록은 선택한 블록과 겹치지 않습니다. 이 상황에서 포기하는 유일한 것은 선택하지 않는 한 현재 블록 위의 블록에 대한 블록 도구에 액세스 할 수있는 기능입니다.

또 다른 아이디어 : 커서가 다른 블록을 가리킬 때 하단 막대가 자동으로 숨겨 질 수 있습니다. 커서가 블록의 경계로 다시 이동할 때까지 돌아 오지 않습니다. 이것은 중첩 된 컨텍스트에서 더 많은 도움이 될 수 있습니다.

무엇보다도 중첩 된 컨텍스트에서 더 적은 겹침 문제를 원하는 경우 서식 도구 모음을 편집기의 상단 표시 줄에 고정 할 수 있습니다. (이는 모바일에는 영향을 미치지 않지만 모바일에서는 막대가 공간을 차지하고 아무것도 겹치지 않으므로 처음에 겹침 문제가 없습니다.)

전반적으로 더 악화 된 상황보다 최근의 모형으로 개선 된 상황이 더 많다고 생각합니다.

그대로, 내 목업 (또는 그에 가까운)과 같은 것이 생성하는 것보다 더 많은 문제를 해결한다고 생각합니다. 위의 혜택 외에도 다음과 같은 이점이 있습니다.

• 모든 블록 너비에서 작동합니다.
• 형제 삽입 기, 이동 제어 및 줄임표에 대한 접근성이 향상되었습니다.
• 형제 삽입 기 및 드래그 핸들의 가시성과 검색 가능성이 향상되었습니다.
• 블록 측면의 끌기 영역은 제거 할 수 있으며 호버 레이블은 끌기 핸들이 될 필요가 없습니다 (어쨌든 약간 작습니다).
• 형제 삽입 기는 일반적으로 사용하려는 블록 아래에 있습니다 (위와 반대로).
• 별도의 형제 삽입 기 UI가 필요하지 않으므로 복잡성이 줄어 듭니다.
• 형제 삽입자는 더 이상 중첩 된 컨텍스트에서 겹침 문제가 없습니다. (나는 그것이 # 6520이 아직 일어나지 않은 이유라고 생각합니다.)
• 블록을 둘러싼 블록 UI는 해당 블록의 내용과 겹치지 않습니다.
• 블록의 자동 여백을 제거 할 수 있고 블록에는 내부 패딩이 전혀 없을 수 있으며, 블록 UI 테두리는 실제 콘텐츠 테두리로 다시 변경 될 수 있지만 블록의 콘텐츠에는 컨트롤이 겹치지 않습니다. 이러한 종류의 엣지 케이스는 사용자 지정 블록에서 발생하므로이를 고려하는 것이 좋습니다.
• 블록의 반대편에있는 줄임표 및 화살표 이동 자의 이전 상황에 비해 모든 블록 도구는 매우 가깝기 때문에 모든 도구에 접근하고 모두 발견하기가 더 쉽습니다.
• 중첩 된 컨텍스트에서 현재 컨트롤과 함께 자주 발생하는 혼란과 비교하면 컨트롤이 연결된 블록이 무엇인지는 매우 분명합니다.
• 컨트롤은 모바일과 더 일치합니다.

네, 제 목업은 실제로 중첩 된 컨텍스트에서 더 잘 작동한다고 생각하며 블록 UI는 당신이 얻는 것에 비해 거의 중요하지 않다고 생각합니다. 어떻게 생각해? 동의하지 않는 경우 모형이 현재 UI보다 훨씬 더 나쁘고 이전에 언급 한 제안으로 해결할 수없는 상황을 지적 할 수 있습니까?

또 다른 ... ~ 스카이 워커 ~ 아이디어

다른 모든 것이 실패하면 기술적으로 모든 주요 문제를 해결할 수있는 아이디어가 하나 있습니다. 구텐베르크 1.6 에서처럼 서식 도구 모음이 항상 맨 위에 고정되었지만 이번에는 이동 컨트롤과 줄임표가 측면이 아닌 블록 위에 표시되면 어떻게 될까요? (또는 내 모형처럼 바닥에 둘 수도 있습니다.)

이 개념에서는 편집기의 상단 표시 줄에있는 삽입 기가 동일한 기능을 제공하기 때문에 형제 삽입 기가 존재하지 않으며,이 컨텍스트에서는 서식 도구 모음이 동일한 영역에 있기 때문에 더 가까울 것입니다.

모바일 UI는 지금과 똑같습니다. 이 변경 사항은 데스크톱 (및 태블릿) 사용자에게만 영향을 미칩니다.

하지만 더 있습니다!

실제로 생각해 보면이 아이디어와 내 모형을 사용하고 Fix Toolbar를 Top으로 활성화하는 것의 차이점은 무엇입니까? 모바일에서 인라인 서식 도구 모음을 완전히 제거하여 얻을 수있는 유일한 이점은 이동 컨트롤과 줄임표가 아래가 아닌 블록 위에 표시되는 기능입니다. 기술적으로는 도구 모음을 맨 위로 수정 옵션의 일부일 수 있습니다.

측면 UI가 여전히 두 측면으로 분할되고 혼란스러운 보이지 않는 드래그 핸들이 여전히 존재하고 형제 삽입 기가 중첩 된 컨텍스트에서 여전히 겹치기 때문에 Fix Toolbar to Top 이 모든 겹치는 제어 문제를 제거하지 않는 현재 UI와 비교해보십시오. 등

텍스트의 각 단락이 별도의 블록이라는 것이 미래를 위해 확실히 설정되어 있습니까? 그렇다면 블록 도구의 표시는 여러 텍스트 블록 선택을 고려해야합니다.

@padraigobeirn 제가 잊었던 좋은 점입니다.

특히 현재 UI의 컨트롤은 긴 선택 항목을 고려하지 않습니다. 이동 컨트롤과 줄임표는 선택 항목의 첫 번째 블록의 왼쪽 및 오른쪽 상단에 있습니다. 서식 도구 모음조차도 선택 영역의 첫 번째 블록에 대해서만 고정됩니다. # 7962를 참조하십시오.

내 목업의 하단 막대의 경우 위로 스크롤 할 때 화면 하단에 고정 상태를 유지함으로써 이론적으로 여러 선택 항목에서 작동하도록 만들 수 있습니다. 그러나이 고정 동작은 선택한 블록에만 바람직 할 수 있습니다.

아시다시피, 저는 Fix Toolbar to Top 이 기본적으로 켜져 있어야한다고 생각하기 시작했습니다.

현재로서는 블록 주위에 너무 많은 컨트롤을 맞추기 위해 할 수있는 일이 정말 많고, 저의 최신 모형을 사용해도 UI가 혼잡하다고 느낄 수있는 경우가 여전히 있습니다. UI가 너무 뭉툭한 느낌에 대한 우려도 있습니다.

이러한 문제를 해결하려면 서식 도구 모음을 맨 위에 고정하는 것이 기본값이어야한다고 생각합니다. 많은 블록 주변의 공간을 절약하고 가능한 컨트롤 겹침의 양을 대폭 줄입니다.

여전히 아래쪽에있는 이동 컨트롤과 줄임표를 선호하지만 서식 지정 도구 모음이 고정되어있을 때 위쪽으로 이동할 수도 있습니다. 서식 도구 모음을 블록에 연결하지 않으면 어색해 보이거나 너무 많은 공간을 차지하지 않고 블록 도구 모음을 오른쪽 하단 또는 오른쪽 상단에 배치 할 수 있습니다.

그래도 왼쪽 하단이나 오른쪽 하단 중 하나를 선호한다고 생각합니다. 이렇게하면 컨트롤이 시각적으로나 탭 ​​순서로 블록 뒤에옵니다. 블록 뒤에 형제 삽입기를 던지는 것이 블록 앞에 나타나는 것보다 더 의미가 있습니다.

참고 : 최근 Infusionsoft의 이메일 빌더에는 자체 "차단"개념이 있으며 오른쪽 상단의 블록 위에 표시된 블록 도구 (복제 및 삭제)가 있습니다. 커서가 텍스트 영역에 들어가면 편집기 상단의 막대에 서식 제어가 나타납니다.

나는 최근에 Infusionsoft의 이메일 빌더가 실제로 자체 "차단"개념을 가지고 있고 오른쪽 상단의 블록 위에 표시된 블록 도구 (복제 및 삭제)가 있음을 확인했습니다. 커서가 텍스트 영역에 들어가면 편집기 상단의 막대에 서식 제어가 나타납니다.

@SuperGeniusZeb 인터페이스의 일부 스크린 샷을 클립 해 주시겠습니까?

구텐베르크를 처음 사용하기 시작했을 때 나는 확실히 "도구 모음을 맨 위로 수정"하는 사람 이었지만 한동안 사용 했으므로 다시 돌아가고 싶은지 모르겠습니다. 도구 모음은 여러면에서 이러한 모든 문제의 원인이라는 것을 완전히 인식합니다. 중첩 된 컨텍스트에서 잘려나 가고 측면 컨트롤에 사용할 수있는 공간을 차지하는 많은 항목이있을 가능성이 가장 높지만 블록과 짝을 이루는 것은 너무 좋습니다. 필요한 모든 것을 한곳에 보관하고 많은 눈동자와 마우스 움직임 등을 피합니다. 지금 말하면 놀랍지 만 그게 없으면 살 수 없을 것 같아요.

@SuperGeniusZeb 인터페이스의 일부 스크린 샷을 클립 해 주시겠습니까?

@chrisvanpatten 아니요, 누군가를 돕는 동안 일시적으로 만 액세스 할 수있었습니다.

고정 / 비 고정 서식 도구 모음에서 어느 쪽이든 강하게 느끼지는 않지만 블록 주변의 시각적 혼란을 줄이는 데 도움이 될 것이므로 고정쪽으로 기울일 것입니다. 사용자 피드백을 바탕으로 다른 사람들은 무엇을 선호하며 그 이유는 무엇입니까?

@chrisvanpatten 누군가가 Infusionsoft의 이메일 작성기에 대해 이야기하고 이에 대한 비디오가있는 기사를 찾았습니다.

https://www.monkeypodmarketing.com/the-new-email-builder/

@chrisvanpatten Argh, 방금 확인한 결과 해당 비디오가 오래된 것 같습니다 ... 그때는 구텐베르크가 지금하는 것처럼 서식 지정 도구 모음이 블록에 첨부 된 것 같습니다. 하지만 그들이 그것을 바꾼 것은 흥미 롭습니다.

몇 가지 생각 :

게시물 중간에 블록을 삽입하려는 경우 일반적으로 선택한 _ 후에 _ 블록을 삽입하고 싶습니까? 일반적으로 선택한 블록을 _ 앞에 _ 삽입하지 않습니다. 블록 뒤에 삽입하는 것도 접근성 관점에서 의미가 있습니다. 누구든지 이것에 동의하지 않습니까? 나에게 이것은 형제 삽입자가 블록의 맨 아래 어딘가에 나타나는 것을 선호하는 강력한 주장처럼 보입니다.

형제 삽입자는 선택한 블록의 내용과 겹치지 않아야합니다. 선택된 블록의 내용과 영구적으로 겹치면 안됩니다. 누구든지 이것에 동의하지 않습니까? 이것은 형제 삽입자가 선택된 블록의 내용 외부에 위치해야한다고 믿게합니다.

나는 이동 컨트롤과 줄임표가 어디로 가야하는지에 관계없이 형제 삽입자가 선택된 블록 아래의 일종의 도구 모음에 나타나야한다고 생각하기 때문에 이것을 지적합니다. 테두리 / 배경이 없습니다. 지금과 거의 똑같이 보일 수 있지만 아래쪽으로 이동하여 블록 위가 아닌 아래에 표시되도록 변경되었습니다.

또 다른 생각 : 줄임표를 이동 화살표와 같은쪽에 배치하는 것이 master 보다 개선 된 것일까 요? 아니면 그 반대일까요? 그러면 중첩 된 컨텍스트에서 중첩 된 컨트롤과 관련된 많은 문제를 해결할 수 있지만 블록의 왼쪽 (또는 오른쪽)에 더 많은 양의 블록 UI가 있어야합니다.

방금 # 8836을 사용해 보았습니다. 병합하면이 티켓의 많은 UI 디자인이 가지고있는 것처럼 보이는 무겁고 막힘있는 UI 문제를 줄이는 데 도움이 될 수 있다고 생각합니다.

티켓 # 9074 및 # 9075에서 저는이 토론에서 영감을 얻은 두 가지 아기 단계를 제안하여 상황을 완화하고 개선합니다. 첫 번째 제안에서는 줄임표 / 추가 버튼을 도구 모음으로 이동하여 사이드 UI (이동) 중 하나만 있고 다른 하나에는 블록 도구 모음이 더 잘 맞도록 설정을 축소 할 수있는 제안이 있습니다. 얇은 컨텍스트.

최신 상태로 유지하기 위해 @jasmussen 의 티켓에서 제안한 변경 사항과 3.6의 최근 UI 변경 사항을 고려하여 모형을 업데이트했습니다.

실제로 # 9074 및 # 9075가 구현되면 화살표 이동기를 블록 아래로 이동하는 것이 더 이상 필요하지 않을 수도 있습니다. 인접한 블록의 줄임표가 더 이상 기둥과 같은 것들에서 중첩되지 않기 때문에 블록의 측면에 머무르면 괜찮을 수 있습니다. # 8880, # 8881 및 # 8883에 대한 솔루션이 발생하고 # 8836 및 # 8920이 구현 된 경우 UI가 이미 중첩 된 컨텍스트에 적합 할 것입니다. 나는 위쪽 / 아래쪽 화살표가 블록의 왼쪽에 머무르는 것이 괜찮은쪽으로 기울이기 시작했습니다.

즉, 형제 삽입 기가 블록 아래에 확실히 속한다고 생각 하지만 형제 삽입 기가 블록 아래에 혼자 나타나도록 할 수는 있습니다. 아마도 현재 형제 삽입 기처럼 중앙에 위치 할 수 있지만 위 / 아래 이동 컨트롤처럼 작동하고 보이며 블록의 아래쪽 부분 내부를 가리키면 블록 아래에 떠있는 버튼으로 나타납니다.

@jasmussen 이 # 9074와 # 9075에서 작업하고있는 반복을 얻는 데 집중 해 보겠습니다. 그러면 다음 단계를 고려할 수 있습니다. 나는 완전히 많은 것을 바꾸고 싶었지만 균형을 잡자.

앞서 언급 한 # 9074 및 # 9075와 # 8920 및 # 9197과 같은 다른 문제 및 PR 덕분에 화살표 이동기를 블록 아래로 이동하는 것이 더 이상 많은 이점이 없다고 결정했습니다.

대신 형제 삽입 자만 블록 아래로 이동하여 위 / 아래 이동기와 유사한 플로팅 컨트롤로 작동하고 표시되도록 제안하고 있습니다. # 9202를 참조하십시오.

이 토론과 다른 토론에서 많은 개선 사항이 나타 났으므로 지금은이 문제를 종료하겠습니다. 마지막으로 몇 가지 개선 사항은 후행 삽입 기 주변에 있습니다.