Hello.

Many companies have Human Interface Guidelines (HIG) that dictate how their products should look and feel. But what about the developers? This post explores the need for Developer Interface Guidelines, proposing a framework for what that might look like and what benefits that could bring.

I added dark mode to my blog! Inspired by Jeremy Keith, I used CSS custom properties and media queries to switch between light and dark themes based on the user's preference. I also included a fallback for browsers that don't support custom properties and a temporary CSS class for testing since Chrome DevTools didn't yet have dark mode emulation.

I recently noticed Twitter has adopted the Well-Known URL for Changing Passwords, which is a simple yet effective way to improve user experience. This spec allows browsers to offer a UI for quick password resets without navigating complex site structures, simply by checking a well-known URL. This sparked an idea: could we expand this concept to other common user actions? Imagine well-known locations for managing GDPR consent, browser permissions, account details, or mailing list subscriptions. It's a powerful concept that could simplify many online interactions, and I've even raised an issue with Chrome to explore implementation.

This post revisits the UX issues that contributed to the demise of Web Intents. We never adequately addressed the wide array of potential actions and data types, leading to a generic and confusing user experience. Handling data return from a long-running operation in another app proved problematic, especially if the initiating app closed. The lack of an explicit API for expecting returned data, similar to Android's startActivityForResult, further hindered the development of intuitive UI affordances. The open nature of Web Intents resulted in a proliferation of schemas and protocols, making standardization difficult. Users were forced to choose an app for every action, and developers lacked control over how apps launched, leading to inconsistent experiences. Finally, the absence of reliable fallbacks for unsupported intents eroded developer confidence and potentially left users stranded. In short, a combination of UX shortcomings ultimately led to Web Intents' downfall.

I've been working on making html5rocks.com more mobile-friendly, focusing on reducing "Time to first read". The main culprit was the Table of Contents (ToC). My initial experiment with an offscreen ToC using CSS had cross-browser inconsistencies. Now, using existing JS, the ToC is fixed to the footer and toggled into view. I'm still exploring pure CSS solutions. Initially, I favored a small scrollable ToC at the bottom, but Paul Lewis suggested a full-screen ToC, which proved better. It minimizes distractions and clutter, provides more screen space for a readable, easily navigable ToC with larger touch targets and subtle hierarchy, even for long lists. The before/after screenshots demonstrate the improvement.

In this post, I share my support for Internet Explorer 7's decision to enable ClearType by default. Bill Hill's blog post on the topic highlights research demonstrating ClearType's positive impact on reading, IE's primary use case. Personally, I've found ClearType enhances readability and focus, though IE7 Beta 2 has presented rendering issues on platforms like Blogger.

I tried out Blogniscient and Memeorandum, the automated blog news organizers, but I'm not impressed. The main reason? I can't even spell their names correctly when I want to visit their sites!

I often disagree with Jacob Neilson's views on usability, but his recent article on blog usability is spot on. I plan to implement several of his suggestions, especially adding a personal photo to my blog.

I'm seeking feedback on the AJAX Tagger I've implemented in my journal entries, specifically concerning the Wikipedia article links. Are they useful? Do you have any suggestions for improvement? You can email me at paul.kinlan@gmail.com or leave a comment.

I'm still waiting for a response from Start.com regarding my UI improvement suggestion. Even though Robert Scoble mentioned their quick response to feedback, I haven't heard anything about my suggestion to improve the functionality of the close ("x") button on content panes. I've sent an email and even blogged about it, but no luck so far. Hopefully, they'll address it soon!

This is the fifth installment in my series on the AJAXTagger's failures. A major issue is its lack of intuitiveness. Users couldn't understand its purpose or how to use it without a demo. While it significantly reduced my tagging time, the next version needs improvements. I'm looking for feedback on how to make it more user-friendly, including better visual cues, a clearer UI, and improved documentation. Email me or comment with your suggestions!

This blog post, the third in a series about my first AJAX application, focuses on the disastrous visual design. While the functionality is there, the UI is frankly terrible. I've realized my design skills are lacking, and though I have a vision, I struggle to bring it to life visually. The problem is that the application's logic is tightly coupled to the UI. Moving forward, I need to decouple these components. The next version will have a UI-agnostic data structure that the UI can interrogate. This separation will allow me to work on the AJAX framework, business logic, and UI independently.

Start.com's AJAX web portal, which displays web feeds in an HTML interface, has been promoted to the main site. However, a persistent issue remains: the inability to cancel the close event on RSS feed panels, a problem previously highlighted and still unresolved.

This post discusses the shortcomings of my first AJAX application. While it successfully implemented Technorati tags, it failed to provide related search functionality, which I believe is crucial for offering readers valuable external resources and further learning opportunities. I aim to address this in the next version by incorporating related searches via Yahoo's API and relevant quick links, enhancing the overall user experience and educational value of my blog.

Many complain AJAX breaks browser navigation, but I believe that pressing the back button should exit an AJAX application entirely. It's not AJAX itself, but poorly designed applications that break navigation and bookmarking. Google Maps has addressed bookmarking, but some applications aren't suited to web-style navigation or bookmarks. More thoughts on this to come. Comments welcome via email or the comments section.

IE7's synchronous XmlHttpRequest locks up all browser tabs during long requests, not just the active tab. Is this behavior expected or a bug? If you've encountered this problem, please email me so I can investigate further.

After using IE7 Beta 1, I've found tabbed browsing, while a welcome addition, has a few quirks. Modal dialog boxes lock the entire browser, not just the tab, which is disruptive. Tabs don't have tooltips, making it hard to distinguish between similar pages. Closing tabs requires going to the far right of the screen or right-clicking, neither of which is ideal. And finally, new tabs don't open to the homepage, which would be a useful option.

I've been exploring the RSS features in IE7 Beta 1 and have a couple of suggestions. First, it would be great if we could add feeds to favorites directly from the feeds toolbar button, rather than having to navigate to the feed itself. It's an extra step when we've already decided we like the content enough to add it. Second, I'm curious about how IE7 discovers feeds on a page. Sometimes it works, sometimes it doesn't. Is it just looking for a specific link tag in the head section or is there more to it? It seems to struggle with feeds linked via anchor tags. Overall, I'm enjoying IE7 so far, just want to offer some feedback.