Release 2026 redesign

.editorconfig

@@ -0,0 +1,11 @@
+# http://editorconfig.org
+root = true
+
+[*]
+charset = utf-8
+end_of_line = lf
+indent_style = space
+indent_size = 2
+insert_final_newline = true
+trim_trailing_whitespace = true
+max_line_length = 100

.env.example

@@ -0,0 +1 @@
+DRIZZLE_DATABASE_URL=YOUR_DATABASE_URL

.github/workflows/ci.yml

@@ -0,0 +1,26 @@
+name: CI
+
+on:
+  pull_request:
+  push:
+    branches: [main, next]
+
+permissions:
+  contents: read
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: 1.4.0
+
+      - run: bun install --frozen-lockfile
+      - run: bunx next typegen
+      - run: bun run lint
+      - run: bun run typecheck

.gitignore

@@ -34,3 +34,9 @@ yarn-error.log*
 # typescript
 *.tsbuildinfo
 next-env.d.ts
+
+# content collections
+.content-collections
+
+# claude
+.claude

.prettierrc

@@ -1,7 +1,11 @@
 {
+  "printWidth": 120,
   "semi": false,
   "trailingComma": "all",
   "singleQuote": true,
   "tabWidth": 2,
-  "useTabs": false
-}
+  "useTabs": false,
+  "plugins": [
+    "prettier-plugin-tailwindcss"
+  ]
+}

README.md

@@ -1,44 +1,55 @@
 # evowizz.dev
 
-This repository hosts the source code for my personal website.
+The source for [evowizz.dev](https://evowizz.dev), my personal website and writing archive. It is built with Next.js, React, Tailwind CSS, Content Collections, Drizzle ORM, and Neon Postgres.
 
-## Getting Started
+## Local development
 
-To get a local copy up and running, follow these simple steps:
+You need [Bun](https://bun.sh) and Node.js 24.
 
-1. Clone the repository:
-```bash
-git clone https://github.com/evowizz/evowizz.dev.git
-```
+1. Clone the repository and enter it:
+
+   ```bash
+   git clone https://github.com/evowizz/evowizz.dev.git
+   cd evowizz.dev
+   ```
 
 2. Install the dependencies:
-```bash
-bun install
-```
 
-3. Run the development server:
+   ```bash
+   bun install
+   ```
+
+3. Create the local environment file:
+
+   ```bash
+   cp .env.example .env.local
+   ```
+
+4. Set `DRIZZLE_DATABASE_URL` in `.env.local` to a Postgres connection string, then apply the schema:
+
+   ```bash
+   bun run db:migrate
+   ```
+
+5. Start the development server on [localhost:3000](http://localhost:3000):
+
+   ```bash
+   bun run dev
+   ```
+
+## Quality checks
+
+Run the same checks as CI before opening a pull request:
+
 ```bash
-bun dev
+bun run lint
+bun run typecheck
 ```
 
 ## Contributing
 
-At the moment, no new features are being accepted. However, if you find a bug or have a suggestion, feel free to open an issue.
+New features are not currently being accepted, but bug reports and focused fixes are welcome. Please open an issue before larger changes.
 
 ## License
 
-```text
-Copyright 2024 Dylan Roussel
-
-Licensed under the Apache License, Version 2.0 (the "License");
-you may not use this file except in compliance with the License.
-You may obtain a copy of the License at
-
-    http://www.apache.org/licenses/LICENSE-2.0
-
-Unless required by applicable law or agreed to in writing, software
-distributed under the License is distributed on an "AS IS" BASIS,
-WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-See the License for the specific language governing permissions and
-limitations under the License.
-```
+Licensed under the [Apache License 2.0](LICENSE).

content-collections.ts

@@ -0,0 +1,127 @@
+import { Context, defineCollection, defineConfig, Meta } from '@content-collections/core'
+import { z } from 'zod'
+import { compileMDX } from '@content-collections/mdx'
+import rehypePrettyCode from 'rehype-pretty-code'
+import rehypeSlug from 'rehype-slug'
+import remarkGfm from 'remark-gfm'
+import { getColor } from 'colorthief'
+import path from 'path'
+import { argbFromRgb, hexFromArgb, Variant } from '@evowizz/material-color-utilities-canary'
+
+const VARIANT_MAP: Record<string, Variant> = {
+  monochrome: Variant.MONOCHROME,
+  neutral: Variant.NEUTRAL,
+  tonal_spot: Variant.TONAL_SPOT,
+  vibrant: Variant.VIBRANT,
+  expressive: Variant.EXPRESSIVE,
+  fidelity: Variant.FIDELITY,
+  content: Variant.CONTENT,
+  rainbow: Variant.RAINBOW,
+  fruit_salad: Variant.FRUIT_SALAD,
+}
+
+type VariantName = keyof typeof VARIANT_MAP
+const VARIANT_NAMES = Object.keys(VARIANT_MAP) as [VariantName, ...VariantName[]]
+
+type TransformInput = {
+  _meta: Meta
+  content: string
+  themeColor?: string
+  themeVariant?: VariantName
+  image?: string
+}
+
+async function transform<T extends TransformInput>(document: T, context: Context) {
+  const mdx = await compileMDX(context, document, {
+    remarkPlugins: [remarkGfm],
+    rehypePlugins: [
+      rehypeSlug,
+      [
+        rehypePrettyCode,
+        {
+          theme: {
+            light: 'github-light',
+            dark: 'dark-plus',
+          },
+          keepBackground: false,
+        },
+      ],
+    ],
+  })
+
+  let themeColor = document.themeColor
+  if (!themeColor && document.image) {
+    themeColor = (await extractColorFromImage(document.image)) ?? undefined
+  }
+
+  // Without a color, ThemeOverride keeps the site theme, so the variant stays unset too.
+  let themeVariant = document.themeVariant ? VARIANT_MAP[document.themeVariant] : undefined
+  if (themeVariant === undefined && themeColor) {
+    themeVariant = Variant.TONAL_SPOT
+  }
+
+  return {
+    ...document,
+    slug: document._meta.path,
+    themeColor,
+    themeVariant,
+    mdx,
+  }
+}
+
+const posts = defineCollection({
+  name: 'posts',
+  directory: 'content/posts',
+  include: '**/*.mdx',
+  schema: z.object({
+    title: z.string(),
+    publishedAt: z.string(),
+    summary: z.string(),
+    content: z.string(),
+    image: z.string().optional(),
+    themeColor: z.string().optional(),
+    themeVariant: z.enum(VARIANT_NAMES).optional(),
+    hidden: z.boolean().default(false),
+  }),
+  transform,
+})
+
+const caseStudies = defineCollection({
+  name: 'caseStudies',
+  directory: 'content/case-studies',
+  include: '**/*.mdx',
+  schema: z.object({
+    title: z.string(),
+    overview: z.string(),
+    stack: z.array(z.string()),
+    role: z.string().optional(),
+    image: z.string(),
+    themeColor: z.string().optional(),
+    themeVariant: z.enum(VARIANT_NAMES).optional(),
+    content: z.string(),
+    hidden: z.boolean().default(false),
+  }),
+  transform,
+})
+
+export default defineConfig({
+  content: [posts, caseStudies],
+})
+
+async function extractColorFromImage(imagePath: string): Promise<string | null> {
+  if (imagePath.startsWith('http') || imagePath.startsWith('/api/')) {
+    return null
+  }
+
+  try {
+    const fullPath = path.join(process.cwd(), 'public', imagePath)
+    // colorthief v3 quantizes in OKLCH by default, so pin to rgb to match prior output
+    const color = await getColor(fullPath, { colorSpace: 'rgb' })
+    if (!color) return null
+    const { r, g, b } = color.rgb()
+    return hexFromArgb(argbFromRgb(r, g, b))
+  } catch (error) {
+    console.warn(`Failed to extract color from ${imagePath}:`, error)
+    return null
+  }
+}

content/case-studies/inware.mdx

@@ -0,0 +1,89 @@
+---
+title: 'Inware 7'
+overview: 'Designing a clearer way to explore everything Android can tell you about a device.'
+stack: ['Material 3', 'Kotlin', 'Jetpack Compose', 'Navigation 3']
+role: 'Design and development'
+image: '/content/case-studies/inware/hero.png'
+themeColor: '#33CC7A'
+themeVariant: 'rainbow'
+---
+
+Inware 7 is a complete overhaul of my Android device information app. It shipped in April 2026 and has kept moving since. It's the completion of the <Tooltip content="Android's modern toolkit for building interfaces entirely in Kotlin.">Jetpack Compose</Tooltip> transition, and a complete <Tooltip content="The latest, more expressive evolution of Google's Material Design language.">Material 3 Expressive</Tooltip> redesign. I had no specific design in mind, only certain constraints. Every decision was implemented and tested live on a device so the motion could be judged for real, whether by me or by testers. That is how I made sure Inware felt right.
+
+## Jetpack Compose
+
+I started fiddling with Jetpack Compose in 2019, and tracked its progress ever since. In 2020, before Compose was even stable, I published [compose-to-edge](https://github.com/evowizz/compose-to-edge), a small library for going edge-to-edge in Compose apps. In 2022, I started implementing Compose in Inware: I knew Google was betting on it. It was showing up in Android itself, in Settings and SystemUI, and Google had built Now in Android, a reference app written with it. So while Android Views were still used at the time, Compose was a modern toolkit that was actively being used and developed. By the last 6.x release, various components of Inware were already Compose, but it was still a hybrid app.
+
+Inware 7 is the first version fully written in Compose, a decision Google confirmed earlier in 2026, when [Android UI officially went Compose first](https://android-developers.googleblog.com/2026/05/android-ui-development-is-compose-first.html).
+
+## From 6 to 7
+
+For years, Inware relied on Overpass Mono as its brand font. The font, along with the cards of the home screen, made Inware easy to recognize up to version 6. With Inware 7, things changed. While the brand color remains `#33CC7A` and <Tooltip content="An Android feature that recolors apps with a palette taken from the wallpaper or picked by the user.">dynamic colors</Tooltip> are still supported, Google Sans Flex now replaces Overpass Mono. It is a variable font with many axes to tune, it is visually balanced, and it is the font Pixel devices use, so it feels at home on Android. Users who would rather not have it can switch to the system font in the settings. The cards are also gone. The refresh went all the way down to the app icon and the splash screen.
+
+![The Inware 6 and Inware 7 app icons side by side](/content/case-studies/inware/inware-logos.png 'The Inware 6 icon on the left, the Inware 7 icon on the right.')
+
+Inware is represented by a chip as its icon, and the new logo introduced with version 7 keeps it. The old logo was a good one, but it felt too generic, too simple. And as the app evolves, so should the logo. We're entering an era where modern logos use gradients: Android app icons are getting redesigned all over the place, and as Inware is built to fit Android, its logo should follow. The changes remain small: a grid as the background, smoothed corners, tweaked colors, etc. So Inware remains easy to identify, but feels modern.
+
+Inware is made to embrace Android: it follows Material closely, and it should feel like it belongs on the device it describes. This is why dynamic colors are enabled by default. Like the system, the app can take the colors of the wallpaper. Dynamic colors are only as good as the device's implementation, though. On a Pixel, they behave the way Material intends. On Samsung's One UI, they are more of an adventure. Fixing that is on Samsung, not on apps, so Inware simply lets users turn dynamic colors off.
+
+![The Inware 6 and Inware 7 home screens side by side](/content/case-studies/inware/home.png 'Inware 6 on the left, Inware 7 on the right')
+
+The home screen of Inware 6 was a grid of large cards, each showing an icon and a name. The cards did not describe the pages behind them, so the only way to know what a page contained was to open it.
+
+In Inware 7, every destination is still there, but each one now has a description. And above the list, a dashboard shows a few live values, through tiles that users can pick and arrange themselves.
+
+## Navigation
+
+![The floating toolbar from the Inware 7 beta](/content/case-studies/inware/toolbar.png 'The floating toolbar, as it appeared in the beta.')
+
+The home screen did not start out as a single screen. Initially, the dashboard, the explore page with the list of destinations, and the settings were three separate pages. The plan was to move between them with a Navigation Drawer, but I switched away from it before it was ever released: in a drawer, the dashboard would have been yet another page in a list, sitting somewhere between Device and Hardware. A floating toolbar at the bottom took its place. It worked well.
+
+A dedicated dashboard page had room to preview a lot more tiles as soon as the app opened. But testers highlighted how it became harder for them to quickly jump to a specific data page.
+
+One way to do that would have been to make the explore page the default, or to make the default page configurable. But in both cases, the dashboard page would have become less useful. Instead, I merged both pages into a single screen, and one of my favorite components made it possible: the Backdrop.
+
+The dashboard became a back layer of live data, the destinations became a front layer that you can drag over it, and the settings moved into a button at the top. The Backdrop was released in beta, and people quickly preferred it to the toolbar.
+
+## Dashboard
+
+![A close-up of the Inware 7 tiles](/content/case-studies/inware/tiles.png 'Four tiles on the first page of the dashboard.')
+
+The dashboard is made of tiles. Each of its pages contains four of them. When four tiles are not enough, additional pages are just a swipe away. Every tile has the same size, which allows the grid to adapt to any screen without the tiles having to change. However, not everyone cares about the same data, which is why users can also customize their dashboard.
+
+![The edit dashboard, with the tile catalog below the grid](/content/case-studies/inware/edit.png 'The edit screen, with the catalog of unused tiles below the grid.')
+
+In edit mode, users can reorder tiles, add them, or remove them. Tiles that are not in use sit in a catalog below the grid, grouped by destination. You can't really break anything while editing. An undo button shows up after your first change and reverts changes one by one, and the reset button stays disabled until the dashboard no longer matches the default.
+
+The editing system was also made to look like the editor of Android's own <Tooltip content="The tiles in Android's notification shade, like Wi-Fi, Bluetooth, or the flashlight.">Quick Settings</Tooltip> panel. Inware is built to stay close to how the system works, and this was a way to avoid asking users to learn a new system: they can edit their dashboard the same way they already edit their QS Tiles.
+
+## Inside a page
+
+![A tile and the page it opens](/content/case-studies/inware/tile-and-page.png 'The battery tile on the dashboard, and the page it opens.')
+
+Each tile is both a preview and an entry point. The battery tile only shows the level. The page it opens has the rest: health, cycle count, charge current, temperature, and whatever else the device can report.
+
+I also made every destination declare its parent. Back navigation and `iw://` deep links both rely on that declaration, so a page opened from a link behaves exactly like a page opened by hand.
+
+![A long press on a value opens copy and share](/content/case-studies/inware/long-press.png 'The copy and share menu, here on the battery cycle count.')
+
+The values are the reason people open Inware, so I made them easy to take out of it. A long press on any value opens a small menu to copy or share it, without going through a screenshot. It may sound like a detail, but values like a kernel version or a build number are long, and nobody should have to retype them by hand.
+
+Material 3 places menus relative to the component that opened them, and prefers extending to the right, which for a long press often puts the menu under the thumb of a right handed user. Inware handles the menu position differently. I believe a touch context menu should open away from the hand, so Inware uses a custom position provider that opens the menu on the opposite side of the press. You usually press on the side your thumb rests on, so a long press on the right side of the app opens the menu toward the left, and a long press on the left opens it toward the right. I [shared that view](https://issuetracker.google.com/issues/499330952) with the Material team.
+
+## Bottom sheets
+
+![A confirmation presented as a bottom sheet](/content/case-studies/inware/bottom-sheet.png 'A confirmation as a bottom sheet, here for enabling developer options.')
+
+A confirmation like this is usually a dialog: a card in the middle of the screen, two small buttons in a row. On a tall phone, that puts the decision away from the thumb, and it leaves little room for the warning itself.
+
+Inware uses a bottom sheet instead, which is what the Material 3 guidelines suggest: on mobile, a modal bottom sheet [is recommended](https://m3.material.io/components/bottom-sheets/guidelines#1cb775b6-6d2b-4d50-96ad-1862727e986b) as an alternative to simple dialogs and inline menus, especially when actions need icons or longer descriptions. The page stays visible behind a scrim, the sheet sits where the hand already is, and Proceed and Cancel are full-width rows rather than dialog buttons. This one cannot be dismissed by tapping outside or by going back, and since it cannot be swiped away either, it does not show a drag handle. Enabling developer options is a real choice, so the sheet waits for one.
+
+The same sheet is used for confirmations and for lists of actions, so a warning does not look like a different kind of UI from the rest of the app.
+
+## Big screens (in beta)
+
+![The split layout on an unfolded foldable](/content/case-studies/inware/split.png 'The split layout on an unfolded foldable. The divider follows the hinge.')
+
+On large screens, Inware uses a <Tooltip content="A layout that shows a list next to the page of the selected item.">list detail</Tooltip> layout: the destinations stay on the left, and the selected page opens next to them. The list could not simply transform into a Navigation Drawer or a Navigation Rail, because the selected page would then be alone on the screen, either quite large or centered with empty space around it, and the dashboard would have had nowhere to sit. Material 3 provides a scaffold for this layout, and while it animates the transition between the list and a page, it does not animate the move from one page to the next, which in Inware is most of the movement. So I wrapped the Material 3 scaffold into my own and added the missing transition. It ships in 7.1.0.
+
+Inware 7 did not stop at 7.0. It is still built the same way: every change is tested live on a device, then sent to the testers. The Backdrop came out of that, so did the dashboard and its editor, and so will the list detail layout. That's Inware for you.

content/case-studies/template.mdx

@@ -0,0 +1,20 @@
+---
+title: 'Template'
+overview: 'This is a template case study for development purposes.'
+stack: ['Template']
+role: 'Template Role'
+image: '/api/placeholder/1200/600'
+hidden: true
+---
+
+This is a placeholder case study used during development.
+
+![A wide placeholder screenshot](/api/placeholder/1600/900 'A landscape placeholder, standing in for a screenshot.')
+
+Sections further down get their own figures too, so spacing and caption alignment can be checked against real content.
+
+![A portrait placeholder screenshot](/api/placeholder/1200/1500 'A portrait placeholder, for tall screens or detail shots.')
+
+Full-bleed figures should escape the container to the viewport edges, while this text and the captions above stay inside the column.
+
+![A short, wide placeholder screenshot](/api/placeholder/1600/700 'A short, wide placeholder, for a workflow overview.')