I’m off to go camping for the weekend with Heather. I will have my cell phone with me but I don’t know if there’s any EVDO coverage so I may or may not be checking support email while I’m gone. I am gonna be working on TEO there cause I’m not really into camping much.

Made a ton of progress last night (thanks, Stacker 2) but I’m still having some trouble with DynamicRenderer.Refresh(). It’s just an annoying visual glitch right now. But anyway, the new window management is completed and working and TEO forms are loading much faster in 3.0. I had to scrap the standard XP-themed tab control (again) because it does not paint quickly when using transparent controls. Since there’s a lot of tab switching going on, there’s a lot of paint operations. So I’m back with SandDock again.

All of you who have asked for larger input areas will get your wish! But those of you with ultra portables, don’t worry there is a special layout manager for smaller screens that will optimize the UI for your display.

I have been invited to speak on behalf of Einstein Technologies at the Sylantro Global Summit 2005 (Las Vegas, Sept 12-14), a private conference for Sylantro customers, partners, and developers. I accepted the invitation and I’m really excited to showcase some of the awesome technologies I have developed around SAI and CDR using Microsoft .NET.

While my development of SAI.NET and CDR.NET have slowed significantly (temporarily halted, even) due to the tons of work I’ve been investing in Tablet PC, I am going to continue to try to juggle these two technologies because I think they both have a lot of potential and I’m really proud of the work I’ve done with both.

Oh and I’m taking Heather with me this time so there’s no chance of coming back to find that she moved to another state.

As I work diligently on TEO 3.0, one of the things I am writing completely from scratch is the input control. This handy little “ink text box” is the rounded rectangular region in which you write in TEO. I feel that my ink text box has a number of advantages over controls such as InkEdit, the ink feature in InfoPath, and ink entry controls in other applications. Here are the four big advantages that I see:

  1. Ink to text conversion is an explicit mode switch
    That is to say that recognition does not happen automatically from the user’s perspective. (Though recognition is performed in the background for interoperability purposes.) The user chooses exactly when to convert the ink, if ever.
  2. Mode switching is fast! Not context menu driven, no dialogs.
  3. Eraser is fully supported
    Because of #1, the eraser can be used to give a more natural pen-on-paper experience. Scratch-out is also supported (and by the way, works much more predictably than in Journal, OneNote, and Infinotes!) for a faster (but less natural) erasing method.
  4. Field is still fully functional with a keyboard
    Many users don’t know this, but you can actually click into a TEO field and start typing to switch it into text mode. Part of the problem with this in 2.x is that there is no indicator that an ink control has the focus. This is being improved upon for 3.0.

But now let me get back to the title of the post. Better recognition in Tablet PC OS. As I am rewriting this control and finding ways to make it better, I am learning all sorts of new tricks that I knew existed but didn’t fully investigate in previous versions. For example, the recognizer can be provided a guide that tells it where you expect the user to be writing and how the position of the ink should be understood. In TEO 2.0 I didn’t use this at all. And while common requests were “make the fields bigger” and “give me a visible base line”, really what people were asking me without realizing it was to implement this guide.

TEO 2.0's input control

So for TEO 3.0, the guide will be fully supported for both Western/European languages and Asian languages which take boxed input. The guide will be drawn with an attractive decorator object that renders subtle rule lines like you’re used to as well as a dashed midline. This helps improve recognition greatly for two reasons. First, you know where to draw now. Secondly, the recognizer knows where you’re supposed to draw! Whereas before, you were both just guessing. Which, by the way, the recognizer is very good at doing. But every little hint helps.

TEO 3.0's input control (prototype)

This along with some very pretty visual enhancements to the control will make sure TEO’s input control remains, in my not so humble opinion, the best ink entry control (for fields) that exists.

One feature I used to really like about VB6/COM was a security feature called private interface implementation. Basically, what this means is that you have an interface that two components are aware of, but the public is not. So imagine if you will the following (in C# syntax, though C# doesn’t support this):

public class MyComponentA
{
     private MyComponentB _componentB;
     public MyComponentB ComponentB
     {
         get { return _componentB; }
     }
     public void Execute()
     {
         ((IPrivateExecution)_componentB).DoSomething();
     }
}

public class MyComponentB : IPrivateExecution
{
    void IPrivateExecution.DoSomething() { }
    public string SafeProperty { get{ return “blah“; } }
}

internal interface IPrivateExecution
{
    void DoSomething();
}

What the above allows you to do is define members in IPrivateExecution that no one else can call unless they have IPrivateExecution and share the MyComponentB class publicly without giving direct access to the IPrivateExecution implementation. Of course, this can be worked around using internal (friend) accessors and the new friend assembly attributes in .NET 2.0, but I am always suspiscious of friend access. The advantage of the private interface is that after compile time and deployment, you can choose to deploy the IPrivateExecution interface (which usually resides in another DLL that is not shipped) to a development partner or customer and then it “unlocks” access to that interface.

It was really handy and I’d love to see it returned to .NET CLR.

I got an email a few weeks ago from Handango informing me that they were preparing to launch their Tablet PC marketplace which is something that has been announced before but apparently they’re very close to launching it. They wanted me to list with them so that they have a nice catalog of apps for when the shop opens up in a few weeks. I’m sure they are actively going out and seeking the Tablet PC developers because I didn’t initiate the conversation with them.

So anyway, I asked a very simple question and got a very prompt and simple answer (thank you, Emily) but the answer was astonishing. They want 40% commission for apps sold through their web site Handango.com, 40%-50% for “value added channels”, and 10%-20% for their commerce engine (basically you sell the app, use Handango as a shopping cart – much like PayPal does for a lot less).

Why on earth would anyone willingly subject themselves to this? And who does Handango think they are? In the Tablet PC space, they have little relevance and they think they are going to build it by raping ISV’s who are already not making enough money because the Tablet PC platform has yet to surge the way we all hope it will someday??

If you are a Tablet PC ISV considering selling your wares on Handango, I would very highly suggest you look at alternatives like Tablet PC Post which is *MUCH* more relevant, and maybe even the Microsoft Tablet PC Software Showcase which in its current form stinks, but will probably get better in time.

As for payment processing, you’re a developer already so you can make PayPal work almost exactly like a credit card gateway with just a little bit of code. And unlike Handango, PayPal’s rates are typically around 3%. And your customers no longer need to have PayPal accounts.

And I, for one, from now on will think twice about buying anything from Handango knowing just how much they are screwing the software companies.