Daniel De Laney 5 days ago

I built a timer I can’t fail to set

Have you ever gotten to the end of a long work day and realized you’re no closer to your goals? I have. The problem, counterintuitively, was lack of interruption. Sure, I was doing a lot of stuff. But I never paused to ask whether I was doing the right stuff. Or whether my approach was working. Or if I was spending the right amount of time on it. So I needed a reliable way to interrupt my “unproductive productivity,” and refocus on what’s important. The obvious first-thought solution was a timer. Unfortunately, if you use timers a lot, you learn to dismiss them reflexively. And it’s really easy to forget to set the next timer. A week later I’d think “Hey, that timer idea really worked, I should get back to that.” And then I didn’t. So I built a new kind of timer . It does 2 unique things: Every few minutes it asks me the same question: “What will you focus on?” I answer in a word or two, hit enter, and keep working. Having to name my intention keeps me fully aware of my trajectory. If I’m in danger of drifting, it’s obvious. If I’m flying on something simple and don’t need to reorient frequently, I can set the timer for a longer duration, maybe 30 minutes. But if I’m working on something more open-ended, I might tighten the leash all the way down to 3 minutes. Then I can’t get off track. Unlike a regular timer, I can’t fail to set the next one. If I don’t restart it promptly, the screen gradually becomes less readable until I do. If I wanted to avoid answering, I’d have to make a conscious decision to close the app just so I could see the screen clearly. I’d have to decide to be less productive. I never do. This small intervention has worked beautifully. Not only am I catching unproductive divergences earlier, I’m noticing fewer of them over time. It seems to be training me to do more and better thinking. It’s not a replacement for a more extensive journaling practice. I love to journal, but that only happens once per day. What about the rest of the day? There’s a lot of benefit in reflecting more often than once every 24 hours. If you’re running macOS, I recommend giving Intention a try. I use it every day, and I think it’s the superior way of working. My timer asks me a question. It gradually blurs my screen if I don’t set a new timer.

Daniel De Laney 1 months ago

Free software scares normal people

I’m the person my friends and family come to for computer-related help. (Maybe you, gentle reader, can relate.) This experience has taught me which computing tasks are frustrating for normal people. Normal people often struggle with converting video. They will need to watch, upload, or otherwise do stuff with a video, but the format will be weird. (Weird, broadly defined, is anything that won’t play in QuickTime or upload to Facebook.) I would love to recommend Handbrake to them, but the user interface is by and for power users. Opening it makes normal people feel unpleasant feelings. This problem is rampant in free software. The FOSS world is full of powerful tools that only have a “power user” UI. As a result, people give up. Or worse: they ask people like you and I to do it for them. I want to make the case to you that you can (and should) solve this kind of problem in a single evening. Take the example of Magicbrake , a simple front end I built. It hides the power and flexibility of Handbrake. It does only the one thing most people need Handbrake for: taking a weird video file and making it normal. (Normal, for our purposes, means a small MP4 that works just about anywhere.) There is exactly one button. This is a fast and uncomplicated thing to do. Unfortunately, the people who have the ability to solve problems like this are often disinclined to do it. “Why would you make Handbrake less powerful on purpose?” “What if someone wants a different format?” “What about [feature/edge case]?” The answer to all these questions is the same: a person who needs or wants that stuff can use Handbrake. If they don’t need everything Handbrake can do and find it bewildering, they can use this. Everyone wins. It’s a bit like obscuring the less-used functions on a TV remote with tape. The functions still exist if you need them, but you’re not required to contend with them just to turn the TV on. People benefit from stuff like this, and I challenge you to make more of it. Opportunities are everywhere. The world is full of media servers normal people can’t set up. Free audio editing software that requires hours of learning to be useful for simple tasks. Network monitoring tools that seem designed to ward off the uninitiated. Great stuff normal people don’t use. All because there’s only one UI, and it’s designed to do everything. 80% of the people only need 20% of the features. Hide the rest from them and you’ll make them more productive and happy. That’s really all it takes.

Open Source

Daniel De Laney 8 months ago

Objectivity is superstition

An objective, external world is a non-falsifiable assumption. Experience is the only reality which is detectable. Materialism is religious faith. Modern civilization is optimizing materials, not experiences. The only rational goal is maximizing satisfaction. The prevailing theory is that our subjective experiences correspond to an external reality. However, they may simply be subjective through and through. That which we claim to be evidence of external reality is actually subjective experience, which may or may not have an external and objective cause. Any test devised to prove objectivity is evaluated within subjectivity and therefore does not require objectivity to explain the result. Some object to this, claiming that the consistency of experience is best explained by an external world. However, consistent experience does not require any external mechanism, let alone the specific one we have assumed. Claiming that belief in an external world is simpler is like claiming that belief in God is simpler; in truth we are inventing something vast and complex without evidence and agreeing not to question it. This is not science, it is a substitute for epistemic humility. Much as dreams appear consistent while dreaming, that which we consider waking experience may not actually be as consistent as we believe. However, questioning this is unproductive reasoning because it undermines the value of reason itself. We must assume our experiences are rational and consistent, or else give up thinking altogether. Whatever experience is, it is real and directly perceptible, unlike objectivity. Claims that experience is an illusion presuppose an objective world to which experience does not correspond. Pragmatic truth is supportable, correspondence is not. If an objective world can’t be proven, neither can we prove that knowledge does or does not correspond with it. That which produces a consistent effect in experience is useful in influencing experience in the desired way, therefore science is useful. Just as we once invented a spirit world to help explain our experiences, we invented an objective world for which there is similar quality evidence. Both are assumed to explain experience, yet neither is directly known. The assertion that matter gives rise to experience is no more compelling than the assertion that experience gives rise to matter. The assumption of an external world has zero explanatory power, as consistent experience does not require it. Materialism is superior to classical religions in that it responds to pragmatic truth, but it still accepts unsupportable metaphysical claims and regards them as unquestionable. By contrast, noting that we have experiences does not require extrapolation or invention. Focus on economic metrics has allowed us to make tremendous progress in reducing starvation and otherwise improve the experience of the least fortunate. Nonetheless, the subtle error of conflating material improvement with improvement in well-being has consequences. In advanced societies, increases in abstract indicators of material wealth like GDP have been accompanied by negative changes in consciousness: stress, social disconnection, and increased suicide. The materialist assumption that improving external conditions will always trickle down to better experiences is demonstrably unreliable. Often, this assumption results in methods which improve economic indicators by reducing experiential well-being, and in these cases it is worse than nothing. In addition to misallocating its priorities, modern civilization also conditions people to feel powerless over their own well-being. As materialist structures (corporations, governments, economic systems) become more dominant, individuals are increasingly absorbed into mechanisms designed to optimize external conditions rather than subjective experience. People come to believe that their quality of life is dictated by forces beyond their control. The best way to improve experience is to optimize it directly. Long-term positive changes in consciousness are what is best in life. If a person achieves material or hedonistic aims but is unsatisfied in the long term, they are having a negative experience and are working against themselves. Secure, nourish, nurture, and build yourself and your community. Seek what is satisfying and aesthetic—that which feels good and true and beautiful. Unlike materialist assumptions, this requires no external faith, only a direct commitment to improving the reality we actually experience.

Daniel De Laney 10 months ago

Chat is a bad UI pattern for development tools

Code forces humans to be precise. That’s good—computers need precision. But it also forces humans to think like machines. For decades we tried to fix this by making programming more human-friendly. Higher-level languages. Visual interfaces. Each step helped, but we were still translating human thoughts into computer instructions. AI was supposed to change everything. Finally, plain English could be a programming language—one everyone already knows. No syntax. No rules. Just say what you want. The first wave of AI coding tools squandered this opportunity. They make flashy demos but produce garbage software. People call them “great for prototyping,” which means “don’t use this for anything real.” Many blame the AI models, saying we just need them to get smarter. This is wrong. Yes, better AI will make better guesses about what you mean. But when you’re building serious software, you don’t want guesses—even smart ones. You want to know exactly what you’re building. Current AI tools pretend writing software is like having a conversation. It’s not. It’s like writing laws. You’re using English, but you’re defining terms, establishing rules, and managing complex interactions between everything you’ve said. Try writing a tax code in chat messages. You can’t. Even simple tax codes are too complex to keep in your head. That’s why we use documents—they let us organize complexity, reference specific points, and track changes systematically. Chat reduces you to memory and hope. This is the core problem. You can’t build real software without being precise about what you want. Every successful programming tool in history reflects this truth. AI briefly fooled us into thinking we could just chat our way to working software. We can’t. You don’t program by chatting. You program by writing documents. When your intent is in a document instead of scattered across a chat log, English becomes a real programming language: The first company to get this will own the next phase of AI development tools. They’ll build tools for real software instead of toys. They’ll make everything available today look like primitive experiments. You can see your whole system at once You can clarify and improve your intent You can track changes properly Teams can work on the system together Requirements become their own quality checks Changes start from clear specifications

AI Programming

Daniel De Laney 6 years ago

Data Center Monitoring

The computing power that runs the world is hidden away in data centers that few people get to see. While many data centers are lights-out operations most of the time, people are still needed to update them, keep them running, and prevent and resolve outages. Those people need to know where their critical assets are in the labyrinth that is their global data center network. They need to know when areas get too hot, or get so cold and humid that condensation becomes a worry. In addition to data centers, large enterprises will also have smaller compute sites scattered across the nation or the world. Those sites are often physically unmanned with poor visibility into the health of critical systems. Operators need to know when potential issues arise and how to prioritize them. I help solve both of those problems. Every design challenge starts with research. I put together extensive design research presentations with photos and video inside of real, working data centers. These included profiles of specific data center operators, personas/archetypes extracted from them, and detailed notes on pain points that customers face. Due to confidentiality concerns, heavily redacted and anonymized excerpts are available for eyes-only review upon request. Once the context and specific challenges are understood, it’s time to start rapidly prototyping solutions. I like to use sketches to validate ideas quickly, without a lot of investment in the wrong direction. Once I’ve put ideas in front of customers and gotten enough feedback to be confident in a direction, I produce specs for engineers to build the real thing. This frequently involves extensive annotation. In many cases the sketch is sufficient because the visual design of reusable elements has already been defined as part of a component library or as part of the product design guidelines. Of course, while sketches can convey functionality, if new elements are used for which I don’t already have a visual design specification, it’s important to provide fully realized mockups. Once the appropriate specifications are produced, I work extensively with software engineers. I write stories in JIRA, collaborate to find clever solutions to performance problems on Slack, and even contribute CSS here and there. Whatever I can do to ensure that the finished product is as good as our intentions.

DevOps CSS Design

Daniel De Laney 6 years ago

Artificial Intelligence

In 2018 I worked with argodesign on an artificial intelligence client project, and Fast Company published an article on our work: This Is The World’s First Graphical AI Interface . For confidentiality reasons I can’t publicly go into more detail on the project than to link to that article. For the full case study, please contact me at [email protected] . During my time at argodesign we held an event with AIGA, the professional association for design, during which the team explained our point of view on artificial intelligence, and the way we approached designing interfaces for new technologies.

Design AI C#

Daniel De Laney 7 years ago

Secure File Transfer

During my time at frog, I lead a team of designers to transform a secure file transfer app owned by IBM. In addition to leading the team in Austin I helped manage designers working out of frog’s new studio in India, reviewing their work and setting priorities. frog itself has a long and storied history in design, and I felt lucky to work with such an amazing team of serious veteran designers. The first part of the program was spent on research, interviewing stakeholders and gaining an understanding of how the product worked and where it needed to go. User research was conducted remotely with a variety of large clients in finance. Our research showed that the short-term focus needed to be on fixing some glaring UI issues, whereas the long-term focus should be on evolving the software to be centrally managed. I spent time guiding the visual designers on my team, helping them to understand the unique requirements associated with this kind of product. Special attention needed to the meaning of color in the context of an secure enterprise product, and IBM has strict brand and accessibility guidelines.

Design Security

Daniel De Laney 7 years ago

Maritime Marketplace

Business

Daniel De Laney 7 years ago

Atomic Design in 1998

When you hear “atomic design,” you probably think of Brad Frost. Interestingly, he was not the first person to develop that method of delivering design as components, or even the terminology. Brad published his atomic design article in 2013. While digging through the archives at frog , I’ve learned that Mark Rolston developed and applied an atomic framework as early as 1998. The description found on the Index page, now 20 years old, embodies every bit the same spirit as the recent design systems movement: The Dell Design Center helps Dell employees and creative vendors maintain a single, global online brand for Dell.com. By adhering to the design methodology and object guidelines in the Dell Design Center, anyone can create and implement new content without diluting the Dell global online brand. Part reference manual, part cookbook, part toolbox, the Dell Design Center is an up-to-date, online repository of the imagery and methodology needed for Dell.com construction. When I asked Brad, he said that he wasn’t familiar with the earlier work done at frog. “For what it’s worth,” he remarked, “modular thinking in design is nothing new, and I acknowledge as much in my book.”

Design

Daniel De Laney 8 years ago

Resource Management

The client came to us with a problem: They had paid for a custom tool that didn’t do what they needed. They had expected ease and efficiency. What they got was frustration and unnecessary manual effort. What they needed was a tool that could help them plan. How much more work could their team take on right now? Did their team have the capacity to complete their projects next October? My job was to design a tool that worked for them, not against them. My first step was to understand where everything had gone wrong. Who were their users? What were their goals? From there I could see the right way forward to the tool they wished they knew how to ask for. A problem well-understood is half solved. That’s why research is the most important part of my process. I discovered that humans were doing hours of tedious mental labor that a computer could do for them. Their software wasn’t presenting the right information at the right time. Smart planning requires seeing the big picture and specific details at the same time. We had to display a lot of information at once and help them make sense of it. There are many ways to do that wrong and only a few ways to do it right. I went through dozens of sketches before arriving at a solid direction. While the interface would have to be flexible, it would also need to lead the user to the right conclusions. By providing contextual tips, we could cut guesswork and make the user more efficient. One of the biggest deficiencies of the old system was that it didn’t alert users to upcoming issues. It didn’t offer any help solving them, either. These major omissions defeat the purpose of a planning tool. Instead of making the user find problems on his own, I designed an alert system. Any conflict or discrepancy is obvious when the user first opens the product. (I’ve recommended e-mail alerts as well.) When working with dense data, I strip everything down to the essentials. It’s hard enough to see what’s going on in a windstorm of information without having to contend with decoration. Often, designers use still images to communicate screen designs. In my experience, clickable prototypes are non-negotiable. Nobody knows how a product works until they see it working. (Design nerd footnote: If you haven’t tried the Craft plug-in for Sketch, you should.) Engineering is putting the real thing together now. Preliminary testing has gone great. I’ve designed solutions to their big problems, plus enhancements they didn’t know they needed. The stakeholders can’t wait to see the product working for real. I’ll keep you posted.

Design

Daniel De Laney 8 years ago

Network Engineering

When you type “google.com” into your browser and press the Enter key, what happens? How do you get to Google? Where is Google? Is there a single data cable between you and Google? The answer is that there are lots of computers called routers between your device and Google. The routers figure out which way to direct you. Your device connects to a router, which connects to another router and then another. After a long series of “hops” from router to router, you arrive at one of Google’s computers: Those routers need engineers to pay attention to them and fix them when they break. When one computer can’t talk to another, they need to find out why. They need to find the route between the two computers, identify the problem along that route, and fix it. When too much data is going through the network, the routers begin to buckle under the load. Engineers have to analyze the network to understand how to expand it. The product I designed helps engineers in Network Operations Centers fix problems. It listens to the routers in the network and records information about them. Then it tells the engineers what to pay attention to, how to fix any problems that arise, and how to plan for the future. The company I was working with already had the technology to listen to the network. They didn’t know how to show what they recorded in a useful way, though. The user interface was raw, unprocessed data: My first job was to understand what network engineers do. Then, I had to show them complex data in a comprehensible and usable way. Finally, I had to make it less ugly. To do that, I talked to network engineers to understand the job they do and the problems they solve. I found out what they need to know about the network to do their job. And I learned what the difficult parts of their job are, so that I could make them easier. Network engineers go to school for many years to do their job. I didn’t have time to learn everything there is to know about being a network engineer. What I could do was understand specific problems well enough to build tools to solve them. Once I understood a problem, I began to sketch ideas for user interfaces that solved it. Then I used tools like InVision to make clickable prototypes from the sketches. Network engineers could use those prototypes to understand new ideas. That allowed us to test user interfaces before we actually built them. We held many design reviews and collected a lot of feedback. We explored dozens of possibilities before deciding on a direction. I kept working on the prototypes until everyone was sure they showed exactly what we needed to build. Once the prototypes were complete, it was time to work on the visual design of the user interface. To show the nuances of form and color, I made high-quality versions in Balsamiq Mockups or Sketch: Somebody had to write the code to make these ideas real and it wasn’t going to be me. Luckily, the company had many talented developers. I did my best to make their job as easy as possible. When designs required lots of precise details, I liked to give them finished HTML and CSS. If a new design element or pattern was likely to appear in many places, I liked to define that element in one place. The impact we made was huge. We increased the number of users from 1 or 2 network engineers per customer to 20–30. We expanded sales and increased renewal rates. Before, it was hard to convince potential customers to look at the product. Afterward, they approached us. Before, users asked our support team to use the product for them. Afterward, they knew immediately what they were looking at and how to use it. We made a big difference that the whole team can be proud of.

HTML CSS DevOps