The INTERFACE Tab

Layout

Vertically, settings that only affect SETUP should come first, followed by SETUP and GO, followed by settings that are OK to change while the model is running. The idea is to put the controls in the same order the user will use them.

Try to lay things out in such a way that if the user wants to make the world and/or view bigger, they won't have to rearrange a bunch of stuff. This usually means avoiding putting stuff to the right or bottom of the view. (Not a hard and fast rule.)

Snap to grid

NetLogo includes a "snap to grid" feature, under the Edit menu. Use this when creating or moving GUI widgets. This makes it easier to ensure that widgets are of the same size, or that they're aligned. The settings is saved with the model.

Keep in mind, however, that "snap to grid" doesn't work when zoomed in, so you may want to press Ctrl0 before moving widgets around.

Ticks

If the model predates NetLogo 4.0, it may use a global variable instead of the built-in tick counter to keep track of time. Use the built-in tick counter instead. If there was a monitor for the variable, you can get rid of it.

Almost any model should use the tick counter, even if the model doesn't do anything with it besides increment it. In almost every model, it is useful to the user to know how much time has passed (or even just to be able to see that time is passing).

If you're sure you don't want the model to use the tick counter (for example, in a game), then use the Settings button to hide it.

If the model uses some other unit of time besides ticks, use the Settings button to change the tick counter to read "days" or "weeks" or whatever instead of "ticks".

Tick-based updates

The tick command always goes at the end of your go procedure, never at the beginning. Nearly every model in Sample Models uses tick-based updates. Don't use continuous updates unless you know exactly what you're doing and have a specific reason to. (You should probably talk to the devel team about it to be really sure.)

Some reasons you might want to use continuous updates:

• Model has only once buttons, many code examples. And even then, those models can usually be made to use tick-based updated.
• Model is turtle-forever-button based, like Termites, and therefore can't use ticks (very rare).
• Model doesn't really have a concept of time passing, e.g. Voronoi, and displaying intermediate state isn't a problem.

(feel free to add to this list if you know more reasons)

If you are considering using continuous updates in order to get animation to happen between ticks, usually you should stick with tick-based updates but use the display command to request additional updates in order to make the animation visible.

If you use tick-based updates, you may need to use the display command in some buttons. For example, in the Life model, the "add cells" and "remove cells" buttons use display so the user can see the cells they are adding and removing even though the tick counter is not advancing.

World wrapping

Think about whether world wrapping should be on or off (horizontally and/or vertically). Is the phenomenon modelled logically a torus, a box, or a cylinder? Keep in mind that turning wrapping off means that the edges become special cases that may need to be dealt with in the code.

Position of 2D view

Put the 2D view on the top right, so it can easily be made larger without covering other widgets. It's best not to put anything to the right or below the view (although for some models with very crowded interfaces sometimes we throw up our hands and do it anyway). If you must, you can put some interface items above the view, but this is unorthodox and shouldn't be done unless you really feel you need to.

When deciding on the overall window size, it's best if everything can fit on a 1024x768 display. Remember to leave some room for taskbar, dock, menubar, etc. If fitting comfortably within 1024x768 is impossible, then you should consider what will happen when the interface tab becomes scrollable and position widgets appropriately.

View not used?

If the model doesn't use the view, it's OK to make the view very short by setting screen-edge-y to 0, but don't try to make it super narrow by setting screen-edge-x to something tiny. It's better to let the 2D view have a reasonably normal width so there's room for the tick counter and so on. In the applet, the speed slider is in the gray strip at the top of the view, so that's another reason not to make it very narrow.

Patch size

Make the patch size a round number (e.g. 10.0 not 10.7). This can make the 2D view look a little nicer.

Turtle shapes

All shapes need names. There's no need to end shape names in "-shape", like "circle-shape"; just say "circle".

Naming

Name sliders and switches like this: leopard-spot-count, and not like leopardspotcount or leopardSpotCount or leopard_spot_count.

Switches (like all boolean variables) should have names ending in question marks, like this: grow-grass?.

Buttons and monitor allow a bit more flexibility in naming, since they have a separate "Display name" that can be different from the procedure called or the variable watched. Two main rules regarding those:

• Don't leave dashes in the display name: e.g., if you're monitoring a variable called maximum-speed, use "maximum speed" (or "Maximum Speed") as the display name.

• We don't have a single standard regarding capitalization. A button or monitor can be capitalized ("Maximum Speed") or not ("maximum speed"). The two rules we do have are:

  • Be consistent. Within the same model, either capitalize everything or nothing.
  • Never use ALL CAPS.

Widget sizing

Don't make widgets just-barely-wide-enough to display the text on them; leave some extra width, to allow for the different fonts on different operating systems. (You don't need to leave extra space between widgets, only inside widgets.) (If you want to really sure the text fits, the VM with the largest font seems to be on Linux, so you may want to test your model on that.)

Slider units

Use the "units" slot in sliders if appropriate to indicate what units the slider is in.

Default slider settings

Make sure the default slider settings are sensible (and match what is described in the info tab, if slider settings are discussed there).

All slider combinations work

Many models have setup procedures that take values from several sliders. In the past, modelers have written procedures that cause run-time errors for certain combinations of the slider values. The modelers missed these combinations, because there were so many possible combinations. If you are concerned that your model could have such a problem, one way to go about it is to run the model through BehaviorSpace, making sure that all the slider combinations are covered.

Monitors

Set the number of decimal places in monitors appropriately. (The default is 3, but in many cases 1 or 2 would be more appropriate.)

Action keys

Refrain from assigning such action keys to buttons unless the model will significantly benefit. Most of the time action keys are visual clutter.

Games, HubNet clients, and solo versions of HubNet activities are all good examples of where action keys are important.

Plotting

In general, you should not use plotting code inside the CODE tab. Instead, refer to the "5.0 Plotting" Style Guide and use the Plot Editor to manipulate your plots: http://ccl.northwestern.edu/netlogo/5.0/docs/interface.html#plots

In addition, plots should have readable titles (main and axes) and should generally include units. Try not to display too much information in a single plot. Remember, you can always add an additional plot.

Color blindness awareness

According to Wikipedia:

Color blindness affects a large number of individuals, with protanopia and deuteranopia being the most common types. In individuals with Northern European ancestry, as many as 8 percent of men and 0.4 percent of women experience congenital color deficiency.

That's a lot of potential NetLogo users!

Ideally, all of our models would be easily usable by people affected by various forms of color blindness. A lot of models in the library currently fall short of that standard. We should aim to do better for new models.

Here a few tips that can help:

• Don't rely solely on color to convey meaning. Shape is the most obvious alternative, but size and sometimes labels can also be used. Texture is also a good tool but can be hard to use in NetLogo.

• Ask a color blind person to test your model! Alternatively, you can use a software tool to simulate the effect of color blindness on your screen. I like http://colororacle.org/: it's open source and works on Mac, Windows, and Linux. This StackOverflow question has links to many other tools.

• Use a "color blind safe" color palette. http://colorbrewer2.org/ has a few and some of those are available in the Palette extension that is bundled with NetLogo.

• Read about it!