Tantek Çelik

Independent technologist, writer, teacher

 

  2. Why is there no Latin phrase (and abbreviation) for "in summary"? Could one of you Classics majors make one? #lazyweb

  5. Twelve Blog Post Writing Tips From 2012

    I made a concerted effort to write more and better blog posts last year. Here are a dozen things I learned and/or put into practice that helped me do so. If one of your 2013 resolutions is to blog more, perhaps you'll find a few of these tips useful.

    1. Single topic post. Think of each post as a building block that you might use as a reference in some other post. The more your post focuses on a single point (or a closely related set of points) the more reusable/citable it will be, both by others and your future writings.
    2. Tweetable post title. Social media this, social media that. POSSE and distribute. Enough said.
    3. Summary opening paragraph. This is a classic, but absolutely essential as attention spans shorten every year. Provide context but don't bore with background. Expand on your post title and let it be. If your topic is interesting, your readers will read on.
    4. Put tangents aside. Use the HTML5 <aside> element to isolate tangent fragments or seeds of related topics and keep you (and your readers) focused on your post's single topic.
    5. Quotable Tweetable sentences, sprinkled throughout. Use strong, self-supporting sentences as the start, end, or even as the entirety of a paragraph. Even better: quotable multi-sentence paragraphs.
    6. Local text editor. There should be zero latency between your thoughts and your text. Online editors are still janky and/or have distracting excessive navigation & user interface. They're notorious for losing your data "in the cloud", touchy AJAX code (I'm looking at you, comment box in the Google+ Notification drop-down - why not keep drafts of all textareas?), or fragile page refreshing javascript, vulnerable to network glitches. Such uncertainty in an authoring user interface is like background noise: it distracts you from focusing and writing better. Using a local text editor greatly reduces (or eliminates) those distractions, delays, and doubts.
    7. Lists are nice. Make and share lists. People like lists.
    8. Subheadings help cluster related paragraphs and provide a skimmable (and linkable - use fragment ids) outline. Even in lists, keep the first phrase/sentence of a list item short, self-standing, and stylized.
    9. "The Skirt Rule". Stop adding content when you've covered the topic and yet your post is still short enough to be interesting.
    10. Edit furiously. Content is like interface: anything that's not helping your main point is distracting from it.
    11. Use a footer for updates, terminology, previous writings, additional reading, and citations. Link-heavy hypertext is hard to read text. And distracting. Move definitions, citations, etc. to the footer unless including them inline either provides little risk of distraction or significantly helps reading flow. Use "Previously" text (or a section) to link to your previous posts on the topic (Jamie Zawinsky is particularly good at/about this). Use a "References" section for citations (including Wikipedia/Wiktionary expansions of any jargon) and an "Additional Reading" section for links to related articles.
    12. Check your references. "Always... no, no... never... forget to check your references."

    What helps you write good blog posts?

    Previously

    References

    Additional Reading

  8. In Praise of Checkie: the Minimal Foursquare iOS Client That Could, Can, And Does

    If you use Foursquare on an iOS device, I highly recommend trying out the Checkie iOS app. It's an incredibly minimal and efficient interface for checking into Foursquare.

    Though I'm a big fan of the numerous innovations that Foursquare has made, the user efficiency of Foursquare's fundamental check-in feature has been steadily deteriorating since the days we could simply send a text message to Dodgeball.

    Foursquare: 5+ steps with waiting to check-in

    Now it takes several steps check-in with Foursquare:

    1. Launch Foursquare
    2. Tap the "Check-in" button
    3. Wait for network response
    4. Spend time reading/scrolling to find the venue you want
      • if you don't find it, search and wait for network response again
    5. Tap a venue in the list
    6. Wait for network response to fill in information
    7. Tap the "Check In Here" button
    8. Consider entering a message (and/or photo)
    9. Tap the "Check In" button

    On the other hand...

    Checkie: 2 steps to check-in

    With Checkie, it's two steps:

    1. Launch Checkie - it lists the venues from the last time you used it (in easily readable nicely sized black on white Helvetica to boot), so if you're nearby, it's easy to immediately find your new venue. Or if you wait a few seconds it will quickly and automatically refresh the list.
    2. Tap a venue to immediately check-in

    That's it, you're done. Power-button-lock your device and put it away, no need to wait to see the UI update, though it eventually does, showing you the number of points you got for that checkin. You can also optionally tap-and-hold a venue in the list, and Checkie will take you to a second screen where you can add a message to the check-in.

    Mobile UI = focused, task-oriented, minimal

    Minimizing the number of steps it takes to check-in is super-critical for an application like Foursquare, where you're typically out and about, and want to spend very little time interacting with your device before putting it away. I wrote most of this recommendation to use Checkie as a comment on Edd Dumhill's Google+ post where he lamented: "I never have time [to check-in] when I'm somewhere interesting." Edd's observation is spot-on. Mobile UI design must be focused task-oriented in order to be cheap enough in terms of time/attention cost to be worth using. Get in, minimal steps to do the task, get out. All the "distract me looking through a seemingly endless stream of random unrelated things" features should be buried or secondary at most.

    Toward IndieWeb Checkins

    I find Checkie not just useful, but inspiring. If a third party client can provide a better check-in experience than Foursquare itself, then perhaps by adopting such designs we can provide a better IndieWeb check-in experience. Such an IndieWeb check-in interface would first post a check-in to your own site (perhaps privately or with limited access), and then syndicate it out to Foursquare (and potentially other check-in sites) so you could keep in touch with friends still in the silos. The best part: Checkie is on github.

    Bottom line: if you have an iOS device and use Foursquare, get Checkie, use it, be inspired, build something similarly minimal and useful for your own site. Hat-tip to Edward O'Connor for showing me Checkie earlier this year (who then hat-tipped Ben Ward for telling him about Checkie).

    Additional Reading

    Previously

  9. How to Disable Java Now in Chrome, Firefox, Opera, and Safari

    It's the end of another year and holiday season, and thus a good time to help make sure those you visit have Java disabled on their browsers in order to reduce the chances they'll get exploited. Originally posted in 2010, here are the instructions (with few changes) to turn off Java in Chrome, Firefox, Opera, and Safari.

    Disable Java in Chrome

    • There is no direct UI in Chrome. You have to:
    • Go to chrome://plugins (if clicking that link doesn't work, copy/paste it into a new tab)
    • Scroll down to Java ...
    • Click the blue underlined Disable text link there
    • Consider disabling Flash and others too

    Disable Java in Firefox

    • From the Tools menu, choose Add-ons
    • Click Plugins on the left
    • Scroll down the list til you see Java Plug-in ...
    • Click the ( Disable ) button on the far right
    • You should see (disabled) immediately to the right of the Plugin name.
    • Consider disabling Shockwave Flash and others too
    • Close the Add-ons window

    Disable Java in Opera

    • Go to opera:config#Java|Enabled (if clicking that link doesn't work, copy/paste it into a new tab)
    • Uncheck the Enabled [ ] checkbox if any
    • Click [ Save ]
    • Click ( OK ) to dismiss the dropdown sheet
    • Choose Quit Opera from the Opera menu
    • Relaunch Opera
    • Go to opera:plugins (if clicking that link doesn't work, copy/paste it into a new tab)
    • Click the blue Disable text button to the right of where it says "Java Applet Plug-in..."
    • Or simply uncheck [ ] Enable plug-ins at the top to disable Java, Flash, others in one click
    • Close the tab/window

    Thanks for the update ‏@rchl2k!

    Disable Java in Safari and WebKit nightlies

    • From the Safari menu, choose Preferences...
    • Click the Security (with lock icon) in the top row
    • Uncheck [ ] Enable Java
    • Close the Preferences window (titled Security at this point)

    Bonus: Disable Java in Camino

    • From the Camino menu, choose Preferences...
    • Click Web Features (with globe/switch icon) in the top row
    • Uncheck [ ] Enable Java
    • Close the Preferences window (titled Web Features at this point)

    Performance boost: disable Flash

    Disabling Java will not only increase security (by avoiding all the above-mentioned Java vulnerabilities) but it will increase performance as well because your browser won't waste any network time downloading Java applets, nor will it waste any CPU time running them.

    Disabling Flash, though it has fewer vulnerabilities than Java, will likely cause sites to load faster, since much more network/CPU is wasted by all the Flash ads that sites have these days. I disable Flash everywhere but Safari and run ClickToFlash (the 1.6b9 beta works fine) to selectively run Flash on video sites like Hulu and YouTube.

    Additional Reading

    More on the subject of Java (and Flash) vulnerabilities, additional sets of disabling instructions, etc.

  12. FYI printable asciibet: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~

  13. new personal nerd trick for 2013: memorizing the printable asciibet (0x21-0x7E), and respective Helvetica letterforms.

  17. Why you should say HTML classes, CSS class selectors, or CSS pseudo-classes, but not CSS classes

    Search the web for "CSS classes" and you'll find numerous well intentioned references which are imprecise at best, and misleading or incorrect at worst. There are no such things as "CSS classes". Here's why you should refer to HTML classes, CSS class selectors, or even CSS pseudo-classes, but not "CSS classes".

    Terminology Summary Table

    Wondering what to call "classes" and don't care why? Here's a handy table of examples and terms.

    the thing what to call it
    class="h-card vcard" class attribute, HTML class attribute
    h-card vcard classes, class names, HTML classes / class names, or class attribute value
    h-card class, class name, or HTML class (name)
    .h-card class selector, or CSS class selector
    :active pseudo-class, pseudo-class selector, or CSS pseudo-class (selector) - except for :first-letter, :first-line, :before, :after
    ::first-letter pseudo-element, pseudo-element selector, or CSS pseudo-element (selector)

    Why "CSS classes" is imprecise or incorrect

    There's no such thing as a CSS "class". Optimistically what may be happening is that people who say "CSS class" are using it as an imprecise shorthand for "CSS class selector". However, in articles / conversation I've seen / heard that's not the case. They're incorrectly referring to the "class" itself, just the class name, e.g. "h-card" in the above table/examples.

    Both "h-card" and "vcard" are just "classes" or "class names" (as well as being root class names for the h-card / hCard microformats). If you need to be explicit that you're talking about web technologies, prefix the phrases with "HTML", e.g. "HTML class(es)" or "HTML class name(s)".

    Why saying "CSS classes" is bad practice

    This isn't just pedanticism. By using the phrases "CSS class(es)" or "CSS class name(s)" you're not only being imprecise (or just plain wrong), you're tying the presentational context/framing of "CSS" to class names which implies and even encourages the bad practice of using presentational class names.

    Why saying "HTML classes" is good practice

    In conversations, discussions, and especially when teaching workshops, it's better to be consistent about calling them "HTML class(es)" because that more accurately refers to their effects on structure and semantics. It's upon that structure and those semantics that we can then write whatever CSS rules we need to achieve the design of the day/week/month (which inevitable gets changed/tweaked far more often than the underlying markup / classes).

    Hat-tip to Jonathan Neal, who asked about a "css naming convention guide" in a certain Freenode CSS related IRC channel, to which I answered text similar to the above and then decided I should blog it for reference. Oh, about class naming conventions: a big part of where microformats came from was the desire to come up with naming conventions for common components/chunks/modules in pages like people, organizations, events, reviews, etc. Want to explore more such class naming conventions? Join us in IRC: Freenode: #microformats, or if you're in the San Francisco Bay Area, come by the microformats meetup & drinkup tonight (Facebook, Google+, Plancast).