Assignment: Gallery System Design Sprint

Due: Next class meeting (April 13)
Format: Group work (3 teams), written deliverable + short presentation
Goal: Move from ideas to clear, implementable designs for the gallery systemGallery System Design Sprint – Summary

Team	Focus	Core Tasks	Deliverables
Team 1	Gallery Structure	Define and finalize `gallery.yaml` (rooms, walls, doors, windows). Ensure IDs and references are consistent. Add realistic constraints (usable walls, blocked space).	Complete `gallery.yaml` + short writeup of design decisions
Team 2	Evaluation (Scoring)	Define criteria (spacing, balance, theme, etc.). Design scoring function with weighted components. Specify required inputs.	Scoring model + clear pseudocode + explanation of components
Team 3	Generation (Layout)	Design how layouts are created (select + place artworks). Break into steps (selection, ordering, placement). Consider variability.	Algorithm description + pseudocode + design explanation

Overview

Over the next several days, each team will focus on a different core component of the gallery layout system:

Gallery Structure (Data Model)
Evaluation (Scoring)
Generation (Selection / Placement)

By the end, we should have:

a clean, consistent gallery model (gallery.yaml)
a well-defined evaluation approach (scoring function)
a clear algorithm for generating candidate layouts

These pieces will come together into a system we can implement.

Team Assignments

Team 1: Gallery Structure & YAML Model

Goal: Finalize the structure of gallery.yaml so it fully and clearly represents real gallery spaces.

Tasks

Complete the Gallery Model
- Define:
  - rooms
  - walls (with dimensions and properties)
  - doors (connecting rooms)
  - windows (blocking wall space)
- Ensure:
  - all IDs are consistent and unique
  - references (room_id, wall_id) are valid
Refine the Data Structure
- Decide what fields are necessary vs unnecessary
- Ensure everything is:
  - consistent
  - easy to read
  - easy for algorithms to use
Add Realistic Constraints
- What makes a wall usable?
- How do doors/windows affect available space?
- What metadata should walls include (displayable, height, etc.)?
Produce a Clean Example
- A complete gallery.yaml with:
  - at least 2 rooms
  - multiple walls per room
  - at least 1 door connecting rooms
  - at least 1 window

Deliverable

Final gallery.yaml
Short writeup (1–2 pages):
- key design decisions
- assumptions made
- anything still unclear or undecided

Team 2: Evaluation (Scoring Function)

Goal: Define how we score a given arrangement of artworks on a wall or across a room.

Tasks

Define Evaluation Criteria
Examples (you may refine or expand):
- spacing consistency
- visual balance
- thematic coherence
- color harmony
- focal distribution
- size compatibility
Define Data Inputs
- What data is needed from:
  - artworks (size, theme, intensity, etc.)
  - gallery (wall size, constraints, etc.)
  - layout (positions of artworks)
Design the Scoring Model
- Break into components: total_score =
  w1 * spacing_score +
  w2 * balance_score +
  w3 * theme_score +
  …
- Define:
  - each sub-score
  - how it is computed
  - expected range (e.g., 0–1)
Write Clear Pseudocode Example structure: function evaluate_layout(layout, artworks, gallery):
spacing_score = compute_spacing(layout)
balance_score = compute_balance(layout)
theme_score = compute_theme(layout, artworks) total =
w_spacing * spacing_score +
w_balance * balance_score +
w_theme * theme_score return total
Explain Tradeoffs
- What happens when criteria conflict?
- How sensitive is the system to weights?

Deliverable

Written scoring model
Clearly structured pseudocode
Explanation of each scoring component

Team 3: Generation (Selecting & Placing Artworks)

Goal: Design how the system constructs candidate layouts for a wall or room.

Tasks

Define the Problem Clearly
- Input:
  - available artworks
  - gallery structure
- Output:
  - a layout (positions + selected artworks)
Decide on Approach
Options include:
- greedy selection
- random generation
- constraint-based selection
- incremental placement (build left → right)
Break into Subproblems
- selecting which artworks to include
- ordering them
- placing them on a wall
- handling constraints (size, spacing, windows, etc.)
Write Pseudocode Example structure: function generate_layout(wall, artworks):
candidates = select_candidate_artworks(artworks) layout = empty_layout() for artwork in candidates:
position = find_valid_position(layout, artwork, wall)
if position is valid:
place artwork in layout return layout
Consider Variability
- How do we generate different layouts?
- How might this support:
  - hill climbing
  - simulated annealing (later)

Deliverable

Clear algorithm description
Pseudocode for generation
Explanation of choices and assumptions

Final Requirement (All Teams)

Each team must be prepared to:

Present (5–8 minutes)
- what you designed
- why you made those choices
- what still needs work
Submit written work
- clear, readable, structured
- not just notes — something another team could implement from

Big Picture

By the end of this assignment, we should have:

a complete data model (Team 1)
a clear evaluation function (Team 2)
a generation strategy (Team 3)

These will become the foundation for the next phase:
→ building and testing actual algorithms.

Deliverables & Expectations

Component	Requirement
Written Work	Clear, structured, and readable (not just notes)
Pseudocode	Required for Teams 2 & 3 (clear and implementable)
Presentation	5–8 minutes per team
Goal	Produce designs that can be implemented in code

Grading (100 pts)

Category	Points
Clarity & Organization	20
Completeness	25
Technical Soundness	25
Specificity (concrete, not vague)	20
Insight & Design Thinking	10