RESO Rules: user experience questions/concerns

[bryanburgers]

While implementing rules for our system, our front-end team had a variety of questions about various edge cases should be handled when they have the potential to introduce user experience issues.

Has anybody built out a front-end using RESO’s rules that has had to wrestle with these details?

Example 1: Modified values in hidden fields

The spec includes the SET_DISPLAY action, which allows fields to be displayed or hidden based on other fields.

A great example of this is a rule like the following that only shows the “Close Price” field if the listing is closed.

{
  "RuleField": "ClosePrice",
  "RuleAction": "SET_DISPLAY",
  "RuleExpression": "MlsStatus = 'Closed'"
}

The question that came up is what should happen if a field gets shown, the agent updates the field, and then the field gets hidden again? If the update is sent to the server, should that field be included in the update?

So the example would be that, on the listing add/edit form, the agent changes the status to Closed. This causes the “Close Price” field to become visible. The agent enters a value for the Close Price. The agent then changes the status back to Active, and edits other fields. When the update with fields that changed gets sent to the server, does the ClosePrice get sent?

Sending a field that the agent can’t see and can’t edit seems like a bad experience for the agent. And it’s especially bad if the server responds with an error that the close price can’t be set for active listings, because the agent may not know how to get the Close Price field to appear to clear it out.

On the other hand, a front-end that sends Close Price is in compliance with the spec, so MLSes may be making assumptions based on front-ends behaving that way.

Example 2: SET

The spec provides for a way to set the value for a field using the SET action. However, it doesn’t say anything about whether that field is still editable for the agent.

Our front-end team is concerned that it will be a bad user experience to have a field that is affected by SET be editable, because if the agent changes the field but it then gets updated by a SET, the agent may not notice and the value will change out from under them. So the question they posed is: should we treat all fields that get updated by a SET as read-only fields.

We don’t have a large corpus of rules, so we aren’t, at this point, able to determine whether there are situations where a field is expected to be updated by the agent and is the target of a SET, and how that works together.

[paulhethmon]

We aren't using RESO rules (yet) but we have a lot of rules that predicate on values of other fields. Given how our front end is structured, Example 1 would end up with the ClosePrice not being sent. That's due to how our UX is though, not a rules based thing. I think a UI/UX would need to toss any field that is not displayable. That's actually how ours works. The DOM ends up being manipulated and the ClosePrice field just doesn't exist anymore when the status is set back to active.

[darnjo]

So the example would be that, on the listing add/edit form, the agent changes the status to Closed. This causes the “Close Price” field to become visible. The agent enters a value for the Close Price. The agent then changes the status back to Active, and edits other fields. When the update with fields that changed gets sent to the server, does the ClosePrice get sent?

If someone changed a listing to Closed and then back to Active, why would the ClosePrice be sent? It wouldn't be valid for the listing...It's Active. I would assume that there would be a SET rule to clear a value ClosePrice if status changed from Closed to Active.

[paulhethmon]

Technically, the listing never changed to closed. The agent changed it in the front end application but then changed it back. It was never persisted as a change.

It does seem a SET rule on ClosePrice might work though to reduce ambiguity.

[darnjo]

Technically, the listing never changed to closed. The agent changed it in the front end application but then changed it back. It was never persisted as a change.

Yep, agreed. They didn't submit it back to the server...

[darnjo]

Regarding example (2):

Our front-end team is concerned that it will be a bad user experience to have a field that is affected by SET be editable, because if the agent changes the field but it then gets updated by a SET, the agent may not notice and the value will change out from under them. So the question they posed is: should we treat all fields that get updated by a SET as read-only fields.

I'll have to think a bit more about potential cases here, but I'm not sure we'd want to make a blanket rule that all items updated by SET are read-only? SET could be used to auto-pop a timestamp or other value that the user could override. And the value that's SET could potentially just be a suggestion in that case...

One option is to have both a SET_COMPUTED_READ_ONLY and SET operation, if this is something we want/need to support.

That being said, one of the topics of discussion at the Summer Dev Workshop is whether we want to use RETS VE or something else, in which case it could change the behavior or potential options we might have.

[paulhethmon]

I definitely have SET rules in my system, but they are really reserved for the back end. Things like setting a timestamp on a status change are only done by the back end. I could possibly see having a SET on a display/read-only type field. Something like the field PoolType is a required field and when you select in-ground the PoolYN field gets set to true.