Fixes header on all pages to handle titles better; cleans up design values doc

content/values.md

@@ -3,9 +3,15 @@ title: "Design philosophy"
 layout: "document"
 slug: "values"
 summary: "<span color=\"blue\"><strong>How I think about design</strong></span>, particularly for the browser, and the values I hold close. Good design can't happen without <span color=\"red\"><strong>respect for the user</strong></span> and their device. <span color=\"yellow\"><strong>Taste and personality matter.</strong></span>"
+header:
+  page:
+    title: "Design"
+    url: "/values/"
 footnotes:
   - symbol: "&dagger;"
     note: "There are exceptions, especially for truly application-like experiences, but my default position is progressive enhancement whenever possible."
+  - symbol: "&ddagger;"
+    note: "The design team's taste is part of what they offer the organization. More importantly, they offer expertise in user interaction design and the art and science behind the user experience. It would be silly for me as a designer to offer an opinion on database design or how a backend engineer implements a feature, and even sillier to demand that it be implemented the way I think best."
 ---
 
 <em>I design for the browser first.</em> This is true even in an age of mobile-first and push-them-to-the-app-at-all-costs. I think the web browser is a great equalizer and perhaps the greatest preserver of the open internet. 
@@ -18,12 +24,12 @@ I am not opposed to frameworks or complex client-side applications when they're
 
 <em>That same respect extends to semantics, controls, and data structures.</em> A button should be a button. A checkbox should be a checkbox. Tabular data should (almost always) be shown in a table. I don't believe in reinventing familiar controls when the native version already communicates the right thing and behaves the way users expect. **Page load times, payload size, and memory use all matter too.** These are not just engineering's job or an anachronism&mdash;**they are a foundational part of the user experience**.
 
-<em>I don't believe products need to wait for perfect alignment before they improve.</em> Some of the most harmful thinking on product teams comes from the idea that everything has to be redesigned at once in order to be worth doing. Consistency matters, but so does momentum. If something is broken, **it's often better to make it better now than to wait for the ideal future state that may never arrive**. Many interfaces stay bad for years because teams are too concerned with doing every related piece at the same time.
+<em>I don't believe products need to wait for perfect alignment before they improve.</em> Some of the most harmful thinking on product teams comes from the idea that everything has to be redesigned at once in order to be worth doing. Consistency matters, but so does momentum. If something is broken, **it's often better to fit it now than to wait for the ideal future state that may never arrive**. Many interfaces stay bad for years because teams are too concerned with doing every related piece at the same time.
 
-<em>Good design starts from a strong brief.</em> Every good design effort needs a clear understanding of the users, the problems that need to be solved, and the constraints that shape the solution. On larger teams especially, the brief is what keeps the work focused when there are tons of opions or when strong personalities have outsized influence. **Designers should be part of that conversation early.** The quality of the brief often determines the quality of everything that follows.
+<em>Good design starts from a strong brief.</em> Every good design effort needs a clear understanding of the users, the problems that need to be solved, and the constraints that shape the solution. On larger teams especially, the brief is what keeps the work focused when there are tons of opinions or when strong personalities have outsized influence. **Designers should be part of that conversation early.** The quality of the brief often determines the quality of everything that follows.
 
 <em>I prefer interfaces that are minimal, but not anonymous.</em> White space, alignment, and typography can solve tons of visual problems. At the same time, software should not lose all of its personality in some quest for minimalism. An app can be clean, efficient, and out-of-the-way while still feeling specific to the team, company, or people who made it. Off the shelf systems like shadcn are amazing but **every app doesn't need to look the same.** Minimalism is the best place to start, and keeping it as a goal can prevent a design from getting unweildy.
 
 <em>Type is just as much a part of the design as everything else.</em> I often design around or with the words on the screen, and it's OK to add another line of text or force everything to be a single line when it makes the design and usability better.
 
-<em>Finally, design benefits from collaboration, but not from design by committee.</em> Everyone has opinions about interfaces because everyone uses them. That's normal and useful! **But not every opinion should carry the same weight**, and not every preference should become a product decision. Good design requires judgment: knowing when to listen, when to test, when to defend a choice, and when to change course. My job is not to impose my taste by fiat&mdash;**my job is to make informed decisions in service of the user and the product&mdash;but my taste as the designer <em>does</em> matter** and I will rely on it.
+<em>Finally, design benefits from collaboration, but not from design by committee.</em> Everyone has opinions about interfaces because everyone uses them. That's normal and useful! **But not every opinion should carry the same weight**, and not every preference should become a product decision. Good design requires judgment: knowing when to listen, when to test, when to defend a choice, and when to change course. My job is not to just impose my taste by fiat&mdash;**my job is to make informed decisions in service of the user and the product&mdash;but my taste as the designer <em>does</em> matter**&ddagger; and I will rely on it.

layouts/_default/baseof.html

@@ -27,19 +27,33 @@
     {{ end }}
   </head>
   <body id='{{ with .Slug }}{{ . }}{{ else }}default{{ end }}'>
+    {{- $pageLabel := "" -}}
+    {{- $pageHref := "" -}}
+    {{- if and .IsPage (eq .Section "studies") -}}
+      {{- $pageLabel = "Case study" -}}
+      {{- $pageHref = "/#studies" | relURL -}}
+    {{- end -}}
+    {{- with .Params.header.page -}}
+      {{- with .title -}}
+        {{- $pageLabel = . -}}
+      {{- end -}}
+      {{- with .url -}}
+        {{- $pageHref = . | relURL -}}
+      {{- end -}}
+    {{- end -}}
     <header>
       <div class="title">
         <a class="logo" href="{{ "/" | relURL }}">
-          {{- if and .IsPage (eq .Section "studies") -}}
+          {{- if $pageLabel -}}
           <span class="tablet-hide">AG</span>
           <span class="tablet-show">Andrew Gioia</span>
           {{- else -}}
           <span>Andrew Gioia</span>
           {{- end -}}
         </a>
-        {{- if and .IsPage (eq .Section "studies") -}}
-        <a class="page" href="{{ "/#studies" | relURL }}">
-          Case study
+        {{- if $pageLabel -}}
+        <a class="page" href="{{ $pageHref }}">
+          {{ $pageLabel }}
         </a>
         {{ end }}
       </div>
@@ -71,4 +85,4 @@
       {{ partial "footer.html" . }}
     </footer>
   </body>
-</html>
+</html>