추상 위키백과/업데이트/2022-06-10

This page is a translated version of the page Abstract Wikipedia/Updates/2022-06-10 and the translation is 100% complete.
추상 위키백과 업데이트 Translate

메일링 리스트를 통한 추상 위키백과 IRC의 추상 위키백과 텔레그램의 위키함수 마스토돈의 위키함수 트위터의 위키함수 페이스북의 위키함수 유튜브의 위키함수 위키함수 웹사이트 Translate

위키함수에 대한 권장 사항

디자인 연구원인 제프 하워드는 출시와 그 이후의 문제에 우선 순위를 지정하기 위해 또 다른 연구를 수행했습니다. 사용자 연구의 전체 보고서가 메타에 게시되었습니다. 추상 위키백과 팀의 디자이너 아이쉬와라는 연구 결과를 읽고 분석하여 슬라이드 데크에 요약했습니다. 이번 주에 아이쉬와라는 팀에 이 덱을 발표했으며 여기에서 프레젠테이션에 대한 간략한 요약을 제공합니다.

함수 페이지를 디자인하는 목표는 두 가지입니다. 모든 배경의 기술적인 사람들이 이해할 수 있고 사용할 수 있게 하는 것이고, 낮은 수준의 프로그래밍 전문 지식을 가진 사람들을 환영하는 것입니다. 기술 기여자는 함수 생성 워크플로와 위키함수 멘탈 모델을 이해해야 합니다. 피그마에서 아이쉬와라의 디자인을 사용하여 7명의 기술 참가자를 인터뷰했습니다(화면의 아무 곳이나 클릭하여 슬라이드를 진행하고 창을 확장하는 것을 잊지 마세요).

인터뷰 대상자들은 많은 훌륭한 질문을 제기하고 많은 디자인 작업을 검증했으며 개선해야 할 몇 가지 영역을 식별했습니다. 전반적으로 보고서는 기술 인력이 이해할 수 있고 사용할 수 있는 사용자 인터페이스의 명시된 설계 목표를 충족했음을 확인했지만 보고서는 기여자가 함수 생성 워크플로와 일반적인 위키함수 멘탈 모델을 실제로 이해하지 못했다는 점도 강조했습니다. 요컨대, 그들은 모든 일을 끝낼 수 있었지만, 그들이 하는 일과 그것이 왜 그런 식으로 표현되었는지에 대해 종종 혼란스러워했습니다.

저는 잘 된 많은 것들에 들어가지 않을 것이다. 전체 보고서와 슬라이드에서도 이에 대해 읽을 수 있습니다. 작업 요약 다이어그램에 대한 찬사를 불러일으키고 싶습니다. 이는 채팅 및 위키미디어 커뮤니티 구성원과의 다른 상호 작용에서도 얻은 다른 많은 반응과 일치합니다. 저는 또한 이 기회를 사용하여 아이쉬와라의 디자인 작업에 대해 축하하고 그것이 매우 긍정적으로 검증되는 것을 보고 싶습니다. 우리 모두는 여러분이 가지고 놀 수 있도록 구현된 디자인을 얻고 이를 개선할 수 있는 방법에 대해 더 많이 배우기를 고대하고 있습니다.

인터뷰 대상자들은 특히 놀라움이나 혼란의 원인으로 두 가지 점을 지적했습니다. 함수 정의와 구현 간의 분리, 그리고 위키함수의 다국어 특성입니다.

위키함수에서는 각 함수가 여러 구현을 가질 수 있도록 허용합니다. 우리는 구현이 위키함수의 자체 페이지가 되도록 함으로써 이를 달성합니다. 이러한 분리는 새로운 개념이 아닙니다. C++ 또는 Ada와 같은 프로그래밍 언어에는 수십 년 동안 헤더 및 구현 파일이 있었고 객체 지향 언어에는 다른 클래스에서 구현할 수 있는 인터페이스가 있습니다. 그러나 인터뷰 대상자들은 반복해서 바로 구현을 제공하기를 원했습니다. 그들은 구현을 제공하기 전에도 함수의 정의를 게시할 수 있다는 사실에 혼란스러워했습니다. 이것은 이전 사용자 테스트에서 본 요청이기도 합니다.

부수적으로, "게시"라는 작은 단어는 여기에서 정말 많은 힘을 주었습니다. 오래전 위키백과에서는 기여자가 편집한 내용을 저장할 수 있는 버튼에 대해 "저장"이라는 단어를 사용했지만, 2017년에 위키 사용자가 단순히 "저장" 편집은 온라인에서 공개적으로 모든 사람이 영원히 볼 수 있도록 합니다. 이 사용자 연구는 "게시"라는 단어가 기여가 실제로 전 세계에 적용될 것임을 분명히 한다는 점을 반복했습니다. 그러나 동시에 여러 인터뷰 대상자들은 아직 구현되지 않은 함수 정의만으로는 게시하기에 유용하지 않은 것 같다고 느꼈습니다. "게시"라는 단어는 실제로 그 대조를 이끌어 냈고 사용자의 멘탈 모델에서 이러한 불일치를 식별하는 데 도움이 되었습니다.

상당히 강한 반응을 불러일으킨 두 번째 요점은 위키함수의 다국어 특성이었습니다. 그것은 위키함수의 설계에서 종종 묻지 않는 질문 중 하나입니다. 왜 다국어여야 합니까? 다른 언어로 레이블을 지정하는 이유는 무엇입니까? 코딩하고 싶은 사람은 다 영어만 배우지 않나요? 인터뷰 대상자 중 한 사람의 말을 인용하자면 "일반적으로 다른 언어를 구사하는 사람들은 코딩을 위해 영어를 배우기만 하면 됩니다"

코딩의 세계는 정말 영어 중심적이기 때문에 코딩 경험이 있는 사람 중에 기초적인 영어를 하지 못하는 사람을 찾기가 매우 어렵습니다. 인터뷰에 응한 모든 기고자들은 실제로 영어를 구사합니다.

프로그래밍의 영어 중심성이 많은 사람들에게 주요 장벽이라는 것을 보여주는 많은 연구 연구가 있었습니다. 자신의 언어를 사용하여 코드를 작성할 수 있는 사람들은 더 빨리 결과를 얻을 수 있습니다. 영어를 못하는 부모에게는 자녀가 프로그래밍을 배우도록 돕는 것이 더 어렵습니다. 이러한 연구 결과와 기타 연구 결과를 기반으로, 우리는 우리 자체 사용자 연구의 권장 사항에서 의도적으로 이탈하기로 선택했습니다. 이는 이것이 특히 지식 형평성에 대한 위키미디어 2030 운동 전략 권장 사항과 더 잘 일치한다고 믿기 때문입니다.

작지만 아주 좋은 점들이 많이 제기되었습니다. 기여자들은 함수를 더 자세히 설명할 수 있는 공간을 요청했습니다(이는 개발 계획의 다음 단계인 이오타(ι) 단계에서 계획됨). "별칭"이라는 용어는 사용자를 혼란스럽게 합니다. 유형 목록이 너무 단순했습니다. 예제 테이블은 복잡한 항목에 대해 확장되지 않을 가능성이 있는 장소로 식별되었습니다. 구현 및 테스터를 보여주는 표에서 "사용 가능"과 "제안" 및 "검증됨"이라는 단어의 차이는 혼란스러웠습니다. 그리고 꽤 많이 더 있었습니다.

우리는 또한 개선할 수 있는 더 큰 영역을 식별했습니다. 언어 사용을 전체적으로 일관되게 만들고, 더 많은 메타데이터를 즉시 표시하고, 정의와 구현을 더 명확하게 구분하기 위해 텍스트를 개선했습니다. 우리는 이러한 디자인 과제를 해결하기 위해 노력할 것입니다.

우리는 디자인을 통해 모든 기여자가 자신의 작업을 수행할 수 있다는 사실에 안도하고 기쁩니다. 우리는 이러한 디자인을 구현하고 여러분에게 제공하게 되어 매우 기쁩니다. 여기 또는 전체 보고서에서 논의된 문제에 대한 아이디어나 제안이 있는 경우 여러분의 의견을 듣고 싶습니다.

인터뷰에 응한 모든 기여자, 연구를 수행한 제프, 결과를 요약해 준 아이쉬와라에게 감사합니다.


6월 3일 업데이트: 수정 주간

  • 5월 30일 – 6월 3일은 추상 위키백과 팀의 '수정' 주간이었습니다. 이번 주 동안 팀은 새로운 기능 개발을 일시 중지하고 기술 부채와 관련된 작업에 집중했습니다.
  • 디자인 업데이트: 이번 주에 팀은 '목록' 구성 요소에 대한 디자인 작업을 시작했습니다.