We just came back after spending a week in Research Triangle Park (RTP) area in North Carolina where my wife had a workshop. From there we drove to Hampton, VA to attend a friend’s daughter’s wedding reception. On the way, we stopped at the Dismal Swamp State Park. It was pretty hot there, but the RTP area is fabulous and provides a lot of opportunities to walk around. I also played a lot of golf, once paired with a grandfather and his 14-yr old grandson. The kid played awesome and was one under for the course – Raleigh Golf Association. If he goes on to become a pro, I can claim that I gave him some tips 🙂

I was thinking about where we were a year ago – right in the middle of Google transition while beginning our work on Drupal. I am very happy to see how through the excellent work that the LTS staff have put into these projects, we have achieved so much in such a short time. And, now,  we are being called on for advice.  At a Drupal gathering a couple of weeks back in Waltham, there were several interested parties who wanted to know about our Drupal implementation. They were collectively impressed by the speed at which we moved as well as the process we have established and the technological innovations we have brought to the table. I have fielded calls from at least six other institutions about our Google implementation, especially our LMS built on Google and LTS staff did a show and tell recently to a couple of other institutions. This is great progress.

Though I use my Droid phone for accessing the internet a lot, I have also seen a huge shift recently to Mobile friendly apps. Pretty much everything that I need to do such as banking, bill payment, editing google docs, can all be done relatively easily on the mobile device. We are increasingly hearing the term “Responsive Design“, which basically refers to a site that responds with the content in a way that it renders well in the device that is requesting content. This is also tied to the “Mobile First” strategy in that increasingly, the users are doing business from their Mobile devices and recognizing that and serving content that way is critical for future success. It is high time that our strategy includes this.

It is no secret that the the last thing in the minds of application developers early on was usability. We all wrote programs that did a great job functionally, but didn’t look and act in ways that was conducive to easy use by the users. We needed documentation and training for that reason. Then in the late ’90s we needed to make adjustments to the way we did business because the world was moving towards the world wide web. I remember the hard battles I had to fight in my previous institution to move to the “web first” strategy. In other words, we wanted all programmers to write for the web first. Not only that, we also needed this to be done in a way that the code and style needed to be separated. Whereas this made a whole lot of sense in many ways, it was a hard sell. Typically, programmers would like specifications all ironed out so that they can finish their work and hand it over to those who requested. Minor changes are anticipated and accommodated. The whole idea of a product that is “Forever beta” and remains unfinished is alien to many.

In the “web first” paradigm this does not work. The functional offices requesting the application can never give the full specs because once they see an app, they want adjustments made to the look and feel as well as text used. In the old way of doing business, code contained all these content and you needed the programmer to make all these changes. Of course, this is really not something that the programmers like to do. So, one would think that separating the code from style and handing over the responsibility of colors, text and even layout of the page to the functional office would make the programmers happy. Unfortunately not. This model assumes that the functional office staff know how to work with the templates etc. Also, when multiple hands are involved in a production system and when it breaks, it is not clear where to draw the line of responsibility. This creates unnecessary tensions resulting from the unavoidable finger-pointing (and in many cases just the fear of it).

As always, the truth is somewhere in the middle. But that should not stop us from doing the right thing and over a period of time, it will sort itself out. I think we are in a much better place now to attempt to move to Responsive design or Mobile first strategy. The reason is, we are already a log way on the path to separation of code and style. In many cases where this is not the case, the tools we are currently using such as PHP, allows for changes to the style much easily than before. Now, the Mobile First strategy is a lot of work on the style end rather than the code end. We still may have to go back and tweak things in the code.  However, the fact that we are doing a lot of our work using a framework means it will be a change in one or two places.

As we begin to formulate our short term strategy for LTS, we will have Mobile First feature in it prominently. Of course, this does not mean that our content won’t render on larger devices! I fear that as we move to this, something new will emerge, such as a virtual reality paradigm or a Google’s Glass API. Oh, such fun!