Agile Software development, Acessibility, Minification & SVN
1 year & 2 months in and I am very happy with being in an Agile pod and getting first hand experience in an Agile development software pod. Basically it's the AT&T eCommerce web site and I belong to the Global Experience Pod (Code named The Fifth Element / Tesla) and we are doing good works and so far we have made improvements to the website, especially related to the Global Navigation portion.
Within the website (www.att.com), my team has added on the Top navigation (top most, on the right hand corner) the Wireless Coverage map and within the Primary navigation (orange colored area) Shop, MyAT&T and Support tabs are larger as part of the ease of use improvements that our pod has been charged with.
It is unfortunate that priorities have changed, and the original ideas of having Navigation take over the whole web site as a single ear file deployment (next gen navigation) and letting other services tap into a smaller real estate in the middle of the page for their purposes like Shopping, myAT&T account management etc have been scrapped.
Currently the system deploys 4 different ear files to run att.com and each of these will then implement their version of global nav war file. This creates an in consistent customer experience and when there is a deployment or changes, it is a painful process in general to get all services aligned.
So for now, a compromise has been reached where we deploy a universal navigation service for the Top Nav, Primary, Secondary & Tray Nav and the footer. This service is readily available for these 4 ears to call and hopefully will make navigation more versatile and "stand-alone" so that changes can be easily reflected in navigation, should there be a change and all these individual ear file owners & development groups need not worry about retrofitting the war file and to bang it into shape for it to work "seamlessly". I have much hope that the November 2013 release will prove this.
There still is, in my book, one major Achilles Heel issue with Source Code Management / SVN, and all these old school waterfall process of "code freeze" major deployment dates. It definitely is not a true Agile environment especially when it comes to software release and the whole mandatory 30 - 40 day code freeze. In general every sprint we do no release and have to wait to piggy back on to a major release just because of how the website is set up, where Global Navigation has to be uniform throughout the pages and Global Navigation touches every ear. I guess the main issue that we have with this waterfall method of release is having a time crunch to get things done and ready (especially with the FCC Mandated Accessibility compliance and AT&T's mobile first initiative) with many last minute directional changes which constantly throws a new hurdle / challenge as to what we need to aim for to develop, test & deliver.
On that note though, I have gained some experience with regards to accessibility testing. Examples are ratio color testing between background and text, ARIA markups and NVDA / JAWS screen reader testing. To a certain degree, I almost feel that we are the first penguins in the water since there is pretty limited resources out there referring to retrofitting or building appropriate styles with proper Aria Markups and it seems like NVDA is mostly in its infancy perhaps. From what I understand, seems like these screen readers actually do take a "screen shot" of what it sees and from there it interprets what it thinks it sees and reads it out. With this in mind, it is a possibility that our test servers (and perhaps client side / end user side) are slow to generate what is seen and hence many times, the NVDA is not able to pick up & read on what we perceive to "see". This has made me more appreciative of my sight, and to be more sensitive and aware of the plight and difficulty of visually impaired users when it comes to surfing the web.
A few other things that I notice is that:
It is unfortunate that priorities have changed, and the original ideas of having Navigation take over the whole web site as a single ear file deployment (next gen navigation) and letting other services tap into a smaller real estate in the middle of the page for their purposes like Shopping, myAT&T account management etc have been scrapped.
Currently the system deploys 4 different ear files to run att.com and each of these will then implement their version of global nav war file. This creates an in consistent customer experience and when there is a deployment or changes, it is a painful process in general to get all services aligned.
So for now, a compromise has been reached where we deploy a universal navigation service for the Top Nav, Primary, Secondary & Tray Nav and the footer. This service is readily available for these 4 ears to call and hopefully will make navigation more versatile and "stand-alone" so that changes can be easily reflected in navigation, should there be a change and all these individual ear file owners & development groups need not worry about retrofitting the war file and to bang it into shape for it to work "seamlessly". I have much hope that the November 2013 release will prove this.
There still is, in my book, one major Achilles Heel issue with Source Code Management / SVN, and all these old school waterfall process of "code freeze" major deployment dates. It definitely is not a true Agile environment especially when it comes to software release and the whole mandatory 30 - 40 day code freeze. In general every sprint we do no release and have to wait to piggy back on to a major release just because of how the website is set up, where Global Navigation has to be uniform throughout the pages and Global Navigation touches every ear. I guess the main issue that we have with this waterfall method of release is having a time crunch to get things done and ready (especially with the FCC Mandated Accessibility compliance and AT&T's mobile first initiative) with many last minute directional changes which constantly throws a new hurdle / challenge as to what we need to aim for to develop, test & deliver.
On that note though, I have gained some experience with regards to accessibility testing. Examples are ratio color testing between background and text, ARIA markups and NVDA / JAWS screen reader testing. To a certain degree, I almost feel that we are the first penguins in the water since there is pretty limited resources out there referring to retrofitting or building appropriate styles with proper Aria Markups and it seems like NVDA is mostly in its infancy perhaps. From what I understand, seems like these screen readers actually do take a "screen shot" of what it sees and from there it interprets what it thinks it sees and reads it out. With this in mind, it is a possibility that our test servers (and perhaps client side / end user side) are slow to generate what is seen and hence many times, the NVDA is not able to pick up & read on what we perceive to "see". This has made me more appreciative of my sight, and to be more sensitive and aware of the plight and difficulty of visually impaired users when it comes to surfing the web.
A few other things that I notice is that:
- AT&T uses way too many cookies
- Due to the IE7 issue, the work around was to use images (rather than CSS image rendering etc) so that the web site looks uniform, and hence creating a lot of latency and server load in order to display the page
- Seems like the developers are not careful when it comes to code merge, added on top of automatic "cron jobs". In essence, everyone seems to be stepping on everyone else's toes. One minute the functionality from my Pod are working fine and on another instant everything is broken or undone.
Perhaps I am not as well versed with regards to web development, however there are so many options and choices available out there for dynamic generation of a web site I'm surprised why Ruby on Rails or PHP are not used to run the website.
Comments
Post a Comment