<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://treydolan.github.io/feed.xml" rel="self" type="application/atom+xml" /><link href="https://treydolan.github.io/" rel="alternate" type="text/html" /><updated>2026-08-19T18:01:06+00:00</updated><id>https://treydolan.github.io/feed.xml</id><title type="html">Trey Dolan</title><subtitle>Web development student focused on building modern, user-friendly websites and applications.
Passionate about frontend development, creative technology, electronic music, and interactive digital experiences.</subtitle><entry><title type="html">Redesigning My Portfolio for Accessibility and Review</title><link href="https://treydolan.github.io/portfolio/accessibility/2026/08/11/redesigning-my-portfolio-for-accessibility-and-review.html" rel="alternate" type="text/html" title="Redesigning My Portfolio for Accessibility and Review" /><published>2026-08-11T00:00:00+00:00</published><updated>2026-08-11T00:00:00+00:00</updated><id>https://treydolan.github.io/portfolio/accessibility/2026/08/11/redesigning-my-portfolio-for-accessibility-and-review</id><content type="html" xml:base="https://treydolan.github.io/portfolio/accessibility/2026/08/11/redesigning-my-portfolio-for-accessibility-and-review.html"><![CDATA[<p>This portfolio redesign gave me a useful reminder: a developer portfolio is not just a place to show projects. It is also a small product with users, goals, constraints, and tradeoffs.</p>

<p>For this pass, I focused on making the site easier for a hiring reviewer to scan. That meant moving projects forward, improving project descriptions, adding clearer calls to action, and making the visual design feel more intentional than the default theme.</p>

<p>The accessibility work was just as important. I added a light and dark theme, improved color contrast, labeled the navigation controls, gave project images more useful alt text, and cleaned up content that was accidentally rendering like a table.</p>

<h2 id="what-i-learned">What I Learned</h2>

<ul>
  <li>Responsive navigation needs to be tested at awkward in-between widths, not only phone and desktop sizes.</li>
  <li>Theme switching is more useful when it respects system preference and remembers the visitor’s choice.</li>
  <li>Good project descriptions should explain what to review and what decisions went into the work.</li>
  <li>Small content details, like stale sample posts or mismatched contact information, can make a portfolio feel unfinished.</li>
</ul>

<p>The redesign is still a work in progress, but it is now a better reflection of how I think: practical, user-focused, and willing to improve rough edges through testing.</p>]]></content><author><name></name></author><category term="portfolio" /><category term="accessibility" /><summary type="html"><![CDATA[This portfolio redesign gave me a useful reminder: a developer portfolio is not just a place to show projects. It is also a small product with users, goals, constraints, and tradeoffs.]]></summary></entry><entry><title type="html">Learning Web Audio Through Small Experiments</title><link href="https://treydolan.github.io/javascript/audio/2026/05/18/learning-web-audio-through-small-experiments.html" rel="alternate" type="text/html" title="Learning Web Audio Through Small Experiments" /><published>2026-05-18T00:00:00+00:00</published><updated>2026-05-18T00:00:00+00:00</updated><id>https://treydolan.github.io/javascript/audio/2026/05/18/learning-web-audio-through-small-experiments</id><content type="html" xml:base="https://treydolan.github.io/javascript/audio/2026/05/18/learning-web-audio-through-small-experiments.html"><![CDATA[<p>The Web Audio API is interesting because it connects programming with something immediately felt: sound. A small change in timing, gain, filtering, or oscillator type can make the browser feel less like a document viewer and more like an instrument.</p>

<p>While working on my Web Audio demo, I focused on building small experiments instead of trying to make a complete music app right away. That helped me understand the API in layers: creating an audio context, connecting nodes, responding to user events, and keeping the interface understandable.</p>

<p>The biggest lesson was that technical demos still need design. A user should not have to understand the entire API before they can try the project. The interface needs to invite exploration while keeping the controls clear.</p>

<h2 id="lessons-from-the-demo">Lessons From the Demo</h2>

<ul>
  <li>Browser APIs are easier to learn when the feedback loop is visible or audible.</li>
  <li>Interactive controls need sensible defaults.</li>
  <li>Audio projects make state management very noticeable.</li>
  <li>A technical feature is stronger when the interface teaches the user what is happening.</li>
</ul>

<p>That is the kind of work I enjoy: practical JavaScript with room for creative interaction.</p>]]></content><author><name></name></author><category term="javascript" /><category term="audio" /><summary type="html"><![CDATA[The Web Audio API is interesting because it connects programming with something immediately felt: sound. A small change in timing, gain, filtering, or oscillator type can make the browser feel less like a document viewer and more like an instrument.]]></summary></entry><entry><title type="html">What IT Support Taught Me About Web Development</title><link href="https://treydolan.github.io/career/process/2026/05/13/what-it-support-taught-me-about-web-development.html" rel="alternate" type="text/html" title="What IT Support Taught Me About Web Development" /><published>2026-05-13T00:00:00+00:00</published><updated>2026-05-13T00:00:00+00:00</updated><id>https://treydolan.github.io/career/process/2026/05/13/what-it-support-taught-me-about-web-development</id><content type="html" xml:base="https://treydolan.github.io/career/process/2026/05/13/what-it-support-taught-me-about-web-development.html"><![CDATA[<p>My background in IT support has shaped how I approach web development. In support roles, the first job is rarely to prove what you know. It is to understand what is happening, reproduce the issue, communicate clearly, and move toward a fix without making the situation worse.</p>

<p>That mindset transfers directly into development. Bugs often start as unclear reports. Users describe symptoms, not root causes. A good developer has to ask better questions, isolate variables, check assumptions, and document the answer so the next person does not have to rediscover it.</p>

<p>I also learned how much tone matters. When something technical fails, people are usually frustrated because the tool is blocking their actual work. A clear explanation can be just as valuable as the fix itself.</p>

<h2 id="habits-i-bring-from-it">Habits I Bring From IT</h2>

<ul>
  <li>Reproducing problems before trying to solve them.</li>
  <li>Documenting steps and outcomes.</li>
  <li>Communicating status when work is still in progress.</li>
  <li>Thinking about the user experience of failure states.</li>
</ul>

<p>Those habits make me more patient with code and more empathetic toward the people using it.</p>]]></content><author><name></name></author><category term="career" /><category term="process" /><summary type="html"><![CDATA[My background in IT support has shaped how I approach web development. In support roles, the first job is rarely to prove what you know. It is to understand what is happening, reproduce the issue, communicate clearly, and move toward a fix without making the situation worse.]]></summary></entry><entry><title type="html">Building a Portfolio with Vanilla Tools</title><link href="https://treydolan.github.io/portfolio/development/2026/05/11/building-a-portfolio-with-vanilla-tools.html" rel="alternate" type="text/html" title="Building a Portfolio with Vanilla Tools" /><published>2026-05-11T00:00:00+00:00</published><updated>2026-05-11T00:00:00+00:00</updated><id>https://treydolan.github.io/portfolio/development/2026/05/11/building-a-portfolio-with-vanilla-tools</id><content type="html" xml:base="https://treydolan.github.io/portfolio/development/2026/05/11/building-a-portfolio-with-vanilla-tools.html"><![CDATA[<p>One reason I like building small portfolio projects with plain HTML, CSS, and JavaScript is that it keeps the fundamentals visible. Without a framework handling structure for me, I have to pay attention to the basics: semantic markup, responsive layout, asset paths, navigation, and how each interaction behaves in the browser.</p>

<p>That kind of project is useful because it exposes the details that larger tools can hide. If a layout breaks on mobile, the fix usually starts with understanding the box model, spacing, image sizing, and source order. If a page feels confusing, the answer is often clearer content hierarchy rather than more JavaScript.</p>

<p>For an entry-level developer, I think that matters. Frameworks are important, but the foundation underneath them is what helps a developer debug calmly when the abstraction leaks.</p>

<h2 id="what-i-focused-on">What I Focused On</h2>

<ul>
  <li>Keeping the structure readable and easy to inspect.</li>
  <li>Making the site deployable through GitHub Pages.</li>
  <li>Practicing responsive spacing and navigation.</li>
  <li>Separating content, styling, and behavior clearly.</li>
</ul>

<p>The project is not meant to be the flashiest thing I can build. It is meant to show that I can take a simple idea, finish it, publish it, and learn from the rough edges.</p>]]></content><author><name></name></author><category term="portfolio" /><category term="development" /><summary type="html"><![CDATA[One reason I like building small portfolio projects with plain HTML, CSS, and JavaScript is that it keeps the fundamentals visible. Without a framework handling structure for me, I have to pay attention to the basics: semantic markup, responsive layout, asset paths, navigation, and how each interaction behaves in the browser.]]></summary></entry></feed>