Page MenuHomePhabricator

Determine various modes of editing in CollaborationKit and design interfaces accordingly
Closed, ResolvedPublic


To start...

We have (at the moment) two content models, and sub-models within those. (We may decide to break them out into dedicated content types.) We have:

  • Hubs (main hubs), i.e. WikiProjects, which include an introduction, announcements, member list, and sections based on transcluded subpages of arbitrary content models, as well as an auto-generated table of contents based on the transcluded sections.
  • Hub subpages, which are basically wikitext pages but with additional metadata that allows for things like automatically loading the navigation icons
  • Structured lists, typically of articles, that have built-in sorting functions and the ability to selectively transclude them (T129271), consistent with WPX design principles.

We currently have either a generic editing interface that represents the bare minimum and is very unintuitive (i.e. Special:EditCollaborationHub) or the wikitext editing interface, showing raw JSON in an edit window. We should have editing interfaces tailored to those specific content models, including flashy JavaScript stuff where appropriate as well as non-JS fallback. The first step is designing this interface.

Related Objects

Event Timeline

Harej renamed this task from [Basic Functionality] Determine points of interaction on CollaborationKit to Determine various modes of editing in CollaborationKit and design interfaces accordingly.Jun 2 2016, 12:37 AM
Harej updated the task description. (Show Details)

In addition we also have the one-click member signup (T119357), which might get its own editing interface (especially as a non-JS fallback; I imagine with JS, it would just be click and you're done).

T129247 is also relevant; we should have fields dedicated to tagging pages/categories as part of (or explicitly not as part of) the WikiProject.

Okay, here's what I've got. Most of it's pretty straight-forward. I'll make some graphics for 2 so it makes more sense; the rest mostly just needs it on the page in roughly that order and working, and I can style it later.

1. mainpage:
	add 'add feature' link to cactions: 
		popup asking for title (goes to 3.1)
	replace 'edit' label with 'manage wikiproject' (goes to 2)
	add links to each subpage (feature) section header: 'edit' (3.1), 'view full feature' (4)
	add button to any redlink (added through direct editing?) subpage (feature) header: 'create now' (3.1)
	members: special case section; add button to 'add yourself' (5; falls back to 3.2), links to 'manage', 'view all'

2. specialeditcollaborationhub mode MAINPAGE
	special interface for adding and removing pages (features) from list quickly
		edit/remove links
	drag-to-move around the page (up/down)
	(they will normally all be subpages, but not always)
	input field at bottom for adding new ones (usually that already exist, but not necessarily; can also be a workflow for creation if people don't want to use the popup, or want to queue a bunch for creation at the same time or stuff)
		autocomplete defaults to finding existing subpages; can do non-subpages by prefacing them with a ':'

3. specialeditcollaborationhub mode SUBPAGE
	3.1 mode create:
		extra field: target title (this is generally prefilled by however they got here in the first place, and the same as the url parameter usually, but we still show it to let them change it in the interface here)
		extra field: 'content type' (dropdown of supported content types, mostly lists and wikitext)
		We make them create the page first, and then bring them back to edit it (3.2): submit creates it, and then dumps them on the same page, but in mode edit
	3.2 mode edit:
		basically as is, but as a backend change actually use the content types properly

4. subpage:
	replace 'edit' label with 'manage feature' (goes to 3.2)
5. member signup
	popup asking for confirmation: 
		checkboxes for opting into metrics reports (default yes) and getting notifications (default yes)
		'sign up' button that edits the page (feature), adding them
		dump user on members page (feature) after so they can see themselves on it

Note: Unless bawolff magically fixed this for me, specialeditcollaborationhub does not currently support page creation at all. This needs to be fixed.

I'm not sure if it's actually a good idea to have this many modes of specialeditcollaborationhub. Does this make sense?

Also let me know if graphical depictions are needed for any of the other bits, or if anything doesn't make sense.

@Bawolff: enough information for your purposes?

@Isarra: We still need an interface for editing lists

@Bawolff came up with a basic concept for editing the list. We can add more editing modes later if we need to. Marking as done.

FWIW, the interface on list editing

List editor (800×1 px, 105 KB)
is mostly meant as a place holder, its really ugly, and probably needs more design love.

Numbered components refer to the enumeration in Isarra's notes.

(1) is represented in T138014
(2) is represented in T138012
(3) and (4) are represented in T138015
(5) is represented in T119357