Who You Calling A Jesse?

My role at work has me looking at a UI for a fairly complex application (known as jobmine) that has three distinct audiences with three distinct reasons for using the web app. The web application is the primary business tool for the co-operative education process at the University of Waterloo. This process sees anywhere from 10-25K people using it at least a couple times every four months. Staff in the CECS department use it for their day-to-day activities.

What is a co-op system? My definition is based on being a student and now an alumni, it is no way the ‘official’ take. Co-operative education is an approach to education that gives students a chance to learn outside of the classroom (and in the case of UW, make some good money) and gain experience in the ‘real world.’ If you are a student you look for and apply to jobs, manage your resume/CV, and find out about interview times and locations, accept and decline job offers. For an employer you post jobs, sort through applications, arrange interviews, and offer jobs. For staff you make sure this all works by supporting both students and employers, generating reports, manage a massive amount of data. Generally speaking.

It would seem easy enough if you walked up to it from a user perspective. You have your role, an idea of what needs to get done, and off you go. The expectations aren’t a whole lot different than say Workopolis or Monster.com.

A boat load of research (which involved many interviews with all audiences and was conducted by UW profs/grad students) later and I now have a bunch of what are essentially feature lists along with rationale. What I need to do along with my team of three co-op students is absorb the data, digest it, and come up with a set of ‘consoles’ for the UI. The problem is that this sucker is hugely complex and dynamic… it is expected to be 100% AJAX, so how do you do it?

My first thought was to approach this with a wire frame for each console. We can mock up a look once we get the bits we need on the page in the location that works. The problem is that many bits (or blocks) have dynamic states that can change how the data in the block or the block itself is presented.

So our approach is to break these blocks down to their basic elements (submit buttons, textarea, label, input, etc) then put those elements into the blocks themselves. From there we assemble the console. The plan is to have all this done in HTML with DOM scripting to present the UI. This approach seems to be working and more importantly seems to assist greatly in ensuring our HTML/javascript code follows best practices.

I will update once we have a block to look at it. I just wanted to get this initial bit out of my head and into text.