normal New article editor criteria

Author
Message
Chris_Ilias

One of the biggest areas we have had problems in terms of making the contributor experience better is in the article editor. We would like to put forth a design for a new better article editor, that will make contributing to the knowledge base faster and less confusing. I'd like to open a discussion about the criteria for the new editor.

Here are my thoughts:

  • One of the plan from the very beginning of the support project was to have a "What You See Is What You Get" (WYSIWYG) editor. The SHOWFOR feature will make this a litle tricky, so we may need something like tabs. In addition, you wouldn't have to save an edit to see SHOWFOR work.
  • Adding and removing tags sucks. There are often slight variations in tags names, meaning two or more articles that should have the same tag, end up not having the same tag. It would be nice to know which tags have already been created. (either through auto complete, or using checkboxes to add tags)
  • The additional categories sometimes get misused. It very rarely makes sense to change them after the article is created. Perhaps it would be better to only set them when creating a new article, and only make available afterward for admins/locale leaders. The in-product help checkbox is certainly one that should never be touched.
  • Copying and pasting content labels or sample codes from the Using SHOWFOR tutorial is something that is often needed. We need the ability to quick paste often used content.
  • Not many people are citing references when adding content to articles, or even explaining their changes. I've already filed a bug on making the summary field mandatory, and relabeling it to something that includes asking for a reference. But maybe there are other ways to fix this. Perhaps a reference field?

Some minor things:

  • We need our own custom images for quicktags, and to re-evaluate which quicktags are needed.
  • Upload image should be part of quicktags.
  • {SHOWFOR(spans=on)/} should not have to be added manually.
  • Increase the size of the content area.
  • Make the category selector less abusable. Perhaps turn it into a drop-down menu.
  • The "Alert translators" checkbox is already going to be removed on non-English articles, and we should rename it to be more clear of its purpose.


  • I don't know what you mean by tabs with SHOWFOR but I agree that it needs to be easier to use, without having to go to Using SHOWFOR page to figure it out.
  • I don't really understand how tags are used. Are they are somehow tied into the Related Articles section? If you want to use tags to categorize related articles then I think it would be better to have a standard set of tags that can be selected by editors, maybe from a list that is linked from Contributor Tools.
  • I never pay attention to additional categories, maybe because I no longer create new articles, since you went over to the bugzilla system for article requests ( I guess needing to create a bug report first, or getting someone to assign you the bug, is the main reason I only edit existing articles now).
  • Copying and pasting content labels or sample codes from the Using SHOWFOR tutorial is something that is often needed. We need the ability to quick paste often used content.
    Agree.
  • Not many people are citing references when adding content to articles, or even explaining their changes. I've already filed a bug on making the summary field mandatory, and relabeling it to something that includes asking for a reference. But maybe there are other ways to fix this. Perhaps a reference field?
    The summary field is a pain, since it doesn't always display everything you include (if you add a reference link, it is likely to get cut off). In the past, I've added additional documentation to the comments section of the staging copy article, but that's not a good solution. Recently I've been including reference links as tiki comments within the article, next to the related content. (see attached screenshot) A reference field is good but but I would like to be able to add a reference right next to the content that needs it, and have it show up when viewing the article itself, not just the article History.

    The ideal (for me) would be references that are visible in the article, as numbered links (as in MozillaZine). I know you don't want references to be visible to end users but maybe reference links could appear in the staging copy? If that's not possible then a reference field (with clickable links?) that's visible in the article History is easier to review than tiki comments that can only be seen in the page source. If you do include a reference field, where would it be and how would the content of a reference field be visible? Could links be made clickable?

While you're asking for input, would it be possible to preview how an edited article compares with the previous version, like you can compare versions in the History, without having to save the edit first?



Chris_Ilias
Quote:
*I don't know what you mean by tabs with SHOWFOR but I agree that it needs to be easier to use, without having to go to Using SHOWFOR page to figure it out.

By "tabs" I mean having a |Windows|Mac|Linux| tab so see what the article looks like for Windows users, Mac user, and Linux users respectively.

  • Yes, the Related Articles list is entirely dependent on freetags.
  • I think maybe having a quicktag for "reference" might be good for making it easier to add ref links within the article source. Where it is added is not as important as providing approvers with some sort of reference. The problem is that most people are not backing up their edits ("backing up" meaning proving that the info is valid).

If we do have a separate field for entering the reference, I imagine it would be coupled with the edit summary field. But that's what this discussion is for, what do you think is the best place for it? :-)



Chris_Ilias

Right now, we have the ability to add freetags without opening the article editor, yet to remove a freetag you need to go through the article editor. It would help streamline the editor if removing freetags was made separate from the editor as well. What do you think?



Chris_Ilias

In addition, one of the patches checked into the site lastnight was making the edit summary field mandatory. FWIW.



Chris_Ilias

Another thing: We don't really need the category selector when editing staging copies.



Chris_Ilias

Something I realized: If we're switching to WYSIWYG, that means we will not be able to use hidden content (tiki comments).



underpass

Hello,

Since I usually translate the whole article text offline and use the editor window only for the final corrections, it could be a good idea to add a link to download the source (now I copy-paste the source).

Thanks



Chris_Ilias

These are text mockups:
staging_copy_non-locale_leader.xhtml
creating_an_article.xhtml

"Insert Image" button will pop up a prompt for:

  • image uploader (mandatory)
  • image height
  • image width
  • alignment

"SHOWFOR" dropdown will include:

  • Windows
  • Mac
  • Linux
  • Windows and Mac
  • Windows and Linux
  • Mac and Linux

--separator--

  • Firefox 3.1
  • Firefox 3.0
  • Firefox 3.0 and 3.1
  • Firefox 2

(when Fx2 support ceases, we should remove the last two)

Dynamic content dropdown will include all content labels for the language assigned to the article.



Show posts