Change "low" and "high" to 0 and 1

[Shimon-Schocken]

Throughout the IDE.

[DavidSouther]

I understand the desire for book parity, but changing single-bit buttons to 0 and 1 will make them much harder to click and touch on mobile. I've expanded the keypress zone to the entire table cell, but this is close to crossing accessibility guidelines.

[Shimon-Schocken]

It's more than book parity, it's compatibility with many courses and boolean algebra. I am not sure that I understand the problem. If LO and HI were not problematic, we can display 0 and 1 instead, and give them the same keypress zone as that that was allocated to LO and HI. Or maybe I am missing something.

[DavidSouther]

"Low" and "high" are about 40 and 50 pixels wide, respectively. 0 and 1 are 24, with padding. This isn't ideal for mobile devices. Moving the clock handler to the entire table cell makes the clickable area larger, but special attention is needed to ensure screen readers and accessibility tools are able to mark it appropriately.

[Shimon-Schocken]

David wrote that "Low and high are about 40 and 50 pixels wide, respectively. 0 and 1 are 24, with padding. This isn't ideal for mobile devices".

I may be missing something. Why do we have to care about the standard size of these strings? I suggest that we create a "custom" clickable button whose input value is restricted to 0 or 1, and make its dimensions and design (including the 0 and 1 labels) suitable for our needs. So, a 16-bit number will be presented as a sequence of 16 such buttons. It will have the touch and feel of a smooth 16-bit binary string, perhaps with more than regular spacing (which is good), but it will be implemented as a sequence of 16 stand alone buttons. This will require writing functions that handle various I/O issues and binary to decimal conversions.

I am picky about this issue, since I think that interacting with binary input values is a major part of the student experience and the overall IDE UX. For example, presently, when you click on a 16-bit binary input, the displayed 16-bit value increments by 1. This is an elegant effect, due to David. But, what is needed is direct access to every bit. When the user clicks a bit in any n-bit input pint, the bit should flip (and only that bit).

This is not an immediate issue, it can be handled later, when we deal with the final IDE layout.

[DavidSouther]

Ahhh Ok, I see the UX you're going for. I'll keep that in mind and see what I can come up with. I have #28 open as well where I want to add more to the wide pins, but I was looking into an inline editor, rather than a direct bit flipper. I'll summarize this comment there & we can continue the conversation.

[Shimon-Schocken]

Thx for the new rendering of the n-bit input values! Exactly what I was hoping for. There are a few small issues though:

1. Why do we need the +1 feature / button? I find it a confusing (for a student), and adding clutter.
2. I think that the 0/1 buttons / fonts, as well as the spacing between them, can be smaller. As a simple design rule, they can be the same size as the fonts used for the rest of the IDE (for example, same as the HDL code).
3. If the HDL code entails rendering more than one input and output n-values, all these n-values should be vertically aligned. Presently, this is not the case. For example, here is how the IDE deals with an ANd16 chip:

4. I think that it will be better to right-justify the labels of the pin names, and perhaps add a ":" suffix. For example:

5. This is a nitty gritty point, but it can cause pedagogical blunders. Presently, the "inputs pins" and "output pins" labels are fixed. Ideally, they should be dynamic: If there is only one input (output) pin in the HDL code, use the label "pin" instead of "pins". A "pins" label (when there is only one n-bit pin) may cause some students to view every single bit as an individual pin.

[DavidSouther]

1- You mentioned liking the increment feature in another comment, but I agree it looks cluttered. Easy to remove. 3- Related to 1, and removing the +1 incrementer will have them aligned. 4- I like that, will do 2- We can add this to an end "make everything perfect" pass, as part of #67 5- Similar to 2, I have a translations file that will have all the string constants, and includes pluralization etc. See #58 and #61.

Reopening to handle points 1 and 4

[DavidSouther]

Removed inc button in #80