IronShay

Optimizing Software using a Brain-like Mechanism

While I was studying to a test in a Cognitive Psychology class, I figured out that our brain has performance features that we might want to import to our applications.

In short, our brain has this mechanism - "Inhibition of Return" (AKA, IOR). This mechanism refers to the observation that the speed and accuracy with which an object is detected are first briefly enhanced after the object is attended, and then detection speed and accuracy are impaired. This means that when you attend new objects, your response will be quicker than attending already attended objects.
So our brain actually makes us go ahead with a certain flow and it also promises us that it's gonna be quicker, so... why not?

"How does this relate to optimizing software??" you're probably being asking yourselves. Well, most of the time, we can anticipate the usual workflow of our users. Hence, once the user does a certain action and starts the expected flow, we can start preparing stuff for the next expected steps in a background thread. So when the time comes and the user really forwards to the next step, the application will react faster.
This "Inhibition of Return" pattern should be used and developed very wisely. We don't want to consume 100% of the user's CPU after each action, using the excuse that we're preparing the next 200 possible steps in the background. The expected flow should be, in my opinion, a very restrained, tunnel-like flow:

Simple and restrained flow (a flow might be more complex, but we should use the pattern only for specific workflows)

Too complex flow for the pattern

For example, let's say we have a grid with paging support and we know that our users tend to go though the grid pages. After a page is done loading and is presented to the user, we'll start fetching the next records on a background thread.

This pattern also conforms to "The Paradox of the Active User", which concludes "Do NOT design for the idealized rational user, design for the way users actually behave". This strengthens the importance of finding the right workflow that the users really execute.

In conclusion, if it's good enough for our brain, I think that it's good enough for our users! :-) 

Reference

• Wikipedia - Inhibition of Return
• Paradox of the Active User

All the best,
Shay

The Danger in Accessing Row Objects of Word Tables

Recently, our QA team has shown me an error they received while using my Word addin... The error said "Cannot access individual rows in this collection because the table has vertically merged cells". What what what!?!?!?

After investigating the problem and looking over the Internet, I've found that Word won't let you, the miserable programmer, to use any row related property when the table has vertically merged cells... I bet that when MS developers look at this post, they point the finger at it and laugh "Muhahahaha"...

In order to prevent this error, don't use the Row object! use Cell instead to do whatever you need to do.
If you need a cell in a certain row, do this by using the Cell.RowIndex property (you can't touch the Cell.Row property, remember...).

A helpful code to get the last cell of the table:

private Cell GetLastCell(Table tbl)
{
    Cell _cell = null;
    Cell _nextCell = null;

    _cell = _nextCell = tbl.Cell(1, 1);

    while (_nextCell != null)
    {
        try
        {
            _cell = _nextCell;
            _nextCell = _cell.Next;
        }
        catch
        {
            _nextCell = null;
        }
    }

    return _cell;
}

All the best,
Shay.