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)