publish.obsidian.md/programmingsimplicity/2023-07-17-What+are+the+Steps+in+Creating+a+Compiler%3F
📝 2023-07-17-What are the Steps in Creating a Compiler? - Obsidian Publish
What do we need to know to compile a piece of code? - phrasing (parsing, syntax) - type system information gathering - type system consistency checking - data allocation - mapping control flow to …
The default behaviour for a validated text field in Blockly is to turn the background red while the value is invalid, and if the user hits enter (or nvaigates away from the field) while the field is red, abandon the change and return the field to the previous value. This feels broken to me. In the visual interface, if you try to put something somewhere and it doesn't "fit", the piece doesn't go back where it started. It stays close to where you tried to put it, but far enough away to visually indicate that it isn't connected. So you get immediate feedback that it didn't work, and what was done instead. But in the text field, if I have "value" and I change it to "value$", and the dollar sign is invalid, the field will only turn red between when I hit dollarsign and when I hit enter, and then it will go back to the previous value, and just hope I notice that it didn't do what I wanted it to do. For people who look at the keys while typing, that's not going to work. Blockly steadfastly tries to avoid invalid state, presumably because syntax errors aren't any fun. But in the visual interface it accomplishes that by making invalid syntax impossible to generate, and when it modifies the syntax for you to keep it valid, that's easy to see. Here, it lets you type an invalid value, let's you hit enter, and the fact it didn't work is potentially invisible. It feels like it should be possible to do better. Has anyone seen an interface for entering values into a text field that solves this problem? Where the field maintains a valid value, starting with a default, but it also allows you to maintain a view on failed attempts to modify it, so that you can correct them? Should the screen just go modal, not responding to "enter" or clicks outside the editor while the value is invalid? Should the failed attempt to change it be noted somewhere? Or is maintaining valid state in text fields a silly goal, and instead you should just throw errors at a later step, or something?
A couple ideas, possibly combinable: text field stays red indefinitely, blocking any attempts at running or inferring from the program (I forget what the right term is in your project); I guess this is basically "throw errors later", but with a more deliberate focus on showing the reason for the error. Other idea: each text field stores both the last user input, possibly invalid, ("draft"?) and the last valid, active value, with really clear UI about what text is currently active: probably invalid draft text off to the side in red. Or possibly a "restore 'my previous valid text'" operation if you go the throw-errors path.
I think it's really important not to casually throw away user input even if it's invalid. It might contain a pretty significant bit of work (e.g. digging through an obtuse document for the exact right term) that's only slightly invalid, e.g. only typo'd. And if the user trusts the computer to remember it, they're liable to completely flush it from their mind until they come back later to an error message or mysterious reversion to the old value, whereupon they feel both frustrated and betrayed. :melting_face: (I think I'm preaching to the choir here, just had to vent dredged-up memories of frustrating software)
I think a modal dialog , front and center on the screen, might be ok, albeit clunky. But just stopping responding to clicks elsewhere is exactly the kind of interaction that gives modal interfaces a bad name. The scenario when this whole thing is a problem is when the user's locus of attention moves away "prematurely", which is the exact reason they'll be confused and frustrated when the rest of the UI "freezes".
So user hits enter or navigates away while invalid, a modal dialogue pops up with value, OK, Cancel, but OK is greyed out while the value is invalid, the invalid new text is in the dialog, the validity requirements are displayed, the prior valid value is displayed next to the cancel button. Something like that? I'm also imagining a "current value" non-editable element, and a usually hidden "set to" element that hides when it succeeds or is cancelled, stays visible otherwise. Not sure what that would look like, but it wouldn't require you to solve the validity problem first, which seems like an improvement.
I think it would be interesting if the invalid string split into a separate red-highlighted "string block", lying near the text field (which retains the old valid value).
If you absolutely need to maintain valid state at all times, I would leave user entered value, highlight in red and have a little modal that says "X is an invalid value, using last valid value in its place (Y)" with a one-click option to change X explicitly back to Y.
I personally hate editors that try to maintain a valid value at all times. When you are sketching something out you want to be able to just put crap like "??? salary ??? wealth ???" as placeholders for half thought out ideas. I really think that thinking tools need to be really, really cautious about editing what the user has input.
Why do you need to maintain valid values only? Can't you just disable whatever feature requires this until they provide them? This is a meaningful quid pro quo for the user. If you don't want the quo right now (i.e. I know this code doesn't compile, I'm not asking for that), it's very, very frustrating to be forced to swallow the quid (valid syntax)
Jan, the thought had occurred to me of rejecting invalid text blocks the same way other blocks are rejected for type problems. That's not impossible, but it would make things clunky, and I don't actually have strings as a data type in the tool, right now. Chris, I don't actually know if maintaining validity is worth it. It's just the approach taken by the library, which I'm assuming is better informed than I am about learning outcomes. My instinct is to override the current behaviour and just leave the thing highlighted red, and refuse to save.
One of my favorite problems — more especially the case when each individual field is okay, but some cross-field condition needs to be satisfied. In practice my solution is to allow inconsistent working state backed by an always consistent committed state, which you can choose to revert to. Taken to its natural extreme, version control emerges from these considerations.
do you use drag & drop on gmail?
why? why not?
My answer is a big old “sometimes” and specifically in relation to the feature that lets you drag attachments on to the composition pane.
Drag and drop interfaces have to make different assumptions about visual acuity and motor skills than a lot of other interface elements.
If I use them or not often depends on the proximity of the thing I want to drag and drop. If it’s in an open file navigator window or my desktop, such that it appears to be “next to” the composition pane then I’ll often use it.
If the file isn’t readily available, though, I usually use the traditional method of attaching a file since it’s easier to navigate to/search for in a file located like macOS’ finder.
I do use it, because speed .
I notice that both assumed only dropping files, did you notice you can drag mails into tags, tags into mails and so on? 🙂
lol, nope 😂 Today I’ll see if I get any emails and if I need to organize them! Thanks for the revelatory new teaching!
yeah! I sometimes add tags to emails. Honestly tho I try to get in / out of Gmail’s slow, bloated UI in general 😛 so I don’t use tags much in general
Never used the internal drag-drop features. I've explored drag-and-drop a lot in the past and I feel that in order to be discoverable and memorable as an interaction it helps to deal with very concrete object representations. IDK what dragging an email into a tag "is" in the world, I can't imagine doing that with a physical letter and a sticky tag. It doesn't have to have a literal real-world analogue, but the way the software models the objects has to give them a clear physical identity in the visual space (like dragging items to reorder in a list: each item has a physical identity, and you manipulate a direct and visible relationship).
To be not just discoverable, but actually useful, dnd has to also be more efficient than a direct interaction. e.g. I could physically understand the action of picking up a tag and dragging it onto an email to classify it, but it's much easier to just press the tag as a button to toggle it.
dnd for file attachments hits both of these. I am paperclipping this file from my workspace onto this message, and it's so much faster than digging through file hierarchies to find the file I probably already have open in my file manager.
Mostly no. When I'm moving emails, it's almost always in bulk, where it's no harder and maybe a little less fragile to use the menu (I think I have done this a few times though). I usually have my web browser maximized, so getting a file browser up at the same time to drag an attachment over is not worth the fiddling with windows that I'm immediately going to undo. Same applies to every other drag and drop file upload, I don't see the appeal.
Is it just me, or does anyone else on this thread primarily use the keyboard to navigate Gmail?
📝 Keyboard shortcuts for Gmail - Computer - Gmail Help
Want to get more out of Google apps at work or school?  
the way I noticed you could do actions on mails by dnd was when I accidentaly clicked and moved my mouse and I saw the ui indicate I was dragging it, I didn't know what I could do with it. Today after I wrote the initial message I tried to see if I could drag a tag to a mail and noticed that you can. I've been using gmail since it was invite only and never knew that was possible 😄
I'm using gmail here because I've asked a more general question before and got no answers but my interest is more general: do you use dnd in the applications you use for something other than dropping a file? do you know which things can be dragged and where can they be dropped?
Trello is a good example of a UX which makes dnd very clear and useful IMO. It's easier for me to drag the card between columns than select a new status.
I'm biased, but in my own groceries app I made I always use dnd to categorize items in my list, although I did build an affordance for doing it via dropdown in case people found that cumbersome. I spent a lot of time designing the interaction but I still feel like I have a ways to go before I master making dnd feel natural.
A rule of thumb telling me I haven't got it right yet is that I have to have a tooltip tutorial for first-time users calling out that the interaction exists at all.
I think it's really interesting that the Gmail devs bothered to spend the time to make dnd interactions but never tell the user about them. I wonder if we can ever hit a threshold of dnd support and consistency of expectations to create a cohort of users who just intuitively find and utilize these things without being tutorialed.
I think it’s really interesting that the Gmail devs bothered to spend the time to make dnd interactions but never tell the user about them
Not just that, but the keyboard shortcuts are disabled by default , one step further than not telling the user about them.
Which makes me think it’s an intentional design choice:
Perhaps they are intentionally limiting the feature to advanced users who think about “how can I be more efficient with Gmail” and are proactive enough to seek out and enable such a feature?
Or maybe it’s the inverse: the Gmail team wants to avoid confusing newbies, who might accidentally activate the shortcuts and have no idea WTH just happened?
