andrew/portfolio
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Minor fixes with the TOC nav, clarifications in values page, adds footnote links to values

Browse source
This commit is contained in:
Andrew Gioia 2026-05-11 14:19:50 -04:00
commit 094ce698fe
Signed by: andrew
GPG key ID: FC09694A000800C8
2 changed files with 21 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

28
assets/css/site.css
View file

@ -74,6 +74,15 @@ a {
&[in] {
text-decoration-style: dotted;
}
&.fn {
text-decoration: none;
&.sect {
font-size: 0.7rem;
vertical-align: super;
}
}
}
h1 {
@ -116,7 +125,7 @@ h4 {
code {
font-size: 0.875rem;
background: var(--light);
background: rgba(0, 0, 0, 0.1);
border-radius: 3px;
padding: 0.125rem 0.25rem;
}
@ -468,15 +477,6 @@ main {
font-size: 1.1rem;
}
a.fn {
text-decoration: none;
&.sect {
font-size: 0.7rem;
vertical-align: super;
}
}
section {
width: 100%;
@ -1669,14 +1669,14 @@ body.simple {
flex-direction: column;
> li {
padding: 0.4rem 0 0 0.5rem;
padding: 0.45rem 0 0 0.5rem;
a {
margin-left: 0.25rem;
}
&:first-child {
border-top: 1px solid var(--faded);
border-top: 1px solid var(--black);
}
&:last-child {
@ -1688,14 +1688,14 @@ body.simple {
li {
height: 2.5rem;
overflow: hidden;
padding: 0.4rem 0 0;
padding: 0.5rem 0 0;
text-indent: 0.25rem;
/* group <li> is a list item again */
&.group {
height: auto;
display: list-item;
padding: 0.4rem 0 0;
padding: 0.5rem 0 0;
a {
display: inline-block;

12
content/values.md
View file

@ -10,10 +10,12 @@ header:
title: "Design"
url: "/values/"
footnotes:
- symbol: "&dagger;"
- id: "fn1"
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."
- id: "fn2"
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 schema or how a backend engineer implements a feature in the codebase, 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.
@ -22,7 +24,7 @@ footnotes:
<em>Good interfaces should respect the user and their device.</em> The browser, HTML, and CSS are already an extraordinarily capable platform, and I try to stay as close to browser-native as possible. If something can be done well with HTML and CSS, I will always do that rather than rely on JavaScript as a crutch.
I am not opposed to frameworks or complex client-side applications when they're justified, I just think they rarely are and too often introduce more usability, accessibility, and performance problems than the ones they solve. **JavaScript should enhance an experience, not become a requirement** by default.&dagger;
I am not opposed to frameworks or complex client-side applications when they're justified, I just think they rarely are and too often introduce more usability, accessibility, and performance problems than the ones they solve. **JavaScript should enhance an experience, not become a requirement** by default.<a href="#footnotes" id="fn1" class="fn">&dagger;</a>
<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 anachronisms&mdash;**they are a foundational part of the user experience**.
@ -36,4 +38,4 @@ I am not opposed to frameworks or complex client-side applications when they're
<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.
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**.<a href="#footnotes" id="fn2" class="fn">&ddagger;</a> I rely on it and a product team should respect it.