write a story 2.0

The tasks required to implemented New board: After picking a card, the author is asked to enter a story were split. An architecture is proposed for animations in cardstories. The reload frequency was reduced to a minimum to create conditions favorable to animations.

write a sentence sprint


It was decided the day before to accomplish a one day sprint on New board: After picking a card, the author is asked to enter a story. To that extent, the following tasks were created and dispatched:

transitions between states

Reloading the page at each game state change is going to be a problem for smooth transitions from state to state and a task was created to minimize when it happens.
Introducing animations in cardstories means that the HTML of a given game states changes over time.

  1. the player wants to create a story and starts by going to the state where (s)he can pick a card and the HTML in div .cardstories_create .cardstories_pick_card is displayed
  2. once the card is chosen, the HTML is animated and ends up in a different state, where only one card is displayed
  3. the game then switch state and displays a different HTML from div .cardstories_create .cardstories_write_sentence

When switching from the second to the third state, the change must not be visible to the user. This is done by ensuring that all the HTML to be displayed is already loaded and that the change is only a matter of hiding the previous HTML and showing the next. It is believed that such a change will not be visible to the user. Each game state must be designed to allow for such a separation. It means that there cannot be animations that span over two states.
Here is an example of how to satisfy this constraint. In the example above, the chosen card goes to the middle of the screen and is then moved up with a slightly different background and enlarged. After a short delay the input box is displayed.
The first part of the animation, up to the centering of the card, belongs to the first state, where the user picks a card. The next state, where the user writes a sentence, should start with a HTML and associated CSS showing the card centered at exactly the same place with exactly the same size.
The alternative would be to prefer a single HTML DOM tree that is changed from state to state instead of being replaced entirely in order to allow for animations that span over state changes. While this may provide for smoother animations (it remains to be demonstrated that the method above creates artifacts visible to the user), it would also be a more difficult to maintain. Definining the starting HTML DOM of a state as being visualy exactly the same as the ending HTML DOM of the previous state creates a kind of interface between states. It allows a CSS/HTML integrator to work independently without worrying about the previous state animations leftovers. It also allows to code the javascript dealing with a game state without a need to synchronize with the previous state.

reduce the reload frequency

The reduction of the number of reloads turned out to imply more changes because it revealed that the display_or_select_card function was not reentrant.
The poll now calls game_or_lobby instead of reload to prevent reloading the page whenever the poll function returns, which may happen each time a player vote. In the previous design that was only a small annoyance. With the board design it becomes much more visible and can even disrupt the animations. The display_or_select_card has been modified to allow for multiple calls on the same HTML element. The basic idea is that the original HTML is saved before it is altered by the jqDock.