mirror of
https://github.com/AzzyAz-net/AzzyBlog.git
synced 2026-08-25 19:24:58 +00:00
Changed Branding
This commit is contained in:
parent
29f81fd3b7
commit
2f9f638c76
10 changed files with 1867 additions and 1943 deletions
BIN
.vs/Azzy.slnx/v18/.wsuo
Normal file
BIN
.vs/Azzy.slnx/v18/.wsuo
Normal file
Binary file not shown.
BIN
.vs/slnx.sqlite
Normal file
BIN
.vs/slnx.sqlite
Normal file
Binary file not shown.
|
|
@ -2,7 +2,7 @@ import { defineConfig } from "astro/config";
|
|||
import mdx from "@astrojs/mdx";
|
||||
|
||||
export default defineConfig({
|
||||
site: "https://uinuxblog.getuinux.com",
|
||||
site: "https://blog.azzyaz.net",
|
||||
integrations: [mdx()],
|
||||
markdown: {
|
||||
shikiConfig: {
|
||||
|
|
|
|||
3620
package-lock.json
generated
3620
package-lock.json
generated
File diff suppressed because it is too large
Load diff
|
|
@ -3,11 +3,10 @@ const currentPath = Astro.url.pathname;
|
|||
---
|
||||
|
||||
<nav class="nav">
|
||||
<a href="/" class="nav-brand">UINUX Blog</a>
|
||||
<a href="/" class="nav-brand">Azzy</a>
|
||||
<div class="nav-links">
|
||||
<a href="/tags" class:list={[{ active: currentPath.startsWith("/tags") }]}>Tags</a>
|
||||
<a href="/search" class:list={[{ active: currentPath === "/search" || currentPath === "/search/" }]}>Search</a>
|
||||
<a href="/about" class:list={[{ active: currentPath === "/about" || currentPath === "/about/" }]}>About</a>
|
||||
<a href="/rss.xml">RSS</a>
|
||||
</div>
|
||||
</nav>
|
||||
|
|
|
|||
|
|
@ -1,36 +0,0 @@
|
|||
---
|
||||
title: "On Calm Software"
|
||||
description: "Most software demands attention. The best software respects it."
|
||||
date: 2026-01-15
|
||||
tags: ["design", "philosophy"]
|
||||
---
|
||||
|
||||
Open most applications and they compete for your attention. Notifications, badges, banners, modals. Every surface is an opportunity to interrupt.
|
||||
|
||||
This is not a design failure. It is a design choice. These products are optimized for engagement, and engagement requires interruption.
|
||||
|
||||
But there is another way to build software.
|
||||
|
||||
## Attention as a resource
|
||||
|
||||
Your attention is finite. Every notification, every animation, every unexpected change in the interface costs something. Most software treats this cost as zero. It is not.
|
||||
|
||||
Calm software acknowledges this. It does its job and gets out of the way. It does not celebrate itself. It does not demand that you notice it.
|
||||
|
||||
## What calm software looks like
|
||||
|
||||
- It loads fast and stays stable
|
||||
- It does not move things around after the page renders
|
||||
- It uses typography and whitespace instead of color and motion
|
||||
- It provides information without demanding a response
|
||||
- It respects the back button
|
||||
|
||||
These are not features. They are qualities. You cannot put them in a changelog, but you feel their absence immediately.
|
||||
|
||||
## Why this matters
|
||||
|
||||
The tools we use shape how we think. Frantic tools produce frantic work. Calm tools create space for focus.
|
||||
|
||||
We build UINUX products with this in mind. Not every product needs to be calm. But the ones that do — the ones used for writing, thinking, and building — should be.
|
||||
|
||||
This blog is one of them.
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
---
|
||||
title: "Systems, Not Themes"
|
||||
description: "Why we build design systems instead of selling themes, and what that means for long-term product thinking."
|
||||
date: 2026-02-01
|
||||
tags: ["design", "systems"]
|
||||
---
|
||||
|
||||
There is a difference between a theme and a system.
|
||||
|
||||
A theme is a surface. It gives you colors, fonts, and a layout. You install it, adjust a few settings, and move on. It works until it does not. When your needs change, the theme becomes a constraint.
|
||||
|
||||
A system is a structure. It gives you rules, relationships, and a way of thinking about your product. It grows with you. It does not need to be replaced — it needs to be understood.
|
||||
|
||||
## The problem with themes
|
||||
|
||||
Themes optimize for first impressions. They are built to look good in a preview. They are designed to convert browsers into buyers.
|
||||
|
||||
But the people who use them — the ones who build real products — quickly discover the gap between what was promised and what is possible.
|
||||
|
||||
- Customization hits a wall
|
||||
- Components do not compose well together
|
||||
- Updates break things
|
||||
- The original design intent gets lost
|
||||
|
||||
This is not a failure of any individual theme. It is a failure of the model.
|
||||
|
||||
## What a system provides
|
||||
|
||||
A system does not try to look good in a screenshot. It tries to work well over time.
|
||||
|
||||
It provides:
|
||||
|
||||
- **Consistent spacing** that scales across screen sizes
|
||||
- **Typography rules** that maintain hierarchy without manual adjustment
|
||||
- **Component patterns** that compose predictably
|
||||
- **Constraints** that prevent drift
|
||||
|
||||
The value is not in what it gives you. The value is in what it prevents.
|
||||
|
||||
## Building with restraint
|
||||
|
||||
The hardest part of building a system is saying no. Every feature request feels reasonable in isolation. But systems degrade one reasonable addition at a time.
|
||||
|
||||
Good systems are opinionated. They make decisions so you do not have to. They trade flexibility for coherence.
|
||||
|
||||
This is the approach we take at UINUX. Not because constraints are fashionable, but because they work.
|
||||
|
|
@ -1,47 +0,0 @@
|
|||
---
|
||||
title: "Writing as Interface"
|
||||
description: "The best interface for communicating complex ideas is still plain text."
|
||||
date: 2026-01-02
|
||||
tags: ["writing", "design"]
|
||||
---
|
||||
|
||||
We spend enormous effort designing interfaces. Layouts, components, interactions, animations. All of it in service of communicating something to someone.
|
||||
|
||||
But for complex ideas — the kind that require nuance, context, and careful reasoning — the best interface is still a paragraph.
|
||||
|
||||
## The limits of visual design
|
||||
|
||||
Visual design excels at orientation. It tells you where you are, what you can do, and what matters most. It is essential for applications, dashboards, and tools.
|
||||
|
||||
But it struggles with depth. A card component can hold a title and a summary. It cannot hold an argument. A grid layout can organize information. It cannot develop a thought.
|
||||
|
||||
For that, you need prose.
|
||||
|
||||
## Why Markdown works
|
||||
|
||||
Markdown is not a design tool. It is a writing tool. It gives you:
|
||||
|
||||
- Headings for structure
|
||||
- Paragraphs for ideas
|
||||
- Lists for enumeration
|
||||
- Code blocks for precision
|
||||
- Links for references
|
||||
|
||||
Nothing else. And that is exactly right.
|
||||
|
||||
The constraint of Markdown forces clarity. You cannot hide weak thinking behind a beautiful layout. The words have to do the work.
|
||||
|
||||
## Building for writers
|
||||
|
||||
When we built this blog, we started with the reading experience. Not the homepage, not the navigation, not the visual identity. The paragraph.
|
||||
|
||||
Every decision flows from there:
|
||||
|
||||
- **Font choice**: optimized for long-form reading
|
||||
- **Line length**: constrained to prevent eye fatigue
|
||||
- **Spacing**: generous, to let ideas breathe
|
||||
- **Color**: neutral, to keep focus on the text
|
||||
|
||||
The result is not impressive. It is not meant to be. It is meant to be readable.
|
||||
|
||||
That is enough.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
import Layout from "../components/Layout.astro";
|
||||
import Heading from "../components/Heading.astro";
|
||||
import Prose from "../components/Prose.astro";
|
||||
---
|
||||
|
||||
<Layout title="About — UINUX Blog" description="About UINUX Blog.">
|
||||
<script slot="head" type="application/ld+json" set:html={JSON.stringify({
|
||||
"@context": "https://schema.org",
|
||||
"@type": "AboutPage",
|
||||
"name": "About UINUX Blog",
|
||||
"description": "About UINUX Blog.",
|
||||
"url": new URL("/about", Astro.site).href,
|
||||
"isPartOf": {
|
||||
"@type": "WebSite",
|
||||
"name": "UINUX Blog",
|
||||
"url": Astro.site?.href,
|
||||
},
|
||||
})} />
|
||||
<section class="about">
|
||||
<Heading as="h1">About</Heading>
|
||||
<Prose>
|
||||
<p>
|
||||
UINUX Blog is a quiet place for writing about systems, design decisions,
|
||||
and the craft of building digital products with restraint.
|
||||
</p>
|
||||
<p>
|
||||
It is part of <a href="https://uinux.co">UINUX</a>, a design practice
|
||||
focused on systems over themes, clarity over complexity, and long-term
|
||||
thinking over trends.
|
||||
</p>
|
||||
<p>
|
||||
This blog exists to share ideas, not to sell. There are no newsletters,
|
||||
no pop-ups, no tracking. Just writing.
|
||||
</p>
|
||||
</Prose>
|
||||
</section>
|
||||
</Layout>
|
||||
|
||||
<style>
|
||||
.about {
|
||||
max-width: var(--width-content);
|
||||
}
|
||||
</style>
|
||||
|
|
@ -13,18 +13,18 @@ const posts = allPosts.slice(0, PAGE_SIZE);
|
|||
const totalPages = Math.ceil(allPosts.length / PAGE_SIZE);
|
||||
---
|
||||
|
||||
<Layout title="UINUX Blog">
|
||||
<Layout title="Azzy">
|
||||
<script slot="head" type="application/ld+json" set:html={JSON.stringify({
|
||||
"@context": "https://schema.org",
|
||||
"@type": "WebSite",
|
||||
"name": "UINUX Blog",
|
||||
"description": "Writing about systems, design, and building with restraint.",
|
||||
"name": "Azzy",
|
||||
"description": "Tech Stuff, and more",
|
||||
"url": Astro.site?.href,
|
||||
})} />
|
||||
<section class="home">
|
||||
<header class="home-header">
|
||||
<Heading as="h1">UINUX Blog</Heading>
|
||||
<p class="home-tagline">Writing about systems, design, and building with restraint.</p>
|
||||
<Heading as="h1">Azzy</Heading>
|
||||
<p class="home-tagline">Tech Stuff, and more.</p>
|
||||
</header>
|
||||
<ul class="post-list">
|
||||
{
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue