Generating web apps with AI agents like Replit is incredibly powerful, enabling rapid prototyping and deployment. My experience building tldr.express, a personalized RSS feed summarizer, highlighted the importance of a detailed specification. While initial prompts yielded impressive results, I iteratively refined the app through configuration and additional prompts to address issues like email integration, AI model selection, output formatting, spam prevention, and bot mitigation. This iterative process reinforced that while AI agents excel at rapid generation, a well-defined specification upfront is crucial for a successful outcome.
Reflecting on my journey with computers, from the C64 and Amiga 500 to the present day, I've found a renewed excitement in software development. New tools like repl.it and websim.ai empower rapid creation of full-stack, disposable web apps – software built for personal use and easily discarded. This ease of creation removes the barrier to starting projects, making the web an ideal platform for even single-user applications. It's a shift from handcrafted software to a more ephemeral approach, allowing for quicker prototyping and experimentation.
Experimented with WebSim, a simulated web environment, creating sites like a personal blog, timezone converter, interactive globe, and a travel site. The experience was reminiscent of the early web's playful exploration and highlighted WebSim's potential for creativity and interactive experiences.
In this blog post, I share some findings from my exploration of HTTP Archive data. I discovered that a significant number of websites using manifest.json files are using the default configuration generated by Create React App. I plan to investigate this further and determine how prevalent default manifest files are across the web.
I've created a small library called reactive-prompt that lets you easily manage prompts in a reactive way, similar to how you'd build a web app with React. It uses Preact's Signals to track changes to inputs and automatically re-runs prompts when those inputs update. This allows for efficient chaining of prompts, where the output of one becomes the input of another, and only necessary prompts are re-evaluated. The library currently uses Chrome's experimental prompt API but could be adapted for other providers like OpenAI or Gemini. It makes complex prompt flows much more manageable.
I explored using ChatGPT's Code Interpreter to analyze browser compatibility data from the BCD project. My goal was to determine the latest released versions of different browsers. While the initial results weren't perfect, through a few iterations of feedback, the Code Interpreter generated a Python script that accurately extracted the desired information. I was impressed by the speed and efficiency of this process, as it accomplished in minutes what would have taken me much longer manually. The generated code also provided a starting point for further analysis, like visualizing browser release timelines. Despite minor imperfections, the Code Interpreter proved to be a powerful tool for quickly extracting and analyzing data.
This blog post introduces a bookmarklet utilizing the EyeDropper API for quickly grabbing color information in Chromium-based desktop browsers. The bookmarklet simplifies color selection by opening the eyedropper tool and returning the chosen color's sRGBHex value in an alert box. A link to a related blog post about creating a similar Chrome extension is also included.
I explored using LLMs for checking web API browser compatibility. Existing LLMs struggle with outdated data, so I experimented with MDN's Browser Compat Data (BCD). Initial trials using raw BCD JSON with GPT-4 had limitations. To improve this, I converted the BCD into English descriptions of API support and loaded it into a Polymath instance. This allows natural language queries about API compatibility across browsers, like "Is CSS Grid supported in Safari, Firefox, and Chrome?" or "When was CSS acos available in Chrome?". The results are promising, but further refinement is needed to ensure accuracy and reliability.
I built Ask Paul, a generative AI demo that answers front-end web dev questions using my content. It leverages Polymath-AI to index content, find related concepts, and generate summaries by creating embedding vectors, using cosine-similarity, and querying OpenAI. The implementation has a UI, a Polymath Client, and a Polymath Host. It's super cool how accessible this tech is now!
I've added a new feature to time-to-stable that lists experimental APIs across browsers using BCD. This helps developers track experimental APIs, understand their stability, and consider the implications for website integration. It helps answer questions about cross-browser compatibility and potential deprecation, informing decisions about using these APIs.
In this post, I explore the potential of the File System Access API to create local-only web experiences. I discuss how this API, combined with tools like Logseq, allows for on-device data storage outside the browser sandbox. While exciting, I also acknowledge the current limitations, such as the need to re-grant file access on refresh, the lack of a visual indicator for local-only sites, and the difficulty of preventing data exfiltration entirely. Despite these challenges, I believe this area holds significant potential and deserves further exploration.
I created a Lighthouse audit that uses machine learning to detect if an anchor tag looks like a button. This involved training a TensorflowJS model, building a custom Lighthouse gatherer to capture high-resolution screenshots, and processing those screenshots to identify anchors styled as buttons. The audit highlights these anchors in the Lighthouse report. The code for the scraper, web app, and Lighthouse audit are available on GitHub. While there are edge cases, this project demonstrates the potential of using ML for visual inspection tasks in web development.
I needed higher resolution screenshots for an ML model to classify elements on a webpage, but the default Lighthouse screenshot was too compressed. So, I created a custom Lighthouse Gatherer using Puppeteer. This gatherer captures a full-page, high-resolution screenshot encoded as base64 and returns it along with the device pixel ratio. This was a fun little project, and the code is surprisingly concise. However, future Lighthouse versions may include higher-resolution screenshots, making this gatherer redundant.
I built a web app using Deno, Fresh, and TensorFlowJS to classify images as links or buttons. The app uses a pre-trained ML model and allows users to drag and drop multiple images for classification. I encountered challenges with server-side rendering and islands, specifically with integrating a file-drop web component. I also documented the process of integrating the TensorFlowJS model, including model loading and prediction handling. The code is available on GitHub.
In this project, I'm working on an accessibility tool to detect links styled as buttons, a common issue that can confuse users. My approach involves scraping websites to gather images of buttons and links, and then training a machine learning model to distinguish between them. This post focuses on the scraping process using Puppeteer. I encountered challenges like occluded elements and smooth scrolling, which I addressed by checking for occlusion and disabling smooth scrolling. The next step is training the ML image classifier.
This blog post explores how machine learning (ML) can enhance the developer experience. Inspired by Corridor Crew's use of ML in VFX, I initially brainstormed ways ML could automate tedious developer tasks, like accessibility improvements and performance optimization. I also considered ML's potential for generating layouts and images. The emergence of tools like GitHub Copilot and DALL-E-2 significantly impacted my thinking, especially regarding the future of software development and my role as a DevRel lead. Ultimately, the transformative power of GPT-Chat, demonstrated through its ability to generate webpage layouts and populate them with images based on simple prompts, left me questioning the future of my profession and considering the role I might play in training the next generation of AI tools.
Custom URL schemes can enhance web app functionality by handling specific URLs, but detecting scheme support is tricky. Several methods exist, including click handlers, navigation handlers (Blink), and server-side redirects with meta refresh. While the server-side approach offers the most robust solution, it introduces complexity. A key challenge is the limited user understanding of custom schemes, leading to a preference for standard HTTPS URLs. This post explores a common pattern for custom scheme usage, involving detecting navigation failures and presenting alternative UI. The pattern addresses the issue of handling custom schemes like web+follow for Mastodon, aiming to improve user experience. While custom schemes are valuable developer tools, user preference for HTTPS URLs persists. Despite this, custom schemes empower developers to guide users to preferred apps or sites while gracefully handling cases where no suitable option exists. This approach also opens possibilities for other applications, like rebuilding web intents.
This post explores browser compatibility data, focusing on features present in some browsers but not others. I've created a tool, "Not yet Stable," to visualize these differences and help developers understand the current web platform landscape. While high-level comparisons are interesting, the real value lies in identifying smaller, unexpected compatibility issues that can cause frustration. The tool allows for granular comparisons between specific browsers (e.g., Chrome vs. Firefox, Safari vs. Firefox) to pinpoint these inconsistencies. I've observed significant discrepancies in media-related features, such as Web Codecs API, Picture-in-Picture, and MediaStreams. The goal is to leverage this data for better understanding and ultimately improve web compatibility.
I've created a tool called "Now Stable" using Browser Compat Data (BCD) to help developers determine when web APIs become stable across different browsers. This addresses the challenge of keeping up with browser updates and helps developers confidently choose APIs for their projects. The tool allows users to select their target browsers (e.g., Chrome, Safari, Firefox) and see a chronological list of when APIs became available across those browsers. I'm looking for feedback on how this tool can be improved and how developers would use this data.
This blog post discusses the current state of web API permissions and argues for a more restrictive "off-by-default" approach. It highlights the Principle of Least Privilege and observes that most websites don't utilize Feature Policy or Permissions Policy effectively. The author suggests that instead of asking "what should I turn off?", developers should ask "what should I enable?". The post details the different permission models, the complexity of managing numerous permissions, and the benefits of a deny-all-then-enable approach. It also acknowledges the drawbacks and the need for tooling and guidance to facilitate this shift in thinking. The author concludes by advocating for intentionality in permission management and encouraging a discussion on the topic.
HTML5Rocks, a beloved resource for web developers, is shutting down. This post reflects on the site's history, its impact, and the reasons behind its decline. Key factors include the shift away from "HTML5" as a buzzword, changing team priorities, lack of a focused content plan, and challenges with community management. Despite the shutdown, the author expresses gratitude for the experience and the connections made, highlighting the lessons learned about content creation, developer engagement, and the open-source community.
This post discusses the challenges web developers face due to the constantly evolving web platform. It highlights the difficulty in keeping up with changes, browser inconsistencies, and the lack of clear documentation. It then outlines the efforts made to address these issues, focusing on improving communication about the web platform, enhancing compatibility and interoperability across browsers (Compat 2021, Interop 2022), and investing in better documentation like MDN's Browser Compat Data. These initiatives aim to create a more stable and predictable web development experience, fostering innovation.
The Chrome and Web Developer Relations team is significantly expanding in 2022. Open roles span program management, Chrome extensions, CSS, rendering, DevTools, web performance, the Privacy Sandbox, and web ecosystem. The team is seeking program managers, developer relations engineers, technical writers, and infrastructure specialists to contribute to various initiatives, including Chrome Dev Summit, Google I/O, web.dev, and improving the overall web platform.
I'm starting a project to document web technologies that didn't become mainstream. For every success story, countless others fade away. I want to explore these untold stories, starting with my own experience with Web Intents. I aim to understand why some projects thrive while others don't, and share these learnings with the community. If you have a similar story, please reach out!
I missed the trajectory of React's rise. Blinded by my focus on technical details, I failed to see the bigger picture of market demands and developer needs. I need to improve my ability to identify these trends earlier.
This blog post discusses the top challenges faced by web developers in 2021 based on a quarterly survey. The findings reveal that the top pain points remain consistent with previous years, including browser compatibility, testing, documentation, debugging, framework usage, and security/privacy concerns. The survey data highlights the difficulties developers face in keeping up with evolving web standards and the ever-expanding ecosystem of tools and frameworks. Cross-browser compatibility and testing remain significant hurdles. While initiatives like Compat 2021 aim to address these challenges, their impact is yet to be fully realized. The data consistently shows the need for improved developer tooling and a more streamlined web development experience.
The pace of change in web development, particularly with APIs and browser updates, is overwhelming. The constant deprecation and breaking changes cause friction and highlight a lack of empathy for developers struggling to keep up. While frequent updates are important, the current model, exemplified by Chrome, feels too aggressive. This blog post will explore this tension, examining whether we've pushed developers too far, and discuss strategies for a more sustainable pace of change. It will also touch on platform-specific resources like web.dev and the challenge of balancing innovation with support for the broader developer community.
With Chrome nearing version 100, there's a concern about whether user agent checks relying on "Chrome 10" will break. Analysis of HTTP Archive data suggests this is unlikely, with most instances of "Chrome 10" in JavaScript code being comments or workarounds rather than version checks. While client-side checks seem safe, server-side checks remain a concern, highlighting the need for User Agent Client Hints. If you know of tools that might be affected by the Chrome 100 user agent change, please get in touch.
We've been using surveys like the MDN Developer Needs Survey and our own quarterly surveys to understand web developer challenges and prioritize our efforts. These surveys highlighted issues like web compatibility, testing, and documentation, leading to improvements like our Web Compat initiative and increased focus on MDN documentation. While valuable, these surveys don't offer granular feedback on specific projects or proposals. Direct feedback is essential, but our current approach is informal and inconsistent. To address this, we've partnered with C SPACE to create the Web Developer Insights Community – a dedicated group of ~1000 web developers who'll provide direct feedback to our questions. This community allows open communication among developers while limiting Chrome team influence. We're excited about this new channel for gathering actionable developer insights and encourage you to join if you're interested.
I integrated the Squoosh CLI into my web app to optimize images. Although Squoosh offers a great CLI, I needed its functionality within my app. Leveraging my experience with FFMPEG in web apps, I adapted the Squoosh CLI code, replacing Node.js dependencies with web APIs. Now, I can call Squoosh's 'run' method directly in my app to resize and compress images. This unofficial solution works for now, but a dedicated browser API would be ideal for broader integration in CMS platforms, performance analysis tools, and other web applications.
The blog post explores the current state of web development, highlighting the tension between optimization demands from major players like Google and the emergence of new, faster build tools. It expresses the author's personal experience with these new tools and their potential to streamline the development workflow.
I'm sharing my raw, unedited thoughts on modern web development here. Consider this a living document of my ideas, some old, some new, all evolving over time. Expect errors and feel free to provide feedback (@paulkinlan@google.com, @paul_kinlan). The list of ideas will be kept up-to-date below.
This post explores whether developers are actively addressing issues highlighted by Lighthouse performance audits. By analyzing HTTP Archive data and tracking Lighthouse scores over time, we aim to uncover potential improvements. While directly correlating specific fixes to Lighthouse test failures is challenging, we can investigate trends and infer the impact of Lighthouse on web development practices. A key consideration is the evolution of Lighthouse itself, such as changes to CPU performance calculations, which may affect the comparability of results over time.
I'm excited to announce that I'm starting "Office Hours" to connect directly with web developers. Following a successful run at Chrome Dev Summit, I'm opening my calendar for anyone to schedule a meeting with me. I'm happy to discuss anything from JavaScript, CSS, and performance to career advice. I'm especially eager to connect with developers in underrepresented regions. Book a meeting and let's chat!
I created a bookmarklet to easily download all images from my daughter's nursery school portal, which doesn't allow direct downloads. It uses the File System API to let the user choose a directory and save all images there. The bookmarklet grabs all images, fetches them sequentially to avoid overloading the server, and saves them to the chosen directory using file handles and writer streams. Now I can easily preserve these memories!
I built a Material Design-style Floating Action Button (FAB) without using any JavaScript. This was achieved using only HTML and CSS, leveraging anchor links and the ":target" selector to control visibility and create the open/close functionality. Clicking the FAB opens a menu with links to different actions, and clicking a close button hides the menu. This approach does have the trade-off of adding entries to the browser history, but it's a pure HTML/CSS solution for a common UI element.
I accidentally discovered that Twitter has implemented PWA shortcuts, a feature that allows websites and web apps to provide users with quick access to common actions. This is a great step towards bridging the gap between web and native applications, allowing websites to provide a more app-like experience.
I created a shortcut for iOS that lets you view the source code of web pages in Safari and Chrome. It's a workaround for the lack of a built-in view-source feature on these mobile browsers. The shortcut shares the URL to a third-party website I built which then displays the source code. Because it uses a third-party site, it won't reflect the current state of the page if you are logged in or have specific cookies set. Hopefully, Safari and Chrome will eventually bring back a native view-source option.
Just saw that Scroll To Text Fragment is launching in Chrome 81! This feature lets you link to specific text within a page, which is awesome. I created a bookmarklet that grabs your selected text and generates a link using the new :~:text= fragment identifier. Drag the "Find in page" link to your bookmarks bar to try it out. The bookmarklet currently selects whole words, but I'm planning on adding some logic to handle partial word selections better. You can also easily modify the bookmarklet to copy the generated link to the clipboard instead of opening a new window.
Celebrating my 10th anniversary at Google working on Chrome and leading a Developer Relations team. As we plan for the next few years, I'm reflecting on how we can improve Developer Satisfaction. Inspired by recent feedback on Apple's developer relations, I'm curious to hear your thoughts on what a web browser developer relations team should prioritize. What can we do more of? Less of? How can we best support you and your team? Share your opinions, especially broad strategic ideas.
This post discusses the importance of developer satisfaction, particularly for web developers, and how the MDN Web Developer Needs Assessment has influenced Chrome's web platform priorities for 2020. My hypothesis is that improving the web platform will lead to increased developer satisfaction, more content creation, and happier end-users. Based on the MDN survey data, key areas for improvement include browser compatibility, testing, documentation, debugging, framework integration, and privacy & security. Chrome is committed to working with the web ecosystem to address these challenges and increase developer productivity and satisfaction. We'll share more specific plans in the coming weeks and welcome your feedback on these focus areas and how Chrome can better engage with the developer community.
I'm looking for a Developer Advocate to join the Chrome team and help us improve web privacy. We have many ongoing and upcoming projects within the Privacy Sandbox initiative. This role will focus on advocating for cross-browser privacy solutions, working with external developers, and ensuring our internal teams prioritize user and developer needs. This will involve explaining potentially disruptive changes (like the SameSite cookie attribute update) and helping developers adapt.
Chrome 81 finally fixes a long-standing bug where images taken in portrait mode on phones were displayed in landscape. Now, images will respect the orientation from the EXIF data by default, unless overridden with the CSS attribute image-orientation: none. Check out the demo!
Mobile devices lack the bookmarklet functionality found in desktop browsers. However, the ShareTarget API offers a potential workaround. This API allows web apps to be installed and receive native share actions, similar to how the Twitter PWA handles shared links and files. By leveraging this API, developers can create mini-apps that perform actions on shared data. This approach involves defining how to receive data in a manifest file and handling the request in a service worker. I've created examples for Hacker News, Reddit, and LinkedIn demonstrating how to utilize the ShareTarget API. While not a perfect replacement for desktop bookmarklets, this offers a new level of hackability for mobile web experiences.
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've added Webmention support to my blog! I'm excited about Webmentions because they allow decentralized commenting and reactions, unlike Disqus which I'm looking to remove. Sending webmentions involves two parts: the sender and the receiver. I used Remy Sharp's webmention.app tool to simplify the sending process. Integrating it into my Zeit/Hugo blog was super easy - I just installed the package and added a call to the CLI in my build script. Now, whenever I publish a post, it automatically pings any URLs I've linked to.
I've created a simple UI for my static site and podcast creator that allows me to quickly post new content. It uses Firebase Auth, EditorJS, Octokat.js, and Zeit's Github integration. This post focuses on committing multiple files to Github using Octokat.js. The process involves getting a reference to the repo and the tip of the master branch, creating blobs for each file, creating a new tree with these blobs, and creating a commit that points to the new tree. The code handles authentication, creates blobs for images, audio (if applicable), and markdown content, and then creates the tree and commit. This setup allows me to have a serverless static CMS.
I've been working on creating a simple screen recording software, and in this post, I share how I finally figured out how to record both microphone and desktop audio simultaneously. Previously, I could only record one or the other. The key is to use the Web Audio API, specifically createMediaStreamSource and createMediaStreamDestination, to combine the two audio streams into one. This combined stream can then be fed into the MediaRecorder API. You can check out the full code on my Glitch project and see a demo, too!
I built a Progressive Web App (PWA) that extracts text from images shared to it. It uses the Share Target API to receive images, the Shape Detection API's TextDetector to analyze them, and EXIF-Js to handle image rotation issues. While it's a handy tool, it currently suffers from cross-browser and cross-version compatibility problems due to the lumpy nature of the web platform. The code snippets highlight key implementation details, like manifest setup, service worker handling, text extraction, and image rotation.
This blog post provides a guide on how to debug web pages on the Nokia 8110 (KaiOS) using Chrome OS with Crostini (m75 or later). It builds upon a previous post about using Web IDE for debugging KaiOS devices but focuses on using a Chrome OS environment. The guide outlines the necessary steps, including enabling Crostini USB support, installing required packages like USB tools, ADB, and Fastboot, and configuring udev rules to allow Chrome OS to recognize the Nokia 8110. The post includes commands for installing dependencies and verifying device connectivity.
Safari 12.1 introduces significant updates for web developers. Notably, Apple now recommends using the Payment Request API for Apple Pay implementations on the web. This shift aligns with broader industry efforts towards standardized payment methods, though it contrasts with Google's prior emphasis on their Google Pay library. Additionally, the new Web Share API empowers developers to trigger native sharing functionalities on the user's device via navigator.share(). This allows for seamless content sharing across various apps and contacts, enhancing user experience. While the Share Target API is still anticipated, this release marks substantial progress in web sharing capabilities.
This post introduces a simple yet effective approach to improve offline user experience on the web using Service Workers. Instead of a browser's default offline page, this method displays a custom offline page when the network is unavailable. The provided JavaScript code caches essential offline assets and intercepts navigation requests. If a request fails due to network issues, it serves a pre-cached 'offline.html' page, ensuring a smoother experience for users. This strategy enhances user perception of web applications, especially in areas with unreliable internet connectivity. A key improvement mentioned is the use of Navigation Preload, which optimizes the loading process by not waiting for the Service Worker to boot up for all requests.
I created Quick LogCat, a web tool for debugging Android devices without needing adb installed. It uses WebADB.js and the WebUSB API to connect to your device and display logcat output. The tool is useful for on-the-go debugging. It's powerful but also highlights the potential security implications of granting web access to USB devices. This technology opens up exciting possibilities like firmware updates and app sideloading via web interfaces. I'm curious to see what others build with WebUSB and adb access.
Debugging web pages on the Nokia 8110 (KaiOS) can be tricky due to the lack of traditional developer tools. This post outlines the steps I used to successfully debug, involving enabling Developer Mode on the phone, forwarding a port using adb, and connecting to the phone's runtime via Firefox 48's Web IDE.
I've been exploring Chrome's Shape Detection API and its potential, even creating a QR code detector with a JS polyfill. While I appreciate the API, I'm more impressed by libraries like Jeeliz, which offer faster face detection and broader cross-platform compatibility via WebGL and WASM. This tech allows for augmented reality experiences without large app downloads and data harvesting. There are numerous practical applications for this technology, from text selection and translation to product search and accessibility features. I believe the web is ideal for such experiences, and although I appreciate the native Shape Detection API, its inconsistencies across platforms raise questions about the need for native implementations when web-based solutions using WebGL and WASM can offer better consistency and reach.
This post discusses the importance of using push notifications responsibly in Progressive Web Apps (PWAs). It highlights the negative impact of intrusive notification prompts and emphasizes the need for providing context and respecting user preferences. The post links to a helpful article and video by Thomas Steiner that provides further guidance on best practices for web push notifications, including avoiding immediate prompts and clearly communicating the value and frequency of notifications.
Feature Policy is a powerful web platform tool that allows developers to control the behavior of APIs and features, similar to CSP. It helps manage third-party content by enabling or disabling functionalities like autoplay, geolocation, and sensor access within iframes, giving embedders more control over their page experience. Additionally, Feature Policy assists in maintaining performance budgets during development by flagging potential violations, such as excessive image downscaling, as demonstrated with the 'max-downscaling-image' policy used during Chrome Dev Summit. Developers can explore more about Feature Policy, code samples, and demos at featurepolicy.rocks, submit feedback at https://bit.ly/2B3gDEU, and learn about the Reporting API at https://bit.ly/rep-api. For the latest Chrome implementations, visit Chrome Status.
Excited for the 6th Chrome Dev Summit! Join us for two days of exploring modern web experiences. Day 1: Web of Today - focusing on Speed, UI, and Capability in modern web development. Day 2: Web of Tomorrow - a look at what we're working on for the future, including deep dives into new technologies and opportunities to give feedback. See you there!
My QRCode scanner app in China ran into an issue offline: the camera wouldn't start due to a Google Analytics request hanging in the onload event. This highlighted a broader problem of render-blocking third-party assets. If these assets (like scripts) are critical, a slow or failed connection can prevent the page from rendering for over a minute while the browser waits for a timeout. This results in a blank screen for the user. This post explores the impact of render-blocking third-party resources on performance and how optimizing their integration can drastically improve the user experience, particularly in unreliable network conditions.
I've encountered a bug in Chrome on Android where MediaRecorder, using Canvas.captureStream(), fails to encode video from large canvas elements (e.g., 1280x720). While the process works on desktop Chrome, on Android, the recording stops abruptly at unpredictable points, likely due to limitations in the MediaRecorder API's encoding capabilities. A smaller canvas (640x480) works fine, suggesting resolution-based limitations. I've reported this as Chrome bug 897727 and created a demo to illustrate the issue.
This post discusses Progressive Web Apps (PWAs) and why companies like Microsoft and Google are embracing them. While PWAs offer instant access to content and cross-device compatibility, a key concern is their isolated nature, making it difficult for them to share data and resources. This contradicts the core principles of the web, which should be linkable and interoperable. The increasing isolation of PWAs, along with the broken functionalities of basic web operations like copy/paste and drag/drop, contributes to the creation of unintended data silos on the modern web.
In this post, I'm sharing a screencast demonstrating how I built a web-based webcam and screen recorder using the navigator.getDisplayMedia API. This allows users to grant access to their screen content for recording. The code provided captures both screen and audio, combines them into a single video stream, and allows downloading the recorded video as a webm file. This is a very early stage, and the current output is raw. The ultimate goal is to build a full-fledged video editor in the browser, but for now, this screencast shows the initial steps in capturing video and audio.
I'm embarking on a project to build a web-based video editor! The goal is to create a tool that simplifies video creation and editing entirely within the browser. Think Screenflow, but accessible to everyone directly on the web. This project is driven by my own needs for creating device demos, screencasts, and other videos. I've already made some progress (check out the demo!), but there's a lot more to do. I'll be exploring existing web technologies to record audio/video, manipulate content (watermarks, filters, overlays), and output in various formats. This isn't about building a massive commercial product, but rather about understanding what's possible and empowering others to create great videos using the open web.
In the early days of mobile web development, Google Gears played a pivotal role in shaping the APIs we use today. It introduced concepts like local caching, local databases, and background processing, which paved the way for modern APIs such as AppCache, WebSQL, Geolocation, and Web Workers. While WebSQL and AppCache have been replaced by IndexedDB and ServiceWorkers, respectively, the legacy of Gears is undeniable.
This blog post discusses the evolution of Progressive Web Apps (PWAs) since their inception in 2015. While PWAs offer numerous benefits like offline functionality, push notifications, and installability, the author observes that adoption hasn't been universal. Many developers and businesses misunderstand PWAs, sometimes treating them as separate products or focusing on single features like push notifications. The post argues that the focus should shift from "apps" to user experience. It proposes a set of principles for modern web experiences: discoverable, safe, fast, smooth, reliable, and meaningful. These principles aim to guide developers towards building better web experiences that naturally embody the core values of PWAs, benefiting both users and businesses.
In Chrome 68, the Add to Homescreen banner will no longer automatically appear, even if the site meets the criteria. Instead, developers have control over prompting users. Listen for the beforeinstallprompt event, then present a custom button or UI element to trigger installation when appropriate. This change aims to reduce annoying prompts and give developers more control over the user experience. While potentially impacting install rates initially, it empowers developers to prompt users strategically. Chrome is exploring ambient badging as a less intrusive way to indicate installability.
Hugo, by default, doesn't serve .mjs files with the correct MIME type, which is necessary for using ES modules. However, starting with v0.43, you can configure Hugo to serve .mjs files correctly by adding the 'mjs' suffix to the 'text/javascript' media type in your config file. This allows for proper local testing of ES modules, although hosting considerations might differ.
I recently had the pleasure of attending and thoroughly enjoying a live stream hosted by This Dot, featuring browser representatives from Brave, Beaker, Edge, Chrome, and Mozilla. They discussed recent updates and the future direction of browsers. Key highlights included Beaker Browser's innovative work on the distributed web, Edge's significant updates like Service Worker support and WebP integration, Mozilla's focus on Web Assembly, and Brave's progress with BAT. My team at Google is focused on Discovery, Speed & Reliability, UI Responsiveness, UX, Security, and Privacy. We're working to improve how developers build sites for headless services, optimizing for speed and reliability using metrics like TTI and FID, improving UI responsiveness with techniques like FLIP and Houdini, prioritizing user experience, and addressing security and privacy concerns in light of Intelligent Tracking Prevention and GDPR. It was also exciting to see a shared interest in bringing back Web Intents.
I explored the Ambient Light Sensor API, a new feature available in PWAs. It lets developers access ambient light levels in lux units, useful for various applications like smart home lighting control or adjusting app brightness based on environmental conditions. The API is built on the Generic Sensor API, which also supports other sensors like gyroscopes and magnetometers. I previously discussed the Generic Sensor API at Chrome Dev Summit 2016, and it's now available in Edge and Chrome (behind a flag).
This blog post provides a basic overview of web architecture concepts that are helpful for new web developers. It covers a standard, scalable web stack and discusses the benefits and tradeoffs of using Platform as a Service tools like Heroku, Firebase, or AppEngine for simplifying development, even with higher costs.
Feature Policy is a new web platform API designed to help developers maintain control over their web app's performance, security, and user experience. It allows developers to define policies that restrict access to certain features or modify the browser's default behavior. Examples include controlling autoplay, access to sensitive APIs, usage of fullscreen, preventing use of outdated APIs, and managing image sizes. Policies act as a contract between the developer and the browser, ensuring the developer's intent is followed even as the project grows and evolves. While adoption is a concern, its potential benefits for performance, security and privacy are substantial, especially if tied to incentives like app store listings.
I'm exploring the best way to load web components, focusing on how to include styles and templates without creating uncontrolled blocking requests. I've experimented with using a single JavaScript file that encapsulates everything, including styles and a dynamically created template element. This approach avoids external requests but raises questions about extensibility and best practices. Should we revive HTML imports, embrace ES modules, or find a common model for handling templates and styles? Is inlining templates a reasonable solution? I'm looking for community input on how to balance performance and developer experience when deploying web components.
This blog post explores the potential of WebAssembly (Wasm) for full-stack development, allowing code sharing between client and server. I discuss how Wasm could enable progressive enhancement for web APIs like the Shape Detection API. Using this API as an example, I illustrate how a C-binding library like OpenCV, compiled to Wasm, could be used on both client and server to provide consistent functionality regardless of native browser support. This approach involves creating a wrapper around OpenCV and the target web API to bridge the gap between them. I express my excitement about Wasm's potential to simplify deployment and maintenance by enabling the use of a single binary across different environments.
In this post, I share a simple client-side JavaScript PubSub system I built. Motivated by the Not-Invented-Here syndrome and the desire for independent UI components, I created a lightweight event manager called EventManager. It allows components to communicate without direct dependencies by publishing and subscribing to named events. While similar to tools like Redux, this approach avoids separate state management, leveraging the browser's existing state. The code is available on GitHub.
I'm excited to share that barcode detection is now available in Chrome Canary via the Shape Detection API! This feature, along with QR code detection, offers a standardized way to access device hardware and bridge the physical and digital worlds. It's especially useful for mobile, eliminating the need for special apps just to scan barcodes. The API is simple: use BarcodeDetector.detect() with an image input to get a promise resolving to a list of barcodes. I've already integrated this into my QR Code Scanner App, and the ability to use it in worker threads is a huge bonus. It's a very promising addition to the web platform and I'm looking forward to seeing what people build with it!
In this follow-up post, I've revised my blog's Service Worker and caching strategy to address previous issues, particularly the Firefox incompatibility due to the use of waitUntil and a misunderstanding of cache.put. The updated strategy now correctly fetches from the network, caches the result, and serves content from the cache, falling back to the network request if not found. The code has also been improved for readability and reliability.
I'm excited about the new experimental Shape Detection API in Chrome Canary! It provides a simple JavaScript API for face and barcode detection, leveraging underlying hardware for performance. This opens up new possibilities for web apps, from faster face detection and profile picture cropping to real-time tagging and optimized facial recognition. While currently only available in Chrome for Android (desktop support coming soon), I've shared a demo on JSBin. I also discuss strategies for progressive enhancement to ensure broader compatibility, including server-side detection, client-side JavaScript libraries, and the potential of Web Assembly. This API has the potential to revolutionize object detection performance on the web, and I'm particularly keen to see its impact on barcode scanning apps like my own QR Snapper.
Tired of typing in usernames and passwords? So are your users. Autofill helps, but the Credential Management API gives developers more control. It lets you securely store and retrieve user credentials, simplifying logins with just a couple of taps. This Chrome-only API allows access to a PasswordCredential object, rather than raw passwords. It works with other improvements like proper autofill fields (email, username, new-password, current-password) and offers a potential future where landing and login pages are obsolete. Imagine a web where users stay logged in seamlessly, only re-authenticating when necessary. This post covers how to implement the API, including a demo and sample code. Plus, explore how it might combine with the Web Payment Request API to streamline e-commerce.
I explored building a progressively enhanced sharing web component using Shadow DOM. My focus was on URL visibility and manipulation within web apps, even when they behave like native applications. The component is designed to be customizable and work across browsers, with or without JavaScript, by leveraging existing elements like anchor tags. It uses a Twitter intent as a fallback sharing mechanism when Web Components aren't supported. I'm excited about the potential of web components, even without widespread custom element support.
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 spent this week in India doing more research about Web Development in India and how mobile is changing that. Publically at least it is not rosey, app development and app thinking is very high whislt building for the web with mobile in mind is very low.
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.
I wanted a traffic light system on iwanttouse.com to visually represent feature support. Initially, I used simple CSS classes like .good (green), .ok (amber), and .bad (red), but this required clunky conditional logic to handle the color transitions based on percentage support. Paul Lewis suggested using HSL which allows for smooth transitions between red, amber, and green by adjusting the Hue value (0-359). Now, I can dynamically set the color using element.styles.color = \"hsla(\" + ((percentage / 100) * 90) + \", 50%, 50%)\"; which maps the percentage support to a Hue value between 0 (red) and 90 (green).
LocalStorage is a flawed API with poor querying, performance issues, limited storage, inconsistent event handling, and locking problems. Its only advantages are its simple semantics and browser support. Continued use of LocalStorage hinders the development of robust offline and client-side web apps. We should transition to IndexedDB, a superior alternative. I've demonstrated this by converting the BackboneJS TodoMVC example from LocalStorage to IndexedDB using Julien Genestoux's adapter. This involved a few configuration changes, highlighting the ease of adopting IndexedDB, which is our only viable path forward for client-side storage. Let's abandon LocalStorage and embrace IndexedDB to unlock the potential of offline web apps.
I'm excited about Mozilla's consideration of implementing webkit prefixes and starting a conversation around this. I believe that switching prefixes should only happen if the vendor is willing to drop their existing prefix in favor of another for the sake of standardization. Developers often target specific prefixes based on the dominant browser for their target audience (like WebKit for mobile). While I appreciate Remy Sharp's take, I disagree with his proposed solutions. I think prefixes should be dropped only when committing to another, and that the "production ready browser" idea is unrealistic. We should focus on educating developers on tools for handling prefixes.
It's been an incredible two years at Google! The first year was amazing, but the second year was even better. I spoke at Google IO, traveled to numerous countries giving presentations, and saw Web Intents become a real project. I even got misquoted on TechCrunch! I also spent more time in Liverpool and worked with developers throughout the UK. I'm excited about the future and continuing to improve the user experience on the web.
Web Intents is a new project designed to solve the problem of web application integration. Inspired by Android's intent system, it allows developers to build features without needing to integrate with every possible 3rd party service. Web Intents lets users choose their preferred service for actions like image editing or sharing. The project has been revised with a simplified API to make integration easier for developers, requiring minimal code. Service registration is done via a new tag, and client initiation is also streamlined. Check out the examples at http://examples.webintents.org/ and share your thoughts as we work with Mozilla to refine this game-changing approach to web development.
I have mixed feelings about SVG. I find it complex and requiring specific tools, and its integration with the web is clunky. It feels like a context switch between HTML and SVG DOM. However, SVG is scalable, vector-based, and has powerful graphical capabilities like filters and paths, enabling things not possible with regular web technologies. I wish path could be a CSS property, simplifying its usage and allowing text or even block elements to be rendered along a path. This would be more efficient than embedding SVG within HTML elements.
During my "Mobile Web Development: From Zero to Hero" talk at Google I/O, a question came up about client-side data storage now that WebSQL is deprecated. While IndexedDB is on the horizon, what are developers using today? I shared my preference for Lawnchair, a simple key-value store abstraction that's easy to use and perfect for many situations. While I didn't use it in the IO Reader app due to late-stage project constraints and the sufficiency of localStorage, I generally prefer using such libraries. I'm interested in hearing from others. What data storage wrappers or techniques do you prefer when building web apps?
I've been working on Web Intents, a project to simplify client-to-client service discovery and communication on the web using technologies like IFrames and SharedWorkers. It addresses the current issue of apps needing to integrate with third-party services, which restricts user choices. However, I recently discovered a similar project, Web Introducer, also by a Googler. It tackles the same problems with more in-depth security considerations. So, I'll be shifting my focus to contribute to Web Introducer. Web Intents remains a valuable example of using SharedWorkers and messaging effectively within web apps. More on Web Introducer and SharedWorkers coming soon!
The Chrome Web Store is launching in the Netherlands with integrated support for Dutch sellers! Join the Dutch GTUG on March 2nd, 2011 at 7pm at Google Amsterdam for an event about HTML5 and the Chrome Web Store. I'll be showcasing new HTML5 features and discussing how to leverage the Chrome Web Store to reach more users. The event includes Q&A and lightning talks, so come prepared to demo your projects! Space is limited, so sign up now!
I'm excited to introduce "commently," a simple Buzz-based commenting system for blogs and websites. It synchronizes with your Buzz feed, allowing you to easily embed comments. Just replace the placeholders in the provided javascript snippet with your Buzz username and the URL-encoded title of your blog post, and customize the handler function to display the comments on your site. Check out this post for a quick "Getting Started" guide.
In appmator, I wanted to avoid traditional web elements like 'Save As' buttons. Instead, I implemented a drag-to-desktop feature using Chrome's drag-and-drop functionality. By setting a 'DownloadURL' with a data URI or regular URL on the 'dragstart' event, users can drag data directly to their desktop. This method bypasses the need for a save button. The code example demonstrates how to use the dataTransfer.setData() method with the DownloadURL type. It leverages the JSZip library to generate ZIP files as data URIs for dragging. This approach is Chrome-specific and has no feature detection available.
I'm super excited about the new classList API! It's like having jQuery's class manipulation, but built right into the browser. This means we can easily add, remove, toggle, and check for classes without messy string parsing. Currently supported in Firefox 3.6+ and Chrome 7+, the classList API uses the DOMTokenList interface and is way more convenient. I'll have a better demo up on the blog soon!
Styling file input elements has always been tricky due to browser inconsistencies. WebKit-based browsers offer a clever way to style these elements. You can style the text and color of the file input using standard CSS. Additionally, the ::-webkit-file-upload-button pseudo-element allows customization of the OS-specific button's appearance, like changing it from rounded to square, going beyond basic styling.
In a previous post, I discussed the lack of a direct method in JavaScript for deleting arbitrary elements from an array. I had attempted a solution, but misread the documentation for Array.prototype.splice. While I believe my solution is still useful for removing elements without needing to find their indices first, splicedoes allow removing arbitrary elements by index. To remove one element at a specific position, use values.splice(index, 1). This modifies the original array and returns an array of the removed elements. Thanks to @dezfowler for pointing this out!
I recently discovered a cool trick in WebKit that lets you use a canvas element as a background image, which opens up a ton of creative possibilities. It's a powerful feature, allowing for dynamic, programmatic manipulation of background images. I've included a simple demo showing how to draw a square on a div's background, but imagine the possibilities for games or complex animations! While currently WebKit-specific, I hope other browsers will adopt it soon. More demos to follow!
I'm excited to announce I'll be speaking at the Berlin GTUG on July 15th, 2010, about building HTML-based applications. The talk will explore the differences between web pages and true applications, with plenty of examples. This will be my first time in Berlin, and although my visit is short, I'm looking forward to it! Slides and photos to follow.
I've decided to create iforgive.eu, a C# ASP.Net 2.0 sample site, and document the entire process on my blog. This includes design, development, refactoring, and even my mistakes! I'll begin by outlining the site's purpose, planning its design, and employing a TDD approach. Follow along as I build this site from the ground up!
This blog post explores the techniques used by high-traffic websites like Digg and Zooomr to handle large numbers of simultaneous users. It delves into performance optimization strategies to improve website efficiency and prevent crashes under heavy load. Click the link to learn more.
A big thanks to the first person who Dugg my Ajax Tagger on Digg (I think it was Zoodle)! I'd love to hear your feedback on it, good or bad. Let me know what you think! :)
This post explains AJAX (Asynchronous JavaScript and XML) and its use in .NET. AJAX allows web pages to update small sections without reloading the entire page, improving user experience. Traditional ASP.NET (1.x) struggles with this as it's designed to reload entire pages. However, .NET's flexible request pipeline allows plugins/HTTPHandlers to manage AJAX requests, enabling developers to execute specific methods within a page. The post lists several .NET AJAX frameworks, including AjaxPro, Arshad.NET, and AjaxAspects, and points readers to ajaxpatterns.org for more options.
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've added a custom search provider to my blog using Google Search for Internet Explorer 7 Beta 2 users. It lets you easily search my site's content. The provider is set up using an OpenSearch XML file linked in each page's header. Not sure about Google's terms on this, so I'll remove it if there's an issue. Hopefully, this example helps others implement search providers.
I've just downloaded Beta 2 of the IE Developer Toolbar and while it's incredibly useful for diagnosing web page issues, there are still some bugs that need fixing. The element outlining in frames and scrollable divs is completely off, and re-enabling CSS after disabling it doesn't render the page correctly. If these issues are resolved, it has the potential to be one of the best developer tools out there.
In a previous post, I shared a regular expression for extracting CSS class names, and a reader asked for clarification. This post addresses the question with a corrected regex and C# code example using Regex.Split and Regex.Match. The regex is designed to capture class names from CSS, even those containing escaped characters, and the example code demonstrates splitting a CSS string by class names and suggests using Regex.Match for obtaining the names themselves.
As part of my ongoing project to build a CSS 2.0 parser in C#, I've developed a regular expression based on the CSS 2.0 specification to extract class names from CSS files. This regex is a step towards creating a complete CSS 2.0 parser, and I plan to develop more regular expressions for other CSS elements in the coming days. Check out my related side project about creating a CSS 2.0 parser in C# for more context.
I've updated the AJAX Tagger and moved it to a new subdomain: ajaxtag.kinlan.co.uk. This should make it easier to access. The old location (www.kinlan.co.uk/AjaxExperiments/AjaxTag2) will still work and be updated alongside the new address.
My site, DeliTag, is being flagged as suspicious by IE7, likely due to the username and password fields for Delicious. I've created a privacy statement to address concerns about how this information is used. In short, the credentials are passed directly to Delicious without any further processing. The transmission is unsecured, mirroring Delicious's own security. The privacy statement at http://www.kinlan.co.uk/Deli/DeliPrivacy.htm offers more details. Please contact me with any questions.
I'm struggling to understand the practical uses of OPML, especially given the inconsistent use of attributes like 'type', 'url', and 'xmlurl'. While I'm developing a JavaScript OPML object model for my own projects (like a tagging system where OPML stores related links for blog posts), I haven't found a clear standard for defining outlines. It seems like the 'standard' emerges from popular usage rather than formal specification. I'm particularly interested in how to determine the file type of items within an OPML outline, as my current application only uses links for pages and images (feed support is still pending). The lack of clear semantics in OPML makes it difficult to build dynamic applications that can 'mash up' content from different sources based on the OPML structure.
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.
The IE team has announced that some CSS hacks used to fix issues in IE5 and IE6 won't work in IE7. This means web developers targeting IE7 will need to update their sites to address these breaking changes. The IE team encourages developers to check for common CSS hacks and replace them with standards-compliant code or conditional comments. While a CSS-based solution would be ideal, there currently isn't a standard for this issue, prompting a call to action for developers to update their code and support the move towards better standards compliance.
I'm considering compressing Yahoo Search results from my proxy, as suggested in a Yahoo Developer Blog post. I'm unsure if it's easy, worthwhile, and where to implement it (client-side or proxy-side). I'll need to handle browsers without compression support. Any advice?
I'm developing a complex new version of the AJAX Tagger (2.0) with enhanced features for adding data to journal entries. However, I'm curious if there's still interest in a simpler version like the original AJAX Tagger. Please share your thoughts and comments!
I'm excited to announce the release of the IE Developer Toolbar, a free tool for exploring HTML documents in both IE6 and IE7. It offers features like DOM exploration, disabling IE settings, viewing element information, outlining, image control, resizing, a ruler for pixel-perfect measurements, and standards validation with links to W3C specs. Download it now and share your feedback and bug reports!
I just read on the IE Team's Blog that Internet Explorer 7 will have native support for XMLHttpRequest and a rebuilt, windowless select element. This is huge! Native XMLHttpRequest means no more ActiveX security issues. And a windowless select element? Finally, we might have proper layering and styling. Fingers crossed these features make it into Beta 2!
I just got my first comment from a stranger, Gaby de Wilde, on my AJAX Tagger! He even used it on his site. I'm grateful for the feedback and plan to incorporate his suggestions in the next version. Check out his blog to see it in action, and please send me any feedback you have!
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!
In part 8 of "Failures of my First AJAX Application," I discuss the lack of traffic generated by the application. Initially, I hoped for ad revenue, but I've realized that user engagement is more important. My focus now is on improving the application and planning a marketing campaign to highlight its benefits.
In this final part of "The Failures of my First AJAX Application" series, I reflect on the cross-browser compatibility issues I encountered. Focusing on Internet Explorer during development led to problems in Firefox, particularly with security errors (cross-domain data retrieval) and differences in the XML DOM model. The key takeaway is to consider cross-browser support from the outset, anticipating discrepancies between browsers and coding around missing features, similar to CSS development. The next version will prioritize cross-browser compatibility, potentially including Safari. This series has been invaluable for shaping the requirements of the upcoming version.
This is the sixth part of my series on the failures of my first AJAX application, AJAXTagger. While I initially hoped it would be useful for everyone, it mainly ended up benefiting just me by simplifying the tagging process for my blog posts. Although it didn't meet my initial grand expectations, it was a valuable learning experience. The next version will prioritize my needs but also consider features that could benefit other users, ultimately adding value for my readers.
In this part of my series on my first AJAX application, I discuss how my initial hopes for AJAX as a solution to bandwidth and UI problems, and for speed improvements, weren't fully realized. The first version, which incorporated Technorati stats and Yahoo's TermExtraction API, was slow due to sequential queries and Technorati's performance. I removed these features because I wanted a fully rendered page, which negated AJAX benefits. The next version will be fully asynchronous, with a request manager for trickle filling and background processing. Check out my AJAX Technorati Tagger to see what I'm aiming for.
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.
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.
This blog post introduces a Perl proxy script that leverages the Yahoo Related Suggestions API. Given a search term, the script queries Yahoo and returns a list of related search terms. This can be used to enhance search functionality by providing users with additional relevant search options. An example is given using the term "Kinlan" and the post links to a previous entry describing a proxy for the main Yahoo search API. The provided code snippet demonstrates how to construct the API call using LWP and CGI, requiring a valid Yahoo App ID.
A List Apart, a popular website found via Technorati, uses Ruby on Rails. I'm curious about Ruby on Rails and its benefits for web development. The site's neutral color scheme and articles are visually appealing, possibly utilizing color theory.
This blog post discusses the ideal length of blog entries. It argues that both too short and too long posts can be detrimental to a blog's success. Short posts can appear superficial, while overly long ones can bore readers. The author aims for a balance, using shorter entries for critiques and longer, focused articles for more in-depth topics. This particular post, part of a series on the author's first AJAX application, exemplifies this approach by being broken down into smaller, manageable segments.
In this third part of my series on my first AJAX application, I'm diving into the power of the Yahoo! API. It's been a learning experience, and I'm incredibly impressed with how much it offers compared to Google's. I've been exploring the Term Extraction and Related Searches APIs, and I'm starting to think about how to use the Contextual Search API. The Term Extraction API is great for pulling out keywords, while the Related Searches API helps me find relevant search queries. My app combines these to analyze blog posts and generate related searches. I'm hoping to use the Contextual Search API to add targeted search results. Future versions will incorporate more APIs, possibly from Technorati, to enhance functionality. Stay tuned!
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.
In this first installment of a series about my AJAX application journey, I'm sharing my initial success: learning to think asynchronously. The current app takes user-entered text, sends it to a Yahoo web service (via a local Perl script), gets "interesting" words, and then makes synchronous calls to Technorati for tag counts. This synchronous approach locks the browser, especially with multiple tags. The next version will use a queue and multiple asynchronous XMLHttpRequest objects managed by a thread manager to avoid browser lock-up. This will create a more responsive app where results appear as they become available. Key requirements for v2 include full asynchronicity, XMLHttpRequest management, a generic work queue, background task indicators, and a non-blocking UI. I'm also planning to develop a reusable object model.
My first foray into Ajax was a mixed bag, yielding both valuable lessons and frustrating setbacks. On the plus side, it sparked a deeper understanding of asynchronous coding, cross-browser compatibility (especially between Firefox and IE), and the potential of APIs like Yahoo! and Technorati. It also reignited my interest in Perl and prompted reflection on my blogging practices. However, the application fell short in several areas: it lacked search functionality, didn't reduce bandwidth, had a poor visual design, and wasn't user-friendly or impactful enough to generate feedback or traffic. Moving forward, I'll share my design process and desired improvements, starting with a clear requirements document. I'm eager to learn from this experience and create a more effective application.
