Include more hints throughout Discourse that link to relevant Docs on Meta

배경

Discourse 팀은 여러 곳에서 관리자 경험(admin experience)을 개선하고자 한다고 언급했습니다.

문제

Discourse에는 설정이 많고 문서도 방대합니다. 하지만 필요한 순간에 올바른 문서를 찾기는 쉽지 않습니다.

기능 제안

Discourse의 설정과 메뉴에서 https://meta.discourse.org/docs에 있는 해당 문서를 링크할 수 있는 곳이 훨씬 더 많을 수 있습니다.

예를 들어, Discourse 설치 환경에 링크되어 있는 Understanding Discourse Trust Levels 블로그 게시글이 있습니다.

하지만 링크가 없는 문서들이 훨씬 더 많습니다.

예를 들어, 카테고리를 삭제하는 방법에 대한 안내 문서가 있습니다.

카테고리 삭제 버튼을 볼 수 있는 모달 창에 이 문서를 포함하는 것이 관련성 있고 유용할 것 같습니다.

링크일 수도 있지만, 모든 경우에 반드시 링크일 필요는 없습니다. 문서로 연결되는 물음표 버튼이나 “더 보기…” 등으로도 가능합니다.

Discourse 팀은 주요 문서부터 시작하여 문서들을 살펴보고, 소프트웨어 내에서 해당 문서로 연결하는 것이 가장 적절한 위치가 어디인지 파악할 수 있습니다.

(즉, “필요할 때(Just-in-time)”)

다른 소프트웨어 사례

Ghost(오픈 소스 블로그 소프트웨어)는 필요한 순간에 바로 문서로 연결되는 링크가 있는 몇몇 부분이 있습니다.

예를 들어, 이 ‘자세히 보기’ 버튼은 관련 문서로 연결됩니다:

여기서도 마찬가지입니다:

Contribute > Feature 또는 Contribute > UX 중 어디에 해당되는지 확실하지 않아, 자유롭게 이동해 주세요.

5개의 좋아요

I’ll have to disagree slightly with that. There are different scopes of help content you can make. If we go by the Diátaxis model, it’s tutorials, how-to guides, references and explanations.

Tutorials probably have a place to be linked in the app itself, such that if you go in on a page with the intent “I want to learn how this works”, you can learn it, even if the page isn’t self-explanatory. Perhaps even a tutorial center which essentially lets you complete a course on the software if you wish.

The other 3 categories I take some issue with.

If I go to the category settings page, there might be 20 different things I’d want to do. Putting a how-to guide there would result in a list I’d have to search - and because I have an expectation that what I’m out for won’t necessarily have a dedicated how-to article, I’ll probably type that question into Google instead of searching through the list.

Off-site references are a bane I have to deal with daily. We have a “reference manual” which will tell you what each slider and button does, down to:

Cancel button: Closes the dialog without applying changes
OK button: Closes the dialog, applying the changes

Using this reference means you have to scroll past a lot of technical stuff before you get to your section, when what you really needed is a tooltip which rephrases an option in a few more words.

If I try to delete a category, the current behavior is almost desirable. I see the button, usually greyed out but with a questionmark, and if I click it, it says:

Can’t delete this category because it has sub-categories.

or:

Can’t delete this category because it has 25852 topics. Oldest topic is…

The behavior is good, I know what’s wrong and what my next step is - delete a bunch of posts and subcategories. It would not be improved by linking to the “delete a category” how-to guide instead.

Of course, it still is a band-aid fix to the real problem: Why doesn’t it let me delete a category with posts in it? I can delete folders with subfolders and files on my system, why can’t I delete categories with subcategories and posts? If it didn’t have these weird restrictions, there wouldn’t be a need for a how-to guide in the app to begin with.

And lastly, explanations - that is what the “understanding trust levels” blogpost is. When I first encountered it, it was pretty confusing - “is a random blogpost from 6 years ago really the best you have as documentation?” - and it links out to a reference article which lists out all the things in a table, which was more in line with what I expected (though not sorted in the way I expected). Explanations do not help me figure out a task directly, so putting them in a place where a task would be completed doesn’t work too well.


I think that ultimately, while documentation is important in a few places (eg onboarding, or in instances where design fails), it really is the design which should be the primary focus. Reading or watching a video in which someone explains the website to you rarely is the desired experience.

5개의 좋아요

Yeah as a past game design student, I wholeheartedly agree with you there. (I remember you’re designer for Audacity. Btw I use Audacity a lot, very grateful for it!)

I think as well that the whole experience could be rethought from the ground up (starting with thinking: “what would an admin like to do, and how can we best help them do that?” for all use cases) to both have the processes be conveyed much better and also have the processes themselves be as straightforward as possible.

For the example there — of not allowing you to delete a category if there are topics in it — a more graceful way of the software handling that could be like this. When you try to delete a category with topics in it, it could first suggest if you would like to:

  • move all the existing topics to another category, or
  • put all the existing topics into Uncategorized, or
  • delete all topics in the category

and then confirming that you would like to delete the category.

I guess seeing that the Discourse team was going for more incremental changes at this stage:

I was appealing for a lower hanging fruit – adding some links to the most popular/common/major docs where it would be most relevant.

(I might also make a new topic later on for the feedback/suggestions we have talked about here, on improving the experience for deleting categories.)

I like this suggestion a lot - thanks for highlighting it, @traceymoko! We’re currently working on improving the general structure and categorisation of our documentation, and I think this kind of feature would be worthwhile to consider as part of that process. I’ll add it to the documentation roadmap as something to explore, and we’ll see how best it could be implemented.

2개의 좋아요

Sorry to revive an old topic, and very much aware of the current work that’s happening around Admin search and improving the overall Admin experience. Many times in the last few weeks I’ve been thinking how much I wish that the Name of each Site Setting was a link to the relevant documentation topic on Meta. Over the past few years the Meta documentation has improved vastly, and is now quite comprehensive, organised, and informative.

Example:

In the above example I’d like “Backup location” to link to a Meta topic like Configure automatic backups for Discourse

Could we gradually approach a stage where each of these Site Setting names would link back to the relevant Meta thread? I can see you might not want to hard-code URLs into Discourse code, but I guess it could be in the Site Texts somehow.

The work of doing all this linking is quite large, but perhaps a crowd-sourced effort across a number of self-hosters would be possible?

3개의 좋아요