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)

Regarding transforming any e.g. HMS texts to links, I don't think this is very useful since there's already a sidebar on the page with an "HMS" entry in it, so it'd just be overlinking. For chain throws and other pseudo-stances (e.g. INF), the moves all being close together in the movelist should be sufficient. And ctrl+f is a thing when it isn't. RogerDodger (talk) 18:48, 4 February 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)

Oldmanwang -- Made some adjustments:

• changed ordering of small screen view: toggle at bottom, frames across from id.
• Reduced instances of id crashing into frames. In the majority of cases this isn't an issue, but I'm sure there are exceptions --can figure them out as they come up.
• Input and threat are now indented under moveNo, easier on the eyes.
• MoveNo now upright with a fitted background.
• Small screen view: 'whiff' section given more space -longer tracking bars.
• Added some color

In regards to your evaluation:

• MoveNo: the way I've used this parameter with the ordering of Lee's movelist is coincidental. Here I've structured the movelist purely based on the in-game order. Another way is to assign numbers in sequence, disregarding in-game order and moves that don't official listings. The utility is there for users to gauge how far through the movelist they are; or as you said, to check how many distinct moves each character has. I think it's a handy way of quickly locating moves, if you roughly know their moveNo.
• New moves get added roughly once a year, updating moveNo's with this isn't that much of a concern (can be done in 5 mins or less).

• Too much negative space: If we're to add string information to the notes along with crush, what's to stop us from adding the move name or the damage and hit level; considering these things are also empty for a fair few moves. Relegating these parameters to the notes with full sentences impedes time taken to find the information. I think notes should be specifically for uncommon, specific information. 'Combo from first counterhit' is too common to have in the notes.

• 4 things per group: Only two columns have this issue, frame data and string info.

• Frame data: there is always a startup, block may be empty for an unblockable, but this is indicated from the ! in hit level. Counter hits are only filled out if hit is filled out i.e. ch is always below hit. So I don't think frame data is too effected by this.
• String info: the ordering isn't final or anything. Main idea is distinguishing metrics with unique units and signifiers.For For combo I've made shorthand (hit no.,hit/ch). For jail it's text. Haven't come up with a distinction for leniency and delay -open to ideas.

• On the note of string info, I'll admit it's probably the most esoteric of the lot, which is why I've placed it furthest from the left.

• Parameters being bumped down by long siblings: can tune the column, font and gap sizing to curb this.

• Stubby bars: I've expanded the whiff column to compensate for this. I don't think they need to span more than a third of the row, I see the main purpose of the bar is to spot relative differences in tracking while scrolling, not for specific values. As I mentioned before it could be even better if their width scaled with length (from 1px to 5px).

Collapsible options: A hide/show toggle at the edge (or bottom on small screen view) could hide and show the specific information i.e. everything except no., id and frames. this would reduce scrolling time on small screens and would help to not overwhelm newcomers. Two toggles: one on the edge of MoveDataHeader and one on the edge of each move. By default they would be hidden seeing as the most common reasons to consult frame data is for the frame advantages, startups and hit level. The toggle on the Header shows/hides all move's extra info (including the header itself) while the move toggles only toggle their respective info. Not exactly sure what you meant by 'making it the reader's problem' but I don't think anyone who can find their way to a character's movelist is going to be unfamiliar with hide/show buttons.

In short:

• Reduce scrolling time and screen space
• Hide info that isn't often sought out
• Allow contributers to include all details (no tech too obscure)
• Not overwhelm newcomers

The way I see it, this is the only way to successfully strike a balance between accessibility and meticulous detail. However I'm not familiar with what this would require, perhaps you could fill me in on specifically why this is not an option.

Personal issues I have with the current design:

• Can't see myself or anyone else finding satisfaction in filling it out. Which is significant with the time it takes to fill one out.
• Centered values make it harder to locate metrics, the listing starts at a different point based on how many characters come after.
• Having crush surrounded by startup, advantage and recovery feels incongruent.

Oldmanwang 6:27, 4 February 2021 (UTC)