Page MenuHomePhabricator

Design a usable heterogenous wiki farm UI
Open, MediumPublic5 Estimated Story Points

Description

In scope: creation and editing of wikifarms with different settings for subwikis

What we want:

  • As a user, I want to make a wikifarm with multiple wikis that are configured differently (e.g., different extensions, different skins, different...etc)
  • I would like to be able to do this, in the base case, without JavaScript
    • It doesn't have to look as nice as with JavaScript
    • Fields may not update dynamically as if I had JavaScript
    • BUT I should be able to configure multiple wikis differently within a wikifarm

Problems:

  • Our UI is getting cluttered
  • We currently create the "create wiki" form in PHP, so adding a bunch of fields in response to user actions would mean initially hiding a bunch of fields somehow (there may be workarounds via https://www.mediawiki.org/wiki/OOjs )

Possibilities:

  • Adding more fields to our create (on the home page)/edit screens and figuring out how to make that look acceptable for both the base-case of noJS and using JS
  • Using a "wizard"/editor – using multiple screens to walk folks through the process

AC:

  • Find a workable UX solution that would enable "What we want" which should cover
    • How does this work from the code side; i.e., how does that work in PHP/JS world
    • What does it look like from the design side?

Event Timeline

Ideas from meeting discussion:

  • Non-javascript version could be multiple pages when creating a wikifarm vs. having everything on the one screen
  • JavaScript version could dynamically load this
  • One option could be to have alternate pages that users can opt into
    • One difficulty is those page may diverge over time/more to maintain
    • Personally, hoping to avoid if we can find a nice alternative.

Let's try to sketch some ideas and come to a quorum on 2026-02-05 (two weeks from now)

  • One option could be to have alternate pages that users can opt into

Why would different users (as opposed to different wiki creations) need different pages? How would the pages be different? (If I fill in a number in the wiki count box and that causes me to land on a new page, I wouldn’t call that an “opt-in”, that’s just a wizard step.)

  • One option could be to have alternate pages that users can opt into

Why would different users (as opposed to different wiki creations) need different pages? How would the pages be different? (If I fill in a number in the wiki count box and that causes me to land on a new page, I wouldn’t call that an “opt-in”, that’s just a wizard step.)

The idea here is like different subdomains like reddit does. I added this as notes from our meeting—brainstorming! Ultimately, not an idea we're apt to pursue.

thcipriani triaged this task as Medium priority.
thcipriani updated the task description. (Show Details)
thcipriani set the point value for this task to 5.

@EBomani covered the design side of this task over in the parent task:

Brainstormed some potential designs for the UI that would allow for feature expansion without affecting too much of the existing structure and workflow and while using the space effectively. These are not final and are here mainly for documentation purposes as we continue discussing the path forward and await more information from actual UI/UX professionals at the foundation since it feels warranted for a change at this scale.

The considerations on usability without JS are something we are keeping in mind and since we have not ventured into using Codex before, this is still to be determined. Will communicate updates regarding the evolution (or complete overhaul) of the design as iterations go on and more information is gathered.

Currently:

PatchdemoSketchCurrentAnalysis.png (1×1 px, 2 MB)

This image shows how valuable visual real-estate is being used on Patch demo and the potential areas of improvement as a starting point.

Version 1:
To make adding new features to Patch demo visually cleaner and the UI scaleable, Codex assets like form templates and tabs for pagination and navigation (among other things). The aim here is for the creation form to have ample space that allows for iteration and scaling with regards to features and patchdemo capabilities without growing to an overwhelming degree and physically demanding more of the page. This version uses tabs to have 4 distinct sections with the settings divided into their relevant categories. One thing to note is "Wikifarms" gets its own tab and in it, specific configurations for wikis can be achieved by allowing customization. It has been noted that this step should probably come earlier in the creation process or be combined with the general settings, but those options are yet to be brainstormed.

The sketches below illustrate the most important thing: with this format, the process of wiki creation improves (less scrolling to create a demo), and also becomes something we can expand on in a much easier way.

PatchdemoSketchVersion1Page1.png (2×1 px, 1 MB)

PatchdemoSketchVersion1Page2.png (2×1 px, 1 MB)

PatchdemoSketchVersion1Page3.png (2×1 px, 1 MB)

PatchdemoSketchVersion1Page4.png (2×1 px, 1 MB)

PatchdemoSketchVersion1Page3-WF1.png (2×1 px, 1 MB)

PatchdemoSketchVersion1Page3-WF2.png (2×1 px, 1 MB)

Again, none of this is final and this task will be updated as it goes. Implementation will only happen after proper approvals occur this as it is a very significant change and will determine how future feature integration occurs. Thanks!

Remaining: how do we make something like this usable for both JS and non-JS users?