Raven Slingshot Portal

Taking a look back...

1. Create the new look and feel: I designed a centered page layout, which had the ability to go full screen if needed. This was accomplished by taking the existing header and stretching it across the entire page, then centering the logo, login area, and navigation, with a 960px width page content area below. Now if one wants to go full screen with this layout just make the 960px width page content area scale across the entire screen. Same familiar look and feel, just a lot more screen real estate to work with.

   Originally Raven just wanted me to fix and update the design of these menu’s but it wasn’t that simple. The issues with the menus ran deeper than just the menu code itself. It was a combination of broken HTML and CSS on the menu’s themselves along with broken page content HTML and CSS that was causing the problems. In order for everything to work properly across all browsers both problems had to be fixed, simultaneously.

2. Fix and update the design of the navigation menus: This was the original scope of this project. Luckily Raven was already using the jQuery framework which makes anything cross browser just that much easier to accomplish. Raven wanted to have drop-down menu’s with swing out sub-nav’s, instead of the current all-encompassing single drop-down menu that would scroll off all but the largest monitors. In the process of creating/fixing the menu’s I had to identify all the other issues that affected their proper operation. This was to be the road map for the rest of the project, creating a new Master Page structure, and implementing it across RSP.

3. Create the new Master page structure: The new structure needed to handle all the current page layouts and any future ones. To accomplish this I broke the single Master Pages into a system of nested Master Pages, containing different content section areas. These content sections are controlled by logic based on flags set in the controllers, that dictate when to active certain components. Then breaking some of the specific components, for instance the navigation menus, into separate includes that could be selectively cached, which greatly shortens page processing time because they were data base driven. Now if one wants to change the logo or swap out the footer copy-right, it could be done from one place and one place only. Or if you wanted to change out the navigation menu logic, or even add an additional navigation menu component, this can be easily handled within this structure.

   JavaScript Namespaces: RSP is a mature application that has evolved over a number of years. And like most mature pieces of web based software it incorporates an evolution of client side JavaScript. The jQuery framework has become very popular in the last few years for helping to obscure the differences between the browsers and allow developers to basically build to a universal API as opposed to the one off browser paradigm. There are also a lot of other JavaScript frameworks and code widgets that get mixed in with all the custom code that is written. A big problem in JavaScript is that all declared variables of improperly non-declared variables are children of the Window object. So if a variable is declared outside of a closure it will essentially be universal. The is great until two developers declare the same named variable in separate pieces of code that are included on the same web page. The second one read into the interpreter is going to win, which will cause some really unexpected results! This applies to function and object also. The Visual Studio 2010 IDE has a really robust debugger and intellisense system, but that doesn’t translate to the JavaScript code. So we don’t get much help avoiding these problems by relying on that system. A good solution to this problem is “Name Spacing” our JavaScript code. This is the same technique employed by the jQuery framework and many others for that matter. By wrapping all of our code in a combination of self-executing named functions, we can use JavaScript’s closures to protect our variables, functions, and objects. The larger the application and the more people working on it the more important a technique like this becomes.

4. Do the hard work: Many pages/views on the site had multiple modals and UI based user data. Different users would see different content, which makes updating the UI really challenging. When creating something from scratch one takes all these factors in consideration, but when updating an existing application without intimate knowledge of its inner workings or a detailed build specification this becomes problematic at best. With any client side work, be it HTML, CSS, or JavaScript I go at it one change at a time. Make a modification, and then test (often in multiple browsers). Browser based UI work has pretty poor debugging in general, and the cross-browser work can only really be tested in each browser separately. My approach is based on long hours of experience, and plays a key part in my success of turning out mostly bug free code (there are always some bugs, no one is perfect).

5. Merge to QA: After many, many hours of work it’s finally time to push the code out to QA. As always this is an exciting but stressful time for me. This is usually when the work starts to get some real company exposure, and one always wants everyone to be as excited about the work as they are! Every clients QA process is different but the end game is the same, a bug free roll-out! I’m happy to report that in this case there were very few real problems, which in my opinion is a testament to all the talented people involved.

6. Roll-out: Not much to say here… there were a few unexpected problems integrating with another vendors controls that exposed themselves in the production environment. But, because of sound application architecture, a few configuration settings quickly solved the problem.

7. Knowledge transfer: After finishing a project of this scope, with the number and types of changes that were made, it is often best to gather up all involved parties to clarify what was done, why, and how to work with it going forward. This is especially important when the work has been performed by a consultant. I always make it a point to do a good job of documenting my code, and I almost always use a very verbose naming scheme, but nothing replaces a good developer pow-wow. Every group of developers approaches this differently, but I like to go about it as if giving group talk or presentation. Having a defined story board with lots of corresponding code samples, taking any relevant questions as they come up, and finishing with individual specific questions at the end.

Agile Web Development Methodology

Explained...

A question that I'm often asked is "What is your development methodology?" There are a lot of nomenclature and buzz words thrown around the development landscape; "Scrum", "Agile", "TDD", etc... My development methodology has been derived from working with great people on great projects, and I'm not sure that it exactly fits into any of the formal definitions of the aforementioned methodologies. I think the best way to describe it comes from Joe Guido, CEO of Integre International, Inc. He calls it "Agile Web Development" (AWD):

• Agile Web Development (AWD) is a development model that is different from more traditional, out of date SDLC "Big Bang" methods, such as Waterfall, Fountain, and Spiral development. It has proven to deliver more efficient and more powerful results more quickly than other models because it involves continuous user involvement that combines information technology people with end users into a single team that share the same deliverables. AWD uses senior developers and project/oversight managers working together to share and perform management functions, discovery, business analysis, system architecture, Q/A, training, and rollout functions, in addition to their primary functions of development and oversight. The AWD SDLC emphasizes clear and concise goals, realistic planning, and iterative delivery. This AWD construct ensures the successful completion of each product phase by the end of each iteration cycle.

  The AWD model follows planning, discovery requirement analysis, designing, coding, testing, documentation, training, and rollout stages. However, it breaks the deliverables of each application software development step into "digestible bytes". Continuous interaction between all parties' races toward the successful completion of the application software, because of the customer involvement we avoid having to change the product after the fact due to modifications in the requirements. We have learned that these potential changes in requirements happen more quickly and successfully when the user sits next to the developer during the prototyping/unit testing stages. Correct development decisions result by keeping the user close by, during these processes. User confidence is created because joint and informed choices are made, thereby minimizing the omni-present delays which always occur in the traditional SDLC models. The user and developer feel a mutual ownership of each iterative phase and they are not overwhelmed by the bigness of the "Big Bang" methodology when for example a department would have to wait years to get their installed system, all happening after the requirements and expectations have changed multiple times. Using AWD, all the tasks are performed in a given period achieving a stepped result, with just enough documentation to be effective , and with the next iterative phase being just ahead.

  Although many large companies use the AWD methodology for their software development, AWD is generally best for small to medium sized projects that are characterized by:

  • Short timelines
  • Frequent overlapping deliverables
  • Small, highly experienced teams of users and IT professionals
  • Clearly defined planning, goals, and objectives
  • Small budgets
  • Concise inline user and technical documentation

  Due to the continuous involvement and feedback of the user, the AWD application tends to be more error free, more requirement-oriented, and more user friendly. Also, tasks such as planning, development, design, coding, testing, etc. are done simultaneously, driven by the quality of the user’s subject matter expertise and demands and by the developer's experience and desire to please the partner (user). AWD also reduces the development cycle time. The documentation of the application is less formal, but incorporated into the web application's pages in a context-sensitive manner. This is done in order to reduce the time taken to produce it by the developer/oversight manager, and for it to be read by the user, thus resulting in a more usable, human friendly end product. AWD is a methodology, that rather than spending time and budget talking about writing the application, it spends its time doing it, all while enabling users to use it.

I have worked with Joe on a number of large scale, high visibility projects, and with the right team of project managers, business analysts, and developers, the AWD methodology works, and it works well!

Dale Carnegie Course

What a great experience the Dale Carnegie Course was! The course description is as follows; "This course will help you master the capabilities demanded in today's tough business environment. You'll learn to strengthen interpersonal relationships, manage stress and handle fast-changing workplace conditions. You'll be better equipped to perform as a persuasive communicator, problem-solver and focused leader. And you'll develop a take-charge attitude initiated with confidence and enthusiasm."

The Carnegie course constantly pushes you out of your "comfort zone" by asking you to perform often seemingly silly tasks that force you to relay information and personal beliefs to an audience of both strangers and your peers. It also focuses on learning to look at situations from the point of view of others. Identifying interpersonal problems with management, peers, and subordinates and then, most importantly, coming up with solutions to affect real change.

I have always been uncomfortable giving any sort of public speech or presentation in front of both large and small groups. One of the break through nights for me was when I spoke about the passing of my father to the group. The welling of tears that came as I recanted my story forced me into a seemingly vulnerable state, but as I looked to the audience and saw some other teary eyes, I started to understand that this show of emotion was actually a position of strength. I had their full attention, and that in the end was the point of the exercise.

Carnegie teaches you by "doing". Some of the key points that I took away from the course was that even the best speakers/leaders get nervous before giving a speech/presentation, and one can use this natural adrenaline rush to their advantage, harness it to increase focus! Preparation and subject knowledge is vital to giving a compelling speech/presentation, and tying in personal antidotes when possible humanizes the material and grabs the viewer's attention. If you are properly prepared, and thoroughly comprehend your subject matter, you are much more likely to exchange that information successfully with the audience.

This is one course that I think almost any person of any standing could benefit from. It comes highly recommended!