Yikes, I’m already kind of doing things out of order.  I had intended to start with wireframes, but I’ve jumped straight to data.  That said, this isn’t quite as out of order as it might seem.

As I mentioned earlier, I want to be able to sync with Remember The Milk (which you really need to check out if you haven’t already…it may not seem like much at first, but poke around a bit and see all of the stuff that it does…thanks for the heads up Kevin).  To avoid wireframing myself into a corner, I wanted to make sure that I really understood what I can and cannot do with the Remember the Milk API.

So, first step has become the data layer.  The thought is that this will inform the wireframes and that makes sense.  It can be good to understand some constraints before jumping into a design process.  Fortunately, the API is really solid and just about exactly what I think I need.  My data model doesn’t sync yet, but it is a good match to their API so when it comes time things should go smoothly.

All in all, I was able to build out the data layer in about an hour.  It went fast.  The trick was a combination of Dr. WPF’s sweet snippets (for creating properties that support INotifyPropertyChanged) and my super favorite xaml as a data format trick.  Oh, and there were really only two classes.

In the end, the serialized xaml for the data layer looks like this:

<d:ProjectList xmlns:d="clr-namespace:ThoughtBox.Data;assembly=ThoughtBox">
  <d:Project Description="Shopping List">
    <d:Project.TaskList>
      <d:TaskList>
        <d:Task Description="Milk" />
        <d:Task Description="Chocolate Milk" />
        <d:Task Description="Evaporated Milk" />
        <d:Task Description="Coconut Milk" />
      </d:TaskList>
    </d:Project.TaskList>
  </d:Project>
  <d:Project Description="Clean The Study">
    <d:Project.TaskList>
      <d:TaskList>
        <d:Task Description="Go through files" />
        <d:Task Description="Hang whiteboard" />
        <d:Task Description="Hang artwork" />
        <d:Task Description="Refill stapler" />
      </d:TaskList>
    </d:Project.TaskList>
  </d:Project>
</d:ProjectList>

It’s not a perfect way to structure the data.  The problem is that some tasks will not actually belong to a project.  The problem with using XAML for this is that XAML likes to produce trees of things and this data is more like a relational database.  I decided to compromise though.  We’ll figure out the “dangling” tasks later, probably by introduce a “null” type project object which, as hacks go, doesn’t seem like such a bad one and it keeps a lot of things simple.