It seems like Darren & I had the same ideas over the last few days of 2004 -- learn/play with InfoPath. I have to say, I didn't really *get* InfoPath for a while (perhaps I still don't get it). However, I've now used it for 1.75 items, and so it's time to document my experience.

First up was a Quick & Dirty OPML editor. Nothing too generic, just something to edit blogroll-type OPML files. After a bit of searching, I found a half-decent XSD for OPML. It did have a few ... irritations. So, I cleaned it up and pointed InfoPath at it. Boom, insta-form, my Q&D(r) OPML Editor was born. While it did add a few items I wouldn't have normally (one PI for the automatic InfoPath and a namespace on the root node), but they were both fine based on the XML spec, and my reader (and others that were properly written) ate the files without complaint. Life and morale was good.

OPML Editor

Next, I wanted to work on something to improve on our process for selecting headlines for the MSDN home page. However, before I go there, I need to explain the current process (and get myself into trouble for the first time in 2005).

When I first started at MSDN, the MSDN home page headlines were done by others, so I had no clue of the process. After a while, though, it became the mandate of the Content Team to select them every week. Our initial process hasn't changed much since then, and basically boils down to:

  • One of the editors runs a report that lists the articles that have been published in the last three weeks, but that haven't been headlined yet. This is emailed out to the team (initially, 'n' copies were printed and brought to the weekly meeting.
  • Each Content Strategist looks at the list (or not) and creates bugs (or not) in our bug tracking system, assigned to the magical 'msdnhd' account. To this end, I had created an ASP.NET page to make submitting them easier (it would do the same query as the report, and let you create Product Studio bugs by clicking a link associated with the article). Also a Bookmarklet that would let you create the bug if you browsed to a good article.
  • Every Tuesday morning at 10:30, we shuffle, shamble, phone and or rumble down to 5/1255 for what I am sure is one of the louder meetings in merry Building 5. During the meeting, we discuss foreigners in the US (Canadians and Texans), sports, and whether Washington or Wisconsin has more serial killers per capita. Oh, and we pick the headlines for the next Monday and Wednesday. For this, we look at the list of bugs (refreshing the list as people quickly adds a few more), and people call out their favourite bug numbers. The ones closest to the "theme of the month" boil up to featured items (the ones with the graphics), while others become headlines or announcements.
  • Bugs get resolved, headlines get edited to "jazz them up".
  • The new list is sent on to the team that builds the home page. They then use a tool that D wrote, and publish the headlines on Monday and Wednesday of each week.

The current process has a few problems. First, it's very human-intensive, and as any good programmers know, that must be broken. Programs need to be inserted to make the humans feel they are doing less work (while they're actually doing more). Second, there was a limited paper trail. Only one magical Excel spreadsheet (that required re-entering the selected headlines) that was on some SharePoint that I can never remember where. Probably somewhere beside the spreadsheet that identifies the themes of the month. We've been meaning to fix this process for a while, but we've never really gotten around to it. Also, new internal tools are on the way that would probably make whatever we create a temporary placeholder anyway. So, no one was really interested in writing anything with such a short shelf life.

Enter InfoPath, Christmas downtime, and a slightly bored Kent with a desire to learn InfoPath flush from a recent success with the above OPML editor.

As I said above, I'm still not sure I *get* InfoPath. I've still been wrestling with using multiple data and query sources, and in laying out my forms. Initially, I think I tried to do too much on one page (see figure 1), and it looked a little muddy (D had suggested I do it as a Windows Forms app, but I wanted to do this one with InfoPath).

first attempt

One thing I do *love* about InfoPath though is the deployment model. Everything you need, including your schema files, the assorted XSLT files and even DLLs you reference are bundled up into an XSN file, which is really a ZIP file. So this JAR... uhm XSN file is all you need to give someone, you can even post it to a share (or a SharePoint) folder, and simply by clicking on it, they get the editing interface. Update the file on the SharePoint, and they get the new one. A lot of the joy of ClickOnce, but here today.

XSN file

I'm still working on the form, but I think it's taking shape (see Figure 2). I ended up with three views, so far it consists of the main XML it generates (based off of a schema), three web services (one to read from the database, one to write bugs to Product Studio, and the last to read the Product Studio bugs and create the main XML). This then goes off to a SharePoint folder for longer term storage. (see Figure 3)

current attempt
Headlines in Sharepoint<

Well, that's the current state of my babbling. So far, I think I like InfoPath for these XML-centric workflow type apps. If you have a schema in hand, it's quite easy to band out a handsome(ish) form in no time, and with the new Toolkit for Visual Studio .NET, you can now write your code in VB.NET or C# (your DLL gets bundled into the XSN file). Worth looking at for those data entry forms you might need to create.

TTFN - Kent
[Currently avoiding picking headlines for the Visual Studio and ASP.NET Dev Centers while listening to Army of Me by Bjork and jonesing for a decent network connection and/or a good strong cup of coffee to sleep in]