Miljan Braticevic

$10,000 for the Best Silverlight App!

2009-06-22T18:39:00Z

Ok, this should be a lot of fun!

ComponentArt has just announced the official beginning of the 2009 Summer Silverlight Coding Competition. Starting immediately and throughout the summer (until September 22), developers can submit their Silverlight applications for evaluation by our Expert Panel and the developer community. The author(s) of the "best" application, as decided by the Expert Panel and the community, will walk away with the grand prize of $10,000 USD. Authors of the two runner-up applications will each receive ComponentArt licenses (a $1,299 USD value).

How the Winner Will Be Chosen

Obviously, there's no such thing as the "best" application. The winner will be chosen based on the number of points collected from the Expert Panel (maximum 450 points) and the community vote (maximum 100 points). So, we highly value the opinion of our Expert Panel, but the community vote might well tip the scale and select the winner!

The grading criteria and the precise details for collecting points and are outlined on the how to win page.

Our Expert Panel

We are proud to have the following individuals on our Expert Panel:

Microsoft Silverlight Team
- Tim Heuer
- Laurence Moroney
- Mike Snow

Industry Gurus
- Dino Esposito
- John Papa
- Steve Smith

ComponentArt Silverlight Team
- Milos Glisic
- Phil Tucker
- Corey Cahill

Use of ComponentArt Products is NOT Required

Applicants are not required to use ComponentArt's products to enter the competition (or as the legal jargon requires us to say: NO PURCHASE NECESSARY). We'll obviously let you use our products if you want to, but the purpose of this contest is to increase awareness of Silverlight features and applications already released, so we would like to keep it open to the entire Silverlight developer community.

The full contest rules are available here. Let's have some fun and may the best app win!

Share this post: email it! | bookmark it! | digg it! | reddit!

ComponentArt: Past, Present and Future

2009-04-21T14:12:00Z

Shipping UI Framework 2009.1 was a lot more than a software release here at ComponentArt. In many ways, it was a re-launch of the company itself. Now that the big release is out in the wild, I thought that it would be fun to reflect on what we have done in the past as well as think about what lies ahead.

A Walk Down Memory Lane

A couple of days ago we went through our archive of previous websites and had a good laugh while we relived some of those moments. Here is a quick list of the key points in ComponentArt's history, with website screenshots:

		February 28, 2002 - The Beginning ASP.NET Menu launched by CYBERAKT INC. Throughout the summer of 2001 we were evaluating Microsoft’s new .NET Framework, which was in Beta 2 at the time. We were very impressed by ASP.NET and thought that it could use a good menu control. Our first software component product - ASP.NET Menu – was released at the same time as ASP.NET itself. It quickly became the most downloaded control on the official ASP.NET website and sales started pouring in! Without a doubt, ASP.NET Menu was the big catalyst that enabled our growth.

		March 28, 2003 - Rich Content Rotator Proceeding with the rich DHTML control theme, we released our next product: Rich Content Rotator for ASP.NET (we affectionately refer to that control as "Rotato" here at the office). Rotato was less than a blockbuster product for us: it wasn't anywhere near as popular as ASP.NET Menu. Also notice that it took us more than a year to release the second component. In any case, we learnt that you can't win them all and started working hard on our next release.

		May 14, 2004 - ComponentArt 1.0 This release marked the end of the "CYBERAKT" era. We changed the company name to ComponentArt and went through an elaborate rebranding exercise. We wanted a fresh new look that would be distinctive in the marketplace. Market reaction was overwhelmingly positive and we received numerous awards for our print ads in the coming years. This release also marked the introduction of our flagship Web.UI for ASP.NET product line, with TreeView and Snap controls added to the mix for a total of four components!

		September 9, 2005 - ComponentArt - AJAX Edition Skipping a few smaller releases, it was Web.UI 3.0 that marked the next major step in our offering. We implemented client-side rendering across the entire Web.UI suite, released our super-popular Grid for ASP.NET control and introduced the first generic AJAX container control for ASP.NET: ComponentArt CallBack (code named "AjaxBox"). This control was a major innovation. Notice that we released it well over a year before Microsoft's UpdatePanel control and quite a bit before any other competing products. (By the way, CallBack and UpdatePanel have different architectures and are complementary products. More info on that is available here).

		December 21, 2005 - Charting Redefined End of 2005 was when we revealed our next major achievement: Charting for .NET. We had been working on that product for 2 years prior to its release and we were very proud of our own 3D rendering engine. The rendering quality of our charts was impressive enough for the most established charting vendor to approach me at a tradeshow and ask: "Hey, who wrote your rendering engine?" I replied with a smile: "My dad." But that's another blog post.

		November 21, 2006 - The First True "Atlas" Controls We had been working closely with the ASP.NET AJAX (code named "Atlas") team for many months prior to shipping Web.UI for ASP.NET AJAX. Our release was parallel with the "Atlas" release itself and generated a great deal of buzz in the industry, including a mention on Scott Guthrie's blog. Business-wise, this product was also a blockbuster for us. The strategy of putting so much effort into supporting an upcoming MS framework and developing against its alpha bits was a risky one. It took some effort to convince the management team, but it really paid off in the end.

		May 1, 2007 - The Ribbon Nav The May 1st release marked a website redesign and the introduction of ribbon-based navigation. Implementing non-standard UI elements for main navigation was another risky move. We had to make sure that it was perfectly executed, otherwise the website would be rendered useless (additional thoughts on that exercise are available here). We worked long and hard on the new site and in my opinion once again ended up with something unique and well executed.

ComponentArt 2009.1

Even though we've done some noteworthy things in the past, our latest release is undoubtedly our biggest achievement. We have grown our product offering by an order of magnitude, completely redesigned the website and introduced a new brand: ComponentArt UI Framework for .NET.

I believe that this product release is significant beyond the fact that we have shipped a number of new components. We are introducing a powerful new paradigm with UI-centric web services and the ability to share code between AJAX and Silverlight applications. Most web developers on Microsoft's platform today are somewhere between building vanilla ASP.NET apps and full Silverlight adoption. Our SOA.UI framework was designed to help bridge that gap as well as offer value to those who are already there (you can save quite a few lines of code even if you are doing Silverlight development exclusively). A lot more on that later.

The new website is something we are particularly proud of. We have decided to take another fresh (although not as radical) approach to navigation. I think that the new "mega menu" works quite well. However, our customers always have the final say regarding these things, so please let us know how we did.

ComponentArt v.Next

You won't be surprised to hear that we are already working on the next release. As outlined in our new product roadmap, our plan is to expand our existing product lines as well as introduce a new Win.UI for WPF control suite by the end of the year. We are also working on additional website upgrades: the knowledge base and community sections will see major overhauls in the near future.

We will always continue to think about creative ways to add value to the platform and best serve our customers.

Share this post: email it! | bookmark it! | digg it! | reddit!

Tapping Into the Raw Power of Silverlight

2009-02-17T21:37:00Z

We are excited to announce the availability of ComponentArt Web.UI for Silverlight Beta - our latest suite of controls for Rich Internet Application development. The initial release will feature eight controls, with rapid expansion of the suite planned throughout 2009. Links to live demos, beta download package, as well as detailed roadmap information are all available on our Silverlight Controls page.

Admittedly, we are a little late to the Silverlight party. Other leading vendors have been offering Silverlight products for a few months now. On top of that, there is Microsoft's own excellent Silverlight Control Toolkit, containing a large number of controls.

However, what's missing from the marketplace at this time, in my opinion, are real "industrial strength" line of business controls. Rather than trying to quickly ship a large number of controls, we decided to take our time to make these core controls (Menu, TreeView, Grid, ToolBar, etc.) as solid as possible. There are many features that we still want to add, so this release is only the first step on that journey. I hope you will find that our effort was worthwhile and that we managed to deliver best-of-breed core UI functionality.

Silverlight is truly a wonderful presentation layer platform. Products currently offered in the marketplace merely scratch the surface of what can be done with it (that includes our own offering). There is so much "raw power" in Silverlight and we are really excited about the opportunity to add value to it.

As always, your feedback is welcome and highly appreciated. Please let us know what you think about the current features as well as the announced roadmap. A flurry of blog posts by our Silverlight team is forthcoming, I'm sure, so don't hesitate to tell us what you'd like us to write about.

Share this post: email it! | bookmark it! | digg it! | reddit!

ComponentArt Web.UI 2008.2 Details Announced

2008-07-10T18:34:00Z

The Web.UI product team has been hard at work on the next major release of ComponentArt's flagship product line. I am pleased to announce that the release of Web.UI 2008.2 is on the horizon and that it will include three new controls, a major Grid overhaul and several important new suite-wide features.

Three New Controls

The Web.UI suite is being expanded yet again. The following controls are being added with v2008.2:

Input for ASP.NET
Slider for ASP.NET
ColorPicker for ASP.NET

Major Grid Overhaul

Since its initial release, ComponentArt Grid has been perceived as one of the most valuable controls within the Web.UI suite. Our Grid-related R&D work has introduced many important innovations into the ASP.NET control space: client running mode, client-side structure creation, client templates and direct binding with web services, just to name a few. We are excited to push the capabilities of this control even further by adding the following features in v2008.2:

Multi-level grouping (web service running mode only)
Header context menus
Improved editing capabilities
Revamped keyboard support
Client-side sub-level sorting
Templated footer rows

New Suite-Wide Features

The following suite-wide features are being added with v2008.2:

Extended support for direct binding with ASP.NET AJAX web services
Accessible output and Section 508 compliance
ASP.NET MVC support
Extended keyboard support
Revamped product documentation

Release Dates - Updated!

The anticipated release dates for Web.UI 2008.2 are as follows:

Beta Release: Week of August 18, 2008
Full Release: Week of September 15, 2008

Please note that these release dates are based on our best estimate and are subject to change.

Share this post: email it! | bookmark it! | digg it! | reddit!

Charting 2008.1 - Boldly Going Where No AJAX Chart Has Gone Before

2008-06-17T18:24:00Z

We are thrilled to announce the release of ComponentArt Charting 2008.1. This product has been in the works for well over a year and it brings a number of truly important new features to the market. At this time I would like to highlight the two most significant areas of product improvement in v2008.1, and the Charting development team will follow up with additional juicy details related to the new functionality.

AJAX Interactivity

We think that the new view angle chooser, zooming and scrolling UI and the drill-down features push AJAX capabilities further than any other charting solution on the market. A key point here is that all of these features were implemented through the brand-new client-side API of the WebChart control. We are only scratching the surface of what can be done by showing a few practical applications of this API.

Dual Rendering Engines

The 2008.1 release of Charting for .NET introduces a new high-speed rendering engine, augmenting ComponentArt's famous 3D rendering quality with the ability to produce GDI+ chart renderings in high-traffic environments. All charts within our brand-new gallery can now be viewed through both rendering engines.

I hope this has served as a nice high-level overview of the most important new features in v2008.1. Many additional details will follow in the coming days and weeks.

Share this post: email it! | bookmark it! | digg it! | reddit!

ComponentArt Web.UI 2008.1 Details Announced

2008-02-27T14:19:00Z

We've been hard at work on Web.UI 2008.1 for a few months now, and I am happy to report that we are rapidly approaching the feature-complete beta milestone for the next major Web.UI release. This means that we are ready to announce what will be included in v2008.1 as well as our anticipated release dates.

Web.UI 2008.1 Overview

The upcoming Web.UI release will include the following major new features:

New control: ComponentArt Upload for ASP.NET
Extended suite-wide support for web service binding
Expanded Editor features:

New "Media Explorer" dialog, with uploading capabilities
Streamlined skinning

We are on schedule to ship the full production release of Web.UI 2008.1 by the end of March. The first public feature-complete pre-release build of v2008.1 should be available in about two weeks.

New Control: ComponentArt Upload for ASP.NET

We are excited to yet again expand the Web.UI suite by adding a highly demanded file upload control. As always, we are aiming at the very top of the market, so this control will include all the high-end features that you've come to expect from ComponentArt's ASP.NET controls: multi-file uploading, AJAX progress indicators, comprehensive client-side API, full control over the upload file and folder details.

We were able to put our client-side templating technology to a good use to provide some snazzy and highly customizable UIs. I'll give you a taste of what's coming by including a product screen shot from our development branch:

More info and some live demos featuring our Upload control will be available in the coming weeks.

Update (March 27, 2008): The full Web.UI 2008.1 release is now available.

Share this post: email it! | bookmark it! | digg it! | reddit!

A New AJAX Approach - Client-side Controls Invoking Web Services

2008-01-25T17:29:00Z

Since the time we shipped our first production suite of native ASP.NET AJAX controls back in November of 2006, we've been experimenting with new ways of doing efficient incremental page updates. We felt that we had something promising on our hands with full fledged client-side controls. The ability to create high-level UI elements (menus, treeviews, grids, etc.) on the client seemed like a solid foundation to build on.

Our research produced a new high-performance AJAX technique which is currently gaining quite a bit of momentum among our customers. I will explain how this technique differs from standard AJAX techniques, with comments on ease of use, performance, elegance and the available client-side features within each technique.

I highly recommend trying the live examples associated to individual AJAX techniques below. Significant performance improvements are quite visible when the same functionality is implemented using different AJAX approaches. The final example is so fast that it truly feels like a local desktop application.

Overview of Common AJAX Techniques

Technique 1 - Server-centric AJAX Containers (ASP.NET AJAX UpdatePanel)

The server-centric AJAX container technique is employed by the ASP.NET AJAX UpdatePanel control as well as several AJAX solutions sold by the leading 3rd party control vendors. UpdatePanels are driven entirely by ASP.NET postbacks. AJAX applications are created by wrapping postback-based ASP.NET portions of the page and specifying which triggers (server-side events) will cause certain page areas to re-render.

Ease of use: The most obvious advantage of this approach is that it is extremely easy to implement. It is really not much harder than building a vanilla postback-based ASP.NET application and then wrapping certain areas of the page with UpdatePanels. This approach is ideal for quickly adding AJAX features to existing ASP.NET applications.

Performance: The biggest downside of this approach is performance. UpdatePanels always post the entire page - including full viewstate - to the server. Even though the required AJAX update to the page is often minimal, its server-side page processing essentially takes the same resources as when doing a full postback. The response sends raw HTML back to the browser, adding kilobytes to the required network traffic to process the AJAX request.

Elegance: The server-centric AJAX container technique is fairly elegant from the implementation point of view. Page areas are cleanly wrapped by UpdatePanel instances and AJAX updates are accomplished by mapping server-side events to triggers. All AJAX magic is performed by the UpdatePanel control itself.

Features: All features exposed to the developer using the UpdatePanel control are entirely on the server side. The control was not designed to be driven by client-side logic. The server-centric approach lacks the finer level of control on the client, which is definitely needed to build sophisticated AJAX apps with hyper-responsive user interfaces.

AJAX Explorer Example: Technique 1 - Server-centric AJAX Containers (ASP.NET AJAX UpdatePanel)

Technique 2 - Client-centric AJAX Containers (ComponentArt CallBack)

ComponentArt CallBack is similar to the UpdatePanel control in its high-level concept of acting as a generic AJAX container for ASP.NET content. Both controls allow rendering custom ASP.NET content (including server controls, user controls as well as literal content) through AJAX callbacks - without reloading the entire page.

However, ComponentArt CallBack is driven entirely by its client-side API. Developers specify exactly when a callback will be triggered and exactly which parameters will be sent to the server (CallBack doesn't post the page by default). This triggers a server-side event, where the developer has full control over what will be rendered back to the client.

Ease of use: ComponentArt CallBack is not as easy to use as the UpdatePanel control. It requires JavaScript code to initiate the callback request through the control's client-side API as well as implementing a server-side event handler to render content back to the browser. In most cases this amounts to just a few lines of code on the client and the same amount on the server.

Performance: Requests made through the CallBack control are extremely lightweight in terms of network traffic. However, each request has to go through the full page life cycle and the response typically generates HTML and sends it back to the browser.

Elegance: The CallBack control hooks into the page life cycle and exposes the native ASP.NET object for rendering (HtmlTextWriter) to the developer. While the developer needs to write custom code both on the server and the client to perform an AJAX request, the level of control that is gained makes it worthwhile in most cases.

Features: The client-centric AJAX approach exposes more capabilities to rich web applications with highly-responsive user interfaces because all AJAX request decision-making logic resides within the client-side event-driven code.

AJAX Explorer Example: Technique 2 - Client-centric AJAX Containers (ComponentArt CallBack)

Technique 3 - Manual JavaScript Coding Against Server-side Logic (Ajax.NET, ASP.NET 3.5 Script Services)

The previous two techniques revolve around the ASP.NET page model and are essentially delivered as ASP.NET server controls. In contrast with these techniques is a pure JavaScript approach originally introduced by Michael Schwarz with his Ajax.NET library. The core idea is to provide a way to mark methods of any server-side class with the "[AjaxMethod]" attribute and then be able to invoke that method from client-side code.

A similar technique is available with ASP.NET AJAX/3.5, which makes it incredibly easy to expose a web service and invoke it directly from client-side code. Significant performance improvements of this approach over the previous two are probably the main reason for its incredible popularity within the development community.

Ease of use: Invoking server-side logic on the client is easy with Ajax.NET / ASP.NET 3.5. However, this solution assumes quite a bit of manual JavaScript coding in order to generate and update user interface elements of the page. This is why it doesn't get high marks in the "ease of use" category.

Performance: There are two important performance breakthroughs of this approach: 1) Since methods of any class can be invoked through client-side code, the server-side request processing doesn't need to go through the ASP.NET page life cycle. The client-side request hits exactly the method it needs and it receives exactly the response it needs. There is no waste of server resources. 2) The response doesn't contain HTML markup. Rather, it contains only the data requested by the client. This can reduce the network traffic required to process the AJAX request by an order of magnitude. The received data is used on the client side to generate or update user interface elements.

Elegance: All functionality included with Ajax.NET or ASP.NET 3.5 Script Services is well architected. However, the overall solution is missing a piece of the AJAX puzzle and this is the reason why this approach loses points in the "elegance" category. The fact that developers are stuck with generating the user interface layer leaves the application with quite a bit of JavaScript code to maintain.

Features: The Ajax.NET library as well as ASP.NET 3.5 Script Services are loaded with client-side features. They contain the ability to easily invoke server-side logic as well as serialize .NET objects to their JSON representations. They don't, however, have the ability to manipulate high level UI elements (menus, treeviews, grids, etc.).

AJAX 2.0 - Client-side Controls Invoking Web Services

The new AJAX approach builds on best performance practises presented in the previous technique: efficiently executing server-side logic by invoking ASP.NET 3.5 web services and only sending data over the network. However, instead of requiring manual JavaScript coding to create and manipulate user interface elements, this functionality is now built into ComponentArt Web.UI client controls.

Ease of use: High-level client controls expose API methods to invoke web services. The structure and content of those controls is automatically populated with the results returned by the web service and the update is immediately visible on the screen. Even though some client-side coding is required to create and maintain user interface elements, it is reduced from many hundreds of lines to just a handful of high-level API calls. Not as easy as using the UpdatePanel control, but pretty close.

Performance: As already stated, this approach builds on best performance practises presented in the previous technique. However, the overall performance of an application built with this new approach actually exceeds the previous one. Additional performance improvements come from extensive client-side UI generation optimizations that we've built into the ComponentArt Web.UI suite.

Elegance: A high-level description of this technique is simple and powerful: "Objects on the client (client-side controls) communicate directly with objects on the server (web services)". The server-side logic of the application is delivered as a collection of web services - without any preconceived user interface decisions. This produces a real separation of tiers and greater code reuse options. Those web services could potentially be reused by multiple types of applications: mobile, smart client, Silverlight or other ASP.NET apps.

Features: Not only is AJAX request decision-making logic in the same domain as the rest of the app, but it is transparent to it. Updating a portion of the user interface through a fast AJAX request is no different than invoking any other client-side API method.

AJAX Explorer Example: Technique 4 - Client Controls Invoking Web Services

Summary

The new AJAX technique presented here is an evolution of the previously available techniques, rather than a radical departure from them. It builds on the strengths of AJAX best practises, while introducing something new: full fledged client-side controls capable of communicating directly with web services.

It's important to note that there is no clear winner for all application scenarios. All of these techniques deserve consideration, depending on the specific situation. For example, ASP.NET AJAX UpdatePanels might end up being chosen for apps that run on fast internal networks. Client-controls invoking web services are a great option for high-performance apps with rich and responsive user interfaces. Mixing various techniques within the same application is also a perfectly viable strategy.

Share this post: email it! | bookmark it! | digg it! | reddit!

Finally! ComponentArt Editor for ASP.NET AJAX

2007-09-13T20:48:00Z

Without any doubt, the upcoming Editor control is the most anticipated product ever developed by ComponentArt. Our customers have been telling us for years that they are unhappy with existing solutions on the market, and that we should make a ComponentArt-quality browser-based WYSIWYG editor. We set out to do that about a year ago, and I am happy to announce that we are approaching the first public beta release.

Building a solid browser-based text editor is hard. Our research has uncovered fundamental problems with various ASP.NET editing controls as well as major online document editing services like Google Docs. I will talk about our unique approach to the problem as well as share some interesting things we learnt along the way.

How Browser-based Editing Works

Modern browsers have built-in rich text editing features. Developers can take advantage of those features by simply adding an IFrame to a page and setting its document.designMode property to "on". This enables editing of the IFrame's content and provides many basic editing features "for free". However, there are vast inconsistencies among the browsers in the way that editing is handled. Consider the following minimal fragment of text:

First some bold text, then some italic text, then a change of color.
Finally, a new paragraph!

Let's review the markup generated by various browsers when this piece of rich text is entered.

Internet Explorer 6-7:

<P>First some <STRONG>bold text</STRONG>, then some <EM>italic text</EM>, then a change of <FONT COLOR="#ff0000">color</FONT>.</P> 

<P> Finally, a new paragraph! </P> 

Firefox 1-2:

First some <span style='font-weight: bold;'>bold text</span>, then some <span style='font-style: italic;'>italic text,</span> then a change of <span style='color: rgb(255, 0, 0);'>color</span>.

<br>Finally a new paragraph!<br>

Ouch! Not only is the output from IE and Firefox entirely different, but neither is XHTML-compliant. Let's try the other two leading browsers...

Safari 3 (beta):

First some <span class="Apple-style-span" style='font-weight: bold;'>bold text</span>, then some <span class='Apple-style-span' style='font-style: italic;'>italic text</span>, then a change of <span class='Apple-style-span' style='color: red;'>color</span>. 

<div>Finally a new paragraph!</div> 

Safari seems to do the best job so far - the generated markup is XHTML-compliant. However, why is the second paragraph contained in a DIV, but not the first? Also, what's with those Apple-style-span CSS classes? Let's look at Opera...

Opera 9:

First some <strong>bold text</strong>, then some <em>italic text</em>, then a change of <font color="red">color</font>.

<br>Finally, a new paragraph!<br> 

We have found that the currently available web editors (including ASP.NET controls as well as online document editing services) deal with these inconsistencies with varying degrees of success. However, we haven't found a product that always natively produces cross-browser-consistent, XHTML-compliant markup - without the need to run additional clean-up and conversion utilities.

Our Approach

Let's repeat this mantra one more time: "Create an editor control that natively produces cross-browser-consistent, XHTML-compliant markup - without the need to run additional clean-up and conversion utilities."

In order to accomplish that, we had to take over the control from the browser and write a custom XHTML serializer whose responsibility is to generate the document in response to user commands. That task is not trivial. It essentially amounts to writing a text editor in JavaScript from scratch, since we are no longer getting freebies from the browser. It was a lot of work, but we think it was worth it, as it brings additional important advantages beyond the purity of the generated content:

1. Completeness and power of the client-side API. Having full control over not only the markup, but the code that generates that markup allows us to expose a pretty powerful API to the developer. This API includes the same methods (for things like applying styles, getting/setting selections, controlling the structure of the document, etc.) as those used internally by the Editor control itself. In line with the rest of the Web.UI suite, Editor's API is based on the client-side component model introduced by ASP.NET AJAX. More info on the API will be coming soon from members of the Web.UI development team.

2. Ease of extensibility. Our solution consists of a lightweight, standalone Editor box (which can be used without any decoration) and the UI (toolbars, menus, tabs, dialogs, etc.), built entirely through our native Web.UI controls. The Editor box and the UI controls are "tied" together through their public APIs. This means that developers can create custom UIs to drive the Editor control using exactly the same techniques we did. Custom UIs are not only possible; they will be treated as "first class citizens" by our Editor control.

3. Customizable document styles. This is one of my favourites. Separated from Editor UI skinning, developers are also able to customize the styles that will be used for the document content. This includes things like paragraph and heading styles, bullet and number list styles, custom CSS classes and style strings that will be available in the style dropdown, as well as the collection of custom colours that will be added to the colour picker. In a nutshell, this feature enables developers to provide their end-users with a convenient collection of style elements that will fit into the target theme. A Glimpse of this feature can already be seen in the two demos below.

4. Ability to control all aspects of the document. For example, we can allow customizing the line breaking style: developers should be able to specify whether they prefer <p></p>, <div></div> or <br/> elements for breaking.

Finally, adding other new features is fairly easy, now that we have a solid core engine in place and full control of the document as well as the serialization logic. For example, Word paste clean-up can now be easily done, as stripping unwanted tags is simply an option in our serializer.

Live Demos

We are happy to provide a sneak preview of ComponentArt's Editor control in action:

- "Black Ice" Skin
- "Arctic White" Skin

Please be advised that this is a pre-beta quality product, so it is still rough on the edges, and its functionality will not be entirely stable. I should also say that these demos don't show off all Editor features - they contain only minimal toolbars and no dialogs.

Next Steps

We are currently alpha testing the 2007.2 release with a small group of select customers. If you run into any bugs while using the demos above, please send the exact steps for reproducing each problem directly to beta@componentart.com.

We are planning to ship a public beta release at the beginning of October, and the full 2007.2 release in mid November. As always, these dates are based on our best estimate and are subject to change.

This release has been a long time coming, but we hope you'll find that it was worth the wait!

Update: We have just shipped the public beta of Web.UI 2007.2, which can be accessed through our beta download page. You will need to be logged into your ComponentArt profile and signed up to the beta program to access the download package.

Among other things this build includes two new skins:

- "Office 2003" Skin
- "Web Ribbon" Skin

The last one is my personal favourite. I hope you'll like it too.

Share this post: email it! | bookmark it! | digg it! | reddit!

Visual Studio 2008 and ComponentArt Web.UI

2007-07-30T21:30:00Z

Now that Visual Studio 2008 Beta 2 has shipped, it's a good time to talk about the next version of ASP.NET and Visual Studio. More specifically, I am happy to share some good news on how Microsoft's next major platform release will affect ComponentArt's customers.

Scott Guthrie has a great post on ASP.NET AJAX in .NET 3.5 and Visual Studio 2008. I encourage you to read the entire post, but here are some key points you should take away from it:

"ASP.NET AJAX 1.0 shipped as a separate download that you could install on top of ASP.NET 2.0. Starting with the .NET Framework 3.5 release, all of these features are built-in with ASP.NET, which means you no longer have to download and install a separate ASP.NET AJAX setup when building or deploying applications. When you create a new ASP.NET application or web-site in VS 2008 that targets the .NET 3.5 framework, VS will automatically add the appropriate AJAX registrations in your web.config file and the core ASP.NET AJAX server controls will show up in your toolbox."

"The V3.5 of System.Web.Extensions.dll is a fully compatible super-set of the 1.0 implementation (which means you don't need to change any code in order to use it)."

As expected, ASP.NET AJAX has become a native part of ASP.NET and Visual Studio. We are extremely excited about this because it puts our customers in a unique position when it comes to exploiting the new features as well as gaining forward compatibility of applications based on ComponentArt Web.UI.

If you examine the ASP.NET component space today, you will notice that other leading vendors are currently in the early stages of developing component sets based on the client-side component model introduced with ASP.NET AJAX. These products are entirely new, and don't provide backwards compatibility with the current component offerings by those vendors.

In contrast, ComponentArt's customers will be able to enjoy seamless upgrading to Visual Studio 2008 and ASP.NET 3.5. All of your code based on the public APIs of ComponentArt Web.UI v2006.2 or later will be fully functional and in sync with the overall architecture and philosophy of Microsoft's new framework.

I think that great things are on the horizon with Visual Studio 2008. We anticipate that its adoption will be fast due to: multi-targeting features, new JavaScript IntelliSense and debugging, new web designer, as well as major improvements of the IDE performance.

Share this post: email it! | bookmark it! | digg it! | reddit!

Wake Up and Smell the Ribbon!

2007-05-03T16:14:00Z

A little while ago it hit us that our website was almost 3 years old. It had aged well, but the polish was starting to come off, and it grew to the point where its navigation was no longer adequate. It was time for a complete re-vamp.

While brainstorming the new website and its navigation structure, we quickly came to the subject of ribbon - a new user interface element introduced by Microsoft Office 2007. We felt that it worked really well in desktop applications, but at that point we had never seen a website driven by it. We decided to give this idea a try and allocated some resources to research it.

The problem with getting website navigation wrong is that it essentially makes your entire site useless. If people are not able to find what they are looking for, they simply won't stick around. Trying to do something new and unusual is asking for trouble and should be heavily scrutinized - it would have to be extremely intuitive and well executed in order to even begin to compete against solutions that people have previous experience with.

It was interesting to observe the stages we went through while trying to design the ComponentArt.com ribbon. We went from initial excitement to anxiety, to denial and despair. :) After a couple of weeks of building various mock-ups we came to the conclusion that it was simply not going to work. I was actually trailing behind our website developers by about one week: at the time I was excited they had already reached the denial phase. But by the time I came around and started having doubts about using the ribbon for website navigation, the guys came back to me and said: "No, wait! It's going to work! Check out these wireframes... "

We then spent many hours populating the ribbon with tabs, groups, items; giving special attention to the overall hierarchy as well as carefully crafting each individual title, label, description. We wanted our navigation to have a no-nonsense vibe to it, so we stayed away from cute or catchy terms and phrases.

We are quite happy with the final result. However, our website visitors are the ones who have the final say on whether this experiment was a success. What do you think, does it work?

Share this post: email it! | bookmark it! | digg it! | reddit!

AxoSoft OnTime 2007 - Powered by ComponentArt Web.UI

2007-02-22T01:26:00Z

The latest incantation AxoSoft's bug tracking and project management software - OnTime 2007 - was officially released yesterday.

AxoSoft is a leader in its space, offering a product that hits the sweet spot for customers looking for high-end tracking and team collaboration features found in packages such as Visual Studio Team Services, but without the complexity and implementation headaches that are typically associated with those systems.

We've been using OnTime 2006 for defect & feature tracking for about a year now, and I can highly recommend this product. We are also quite excited about moving to the latest version. One of the major new features in OnTime 2007 is the brand-new web client interface, powered by ComponentArt Web.UI for ASP.NET AJAX. If you are interested in seeing a fully featured web application built with ComponentArt controls, I recommend taking a look at the following 3-minute video:

- OnTime 2007 Web UI

Here is what AxoSoft guys had to say about their new web client:

"You haven't seen a web application rival the Windows user experience until you've seen OnTime 2007's web UI. This is the way a full-featured Web application is supposed to work."

I definitely share their enthusiasm. However, I don't think that this is the "final frontier" for OnTime's web client. Many new exciting and yet unseen features of ComponentArt Web.UI 2007.x have the potential to help take the richness of OnTime's web client even further.

For more info on OnTime 2007, be sure to check AxoSoft's Media Center.

Share this post: email it! | bookmark it! | digg it! | reddit!

ComponentArt Web.UI 2007.1 Details Announced

2007-02-01T15:49:00Z

Last night we updated the official Web.UI product roadmap.

We are about 1-2 weeks off target regarding the release dates that were announced back in November. However, the good news is that the 2007.1 release will include one additional control (Dialog for ASP.NET), adding a total of three new controls: ComboBox, ToolBar, and Dialog.

Adding a third control won't be the only surprise with the 2007.1 release. We are about to deliver a set of features that will take the built-in AJAX capabilities of ComponentArt Web.UI to the next (and yet unseen!) level of richness. We are very excited about this aspect of the 2007.1 release. I won't reveal any more details at this time, as these types of features are always best seen in a live demo.

Share this post: email it! | bookmark it! | digg it! | reddit!

Ditch That Beta Sign Eugene, We're Going to Production!

2007-01-23T17:56:00Z

The final version of ASP.NET AJAX was released today. We are very pleased to simultaneously announce the immediate availability of the full production version of ComponentArt Web.UI for ASP.NET AJAX. Taking those "beta" signs off our ASP.NET AJAX product line felt really good!

Developing for various technology preview and beta builds of "Atlas" / ASP.NET AJAX has been quite an experience. It all started at the PDC 2005 conference where Microsoft showed off the first prototypes of their new framework. I remember that Phil, Jovan, Milos, and myself were there, but we were not allowed to enter Nikhil's presentation on Atlas because we were exhibitors and had only one attendee pass. We sat on the floor just outside of the conference room, where we were sort of able to follow the presentation on one of the screens.

In the coming months we were thinking hard about our role as a component vendor, and the best way to add value to the platform. We were very impressed by the early CTP builds of Atlas, so we made a somewhat risky move to put most of our development resources on building a suite of UI controls for a framework that hadn't even reached the beta stage. Our assessment was that the release of Atlas would be a game-changing event of magnitude comparable to the release of ASP.NET itself.

That decision meant developing against a (rapidly) moving target. Microsoft promised that they would change designs and implementation details on the go, and they sure kept that promise. One of the most drastic shifts was the famous Beta 1 release. I blogged about our experience upgrading to Beta 1 here.

Developing against such early builds of a framework is not a simple task, not only because things tend to change a lot, but also because resources are so incredibly scarce. You can't buy a book and learn all about it. Forget about handy reference manuals. In the early days, our only resources were blogs of various dedicated Atlas team members, as well as the source code of the product itself.

Somewhere in the middle of 2006 ComponentArt became a part of the "ASP.NET AJAX Develop Program", designed to engage early adopters of this technology. We were able to attend various technical sessions in Redmond, as well as get preview builds of the framework well before they were available to general public. Yes - we finally got our revenge. Take that, Mr. PDC05 security officer!

The flip side of all the challenges was a highly rewarding sense of accomplishment as we saw things come together in the last quarter of 2006. We were determined to bring something new and significant to this changing market, and to try to ship at the same time as the framework itself is released. The result of our work is the industry's first commercial suite of UI controls built on top of the ASP.NET AJAX component model. The client-side capabilities and the level of client-side programmatic control offered by ComponentArt Web.UI for ASP.NET AJAX far exceed that of any UI library (for any framework) that we are aware of:

- Watch the Web.UI for ASP.NET AJAX Video

We are very excited about ComponentArt's unique position in the AJAX space. Instead of creating yet another proprietary AJAX framework that duplicates functionality found in ASP.NET AJAX, we have embraced Microsoft's new technology and created something that every AJAX framework needs: true client-side UI controls.

Starting today, our customers have a best-of-breed AJAX development framework in ASP.NET AJAX, and best-of-breed UI controls in ComponentArt Web.UI for ASP.NET AJAX. This is a truly exciting moment!

Share this post: email it! | bookmark it! | digg it! | reddit!

"Interoperability" vs. "True ASP.NET AJAX Controls"

2007-01-08T17:42:00Z

"Interoperability" is a term that has been used by several ASP.NET control vendors, including ComponentArt, to describe integration with ASP.NET AJAX. However, since we shipped the first public beta release of Web.UI for ASP.NET AJAX, we started using new verbiage to describe our product offering: "True ASP.NET AJAX Controls".

Is this just marketing spin? Is there some technical backup for these claims? Finally, as an ASP.NET AJAX developer, why should you care? I'll try to explain the meaning of these terms, and let you draw your own conclusions.

Interoperability

Providing interoperability with ASP.NET AJAX essentially means that the controls won't break when used with ASP.NET AJAX. Specifically, they will operate as expected when nested inside the new UpdatePanel control, and they won't **interfere** with the ASP.NET AJAX client-side JavaScript code.

However, controls that provide interoperability with ASP.NET AJAX are actually native ASP.NET 2.0 controls, tweaked so they can co-exist on the same page with ASP.NET AJAX. They don't have any ASP.NET AJAX dependencies and don't really take advantage of ASP.NET AJAX features.

Providing this level of support for ASP.NET AJAX is definitely the first step in targeting Microsoft's new web development framework. ComponentArt originally started providing interoperability with ASP.NET AJAX (or "Atlas") back in May of 2006 with Web.UI 2006.1 SP2.

True ASP.NET AJAX Controls

There is much more to ASP.NET AJAX than the UpdatePanel control. Actually, the most significant aspect of ASP.NET AJAX is that it introduces a real framework for JavaScript development, including a comprehensive model for creating client-side components and controls.

ComponentArt Web.UI for ASP.NET AJAX is the first commercial control suite built on top of this new component model. Having user interface controls that allow complete client-side programmatic manipulation opens up a world of possibilities. What's more important, these client-side capabilities are exposed in a standardized way, which is supported by Microsoft, and guaranteed to work with ASP.NET vNext, and Visual Studio Orcas.

Watch the Video

The difference between "interoperability" and "true ASP.NET AJAX controls" is explained quite well in the video we recently published. If you have 5 odd minutes to invest into perhaps getting a deeper understanding of the subject by seeing some of this functionality in action, then I highly recommend it:

- Video: ComponentArt Web.UI for ASP.NET AJAX

I think the following quote by a seasoned industry veteran sums it up quite well:

    "Writing the code you show in the video has been my dream for 7 years now.
        Since the time I saw a very early demo of what was then called ASP+. "

        Dino Esposito
        Author, Speaker, and Columnist for the MSDN Magazine

Thank you Dino. It has been our dream too. :)

Share this post: email it! | bookmark it! | digg it! | reddit!

ComponentArt Web.UI 2006.2 SP2 - Now Supporting the ASP.NET AJAX Release Candidate

2006-12-18T23:36:00Z

The ASP.NET team shipped the release candidate for ASP.NET AJAX 1.0 late last week. According to Scott Guthrie, "the next public release will be the final, fully supported, 1.0 product", and the final release is expected in about 4 weeks.

We have been working with the ASP.NET AJAX RC build for just over a week, and I am pleased to announce the immediate availability of ComponentArt Web.UI 2006.2 SP2 (build: 2006.2.1498) which targets the ASP.NET AJAX Release Candidate.

The latest build is available from the main Web.UI download page.

Share this post: email it! | bookmark it! | digg it! | reddit!