Running Dinner Planner



In most Running Dinner cases 3 Courses are served, and this is therefore the default for the Planner. That said, this screen give the user control over how many Courses are served (minimum 2, maximum 9), what they are called, and how many Hosts should be present in a House (where available) that caters that Course. Inputting the number 0 here means the House’s Hosts need not be present when the Course is served - this can be useful when your Dinner is served in restaurants instead of Houses. Furthermore, when historic seating arrangements are allowed (beta functionality - see Settings), the penalties associated with multi-meets involving those Courses can be discounted based on the slider settings on this screen. After all, penalties associated with people meeting each other once during last year’s Dinner and again during this year’s Dinner shouldn’t count as heavily as people meeting each other twice this year. It needs no argument that calculations involving Dinners that occurred in the past become far more computationally intensive. Moreover, since this constitutes Beta functionality, the user is discouraged from trying this. 

In this screen the user can define Special Relations, and assign in a qualitative way a penalty to meetings between two such people - be it negative (red) or positive (green). There are 3 ways of inputting this data:

  • by Course
  • as CSV

The information banner

As with all screens, a context-dependent information banner is located at the top of the screen. It features a “back to previous screen” button on the left, and a button for context-dependent help on the right

Input methods

By Course

No historic Dinners allowed

This screen can be used to create a new Course by pressing the Add ( Square Plus ) button. The Planner needs at least two Courses (which, if historic Dinners are allowed: must be set to ‘now’). The names can be set by the user, but must be unique. To delete a Course, swipe left.

Historic Dinners allowed

Naturally, penalties associated with people meeting each other once during last year’s Dinner and again during this year’s Dinner shouldn’t count as heavily as people meeting each other twice this year. So, when ‘historic Dinners’ are allowed, the penalties associated with multi-meets that involve Courses in the past should be discounted relative to such meetings happening in the here-and-now. The slider on this screen allows for just that. Note that the user is free to choose the name of the timeframe under consideration.


CSV - the interface

Arguably the easiest way of inputting Special Relations into the system is by way of the MyPlanner section on the website. To make use of this, the user needs to create and login to an account on, and  copy-paste data from, for example, Excel into the web interface. See also the CSV tutorial on the Tutorials page. That data can subsequently be downloaded from MyPlanner with the click of the cloud ( Cloud Queue ) button. 

The format the data needs to have is that of a Comma-Separated-Value (CSV) list, and can be inspected in the CSV text field. One line should contain:

    CourseNumber, CourseName, NrRequiredHosts, TimeFrame, PenaltyDiscount


  • CourseNumber: the number of the Course, starting with 1
  • CourseName: unique name for the Course (case sensitive)
  • NrRequiredHosts: the number of hosts that, when available, need to be present
  • TimeFrame: when taking into account Historic Dinners (see Settings),

this field should denote the name of the Time when the Course

was or will be served (e.g., 'LastYear', or 'now').

When left out, the Course will be assumed to be served 'now'.

Any name other than 'now' will create a different TimeFrame.

The TimeFrame of Course 1 & 2 can not be changed from 'now'

  • PenaltyDiscount: every 'multi-meet' between persons causes a seating-arrangement

to receive a 'penalty'. This number represents how much the penalty

should be discounted when partly or entirely taking place in this

Timeframe. The value should lie between 1 (treat this TimeFrame

the same as the 'now'-timeframe) and 100 (heavily discount the

penalty when (partly or entirely) taking part in this TimeFrame.

  • Note 1: Not all Courses have to be listed
  • Note 2: While possible, it is strongly advised to have no more than 2 TimeFrames.
  • Note 3: The maximum number of TimeFrames is 8.
  • Note 4: The maximum number of Courses is 9.
  • Note 5: If a CourseNumber does not already exist, a new Course will be created.
  • Note 6: If a CourseNumber already exists, the inputted values will replace its details.
  • Note 7: When left out, NrRequiredHosts and TimeFrame will be set to '1' and 'now'.
  • Note 8: TimeFrames can be used to take into account Running Dinners that occurred in the past.
  • Note 9: A single line can only hold data on a single Course

When loaded, the text field will contain the data currently available to the Planner. With the Copy ( Copy ) or Mail ( Envelope ) button, the entire content of the field, plus extra information such as the data format, can be made available outside the App.

CSV - downloading data from the cloud

In MyPlanner data can be stored for all the Steps involved in planning a Running Dinner. While, for each Step, the relevant data can be loaded on its own, the CSV functionality also allows for importing data for more than just 1 Step into the Planner. That is to say: upon pressing the cloud button ( Cloud Queue ), the App retrieves all the data from MyPlanner and allows the user to choose which data to load. Note that it is not enough to download, paste, or manually change the content of the textfield: it will only be made available to the Planner by pressing the Add ( Square Plus ) or Apply button. The App will then report how much of the data could be interpreted and was added to the system.