The coding museum

Choose something you want to make, then choose a small question you can answer by trying it. “Can a visitor change this sentence?” is a useful first experiment. You can add complexity when you understand the first result.

This is an optional reference room for DIKULT105. Read it in any order. The controls are teaching demonstrations, not templates for assessed work. Nothing here adds another compulsory task or changes the official assessment rules.

Four places to know

Your folder contains your files. VS Code edits them. Your browser displays and runs the website. Your published address serves a particular uploaded version. A change in the editor does not automatically update all four.

Open the whole project folder in VS Code. Start with filenames you can recognise: index.html, styles.css, main.js and an assets folder. Check which file your preview is serving. Keep a working copy before a large experiment.

HTML gives content structure and meaning. CSS controls its presentation and layout. JavaScript adds programmed behaviour. They work together in the browser. You can make useful work with a small amount of each. MDN explains the web standards model.

Read a small page as a document

The <head> contains metadata such as the page title, viewport and stylesheet link. The <body> contains the visible content. Nest elements deliberately, close them correctly and give form controls labels. An id identifies one element; a class can identify a reusable group.

<link rel="stylesheet" href="styles.css">
<script src="main.js" defer></script>

These paths are relative to the HTML file. If a page moves into a subfolder, check its paths again. A plain, unstyled page often means the CSS did not load. Check that before changing the design.

Learn HTML structure with MDN. Try explaining your own document aloud: what is the main content, which heading introduces it, and which controls can someone use?

Understand the rule before adding another one

A selector chooses elements; declarations set their properties. In .caption { color: white; }, .caption selects a class and color changes its text colour. CSS decisions can inherit, compete or be overridden. When something looks wrong, inspect the element's matched and computed styles. Find the rule responsible before adding a new override.

More specific selectors can beat less specific ones. Source order resolves otherwise equal competing rules. Repeated !important declarations make the relationship harder to follow. Prefer a small set of intentional rules and local classes. MDN's cascade guide explains these conflicts.

The box model explains surprising gaps

Content sits inside padding, then a border, with margin outside. Check all four in the browser's box-model display. With box-sizing: border-box, a specified width includes padding and border. Use gap for space between flex or grid items so spacing decisions stay visible in one place.

Choose a layout system

Use normal document flow for reading. Try Flexbox when you want to arrange items along a row or column. Try Grid when relationships across rows and columns matter. Let text wrap, use a readable maximum width, and avoid setting a fixed height on a box that contains changing text.

Make the browser narrower while working. Add a media query where your composition needs to change, rather than choosing a device label first. Test long words, zoom and a real phone if one is available. A layout should still make sense when a font loads differently.

Save the decisions that define your style

When a version works, record a few choices: background, text colour, type family, spacing scale, borders and button behaviour. Store repeated values as custom properties and reuse a shared stylesheet across related pages. MDN documents CSS custom properties and their scope.

:root {
  --surface: #08090b;
  --text: #f1eadb;
  --space: 1.25rem;
}
.project-note {
  color: var(--text);
  background: var(--surface);
  padding: var(--space);
}

This is a practice example, not a required palette. Pick values that belong to your own work. Keep shared navigation, text and controls consistent. A particular artwork or blog post can have a different composition; scope its CSS to that page so its choices do not accidentally change every other page.

Reuse a pattern without freezing the work

Save a small component you understand: a caption, navigation item, accessible button or source note. Give it a descriptive class. Change the shared definition when you want all instances to change; add a named variation when the exception is intentional. Avoid copying an entire page of CSS for each new screen.

Write a plain sentence: “When this button is activated, add one visit and update the count.” That gives you an event, a value and a visible response. Test each part before adding another feature.

• Values and variables: text, numbers and true/false values describe the current situation. Use meaningful names. const prevents reassignment; let allows it.
• Functions: name a piece of behaviour you want to call again. Keep its purpose small enough to explain.
• Conditions: if chooses a path based on a test. What happens when the condition is false?
• Events: an event listener reacts to something such as a click or input. Native buttons already support keyboard activation.
• The DOM: JavaScript can select elements in the document and update them. Check that the element exists before using it.
• State and reset: decide what is remembered, for how long, and how someone can start again. A local variable, browser storage and a remote database are different choices.

Use textContent for plain text rather than interpreting someone's text as HTML. A working interaction should communicate its result, including when no change is possible. Think about the visitor who repeats the action, uses a keyboard, or returns after reloading. MDN's JavaScript learning material develops these skills step by step.

A transition can show a change between states. A keyframe animation can describe a sequence. JavaScript can decide when a sequence starts or responds to an action. Choose the simplest method that expresses the idea.

Try a slow cycle and a fast cycle in the workbench. Does the movement suggest a living thing, a warning, a machine or a distraction? Duration, repetition and distance carry meaning. Keep important instructions readable while objects move.

• Give continuous decorative motion a pause control. Avoid flashing effects.
• Keep the full information and usable controls when movement is off.
• Respect prefers-reduced-motion. Test the reduced version, rather than assuming an animation setting fixes every issue.
• Use movement to communicate a response; do not rely on movement alone to communicate success or failure.

The hosts above use the lab’s original punched-card and tape-machine animations. The time machine offers the historical route. See MDN’s reduced-motion explanation for implementation details.

Learn a few commands you use every day. Shortcuts can differ with keyboard layout, operating system and custom keybindings; the Command Palette is another way to find them. VS Code is the editor, not Visual Studio.

Check the official keybindings and editing guide. Operating-system shortcuts can intercept a key combination.

A setup you can understand

1. Open a folder. See the project's structure in Explorer. Avoid editing a second copy with the same filename by accident.
2. Keep the browser beside the editor. Save, reload and observe. Know whether your preview updates automatically or needs a reload.
3. Use formatting. Format Document makes nesting easier to inspect. Format on Save is optional. Formatting helps readability; it does not prove the code is correct.
4. Use Problems as a starting point. Read the message and follow its location. Check the running page too; an editor cannot discover every runtime or design problem.
5. Rename deliberately. Rename Symbol can update recognised references. Review the diff; a filename or a class inside a separate HTML file may still need attention.
6. Search before replacing. Look through matches in the project. Limit the replacement to the files or selection you intend to change.
7. Save tiny repeatable patterns. VS Code's user snippets can expand a pattern you understand. A project snippet file can keep the same caption or source-note structure within one project. Official snippet instructions explain setup.
8. Keep extensions purposeful. Add one because it solves a problem you have. Know what changes your formatting, preview or code suggestions.

A reliable working loop

Write the next visible change in one sentence. Save the current version. Edit a small part. Run it. Check the intended path and an unexpected one. Review the diff and keep a version you can return to. Finish by naming the next step, not by leaving five half-understood changes together.

With Git, inspect Source Control changes and make a commit when a meaningful step works. Without Git, keep a dated backup outside the active project. Neither method replaces checking that your exported or published version actually opens.

1. Describe the trigger. Which page, action and screen size produced the problem?
2. Compare expectation and result. “I expected the count to become 1. It stayed 0.”
3. Check the first useful error. Read the message, filename and line. Later errors may follow from the first failure.
4. Check Network. Did the HTML, stylesheet, script and assets load? A 404 means a requested resource was not found.
5. Inspect the smallest relevant part. Confirm the selected element or event, then the value and the result.
6. Change one cause and retest. Save a working checkpoint. If the change fails, undo it and keep your observation.

When asking for help, bring the file, the exact message, what you tried, and one reproducible action. You do not need to pretend you understand a broken system. Explaining the uncertainty clearly is part of technical and academic work.

A late first image, jerky movement and delayed typing can have different causes. Choose a particular action and device, observe the delay, then compare the same action after a change. Keep your artistic intention in view.

• Loading: inspect Network for large images, video, missing files and unnecessary requests. Make image dimensions appropriate to their displayed use. Keep originals separately; export smaller versions for thumbnails.
• Movement: record a short interaction in the browser's Performance panel. Look for time spent in script, layout and painting. Test a simpler version to isolate the expensive part.
• Effects: compare costly-looking layers, full-screen blur, shadows and many moving objects individually. Keep the effect that serves the work, and measure its cost on a modest device.
• Background work: avoid running needless repeated tasks. The Page Visibility API can tell your code when the page is hidden. Design a safe way to resume.
• Repeatability: test the same page, action and conditions. One fast reload from a warm cache does not prove a first visit will be fast.

Use the Chrome Performance reference, its Rendering tools and MDN's Page Visibility guide as technical references. Keep a short before/after note rather than claiming a universal speed improvement.

“AI slop” is a useful concern when a polished result avoids the particular idea, person or evidence it is supposed to represent. A font, colour or neat layout alone cannot tell you whether something was made with AI. Look at purpose, accuracy and working behaviour.

• Copy: could this description fit almost any project? Replace a vague claim with the actual material, action or finding.
• Visual decisions: do the repeated cards, effects and icons help this work, or simply fill space? Remove one and check whether anything meaningful is lost.
• Interaction: follow every link and activate every control. A polished surface can conceal dead ends, fake state and inaccessible actions.
• Code: can you explain the main rule? Look for duplicated handlers, unused styles, inconsistent names and dependencies nobody needed.
• Evidence: open the reference. Does it exist, support the claim, and identify its author? Check dates, permissions and image credits.
• Ownership of decisions: can you explain what you changed after a test and why? Keep a process record with specific observations.

During practice where AI is explicitly allowed, ask for a bounded explanation, inspect the proposed change and test its claims yourself. Follow the assessment rules at the beginning of this guide.

Try this critique with a partner: “The work seems to ask ____. This choice helps because ____. This part is unclear because ____. One test would be ____.” Talk about the work and the evidence, rather than guessing how someone made it.

Keep a small process note: intention, choice, test, observation and next step. An unsuccessful test is useful when you can show what it revealed. Choose a term or reading that helps explain the encounter you are building, then check that connection against the actual work.

The academic library connects genres, examples, research questions, source evaluation and Chicago author-date guidance. The final guide explains the creative work, text, walkthrough and submission route. Consult the official brief and Mitt UiB for assessment requirements and deadlines.

The history behind the imagined hosts

Ada Lovelace's 1843 notes on the proposed Analytical Engine explored how operations could work with symbols and included the Bernoulli-number procedure. Read her published notes and the Computer History Museum's account. Alan Turing's 1936 work described a mathematical model of computation; the Turing Digital Archive provides the paper and context.

The hosts' conversation and shared laboratory are fiction written for this teaching page. They are not quotations, a historical meeting, or claims that either person invented HTML, CSS or JavaScript. Use the history to ask better questions about today's tools.

Return to Friday's Future lab · All guides · Enter the time machine