telerik officially licenses Office 2007 UI

A little more than a week has passed since Microsoft announced that it would be making the Office 2007 UI available to application developers via a perpetual, royalty free, no charge license and today telerik announced that they would be an early participant in the license program. The program makes the new Office UI freely available to any developer interested in building applications or components that implement the (love it or hate it) Office 2007 UI. The only catch is that you cannot use the license to build applications that compete with Microsoft Office (seems fair enough).

What makes the telerik announcement significant, though, is that all participants in the license program must agree to strictly adhere to the 120+ page Office 2007 UI Guidelines. The guidelines in this document come in three flavors- required ("MUST"), optional ("SHOULD"), and Best Practice- and they aim to ensure all implementations of the Office UI are done consistently and correctly. The guidelines are illustrated, detailed and very thorough, so little is left to the imagination regarding the correct implementation of Office UI components (like Ribbon, Quick Access Toolbar, etc.).

For example, in a preview of the full Guidelines document (available here [PDF]) we learn that implementations of the Ribbon MUST do the following:

• Resizing the width of the window must re-size the Ribbon and change the layout of the controls
• Layout changes must be real time and must not wait for the left mouse button to released
• Ribbon Groups must have at least two variants: "Large" and "Collapsed"
• Clicking a collapsed Group must display the largest variant bellow the Ribbon
• The width of each Group must be determined by the controls and must not be determined by the Group label
• Scroll state must be remembered per Tab and must be preserved when navigating between tabs

And that's just a few of the many required guidelines for Ribbon alone! Clearly, any component that implements the UI Guidelines to a Best Practice level will be a very full featured and powerful UI component. Telerik's announcement is exciting because we know that future versions of their Office 2007 controls (for the Web and Windows) will fully implement the features outlined in these Guidelines. Notice that I said Web and Windows. The official Guidelines FAQ makes it clear that web components must fully implement all required UI features, just like their Windows brethren.

It looks like 2007 is going to be a fun year for UI development!

How to choose: Web or Windows?

I recently ran across a question on the telerik forums that asked this: how do you know ahead of time when you should build an application for the web or instead build it for the desktop? That got me to start thinking about the issue and I realized that there are very few reasons in a Utopian world why you shouldn't build a new *business* application for the web. Applications designed and built for the web offer a number of benefits over their stodgy desktop counterparts:

• Easy deployment and version management
• Easy to upgrade and patch
• Inherent cross platform compatibility (thanks to FireFox)
• No software compatibility issues to contend with (because there is no installation to contend with)
• Familiar application interface for end users (users are used to using their Internet browser)

During my time developing at a Fortune 200 I/T shop, I found that the simple task of bringing in a new desktop application can take hundreds of hours. You've got to get your Software Packaging team to package and verify the software, then you've got to get your Security team to validate the package, then you've got to get your Desktop Change Control Board to approve the new software for the desktop environment, then you've got to Software Distribution to schedule the deployment of the software to correct users, and finally you've got to help your end users find the new application on their computer. And all that assumes your Legal Department didn't have any issues with the installation license for the software; if they did, tack an extra 3 months onto the process for contract and license negotiations.

The web is not immune from all of these problems, but my experience has been that it is much easier to introduce a new web application to an Enterprise environment. Once a contract is in place (or if it's in house development, once the application is live), just email a new link to your users and everyone is on their way (with a little training, of course).

I emphasized early that this philosophy applies primarily to business applications, such as data manipulation applications, office-like applications, and the like. The web is still a long way from being a suitable replacement for all desktop applications (can you imagine doing your Visual Studio development in a web app?), so at the end of the day the appropriateness of the web depends entirely on your situation and application. Three years ago I would have called you crazy if you told me that Office could be replaced by web apps; today I'd tell to you it's only a matter of time (for average users- power users are a different bunch that will hit the limits of web apps quickly).

With that understanding, there a few reasons in the "real world" (sorry, we don't live in Utopia) that business applications shouldn't be built for the web:

• Lack of technical know-how on your development teams (If you've got experienced Windows developers, their talent will be wasted trying to build for the web.)
• Internal chargeback rates for web applications exceed benefits (a.k.a. Cost) (In large Enterprises, it is not uncommon for the internal chargeback rate for standing up and running a new web application to far exceed the costs of obtaining and installing a desktop app, especially if you have a small user base.)
• Paranoid management (While security on the web can be managed just as easily as security on desktop- via AD integration, VPN, etc.- some management environments do not like the idea of having their business data accessible via a web browser.)
• Technical capacity requirements of application (If you're application will be doing heavy data analysis, the desktop may provide a better experience. Case in point: Google Spreadsheets can handle 10,000 rows and Excel can handle 65,000+. Users working with lots of data need Excel's capacity.)

So where is the tie in to telerik? After all, this is the "Telerik Watch" blog. Quite simply, telerik controls take the User Interface question out of the equation when trying to decided between Web and Windows. Any user interface that you could build for a WinForms application using Visual Studio can just as easily be built for the web using r.a.d.controls for ASP.NET. Whatever other reasons you may find that the web is not appropriate for your application, limits due to your ability to create a desktop-like UI shouldn't be among them. With r.a.d.ajax it is very easy to create responsive, desktop-like experiences on the Web and the other 17 controls in the suite give you most of the tools you'll need to finish the job.

Web or Windows? The answer depends on your situation, but the application UI will be easy to build and will look great either way if you use r.a.d.controls.

telerik reporting template in VB

Thanks to Jason Burch, VB developers in the telerik community can now build telerik reporting reports using a VB project instead of the provided C# examples. He took the time to convert the C# report template item into its VB variant and posted the code to this forum thread on telerik.com. This code applies to the November CTP of telerik reporting that I previewed last week and should be used by developers that would rather test the CTP with a VB project (instead of a C# project). I should note, though, that the visual designer used to build the reporting reports makes it unnecessary to deal with the auto generated code unless you're tweaking or just interested in what's going on.

More Q4 release details

With the Thanksgiving holiday behind us (in the US), only a few weeks remain until the Q4 2006 release for r.a.d.controls. Here are some extra details regarding features we can expect to see in the upcoming Q4 release of r.a.d.controls for ASP.NET gleaned from the telerik forums:

• New client-side row operations for r.a.d.grid. This is a pretty big feature enhancement for grid that should come as a welcome addition for many developers. The new client-side features will allow developers to implement completely client-side row deletes (and possibly client-side inserts and updates) that will be persisted back to the server on the next PostBack/Callback. Vlad Enchev from the grid team posted a great blog entry on the upcoming feature here along with a link to a live demo of the delete feature.
• Enhanced editor RealFontSize toolbar. Anyone looking for more out-of-the-box power to choose your font units in editor should get a big productivity boost with the enhanced RealFontSize toolbar in Q4. The enhanced toolbar will supposedly deliver the ability to switch between relative, pixel, point and other font units with simple configuration file settings.

• r.a.d.upload to be integrated with r.a.d.editor Developers using editor to upload files will no longer have to create a custom editor dialog to take full control of the upload process. The telerik team will be integrating r.a.d.upload into editor giving developer's complete access to the features exposed by the upload product, including the ProgressArea functionality.

• r.a.d.spell will use the standard skinning mechanism One of the changes we can expect to see in spell 3.0 (besides the new AJAX spell check mode) is the adoption of the "standard" telerik skinning mechanism. That means it should be very easy to change spell's skins in the future via the normal Skin property.

• r.a.d.grid click on row to PostBack If you've ever built an application with grid where you want users to click anywhere on the row to cause a PostBack, you'll know that that seemingly simple action requires a fair dose of custom Javascript and manual interaction with "__doPostBack". When Q4 ships, this task should finally be as easy as setting a single property on your grid instance.

• Video tutorials for r.a.d.controls If a picture is worth a thousand words, then telerik will be adding hundreds of thousands worth of words to the r.a.d.control help in Q4 with the formal introduction of video tutorials. These videos will allow developers to watch r.a.d.controls development in action and they will hopefully help answer a number of common questions. Are there any video tutorials you want to see?

• Improved r.a.d.menu configuration wizard (maybe) While the confirmation that menu's configuration wizard would be improved in Q4 was a little weak, there is some hope that the Q4 wizard will finally allow developers to re-order menu items. It seems like an obvious feature, especially since the grid wizard lets you reorder columns, so I hope that the team finds the time to get it into the release.

• Word wrap for nodes in r.a.d.treeview (maybe) This is another feature with weak commitment to the Q4 release, but if does make it it will allow long text on treeview nodes to wrap. According to members of the telerik community, this feature will be unique among many treeview controls and will further distance telerik's treeview from the competition.

• Many new properties in r.a.d.window There are a number of posts in the forums with references to features telerik wants to include in window's Q4 release. Among them are new client-side events that fire when a window is moved or re-sized, new properties that give developers access to a window's header and footer, a new MinimizeMode, a handful of new client-side API properties, a constrainable drag area for windows (unlikely that this feature will make it), and full use of Embedded Web Resources (for .NET 2). window is not a control slated for a "major" update in Q4, though, so it's possible many of these features could be cut if the dev teams run out of time.

• Improved localization capabilities for all r.a.d.controls Based on community feedback, telerik will be improving the way its localizable controls (editor, spell, upload, window, and calendar) handle localization. There is not much detail on pending improvements, but it is possible telerik will implement a feature that will enable the control to auto detect the current culture settings of an user and apply the correct localization settings.

The last release of 2006 is scheduled for mid-December, so we should start to see some betas in the next couple of weeks. When we do, I'll be sure to check for these features and let you know what you can expect to see in the final Q4 release. Which enhancements are you most looking forward to in the next release? Let me know in the comments and I'll pay extra attention.

//Todd Anglin //November 27, 2006

reporting November CTP review

Only six short months ago, telerik announced that it would be delivering a full featured, stand-alone .NET reporting product. We are still months away from a final product, but earlier this month telerik unveiled an early CTP (Community Technology Preview) of reporting to give developers a taste of what's to come. I posted an extensive screenshot gallery of the November CTP early last week, but today I'm going to comment on my overall experience installing, configuring, and using telerik reporting.

installation

Even though it is only an "alpha" release, the November CTP of telerik reporting does come with an easy to use Windows installer (Fig 1). Anyone who has used the Windows installer for other telerik products will find the experience familiar. The installer comes with two basic parts: the main binaries for reporting and a number of pre-built examples. One thing not included in the November CTP is documentation (which telerik makes clear on the beta download page), so this CTP is definitely not for the weak of heart.

The installer runs fairly quickly; the total install only took a few minutes on my 3.2 GHz, 2 GB RAM desktop machine. The longest stretch of the install is the time that it takes to update the Visual Studio Toolbox, but a moving progress graphic reassures you that the install hasn't hung (Fig 2).

My only problem with the install was related to the included SQL Server demo database. The installer was designed to work with SQL Server 2005 Express (which I don't have installed) and it did not recognize my running default instance of SQL Server 2005 Developer Edition. Using some very complete help available on the reporting forums I was able to manually install the database and grant the necessary permissions for the demos. Disaster averted.

configuration

Most people who install the November CTP will not have any configuration tasks to complete before they can start playing with the demos. Since the installer didn't like Sql Server 2005, though, I had to add a few extra steps to get everything setup correctly. After I followed the instructions for manually installing and configuring the AdventureWorksT sample database, I had to update the Web.Config (for ASP.NET demos) and App.Config (for WinForms demos) files with the correct connection string to my local database. With those quick updates done, I was ready to hit F5 and play with the demos.

demos

The November CTP includes seven demo reports for both WebForm and WinForm examples. The same report definitions are actually used for both sets of examples, the only difference between the two is the viewer.

Telerik reporting ships with two different viewers, one for the web and one for Windows, both of which look and behave very similarly. The Windows viewer includes a few extra functions (like Zoom and Page Setup), but it's possible the features provided in both viewers will change dramatically between now and the release. The viewers also expose some basic functions like paging, printing, and exporting (to TIFF or MSHTML only, more formats to come in the final release, including PDF, Word, HTML, and more).

The report definitions are all stored in a Visual Studio C# project and complied into a single assembly. After I installed the CTP, I first tried to create a new Web Site in VS 2005 to test reporting. That's when I discovered that you cannot add report definitions directly to a Web Project. Instead, you need to create a new C# project and build your report definitions there and then import the complied assembly to your Web (or Windows) application. I'm not sure if that is indicative of how the final product will ship, but at first pass it seems like maintaining report definitions could become a bit of a chore if it requires you to maintain a separate project just for reports. On the other hand, it makes it easier to add reports to your "report assembly" and deploy them to your site if you run complied ASP.NET sites, so there could be some advantages to this configuration. But I digress; back to the demos.

The ASP.NET demos (and WinForms demos, for that matter) start on a simple page with a DataList that contains links to the available reports. When you click on a report name, a new page is opened with the report viewer filling 100% of the page (Fig 3). The demos show off a number of features available in reporting, including multi-column support (though that support does not seem to work on the web yet), bound text elements, bound image elements, grouping, and multi-section support. All of the reports look the same on the web or in Windows, with the exception of the multi-column reports that render as single column reports on the web. The demos definitely show the ability that reporting has to create a variety of reports, but the functionality is still very basic. Check out my screenshot gallery to see all of the demo reports.

design time experience

Report definitions end in a .cs (C#) extension, but they they open in a new report Design View. The report Design View gives you a graphical tool for laying out your report and it is complemented by two additional views: the PreviewView and the HTMLPreviewView for WinForms and WebForms respectively. These three views make it easy to modify your report and quickly see how it will render on the web or in Windows, which is a major improvement over preview capabilities other reporting products expose. The design and preview views also integrate directly into the Visual Studio IDE, which is another benefit over products like Crystal Reports.

Laying out a report is a familiar affair if you have ever used Microsoft Access' Report Designer or Crystal Reports Report Designer (or any other number of visual report designers I'm sure). In the November CTP, you only have PictureBox and TextBox items to work with on the report but many additional elements (including shapes, sub-reports, etc.) are supposed to be added in the final product. You can right-click on a report to reveal options for adding additional sections (like PageHeader or ReportHeader) or groups to your layout. The GroupReport is the best demo to look at to see how the grouping and sections work (Fig 5).

Reports are connected to your data source through standard ASP.NET DataAdapter and DataConnection objects (of the SQL Server variety in the demos). Using the familiar data objects makes it easy to understand the data connection and configuration, but it also makes the data connection feel less integrated with the report as you might expect a reporting product to deliver. I expect the final release will probably address this area too, though I'd consider this a minor issue at worst.

Adding a new report to the assembly is easy. Just right click on the solution to add a new item and choose the new "telerik Report" item from the "Add New Item" dialog. Once the report has been added, begin adding TextBox elements and binding them to your data source until you have the report you're after. You can use the Preview views to see how things will look with live data from your database and then jump back to the design view to make any desired changes. When you're done, compile your report project and copy the assembly to your website's bin folder.

licensing

The final licensing details for telerik reporting have yet to be announced, but we do know that it will be licensed separately from the r.a.d.controls. That shouldn't come as much surprise since this product is a dramatic departure from the other UI controls currently included in the developer license, but it does put reporting on a pedestal to forcing it compete on its own merits. No pricing has been announced, but I expect those details will be available early next year.

conclusions

Even in its current state, telerik reporting is shaping up to be a very compelling product. It will make it very easy to build professional looking reports and deploy them to the web or Windows with little effort. The November CTP is definitely rough around the edges, but the telerik reporting team has at least four full months to enhance and refine before the official release (which is an eternity in telerik release terms!). There is no question that telerik will be up against some very capable and veteran competitors in the reporting space, but telerik's ability to deliver outstanding UI at very affordable prices should give the big guys a run for their money. This will definitely be a must have product for any telerik developer.

//Todd Anglin //November 20, 2006

another Q3 update: SP3 released today

Only six short weeks before the Q4 release, telerik has delivered another service pack for the Q3 2006 release. It has been almost a year since telerik last delivered three service packs for a quarterly release (Q4 2005 matched the feat), so this has been a busy quarter for telerik and the developers implementing each service pack. The latest release delivers mostly bug fixes and enhanced support for a number of "special case" uses of the r.a.d.controls. There are, however, a few specific enhancements worth mentioning. If you were a fan of the PersistStateInCookie property of pre-version 4 r.a.d.panelbar, you'll be happy to know that the property is back. You can once again set this property to True and rely on cookies to keep track of the panelbar's client state. r.a.d.grid has added a number of new properties to the export command. You can now specify the filename and set the exported data to open in a new window directly from the ExportToExcel method (I'm not sure if the same has been added to the ExportToExcel2007 method). There are a myriad of other items in this service pack from new documentation for ajax, to "major performance improvements" in splitter, to continued support for the latest ASP.NET AJAX Beta 2. Check out the full release notes here. So before you leave for the holidays (if you're State side), be sure to visit telerik.com and download the latest and greatest r.a.d.controls.

Tip: conditional comments and r.a.d.ajax

Do you use any conditional comments in the header of your files? If you do and you use r.a.d.ajax, you may run into very difficult to debug (but easy to fix) problems. Let's look at how I got into this situation and how I learned this "tip" the hard way: Many moons ago, in preparation for IE7, I moved all of my old IE hacks out of my primary stylesheets and into a separate "IE hacks" stylesheet (this was the advice of many CSS experts at the time on how to prepare for IE7). To hide the IE6 hacks from IE7, the experts recommended the use of conditional comments (a not so commonly used syntax supported by IE that looks like this:<!--[if lte IE 6]>(html if true)<![end if]-->) which has worked great up to now. I recently discovered that r.a.d.ajax cannot deal with the conditional comment syntax after callbacks. So if you use conditional comments to attach stylesheets in the header of your page, any ajax callback (which looks for links in the header and re-attaches them after callbacks) will expose your "hidden" hack stylesheet to browsers that shouldn't see it. Here are a few ways telerik suggested you can deal with the problem:

• Set the EnablePageHeadUpdate property of the ajax control to false. This way it will not update the head tag, but if you load dynamically controls with ajax, their stylesheets will not be applied. This is fixable as well, you just need to manually add the stylesheet declarations for the controls on the page.
• Move the conditional comments out of the head tag. This way they will not be updated by the AjaxManager and still applied depending on the browser version. It is even valid xhtml1.1 as the html comments are not verified by the html validator.

Hopefully this little tip will save you some time and help you avoid the possible pitfalls of ajax and conditional comment interaction.

input 2.0 delayed

Those of you waiting on version two of r.a.d.input (with new data type specific textboxes) will have to wait until Q1 2007 as we learned today that the major update will not be ready for the Q4 2006 release. The next version of input is supposed to include a number of data type specific textboxes for validating input, including textboxes for currency, percentages, and a "vanilla" textbox for accepting unmasked input. Telerik has said several times in the forums that input 2.0 would be in Q4, but it appears the work being done on WinForms controls, reporting, and major upgrades to chart, editor and spell have pushed input 2.0 back a few months. So update your project plans and don't count on seeing version two until March.

Exporting to Office 2007

Office 2007 has gone gold and so has telerik's support for exporting to the Microsoft update. Well, maybe telerik's support is closer to silver, but the support is there nonetheless. Anyone who has tried exporting from grid to Office 2007 has probably discovered that the exported files cannot be read by latest Office version. The problem lies in the encoding used by the grid export method, which currently uses UTF7. This encoding works for current versions of Office, but UTF8 is required for exporting to Office 2007 (an encoding which does not work with older versions of office, of course). To address the problem, telerik introduced two new methods in grid 4.0: ExportToExcel2007 and ExportToWord2007. These methods work just like their ExportToExcel and ExportToWord counterparts except that UTF8 encoding is employed for Office '07 compatibility. Curiously, they do not appear in the Q3 documentation, but I expect that will be fixed soon. I'm also concerned that the method names may cause problems for developers down the road (what happens when Office 2009 comes out?), but that's not a big deal today. If you are a developer who must support Office 2007 and older versions of office (as I expect many are), you now must deal with the task of figuring out which export method to call depending on your user's installed version of Office (thus my belief that this support is more silver than gold). For now, the best approach may be to simply ask users exporting from your site if they are using Office 2007 and then use the appropriate grid export function. You can avoid annoying your users by saving their first response in a cookie and referring to that value for future export calls. While the support isn't automatic, telerik has provided a method that enables continuing compatibility with the (officially) days old Office version. Anybody supporting (or soon to be supporting) Office 2007 users should take note and use these new methods whenever exporting from grid.

reporting screenshot gallery

I have put together a full gallery of screenshots showing off all that there is to see in the November CTP of telerik Reporting. This gallery includes shots of all WinForms and WebForms sample reports included in the CTP, the install process, and the Visual Studio design time experience. My first impression is that this is still very much a CTP (not a beta), but Telerik has plenty of time between now and March to make this product shine. I will write a full review of the November CTP later this week, but for now enjoy the pics:

TelerikReportingNovemberCTP

telerik reporting CTP available

In what is becoming typical telerik announcement fanfare (or lack thereof), the first publicly available CTP of telerik reporting was released late last week. Telerik reporting marks telerik's entrance into a brand new product area, one filled with strong competitors like Business Object's Crystal Reports and ComponentOne's Reports for .NET. To the table telerik brings its reputation for making powerful and easy to use .NET components with outstanding support and a loyal community of developers likely to quickly embrace the new tool.

Since its announcement in June, reporting has been the one product that I am most looking forward to implementing in my projects. The CTP is definitely not ready for "prime time reporting" with its limited support of report element types and incomplete API, but it affirms that this product is coming along nicely and will likely be ready for production around the Q1 2007 r.a.d.controls release. When it's ready, telerik reporting should enable you to define reports with a visual designer that integrates into Visual Studio and display reports with included WebForms and WinForms report viewers. A number of export formats are planned too, including HTML, Word, Excel, PDF, and TIFF.

If you are eager to get your hands on the new product, you can download the first CTP and read all of the release notes here. The next CTP will be available in December and it will be followed by Beta 1 in January. I will post some screenshots of the November CTP later this week for those who don't want to download and play. If you are among the daring downloaders, what do you think of the tool so far?

No scheduling tool...yet

Many people have been eagerly waiting for telerik to enhance the r.a.d.calendar control with advanced scheduling features. According to a post from telerik, you'll have to continue waiting until 2007. With major enhancements for many other controls slated for the Q4 release, telerik will not be adding a full range of scheduling tools to calendar in Q4. There is some good news, though. We learned today that telerik will be adding some time-picking (in addition to date-picking) functionality to what is likely to be calendar 2.0 in December. This is a good first step towards a more full featured scheduling component and yet another feature to look forward to in the Q4 release.

AJAX Spell Checker Preview

As mentioned in my preview of the Q4 release, telerik will be introducing a new version of spell this December. Version 3 of spell, which is tightly integrated with r.a.d.editor, will embrace AJAX and bring a "Word-like" spell check solution to the web.

Users of the popular web-based email solutions provided by Yahoo! and Google will find this AJAX spell check familiar. When using editor, users will be able to click on a button to begin the AJAX spell check. Instead of displaying a spell check pop up, misspelled words will be highlighted and users will be able to click on them to reveal a list of suggested corrections and editing options. When users are done spell checking their document, they will push another button that will commit the changes and hide all of the spell check formatting.

This screenshot reveals some of the functionality that we can expect to see in December. It looks ugly now, but telerik's track record for making "good looking" controls is sure to bless this control with a face lift before the official release.

Even though this is not the first ASP.NET component to offer this type of AJAX spell check, it is a welcome improvement to the r.a.d.controls suite. When the other .NET spell check components are compared, telerik's generous licensing scheme makes spell 3.0 the best value by a long shot. This is definitely one update in Q4 that I can't wait to start using!

Q3 2006 SP2 released

Without much fanfare telerik released Q3 2006 SP2 on Wednesday (November 1st). You can download the service pack now from your Client.net account at the telerik website.

The most significant enhancement in SP2 is full support in the entire suite for the recently released ASP.NET AJAX Beta 1. The first beta of ASP.NET AJAX (formerly "Atlas") introduced a number of changes to the core AJAX libraries that broke r.a.d.control compatibility. Telerik has quickly responded to those changes, though, and delivered on their promise of "Atlas" support in SP2. Anybody who has been reluctant to install ASP.NET AJAX Beta 1 due to the compatibility problems with r.a.d.controls (like myself) can now commence with downloading the latest toys from Redmond.

This service pack also provides additional updates for ajax, calendar, combobox, editor, grid, treeview, and upload. Among the updates are optimizations for ajax and grid and a new ability in combobox to set its width as a percentage (previously unavailable). upload now includes default (or English) localization files and the default skin as part of the assembly (via WebResources), so you shouldn't need the RadControls folder for this control in the future if you use .NET 2. For a full list of changes in SP2, check out this link.

All in all, this is a pretty significant service pack that all r.a.d.control developers should download and test in their applications (especially if you're using/considering ASP.NET AJAX). And don't wait too long, Q4 2006 is just 7 short weeks away!