Mark Finkle's Weblog

Permanent Redirect

2006-03-14T00:07:00.000-05:00

I finally decided to get a host of my own. I setup a blog at www.starkravingfinkle.org. Blogger has been a great experience for me and I would recommend it to anyone. I just wanted more control and space for doing my own thing.

I am updating the FeedBurner feed, so anyone actually subscribed should get updated without any problems.

Live Clipboard & Open Laszlo

2006-03-09T00:53:00.000-05:00

Two really cool announcements this week: Ray Ozzie's Live Clipboard concept and Open Laszlo running on DHTML. I see both announcements having long term effects.

Live Clipboard is just so simple and useful, it has to get adopted, standardized and built into any serious web and non-web applications. That's right, desktop applications and OS shells should also support Live Clipboard. Users will love it. Moving data between web and desktop applications should be as simple as copy/paste.

Applications built using Open Laszlo can now be run using Flash or DHTML runtimes. So those Laszlo guys were serious after all. They have a demo running on both runtimes. Very nice. This goes a long way toward platform and runtime independence. A trend I'd like to see continue. Maybe a XUL based runtime could happen too.

IE7 Changes for MSHTML Embedding

2006-02-05T16:37:00.000-05:00

This is post is really for me more than anything else. I have been trying to find some information on what new features IE7 offers for those embedding the WebBrowser control. In the process, I also found some stuff that came out with IE6 during the WinXP SP2 timeframe.

DOCHOSTUIFLAG: New flags for navigation and redirect control. Also flags for enabling new "windowless" SELECT elements instead of the old "windowed" versions.
INTERNETFEATURELIST: This enumeration of features can out in IE6, mainly for controlling security. IE7 adds a couple new features for controlling more security stuff, tabbed browsing and builtin XMLHttpRequest. Also, it provides a way to turn off the damn navigation sounds without hacking the registry. Used with CoInternetSetFeatureEnabled and related API's.
Tabbed Browsing Developer Summary: Describes the effects on the DOM, shows how applications hosts can enable tabbed browsing shortcuts, and describes new notifications.
What's New in Internet Explorer 7: Summary of the major changes in Internet Explorer 7 of particular interest to the developers.
NewWindow3 Event: Showed up in IE6 XPSP2. Gives developers better control over handling new browser windows.
Microsoft Feeds API: An API for creating, managing, and accessing Really Simple Syndication (RSS) feeds.
Protected Mode API: Develop extensions and add-ons for Internet Explorer that can interact with the file system and registry. Includes methods to control a "Save As" dialog and save content to file.
Many URI related API's: CreateUri and IUri interface just for starters.

I came across most of this stuff by searching the MSDN site looking for "Internet Explorer 7 or later". I'll try to update this page as I find out more information.

MSHTML Hosting - Odds & Ends

2004-09-08T20:28:00.000-04:00

In this post I wanted to cover some miscellaneous things you may want to do with your embedded WebBrowser. On its own, the IWebBrowser2 interface does not support doing much more than we already covered in previous posts. However, if you start using the MSHTML DOM interfaces, much more functionality is available. Here is a list of simple things you can implement without too much difficulty:

Retrieving HTML from the WebBrowser.
Retrieving the HTML of the current selection.
Finding text in the HTML and selecting it.
Creating an image of the current HTML.

Retrieving HTML from the WebBrowser

There are times when you might want to get the currently loaded HTML from the control. You may want to save it to a file or parse it for information. For this functionality, you have to use the IPersistXxx interfaces. These are the same we used to load HTML into the WebBrowser from memory. The same works in reverse:


IHTMLDocument2* pDoc = ...;
IStream* pMyStream = ...;

IPersistStreamInit* pPersist = 0;
HRESULT hr = pDoc->QueryInterface(IID_IPersistStreamInit, (void**)&pPersist);
if (SUCCEEDED(hr) && pPersist) {
    hr = pPersist->Save(pMyStream, true);
    pPersist->Release();
}

Retrieving the HTML of the current selection

If you want to limit the HTML to just what a user has selected, instead of the entire document, we can use the IHTMLXxx COM interfaces. The first thing you need to do is get access to the IHTMLDocument interface for the current document. IWebBrowser2 gives you access using it's Document property. The Document property returns an IDispatch interface, so we need to QueryInterface the IDispatch interface for an IHTMLDocument interface, like so (raw C++):


IDispatch* pDocDisp = 0;
HRESULT hr = pWebBrowser->get_Document(&pDocDisp);

IHTMLDocument2* pDoc = 0;
hr = pDocDisp->QueryInterface(IID_IHTMLDocument2, (void**)&pDoc);
if (SUCCEEDED(hr)) {

    //...

    pDoc->Release();
}

pDocDisp->Release();

The IHTMLXxx interfaces follow the W3C DOM specification used for JavaScript very closely. If your familiar with those objects, the IHTMLXxx interface will be easy to grasp. In fact, if you know how to do something using JavaScript, you can duplicate it your compiled code using the IHTMLXxx interfaces.

That said, you can get the current selection as a IHTMLTxtRange from the document element. Once you have a text range, you can retrieve the plain text or HTML text as shown below:


IHTMLDocument2* pDoc = ...;

IHTMLSelectionObject* pSelection = 0;
HRESULT hr = pDoc->get_selection(&pSelection);
if (SUCCEEDED(hr)) {
   IDispatch* pDispRange = 0;
   hr = pSelection->createRange(&pDispRange);
   if (SUCCEEDED(hr)) {
      IHTMLTxtRange* pTextRange = 0;
      hr = pDispRange->QueryInterface(IID_IHTMLTxtRange, (void**)&pTextRange);
      if (SUCCEEDED(hr)) {
         CComBSTR sText;
         pTextRange->get_text(&sText);
         // or
         pTextRange->get_htmlText(&sText);
         //...
         pTextRange->Release();
      }
      pDispRange->Release();
   }
   pSelection->Release();
}

pDoc->Release();

Finding text in the HTML and selecting it

The Google toolbar in IE does this to make it easy to spot keywords found in the page. We are using body and text range objects. This time we are making a IHTMLTxtRange object, not getting the current selection. IHTMLTxtRange has find and select methods that make this task easy. Be sure to check out the parameters for IHTMLTxtRange::findText as they can be used to modify how the text is searched:


IHTMLDocument2* pDoc = ...;
IHTMLElement* pBodyElem = 0;
HRESULT hr = pDoc->get_body(&pBodyElem);
if (SUCCEEDED(hr)) {
   IHTMLBodyElement* pBody = 0;
   hr = pBodyElem->QueryInterface(IID_IHTMLBodyElement, (void**)&pBody);
   if (SUCCEEDED(hr)) {
      IHTMLTxtRange* pTextRange = 0;
      hr = pBody->createTextRange(&pTextRange);
      if (SUCCEEDED(hr)) {
         CComBSTR sText = "findme";
         VARIANT_BOOL bSuccess;
         hr = pTextRange->findText(sText, 0, 0, &bSuccess);
         if (SUCCEEDED(hr) && bSuccess == VARIANT_TRUE)
            pTextRange->select();
         pTextRange->Release();
      }
      pBody->Release();
   }
   pBodyElem->Release();
}

pDoc->Release();

Creating an image of the current HTML

Turning the contents of the WebBrowser into an image is not as straight forward as you may expect. Looking at the IHTMLXxx interfaces does turn up an IHTMLElementRenderer interface. IHTMLElementRenderer contains:

IHTMLElementRender::DrawToDC(HDC hDC);

You can try to use this method, but I have found that it is not very reliable and reacts inconsistently depending on the type of HDC you give it. A more reliable method uses an older OLE method. IViewObject supports the ability to render to an HDC. The IWebBrowser2::Document property can be QueryInterfaced for IViewObject. Two things to note while using this method, (1) you will probably want to turn off the scrollbars and 3D border since they will show up in the image and (2) you will want to resize the WebBrowser to the size of the contained HTML if you want to capture the entire content in the image. You may want to only make these changes temporarily and change them back after the image is captured:


IHTMLDocument2* pDoc = ...;
IHTMLElement* pBodyElem = 0;
HRESULT hr = pDoc->get_body(&pBodyElem);
if (SUCCEEDED(hr)) {
   IHTMLBodyElement* pBody = 0;
   hr = pBodyElem->QueryInterface(IID_IHTMLBodyElement, (void**)&pBody);
   if (SUCCEEDED(hr)) {
      // hide 3D border
      IHTMLStyle* pStyle;
      hr = pBodyElem->get_style(&pStyle);
      if (SUCCEEDED(hr)) {
         pStyle->put_borderStyle(CComBSTR("none"));
         pStyle->Release();
      }

      // hide scrollbars
      pBodyElement->put_scroll(CComBSTR("no"));

      // resize the browser component to the size of the HTML content
      IHTMLElement2* pBodyElement2;
      hr = Body->QueryInterface(IID_IHTMLElement2, (void**)&BodyElement2)
      if (SUCCEEDED(hr)) {
         long iScrollWidth = 0;
         pBodyElement2->get_scrollWidth(&iScrollWidth);

         long iScrollHeight = 0;
         pBodyElement2->get_scrollHeight(&iScrollHeight);

         // these lines depend on your WebBrowser wrapper
         pWebBrowser->SetWidth(iScrollWidth);
         pWebBrowser->SetHeight(iScrollHeight);

         pBodyElement2->Release();

         IViewObject* pViewObject;
         pDoc->QueryInterface(IID_IViewObject, (void**)&pViewObject);
         if (pViewObject) {
            /* however you want to make your image HDC.
               You can size it using iScrollHeight & iScrollWidth */
            HDC hImageDC = ... // could be bitmap or enhanced metafile
            HDC hScreenDC = ::GetDC(0);
            RECT rcSource = {0, 0, iScrollWidth, iScrollHeight};
            hr = pViewObject->Draw(DVASPECT_CONTENT, 1, NULL, NULL,
                                   hScreenDC, hImageDC, rcSource,
                                   NULL, NULL, 0);
            ::ReleaseDC(0, hScreenDC);
            pViewObject->Release();
         }
      }
      pBody->Release();
   }
   pBodyElem->Release();
}

pDoc->Release();

As you can see, there is a lot of things you can do using the MSHTML object model. Some of it can be tricky. Other things just aren't supported as well as they should be for an application developer. I guess you could say that application developers have their own list of issues for IE.

VML, SVG and Canvas

2006-01-01T14:43:00.000-05:00

Take a couple weeks off from blogging and it's real hard to get back into it. I have been working toward a BETA at my day job, playing around with a web project at home and enjoying the end of year holidays as well.

Anyway, the web project is a web application that makes heavy use of graphics. Started building on IE with VML (Vector Markup Language). I gained experience using VML from my day job. Had no problems putting together a pretty good vector graphic editor, complete with HTML text inside shapes. The editor would be a core component in the web application. Then I started adding in support for Firefox. The plan was to abstract the VML/SVG differences and use as much common code as possible. JavaScript libraries like Prototype made lots of the work easy.

The big pain was the feature differences between VML and SVG. Here are some of the problems:

VML was built as an extension to HTML. SVG is a separate specification. It took a little time to figure out how to get SVG inside an HTML document (called Inline SVG) to work correctly. Also, I can mix HTML and VML together easily in any combination. SVG requires the use of <foreignObject> to mix in HTML and Firefox does not enable <foreignObject> by default.
Shapes in VML (<rect>, <ellipse>, etc.) support text child elements. When I reposition the shape, the text moves with it. It appears that shapes can't hold text child elements until SVG 1.2, which supports <flowPara> child elements. For now, changes to the shape must be manually mirrored to the sibling text elements.
Text in VML supports wordwrap. SVG does not and I can't believe it. Again, SVG 1.2 supports <flowPara>, but I am not sure wordwrap is part of <flowPara>. How long will it take SVG 1.2 to get implemented in Firefox, Safari and Opera?
VML supports the same level of CSS attributes as HTML. SVG does not support the same level. One attribute I could not use was 'cursor'.

My biggest problems with SVG are text related. Maybe I just don't know the right way to do it in SVG. I'm still learning.

And then there's <canvas>. It has good support in Firefox, Safari and Opera (soon). Along comes Emil Eklund with an implementation of <canvas> in IE and now I have to consider switching to <canvas> as the lowest common denominator. My biggest problem with <canvas> is text (I see a theme here). I am not sure how to handle text with <canvas>.

P2P Toolkits

2005-10-15T16:06:00.000-04:00

A while ago, I was looking for a P2P framework library that I could use in a software project. The only real P2P toolkits I found were the Java-based JXTA and the Windows XP (SP1) Peer-to-Peer API from Microsoft. Neither really worked for me. I program in C++ and wanted to support older OSes.

I was too focused on 'P2P' in my searches. It finally dawned on me that multiplayer games have to solve the same problems as a P2P client. Googling turned up several interesting toolkits:

After looking at all of them, I decided to start working with DirectPlay. It has the easiest API and hides all of the low level socket stuff from me. The biggest potential problem with DirectPlay is that it appears Microsoft is sunsetting it. I don't think it's a issue though. It's still in DirectX and will be for a while. It just won't be developed any further. At some point, when Windows XP is the oldest OS I need to support, I'll switch over to the XP Peer-to Peer API.

Improvements in User Experience

2005-09-24T14:32:00.000-04:00

Inductive UI in Office 12

By now anyone interested in software user experience has seen the video or read the articles about Microsoft Office 12 getting a complete UI makeover. For an ongoing explanation of the design rationale, you should also checkout Jensen Harris' blog. Jensen works on the Office user experience team.

Many people write-off the UI changes as merely a ploy to get customers to upgrade. In a way, I agree. Customers will upgrade because the new interfaces will make using Office easier and allow users to be more productive. Inductive UI's have been around for a while, but this is the first large-scale use in a major Microsoft product.

For those of you in the back, it's not just about the menus and toolbars (or 'Ribbon' as they are calling it). It's about why the menus are gone and why the toolbar is separated into contextual sections and chunks. I am glad Microsoft spent the time and money to research how users were interacting with Office. Since Office seems to set a UX precedent, I am hoping we see some of these new conventions trickle down into other applications as well.

Update: Jeff Atwood of Coding Horror has a post about this too.

Windows Vista User Experience Guidelines

Microsoft has also released preliminary Windows Vista UX Guidelines. Although many people are pointing to the download, few are commenting on the information contained within. Chris Pirillo does provide a nice list of nuggets he discovered while scanning the documentation. I'll point out some of my favorites:

Wizard pages: Remove front and back pages. Remove page header. Basically remove all redundant textual information.
Help on Dialogs: 1. Make labels and controls easy to comprehend, 2. Add explanatory text sections as needed, 3. Use hyperlinks to jump into Help for specific topics which may be confusing, 4. Do not use vague or general Help buttons (users don't like vague or general help).
Task dialogs: MessageBox API on steriods.

I like this release better than previous ones (Win2K and WinXP) because it seems more focused on UX and contains some rationale as well. It's not just specs for controls, layout and themes. Some sections, such as Window and Layout sections, are not included yet (it's preliminary). You also need to wade through some Aero graphics babble (I am not impressed with 'glass' for UX).

Jumping In

2005-08-05T00:27:00.000-04:00

In a rather accidental manner, I am starting up several new projects. I am really getting into Wiki's. I installed MediaWiki at work for internal collaboration and knowledge management. I decided to run it on Linux instead of Windows, so I installed Ubuntu. Wow! First time I have ever done anything with a *nix. It's fantastic. I am considering switching my home machine to Ubuntu as well.

I have made many ASP-based web sites before, but now that I had a Linux server, I thought I'd try something different. I installed Django, mainly because I have always wanted an excuse to learn Python. It was much easier to get going than ASP. I had heard the same thing about Ruby On Rails for a while, but had my doubts. Those doubts are gone.

My biggest problem now is finding the time to explore them all.

Hello XUL Runner

2005-07-30T02:35:00.000-04:00

I have been playing with XUL Runner. It feels like writing a web app, but runs on the desktop. Windows, Linux and Mac desktops. Sweet!

Other things I like:

Nice selection of widgets and layouts
XBL allows new widgets and behavior to be added.
XPCOM allows calls to JavaScript and C++ non-GUI code.
SVG support is builtin. (soon)

UI Frameworks Are Pigs

2005-07-13T00:14:00.000-04:00

Why are UI frameworks pigs? Because they don't love you back.

You know the story: You meet this new UI framework. It seems so fresh and exciting. You start spending more time together, just doing small stuff. Things are so easy, not forced or boring like with your previous frameworks. So what if it acts a little immature. Before you know it, your writing specialized controls from scratch, embedding large amounts of business logic and enjoying every minute of it. Your head over heels. Next thing you know, your crying yourself to sleep and listening to Barry Manilow.

Come on buddy! Snap out of it. UI frameworks don't love you back. They don't care about you. You need to watch out for yourself. Protect yourself. Isolate your code.

If your not ready to drop your current UI framework and switch to something else right now because it could take person-years to port, you have problems. If you have team members that love your current UI framework too much to want to change, you have problems.

They don't love you back.

The experiences above are not about me, but I have this friend...

AJAX and Rocket Science

2005-07-13T00:01:00.000-04:00

Seems I am not the only one disturbed by the FUD some groups are pushing about AJAX being very difficult to implement. This post has some good examples of how easy it can be.

Writing good, quality software is non-trivial in any language. Wizards and RAD designers do not automagically generate great software.

Scalable User Experience

2005-07-04T15:48:00.000-04:00

John Montgomery on Scalable User Experience. Although I disagree with the rocket scientist required myth, I agree with John's conclusions. I especially like this quote:

Rather than trying to replace every application model in use today with one perfect model, a better solution is to let them flourish and to connect them together so that each can do what it does best. This vision, which I'd call the "Scalable User Experience," is where Atlas begins to take application models. This team is building off three tenets (even if they don't know it):

Respect the richness of the client (whatever that is) to provide the best possible user experience

Contain complexity on the server to build on existing administration skills and infrastructure

Leave no developer behind by using existing developer skills, code, and tools

I believe that AJAX is a methodology which can help achieve scalable user experiences. I am hoping toolkits like ATLAS can help with some of the weaker aspects of web applications, mainly integration with the desktop client.

In Search Of: A Usable UI

2005-06-27T23:56:00.000-04:00

Jeremy Zawodny's Surprising User Expectations post and Jeff Atwood's UI is Hard post draw attention to a big problem in software development: Developers rarely design good UI's. I have come to the conclusion that UI design should be handled by people who understand how users think, interact and model problems. This is more of a human factors problem than a coding problem.

I am a big proponent of making usable software. It's one of my crusades. Usability is not defined by developers, it is defined by users. We recently completed our second phase of usability testing on a new product. It's always a learning experience watching regular people trying to use software. It can be frustrating when it's software I helped to develop. To make better UI's, developers need to appreciate the obstacles that confront users and try remove the obstacles. Usability testing and reading people like Cooper, Nielsen and Norman can give you a better perspective.

Here are a couple guidelines I compiled from my own experiences and from people smarter than me:

Be flexible: Allow for multiple ways to get something done. Use main menus, toolbars, right-click menus, task panes and hyperlinks. This allows the user to choose the way most comfortable to them instead of forcing them to learn your way. Keep in mind that for any given user, the preferred method could change over time.
Be explicit: Don't force the user to guess or explore the UI. Use verbose captions, messages and explanations.
Be proactive: Don't wait until the user gets into trouble, keep the user from getting into trouble in the first place. Why wait until the end of a process to inform the user they made a mistake at the beginning?
Be forgiving: Make it possible for a user to recover from an unwanted action. People make wrong choices. Recovering from a bad choice with most of your data intact is far better than being forced to recreate something from scratch.
Be simple: Simple, focused screens and dialogs are easier to learn and allow users to get things done faster.
Be consistent: Make use of the fact the users can learn how to do things. Don't force them to re-learn how to do the same or similar things.

None of these points is revolutionary or even original. But it's amazing how few applications implement them.

Jeff's post has some good links to other articles that are worth checking out. He also brings up the concept of UI First development. I definitely agree that the UI should be given some focus early in the project. Unless your building an engine or library, the end-user is going to equate the UI with the software. If the UI is bad it won't matter how good the code is behind the scenes.

Update: For those interested, a co-woker pointed me to another UI First design methodology at Human Factors International (HFI).

This Just In: AJAX Is Important

2005-06-28T12:55:00.000-04:00

Looks like Microsoft is getting on the AJAX bandwagon, whether they like it or not. Scoble mentions a Microsoft Javascript library named ATLAS. CNET, Microsoft Watch and Information Week posted articles about ATLAS. Charles Fitzgerald is, again, the MS guy involved. Reading the articles, I can't tell if Fitzgerald is excited about ATLAS/AJAX or just feels like its something MS needed to do to stay relevant in web development. Some quotes:

"People who do (AJAX development) are rocket scientists," Fitzgerald said. "In some ways, this papers over the mess that is JavaScript development. It's easy-to-build 'spaghetti' code." [CNET]

"Microsoft is really the only company that spans the continuum, from the simplest Web client through he smartest client," said Fitzgerald. [Microsoft Watch]

"We just needed the clever name" – like Ajax, Fitzgerald said, to explain the various things that developers have been able to do for almost a decade with Microsoft technologies. [Microsoft Watch]

Using Atlas, developers will be able to write Ajax apps that contain pre-written code to smooth over technical distinctions between Web browsers, and debug those apps with Microsoft-branded tools, says Charles Fitzgerald, a general manager at Microsoft. Using Ajax today, he says, "is a little bit of a hack." [Information Week]

Here is what I think:

Microsoft invented the technologies now called AJAX, but moved away from browser based clients in favor of Windows based clients (Smart, Rich, Thick, Fat or otherwise).
The world of web development is quickly moving toward AJAX-style development. Microsoft is late and needs to make some mindshare.
Microsoft is a development tool vendor. They sell tools to make development easier, therefore, current AJAX development must be hard (rocket scientists need only apply) and messy.

Seems to me that many AJAX toolkits already exist. Many web applications are incorporating AJAX very quickly. Examples of AJAX range from simple enhancements to full blown applications, implemented by mere mortals.

This move does not seem in sync with Microsoft's .NET/WebForms/Smart Client agenda. Therefore, I question whether their heart is in the initiative. On the other hand, Microsoft's new RSS initiative (also connected to Fitzgerald) seems inline with current company agendas and has good backing inside and outside the company.

Update: Scott Isaacs of MSN Spaces and Scott Guthrie of ASP.NET have some good technical posts on AJAX.

MSHTML Hosting Article Published

2005-06-15T00:16:00.000-04:00

I wrote an MSHTML hosting article for the C++Builder Developer's Journal. They decided to make the issue freely available. HTML and PDF versions are available.

Rich UI vs User Experience

2005-06-14T22:41:00.000-04:00

John Montgomery and Jon Udell are having a discussion about AJAX and rich internet applications. Montgomery is trying to determine what all the fuss over AJAX is about. He played with some toolkits and is unimpressed. Why? He doesn't see how AJAX can compete with Winforms/Webforms on user experience. John says:

Mostly, Jon's posts got me to thinking about why we (that's you and me - Web users) are OK with degraded user experiences. I mean, for years we had great desktop applications to do things like calendaring and email and even mapping software. Then came the initial Web, where HTML 3.2 and some JavaScript meant that Web apps just couldn't be as nice as local apps. And now we're all very excited about things like Evite, Gmail, and Google maps. But compare Google Maps to Streets and Trips, which I did recently, and the experience with S&T is much better. Same with Outlook vs. Gmail (usually, anyway). Heck, most people read blogs through a Web browser, not an aggregator, even though aggregators are much more efficient. So why do we let ourselves settle?

I think he is confusing user experience for rich widgets. Web-based applications can achieve a high level of user experience and usability without the need for complex widgets. Good web applications are simple, small and well focused to the task at hand. In fact, I always use the web versions of the applications he lists over the desktop versions.

As John points out, the web-style hyperlink approach, with few options and everything laid out in front of the user, is easy to learn and use. To me, this increases user experience, not degrade it. John also points out that content is more plentiful in web-based applications and users like getting content. So much so that he feels users are willing to give up a great UI if they can get great content. Why does a user want a great UI at all? Seems to me that users only really care about content (or data). I think usability experts like Nielsen and Cooper would say a great UI is a UI that allows users to complete tasks without getting in the way. The UI should not be centerstage.

Udell's posts point out that AJAX systems have a tendency to allow users access to content they want in ways the web-UI did not anticipate. Also seeming to confirm my suspicion that users don't care much for flashy UI's, but graviate to applications that make it easy to extract and manipulate content. WebDAV and SOAP are not low-hurdle technologies, XmlHttpRequest seems to be. AJAX is a methodology for enhancing web application functionality, not for replicating desktop applications. People don't want desktop applications running in the browser, didn't Java teach us that?

XML File Formats in Office 12

2005-06-02T01:15:00.000-04:00

Brian Jones, program manager on the Word team posted news about the new XML file formats in Office 12. I have posted a few times on XML file formats, so I am interested in what Office is doing. Some interesting points:

Full fidelity. As good as the binary format.
Compressed. Lots of file parts stored in a structured ZIP archive, similar to OpenDocument
Fully documented. Whitepapers, documentation and XSD schemas.
Robust. A lot less likely to get a corrupt file that can't have pieces recovered.

IMO, the above points could be true for any product using an XML package format, but the fact that Office is doing it means millions of users can escape the data roach motel.

Scoble has more on Channel 9 as well as his own blog. Jones plans to link to whitepapers as soon as they become available on MSDN.

Granted, Office is following OpenDocument here, but this is a really good thing.

MSHTML Hosting - Drawing On WebBrowser

2005-04-24T00:42:00.000-04:00

Hosting the WebBrowser in your application makes it easy to create slick-looking textual UI's. HTML is a fairly expressive markup language and the results can be very professional with little difficulty. The graphical side is a little less impressive. Thankfully, SVG and VML (native support in the WebBrowser control) go a long way to fill the gap. Both have capabilities that blow away good old Win32 GDI drawing. Even so, there may be times that you wish you could grab an HDC for the WebBrowser control and start drawing on it. The WebBrowser control actually has a system built into it that allows you to do just that.

IHTMLPainter is part of a system in MSHTML called Binary Behaviors. Behaviors can do lots of cool stuff. Painters are a special kind of behavior called a rendering behavior. IHTMLPainter::Draw is called by MSHTML before or after the HTML content is rendered allowing you to draw below or above the content. MSHTML passes an HDC into method that you can use with any GDI or GDI+ drawing function. Basically, behaviors are COM objects that you implement and are associated with HTML elements, either in the HTML itself using CSS or progammatically using addBehavior. The MSDN has a nice tutorial on creating a rendering behavior that includes sample code.

XML Services In Desktop Applications

2005-04-24T00:27:00.000-04:00

It's pretty fair to say that I'd like to change the way I write desktop applications. I am tired of the UI framework lockin that comes with traditional desktop development. I've posted a couple times about using DHTML+SVG to create a desktop application UI. I have been working on prototypes in DHTML+SVG, as well as Laszlo (server-less deployment is now available) and Xamlon (they have a cool new flash-based system in addition to the .NET system).

I am now focusing my attention on non-UI parts of desktop applications and how Web-like techniques could be applied. Desktop applications, large ones specifically, are usually composed of subsystems that are exposed to the user via a host client. IMO, it's important to componentize these subsystems and get them to interact in a way that does not tightly couple them together. Sounds a lot like the definition of a Web service. One way of doing this in C++ is using abstract base classes as interfaces. I am beginning to find this method too object-oriented for my tastes. The sheer number of interfaces required to support the subsystem can be quite large. Interfaces usually cause a language lockin as well. C++ abstract base classes cannot be used very easily by other languages, unless your willing to completely wrap your interfaces with proxy code.

I am leaning more towards an XML services approach. Each subsystem would have a single entry point which would dispatch XML messages (in a RESTful sorta way) throughout the rest of the subsystem. This approach feels just like Web-based services and has the same kind of benefits. Just about any language can immediately start using the subsystem with minimal effort. The subsystem's dispatch entry point could be made HTTP-aware and suddenly gain the benefits of a true Web service:

Subsystems can be put on different machines.
HTTP techniques can be used to increase scalability and robustness.
Many different and special-use clients can be created which leverage the subsystem.

The kind of subsystems I am referring to include parsers, graph renders, expression evaluators, report generators, data converters and data analysis systems. These are examples of systems that should be made well-defined islands and have great potential for reuse. Instead, they are locked up into the UI client and can not be integrated into other solutions.

MSHTML Hosting - More Tricks

2005-04-02T16:31:00.000-05:00

Here are a couple miscellaneous tips for using the WebBrowser while in design (edit) mode.

Setting Focus In Design Mode

With the WebBrowser control in design mode, there are times that focus (and the blinking cursor) are not set correctly. For example, with focus in the editor, ALT+TAB away from your application, and then back again. Focus may not be set back into the editor. Here is a simple way to fix it. Put this code in an event or message handler that gets called when your application is re-activated:


IHTMLDocument2* pHTMLDoc2 = ...;
IHTMLWindow2* pWindow = 0;
pHtmlDoc2->get_parentWindow(&spWindow);
if (pWindow) {
  pWindow->focus();
  pWindow->Release();
}

Unselecting Current Selection

IHTMLTxtRange has a method to easily select a range of text, but there is no simple method to unselect an existing text selection. Here is a simple way to do it:


IHTMLDocument2* pHTMLDoc2 = ...;
IHTMLSelectionObject* pSelection = 0;
pHTMLDoc2->get_selection(&pSelection);
if (pSelection) {
  IDispatch* pDispRange = 0;
  pSelection->createRange(&pDispRange);

  IHTMLTxtRange* pTxtRange = 0;
  pDispRange->QueryInterface(IID_IHTMLTxtRange, (void**)&pTxtRange);
  if (pTxtRange) {
    VARIANT_BOOL bSuccess;
    pTxtRange->execCommand(CComBSTR(L"Unselect"), VARIANT_FALSE, CComVariant(), &bSuccess);
    pTxtRange->Release();
  }
  pDispRange->Release();
  pSelection->Release();
}

More on Task-based UI's

2004-07-31T00:34:00.000-04:00

Microsoft published the first article of a two-part series on Inductive UI (IUI) design, their buzzword for Task-based UI. This one covers a couple things:

How IUI can help users get frequent tasks completed faster.
What is a frequent task.
How you can implement a IUI design using a .NET library.

If you have ever seen an IUI design (think Task Panes in MS Office 2003), you will almost immediately see Web-style similarities. The article discusses this, referring to Dialog-style versus Web-style UI's. The author does note that in many cases experienced users will prefer Dialog-style UI's over Web-style. While I can agree with the sentiment, it usually happens in cases where the Web-style UI is designed to perform a long, drawn out wizard process. In most cases, such Task Panes, Web-style UI's are just as unobtrusive and straight forward as the Dialog-style counterparts.

Since I am working on a Task Pane infrastructure for an application at work, I was also interested in the details of the Web-style navigation library used to build Task Panes in .NET applications. The library allows programmers to create pages, which appear to be frame-like surfaces you can drop controls onto. The library manages a stack of those pages. This is different than our approach, which uses the MSHTML web browser component to host a stack of HTML pages.

Update: Part 2 is available.

AJAX - Markets Abhor a Vacuum

2005-03-19T14:45:00.000-05:00

If you have only recently heard of greatness of AJAX, then you have not been paying attention for the last 5 years. Not that there's anything wrong with that. Lot's of people are quite excited by the new hype over HTML + JavaScript (+ XML + SVG), myself included. The reason for this post? Just to put down in words some of my reactions to things I've seen written in regard to the new hype.

CNET has an article discussing the renaissance and how AJAX may be used in the future, leading to a possible destruction of desktop applications. I love the media. Anyway, Charles Fitzgerald of Microsoft is quoted:

"It's a little depressing that developers are just now wrapping their heads around these things we shipped in the late 20th century,"

I can agree with that. None of this stuff is brand new. In the same article, David Mendels of Macromedia is quoted:

"It is really, really, really hard to build something like Gmail and Google Maps,"

"Google hired rocket scientists--they hired Adam Bosworth, who invented DHTML when he was at Microsoft. Most companies can't go and repeat what Google has done."

I think this is total crap. The article ends with a quote from David Temkin of Laszlo:

"The successors to Word and Excel and Powerpoint are not going to be written this way. It's just not going to happen."

This seems like a strange thing for a rich Internet application framework vendor like Laszlo to say. Even assuming that David was not quoted out of context, the statement is wrong.

Software products are mainly driven by markets. Users in those markets have needs and software is created to meet those needs. If your company makes a desktop OS, you'll probably make software that runs on the OS. At least until the users' needs change and the market forces you to re-evaluate how you build your software. How quickly you change the way you build your software depends on many factors, including the strength of the market forces and the cost of rewriting your existing codebase.

By the way, writing any kind of software application can be really, really, really hard. There is a difference between building a web-site and writing a web-application. And yes, I do have an aerospace engineering degree. Desktop or web, it's still hard.

My point is that if there was enough of a user need for presentation software that could be run from anywhere, the next version of PowerPoint would be built using an AJAX-like framework. It probably would not be Microsoft that builds it. They have an existing codebase that makes it costly to do such a thing. If PowerPoint was a product of the MSN division, things might be different. IMO, that group is doing some of the best new work at Microsoft.

John Gossman has a couple posts that also stirred me up. In general, John is definitely worth reading. He agrees with Temkin that Office will not be rewritten using AJAX, but attributes some of that to browser limitations. Many of those limitations are gone, including the advanced graphics issue he brings up. SVG and VML (in IE) do some pretty cool things. More than enough to drive a decent PowerPoint/Excel replacement.

Robert Scoble brings up offline usage in a recent post. Again, this limitation can be overcome. Since IE 5, web applications could use the userData behavior to store data locally. Together with client-side XML/XSLT, its pretty effective. I am sure Mozilla/Firefox has something similar.

The replacement does not need to have all the features of the desktop version. Successful web-based applications (like email, bug-tracking, ERP systems, RSS aggregators and blogging tools) have shown that users are willing to give up some of the "niceties" of a desktop version for the benefits of web-based deployment.

Markets (and users) abhor vacuums. If a web-based PowerPoint vacuum exists, some software vendor will fill it.

XML vs Serialization

2005-03-05T02:40:00.000-05:00

In this XML vs Serialization post, the author lists reasons why XML is not a good serialization format. I would turn the list around and say those are the exact reasons why XML is a good way to develop a serialization format. Even if its just an XML dump of your object model (I think we could do better than that), it's still better than a binary dump. If my object model changes, and it surely will, I can always transform the older XML dump to the newer structure. Even if its by a hand-written script. You can't easily do that with binary.

Also, I don't believe serialization implies the object model is more important than the data. I prefer to think it means the object model holds the data.

Via mnot

Object/Relational Mapping - No Thanks

2005-03-04T01:59:00.000-05:00

I have already posted some of my current feelings on using object hierarchies to hold state. It should come as no surprise then, that I am also questioning value of object-to-relational mapping systems. Why in the world would I want some system to create a multitude of objects just so I could manage state (not behavior) using those objects.

I still end up with a brittle object model that is difficult to navigate and breaks when my state changes and exposes the rest of my code to that breakage. SQL and XML both provide simple ways to query and navigate using loosely coupled techniques.

Fewer objects, not more. It does not matter if they are auto-generated or not. I still have to use them in my code.

Holding State as Objects is Painful

2005-03-03T01:43:00.000-05:00

As a developer, I write code. Code is good. I like code. But the people who use the applications I write could care less about the precious code. They care about.. wait for it... the data. Shocking, isn't it. I could have written the most elegant, wonderful code possible, but if I can't move their SuperApp version 1 files to SuperApp version 2, it's worthless.

Coding usually involves either holding state or executing behavior on the state. Holding state as an object hierarchy is really painful. First, someone has to write all those damn classes that map to the state. Then, changes to the state structure break the object model and any code using the object model. Besides brittleness, object models are a pain to walk (or navigate) and difficult to query or filter. Developers usually have to write other framework objects to support parent/child object relationships. Persisting from an object model can also be a pain and increases the likelihood of problems when the state structure (and therefore object model, and therefore persistence format) changes.

I say it's time to let it go. Focus on the data. Protect it. Ensure it's stored in a way that's robust enough to handle future changes. Think about this: MS Word 97 can open an MS Word 2003 file. Somebody was thinking about the data.

Use code to execute behavior on the data. Separate code from data, just like we're told to separate UI from business logic. If you've been reading my stuff, it should come as no surprise that I favor separating code from data by using XML to hold state. It's a means to an end. XML supports the kind of structure my state needs. It also supports standard ways to quickly walk or query for a piece of data from my state.