Address inconsistencies in Window Class exercise

[mikefizzled]

While completing the Windowing System exercise, I realised my tests were failing due to inconsistent ordering of parameters. The tests expect a different pattern than what is laid out earlier in the instructions. These inconsistencies make the intended pattern confusing, and the enforced order differs from typical convention.

The patterns are as follows:

Task 1

• Instructions: x, y, height, width
• Example: x, y, width, height

Task 2

• Instructions: x, y, width, height
• Example x, y. width, height

Task 3

• Instructions: height, width
• Example: height, width
• Tests: height, width

Task 4

• Instructions: y, x
• Example: y, x
• Tests: y, x

Because the tests enforce the (height, width) and (y, x) ordering in later tasks, learners must follow the unconventional ordering even though it contradicts earlier instructions.

Would it make sense to standardise to a single pattern, presumably (x,y) and (width, height) given that these are far more common practice? Using recognisable screen resolutions of 800x600 and then requiring them in the reverse order can be quite unintuitive.

[mk-mxp]

Usually discussions like this should happen in the forum's PHP category. That way more people get involved in the conversation.

We had the issue of that weird sequence of parameters some time ago and decided to keep the code interface stable (for backward compatibility). This would make y,x the order for Task 4. Adjusting the instructions to this sequence in all tasks is fine.

Same goes for mentioning the height,width combination. It's like this in all the code already, so this should be in all parts of the instructions, too.

Anyways, these changes emphasize the mismatch between height,width and y,x. Consistency in the pairs should help get people over that, as it hopefully does not matter that much. I do expect it to come up again, though. I think we need to live with that.

@mikefizzled Do you want to prepare a PR to update the instructions?

[mikefizzled]

My apologies that I skipped that step. I did briefly look into the discussions and I saw a thread of someone making the same mistakes as I had. The backwards compatibility makes sense, so I would lean into (y,x) and (height, width) pairings.

I can prepare a PR for this if you'd like.

Additionally, should I replace the Unicode diagram? I did a quick test by swapping it in the browser for an ASCII version, and the ASCII renders much more accurately.

[mk-mxp]

I'd appreciate a PR for the height,width and y,x changes.

The file itself must be UTF8, so we cannot have ASCII 8-bit characters aka Extended ASCII. You may insert your ASCII version into a comment here (as a DocBlock), and I can take a look at it. But I'm very sure, the line spacing of 1.2 will also make it look a bit different from your screen's output.

Unicode offers Box Drawing characters, which I think are the ones used already. The only issue I currently see is the line spacing on the website.

[mikefizzled]

+-------------------------------------------------------------+
|                                                             |
|   position::y                                               |
|   position::x                                               |
|                                                             |
|                     <----- width ----->                     |
|            ^        +----------------------+                |
|            |        |        title         |                |
|  height    |        +----------------------+                |
|            v        |       contents       |                |
|                     +----------------------+                |
+-------------------------------------------------------------+

This ASCII version simply replaces the Unicode box characters with +, -, and |.

I only edited the element in the browser to preview how it might render with Exercism's CSS, so if it turns out not to be viable, we can drop the idea entirely.

I've submitted the PR without changing the diagram, though the ordering of the text within it was updated.

[mk-mxp]

The proposed ASCII version loses some information:

• The outer screen border is no longer visually different from the inner window border
• The upper left window corner is no longer visually outstanding against the other window corners. Using a * against the + can easily be overlooked

Some of the other missing aids could of course be added, but won't repair the losses above:

• The connecting line between the position:: indicators and the upper left corner is missing
• Referring to the class variables using ::$
• The size class name

So I don't see using ASCII as an improvement here.