Oct 4, 2010 Posted by John MacIntyre

My reaction to being named as a Canadian programmer worth following on Twitter

Yesterday John Bristowe published a list of Developers in Canada You Should Follow on Twitter. I was humbled and honoured to make the list. … actually, I was a little more excited than that, here’s a dramatization …. Watch this video on YouTube … Thanks John … I’ve been dying to use this video in a blog post.... read more

Oct 3, 2010 Posted by John MacIntyre

The UI programmers (not so) secret weapon

An Example: Suppose you had software which matches buyers and sellers, and new users are created via a ‘new user’ wizard[1].  Let’s say the wizard has 4 pages for Basic User Info, Review, Processing, and Completion Status Report.  And there are 5 buttons; Cancel, Previous, Next, Run, and Finish. Cancel is displayed from the Basic User Info, Review, and Processing pages. Previous is displayed from the Review page. Next is displayed from the Basic User Info page. Run is displayed from the Review page. Finish is displayed from the Completion Status Report page. This isn’t difficult to manage the display from the events[2] right? Well … in reality, it doesn’t take much of a change for your simple display functionality to become … The Problem Manipulating application display during events quickly turns into a complex, bug riddled, difficult to maintain, mess. It may not seem like that big of a deal when you have only a few controls and a very simple (or no) workflow.  Actually, you may argue, managing visual display in the events may even seem like the most efficient strategy.  After all, you will never display, disable, or otherwise needlessly manipulate a control, but as your application grows more complex, this approach can leave you tearing your hair out[3].  This is especially true when you have multiple execution paths leading to the same event handlers with different state. What if you received a change request for the above requirements, where additional info is required for buyers or sellers, resulting in a new wizard page for each, and in addition to that, business sellers require a page to gather Tax Information? Your complexity has started to grow, resulting in buyers have a workflow of Basic User Info -> Buyer Info -> Review -> Processing -> Completion Status Report Individual sellers have a workflow of Basic User Info -> Individual Seller Info -> Review -> Processing -> Completion Status Report And commercial sellers have a workflow of Basic User Info -> Commercial Seller Info -> Tax Info -> Review -> Processing -> Completion Status Report Notice how these changes lead to different execution paths all arriving at the Review page.  The question then, is; where does the back button on the Review page send the user?  The back button requires logic to know which wizard page to display. It’s not difficult to imagine the need for logic to be added in more than one place[4], which can result... read more