September 14, 2012
An animated, configurable, spirograph-style graphics generator that can be easily embedded into a site (code generator included).
There’s also a general ‘JS experiments’ domain that I’m putting together to contain a bunch of smaller, yet still interesting projects I’ve worked on since getting into Canvas. That’ll launch soon.
August 16, 2011
From News.com.au’s Gay marriage should be ridiculed, says Independent Bob Katter:
Nationals Senate leader Barnaby Joyce said his four daughters would be affected if same sex marriage was allowed.
“We know that the best protection for those girls is that they get themselves into a secure relationship with a loving husband and I want that to happen for them.
“I don’t want any legislator to take that right away from me.”
You don’t have to support gay marriage or those pink commie lesbo liberals (who hate this country and/or want to convert our children, etc) to see that this statement makes no sense whatsoever.
June 13, 2011
From this month’s Dreamhost newsletter / promo robot:
We now have the ability to act as a domain registrar for a total of 21 top-level-domains.
… [amusing self-deprecatory rambling] …
Then, further down said email:
February 16, 2011
Wouldn’t be so bad if Gawker’s individual sites hosted the JS files since NoScript wouldn’t block everything by default. Did someone skip user-testing?
February 8, 2011
Great in: FF 4, Chrome 6+
Good in: FF 3.6 (a bit slow)
Dodgy in: Safari 4 (audio samples are always reloaded from the network, otherwise it’s ok), Opera 11 (input problems; the browser thinks the numpad keys are the same as the numbers above QWERTY).
January 31, 2011
The intended purpose of the add-on manager’s list view is to give a brief overview of the users’ add-ons and to provide only the minimal, most used information and functionality.
I don’t think a small chunk of text on each addon entry is causing the manager to be aesthetically busy. The absurd amount of whitespace and confusing visual structure is actually responsible for that.
Some additional comments about the addon manager interface can be found in a previous post about the Firefox 4 UI.
Some advanced users use the last updated date as a diagnostic tool to identify which add-on updates may be causing a recent problem in Firefox. However, the date makes a very poor diagnostic tool. One reason is that the date does not give any information about the size nor scope of the update, and thus can only be used for diagnosis by disabling one add-on at a time to isolate a problem. In many cases, a problem in Firefox caused by an add-on are instantly identifiable as being caused by a particular add-on.
This has not been my experience. Disabling the last updated addon has been a successful technique for me in at least two cases. For example, towards the end of last year half of my tabs disappeared with one middle-click. I have a few tab-related addons installed so a few were suspect. Luckily I remembered which one had updated last (around week prior to the bug surfacing so dramatically) so I downgraded the Tree-style Tabs addon and things went back to normal. This is a case where sorting by last update date is very useful. (Or maybe it’s because I’m an advanced user who can tie his own shoelaces without a video demonstration on Youtube).
What would be ideal for situations like this is for recently-updated addons to have a ‘downgrade’ or ‘down-date’ (for want of a better term) option available to the user should something appear wrong with the addon that can’t be explained through error logs or crash reports. This feature also compensates for users who update an addon (or have it updated automatically) only to discover a key feature that they used has been changed or removed.
Even in the rare case where a problem suddenly appears in Firefox, the chances of it being from an add-on update are not large. A problem could be caused by any number of online events, which is why Firefox provides tools such as the Error Console and about:crashes to help diagnose them.
The console output and about:crashes would not have helped for the case above as it was a logic error in the addon, not a syntax error.
And, even if we were to give fuller information about updates in the add-ons manager and make it into a better diagnostic tool, why should this tool be so far removed from other diagnostic tools? How could a new user figure out that, to access diagnostic tools related to add-ons, they should go to the add-ons manager rather than a more comprehensive diagnostic tool? It would be wildly inefficient to apply this elsewhere in Firefox by placing diagnostic tools only on the interface elements they relate to.
No one asked for diagnostic tools to be splayed throughout the interface, so I’m not sure where that came from. I certainly don’t want the dashboard of my car look like a 747 cockpit but I would like to be given a hint about the oil level since that changes over time while I’m not looking.
If I was a user with a few addons that affect say, tabs, and the tab bar started acting funky, I’d think about what change could have caused it. Did I fiddle with any settings? No. Did the browser update in the last week? No. Did those tab addons update? Hmm, I remember seeing something about that. How do I check stuff about addons? Oh, the addon manager.
I think stripping out potentially useful diagnostic information for purely aesthetic reasons is the wrong choice. Consider the difference in time and complexity if I want to find the most recently updated addon for the scenario above:
- With sortable dates: click ‘last updated’ and look at the top of the list.
- Without sortable dates: double click an addon on the list and find the ‘last updated’ field. This will be be in a different screen position depending on the descriptive text supplied by the addon author. Is the update date the closest to now that you’ve found so far? Repeat until you’ve checked all addons.
What we should do is add diagnostic tools about add-ons to comprehensive tools such as about:support. Then, we could provide expert users the information they want in a better format while keeping one-off diagnosis away from list view in the add-ons manager.
Well, yeah, that’d be great. When is that scheduled to be included? In the meantime, however…
The intended purpose of automatic updates is to remove updating from the list of items the user has to care about and remember. By exposing the updated date in list view, Firefox insinuates both that the updated date is very important that this is a process the user should manage.
Please don’t do that. You’re assuming that the addon review process is perfect. If it was then the broken Tree-style Tab update wouldn’t have gotten through and remained live for 2+ weeks.
I also disagree that showing an information update date is insinuating that the user is responsible for it. If Firefox successfully communicates that addons are auto-updated then you have nothing to worry about.
Actually, the actual reason sorting and the last updated date were initially proposed in the add-ons manager design was to give users the ability to sort their add-ons by performance, not updated date. […] However, the ability to rank an add-on’s performance is going to be a part of FIrefox after the 4.0 release, making the remaining sorting categories (alphabetic and updated date) much less useful.
Are you saying that sorting by name & date will be back when performance grading is possible? If so then this change and discussion are a waste of time.
Edit: from the comments underneath the article:
Preferences will be in detailed view also. So, it can be accessed by clicking the name of an add-on once. It’s basically the same reasoning – that this is functionality that isn’t basic, scannable, most used-enough for list view, but is perfect for detail view. Detail view is essentially for more complex interactions with add-ons, while list-view is for overall summary. Preferences is an example of a more complex interaction.
This sounds really non-intuitive and goes against the principle of least surprise.