#summary Use cases for the program iShudan via web browser
#labels Phase-Design,Phase-Implementation

= Introduction =

  There are several target audiences for the program, not all of them necessarily mobile.  In developing the use cases that are envisioned for iShudan, we can identify target features of importance for development by categorizing who uses them and why.  A game of Go has two participants, and in most cases we are therefore interacting with two different sets of expectations.  

  Consider the perspective of a person playing a real over-the-board match with an opponent recording the game using iShudan: if it takes too long or is too complex, this is going to be aggrevating and our player won't continue to enter in future games with the iShudan user, a most undesirable result.

*Q*  What are some advantages to playing go with iShudan?

*A*  It works over slow, intermittent connections such as poor dial up or EDGE cellular networks, a widespread but comparitively slow technology.  low transfer rate is required for those who pay by the byte, both the pay-as-you-go data plan crowd (_no_pun_intended_) and those with limited or metered service.  


* Thanks to Benjam, now includes "kibitz" mode for low bandwidth, simple conversations which run over time of the span of the game. This also is low-weight and stays within the constraints previously defined for game elements above.  this can be ignored if not needed, but is useful if you wish to request a takeback, or just leave a message waiting for your opponent.






= First case, 1 player at home, 1 player via mobile handset =

  Home user (_Alice_) starts a match with remote iPhone user (_Bob_).  If email notifications are on all the time for all users, and if they are making moves in real time, that means Alice receives too many emails.  If automatic refresh is on, Alice can tell when it is her turn, but Bob can't concentrate on the screen at his desired size and portal location because the reloads destroy that session every refresh interval.  

Proposed Solution: checkboxes to enable or disable refresh or specify time, enable email notifications for partner/other, etc? Messy but simple, lacks elegance.



= Second case, 2 players via mobile handset =

   iPhone owner Bob wants to play a game with iPhone owner Charlie.  
*current benefits*

  * email notifications work perfectly, giving a URL to the board and game number in question. Real-time "nagging" keeps players engaged and working to a completed record.
  * Auto-sizing of the smaller boards is working properly for iPhone users, using the portal identification code that Adam implemented.  This will continue to receive additional tweaks, but represents a significant milestone.
  * chat works, but could be better, timestamps or move numbers added per line perhaps?
  * Cookies are stored properly in the mobileSafari, so you need only authenticate once or so.  Can also sign out and back in with a new identity without issues now.

*current needs or issues*

  * need guidance for prospective users on how to move without making a "mis-fire", perhaps a subtle note on the game page that can be dismissed?
  * *jump tags*: not yet implemented, needed to skip to the right section of the game page at will, can use some of the apple-provided UI elements, needs additional information...
  * Request Takeback needs implemented *ASAP*, number one most requested feature.