I just deployed a small update to the site which features new navigation, a redesigned archive and the early stages of some better content organisation via tags. I went through several iterations and couldn’t settle on any that I liked just yet, so this is just the first part of that update. As part of the process, I discarded a lot of near-polished icons which I’ve now put up on Dribbble.
I’ve also wiped about a dozen articles from the site; old, outdated and no longer relevant content has been dropped in favour of some new pieces I have on the way.
Lastly, as a bit of an experiment and part of a new approach to maintaining my site and other projects, I’m making my release notes public. More on this soon.
Last month, my friend @mattieryan and I quietly released a little something we’ve been working on for the past year or so. I’m absolutely thrilled to announce Hubbub; a GitHub Issues client for iOS.
When Matt and I were building WillyWeather, we religiously used GitHub—in particular, GitHub Issues—for logging, assigning and organising tasks and bugs. We both craved a better experience from our mobile phones. Neither of us could bear to use any of the existing apps and with GitHub abandoning their official client, the demand for such a tool became even greater.
So, we built it. Here is just a hint at what’s already available in the first major release:
- Instant filtering, sorting and searching
- Markdown editor for issues and comments
- Collaborator mentioning and issue referencing
- GitHub Status
- Emoji autocomplete
We’re already working on bug fixes, interface issues and performance shortcomings and have many great features in the pipeline, including Background Refresh, GitHub Enterprise support and more.
For now, we think you’ll really like the first cut of Hubbub.
Get Hubbub on the App Store
I’ve been working hard on the biggest update to this site since it launched, with some improvements I’ve wanted since the very beginning.
The feature banner on the home page has been redesigned, rewritten and now makes use of the HTML5 History API. I dropped iScroll and built it around hammer.js which made gesture recognition relatively simple, not to mention being a much lighter library.
I’ve also dropped Typekit and moved to web-safe and self-hosted fonts; Helvetica Neue just works.
Lastly, all graphics have been re-drawn using Sketch, which was a great way to dive in and learn this brilliant tool. As an aside I’m now using Sketch across my projects more than Photoshop, which is simply great.
The current design is a year old, but this update has left nothing untouched giving it a brand new vibe once again.
A common practice in software design is to display an infinite activity indicator while a server or client task is being performed with an unknown completion time. On the web, this often comes in the form of an animating image which obviously must itself be loaded.
There isn’t much more jarring to a user than making a request and waiting, even for a fraction of a second, for part of the interface to catch up. This small lapse can be masked by preparing the loading indicator before the users’ action requests it. There are several ways to achieve this with pseudo-elements. Here is one:
background: url(images/loader.gif) 50% 50% no-repeat;
margin: -8px 0 0 -8px;
This will render the pseudo-element invisibly, but ensure the browser has already pulled down
images/loader.gif for when it’s needed. When an event has been fired that requires the element to display as active, all we need is a class to pull the indicator into view instantly.
opacity or other CSS definitions. It all depends on the context. Once again, this can be combined with the other methods outlined previously for an improved user experience:
Last week I wrote about extending hit areas in CSS; just one handy application of pseudo-elements. Another convenient use is defining consistent overlays.
Consider a button, like the following:
background: #226be4 linear-gradient(top,rgba(255,255,255,.2),rgba(255,255,255,0));
To define the button’s
:active state, one might change it’s colour, dim the type or reduce the gradient. This approach is fine, but as soon as you introduce alternate button styles with different colours, or apply the same logic to other UI components, you need to define the pseudo-classes for those too. Then, if you want to tweak any of the attributes further down the track, you must also change those of the
Enter the pseudo-element:
It’s worth creating the pseudo-element directly on the
button and then altering it’s
background on the
:active state, rather than writing it all solely to the
:active state so that the browser has less work to do on demand.
This technique can be used in conjunction with last week’s trick by setting both
::after pseudo-elements and will, of course, work with
:active or any other state.