Hello Kirti : AJAX

Toolkit showcase

kirtid — Fri, 07 Sep 2007 09:44:00 GMT

We are compiling a list of websites to showcase on the Toolkit page that is a part of the ASP.NET website . Details on how the page will end up looking like have not been fleshed out yet. Just like this ASP.NET AJAX showcase displays interesting websites...(read more)

Toolkit support for .NET Framework 3.5 and Visual Studio 2008 Beta2

kirtid — Fri, 27 Jul 2007 05:39:00 GMT

The next wave of Visual Studio products coming out from the Developer Division in Microsoft promises a richer development experience than its predecessors. Features that deserve special mention since they are particularly relevant to the Toolkit are Javascript...(read more)

Cascading AutoComplete

kirtid — Thu, 17 May 2007 10:52:00 GMT

We have received a lot of feedback from users about not being able to pass additional information to the AutoComplete webservice which limits their usage of the extender. We decided to absorb that input and add support to all extenders that issue XmlHttpRequests...(read more)

Insuring, the Toolkit way

kirtid — Wed, 28 Mar 2007 09:25:00 GMT

My current task at hand is finding a good insurance policy that is kind to my pocket and covers my car well. I have been putting it off for months now, one, because it is so boring and two, because I do not understand "insurance jargon" and have very little interest in making an effort to do the same. I will not complain a lot about insurance sites but they definitely do not fall into the "cool" category. If only shopping for insurance was as exciting as shopping for cars! But now there is hope in the form of the All State site. Notice the ModalPopups, CascadindDropDowns, Accordions, PopupControls, HoverMenus, CollapsiblePanels, Sliders, TextBoxWaterMarks? Well, if you did not before reading this, you sure will now. Yes, it is the Toolkit all the way, a custom showcase made just for us. A very mundane real world scenario packaged attractively! It makes me want to shop for insurance on their site just to experience the Toolkit in action, if not for the end product. I expect my insurance policy hunt to not end in the very near future but in the meantime I will keep myself entertained on the All State site.

WYSIBYG...What you see is "before" you get, uhhh... it

kirtid — Sun, 18 Mar 2007 09:19:00 GMT

One of the most requested controls in the Toolkit is a WYSIWYG editor. There are a bunch of rich text html editors floating around that serve this purpose, so wouldn't having this in the Toolkit be just a "me-too"? I have been thinking if there would be more ways in which our version could stand out. The Office 2007 UI enhanced the WYSIWYG experience greatly by allowing you live previews that demonstrate how your content will look if a particular feature button like "bold" or "font names" is selected. The WYSIBYG acronym comes from a Microsoftie who presented that MS Word feature at Microsoft's Company Meeting. I unfortunately do not remember his name to give him credit for the same. If you do then let me know and I will update the post.

I am writing this post in a Community Server WYSIWYG editor and I wondered if I could apply some learnings from the pains I experienced and introduce some more useful features in the Toolkit editor. If you take a look at my blog post on Slide Shows, it has some links in "blue" instead of the trademark pink enforced by my blog template. The mishap occurred because I was reluctant to write my blog in this editor and chose to use the outlook message editor to compose it before I would cut and paste it. It so turned out that the format was preserved (which is understandable but not what I wanted then). Since some of my content was written using the blog editor it had the right formatting but the editor did not have a "Format Painter" option (at least I could not find one that did something similar) to correct the styles copied over from outlook and hence the inconsistent look and feel. I was too lazy to manually fix that up and I can claim that I got lucky because I could use that to justify why we need format painting in the Toolkit editor.

For now I think a decent format painting story and live preview support sounds like a good start, hopefully to deter people from calling it "yet another wysiwyg editor"... What say?

ContextMenu Extender, anyone?

kirtid — Wed, 07 Mar 2007 00:27:00 GMT

The Ajax Control Toolkit has a bunch of controls wish-listed and we would like to deliver as many as possible to our customers. One of our new contributors, Ziemowit Skowronski, has volunteered to author a new control which will behave like a context menu. It will prevent the default browser menu from showing up when you right click and show you a custom menu and provide you with richer, more relevant functionality. We would have to essentially override the contextmenu event and show a popup. The new context menu could easily use the existing FloatingBehavior support in the Toolkit to show a custom menu control.

Name of the control: ContextMenuExtender

TargetControl: Control

Properties: I am almost stealing this from the HoverMenu control in the Toolkit. The ContextMenu is the HoverMenu handling the contextmenu event instead of the mouseover/mouseout events. We could reuse most of the functionality in that control.

· TargetControlID: ID of the element, right clicking on which will cause the context menu to show

· PopupControlID: ID of the menu popup that will serve as the context menu

· Position: Position of the menu popup with respect to the target control. Any position supported by PopupBehavior?

· ContextMenuCssClass: Name of the css class that will be applied to the menu popup element.

Accessibility: When the target control is focusable the ContextMenu should be able to be activated using the keyboard alone so the extender needs to support keyboard events on the target control as well. The popup panel should have the features expected of an accessible control like semantic html, alternate text, high contrast support, keyboard support and more. This would be a to-do for the website developer though and not the control author since the Extender consumes whatever Menu Control is passed to it.

International: Would there be any left-to-right/right-to-left concerns we should have if we are exposing the Position property? Users can make their page globally aware using that, correct?

Usability: This is something that end users who deploy this control should take into consideration. Right-clicking in a browser to expose non-browser menus is not something that users will discover intuitively. It should be considered that the control needs to communicate in some way that it has a contextmenu that is not the default browser one. It needs to be somehow advertised that there is more possible with the target control beyond just clicking and/or hovering over it. Talking about usability, what would be the Safari story? Would any Macintosh users like to chime in?

Any more feature requests, ideas?

------------

*update*

Some more new ideas...

Chad Smith, a Toolkit enthusiast is working with Ziemowit on the ContextMenu. He suggested the idea of sharing code among PopupControl and ContextMenu since PopupControl is fired by a left mouse button click and ContextMenu will be fired by a right mouse button click. So the only distinction between the two being the value of the property "InvokedBy"

I really liked that idea. Taking it a step further what if we could observe more code sharing?

Instead of restricting it to right-button and left-button clicks we could set it to be the event that fires “show” on the popup and make it more generic. We could then add the “MouseHover” event to that set and take care of HoverMenu support as well.
If we could have a similar “DismissedBy” property which would be set to “MouseUnHover” in case of the HoverMenu, “BodyClick” for the PopupControl and the ContextMenu that would make the model more consistent.
All the core functionality could be moved into a “Menu” class and the classifications on how the menu gets shown would be the three child classes with relevant values for InvokedBy and DismissedBy (those would need the element whose event needs to be fired as well, to create the handlers; for example in case of body click). These properties do not need to be publicly exposed but will remain the distinguishing features and could stay protected.

Sounds more object oriented?

Slide Shows and more...

kirtid — Tue, 06 Mar 2007 13:56:00 GMT

While I was authoring the slideshow extender in the AJAX Control Toolkit I happened to find a very interesting company that actually does *just* slide shows for a living, called Slide, of course with more bells and whistles. There is a Redmond based company called SmileBox which does something very similar as well.

They both overlap in the core aspects, i.e. being able to create a custom slide show to transition smoothly through a set of pictures. But what I found particularly interesting was Slide allows you to pull your pictures from your MySpace, Flickr, Facebook accounts and many more data-sources. There is a caveat though. You need to login and provide your respective account credentials, which they claim they will not use. That being said, it is a cool picture aggregator (It reminded me of Meebo which is the IM webclient). It leverages the fact that people are inherently lazy and do not want to upload pictures to ten different sites and makes for easier and faster adoption. You can then just copy the html and paste it into your page/blog. The cosmetic theming aspect adds particular flair to the slide shows. You no longer need to be a Flash expert to create cool, custom, personalized greeting components and share them with your friends and family easily.

I had thought about this over two months ago when we were deciding on what our MIX07 plans were going to be. A project like this to evangelize the WPF/E technology, Microsoft’s version of Flash++, would be awesome. But it did not fit into our team’s charter…sob sob. Anyways, taking it to the next level, imagine though that the components are user driven. I, as a developer, could create programmable WPF/E components that could be used by end users in collages (greetings, scrap-books, diagrams, slideshows etc.). The API’s supported by the component would be exposed in UI via reflection and users would be able to add that to their site and customize them. This would be much easier to achieve in managed code which WPF/E will support.

In short a “Create my Web Art or Wiki art” style web application that

Allows for a controls to have a generic platform where they can be uploaded.
Allows for the control API’s to be exposed for manipulation in a generic fashion
Allows for overlaying of controls on a canvas to form more complex components (generating xaml on the fly)
Allows for storyboard settings and mutual interaction between components on the canvas

This would then be a forum for both budding wpf/e developers wanting to showcase their work and allow end users to generate fun interactive yet complex xaml components from a medley of pre-existing work. Could somebody be doing that for a living? I am sure they are already out there…

Till then I will continue improving the Toolkit Slideshow. Suggestions/Comments are most welcome.