Brilliant Thinking

Application development is undergoing a metamorphosis: on the technical side developers have never had such a comprehensive choice of tools to practice their craft, but the management and skills problems are greater than they have ever been. Less than 20% of systems are fully tested before they go live, resulting in the business being exposed to unnecessary risk; in part this is a management problem since testing tools are readily available – but the question is how best to use these tools. Development management techniques need to keep pace with the complexity and technological sophistication of the systems demanded by business. Agile Software Development (ASD or Agile) is one solution out of this dilemma.

Agile comprises a number of distinctive development methodologies that share a common philosophy and set of principles, as defined by the Agile Manifesto (see http://www.agilealliance.com/). Some of these methodologies, like eXtreme Programming (XP), have been around for a number of years and have built up momentum and experience in the software community. It is easy to get into semantic muddles when attempting to define exactly what the Agile way is and is not, but what matters is the detail, not the label. So the best approach to understanding Agile is to examine examples of the actual methodologies, such as Adaptive Software Development, Crystal, Lean Development, Scrum, and XP.

The Agile approach can be seen as an evolution of Rapid Application Development (RAD), which introduced concepts such as prioritising requirements into sets of must haves, should haves, could haves and will not haves (leading to the acronym MoSCoW). Another concept used is time boxing, a military concept of deferring a decision in the field until the last moment (the boundary of the time box), allowing maximum intelligence to be gathered before commitment. These RAD concepts transferred to Agile methodologies, but Agile introduced not just technical but - importantly - sociological improvements to development practice.

The sociological changes did away with the idea that programming was a black art that was separate from the business, rather the profile of the Agile programmer was a person with good communication skills, and as socially skilled in interacting with colleagues as other employees in the business. Social skills have always ranked high in business roles but to expect it in IT was novel. Agile has also been radical because it subverted well established principles such as: “plan deep and early”, and “build in future extensibility”. Both appear reasonable but both are typically problematic for software: planning deep and early is a waste of resources if requirements are known to change in the lifetime of the project – better to start on a known requirement and build around that. Again, building in future extensibility is another waste of resources because of requirements changes, rather meeting schedules on time or early is preferable to building latent features that are not going to be used immediately. Agile software development has now entered the mainstream, but the next step and challenge is to adapt management processes to work with Agile.

Reasons for adopting an Agile approach:

• Agile software practices can accelerate application development.
• The Agile approach promotes team discussion, understanding, and knowledge transfer over paperwork.
• The Agile way is designed to cope with the consequences of fast-changing project requirements.
• Agile development is part of the drive for quality, embracing Test-Driven Development.
• The business case phase can benefit from an Agile analysis.
• Agile is now mainstream for small to medium scale projects, with experience growing for large-scale projects.

The emergence of the AJAX programming style in the past year and a half has made rich web clients more than just a pipe dream. The fact that it uses established technologies that are in some cases a decade old means that there is relatively little vendor control over its use.

CBR Online story.

According to Coach Wei -Â founder and CTO of Java/AJAX tools firm Nexaweb Technologies Inc and one of the founders of the Open AJAX project - the top issue at this point is interoperability. With anywhere from 150 to 200 different AJAX tools out there, there are as yet no standards for making widgets, or visual controls, which are portable from one to the other. However, that’s just the tip of the iceberg. As the scripting language JavaScript (the “J” in AJAX) is notably unstructured, and consequently, best practices have yet to emerge on how to readily debug JavaScript.

AJAX, a Web 2.0 technology, does provide for some excellent applications - for example Google Analytics, Basecamp, Flickr, iStockPhoto and many more. As applications (ie tools used by a known and identifiable group of users), the AJAX integration provides for beneficial tool to enable a link between a web page and a server-side application without needing a page refresh every time you click a button or link. This may be an over simplistic abstraction, but it is the essence of AJAX. What happens within the AJAX code is limited only by your requirements.

An alternative to AJAX is Adobe Flash. Flash has also had the ability (via Actionscript) to conduct XML interactions with server-side applications. You could argue that Flash is better because it provides additional tools for developing a user interface for your application, so you can get both form and function and effectively deploy a rich application to users desktops via a web browser. This was the push behind Macromedia’s (now Adobe) Rich Media Applications that have been around for a few years now. See Pandora as an example of a Rich Media Application, essentially using AJAX principles behind the Flash interface.

So, the idea is not a new one, but the questions of how we deploy it in a standards-oriented way so that we can safely transform a set of JavaScript programs into a formal architecture which we can enhance and develop as a true enterprise-class framework.

As an aside, we should also not get carried away with the hype of new technologies and look to put Ajax into everything we do. As an application framework it is a very useful addition to the toolkit, but for straightforward web design and development it’s overkill. Remember, JavaScript = no search engine indexing of the content presented by the JavaScript. It also means potential accessibility issues if people have JavaScript disabled. Flash is more portable and may be a better option but it depends on who is going to be using the application.

AJAX will continue to grow in popularity and ubiquity, and as standards and best practices are developed it will become a more capable solution. One advantage it has over Flash is that it’s just another coding language and so is more accessible to developers than Flash which is a different proposition as it requires new applications and new techniques, and often a designer :).

Six months after unleashing its first production version, Zimbra Inc is adding to its Ajax-based email and group collaboration system a WYSIWYG Wiki document editor and threw in the ability to render natively on several major mobile clients.

Full Story - CBR Online.

What is Zimbra? Zimbra is a collaboration suite designed for teams and offers

• Email
• Shared calendar
• Web document authoring and sharing
• “Over the air” sync to mobile devices
• Microsoft Outlook, Apple, and Linux compatibility
• VoIP integration

As a PIM (Personal Information Manager) it covers the bases that Microsoft’s ubiquitous Outlook software does and is server-based, built using Web 2.0 principles. However, it goes much further as it offers true collaboration functions.

The addition of the WYSIWYG Wiki document editor is a significant addition as it allows groups/teams to collaborate on documents securely from anywhere, including many mobile devices. This allows for more virtual team environments, and the inclusion of a security model allows for tighter document control.

For more information on Zimbra, visit their website.

As a follow on from “The Dao Continues” in May 2005, I’m going to return to the topic of design, form and function on the web as it is often a topic for lengthy discussion between clients, designers and developers. It was sparked by a question one of our design partners asked me today - “so how come there are so many attractive sites out there that seem to be html based” in response to a discussion about removing hard-coded line breaks from the text because it was causing the layout to look bad at different font sizes.

There is always a heated discussion on this every time it comes up on the forums I participate in and there are always people who sit firmly in one camp or the other, and then the rest of us that float in between. There’s no right or wrong and, at the end of the day, it comes down to the client requirement. However, there are some “best practice” guidelines which should be considered before they are discarded at the design stage (the list below links to the Business Link Best Practice guidelines).

• Introduction
• Planning your site
• General design considerations
• Accessibility issues
• Designing the site
• Designing for the user
• Web typography
• Site navigation

Beautiful websites can be achieved, but these usually trade off other aspects of the site. Find a “beautiful” website and try changing the font size and see what happens. Some will break, some won’t change (they used fixed font sizes, graphics or Flash), and some will scale fluidly although might not look quite so beautiful. I see a lot of very good looking websites that are purely CSS based (which we try to use exclusively), but they are usually fluid in at least 1 direction (usually page length) to accommodate accessibility and usability requirements.

Sites that resort to using graphics or Flash to display content to ensure they are beautiful compromise usability; people with screen readers cannot see or hear the text. It also reduces search engine results as there is no content that they can index either. The end result is a pretty, fixed site but not necessarily a very usable one.

Incidentally, did you know it’s actually UK law that websites should be accessible (i.e. not deliberately exclude anybody)? Nobody really enforces/polices this, but it has wide-reaching effects from the graphic design itself right through to the coding (choices of colour, font sizes and much, much, more). If you can’t sleep, I’d recommend reading about accessibility On a serious note, we actually partner with Test Partners (who run accessibility.co.uk) to perform full accessibility testing to ensure we meet the client’s requirements when necessary.

In my view, there is a spectrum of design approaches from fixed layouts at one end to fluid layouts at the other and a good website is one that blends aspects of both to deliver the best experience as possible to the user of the site (ie not the minority that is the designer and/or the client).

Fixed                                                 Fluid

+ - - - - - - - - - - < - - - - - - > - - - - - - - - - - +

Form                                               Function

Marketing                                       Application

Some sites are beautiful at the “default” browser settings. However, it’s not the “default” settings we need to worry about, but those that are outside the bell curve - if we have to consider cross-platform issues to be inclusive for PC (IE/FireFox) and Mac (IE/Safari), why not include other visitors who use these browsers with non-default settings?

I try to occupy a middle-ground on the spectrum, providing a balance between form and function so that sites look good, but work well too. I do not go as far as some accessibility “extremists” who produce completely fluid sites with very few (if any) graphics (I think these sites are dull), and I don’t like the totally fixed sites which make it look like a printed brochure because the designer wanted it that way (I think these sites are missing out on the huge potential of the web).

At the end of the day it comes down to User Experience - understand who is the end user and what do/will they expect from your site and that will help you find the right place on the spectrum.

There are a couple of great books about the web experience which I would recommend for designers and developers (”Don’t Make me Think” - Steve Krug, and “The Art and Science of Web Design” - Jeff Veen). I’d also recommend looking at alistapart.com which has some great articles. I look at these as part of the toolkit for designing and building effective websites today, along with using new technologies such as AJAX as and when appropriate.