Create a complete design of a Jade entity page that allows viewing/editing proposals and endorsements.
|Open||None||T212435 Review real-world query plans and performance for Jade|
|Open||None||T238877 Write Huggle labels to Jade|
|Open||None||T183381 Deploy Jade extension MVP to production|
|Declined||None||T212373 Complete Jade user testing|
|Duplicate||None||T210535 [EPIC] Jade Mockups: Prepare mockups of Jade initial feature set for user testing|
|Open||None||T229973 Implement Jade Entity pages|
|Open||ACraze||T208819 Implement Jade Entity UI|
|Resolved||Halfak||T212370 Design Jade entity UI|
|Duplicate||Halfak||T212379 Jade Wireframes: Entity view mode|
We already have some code which implements the judgment view mode using a Mustache template, so maybe it would be easier to just tweak this template rather than write a JS layer for prototyping?
Great, I'm okay either way here. Another potential reason to write a JS prototype would be that we need to guarantee repeatable data for each test.
Link to the current template for reference:
Copied from T199128:
I'm not a designer, but I figured that it would help jump-start our design conversation if I took a stab at some layouts. Below are three wireframes that I have worked out to demonstrate some approaches we might take to generating a nice layout for a entity view. Note that the vertical "..." is intended to represent a menu tab that, when clicked, would display a pop-over menu pane containing options such as "edit", "remove", or "move". I couldn't find any standard way to represent such a thing so I made due.
This view is inspired by the tab-based navigation of Special:Preferences. The tabs contain the consensus data. When a tab is selected, the proposals and endorsements are visible. One clear downside to this is that tabs will quickly run out of space horizontally. This can be dealt with by stacking tabs, but that is visually unappealing.
This view was designed to experiment with strategies for mitigating the too-many-tabs problem. The idea is that a table of schemas would be visible. Each row would show the consensus data and some basic stats about the # of proposals/endorsements. When a row is expanded, the proposals and endorsements are visible.
This wireframe was developed to explore a mobile compatible entity view. The vector image demonstrates two potential views of an entity. One uses the single-column mobile diff. The other uses a two column default diff view. Each schema is contained within a block that can stack and flow as the browser width changes. The blocks are initially compressed and only show the consensus data but they can be expanded to show reasoning behind the consensus proposal as well as counter-proposals and endorsements.
Copied from: T212374
https://docs.google.com/drawings/d/1fP-4Tmn4bDDLWKD_Uu_W0xQNM-QyRc4LDKQTkKNp_fc/edit covers a few different types of edits someone might do.
Menu items allow "edit", "details", "move", and "remove" where relevant. Editing happens within the view with a "✔ publish" and "✗ cancel" buttons inline. The "details" dialog makes metadata available to the UI. The goal here is not to replicate all of history but instead to provide some useful details for review.
My thought is that "move" only shows up for one's own endorsements. It's really just a convenience since "remove" and "endorse" perform roughly the same action.
Editing someone else's endorsement could be discouraged through the UI by a modal interruption ("You're editing someone else's endorsement. Are you sure?").
https://docs.google.com/drawings/d/1urHCaEycUs0n-63bTcWLOJtaRE7D08yWd8nQS6W6Jd0/edit covers the creation of endorsements and proposals.
The basic UI
Propose a label:
Endorse a label:
Advanced actions (rare)
Edit label (Error):
Promote a label:
Delete label (Error):
Edit endorsement (Error):
This screenshot contains the labeldata field for editquality. I included a lot of content because I think this label benefits from solid coaching. We'll need to set up strings for all of the relevant content bits. I'm working on contentquality next.