Wednesday, April 22, 2015

Out with the old, in with the new

So I've been working on integrating Classic ASP with MVC 5 on the "same" web site.  The client has a lot of old classic asp code with business logic in there that is not feasible to move all at once, but wants any new functionality to be in MVC.  This has posed a number of interesting challenges, from security integration (it can be done!  I'll go into the details of that in another post) to access to the request and response objects between .net and native code (the classic asp).  Interesting fact, if you access the request or response object from .net, native code in the same app pool can no longer access them.  That makes for lots of fun.  So I saw two choices, either let the classic asp be the "root" of the web site as it had been, or put MVC in charge.  The two choices bring different pros and cons.  Putting classic asp at the root requires only two separate application pools, but then you have to bury all the .net stuff into an application underneath the root, so any .net code would be in a sub folder (i.e., instead of  Putting MVC at the root and you get a different issue, namely that you then have to make applications out of every folder where classic asp lives in order to keep them in a separate application pool from the root .net code.  However this allows MVC to live at the root and lets the controllers, views, etc work from there instead of a sub folder.  I opted to go with MVC at the root, as I think this will allow a smoother migration path from classic asp to MVC where we don't have to update links to everything when migrating the classic asp pages (i.e. they won't have to live in that subfolder).  However this will necessitate migrating entire folders at once to avoid the link updates, as the .net code and the classic asp code won't live merrily together in the same application.  I think this is a fair trade-off to move forward with.


I heard of an interesting field of study while listening to the FW:Thinking podcast called Captology.  This looks interesting to me in how it could interplay with UI design.  Once I've finished reviewing the UI design books on my list (ha!) I'm going to investigate this and how it could pertain to UI, specifically relating to computers.


Illustration of two basic problems users frequently encounter.

Once their plan for achieving a goal fails they have no idea what to do.   They falsely think the problem lies in their item lack of ability.

How do people do things? It's easy to learn a few basic steps to perform operations with our technology.  What happens when things go wrong?  How do we detect when things aren't working and then how do we know what to do? Role of understanding and emotions, pleasure when things work smoothly and frustration when our plans are foiled.

Two Gulfs : Execution and Evaluation - Execution is figuring out how something operates, Evaluation is figuring out what happened.  The gulf of execution is bridged by signifiers.  The gulf of evaluation is bridged by a good conceptual model and feedback.  Many people experience difficulties and explain them away by blaming themselves, whereas the difficulties usually lie in the design.

Seven stages of action

Three stages of execution (plan, specify, and perform), three stages of evaluation (perceive, interpret, and compare), and the goal.

The seven stage action cycle is simplified, but it provides a useful framework for understanding human action and for guiding design.
Meaning, it is a useful conceptual model about how people take actions.  Not all (or necessarily any!) of these are conscious.  Determining the actual goal is done by doing root cause analysis, which is simply asking "why" until you get to the root goal (how do you know you're there?).  The action cycle can start from the top, goal driven, or from the bottom, event or data driven.  The gulfs are the obvious places to start developing features.  The big players in finding the gulfs are observational skills and root cause analysis.  We need to understand this because things are designed to be used by people, and without this understanding designs will be faulty.  Most human behavior is at a subconscious level, thus the need for keen observational skills and root cause analysis.  Good example of root cause analysis: if someone comes into the hardware store looking for a 1/4" drill bit, you need to ask why they need it.  The first answer will likely be they need to make a 1/4" hole.  Don't stop there, ask why they need the 1/4" hole.  It could be they need to hang a picture, mount a bookshelf, safety strap shelving to the wall, or look inside the wall.  Depending on the answer you may suggest some alternatives to needing to make the hole, non damaging tape for hanging pictures, shelving that doesn't require attaching to the wall, or you may need to dig deeper, and find out why they need to look into the wall.  Safety strapping probably requires that they drill a hole though.