Sunday, March 22, 2009

Browser Wars ... Again

This week, I had the unfortunate and pleasant (seems strange I know) experience of upgrading my Internet Explorer version from the Release Candidate version to a full blown Internet Explorer 8. While I will say that Microsoft have gone through the hoops and actually put out a very quick browser, what it makes up for in speed it certainly lacks in overall compatibility. The Acid Test for this browser was just horrendous and with coding getting standardized across the board, Microsoft have gone back to their happy niche of saying 'if we didn't make it, we don't care about it'. This however, beckons another discussion based on what I wrote in my previous post about universalizing languages on browsers.

I wonder how many web deployments take into consideration browser requirements for an end user other than the current favorites - Internet Explorer and Firefox. Now, this could be argued with by saying that if the work is done on a Mac then Safari automatically comes in the picture but the boys at Apple and most Mac designers have pretty much got it right when it comes to making webpages for the general masses. I have seen some horrendous deployments in my time that have taken absolutely no consideration about browser-usage statistics and the end users who eventually have to use the system. Some of the browsers that I like testing with for the total web experience are

  1. Firefox 3.X
  2. Minefield
  3. Internet Explorer 6
  4. Safari 3.X
  5. Opera
  6. Internet Explorer 7.X
  7. Chrome
  8. Internet Explorer 8.X
This list is in order of preference with Chrome coming at the bottom for the most obvious reason, its just not enterprise ready yet but maybe one day it will be.

Some of the common problems I have seen in deployments are mentioned below

  1. Deployment of plugins
  2. Table alignment
  3. Content delivery using Java and ASP.NET
  4. Load times
  5. ActiveX
Barring the last one in the list all the rest of these problems show erratic behavior based on your preference of client. One of the biggest mistakes most IAs make in the process of designing a web solution is that the operating system is a Windows-based one and we will worry about any others later on. Unfortunately, this leads to differences in the deployments and some value-add specificaitons are dropped due to incompatibility between two systems. ActiveX is a Microsoft only service and hence doesn't play well on any other operating systems (OSX or Linux); yet, some developers think that because we are given these tools we must develop in them as they are the only way to get the product out to the masses. Sadly, this may be considered a successful deployment from a WinX POV but at the end of the day its a total failure on the side of the other operating systems. Java and ASP.NET are two more troublesome deployment considerations that most people sweep under the rug as 'end-user' issues when the problem is clearly in the deplyoment and not with the end-user. Lastly, plugins are a nightmare for any Firefox or Safari user on a WinX system simply because most web designers/developers rarely take into consideration that not everyone out there uses Internet Explorer as their primary browser. Its not a bad browser, its just not the safest thing the web has to offer right now and with a lack of compliance on nearly 80% of the new standards, I can't see any power user in the enterprise environment considering that as a primary browser.

Some thoughts I always like to put into practice when I am developing or working on testing web solutions.

  1. Have I covered all the major players ? IE, FF, Opera, Safari
  2. Am I unnecessarily adding functionality in the backend that won't work cross-platform?
  3. Is it important to use what I am given in the tool-set that it comes packaged with or can I simply extract the information and manage it in a browser differently?
  4. Is Flash/JAVA-AJAX really necessary for the web-tool to function properly?
  5. Who is my audience?
  6. Do I want my audience to grow?
  7. What are the implications if the browser with the best results doesn't do the job?
In my experience, most users don't like changing the browser that they work with. I have been using Firefox for a very long time now and its only recently that I am giving Safari a chance and it has failed on many ocassions due to backend compatibility but that I am sure is something that can be fixed with a little bit of time and tweaking of the java.

In conclusion, the end product of any web deployment or design should encompass a 'wholesome' experience unless the user-base is a niche community that has access to all the tools being offered. I certainly don't want to make a product that passes 20 tests and fails 80 but it seems that alot of things I see these days are following this trend. Only time and a better understanding of world-wide accepted standards will fix this. Till then, pick your weapon and make sure it can stand the test of change ....

Browser used to write this blog : Firefox 3.0.7
Mood : Happy
Music Listened to : The sound of Diner Dash 4.0

Wednesday, March 11, 2009

Multi-Lingual Systems

Sometimes, we browse content on the web and wish that there was an easy way for us to just switch between languages to make the experience more "wholesome". Most websites out there actually come with a language option varying between different dialects of the English language coupled with some other latin script languages. Of course, this offers users in those languages the opportunity to experience the website in the language of their choice but what about all the other languages that sit outside the scope of what those websites are offering? Do they simply pick up another language or do we assume that everyone reading these pages is a master of one of the choices on the page? The answer may lie in web technologies or future WWW technologies that do translations based on inputs received from users in the system. One such product that I have had the pleasure of working with is IBM's Websphere Translation Server. The server sits as an intermediary over Sametime (The internal messenger used by most IBMers) chats and converts the languages before they reach their destination. For eg. I type in English and the recipient sees it in German. However, this is certainly not enough considering the goal is still not accomplishing a total conversion task.

While I have pondered on the requirements that would make such a feat possible, the end result isn't really all that complicated when you consider the following points.
  • Most dictionaries are updated yearly (sometimes the frequency is much less)
  • All systems are moving to e-Storage
  • Most systems aren't allowing legacy storage techniques as the concept of ease-of-access gets disrupted
  • Languages continually change are modified by consortiums sitting in those countries
  • Web technologies like CSS3 and XML are making the user-defined experience more easier to deploy

The list can once again go on and on but lets focus on these points for now. The primary problem with language-related development is that there will always be significant differences in interpretation when one language is converted to another and this has to be considered when working with technical content as well as literary content. Here are some solutions that might be tried.
  • XML Style Sheets that use conversion methods in the framework for moving certain words and their combinations together
  • Developing world-wide standards for delivering webpages without hampering the process and creativity that goes into most websites
  • Encouraging more developers and designers to start using content development techniques that are feasible to easy conversions thereby touching more users in other languages
  • Enforcing a standard set of protocols in web-browsers for easy conversion that may eliminate the XML Style Sheets mentioned in the first point. The less work done on the website means less work by the developers
  • Using the systems managed by Linguistic teams globally to update the XML content and thereby offering users the most updated information
While the road is long and hard, I believe that most people will benefit from this development. Can you imagine a world where your content can be carried in your pocket on a mobile device and simply converted on call? How about working on a project in India and then deploying it in Japan without ever having to worry about the language requirements in the middle? Imagine a world where creative minds didn't need translation services and worked on simply taking content and pushing it out for everyone to read. The pros are many but unfortunately the amount of jobs lost and the continual man-hours spent in updating XML Content would surely outweigh this need right now. The next step I guess is to automate the updates ... One day.

Music Listened to while writing this blog - Joan Jett - Dirty Deeds (AC/DC Cover)
Mood - Creative