All parts to be retrobrighted need to be very thoroughly cleaned in warm soapy (dishwashing fluid) water, very thorougly rinsed and completely dried. I would also recommend wiping everything down with alcohol lens wipe pads while wearing single-use gloves to remove any possible grease.

I used a plastic tub that was big enough (the AEK is ginormous) and filled it with about a gallon and a half (5.7L) of 3% hydrogen peroxide (you can buy this from e.g. Amazon or probably cheaper locally) and another half gallon (1.9L) of distilled water.

Left partially covered out in about 8 hours of Arizona sun. It depends on the amount of yellowing and the specifics of the plastics involved and the local sun energy on how long this takes — it may be just a few hours but it could be multiple days for your use case.

The liquid reached a temperature of roughly ~110ºF (~45ºC).

3% hydrogen peroxide is very safe, people use it e.g. for medically prescribed gargling. (Still you want to use gloves and eye protection when handling it!)

It’s important to 1) cover everything completely with the liquid so nothing sticks out 2) from time to time move parts around and agitate the liquid (move the box back and forth quickly) to dissolve oxygen bubbles*. Otherwise you might get uneven results as bubbles stick to the plastic.

*Hydrogen peroxide will harmlessly dissolve into oxygen and water during the process.

If you live somewhere sunny you won’t need UV lamps or heaters.

If partially covered, even direct sun won’t heat up the liquid or parts enough for them to bend out of shape.

If you need to provide UV/heat yourself, don’t let the liquid exceed 120ºF/50ºC so your plastic won’t get soft and get out of shape.

If you do this inside, you should cover the plastic box airtight and lock it in e.g. a bathroom. The 3% hydrogen peroxide will likely not smell bad but it can be a danger to kids or pets if ingested or on skin contact.

You can likely reuse the same hydrogen peroxide/distilled water liquid mixture in the future but you will have to replenish the losses.

Otherwise, have fun!

P.S. And for the love of science don’t follow ridiculous people’ advice (like the two-bit guy who melts old computers at 160ºF/70ºC with way too much hydrogen peroxide).

Self-loathing has a long and celebrated history in Silicon Valley. Here’s my top 5 most cringiest songs brought to you by the tech industry.

#5 “Are you keeping up with the Commodore?” (1980s)

Let’s get into the mood with some com-pu-ter ter-mi-no-lo-gy.

#4 “On your mark! Get set! We’re riding on the Internet” (1990s)

Using Netscape to browse to that MTV world wide web homepage! I’m unsure though about the advice that “your parents or teachers can help you connect to your ISP”.

#3 “Playday” (2001)

More of collage than a song — but did you ever want to listen to Bill Gates buy sexy antropomorphized apples? Now’s your chance. (If you like this, there’s plenty more song and dance available in the Ballmer-Gates oeuvre; as well as the spoken poetry performances of Ballmer in this 1986 Windows ad, or “Word-Art” as I call it.)

#2 “Only Amiga Makes It Possible” (1987)

Poss-eh-bell, Uhh-uhh! Notable for the mix of “professional” singing and customer sound bites.

#1 “I Think We’re A Clone Now” (1994)

In the early-to-mid 1990’s Apple started to license its operating system to third-party hardware manufacturers. (When Steve Jobs returned to the company, this is unsurprisingly the first thing he axed.) Today few people remember this era, so let me refresh your memory with this jewel:

(Not to be confused with “I think I’m a Clone Now” by Weird Al Yankovic.)

What’s your favorites?

This week, I quit Twitter.

I had an 11-year old, verified account with over 30,000 followers, I’ve been to the Twitter offices twice, once when they were a 30-people company for a meeting with Ev Williams.

Last week was the last straw. Their hostile stance towards their early users is breathtaking in just how openly they try to fuck us over.

Instead of properly fighting their harrassment problem, they’re openly siding with Nazis, conspiracy theorists and anyone else really who brings them “engagement”.

Instead of widening the options for access, despite their dwindling user numbers, they axe access for third party clients.

Instead of making a new version of their client for macOS, this 4,000 people company decided to no longer make one (after buying the maker of the best app).

Instead of taking a stance to protect their users, they keep a sociopathic CEO in place, with Jack Dorsey going out of his way to constantly explain away his utter spinelessness and lack of action (“We have do to better!”).

Fuck you Jack Dorsey. Fuck you, all you douchebros and douchesisters running Twitter.

You’re abusers. You ceaselessly optimize Twitter for the most possible abuse of its users to drive “engagement” and keep those eyes on the timelines with a never ending barrage of abusive crap.

You keep showing tweets from people your users never chose to follow.

You keep invading people’s privacy by syndicating favorites, which no one ever agreed to.

You keep trying to stir up controversy but willingly allowing criminal assholes to abuse your users just so you can get into the press.

You had a choice, and you chose to willingly and by your own devices, to be assholes.

Twitter’s business model boils down to, “convert negative emotions into money”.

Side note: If you work at Twitter, you’re fueling a cult that makes a profit (well, not sure about that actually) by emotionally abusing people. And the leadership of your company is abusing you, too. Your work is designed to make people miserable, enraged and feeling terrible—all so that your advertisers can sell more stuff.

I’ve deleted my account. I will miss the friends I made, but I will not miss the abuse. There’s a line that was crossed recently with Alex Jones and with removing support for various API functions, a move designed to deliberately target power-users and early adopters who prefer 3rd-party clients over the Twitter apps and their force-fed crap.

It doesn’t have to be like this. Social media can be fun. With friendly people, and with no engagement pressure, and no algorithms force-feeding you content designed to make you feel bad.

I found a new home in Mastodon (follow me there if you like: mastodon.social/@thomasfuchs).

Good riddance, Twitter. Hello meaningful conversations.

There’s still a bunch of companies trying to make things incompatible and pushing proprietary stuff on us (hi, AMP!).

You still need to test in every browser, though it’s been easier than it used to be, as there’s fewer bugs and decent debugging tools.

People still try to fix the perceived shortcomings of the client/server model by trying to make the client do everything.

Hello Java! Hello Flash! Hello Ext.js! Hello Angular! Hello React!

People still eventually give up and try the next thing that promises salvation.

We still constantly add more features to HTML, to CSS, to JavaScript and to HTTP itself. Often welcome stuff that makes things easier. Often bloat that no one really needs.

Yet with all the experience and all the new features and all the “new” client-side techniques, so many web sites and apps are horrible. Worse perhaps than 25 years ago.

I’m not a Luddite, however it’s a good idea to reflect sometimes if you actually need all the crap that supposedly makes things “better”.

Does it, objectively, improve lives of users?

Does more code and more complexity really make things easier to maintain? (The idea of componentized architectures pops up every half decade or so—is it really going to last this time? What’s different this time around?)

If you want to be really great at making web sites and apps—forget about frameworks.

These are and always will be ephemeral.

To be good at “Web” you’ll need to understand first and foremost about humans.

Any web site or web app is ultimately always about a human being wanting to achieve something.

Concentrate on this first. Make it easy to achieve that something.

Make things clear, quick, forgiving, enjoyable and get out of the way when the job is done.

To make things clear, learn about psychology. Learn about how (successful) education works. Have empathy. Be kind of users.

To make things quick, master the platform basics: HTML, CSS, DOM, JavaScript, HTTP. Learn how browsers work. What happens when you hand the browser a chunk of HTML, how does it get parsed, layouted, rendered? Staying on top of this will allow you to make well-informed technical choices, like the type of structure your web site or app has (from static pages, to server-side MVC to full-blown client-side apps; or a mixture of these). As you make apps that will (hopefully) be used for many years to come, deep knowledge on these subjects will come in more than handy when you need to maintain code later. Put a sticky note on your monitor with the old adage of “keep it simple, stupid”. (Will people in 10 years from now still know how to use React? Will they even get the toolchain to run?)

To make things forgiving, see what happens when users block trackers and ads. See what happens on slow and brittle connections. Load up the thing on a 10-year old computer. Test in text mode browser (is it at least somewhat comprehensible?), and test for colorblindness. With very little time investment you can show your users that you care. This will be much appreciated.

To make things enjoyable, learn about design. Learn about human-computer interactions. Learn about visual design, space, colors and typography. Design is not some innate magical ability people are born with.

tl;dr Make great sites and apps that help people kick ass & don’t get tangled up in the pursuit of technical “cleanliness”.

Here’s to the next 25 years of the web.

P.S. And for everybody’s sake, have fun creating things and don’t take everything super seriously.

These are words you should never write in a support email. Why? Because it’s dishonest and reeks of A/B-optimized corporate technobabble.

It’s a lot like saying “my thoughts and prayers are with you” to people that you don’t know that are victims of crimes that have nothing to do with you.

You feel like you need to say something, so you say the acceptable middle-of-the-road default.

This is wrong, and you’re wrong for doing it. You’re saying these things to make yourself feel better; not to actually express genuine support for those you’re addressing.

Reverse these situations for a moment and switch the phrases:

We’re expecting the server to be online again in about an hour.
My thoughts and prayers are with you.

Sincerely,
Support Dude

It literally doesn’t mean anything and fills up space.

What about a tweet like this?

Regarding the terrible attack in <x>, I apologize for the inconvenience.

Would you tweet that?

Please stop using these phrases. If you need to communicate genuine, heartfelt emotion, take a moment to try to come up with something that expresses what you actually mean.

This is our fault, and I know that it’s frustrating that our app doesn’t work for you right now. The team is on it and is working hard on getting it up and running again. I’ll let you know when we fixed this!

How hard is that?

And regarding thoughts and prayers, please feel free to have thoughts and have prayers, but don’t overshare.

The old saying goes, “Time Tracking ain’t easy”. All you want is accurate and on-time data so you can plan your resources, bill your customers and find those pesky projects that just take longer than they should.

But instead you’re fighting with your software, eventually not using anymore and then blaming yourself for being “undisciplined”. Well, it’s not you, it’s your software.

You can’t just automate it

Sure, there’s apps that track which other apps you have open on your computer, and maybe even phone calls — but there’s a lot of work that’s done that happens away from keyboard. Meetings, conversations at the water cooler, or simply having a great idea in the shower. How do you track that? The best way to track time is to manually do it — humans know better than machines what they’re working on. But it has to be easy to do, if it becomes a chore, you end up with bad data.

Dependency hell

Who wants to configure 7 things after doing a 3 minute phone call? That’s right, no one.

When your software requires that you create a client, create a project, create a sub-project and create tasks before you can even track your time you’re bound to just not do it.

Why wouldn’t your software anticipate this and let you log time ad-hoc without any formal requirements? And let you do the details (like an hourly rate for a specific client) later?

“I’ll do it later”

People often log their time perhaps once a week on Friday afternoon, when they’re with one foot out of the office already. Or worse, just quickly log the time for last week on Monday morning.

Time Tracking software should be aware how actual human beings work and help you achieve better quality by providing ways to make time tracking easier, for example by actively reaching out to you when it looks like you forgot to track your time.

Work just doesn’t stop at the office door

Even if you’re disciplined about separating work and private life, we’re all just human beings. Have an idea during your morning shower? Discovered the perfect solution for your client during a weekend stroll? Or you have to switch between projects and need time to get into each project without being productive right away (ask any programmer!).

Your software should know that you’re human. For this reason, in many industries, traditionally time is rounded up to, e.g. quarter hours for billing. This gives a more realistic picture of how much time you actually spend—and minimizes overhead by not making you log every 10-second shower thought.

Business software is terrible

Most business software is like a visit to the DMV. Everything is grey and beige, you need to fill out confusing forms and you have to wait forever for anything.

There’s actually a lot of research on human-computer interactions that, not surprisingly, found that friendly applications that treat the user well (for example with forms that are less intimidating, cheerful color scheme, fast load times, etc.) yield better data quality.

Why? Simply because people don’t feel awful using the apps.

Software really doesn’t have to hurt—it can be actually helpful to get stuff done. But that involves a bit more than just throwing a few forms on a web page and brewing up a buzzword backend soup. It requires research and understanding the problem & knowing how humans behave.

Want time tracking that does all this? Freckle’s foremost design goal is to be cheerful. Give it whirl today.

1. Selecting an image via the keyboard (Shift+Cursor keys) shows two context toolbars on top of each other:

1. Inserting an image just under an item in an ordered list makes following list items lose their position and start numbering at 1 again. More annoyingly, I can’t find a way to keep the numbering correct, because the ultra-minimalist UI doesn’t have any options to configure this.
2. Can’t copy or cut + paste images via the keyboard (⌘X, ⌘C, ⌘V).
3. Shift+Cursor Up or down to select things stops at images. Moreover, Shift+Cursor Up not only stops at an image, the next time you hit Cursor Up it clears your text selection for no reason.
4. I can drag selected text to different position, but it doesn’t move the text to the drop point.

There’s so much hidden refinement in user interfaces, especially with “simple” seeming things like editing text—as a designer or developer it’s a good idea to (once in a while) stop what you’re doing and familiarize yourself again and again with basic user interface controls and patterns.

These patterns have been tweaked over decades, the result of a lot of thinking by a lot of very clever people combined with a plethora of user feedback. This has lead to widely-used standard behaviors in user interfaces. Unlike many other things in programming, there’s no committees or standards for these behaviors—the best way to learn about them is to try out a known great implementation (I’d recommend macOS controls) and literally keep hitting buttons and see what happens.

Why don’t you try a #5minutechallenge in your app? You’d be surprised how far a little focused testing goes. Plus, you’ll probably learn a lot about how controls should behave. And if you find issues in other apps, do write bug reports. These things seem minor, but add up to a lot of user frustration.

Here’s a quick flowchart for you, based on creating high resolution graphics for real, existing web applications, both on the web and in mobile web wrappers:

If you’d like to learn more about the techniques shown here, grab a copy my ebook.

It’s such a big missed opportunity for many businesses to get to know their customers, and make them feel amazing that they made the right choice buying from you.

Here’s what you can do to make your “Help & Support” tab awesome.

1. Make it easy to find. Use a bright color (yay, pink)! Make it clear that it’s something that opens when clicked. You can do this by adding a little disclosure arrow and perhaps having a small animation when the user hovers over it. You can also open it by default on page load until the user closes it for the first time.
2. Call it “Help” or “Support”, not “Feedback”. It’s for people to get help, not free consulting services for you.
3. Introduce yourself. People like to talk to other people. If your users see that your app is made by actual people this can change your users’ mood instantly. Especially when there’s a bug or something bad happening.
4. Offer a self-help option, but don’t prefer it over talking to you and do not force it on people. (This rule might not apply to all types of apps and services. For example, if your customers are all tech-savvy power-users, they might prefer (good) automatic self-help suggestions over having to send an email. You might want to experiment.)
5. If applicable, show relevant contextual help. On your sign in page, have a link to your help page on logging in. On your data import page, have a link to the help page that explains how to make a CSV file. Don’t show more than one or two relevant links as users won’t read them all. However, don’t make this more important than contacting you directly (e.g. don’t make people have to “click through” to your email address).
6. Have a big button to directly send a message right there on the page. Do not ask for people’s names or email addresses if they’re already logged in to your app.
7. Help new users get started quickly. Using a new app can be daunting to users. Have an option to get them up to speed quickly, a tutorial video or screencast works great for this.
8. Send yourself extra information that’s already there in the browser so you can help your users faster. This includes current URL, the user agent string, the current local time of your user, and more (e.g. screen resolution, but also account information like the account ID or which plan type a customer has, so you don’t need to look them up). It’s better to have too much information than too little.
9. Offer a “email us directly” link and clearly indicate your support email address. Don’t make people hunt for it. Support is likely your #1 sales channel. Always be talking to your users. You’re running a business serving customers, not an experiment in avoiding to have to communicate.
10. Indicate your system status right there. That can instantly communicate to people that you’re aware of an issue and serves two purposes: reduce load on support and make people feel good that you’re monitoring things actively and are already on it.

With a little bit of effort you can both make the experience amazing and friendly for your users and you get to a better start when answering those support emails.

Over the last few years the “authorities” of the JavaScript world concentrated on adding ever more features to the language and building a sprawling library of modules and packages.

As of right now (9:52 AM ET on March 26, 2016) there are 259,191 packages on NPM. Yes, that’s more than a quarter million packages.

Imagine a library with no books, instead being filled to the gills with fortune cookie fortunes. That are tied with strings to each other.

The ES6 standard (aka the next major version of JavaScript) adds a huge amount of features to the language, among them arrows, classes, enhanced object literals, template strings, destructuring, default + rest + spread, let + const, iterators + for..of, generators, unicode, modules, module loaders, map + set + weakmap + weakset, proxies, symbols, subclassable built-ins, promises, math + number + string + array + object APIs, binary and octal literals, a reflect api and tail calls.

Now, what is the point of all this? Will it make it easier to write apps? Will it make them work better?

How have we been able to make useful software in JavaScript all this time?

Growth for the sake of growth is the ideology of the cancer cell.—Edward Abbey

Many of the packages on NPM are literally one-liners. Why would people include a one-line-of-code library in their projects and not just write it themselves? Is it lazyness? I don’t think so—it’s more of a convention in the JavaScript world that everything should be compartmentalized, filed away in neat little modules and all held together by some dependency pyramid scheme.

I don’t think short and to the point libraries are evil. I actually launched Micro.js a few years back to highlight useful, small libraries. However, I do not think the proliferation of essentially trivial code snippets that are packaged up is a good thing.

Guess what? In the real world, this model quickly leads to a multitude of issues. The most obvious example is that if a package is removed for any reason, chaos quickly spreads.

That’s actually not the main problem though. As a developer of software, your job is it to find the simplest solution to a problem. “Simplest” is a bit vague, so let’s define it as “does functionally work, is performant (enough), is relatively easy to understand and is not taking too long to implement”.

“There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.”—C.A.R. Hoare

So let’s break this down:

“Does functionally work”. Yes, NPM modules, for the most part, do work. This is kind of a given as you wouldn’t include code in your project that doesn’t work. (However, you will run into bugs eventually in the modules you include. And then the fun of debugging other people’s code starts…) And when a developer decides to update a module but doesn’t adhere to semver semantics, well, good luck. (Yes, this can happen with any packaging system, and indeed it happens to me for example with Ruby’s gems from time to time. However, the amount of gems included in projects is relatively small compared to JavaScripts’s “everything-in-modules” approach which geometrically increases the chances of something breaking.)

“Is performant” is the first hurdle. While the code itself probably is fine (though you won’t know until you measure it yourself), it has to be pulled in from a central repository, and it has to be kept up-to-date, which adds extra time during development and later issues when deploying (imagine the repository is temporarily down, the package is no longer available, something broke in a minor or patch release, etc.). You’ll need a build system, and you need one that offers workarounds for these problems (like local caches). In essence, this is adds complexity. And complexity is the enemy of productivity.

“Is relatively easy to understand” is where it gets hairy. Every library and module you add to your code basically creates a black box where input goes in and output comes out and in-between there’s magic. Magic that you have to go in and understand to see if the modules actually behave like you think they do. This package for example, provides a method that cuts off a string at a given maximum length and adds an ellipsis. Now, to find the package, add it to your build system, review the code if it actually does what you want—is it worth using a module? For something you can implement in one line of code?

“Not taking too long to implement”—how long would it take you to write a function that cuts off a string or checks if a number is positive or adds left padding? Many functions you’ll find in a standard library are likely trivial in nature, but having an agreed-upon standard API to do things will speed up implementing code (fewer instances of “is there a library for this or should I code it myself”). Bonus: other people reading your code can concentrate on learning about dependencies that actually matter instead of the 5th implementation of “leftpad”.

“Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.”—Alan Kay

One thing that strikes people as odd in JavaScript, especially when they come from compiled languages like C, is the utter lack of certain useful functions (for example a function to format numbers in strings, like printf).

Instead of providing a great standard library (like the one in C, which is actually not that large compared to the standard libraries of other languages), development of the JavaScript language has gone another route. The route of featuritis in the name of “making things better”.

There’s a great metaphor in the German language, which is “Eierlegende Wollmilchsau” or “Egg-laying-wool-milk-pig”. It means a thing that tries to be everything. And ultimately the never-ending complexity causes it to fail.

What if all the energy spent on adding all these features to the language would have gone into creating a great standard library, that’s included in browsers and JavaScript runtimes? And perhaps a few small tweaks to make the language better and easier to write? (Hello, CoffeeScript!)

A standard library would make it a lot easier to write JavaScript by eliminating the need to come up with similar or same solutions to small issues. It would effectively make code easier to read and write as a lot of “searching for a library” and “or maybe I should write this quickly myself” would be eliminated. And as a free bonus side-effect application performance would be better, as there’s less need to load external libraries and the implementation can use native code and thus be highly optimized.

A standard library could easily be added to JavaScript without years of committee infighting, stalled projects and failed approaches (remember the bat-shit craziness of E4X?). ES6 took 6 years to finalize and browsers to this day still don’t fully support it. There are plenty of successful and widely used libraries to draw inspiration (and implementation) for a first round from, like Underscore.js (and it’s predecessor in spirit, Prototype.js).

I appreciate that some improvements are underway (like the aforementioned additional APIs for some built-in objects), but I’d love to see a concerted effort to cast aside new language features for a while and really get to work on an underlying standard library.

What if we developers would make things simpler instead of more complex?