Posts tagged "ux"
On 19 April 2011, at around noon Pacific time, I published a short tweet.
Hashify is officially live as of now! bit.ly/dXYxGU
Quite to my surprise word of the release spread incredibly quickly, thanks in
large part to the Hacker News thread that sprang up and received a great
deal of attention.
The vast majority of the ensuing discussion focused on the implications of
stuffing documents into URLs, and of using bit.ly as a document store. While
there was much debate as to whether this "cool hack" will turn out to have
practical application, the one undoubtedly useful component was overlooked.
Markdown editing for the masses
Before dropping off the face of the earth, John Fraser created Showdown
and wmd. The latter is a WYSIWYM Markdown editor, popularized by Stack
Overflow. I've long been supportive of wmd's goals, but I've never liked
its implementation.
Several drawbacks of wmd encouraged me to write my own Markdown editor:
- Its use of inline styles makes it difficult to customize the toolbar's
appearance.
- Many HTTP requests are required to retrieve the toolbar icons.
- Lack of modularity: Showdown is a dependency.
- Unnatural keyboard shortcuts.
Hashify Editor addresses these concerns. Styles are applied via a style
sheet, and selector specificity has been kept low to make overriding default
styling simple. Selectors are prefixed with hashify-editor to prevent
erroneous matches. Additionally, the images have been sprited, optimized,
Base64 encoded, and included in the style sheet as a data URI.
Hashify Editor does not require Showdown, as its focus is on turning the
humble textarea into a useful Markdown editor. TextMate-style keyboard
shortcuts make it a joy to work with metacharacters and text selections.
Best of all is the preview option: one is able to view — and of course,
edit — the text at hashify.me with a single click.
- Hashify Editor at David Chambers Design
- Comment preview at hashify.me
Adoption
I love sites which support Markdown commenting. Unfortunately many of those
that do — even Forrst — don't provide previews. As a result, each time
I'm about to submit a lengthy comment I select all, copy, open a new tab, go
to hashify.me, tab into the editor, and paste in my comment. Were Forrst to
integrate Hashify Editor, six of these steps could be replaced by a single
mouse click. :D
Comment forms that don't provide previews — or at least an indication of
how comments are processed — really annoy me. If I decide to leave a comment
I take care to avoid spelling mistakes and grammatical errors. It's quite
upsetting, then, to see my code snippet completely mangled and my carefully
typed links displayed in plain text (<a href="…).
Despite my appreciation of the preview, not one of my sites provided this
service until a few hours ago. Now that I've migrated from WordPress to
Mango I'm able to spend some time working on front-end code. My first two
challenges were localizing dates and times, and integrating wmd.
Getting wmd working turned out to be extremely easy, but I was not content with
a live preview of the comment only. No, I wanted the preview to resemble as
closely as possible the published result, which meant updating the preview area
in response to changes to "name", "e-mail", and "website" as well as to changes
to the comment itself.
This was a great deal of fun to implement!
Early this year I wrote a post titled
Auto-populating input fields with Prototype. Looking at the code now,
I realize that it's not very pretty. I'm rewriting this site's JavaScript
in MooTools, and the new code is quite a bit more elegant.
// provide input hints
window.addEvent('domready', function () {
$$('input[placeholder]').addEvents({
focus: function () {
if (this.hasClass('placeholder')) {
this.removeClass('placeholder').set('value', '');
}
},
blur: function () {
if (this.get('value') === '') {
this.addClass('placeholder').set('value', this.get('placeholder'));
}
}
}).fireEvent('blur');
});
I really appreciate the fact that MooTools provides addEvents in addition
to addEvent. As a result, the code above is clearer than a well-written
Prototype equivalent.
It's not uncommon to start watching a video online and discover that its
audio is quite quiet. This is not a problem in and of itself, as one can
simply crank up the output volume. What is a problem, however, is a
message then arriving in one's inbox and waking the neighbours!
This situation could be avoided if it were possible adjust the browser's
output volume without affecting the rest of the system. As it is, though,
one is forced to increase the volume of everything. Not ideal.
System Preferences > Sound > Application Volumes
Wouldn't this be nice? Many months ago I did some Googling to find out
whether it's possible to control volume on an application-by-application
basis in OS X. The closest thing to a solution was an X11 (read: ugly) app
that kinda worked.
Apple, I don't bug you often, but here I will. Please build this
into the OS and keep the neighbours happy. It'd be particularly sexy
if applications such as iTunes which do currently grant the user control
of the application's volume synchronized their volume settings with the ones
in System Preferences. That is, adjusting the volume in iTunes would adjust
the iTunes volume setting in System Preferences, and vice versa.
Chris Coyier has done it again. Compelled me to stay up all night,
that is (it's 7am as I type this). In Chris's latest screencast, CSS Image
Switcher, he demonstrates how to create an "image switcher" using CSS.
The problem, though, is that his process is wrong.
Incorrect process
- What effect or experience do I want to create?
- How can I achieve this using CSS (and JavaScript if necessary)?
- What can my markup do to help me?
Correct process
- What effect or experience do I want to create?
- What is the most correct and meaningful way to describe the content?
- How can I achieve the desired effect or experience (or something close to it)
without altering my markup?
Yesterday I wrote a simple class which auto-populates input fields, and
thought it worth sharing. I was originally inspired to write this code
by Roger Johansson's post titled Autopopulating text input fields with
JavaScript. While I approached the problem from a slightly different
angle, I made sure to avoid the pitfalls Roger mentions.