Brad Abrams provided a few predictions for IT-Technology in 2008. I started posting a comment, but it was getting a bit long. So, here are my comments with some snippets from Brad's post.

#1) User Experience Reaches the Enterprise

In 2008 we will see several major enterprises start efforts to build UX centric applications that increase worker productivity, reduced transaction costs and increase pull through as the UX meme of the consumer facing world leaks into the enterprise. The days of the battleship gray, forms of data application as the king of the enterprise are numbered because of an imperative towards richer visualization of complex and interconnected data. ....

Battleship gray forms are cheap and easy for an enterprise developer. The tools make them easy. Even with a toolbox full of IDEs from Microsoft, doing something outside of a standard data entry form is complex. Sure, I can make a quick gradient -- but that's just eye candy, not visualization.(Though some days even picking the colors can be a challenge!)

<RANT>It's still hard to do a nice WPF data entry form that can take advantage of WPF features without resorting to grids in grids in grids</RANT>

Data visualization is a tough nut to crack -- it's hard enough some days to get a simple table to layout correctly the way you want in WPF/HTML/Silverlight/Flash/etc., but actually deciding there's a better way to "visualize" the data is a real art and skill that many developers lack. It's not their fault either -- I call it art for a reason. It's a real skill, not everyone is an artist, a musician, a chef, a leader, or even a computer programmer. We each have our unique combination of talents that make us, well, unique.

Although there are definitely exceptions to this, 'scientists' are often not the best artists. Look at the history of computer software -- look at how many UGLY applications you've used (I'm ignoring usability entirely as that's another skill, but one that is more trainable).

The art is much more difficult than the battleship gray form. Plus, it takes a lot more time.

Rather than trying to change the way data is visualized, the first step in most enterprises is to simplify and make the data more accessible through better use of colors and fonts (usually font weight, not different fonts like this). Once they've nailed that aspect of an application or module, they might step back and see if there's better ways to actually present the data (graphs, 3D, etc.). In far too many cases, the expense of doing that development work will exceed the end user benefit. (And sometimes, a graph may require more user time than just displaying the data formatted nicely).

3. The Companion Applications Become Practical. While RIA and AJAX application categories continue to grow, many consumer facing web applications and enterprise applications developers realize there is a need for desktop exploitive applications as well ...

IT shops don't like to manage workstations. They don't like to install upgrades. They want to move users to web versions of applications to simplify the management of their complex IT needs. Sure, there will be companion applications that are occasionally necessary as the web is not yet capable of delivering a complete 'desktop' experience (think hardware integration, real time feeds, etc.).

What meaningful application wouldn’t benefit from a pairing like that of Outlook and Outlook Web Access? In the past it has been prohibitively expensive to build these applications, but with the circa 2008 technology such as .NET Framework 3.5 and Silverlight, it is finally becoming practical to have a single codebase that fully exploits the desktop and offers a rich web experience.

Really? It's really complex to build an application that can run on the desktop and run on the web. Some aspects can be shared, but the way you would write applications is often very different on the web when compared to an installed application. His example, Outlook is perfect. Outlook 2007 uses a local cache and from my experience about 100MB of RAM when running (Outlook 2007 is using 91MB right now on my home machine). It would be completely impractical if a web version of Outlook used 100MB of RAM for every user who connects. So bad it would be nearly criminal!

The user interface is fundamentally different (one has threads, the other doesn't, the display needs are completely different, sending mail is different, etc.) and although you could extract some shared code again, in the end I don't believe it would pay to do so. It's cheaper to make two distinct clients of the Exchange server, sharing minimal code and mostly protocols (web services?) and techniques only.

More likely though is that a development shop would decide on one version as it would cost too much to maintain two. Microsoft (and Outlook) is unique with the army of developers that are available. Corporate IT and enterprise developers have no such luxuries of time and resources. They can't cross train in multiple languages, tools, ... it just takes too much time and energy.

If an enterprise was developing it's own email front end, they'd do it once and use the technologies that make sense. I could see using Silverlight if they were using ASP.NET, mixed with HTML to produce an effective, modern email client.

I'd change #3: the move to the web and away from the desktop will continue to grow (which may improve the UX of some applications). Developers will start to use Silverlight, Flash, Flex, to enhance the usability of their web applications.