Template talk:MoveData/testcases

• Template:MoveData/testcases

I moved the following from Template talk:MoveData to get around the conflicting stylesheets. RogerDodger (talk) 15:29, 1 February 2021 (UTC)

New design

See here for intended look.

I wanted to make it so each parameter fell in the same place, regardless of what was and wasn't defined, so that the user always knows where to look. The parameters I've put in the column before the frame data are just what I figured were the most common to be added to notes, let me know if you think they could be used better. The two main columns I named 'frames' and 'whiff', I figure the frames info is more useful at close range and the whiff is more useful at a distance.

Issues I'm aware of but not sure of how to fix:

• startupRoot's can push parameters down, obscuring which is which. I don't see the value in having the startupRoot displayed personally, when there are several other indicators of where the move stems from.
• Moves with large inputs (i.e. 10hit combos) go off screen on phones.
• " | " after target and before damage, shows even when those parameters aren't described. This is mainly an aesthetic issue for moves like stances.
• Move No. is harder to read on the light color-scheme, would be better if it was white on light-scheme, black on dark.

Ideas I'd like to implement that I think require altering Javascript:

• Display Notes toggle: (show/hide) and (all/all) buttons on the far right column of the first row which toggle display of notes for particular moves or toggle display for all moves.
• A stance button shortcut: a script that can recognise when something has been put into the move name parameter between brackets i.e. Hitman (HMS), so that anytime HMS is written inside an input-ctn parameter, it would become a link that scrolls to the point of the page where that stance is first described in brackets as a move name. This could also help with follow up moves and chain throws for finding move roots. Could even have it so that the brackets abbreviation was hidden for a cleaner design.

Whaddya think? Oldmanwang 10:44,1 Feb 2021 (UTC)

Updated

Made some changes since posting:

• Re-ordered columns to progress from left to right based on significance.
• Changed 'special' column from:

Screw

Spike

Wall bound

Stage break

To more common notes (based on the Lee movelist)

Combo = at nth hit/CH the string becomes guaranteed

Jail = Does it jail from previous hit in string? Y/N. If specifying whether it jails on block or hit, could be "On hit" or "On block". If both, Y, if neither, left blank. Important to use distinct language from the descriptor for Combo, so there's less required familiarisation with the layout.

Leniency/leeway = how many frames can the input be delayed by.

Delayable = By how many frames is the move (not input) delayable.

This could reduce the space used for notes, and in some cases the need for notes entirely, reducing screen space.

• Reduced size of each row, less negative space.
• Reduced font size on small screen width, so phones would be less likely to cutoff long inputs.
• Moved toggle column on small screen to top row; could include two toggles: one for hiding/showing the notes row, and the other for hiding/showing frame data row, to reduce scrolling.
• Lowered opacity of vertical bar dividing hit level and damage, easier to distinguish l and 1 from |. Still haven't found a way to hide it if both damage and level are left blank.
• Rounded and thickened grid border. Easier to see where one move ends and the other begins. Looks better too imo.
• Frames column can now fit most large startups i.e. i14~15,i10~11, meaning startupRoot's are more feasible to add.

Another idea I think could be useful, but not sure how to implement:

• Tracking bars with scaling width, to aid users on small screens being able to visually spot moves with strong tracking.

All in all, I think it's coming together quite nicely. Let me know if you think something needs changing. Oldmanwang 10:20 ,2 Feb 2021 (UTC)

RogerDodger—The main issue voiced towards the current design is that it's too complicated. Along that axis, the approach you're taking is going the other way: You're inventing more new terms and adding more fixed fields, requiring readers shoulder an even greater memory burden to remember where everything goes. This isn't necessarily a problem, but it should be done with a purpose. Is that purpose adding clarity to inexperienced readers, or creating a better visual aesthetic, or improving skimmability for experienced readers, or allowing more information to be expressed? From what I can tell, in comparison to the current design, this one presents almost the same information (moveNo is the only new data), in more space, in a way that demands more from the reader. Addressing individual parts of the design:

• Giving the moves another identifier in the "moveNo" isn't useful. You probably already noticed that these are not continuous because the definition of a move is fuzzy and the ordering we might want to use may very well differ from the in-game movelist; nor are they constant, because they shift when new moves are added; neither are they unique, because many have no number. (And it's a little farcical that Lee's 1, d/f+1, 4, and 4,4 all have no number, despite being amongst his best moves. I get it's only that way because of how the in-game movelist is written.) Nobody is going to remember and identify a move by this number, so it doesn't really serve a purpose. At best this number tells a reader how many moves a character has (by scrolling to the bottom and seeing the last move is e.g. "moveNo 102"), but this is only useful for complete newbs and already covered by the in-game movelist. Moves already have up to 3 identifiers (id, name, inputLead+input).
• Giving uncommon things a dedicated, fixed spot in the design results in an excess of negative white-space. It does make the data more structured, but this is as much a downside as it is an upside, since an excess of structured data also makes it harder for people to use the template or to note unaccounted for information. I chose to let the Notes field handle a substantial amount of semi-recurring data because that space is going to be there anyway, so expecting to use it a bit on average should work out. This is more-or-less all the new fields you've added. Of the feedback on the current design, more people again suggested going in the other direction and moving the "Crush" field into the Notes as well.
  • These fields being in a fixed spot gives them an enforced ordering, but that can be done in the Notes field just as well by some other means (e.g. a sub-template or Lua module) if that's desired.
• Having any more than 4 things in any particular group makes skimming things visually much harder. Note that the current design sticks to at most groups of 3. It's not clear at a glance with a group of 4 or more where the terms in the middle are, especially when their position can be bumped by a multi-line sibling.
• Making the font size smaller with smaller widths isn't a real solution to wrapping issues. If it's legible at that size, just use that size in every case. (This is potentially worth doing with the current design.) And if it isn't, well, that's obviously a problem.
• Having Notes, or anything else, hidden behind a collapsible is not an option. If the design requires such a thing, then that's the design's problem. Using a collapsible makes it the reader's problem.
• Cramming the tracking bars into a small container robs them of communicating much visually. They're too stubby.
• Moving the target and damage fields into the same row as the input could be a good idea, since these usually scale with each other. In the current design, this could be done to clear up a column. However, this would also remove the ability for a compact, two-row entry to exist (which occurs in most entries without a range number).

startupRoot could already be shown in the current design, but it's not intentionally. I think people will more easily grasp what the leading comma represents in this context without it, and it's only being recorded right now as a "just in case" thing (e.g. if people want to use this data for a frame data bot, displaying e.g. Lee's 2,2,3 as merely ,i21~23 is not super helpful for the central use case).

As a technical aside, you might want to look into using a live CSS editor in your browser. (I use the built-in "Style Editor" tab in Firefox's inspector.) Not only would this let you iterate quicker on designs (by showing you the changes immediately), but it'd keep the noise down on Special:RecentChanges, which is currently filled almost entirely with style3.css edits. RogerDodger (talk) 18:36, 4 February 2021 (UTC)