Example of IC Card Specification

1. Starting with the top level IC card called plan_a_picnic I broke the activities up into other cards. I broke those activities up into a small subset of other activities involving the use of an RSVP list and what might happen the day of the event. See plan_a_picnic.

2. There were two timing issues in my system, determine_time and determine_place. Both of these I handled by having a third party determine conflicts. So to determine the time a calendar is used to find a suitable time. I was going to add in a weather forecast but wasn't sure how to make that interact with this card. The problem I was having was how to have multiple objects interact with the same card.

   The other timing issue was in the selecting of a facility to host the event. I solved this problem by giving the facility the constraints of the picnic (including the time) and then it decides if it can accommodate the picnic. This then allows the IC card determine_place to select an appropriate place.

3. In my configuration I ended up with 2 purple cards. One is the top level plan_a_picnic which involves both myself and my friends and both are in control. The other purple card is the day_of_setup because both myself and the weather are in charge.

   I observed a couple of different ways of breaking these purple cards into multiple cards. One way is to add a level of indirection For instance if for you to do your task you need to wait until something else is done. Just assign another card the responsibility of making the request and waiting until its done this way you can go about your business.

   At a high level the goal is to keep dividing the task into smaller and smaller pieces until the cards can do their work all by themselves.

4. I can easily identify two main patterns by working through the picnic example. One is that cards that represent objects tend to be involved in multiple tasks. For example the rsvp list which represents the final guest list is needed by both the food planning card and the activities planning card. This indicates to me that there needs to be some way of accessing 'global' information. Or have a director card that acts as message passing system between the other cards.

   Another pattern I see is serializing a task by chaining the cards together. Building a house might involve you painting the walls and a contractor doing the rest. To break this up you can have your first card just request the house be built by the contractor. After the contractor has the walls up then he can reference you again with the task of painting. After you are done then you interact with the next card in the series, say for instance laying the flooring. Essentially defining a logical event series. You could implement this using type of callback feature.

5. I assigned an icon to each of the cards that I created. They can be seen on the card page themselves. As an example of building an iconic sentence would be:
   + + =
   -- or in text --
   Incitations + Guest List + Replies = RSVP List

   I could also envision a palm like application which would have a starting menu that would make use of the icons to indicate the actions. Such a menu could be presented in a table like fashion on a small device. Of course with better icons :)

   Notice the logical order of events. Select time, pick place, invite people, assemble rsvp list, plan activities, plan food.