diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index ee232480d..cf003d814 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -51,9 +51,10 @@ SS14 By Example
   - [Porting Appearance Visualizers](en/ss14-by-example/making-a-sprite-dynamic/porting-appearance-visualizers.md)
 - [Basic Networking and You](en/ss14-by-example/basic-networking-and-you.md)
 - [Fluent and Localization](en/ss14-by-example/fluent-and-localization.md)
+- [UI and You](en/ss14-by-example/ui-and-you.md)
+  - [UI Cookbook](en/ss14-by-example/ui-and-you/ui-cookbook.md)
 - [UI Survival Guide](en/ss14-by-example/ui-survival-guide.md)
 
-
 Robust Toolbox
 ==============
 
@@ -79,6 +80,7 @@ Robust Toolbox
     - [Miscellaneous](en/robust-toolbox/toolshed/commands/misc.md)
   - [Toolshed Examples](en/robust-toolbox/toolshed/toolshed-examples.md)
 - [User Interface](en/robust-toolbox/user-interface.md)
+  - [Containers](en/robust-toolbox/user-interface/containers.md)
 - [IoC](en/robust-toolbox/ioc.md)
 - [Rendering]()
   - [Lighting and FoV](en/robust-toolbox/rendering/lighting-and-fov.md)
diff --git a/src/en/robust-toolbox/user-interface.md b/src/en/robust-toolbox/user-interface.md
index 29a999465..0e18e8c48 100644
--- a/src/en/robust-toolbox/user-interface.md
+++ b/src/en/robust-toolbox/user-interface.md
@@ -1,5 +1,9 @@
 # User Interface
 
+```admonish warning
+The information on this page may not completely conform to conventions in Space Station 14 code.
+```
+
 I can't be bothered to think of an elegant opening paragraph for this page. This is the UI tutorial.
 
 ```admonish info
@@ -142,26 +146,6 @@ There are other useful layout properties you can use to influence layout of an i
 * `SetSize`/`SetWidth`/`SetHeight`: Allows you to set a specific size for a control.
 * `Margin`: Allows you to set a margin of blank space around a control.
 
-## Layout Controls
-
-There are many controls whose sole purpose is to lay their children out in a certain way, and otherwise be invisible. This section will go over some of them.
-
-### `BoxContainer`
-
-`BoxContainer` is perhaps one of the simplest layout controls there is. It lays out its children sequentially in a certain `Orientation`, either vertically or horizontally. Controls do not overlap.
-
-### `GridContainer`
-
-`GridContainer` lays out its children in a configurable grid.
-
-### `ScrollContainer`
-
-TODO
-
-### `LayoutContainer`
-
-TODO
-
 ## Common Attributes
 These attributes are present on most layout controls.
 ### Margin
diff --git a/src/en/robust-toolbox/user-interface/containers.md b/src/en/robust-toolbox/user-interface/containers.md
new file mode 100644
index 000000000..1c0c2e651
--- /dev/null
+++ b/src/en/robust-toolbox/user-interface/containers.md
@@ -0,0 +1,72 @@
+# Container Controls
+
+There are many controls whose sole purpose is to lay their children out in a certain way, and otherwise be invisible. This section will go over some of them.
+
+This is not a complete list, but it does cover the most commonly used ones. If you would like to complete this list and PR it that would be appreciated :).
+
+## `BoxContainer`
+
+`BoxContainer` is perhaps one of the simplest layout controls there is. It lays out its children sequentially in a certain `Orientation`, either vertically or horizontally. Controls do not overlap.
+
+```admonish warning
+You MUST include a `Orientation` for the `BoxContainer` to work.
+```
+
+| Field                | Type                | Effective Default Value | Description                                                 |
+| -------------------- | ------------------- | ----------------------- | ----------------------------------------------------------- |
+| `Orientation`        | `LayoutOrientation` |                         | Whether to arrange the elements horizontally or vertically. |
+| `Align`              | `AlignMode`         |                         | The alignment of the children along the orientation axis.   |
+| `SeparationOverride` | `int`               | `0`                     | The separation between elements.                            |
+
+## `GridContainer`
+
+`GridContainer` lays out its children in a configurable grid.
+
+| Field                 | Type    | Effective Default Value | Description                                                                                                                    |
+| --------------------- | ------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| `Columns`             | `int`   |                         | The number of columns to organize the children into.                                                                           |
+| `Rows`                | `int`   |                         | The number of rows to organize the children into.                                                                              |
+| `MaxGridWidth`        | `float` |                         | The maximum width of the grid of elements, and dynamically determines the number of columns based on the size of the elements. |
+| `MaxGridHeight`       | `float` |                         | The maximum height of the grid, and dynamically determines the number of rows based on the size of the elements                |
+| `VSeparationOverride` | `int`   | `0`                     | The vertical separation between elements.                                                                                      |
+| `HSeparationOverride` | `int`   | `0`                     | The horizontal separation between elements.                                                                                    |
+| `ExpandBackwards`     | `bool`  | `false`                 | Whether to expand the grid backwards, i.e. from the bottom-right to the top-left.                                              |
+
+## `ScrollContainer`
+
+`ScrollContainer` is a container that shows a slice of its children, with scrollbars to scroll through the rest. You've seen a scrollbar before you know what this is.
+
+| Field                   | Type   | Effective Default Value | Description                                                                 |
+| ----------------------- | ------ | ----------------------- | --------------------------------------------------------------------------- |
+| `FallbackDeltaScroll`   | `bool` | `false`                 | If true, if we have a y-axis scroll it will convert it to an x-axis scroll. |
+| `ScrollSpeedX`          | `int`  | `50`                    | The scroll speed in the x-direction.                                        |
+| `ScrollSpeedY`          | `int`  | `50`                    | The scroll speed in the y-direction.                                        |
+| `ReserveScrollbarSpace` | `bool` | `true`                  | Whether the scrollbar will take up space in the layout                      |
+| `ReturnMeasure`         | `bool` | `false`                 | _TODO: I do not know what this does_                                              |
+| `VScrollEnabled`        | `bool` | `true`                  | Whether vertical scrolling is enabled.                                      |
+| `HScrollEnabled`        | `bool` | `true`                  | Whether horizontal scrolling is enabled.                                    |
+
+### `LayoutContainer`
+
+`LayoutContainer` helps in complicated layouts by arranging its children.
+
+| Field                 | Type    | Effective Default Value | Description                                                                                |
+| --------------------- | ------- | ----------------------- | ------------------------------------------------------------------------------------------ |
+| `AnchorBegin`         | `float` | `0`                     | The value of an anchor that is at the beginning of the layout.                             |
+| `AnchorEnd`           | `float` | `1`                     | The value of an anchor that is at the end of the layout.                                   |
+| `InheritChildMeasure` | `bool`  | `true`                  | If true, measurements of this control will be at least the size of any contained controls. |
+
+Then children of the `LayoutContainer` may use to following fields to control their layout:
+
+| Field            | Type    |
+| ---------------- | ------- |
+| `MarginLeft`     | `float` |
+| `MarginTop`      | `float` |
+| `MarginRight`    | `float` |
+| `MarginBottom`   | `float` |
+| `AnchorLeft`     | `float` |
+| `AnchorTop`      | `float` |
+| `AnchorRight`    | `float` |
+| `AnchorBottom`   | `float` |
+| `GrowHorizontal` | `bool`  |
+| `GrowVertical`   | `bool`  |
diff --git a/src/en/ss14-by-example/ui-and-you.md b/src/en/ss14-by-example/ui-and-you.md
new file mode 100644
index 000000000..4194cb135
--- /dev/null
+++ b/src/en/ss14-by-example/ui-and-you.md
@@ -0,0 +1,474 @@
+# UI and You
+
+Or how I learned to stop worrying and love Sheetlets.
+
+```admonish note
+The UI system in SS14 has been through several iterations, and much of the
+current UI code is very much antiquated. When creating UI, it is generally very
+helpful to reference other code, however when referencing code when making
+your UI, please keep the age of the code in mind.
+
+If you find some code that is not up to the current conventions, refactors are
+always appreciated!
+```
+
+Before learning how it should be done in SS14, it's important to understand how
+the engine handles UI. Please reference the [user interface documentation](../robust-toolbox/user-interface.md)
+first.
+
+## Okay, but how do I make it fancy?
+
+### `FancyWindow`
+
+`DefaultWindow` is depreciated. Unless you're making your own custom window,
+`FancyWindow` should be used in all circumstances. It has additional properties
+that integrate with SS14 better than `DefaultWindow`.
+
+The `Stylesheet` property allows you to give a window to take styles from a
+certain stylesheet. The default stylesheet is `Nanotransen`, but in certain
+circumstances you may want to use others. Currently there are the following
+stylesheets:
+
+-   `Nanotransen` - The default stylesheet. Used for any standard player-facing Uis
+-   `System` - Primarily used for admin and sandbox UIs
+-   `Syndicate` (COMING SOON™) - Used for any UIs affiliated with the syndicate
+
+### `StyleClass`
+
+Any styles classes that can be reused must be defined in `Content.Client/Stylesheets/StyleClass.cs`.
+This is to centralize the location of all available style classes, for ease of
+access and prevention of duplicate style classes.
+
+Any style classes that are generic / can be used for more than one element are
+defined at the top. For example, the style class `positive` affects `Button`,
+`Panel`, and `Label`.
+
+The rest of the style classes are defined for a specific generic UI element.
+Some common style classes are as follows:
+
+-   `OpenLeft`: Makes the button flat on its left side
+-   `OpenRight`: Makes the button flat on its right side
+-   `OpenBoth`: Makes the button flat on both sides; square
+-   `LabelSubtext`: Makes the label smaller and a more muted color
+-   `LabelKeyText`: Makes the label bold and a highlight color
+-   `LabelWeak`: Weak is the opposite of strong; makes the label a more muted color
+
+There are many more than this, but if you want to know exactly what a given label
+does, its as simple as looking at the field's usages, and reading the style rule definition.
+This is where it may be helpful to use the Rider IDE, as it has a fantastic implementation of this feature,
+but its probably possible in other IDEs as well.
+
+```admonish tip
+In general, if you are doing UI dev, I would recommend using the Rider IDE. It
+eats up quite a bit of RAM, but it provides autocomplete in XAML files, a lot
+of really nice auto-refactoring and searching features, and very decent git
+integration. Give it a shot!
+```
+
+## Writing Styles
+
+This section concerns style rules. For most UIs, editing these will be unnecessary,
+however you should ALWAYS prefer to use style classes instead of hardcoding colors
+or resources that could be commonly used.
+
+### All hail the mighty `Sheetlet`
+
+It's important to understand that basically, a stylesheet is a massive list of
+every single style rule. Instead of manually
+making a giant list of style rules (because that would be ridiculous... haha... ha....),
+the responsibility of chipping into this list is distributed between many Sheetlets.
+Each Sheetlet returns a small chunk of style rules, which is agglomerated into the
+final list at the end.
+
+```admonish note
+Previously every single style rule was in one giant list: `StyleNano.cs`, a 1600
+line pit of despair where dreams went to die.
+```
+
+There are, primarily, two types of Sheetlets:
+
+-   **Generic Sheetlets**: These go in `Content.Client/Stylesheets/Sheetlets`.
+    These stylesheets concern generic UI elements used in many different UIs, and
+    should be written generically to work with any stylesheet.
+-   **Specific Sheetlets**: These go along with the `*.xaml` files they are associated
+    with. These stylesheets concern UI elements that are specific to a single UI,
+    and should be written to work with the specific stylesheet they are associated
+    with.
+
+We will go into more detail about the specific conventions to follow for both of
+these later.
+
+All sheetlets should have the `[CommonSheetlet]` attribute. This is used so
+stylesheets can find all the sheetlets that have this attribute and add their
+styles to their list.
+
+```admonish tip
+Do not forget the `[CommonSheetlet]` attribute.
+```
+
+### Style Rules
+
+Each style rule
+has a few different components to it (This will look familiar to anyone who knows CSS):
+
+**The selector**: This limits the elements that a style rule can affect. This is
+made up of a few different parts:
+
+-   `Type`: The type of element this rule affects. Anything inheriting from this
+    type will be affected by this rule. This is similar to the element selector
+    in css.
+-   `StyleClasses`: The classes that the element must have to be affected by this
+    rule. The element must have all of these classes to be affected by this rule.
+-   `StyleIdentifier`: The identifier of the element. This is a unique identifier
+    that can be used to target a specific element. This should be used sparingly,
+    when there is only one instance of the element that needs to be styled in a
+    highly specific manner. There may only be one of these specified.
+-   `PseudoClasses`: These are special classes that can be used to target elements
+    in a specific state. For example, this is used to style buttons differently
+    when hovered or pressed or whatever.
+
+Selectors that specify more of these parts are more "specific", and will take
+priority over less specific elements.
+
+**The properties**: Any elements matching the selector will then have their properties
+modified by the style rule. These are the same properties you would define in
+the XAML.
+
+To assist with constructing these style rules, there are helper methods defined in
+`Content.Client/Stylesheets/StylesheetHelpers`.
+
+I think it's best to show an examples of style rules instead of describing all
+their intricacies since the code is pretty self-explanatory.
+
+```cs
+// you need this using statement to use the helper methods
+using static Content.Client.Stylesheets.Redux.StylesheetHelpers;
+
+var rules =
+[
+    // select any element...
+    E()
+        // ...with the class "negative"
+        .Class(StyleClass.Negative)
+        // ...and set its font color to the text color from the negative palette
+        .FontColor(sheet.NegativePalette.Text),
+
+    // select any `Label`...
+    E<Label>()
+        // ...with the class "LabelHeading"
+        .Class(StyleClass.LabelHeading)
+        // ...and set its font to a bold 16pt font
+        .Font(sheet.BaseFont.GetFont(16, FontKind.Bold))
+        // ...and its font color to the text color from the highlight palette
+        .FontColor(sheet.HighlightPalette.Text)
+
+    // select any `ContainerButton`...
+     E<ContainerButton>()
+        // ...with the class "button"
+        .Class(ContainerButton.StyleClassButton)
+        // ...and the class "ButtonSmall"
+        .Class(StyleClass.ButtonSmall)
+        // ...that is the parent of a `Label`,
+        .ParentOf(E<Label>())
+        // ...and set that `Label`'s font to an 8pt font
+        .Font(sheet.BaseFont.GetFont(8))
+];
+```
+
+### Death to Hardcoding!
+
+You may have noticed before that there wasn't much hardcoding in the rule definitions.
+This is because most style rules are used in multiple stylesheets, and they have
+to be generic between them. There are a couple different utilities used to reduce
+hardcoding.
+
+#### `ColorPalette`
+
+There is actually a pretty robust (haha) color palette system to hopefully make
+hardcoding colors unnecessary. I created a
+[codepen](https://codepen.io/aspiringLich/pen/VwOXdjd?editors=1000)
+to help visualize the colors. The stylesheets then use these palettes to set the following
+common palettes for sheetlets to reference:
+
+-   `PrimaryPalette`: Used for foreground elements
+-   `SecondaryPalette`: Used for Background elements
+-   `PositivePalette`: A traditionally green palette used to represent success / good / full
+-   `NegativePalette`: A traditionally red palette used to represent errors / bad / empty
+-   `HighlightPalette`: Used to highlight headings or important elements
+
+In C#, you access the colors by accessing the
+properties on the `ColorPalette` class. From brightest to darkest, the properties
+are (as of writing) arranged as so:
+
+-   `+0`: `Text` `Base`
+-   `-1`: `TextDark`, `Element`
+-   `-2`: `BackgroundLight`, `PressedElement`
+-   `-3`: `Background`
+-   `-4`: `BackgroundDark`, `DisabledElement`
+
+Although it would be simpler to have the palettes be arrays of colors, I noticed
+that colors were used in basically three ways: Text, foreground elements, and
+background elements. So I represented that in the palette itself! It just makes
+the code a bit more readable.
+
+All palettes are defined in `Palettes.cs` as static properties. You can read
+them from anywhere! Neat!
+
+#### `ISheetletConfig`
+
+`ISheetletConfig` is intended to cut down on repeated code by providing shared
+functionality and definitions between the stylesheets.
+Any `Sheetlet` that requires the values in some instance of
+`ISheetletConfig` should have a generic type constraint that requires the
+`ISheetletConfig` interface.
+
+```cs
+[CommonSheetlet] // don't forget `[CommonSheetlet]`!
+public sealed class ExampleSheetlet<T> : Sheetlet<T> where T : PalettedStylesheet, IExampleConfig
+```
+
+`ISheetletConfig` also serves as a dependency check. When the stylesheets pull
+all the sheetlets that have `[CommonSheetlet]`, they will first check that they
+satisfy the type constraint before adding the rules to the stylesheet.
+
+```admonish info
+A sheetlet failing to satisfy the type constraints of any stylesheet will cause
+the game to log an error. If your styles are not showing up, this may be why.
+```
+
+#### Resource Access
+
+You should access resources differently in sheetlets. Each stylesheet provides a
+list of resource roots to look in, when requesting a resource of a certain type.
+For example, the root for `NanotransenStylesheet` for `TextureResource` is
+`/Textures/Interface/Nano`. Any texture requested with `GetTexture` will will
+append the provided relative path to the root, and return the texture if it exists.
+
+This system is built to work with any resource type, though currently only textures
+are used in the sheetlets.
+
+### Generic Sheetlets
+
+As stated earlier, generic sheetlets are used for generic UI elements that are
+used in many different UIs.
+
+-   You should always select elements with `.Class` and not `.Identifier`.
+-   When accessing resources, use the `GetTextureOr` method to get the texture and
+    provide a fallback root to use if the texture is not found within the stylesheets roots.
+-   Avoid manual hardcoding of classes. When referencing classes,
+    please only use classes defined on the element being styled (in `StyleClass*` properties)
+    or define your own in `StyleClass.cs`.
+-   Avoid manual hardcoding of colors. Use the palettes provided by the stylesheet
+    to set the colors of elements. There are very few cases where you will actually
+    need to manually hardcode a color in a generic sheetlet.
+-   If you need to access a resource that is not provided already, please add the path
+    to the relevant `ISheetletConfig` or create a new one entirely.
+
+<details>
+<summary>Example Code (click to expand)</summary>
+
+```cs
+using Content.Client.Stylesheets.Redux.SheetletConfigs;
+using Content.Client.Stylesheets.Redux.Stylesheets;
+using Robust.Client.UserInterface;
+using Robust.Client.UserInterface.Controls;
+// you need to add this line manually to access the helper methods
+using static Content.Client.Stylesheets.Redux.StylesheetHelpers;
+
+namespace Content.Client.Stylesheets.Sheetlets;
+
+// MAKE SURE TO INCLUDE THE [CommonSheetlet] ATTRIBUTE
+[CommonSheetlet]
+// define the sheetlet and its dependencies
+public sealed class CheckboxSheetlet<T> : Sheetlet<T> where T : PalettedStylesheet, ICheckboxConfig
+{
+    public override StyleRule[] GetRules(T sheet, object config)
+    {
+        // cast the sheet into any of its required dependencies here
+        ICheckboxConfig checkboxCfg = sheet;
+
+        // get any textures / construct any complicated resources here
+        var uncheckedTex = sheet.GetTextureOr(checkboxCfg.CheckboxUncheckedPath, NanotrasenStylesheet.TextureRoot);
+        var checkedTex = sheet.GetTextureOr(checkboxCfg.CheckboxCheckedPath, NanotrasenStylesheet.TextureRoot);
+
+        // and finally, define all the style rules and return a big 'ol list of them
+        return
+        [
+            E<TextureRect>()
+                .Class(CheckBox.StyleClassCheckBox)
+                .Prop(TextureRect.StylePropertyTexture, uncheckedTex),
+            E<TextureRect>()
+                .Class(CheckBox.StyleClassCheckBox)
+                .Class(CheckBox.StyleClassCheckBoxChecked)
+                .Prop(TextureRect.StylePropertyTexture, checkedTex),
+            E<BoxContainer>()
+                .Class(CheckBox.StyleClassCheckBox)
+                .Prop(BoxContainer.StylePropertySeparation, 10),
+        ];
+    }
+}
+```
+
+</details>
+
+### Specific Sheetlets
+
+As stated earlier, specific sheetlets are used for UI elements that are specific
+to a single UI. These sheetlets are located with the `*.xaml` file they are
+associated with.
+
+-   You should prefer to select elements with `.Identifier` and not `.Class`.
+-   Any styles that COULD be used by another UI should be moved to a generic sheetlet.
+-   Hardcoding is more relaxed, you should still try and avoid it when possible, but
+    hardcoding `StyleClass`es and `StyleIdentifier`s is probably fine.
+-   If you REALLY need a specific resource and its not worth adding it to an
+    `ISheetletConfig` you can access it through `ResCache` as normal.
+-   You don't need to do the generic type constraints thing since the sheetlet
+    should be specific to a single UI, and thus a single stylesheet.
+
+<details>
+<summary>Example Code (click to expand)</summary>
+
+```cs
+using Content.Client.Resources;
+using Content.Client.Stylesheets.Redux;
+using Content.Client.Stylesheets.Redux.SheetletConfigs;
+using Content.Client.Stylesheets.Redux.Stylesheets;
+using Robust.Client.Graphics;
+using Robust.Client.UserInterface;
+using Robust.Client.UserInterface.Controls;
+// you need to add this line manually to access the helper methods
+using static Content.Client.Stylesheets.Redux.StylesheetHelpers;
+
+namespace Content.Client.Paper.UI;
+
+// MAKE SURE TO INCLUDE THE [CommonSheetlet] ATTRIBUTE
+[CommonSheetlet]
+// which stylesheet is this sheetlet for
+public sealed class PaperSheetlet : Sheetlet<NanotrasenStylesheet>
+{
+    public override StyleRule[] GetRules(NanotrasenStylesheet sheet, object config)
+    {
+        // define any IConfigs you need here
+        IWindowConfig windowCfg = sheet;
+
+        // get any textures / construct any complicated resources here
+        var paperBackground = ResCache.GetTexture("/Textures/Interface/Paper/paper_background_default.svg.96dpi.png")
+            .IntoPatch(StyleBox.Margin.All, 16);
+        var paperBox = new StyleBoxTexture
+            { Texture = sheet.GetTexture(windowCfg.TransparentWindowBackgroundBorderedPath) };
+        paperBox.SetPatchMargin(StyleBox.Margin.All, 2);
+
+        // and finally, define all the style rules and return a big 'ol list of them
+        return
+        [
+            E<PanelContainer>().Identifier("PaperContainer").Panel(paperBox),
+            E<PanelContainer>()
+                .Identifier("PaperDefaultBorder")
+                .Prop(PanelContainer.StylePropertyPanel, paperBackground),
+        ];
+    }
+}
+```
+
+</details>
+
+### Making your own `Stylesheet`
+
+Creating a new stylesheet is pretty simple, so I won't go into it too much.
+One thing to keep in mind is how colors are chosen.
+
+The colors are generated using the [OKLAB color space](https://bottosson.github.io/posts/oklab/),
+which is better because something something human eyes something. When you choose
+new colors for your stylesheet, it may be helpful to use an [OKLCH Color Picker](https://oklch.com)
+and modify an existing color.
+
+## Writing C# for UI
+
+> **TODO:** I don't feel confident enough in my knowledge to describe in detail
+> what to do and what not to do. This is just a general overview for now and
+> should be updated.
+
+The best way to learn how to write UI code is to look at existing code. Some UIs
+definitely do some terrible things you should never replicate, but there are mountains
+of terrible code in SS14, so this is not abnormal. I cannot teach familiarity with
+the internals of this game, but I can give a  general overview.
+
+Code you could reference:
+-    Robotics Console
+-    Cryo Pod
+-    Reagent Dispenser
+
+There are a few different parts to any UI. say were working with a entity
+called `MyThing`, which we wanted to show a UI for. Heres, generally, what the
+structure would look like:
+
+```yaml
+Content.Server/MyThing/:
+- Systems/:
+  - MyThingSystem.cs                # Inherits from `SharedMyThingSystem.cs`
+                                    # Takes the messages and makes changes in-world, and takes data from in-world to update the UI state.
+Content.Shared/MyThing/:
+- Components/:
+  - MyThingComponent.cs             # Defines the component for the entity
+- Systems/:
+  - SharedMyThingSystem.cs          # Controls the appearance data and general shared logic
+- SharedMyThing.cs                  # Defines the messages that can be sent between server and client, and the UI state
+
+Content.Client/MyThing/:
+- Ui/:
+  - MyThingWindow.xaml              # The main window, where the main structure of the UI is defined
+  - MyThingWindow.xaml.cs           # Defines behavior for `MyThingWindow.xaml`, reading in inputs and calling `Action`s
+  - MyThingBoundUserInterface.cs    # Interfaces with the server, sending messages and updating the UI state
+- Systems/:
+ - MyThingSystem.cs                 # Inherits from `SharedMyThingSystem.cs`
+                                    # Takes appearance data and makes in-world changes to reflect that
+```
+
+### Bound User Interfaces
+
+> **TODO:** someone more familiar with BUIs than me should write about how to write
+> good BUIs. I'll just stick the notes from
+> `#codebase-changes` by Bard in the discord here for now:
+>
+> > Predicted BUIs are in:
+>
+> For networking data:
+>
+> Option 1 (Preferred). Move the BUI state to component states. Use an existing client system / make one to handle updating the BUI upon the state updating (use TryGetOpenUi) and upon calling Open in the BoundUserInterface. See JukeboxSystem for an example, e.g.
+>
+> ```cs
+> private void OnJukeboxAfterState(Entity<JukeboxComponent> ent, ref AfterAutoHandleStateEvent args)
+> {
+>     if (!_uiSystem.TryGetOpenUi<JukeboxBoundUserInterface>(ent.Owner, JukeboxUiKey.Key, out var bui))
+>         return;
+>
+>     bui.Reload();
+> }
+> ```
+>
+> Option 2. Have the BUI control be a dummy until the state comes in
+>
+> For UIs:
+> Call TryOpenUi in shared where possible and the client should just handle it. Calling it from server will also still work similar to the old behavior.
+>
+> For messages:
+> Use SendPredictedMessage where possible in BUIs. At some point this will likely become the default over SendMessage.
+>
+> Overall:
+> Prefer to use the overloads that take in EntityUids instead of ICommonSession, this will make it easier to code NPCs who can interact with UIs in future.
+>
+> >
+>
+> -   There's a helper under this.CreateWindow<TWindow>() for BUIs that handles disposing + opening + close subscription for you.
+> -   There's a method OnProtoReload that gets called on BUIs so you can override and handle it without having to manually subscribe on another system.
+> -   I have added prototype reload support to some stuff.
+> -   I have cleaned up a lot of BUI code. Windows now just raise events and the BUI itself handles message sending.
+>
+> Some notes for future:
+>
+> -   You should spawn / delete control entities inside of EnteredTree and ExitedTree rather than inside Dispose.
+> -   Controls should be able to be constructed with an empty constructor and should not call BUI methods directly. This makes re-use significantly easier.
+> -   All new controls must handle prototype reloading if applicable.
+> -   All new controls should prefer to use component states and not BUI states where possible. These work better with prediction and are easier to use.
+> -   Controls should be able to handle components disappearing and not rely upon GetComponent<T> everywhere as there are no guarantees the component exists.
diff --git a/src/en/ss14-by-example/ui-and-you/ui-cookbook.md b/src/en/ss14-by-example/ui-and-you/ui-cookbook.md
new file mode 100644
index 000000000..d3d9be0e4
--- /dev/null
+++ b/src/en/ss14-by-example/ui-and-you/ui-cookbook.md
@@ -0,0 +1,45 @@
+# UI Cookbook
+
+This section concerns common UI patterns you may want to implement yourself.
+
+```admonish note
+If you've figured out something tricky with a UI, or if you just want to let people know
+something you made exists, considering sharing the wealth and adding it here!
+```
+
+## Status Colors
+
+`Palettes.Status` allows you to show the status of something with a color, (red = bad,
+amber = ok, green = good). You just need to give it a number between 0 and 1, and
+it will blend between the colors (using fancy OKLAB blending!!).
+
+```cs
+Palettes.Status.GetStatusColor(0.0f); // red
+Palettes.Status.GetStatusColor(0.5f); // amber
+Palettes.Status.GetStatusColor(1.0f); // green
+
+Palettes.Status.GetStatusColor(0.25f); // blends between red and amber
+// etc...
+```
+
+## Multiple Style Classes
+
+Lets say you want to add multiple style classes to an element. Well, lucky for you,
+arrays in XAML are easy-peasy to define!
+
+```xml
+<!-- stupid and bad, why would you ever think this would work?? -->
+<Control>
+    <Button StyleClasses="ButtonSmall negative" Text="delete" />
+</Control>
+
+<!-- the correct solution (obviously) -->
+<Control xmlns:sys="clr-namespace:System;assembly=System.Runtime">
+    <Button Text="delete">
+        <Button.StyleClasses>
+            <sys:String>ButtonSmall</sys:String>
+            <sys:String>negative</sys:String>
+        </Button.StyleClasses>
+    </Button>
+</Control>
+```
diff --git a/src/en/ss14-by-example/ui-survival-guide.md b/src/en/ss14-by-example/ui-survival-guide.md
index 5a0be70bb..18dc1bb89 100644
--- a/src/en/ss14-by-example/ui-survival-guide.md
+++ b/src/en/ss14-by-example/ui-survival-guide.md
@@ -1,5 +1,7 @@
 # UI Survival Guide
 
+{{ #template ../templates/outdated.md }}
+
 ## Learning to walk before you run
 So you have choosen to take on the harsh wasteland that is coding UI and working with Stylesheets?