If you’ve been using a tracking cookie randomizer or if you’re unlucky enough to be on the wrong side of Google’s A/B testing, you may have run into YouTube’s new look and feel.
Unfortunately, while it does have a few small improvements, it has some really big problems:
The all-white background is rather eye-searing
Buttons which only look like buttons and links which only look like links when you hover near them make it slower and more confusing when you want to click Like/Dislike or Show More/Less.
Having things change their appearance as you move your mouse over seemingly empty regions of the page is rather distracting.
As such, I’ve written a little Stylish userstyle named “YouTube – Fix new look with elements from old look” which patches away these flaws by borrowing colors and patterns from the old YouTube theme and locking buttons and links in their on-hover appearance.
I still haven’t decided out how best to make the button for adding to lists (eg. favorites) as easy to find as it was in the old layout, but I’ll keep thinking about it.
Let me know if there’s anything you think could still be improved further.
It’s becoming increasingly well-known that, no matter what you want to improve, the first and most useful thing you can and should do is measure it. Objective measurements keep you honest and give you something to focus on.
A few years ago, being the unit test junkie I am, I wrote a data quality analyzer for my gender-bending index. Unfortunately, for a variety of reasons (it was a quick and dirty mess of a Python CGI script with no thought put into it), it was never made public.
That changed yesterday with my new rewrite of the Data Quality Analyzer to fit into the new GBIndex codebase. Anyone can now look at the current state of things, whether to heckle or to help by contributing data. (Unfortunately, I haven’t yet had time to implement a history so it can’t track change over time)
Thanks to the marvel of dogfooding and my interest in UI/UX design, the analyzer has the following convenience features:
Tests that turn up no problems are hidden by default but can still be shown
Each entry contains a miniature pie chart with an informative tooltip to clarify how serious each problem is.
The miniature pie charts can be clicked to pull up details on the problematic entries
As much as possible, data in the details view is hyperlinked for quick access
Except for pulling up details (which will eventually get fixed), every link can be middle-clicked.
There’s more to be done to streamline things, but that’ll require some other parts (like the new UI for submitting corrections and the new code for managing XMLHttpRequests and history) to be written first.
…and, as I expected, as soon as I got the analyzer working with the new database schema, I ended up taking some time to procrastinate coursework by doing some cleanup on the GBIndex’s data.
Play around with it if you want, have fun, and feel free to suggest new things it can check for.
A couple of days ago, I discovered that my Identi.ca account had been silenced (suspended).
Apparently, they thought it was suspicious that I was posting almost nothing but rigidly mechanistic notices almost exclusively pointing to the same site (Fanfiction.net, A.K.A. the YouTube of fanfiction).
I got my account restored, but I’ll probably hold off on posting more micro-reviews until I can get a response from them on whether I’m part of their intended user base and it was purely a mistake or whether I should be running my own copy of StatusNet rather than using theirs.
Their “your account is locked” message doesn’t provide access to the data export system and now I’m feeling as wary of Identi.ca as I am of Twitter.
Just thought I’d share the Getting Started guide that grew from my periodic use of Lubuntu to make old PCs useful to the needy.
It’s on GitHub and you can also view it online though the WebODF renderer doesn’t yet seem to obey instructions to stretch tables to fill a page’s width or span cells across rows.
TL;DR: This script collects hardware and OS info for reporting bugs in Linux games because, on Linux, the functionality of DxDiag is split up across several different tools.
The Humble Indie Bundle 6 just came out and, wanting Torchlight, I bought it. Now, like any early adopter, I did run into a bug (it’s already been fixed). This isn’t about that, though.
When I read the README.linux file, it asked me to gather a bunch of diagnostic information and, being the distractible geek I am, I ended up writing a script to automate it.
…I went above and beyond the call and expanded it into something more like a console version of the Windows DxDiag utility. (Which will also open a terminal for you if you double-click it) So, if you ever need to submit a bug report for a Linux game, run this script. It’ll gather all your hardware and system configuration in one easy-to-read, easy-to-attach file.
Note: I’m still working on figuring out what kind of data I should collect for debugging audio and input issues. If you have any suggestions, please leave a comment.
In case you don’t feel like scrolling past the embed or you’re not used to working with embeds from GitHub Gists, here’s the direct download link.
After writing what must be my third or fourth e-mail offering advice to an online service whose marketing completely missed the mark with me, I started to notice that I was touching on the same set of points.
Again and again, startups seemed to miss that, despite their differing goals and shorter attention span, smart users will act like investors. As such, it’s essential to address, at minimum, these concerns:
Financial Viability: Can potential users clearly see how you intend to earn enough money to still be around and paying the bills 5 months, years, or decades from now?
Clear Pricing: If your free offering is more than just a trial period or if you offer free accounts to certain groups (eg. non-profits, open-source projects, etc.), does the landing page make that clear? Is your offering only free until the beta period ends? Try to, at the very least, give an estimate how much it will eventually cost.
Clear Offerings: How easy is it for users to compare your different plans? …especially any free offering you may have versus your paid offerings? Don’t get artsy here. Put a table/chart somewhere and, if it’s not on your landing page, follow convention and put a link named “Pricing” or “Plans” in your header.
Clearly Stated Audience: Potential users don’t want to waste their time learning about your features if your service is too expensive or won’t scale up to meet their needs. Make information on your plans clear and easy to find.
Now, when I write these e-mails, I tend to write them to people who strongly believe that their code is a trade secret, but when I’m actually choosing software and services for myself, there are two questions I ask (which are far more important to me) which marketers should have honest responses to:
DataPortability: How hard would it be for me to export my data and take my business elsewhere if I grow disaffected?
Open Source: Can I run and customize a copy of the software myself to meet my requirements for privacy/security/reliability/longevity/features? Can someone else pick up the pieces if the service provider goes bankrupt or loses interest in the product?
All in all, it boils down to two very subjective questions that people try to answer when deciding to invest their time, energy, or money:
Do I understand what I’m getting?
Will any changes without my consent be to my detriment?
Update: For end users, this How Do They Make Money? explorer helps to streamline some of these questions for the more popular sites out there.
Having grown very used commands like these, nobody was more eager than I when PHP 5.4 introduced its own no-setup development server.
python manage.py runserver (Django)
paster serve --reload (Pylons)
nodemon (NodeMon for Node.js)
jekyll --auto --server (Jekyll, used by GitHub Pages)
However, in typical PHP fashion, there’s some assembly required and you’ll probably need code from either the comments or somebody’s blog to get it to behave the way you’d expect it to by default.
So, without further ado, here is what I came up with to get the basic “excise index.php from the URLs and pass static files through” behaviour most people use .htaccess for.
(There is a command-line option for this sort of behaviour, but it doesn’t match the behaviour of the net’s most ubiquitous mod_rewrite snippet.)
It’s been tested under Fat-Free Framework 2.0.6 through 2.0.12 and, if there are any incompatibilities with other frameworks or PHP applications, they should be minor.
