Stuff and Things

5 Ways [s/Google/Everyone] Could Fall Flat

Mon, 11 Jul 2011 15:32:02 -0700

5 Ways [s/Google/Everyone] Could Fall Flat:

This link was posted by a buddy of mine in Google+ about Google+. How deliciously meta and self-referencing this stuff is when we’re using a new social networking tool to discuss said new social networking tool.

The below is my contribution to the comment thread in its near entirety. There may be a few odd quips that don’t make much sense… they’re likely references to the original post (not the linked article). I’m reposting my words here because they’re mine and I can, but I’m respecting the privacy of the original poster and not breaking his Circle. Don’t be a douche and break other peoples’ Circles.

Buzz Levels - if anything, it is good that there’s Buzz-action in G+. They’ve clearly learned some lessons from the Buzz effort, just as they have with Wave. Every stream of content has a “signal vs. noise” problem. Privacy concerns notwithstanding, that’s why I left Facebook. The temporal stream is only one way to look at a set of posts. Bubbling & re-bubbling something isn’t necessarily bad; the whole point of the Stack Exchange network, for example, is to bubble the most relevant posts to the top.

Viral Spam - welcome to the internets, ‘nuff said.

Privacy Concerns - https://twitter.com/raza/status/89606722590736384, ‘nuff said. Well okay, maybe http://www.fastcodesign.com/1664377/infographic-of-the-day-the-alchemy-behind-facebook-and-youtube is worth noting too. Heck, even Diaspora isn’t immune to conflicts of interest, considering how they’ve architected their app and who they’re aiming it towards. Follow the money, hombre.

Interface Complexity - yet another problem everyone faces. Social relationships in meatspace are messy, complex, and nuanced. Adding features or new behaviors can muddy the initially clean waters. Again, look what happened to Facebook. That said, G+ is off to a very clean & outwardly simple (but actually a bit complex under the hood) kind of start. Or in other words,https://twitter.com/matro/status/90184657735389184.

Circle Fatigue - funny how they cite something G+ does better than anyone else as a potential failure point. Circles isn’t perfect, by any means, but it kicks the liquified crap out of its entire competition. I brain-vomited about this (https://plus.google.com/114147669855168659236/posts/FSz8E2ycfL1) with a brief follow-up (https://plus.google.com/114147669855168659236/posts/9VbLaFBpW3U).

The inevitable rehashing of the same arguments, and recycled (yet un-updated) criticisms or praise is getting tiring. To quote ye olde Battlestar Galactica, all this has happened before, and all this will happen again.

The evil Farmville chickens are sadly inevitable. Facebook invited the bastards in, but even Twitter’s surprisingly spam-resistant network has grown noisy as individuals copy ‘n paste their way into spamtardery themselves. Can’t stop people from being asshats, as asshattery seems to be part of our DNA. Vive le diversity, right?

Here’s hoping someone gets it right one of these days, because no, Google/Yahoo/Facebook/X/YZ… I did not join any of you jerks, I joined the Internet: http://news.ycombinator.com/item?id=2728174.

Oh hey, also, http://www.ftrain.com/woods-plus.html is probably my favorite piece on this subject

Originally posted in a private Google+ thread, and now cross-posted to Google+ at large.

More on Google+

Mon, 11 Jul 2011 12:19:10 -0700

On Groupings and Concentric Circles

Sat, 09 Jul 2011 18:36:56 -0700

In the context of what Google+, Facebook, Twitter, and similar communication mechanisms are trying to do, there are two reasons for a user to organize other folks into groups: permissions/privacy, and curation of content streams.

Facebook’s approach ironically acknowledges this better than anything else I’ve seen. Unfortunately, their privacy settings, permissions configuration, and handling & terminology of groups is such an unusable disaster, it’s more work than it’s worth to get anything set even remotely correctly, it simply isn’t worth it… not to mention that everything related to privacy in Facebook’s world is a fast-paced game of Whack-a-mole.

Twitter’s boolean public/private model means that permissions pretty much don’t exist. Everyone can see everything (or in the case of private accounts, if you’ve been let into a person’s world, you can see everything). So with Twitter lacking any semblance of privacy containers or contexts, group-driven permissions don’t make sense. Twitter’s failing is that it conflates the notion of private “for my own sanity” curation groups with public “curated collections of people” groups. I cannot make an internal “spammy noisetards with nuggets of awesome” group to keep my “worthy friends” and “professional homies” streams clear, because my entire followership will see exactly who I consider to be a spammy noisetard. There is no recourse, and Twitter’s signal strength suffers for it.

Google+’s Circles is an example of a permissions/privacy group done right: someone only knows that you’ve added them to one of your Circles. As far as I know, they don’t see what that Circle (or Circles) is, or what that means. Lack of context/nesting aside (more on that later), it is a very good, intuitive tool for letting you govern to whom you broadcast what. Diaspora got this correct well before Google+ was being developed, but Google’s Circles UI is a marked improvement and better interaction metaphor.

However, Circles is not effective as a curation tool for inbound streams. Topical relevance & context (curating inbound streams) is completely different from defining “how much I trust you” with my outbound broadcasts. It suffers from the same “simplify by trying to do too much at once” syndrome that makes Twitter’s groups useless. Ironically, the heritage from which the Circle metaphor comes can, in fact, do this:

(via Smarterware.org)

By Google’s own definition, Circles are topical contexts (or “aspects” in Diaspora’s parlance); we talk about different kinds of things and have different types of interactions with, say our friends vs family vs professional colleagues. In my case, I’d direct my rampant technobabble towards my _professional_ and/or fellow nerd circles, and more personal “stuff in my life” content to friends and family.

This says nothing about the sensitivity (and subsequent privacy) of specific posts aimed at these circles. If I’m pissed and ranting about my boss, I’d post to the professional circle (where it is relevant), but I’d clearly only want a careful “inner circle” of trusted colleagues to see it. If I learn I have an alien parasite or that my girlfriend is unexpectedly pregnant, I’d post to the family circle, but like hell I’m going to let 2nd or 3rd cousins know of such things. By the same token, anyone I trust with details of drunken shenanigans is certainly worthy of seeing some funny cats ARE the internet!! pictures; why would I want to cultivate multiple friends Circles, and then remember to add them all to every silly post? That’s a lot of dumb, unnecessarily repetitive work both in initial permissions settings and at post time.

The diagram linked to above describes exactly this kind of framework. When I heard the Google Circles announcement, this is what I was hoping for. I AM DISSAPOINT!!

Not that we outside The Googleplex have any way of knowing for sure, but I would suspect that it’d take some significant work to add a permissions inheritance model to Google+. This joke is humorous for the code-monkey nerds, but hints at truth. Technical hellishness lies in them waters indeed.

As far as the user interface is concerned though, most of the hard work is already done. Google+’s interface is truly kicking serious ass, and the implementation and experience of Circles’ interface is bloody fantastic. click -> drag, [circle expands!] -> drop —> DONE. The circle you drag to expands in response, smooth animations show you exactly what is happening without being jarring. It’s the best UI for plopping objects in buckets I’ve seen in a web application to date.

Let’s take this brilliance a small step further.

Create circles exactly as we do now, with the usual spread of friends, family, colleagues or whatever. Within each circle, there should be a couple of concentric rings, such as that diagram’s strong ties, weak ties, and temporary. These would obviously be fully editable, as the rings within a Friends Circle will be different than a Professional Circle, but sane defaults matter. click -> course drag [circle expands!] -> fine drag [ring expands!!] -> drop —> DONE.

Is this complicated? Probably a little, especially when trying to describe it with words. Is it intuitive? Depends on the interface; given Google’s showing with Circles’ 1.0, I think they’ve got what it takes to pull it off, yes. Is it necessary? Yes, as this is how social networks actually work in the real world; the specifics are volatile across cultures and circumstances, but the containing framework has been this way for hundreds and hundreds of years.

So, Google… let’s get on this, shall we?

Cross-posted to Google+.

Suggestions for Long-Form Writing Tools?

Wed, 29 Jun 2011 12:19:01 -0700

I am in search of a text editor that is optimized for writing long-form prose. I can’t speak to specifics about the subject matter, but suffice it to say, if you were going to write a novel, what would you use to make it (the writing, then visual design, then export in various incarnations for publication) go as smoothly as possible?

I have a pretty good idea how I’d go about it, but this recommendation isn’t for me… I’m just the implementer and trainer here, and the client is not amenable to the world that bit-heads like I live in.

Some requirements, nice-to-haves, and general things I’m looking for in an app (or a set of apps):

Simple. Text. Editor.
- Writing, first and foremost. Not a word processor. Word/Pages/Writer try to do too much, and distract from the act of writing.
- Datastore should be in as open & standard a format as possible. Something like plaintext+Markdown or clean, semantic HTML would be ideal. RTF is okay. Proprietary formats are very much not okay, and inability to at least export to an open standard is a deal-breaker. Again, not your traditional .doc/.pages word processor. .odf is potentially acceptable. The canonical document shouldn’t be opaque & useless twenty years from now.
- Unicode/UTF-8 is absolutely essential. Easy access to extended character sets (say, Spanish-specific accented letters) is a plus. There will be some strings of text in a language most of you likely haven’t heard of.
Really, simpler is better’er.
- The shallower the learning curve, the better. Context-sensitive help & syntax reference/assistance (in the case of a Markdown editor) is good. Simple buttons are good. Standard keyboard shortcuts are good. This is primarily for writing semantic, structured text, not building a pamphlet or
- The document in question will be of mixed language, so support for demarcating sections of text being different than the document’s default is a plus.
- Extra helper widgets for stuff like character development or timeline-wrangling aren’t necessary, and should be unobtrusive if present.
Optimized for long-form prose.
- Smarts built around aforementioned semantic structure that makes it easy to wrangle large chunks of writing.
- Sections/chapters, parsing of headers that make it easy to leap around a large document, that kind of thing.
- Not writing a short story or a blog post here. Depending on just the scrollbar & “find text” to navigate isn’t sufficient.
Clean separation of content & presentation.
- Write first, format & visual style later.
- Support for multiple presentations (such as remixing the same structured content for a small b&w paperback [or kindle], and 8x10” full-color [or rich .epub & .pdf], for example) is ideal.
Local, Mac-friendly app.
- Cross-platform & open-source would be great, but the author has a Mac, so everything must be able to run on OS X, no exceptions.
- Non-local webapps are out. If it needs Internet access to run, it’s no good. If I can install it to http://localhost, that’s okay (but awkward), and offline HTML5 goodness that’ll make for a Fluid.app is worthy of consideration.

It’s almost like I’m hunting (once again) for a tool that’s good at writing for the web. I guess I kind of am, but I’m not looking for a coding or generic web-authoring tool. Rather, I’m looking for something simple that’s state-of-the-art for writing and publishing a modern book-like thing.

An all-in-one app would be nice, but is hardly necessary. Some kind of “write→design→export” tool chain might be a better choice, especially if automation (via easy button-mashing) can easily push changes from the canonical manuscript out into a set of export targets/formats.

Like I mentioned at the beginning of this post, I’m not the author in need. If I were, I’d likely be crafting my own flavor of Markdown/HTML+CSS frankensteinian script-happy monstrosity, and I’d instead be asking for recommended coder-friendly text editor plugins, export/conversion scripts, and your favorite DVCS. Unfortunately, the timeline of this thing means that building something myself for the author isn’t an option either.

So, what say you?

Say an entity collects and stores data on a person. Said data should be made available to that...

Mon, 24 Jan 2011 23:03:09 -0800

Say an entity collects and stores data on a person. Said data should be made available to that person in its entirety. It should be made available proactively, immediately on-demand, free of charge, and in an open, standard format.

By the same token, said entity should be guarded and protective of an individual’s data. It should not be shared with any other individual or entity without the person in question’s simple, explicit, and informed consent; the previous paragraph’s notion of disclosure should propagate with the data and without exception. The entity choosing to store a person’s data should make every effort to prevent unauthorized access to that which they have taken responsibility for safeguarding.

The only procedural exception I can think of would be in the case of law enforcement agencies… but we already have a model for dealing with such a case: delayed disclosure by declassification. Keeping data on a person away from that person should be the very limited exception, and should never last forever.

A government that was truly by the people and for the people would enforce and protect this right of its people. It is time for the United States to wake up to this, replace all instances of “should” in the above text to “must,” and enact it into law.

The technology exists; it is not a question of inventing anything from scratch anymore. We know how to make the pipes. Let’s stop making excuses and start soldering the plumbing together.

There exists almost no motivation for any entity to do this now, government included. Incentive must be created to shift the agenda of everyone involved to do this naturally. Just as disclosing one’s data to an entity is the built-in cost of doing business or otherwise interacting with said entity, so should disclosing additional or attached data be a built-in cost of collecting it in the first place.

In our blossoming information age, data is power. Statistics, analytics, and the ability to derive meaning from data is the weaponized-nitrous-steroids to data’s peasant-gasoline-athlete. Those who we’ve elected as stewards of our society need to open their eyes, grow up, and stop trying to drop lit matches on the straw-heap.

A Citation for Poor Citation

Sat, 01 Jan 2011 16:56:29 -0800

Something interesting turned up in my Twitter client today

“The Clojure Daily is out! http://bit.ly/hZ7PWT ▸ Top stories today by @lucastex_blogs @matro @listwarenet @chrishouser @cowboyd”

—@ajlopez (emphasis & re-linking mine)

Being that I’ve yet to write a single line of Clojure, and at best possess knowledge that the language uh… exists, I was a might confused. What could I possibly have written that would get me mentioned as a “top story” in any publication even cursorily related to this subject?

Against my better judgement (such a post smells an awful lot like a phishing-bot), curiosity prevailed, and I clicked through.

Ah HA!… and now certain grumbling around the web starts to make sense! But this post is not about Twitter spam or other social-networking app etiquette. Moving on.

It took a little looking, but I soon found the following block of content lurking a little ways down the left side of the page:

Interesting. Plain text, no quotes, a first-person voice with my handle and picture in the by-line. It looks like I did indeed write about Clojure, just as the original post implied? A quick “WTF, mate?” to @ajlopez gets me some clarification, and now we have the impetus of this post:

Then paper.li is doing things wrong. Attrib.’s poorly implied, at best. Without following the link, their page appears to quote me.

—http://twitter.com/matro/status/21306805665660928

For those of you not familiar with the paper.li service, this is what it lets you do: collect a series of Twitter posts into a single bucket. Said posts are then parsed for links and media, the contents of which are embedded or superficially quoted, and automatically digested into a single “paper” page.

The paper.li FAQ gives the impression that this is a highly automated process, and I am unsure of the degree to which a “paper’s” creator has curative or editorial control over what ends up on a given page, let alone how said content is presented.

The presentation and attribution of content: this is the beef.

Paper.li presents content with implied attribution to someone who merely links to it, rather than the content’s original author. This is not okay.

In order to gain any context for a given chunk of content, one must mouse-over the by-line. Only then do you find that it is not, in fact, a by-line, but a reference to the purported author writing a tweet with a link, rather than the content itself. Clicking-on/touching certain parts of the by-line also triggers this pop-over, but it is a small target nestled quite closely against a link to said Twitter user’s profile. This interaction mechanic is non-obvious, and fails easily for the meatily-fingered sans-mouse user. In no way does it provide adequate attribution to the quoted content.

The situation is similarly ambiguous from a search engine’s perspective. Amongst the <div>-riddled HTML source lurks no clue as to who has written what. At least the most prominent link in the block points to the content’s (theoretically) original URL; however, there is no rel attribute to give said link context. Nor is there a <blockquote> tag to be seen, let alone a useful cite attribute.

Solutions to this problem:

Fix the HTML. Use some basic semantics to present these chunks of quoted content and links as what they are. Search engines and accessibility tools will thank you. This is the bare minimum of what any web application of this nature should be shipping to a browser. Your about page says you “like the semantic web,” yet paper.li’s markup is anything but. Practice what you preach.
Fix the design. Once you’ve got meaningful markup, there should be plenty of meat to wrangle into a useful design. A bit more verbiage and some better visual queues will remove the ambiguity noted above, and make the service better capable of accurately presenting a wider array of content. Words like “original” and “tweeted by” would help. Don’t sacrifice nuance and context on the alter of simplicity. You can have your cake and eat it too.

Now, I understand that paper.li is self-identifying as being in an “alpha” state. That’s fine, but why would something in such an early, feature-incomplete/untested state be open to general public registration, let alone be allowed to pump content out onto the public web? Or is this a misappropriation of the label in the same way “beta” has been popularly hijacked? Either way, this is not an excuse to be misrepresenting Twitter users, or to be obfuscating/mis-attributing authorship of content your site syndicates.

Please, paper.li, for the sake of the web, fix your attribution problem.

Context Overload?

Sun, 03 Oct 2010 13:23:07 -0700

I’m thinking about a couple different classes of context.

There’s a class of context that, for lack of a better term, I’ll call “nested contexts”. Any experience where you can “drill down” into something (that buzz-phrase pains me) or “follow a thread” of some kind would be a nested set of contexts. They’re serial; when you switch from one nested context to another, you can effectively ignore anything not in your current context.

The other context class I’m musing about… let’s call it a “stacked” set of contexts. These are parallel contexts; at any given moment, you’re aware of all available context, and are able to leap to or make use of them. Think about the set of keyboard shortcuts and modifier keys OS X uses for intra-app/inter-app/Spaces switching, or overloading touch input by the number of fingers used in a gesture.

As ever, the line between these two arbitrary definitions of context are quite blurred. But for the sake of discussion, just go with the flow for a moment.

Nested contexts can be effectively scaled without limit. Since you only care about what has focus, it doesn’t matter how many other available contexts you have until it comes time to make a switch. On the other hand, stacked contexts all simultaneously have baring on what you’re doing, so they can only be scaled as far as one’s forebrain will allow.

Humans are champion (serial) context-switchers, but we know that (contrary to the boastful claims of some) we absolutely suck at (parallel) multi-tasking.

How many stacked contexts can we cram into a UI? Howmany window-scopes and associated modifier keys will make sense and be used by a typical user? How many fingers can we stack atop a set of gestures and have the whole input palette still be usable? At which point does do we hopelessly saturate a person’s gray-matter-RAM?

Passive/Active Behavior. Not a disorder.

Mon, 09 Aug 2010 19:52:05 -0700

While having a recent musing about WebOS, something popped out at me. When we web-heads thrash back and forth about what we mean by the “behavior” layer of a design, it seems the more strict-minded camps can’t help but draw a hard line between CSS’s responsibility for presentation, and JavaScript’s domain over all things behavioral. Since there is no such thing as an absolute, this can’t be the case; a position that practical, real-world experience supports with the solidity of an iron cannonball. So what’s the big deal? Isn’t this yet another petty flag being planted in sand well-scuffled?

Negative, Ghostrider. There’s a shade of gray in there that wants some illumination.

Before this goes any further, aim your browser at a certain A List Apart article.

Done? Excellent.

So this “responsive web design” thing is a new, delicious way of thinking about solid, stratified design. Hidden in there is the key to making sense of this older “presentation/CSS vs behavior/JS” thing.

On top of the “content” and “graphic/aesthetic presentational” layers of web design lie two layers of behavior: passive & active.

Passive behavior is the layer that this shiny new “responsive” concept describes. It is how a design behaves given the characteristics of its container, such as the size of screen or browser window. It is a list of characteristics that simply are, and which change the presentational layer as a reaction to certain stimuli being tickled. CSS may be a passive, static language, but boy-howdy is it responsive.
Active behavior is the domain most folks will agree belongs to JavaScript. This is where a design does its math, works magic when a trigger is fired, and keeps its heart beating in the background. Your JS is a lurking tiger, waiting to proactively pounce on explicitly executed events. If you punch your CSS in the face, it can at best bend like Gumby and hold things together. Punch your JS in the face, and it’ll happily kick you in the spleen while it fetches you some of that “X” in AJAX.

Now, is this a clear-cut, thick-lined distinction? Of course not. There is still plenty that CSS isn’t yet able to do, even in the most modern, future-leaning browsers… and we’ll always have the long, lagging tail of legacy browsers to bash into shape. By the same token, CSS is certainly capable of doing some pretty “actively”-behavioral magic.

There will always be gray areas, cross-pollination, and more than a few ways of doing things. But hopefully this distinction will give at least a few folks out there a better grip on the complex, nuanced, glorious forest of interactive design.

To Write is to Code

Thu, 22 Jul 2010 13:12:31 -0700

My buddies Andrew Spittle and Ian Beck noted on Twitter that John Gruber is a perfect example of a writer who intimately understands markup, coding and programming, and that his solid grasp of his medium makes him quite the potent force. This conversation stems from an emerging discussion around the Interwebs about whether or not “programming skills” should be considered an essential tool in a journalist’s toolkit.

I completely agree with my associates, but there is a nuanced idea that I feel is worth fleshing out in more than just a few 140-character bursts. To “code” doesn’t necessarily mean to “program”. I would argue that “programming skills” aren’t strictly necessary for a journalist (or any other kind of writer), but that “coding skills” absolutely are.

“Coding” is a broad, umbrella-term, of which “writing” and “programming” are sub-sets. Every writer is a coder. Every programmer is a coder. If you are in any way distilling something in text, whether it be logic, structural semantics, ideas or arguments, you are by definition coding.

Layered on top of this is “writing for the web.” My thoughts on the matter more or less boil down to the following:

A proficient artist must be fluent in their medium and know their craft.
When writing for the web, your medium consists of structured, linked HTML documents.
In order to be a proficient writer on the web, one must understand not only coding as a writer, but also coding links and structure in HTML.
Programming skills will help you better understand or improve your technical editorial publishing platforms. They will help hack and optimize your workflow, but you can still get by without them.
Macros, WYSIWYG widgets, and HTML abstractions like Markdown can help you build your HTML faster and better. But completely relying upon them without otherwise understanding is tantamount to a painter not knowing how to mix paints to create new colors.
A journalist is a technical artist who practices the art of journalism. A journalist is already a writer, and thus a coder. A journalist on the web must also be proficient in the additional flavors of coding inherent to “on the web.”

So, should a journalist acquire some programming skills? It certainly wouldn’t hurt. But a journalist already inherently has coding skills, as a writer. And a journalist “on the web” damn well better be able to craft (or at least read) some basic HTML; it’s your medium, whether you like it or not. Embrace it, don’t ignore it!

A Canonical Identifier

Thu, 20 May 2010 21:29:05 -0700

So, take a look at HTTP’s “basic access authentication” method. Okay, maybe don’t look too terribly closely. The basic gist is that your client program (like a web browser) sends a request to a server with three parts:

Username
Password (optional)
URL of the target resource

The final request string with all this good stuff, which you can put right into your browser’s address bar, looks like this:

name:password@domain.tld/foo/bar

So, I had an idea.

First, ignore the optional “password” part of the string. It is absolutely insane to send a password in cleartext, and current browsers handle these sessions kind of funny-like. Besides, we don’t need passwords in this idea.

Next, chop off the end of the URL in the string. Assume we want to hit the root resource of the domain we’re talking to.

Check out what it looks like:

name@domain.tld

Well now, doesn’t that look familiar?

If I tell you to email me at foo@bar.net, you know exactly what to do with it. You put that string into your email client, press a few buttons, and I get a message in my inbox.

If I tell you to IM me at that same address, you hopefully know what to do with it. Put that string into your IM client, press a few buttons, and we’ve got ourselves a chat session.

Now that Google Wave is open to everyone, I could give you my Gmail or Google Apps address, say “send me a wave,” and waves would be exchanged.

Give a client app a unique identifier with a deep set of namespaces, it chats with the server using whatever set of protocols it’s designed to use, the server tells it what it’s capable of doing, and an exchange of data takes place… and it just works.

Why don’t we do the same thing on the web?

If you can throw “name@domain.tld” into email clients, IM clients, and all manner of other apps using all manner of protocols, why don’t we do the same thing with web pages? Is it even possible to put the mess of addresses, URLs, usernames and the like that encompass our myriad online identities and communication channels onto a non-sucky business card anymore?

I want to say, “This is me: ‘myname@mydomain.tld’. Call me, email me, wave me, follow me, everything,” and have it just work.

Why shouldn’t we do this?

Idea, Bumped.

Mon, 10 May 2010 19:10:55 -0700

Yesterday, I had a neat idea warranted sharing with the world. Naturally, it initially manifested as a post to Twitter. This idea was interesting and nuanced enough that it quickly outgrew Twitter’s 140-character limit and mutated into a serious of µ-posts that could only be described as “twitterhea”. Luckily, the “think before you click” school of thought stayed my hand just shy of mashing the “post” button.

Clearly, this idea needed to be escalated up to a medium-format channel. Naturally, this here long-neglected Tumblr account came to mind. Perfect!

For silly reasons not worth discussing for now, logging into Tumblr’s web interface was not an option. I much prefer small, specialized, native applications that do one thing very, very well. The aforementioned nifty idea as a vehicle made it as good a time as any to try flexing some non-Twitter writing muscles as any, so the search for a reasonable Tumblr client began.

And ended. With nothing.

The most promising find was an app called Tumbleweed. But this particular app (along with many others I found) has a wee little problem. It is built on top of Adobe Air. This is a deal-breaker.

Why was this a deal-breaker? My general distaste for almost all things Adobe (besides Lightroom) aside, note the following: in the time it took me to install Tumbleweed, I was able to download, install, and configure MarsEdit, a far more complex, feature-rich, and otherwise awesome piece of software. Note that I had already downloaded & installed the Air runtime and Tumbleweed’s “.air” installer file.

This is just stupid. But I digress.

I’m writing this using MarsEdit. It is a fantastic piece of software. Were I a serious blogginator personality, it would be exactly what I’m looking for. But I’m not. This is actually the longest piece of anything (outside some serious email smack-downs) that I’ve written in months. Unless this monologuing picks up significantly, this wonderful application simply isn’t worth the price-tag for me. But for those Mac-users who write a lot, I cannot recommend this program enough. Luckily, the demo is deliciously functional, and is enough for this purpose.

If one of you lovely readers has a suggestion for a small & fast, light-weight, Tumblr client, I’d love to hear it, but at this point it doesn’t really matter. I’m moving on.

In response to the twitterhea-on-twitterhea that led to this post, my pal Andrew Spittle had a brilliant suggestion. In the interest of owning my own content, this warrants some serious investigation. Until then, I’ll keep that little army of tweet-drafts lurking around somewhere, and flesh them out at some point.

A Second Wave

Wed, 10 Jun 2009 18:04:00 -0700

I just ran across a good CNET run-through of Wave. It’s yet another reasonably decent summary of Wave, with a little hands-on reviewing, and some question-asking that aligns with some of the things I recently wrote.

So, how will Wave interact with existing email infrastructure?

“At the moment, the only people Wave users can communicate with are other Wave users. Wave addresses look like e-mail addresses, but there’s no gateway between Internet e-mail and Wave, so messages send from standard e-mail clients to Wave will bounce. This is a serious limitation, and one Google hopes developers will rectify by writing gateways between Wave and standard e-mail servers, not to mention IM services and other social and workflow systems like Facebook, Bugzilla, and so on. A Twitter interface is already being shown.”

Gateways as modular extensions… saw that coming, and I think it’s probably the best way to go.

Remember my worries about spam? I’m glad I’m not the only one asking this question, and it sounds like the Wave team approaching the problem in a good, cautious way:

“However, as Rasmussen told me, Wave is currently spam-free since it’s not linked into the global e-mail system. He doesn’t want to open up Wave to standard e-mail until he can ensure that this system won’t be overrun, too.”

I want to hear more about how though. And I still disagree that Wave can be considered spam-free, unless opening a dialog within the Wave ecosystem is an opt-in process. Look at Twitter’s “follow” model for a successful example of this.

And then there’s that whole “virus” thing to consider. Note, all that fancy “embedding” thing that Wave is capable of lets a sender embed all kinds of schmancy executable code into a wave, including add-on components to Wave itself. Who remembers those Word “macro virus” things? Just sayin’…

The full article is worth reading.

Waves of Waves

Tue, 09 Jun 2009 21:32:00 -0700

So, Google recently announced this… thing. They call it “Google Wave.” I have some thoughts. But first…

The Skinny on the Wave

There’s this video of the big reveal. You really don’t need to watch it unless you need help resetting your sleep cycle. But if you feel like it…

Really, it doesn’t matter whether you watch that video or not. The following short click-fest should do a pretty good job filling you in on it:

The Gruber has a good summary, both in answering that question and illuminating the state of my own brain.
Lifehacker published a nice, quick, screenshot-filled brief on the prototype client Google has built.
Om Malik is cautious, but optimistic.
Another guy who writes on Om’s site is less kind or hopeful.
Update (2009.06.09 22:49) - Gina Trapani has cut together a highlight reel of the demo video

Thinking in the Undertow

Let me preface this by saying that the following is pretty much just a spew of thought about something that almost nobody has actually gotten their hands on yet. I suppose it goes to the Google Wave team’s credit that the fruits of their labor have stirred so much thought and discussion, but the proof will ultimately be in the pudding.

We should all be prepared to eat our words and judgment when the product ships and people can get their hands on it.

There’s Sand in this Wave

As I see it, Wave is not a replacement for email. Yes, it is close, but it offers no delineation between long-form, time insensitive messages, and more temporal short-form text bursts. There is the potential for a low-signal/high-noise flood when these various communication classes are mixed.

Wave is not a replacement for instant-messaging. Nor SMS, Twitter, or the telephone. See the above.

This isn’t to say that it doesn’t have the potential to be. With the good API and extensions model that Google is promising, a Wave instance definitely has the potential to become a full-fledged communications gateway by pulling together all of the disparate communications channels we currently have. Hopefully this also means it can also be extended to effectively deal with the resulting torrential flood.

Sparkling Refractions on the Seabed

From the demo, this is what Google Wave appears to be, from a technical perspective: a seamless hybrid of instant-messaging and email, where every discreet message (or “wave” as they’re called) can be edited, manipulated like a Google Doc, broken apart, or recombined by anyone involved in said “wave”, all at the same time. Oh, and every single change of any kind is logged and exposed for “playback”.

It is a new communications channel whose scope stretches across the domain of a number of existing ones. It has the capacity for the long-form, relatively time-insensitive asynchronous messaging that email (or blogging, a public analogue of email) provides. It also has the capacity for the more time-sensitive, nearly synchronous “instant” messaging that many of us are familiar with as well. And everything in between.

There are a few other pieces. There is the Wave client, which is what every user actually sees, whether as a web application or installable software. And then, there is the Wave server, which is what facilitates all of the communication between each person’s Wave client. Finally, there is the Wave protocol, the communications dialect that the servers and clients use to talk to each other.

Google apparently intends to have as much of these components be open-source, so (theoretically) other folks can build their own client and server programs, all of which should be able to talk to each other.

Everything else falls under “how people can use the tool?” rather than the “What is the tool itself?” question.

This is conceptually complex indeed.

The Brain Wave

I would love to take the myriad communication channels I currently use and gather them together under one gateway app like this. The problem though, is that there will be too much noise. With my current silos, I can (at least somewhat) effectively mitigate a lot of noise. My email servers and clients have filters and rules. Facebook and similar social networks are gnarled messes that I more or less ignore, unless certain specific events trigger an email notification. Twitter operates on an opt-in model (unlike email or Facebook), so I have reasonable control over what (or who) shows up in my feed. I don’t have enough IM traffic to be in any danger of getting fire-hosed.

If all of these channels were to be combined into one broad, monolithic service, I believe it would effectively combine these various trickles and streams into one unmanageable fire hose. Silos can be an annoying curse, but they can also be an effective tool. It depends on how a particular person chooses to operate.

Speaking of people…

Regardless of the technology we build to do all these amazing things, people will be people. A few will more or less grok this new, complex and flexible channel, and will shape their use of it to the patterns and habits of those holding the tin can on the other end of the shoestring. A decent number will use it how they see fit, regardless of the receiving parties; but they will use the tool to communicate effectively, so who cares. But unfortunately, most people will stumble around for awhile before they figure out how the tool (not to mention other users of the tool) work, especially without there being a similar physical-world equivalent to compare to. Let’s break this down a little…

Email was designed as a digital version of physically writing and delivering letters on paper made of dead trees. This is a conceptually simple medium with several centuries of tradition and practice to draw from. And yet, it’s impressive much email misuse or poor etiquette there is, not including the gross abuse of spam (more on this shortly).
Instant messaging has a similar, but more loosely connected physical analogue in the telegraph. Though there is less collective experience to inform the use of this kind of medium, it is even more conceptually simple than email. The near real-time nature the digital age’s telegraph system works in its (and that component of Wave’s) favor.
Twitter and other “micro-blog/chat” services have no close “meat-space” analogue. They sit in a weird space between email’s “letter delivery” metaphor and instant messaging’s pseudo-telegraph, sharing characteristics of each. They have the short “burst” characteristics of an IM, but in a context where time-to-delivery (or response, for that matter) is closer to that of email. Despite these tools being almost as conceptually simple as the two previously noted media, it has been an interesting experience watching so many people wrestle with the question, “What is Twitter, and how do I use it?” And no, there isn’t a simple answer, especially to the second part of that question. The medium is too flexible to provide a generic answer without first deciding what one wishes to use it for.
Facebook and other social networks are conceptually complex systems, but they expose their various communication tools as logical silos emulating their functional inspirations. Chatting on Facebook really is just another walled-garden of IM. Facebook’s messaging is just a dumbed-down version of email. Even Facebook’s “wall posting” and “status updating” tools have a striking similarity to Twitter and the like. A user can approach all of these components with the same way of thinking as one would approach the previously noted standalone systems.
Wave is different. It looks like a seamless hybrid of several media types to the extent that there is no way to distinguish between them. In fact, each discreet message (or “wave” as they’re calling them) can embody multiple media types simultaneously. This is simultaneously a strength and a weakness. This tool is functionally complex to a degree that surpasses all of the currently popular social networking tools, but with a user interface that’s more spartan than many popular email clients. It is wide open to a mind-bogglingly large number of use-cases. The more people who use it, the more people there will be misusing it, and the more noisy the medium will be.

The Wave of Canned Meat

All of the above rambling was done more or less taking only normal, legitimate usage into account. What about when we drop spam into the blender?

Spam is a problem that email, to some extent, has become hardened against over the years. There is some serious spam-filtering technology in-place between most of our inboxes and the Internet at large. If Wave is to become a parity technology or modern replacement for email, there damn well better be some solid thought put in on this subject before the software (let alone the rest of the Wave ecosystem mentioned earlier) is set loose on the world.

I haven’t read the draft of the Wave protocol spec (yet!), but I sincerely hope there is some kind of challenge/response mechanism required before allowing waves to be passed between two given accounts. There is no such thing in our current core email protocols. Since Wave is essentially aiming to set up a brand new protocol set, now is as good a time as any to build such things into the very building blocks of the ecosystem. Wouldn’t it be nice if we could start from scratch with something that avoids that which has arguably destroyed its predecessor (email) and threatens to drown its current nearest cousins?

Seriously. There should be no need for certain scripting kits to see through Facebook’s storm of noise… and this is on a system where certain classes of annoying messages can (theoretically) be categorically ignored. What happens when you’re dropped into a system where those categorical silos simply don’t exist?

Here’s hoping that if Wave takes off, the governing specs and protocols take this into consideration. I’ll definitely be giving it a whirl when it becomes available though.

Mostly Unrelated

Finally, I feel compelled to note that this name has interesting precedent:

Wave - Audio-visual transmission sent over the Cortex. Full waves (audio and visual) are generally only available within major Alliance systems. Once a ship has left a major system (or is traveling in a system too unimportant to have a Cortex beacon), the sender must resort to more primitive means of communication.

Source: the Firefly Wiki “Cortex Lexicon” (scroll to the bottom). Yes, I’m a nerd. Please don’t judge me, but feel free to judge the Google products folks, or whoever it was who came up with this altogether nerdtastically appropriate name.

Framing the discussion of "@-replies"...

Sat, 23 May 2009 22:15:00 -0700

The following rambling blurb is a follow-on to a conversation between @sonialexandra and me about the discussion surrounding Twitter’s change to how “@-reply” posts show up (or don’t show up) in one’s Twitter stream.

There has been some significant backlash from a some parts of the Twitter user community, to which the Twitter folks are indeed responding to. It’s also worth noting that the reasoning behind Twitter’s change was largely driven by technical concerns, with some product design considerations thrown in on top. An understanding of or acknowledgement of a key idea seems to be missing from many of the discussions I’ve seen or participated in on this tipic. Namely the separation of and relation between two things:

The technical, functional core of Twitter is a one-to-many messaging service.
The product/interaction design aspects of Twitter is a product that’s built on top of said core.

Here is my attempt at getting my fuzzy thoughts laid out on this.

Twitter’s fundamental essence, its core, is “a tool that broadcasts text messages”. That’s it, nothing more.

There’s a sub-tool (the DM) for one-to-one messaging (a monocast?), but this simplicity is, I think, one of the big things that distinguishes it from every other class of social networking tool. Every other message type (such as the delineation @-replies vs an @-mention) and message convention (like #-tags) are clever hacks implemented on top of this basic text broadcasting tool, driven by how people use it and built into API clients, the Twitter.com website included.

Here’s where I have a problem. With the recent change, @-reply censoring is happening low down in the core service… in the basic tool itself. This is where makes sense to talk about technical concerns, but makes less sense to discuss higher-level “userland” and product design concerns.

I think that when discussing the behavior of @-replies, one needs to think of it in the context of “how a given Twitter client manages & filters the stream” and not “how does the core messaging service behave.” This is what I was trying to say in those <140 characters.

Now this isn’t to say that high-level issues don’t have any effect on the low-level stuff… on the contrary, high-level client features can directly impact parts of the low-level, and has informed and shaped many features in the Twitter API itself. And in fact, the proper implementation of the @-reply setting(s) that the Twitter folks are apparently working on will likely impact the API, and will definitely impact the behavior of the core service (given a sensible default that most people won’t change)… but it’s an enhancement on top of the core service, not a basic part of it.

This is the same problematic disconnect that I think many have when discussing Twitter “groups” as well. The author of the outstanding Tweetie clients has a very worthwhile blog post on this.

In the case of groups, do I think such features should be built into the Twitter website and API? Definitely. But do I think this is something that’s a part of Twitter’s core? Not at all. It’s simply an enhancement on top of it that lets a user shape how they happen to use it, regardless if it’s implemented in 3rd-party clients, or the de-facto client that everyone sees in their web browsers when they visit http://twitter.com.

I think it’s also important to mention that the behavioral change to @-replies means that previously accessible content (and the “discoverability” trait that’s intrinsic in the particular class of content in question) is now obscured, and the choice to reverse that behavior is non-existent. People tend to react badly when something, however minor it may be, is taken away from them.

Minor excuse-making: the above was cobbled together from a number of disjointed tweets that would have become a long stream of “Twitterhea”. Apologizes for the somewhat disjointed nature. I also have work at a disgustingly early time tomorrow morning, so I’m not spending much proofreading or editing time on this. And yes, I know tomorrow is Sunday in the middle of a 3-day weekend; no, I don’t normally work weekends.

And finally, I’m well aware that all of this is just my own opinion and view of things. Please feel free to rip them to shreds in polite and logical commentary.

Expanding a Tweeted Idea...

Fri, 12 Dec 2008 14:45:49 -0800

Expanding a Tweeted Idea...:

For those too lazy to click through, or don’t have access to my Twitterings, here’s the blurb I spewed upon Twitter a short few minutes ago:

Idea: transient/smart/reoccurring playlists for periodical media. Ex: a weekly list for ‘casts A, B, & C (assuming they’re released weekly).

In my efforts to cram this idea into less than 140 characters were, unfortunately, a bit lossy. The following is what I was really trying to say.

Let’s say that you’re subscribed to a decent number of netcasts, and that there are certain clusters of related netcasts. For example, if you’re into animals, you may be subscribed to netcasts along the lines of Whales, Poo-throwing Primates, and Rain Forests. You’ve probably got a slightly more varied palette than this, but these three (fictional) netcasts are topically related, and could be considered something of a home-grown “animals channel” in your netcast-catcher.

Next, let’s say that each episode of these three netcasts is published on roughly a weekly basis. You of course have no real time to consume these quality media productions during the week, or you just prefer to relax and watch those fecal-tossing monkey shenanigans over the weekend. Sure, you can manually select each episode to watch individually, but this is the freaking digital age! There’s got to be a way to automate this. Wouldn’t it be nice to have your weekly favorite animal netcast episodes grouped together a weekly playlist?

For video content, I’m sticking with Miro, and will only go back to iTunes kicking and screaming. Unfortunately, Miro’s playlist functionality is quite limited, and any media added to a playlist is taken out of the auto-delete stream. Not good. This muckery might just be enough to lure me back to the world of Apple.

iTunes has those “smart” playlists that might just fit the bill. I’ve played with them some, but my smartlist-foo is not strong. If you’re an iTunes ninja and you’ve got a solution to this, let me know in the TwitterSphere.

If there are any other solutions out there as well, I’d love to hear about them.

This problem also strikes me as something that some clever tagging might be able to solve. I know there’s at least one tag-maestro who follows my TweetStream… might he have an idea?

If a solution shakes itself out, I’ll definitely be posting about it.

Never mind...

Wed, 26 Nov 2008 22:25:05 -0800

…LifeCast can suck it. I’m not a fan of things that splice in little “posted by” links.

$2 later, here’s to Tumblrette not being sucktastic.

Test Post from the TouchPod

Wed, 26 Nov 2008 22:01:48 -0800

Trying out an app called LifeCast. Not sure about it yet. We’ll see.

Posted with LifeCast

Oh look, an "Update All" button!

Sat, 22 Nov 2008 17:17:10 -0800

In my previous post, I ripped on Apple a little bit. To be fair, the 2.2 firmware so far seems to have far more tally marks in the “improvements” column than in the “regression” camp. One of the big honking (yet subtle) upgrades is to the on-board client for the AppStore. In the “Updates” panel, there’s a nifty little button stashed up in the upper-right corner. The label says “Update All.” Holy crap, it actually installs all of your available updates! At once!!

Now let’s be honest. This functionality is found in every managed software repository system I’ve ever laid eyes on, including the Jailbreaky Freetard that have been available since the 1.1.x era. Cydia has even had a queue subsystem in some versions; select those apps you want to install/reinstall/uninstall, add them to the queue, then press the magic button and walk away rather than fondle and stroke your ‘pod for twenty minutes to babysit it through every step of the process. Now if that were to be added, Apple would deserve a solid pat on the back… for they’d finally have gained parity with the unorganized and unsanctioned ‘pod-hacker masses.

But at least they’re taking steps in the right direction.

phonePod 2.2 Firmware - Changes & New Features

Sat, 22 Nov 2008 15:27:35 -0800

phonePod 2.2 Firmware - Changes & New Features:

Found this c/o Daring Fireball. If you’re an iPod Touch or iPhone owner (referred to in my universe as the touchPod and phonePod respectively) who cares about such things as what your new firmware version does or fixes, this little page is for you.

I’m not going to rehash the list of new features and whatnot, chiefly because it’d be painfully boring. Also, many other people all over the Web who have far more time than I do have already done so. There is, however, an itch that begs to be scratched.

“Podcast Downloading” Itch

One of the new features that has received much hype and noise leading up to this release is the addition of podcast downloading to the on-board miniature iTunes application. This is a very welcome addition (that honestly should’ve been there in the original 2.0 release, but whatever). It could also be seen as Apple’s response to the press surrounding the 3rd-party Podcaster application, and the push-back and controversy surrounding its rejection from the AppStore.

Not to drop down a rat-hole here, but don’t try to argue that the Podcaster incident is about that specific application or this specific feature. It is about Apple’s AppStore approval process, and the steaming pile of bullshittery that lives inside their black box. Podcaster was just one of several such cases, and happened to receive a substantial amount of attention. This issue is bigger and more complicated than most of the treatment I’ve seen devoted it around the Web, but some time spent with the legalese shows that when you get down to the real meat, Apple truly is the large, farting elephant in the room on this one. End of digression.

Take note of the first part of this post’s primary link where mobile iTunes’ new podcasting functionality is described. Pay special attention to the following quote:

Note that there is no way to subscribe to a podcast from the iPhone, or to have the iPhone automatically update with new podcast episodes on a regular basis—for that you will either need to hunt down the newest episodes yourself or simply rely on syncing with iTunes as you have in the past. Unfortunately, the iTunes Wi-Fi Store also does not provide any indications for podcasts that you are already subscribed to, or episodes that you already have on your device, so you will need to check back with your iPod application to avoid downloading episodes you already have.

I don’t have time to turn this post into an essay about the nature of periodical media and how automation afforded by technologies like RSS readers make this stuff a viable content distribution and consumption method. However, suffice it to say that the features noted above to be absent from Apple’s sanctioned solution is exactly what Podcaster is designed to provide. Exploring new content and downloading specific episodes is nice and all, don’t get me wrong, but having this be the core functionality of mobile iTunes’ podcasting module completely misses the point of the medium.

And of course, the Freetard in me has never liked the idea of being chained to and completely reliant on iTunes. More importantly though, this is another example of these devices being reliant on a computer, specifically one capable of running iTunes. Whether Apple likes it or not, this class of device (I’m talking about the iPhone specifically here) has been a discreet and untethered entity since its inception. The usage model that Apple clearly expects of (and continues to enforce upon) its users may be viable in North America. It does not fit most of the planet though, especially developing markets. I enjoy the beautiful and solidly engineered products Apple produces, but they’re still not grokking how much of the world is using devices built by their competition. They may be the best-looking child princess on the stage, but they’re not doing a good job about hiding the nose-picking and booger-eating from the audience. I hope they figure out that they just need to pull their fingers out, clasp their hands behind their backs, and smile into the spotlight. Wouldn’t that be nice. End of second digression.

“Phone/Pod Software Feature Disparity” Itch

Another juicy tidbit from the top of the article:

We have normally focused these Instant Expert articles on the iPhone since iPod touch firmware updates have normally included the same basic features, differing in only those features that would be specifically iPhone-dependent. However, for the first time the v2.2 firmware updates for the iPhone and iPod touch do not deliver the same new features. Specifically, the iPod touch v2.2 update is missing the enhancements to the Maps application—an indication that perhaps Apple now intends to deliver certain features to each device.

I can understand why there can’t be complete feature parity between the two devices. As much as it pains me that the touchPod is clearly the stunted cousin of the phonePod on the hardware front, so it goes. But what about functionality that has no dependency on specific pieces of hardware present in one device but absent from the other?

Take the Google Street View, for instance. Your traditional web browser has absolutely no idea where on the planet it is (yet) or in what direction your screen is facing. This functionality has obvious benefits for a device that does know these things, but constitutes a value-add courtesy of extra hardware features. If Apple has gone to the trouble of implementing Street View in its mobile Maps application, what’s the (non-greedy) argument against shipping it to touchPod folk as well? There is nothing about the touchPod’s hardware that disqualifies it from handling Street View’s core functionality, and there are plenty of AppStore applications that happen to work on both devices, but have added capabilities on the phone.

No, I’m not saying that the touchPod should be “exactly like the phonePod minus the ‘phone’ part.” I just don’t like having something be artificially hobbled for no good (non-greedy) reason. It makes me want to look elsewhere. Too bad nobody else has gotten the big stuff yet; with no real competition yet, they can keep on nailing the big stuff while still screwing us on the small stuff.

How to kick your desktop's ass...

Fri, 21 Nov 2008 16:40:00 -0800

How to kick your desktop's ass...:

The to post-inaugural posts that precede this one show what amounts to my desktop. You may (or may not) be wondering what’s up with that “flaming bag that is (implied to be) containing poo” icon. The simple answer that it is my primary means of shuffling files back and forth between virtual machines and the “VM host.” The techno-babble isn’t important. What’s important is that I have a severe dearth of things on my desktop… one of which is a flaming paper bag that I’m implying has poo in it.

Let me make a polite suggestion: stop making your desktop an ugly, nasty, disgustingly cluttered mess. It hurts you and your productivity when you have a bazillion icons scattered haphazardly across your entire screen. Oh, you’re a spacial organizer with superhuman eyes? Great! Not every method is for everybody. But unless you feel you’re a super-ninja when it comes to keeping your piles of stuff organized, you might want to take some advice from a guy who’s thought about this long and hard enough to make a mini-website about it.

Get yourself kinkless, and do it now.

Seriously, read the whole thing, and think about it. If even part of it sounds like a sensible idea, then drop everything right now and just do the whole thing. I’m not kidding. In the words of a somewhat famous Internet personality, bite the bullet and stop sucking.