Stuff and Things

On Groupings and Concentric Circles

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?

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 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

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:

1. 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.
2. 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?

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.

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

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

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?