Progress/busyness indicators for interactive apps

[Manuel Simoni]

Say I have an RDP application where a user edits a text while a search engine that's indexing the text updates in the background. After an edit, there should be an indication of when the indexing is finished, so the user knows that if he would perform a search now, it would run against the latest state of the text.

One solution would be to have an extra behavior that can be queried to find the current state (busy/idle) of indexing.

Another solution would be to make progress part of the value of the output signal of the indexing behavior. In fact, it would also be possible to model progress as part of the output of the main behavior of the application.

What are your thoughts on this?

[David Barbour]

On Thu, Jun 18, 2015 at 4:15 AM Manuel Simoni <msi...@gmail.com> wrote:

Say I have an RDP application where a user edits a text while a search engine that's indexing the text updates in the background. After an edit, there should be an indication of when the indexing is finished, so the user knows that if he would perform a search now, it would run against the latest state of the text.

Ok. Similarly, this signal would indicate the active search is up-to-date.

 

One solution would be to have an extra behavior that can be queried to find the current state (busy/idle) of indexing.

True. Any model of gradual indexing will involve a stateful resource. This stateful resource might allow a query indicating whether it is idle, or perhaps how many documents are in the queue, etc.. 

As the system scales upwards, you may reach a condition where you're never idle. In that case, indicating the number of documents awaiting indexing, and perhaps a 'total number served', might serve as a better health indicator. You can more easily translate numbers into the desired indicators than the inverse.

 

Another solution would be to make progress part of the value of the output signal of the indexing behavior.

It isn't clear to me what you're envisioning. 

Are you imagining that the indexing behavior is somehow part of the search behavior, i.e. that you aren't indexing unless you're searching? Or maybe part of a UI behavior? That's possible to express in RDP, but it seems an awkward coupling of concerns, analogous to insisting that web pages open to google.com be responsible for indexing the web.

An RDP behavior may be responsible for orchestrating an indexing activity above some stateful resources, but I would keep this cleanly separate from a search behavior responsible for querying the index. The search behavior would be used by the larger UI behavior to integrate the search with the UI (e.g. conditionally on having a search string).

With the architecture I envision, the only real option is to have progress information available as part of a stateful resource involved with the indexing activity, which you might query with a separate behavior. 

[Manuel Simoni]

I'll try to explain myself differently:

I'm interested in turn-based user-computer interaction. Each change/gesture of a user should be followed by a response from the computer, with a clear indication of when this response is ongoing/being computed and when it is complete. For the apps I'm interested in, the computer should rarely autonomously update the display so it doesn't jump around wildly. (Note that the Twitter webapp for example follows this principle: if there are updates from other users, Twitter will not immediately display them. Instead, it will indicate to the user that updates are available, and then wait for the user to make a gesture to actually display them, thereby putting these remote "out-of-the-loop" updates back into the local user-computer loop.)

So I wonder if there's a general way to tell that a RDP behavior network has reached a stable state after processing an update from the user, or whether this information has to be provided through application-specific means (such as the behavior that provides busy/idle information of the search engine indexing process, discussed above). One such general way, AFAICT, would be to embed progress information into each behavior's output signal. E.g. a signal could be a sum of `InProgress | Done value`.

[David Barbour]

It is feasible to heuristically estimate stability based on comparing a signal to its past (or anticipated future) values. This can be modeled via a stateful resource that takes signals now and returns signals of K milliseconds or seconds ago (or perhaps a sliding window, or exponential decay model). Resources that return history are useful. They offer stability information only for a precise subset of signals. But the idea is generally applicable and might do what you need.

It is also feasible, given reflective capabilities, to access 'the virtual machine' or 'the runtime' as a resource and query them to obtain general information about whether the machine is idle or busy. 

You cannot directly query a behavior network for progress. Behaviors, including composite behavior networks, are opaque stateless values - a lot like pure functions. All you can do with a behavior is compose it into a larger behavior, or execute it, e.g. by installing the behavior into a context where it receives a demand signal. 

Under-the-hood, I do track 'stability' information on a per-signal basis in Sirea. E.g. each update was a pair: 

* a list of [(T, Maybe Value)] pairs 

* a stability value of type T

The list of values might include recent past, present, and anticipated future values, with 'Nothing' indicating a period of inactivity. The stability value says: "I'm done with updates below time T." This was most useful for garbage collection and retroactive correction of stateful resources (up to some limited window), and a stability value could certainly be used when rendering, e.g. render the most recent stable value.

I suppose a reflective capability could report the stability value for a signal. Though, I don't believe I ever tried that in Sirea.

I can't say I fully grok what you're envisioning, but do any of the above points help clarify anything for you?