4 ms·

1) Just pushed an update to fix that, thanks for pointing it out. 2) Syntax checking has been a big discussion point for us, we would love to be able to limit

1) Just pushed an update to fix that, thanks for pointing it out. 2) Syntax checking has been a big discussion point for us, we would love to be able to limit people to only valid blocks but also didn't want to have a giant block of validation javascript to deal with the drag and drop on the blocks. As for error messages, you're totally right; they're massively lacking. Difficulty is that we keep changing the way we're storing rules as we learn more about what users want to do, given that we didn't want to have to build a proper syntax parser until we had a more stable concept of how they'd be structured. Out of interest, what sort of error message would be useful? As in, how technical e.g. "I don't understand how to if moving_avg > buy" or "There is an error at 'if moving_avg > buy' returns: Nil expected: boolean"

mikecsh 14y ago
My app is slightly different and uses a patch panel style of interface rather than linear blocks. Every time the system is changed, the layout is parsed into code and any invalid paths are coloured red to show a) where the problem originates b) which blocks are affected by the problem Additionally there is a crude type system that prevents the wrong type of signal being passed to a block - e.g. a buy/sell datatype cannot be passed into a block which expects numerical time series data. I would say that you should prevent users from entering rules which make no sense as far as is possible.. I guess it depends how technical your users are. I'm attempting to stay away from terms such as nil or boolean, so I would go for something like your first example, but with more information, perhaps like: "I don't know how to follow the rule "if moving_avg > buy" because xyz" which sounds friendly and non-technical but hopefully xyz will help them understand why it doesn't work and learn from their mistake.

mikecsh 14y ago

My app is slightly different and uses a patch panel style of interface rather than linear blocks. Every time the system is changed, the layout is parsed into code and any invalid paths are coloured red to show a) where the problem originates b) which blocks are affected by the problem Additionally there is a crude type system that prevents the wrong type of signal being passed to a block - e.g. a buy/sell datatype cannot be passed into a block which expects numerical time series data. I would say that you should prevent users from entering rules which make no sense as far as is possible.. I guess it depends how technical your users are. I'm attempting to stay away from terms such as nil or boolean, so I would go for something like your first example, but with more information, perhaps like: "I don't know how to follow the rule "if moving_avg > buy" because xyz" which sounds friendly and non-technical but hopefully xyz will help them understand why it doesn't work and learn from their mistake.