?

Log in

No account? Create an account
Previous Entry Share Next Entry
What mainstream social network features *should* LiveJournal pick up?
device
jducoeur
Having just shared an EW article on Facebook, it crystallized for me a point about LJ's recent "+1 button" flap.

The thing that bothered me about the whole +1 feature, I am now realizing, is that it was a solution in search of a problem. That is, my sense was that LJ was mostly doing it to keep up with the Joneses, with no thought to what the actual effects on the community would be. It was notable that they never said, "Here is a problem we're trying to address, and this is the way we're planning to deal with it" -- they just said, "Here's a new feature", with no rationale presented at any point aside from the fact that Everybody Else Does it.

And the thing is, I don't actually *like* this feature on FB or G+, because it is too ambiguous. I certainly use it, but I am always bothered by it. FB's "Like" is connotationally wrong in many circumstances: what I usually want to say is, "I agree with this post" -- but there are a lot of posts on horrible subjects, where pressing the "Like" button is just plain squicky. And Google's "+1" is (deliberately, I suspect), semantics-free -- it is never quite clear *what* somebody means when they press it. Sometimes it indicates agreement, sometimes it's a cheap-and-quick way to share the link, sometimes it is simply a way to store this link for future reference.

(Of course, the truth is that both buttons mostly exist for the purposes of giving more information to Facebook and Google, so that they can more accurately profile you, to sell you as an advertising target.)

When I ponder it, I find that I wouldn't actually mind buttons with clearer semantics. A simple "I agree" button would have some downsides (in that it would reduce the impetus to actually comment meaningfully), but at least I would understand its purpose. Frankly, an "I read this" would fulfill the social-back-scratching that many people mean when they say "Like". A configurable mechanism, that let you design your *own* buttons on your blog, and choose from a palette of canned options, might be downright spiffy and interesting. (If more challenging to implement.)

This is leading me to wonder which features from the big social networks I actually *want* in LJ. The one that jumps out to me is "Share". I've wound up doing most of my link-sharing via FB these days, simply because it is so damned *easy*: click the button, type my meta-comments, and it's done. I'd love to have something similar for LJ, but of course LJ can't make sites pick them up, and nowadays they're sufficiently minor that most sites won't. I suspect the right answer would be for someone to implement this as a browser plugin that detects the presence of a Facebook "Like" button and injects the LJ version. (Or possibly just adds a right-click that lets you Share any page via LJ.) Does this already exist?

Anyone have other ideas? LJ's comment system is vastly better than FB or G+'s, and it had the concept of distinct flists long before they picked the idea up. Are there any other features of the other social networks, or variations thereof, that you think would be positive additions to LJ? And for that matter, what features *have* you always wanted to see on LJ?

  • 1
Camino 2.0.9, Firefox something recent, Safari 5.1.10, and Blazer (on which autogrow will never work).

Okay, good reminders to me of more to test. (Especially Camino and Blazer, which I probably haven't even looked at yet.) Thanks.

I'll have to ponder the right way to handle this. I suspect it's going to involve being realistic about whether autogrow works on a given platform, and making sure that if it *doesn't* work right, we fall back to a UI that still doesn't suck. (Which it might well already do, but that assumption should be checked.)

Hmm -- this may require giving the Space's designer the ability to specify how tall they would prefer a given Large Text field to be. That's not hard to do, but doesn't exist yet...

There's a site (that shall remain nameless) with autogrow that I visit in FF (haven't for some time, so don't know how more recent FFs behave or if this has been fixed) and the comment window has the most amazing typing lag. I have no idea why.

Likely the code doing something excessively clever in Javascript, and not sanity-checking it. It's an easy trap to fall into, and if you're going to do a lot of "live" stuff as the user types you need to always think about how much you're trying to do per keystroke.

(This is a bit front-of-mind for me: some of the WYSIWYG stuff I would like to do in Querki is potentially a quagmire of lag unless done carefully...)

Especially Camino and Blazer, which I probably haven't even looked at yet.

They're antiques. Honestly, if your site works in Netscape 4.7, it will work fine in those. :D

Slightly more seriously, AFAIK, js continues to play poorly with assistive tech. Having js-free (or at least "js only at load time", or "js conveniences") sites is an accessibility bonus.

Likely the code doing something excessively clever in Javascript, and not sanity-checking it.

Yeah, I just can't figure out what it's doing that's so demanding. Is it sending every keystroke back to the server and waiting for a response?? (I could read the js, I suppose, but haven't troubled to.)

Slightly more seriously, AFAIK, js continues to play poorly with assistive tech. Having js-free (or at least "js only at load time", or "js conveniences") sites is an accessibility bonus.

Yep, known issue for some time now. (Pretty much since LJ rolled out its new commenting system and broke lots of assistive tools.) The medium-term plan is to support alternate UIs, specifically because of this pair of issues (older browsers and good assistive support). There is a very deep tension between trying to build new-and-sexy UI vs. supporting those properly, and I'm disinclined to kid myself that I can solve that hard problem.

Instead, the plan is to call a spade a spade, architect for multiple UIs, and plan for an alternate UI that is *specifically* designed to play well with older browsers and assistive tech. That's more than simply tweaking a few UI features: it potentially implies a real rethink of some workflows. That, in turn, has a lot of architectural implications: the system needs to think in terms of internal APIs, with UIs as drop-in modules, so that it's sufficiently flexible.

(While it would be lovely to have The One True UI that works great in every circumstance, I'm betting that it's a pipe dream.)

I'm not going to be able to do much about it this year, while I'm still getting the core bootstrapped. But I'm trying to move the architecture in that direction (albeit slowly), and it's in the plan for next year to properly prioritize this. (And I have a couple of folks who have volunteered to help me understand the assistive tech better when I get there.) Actually, that's a good reminder -- there, I've just added it to the formal Roadmap, so I don't lose sight of it.

Is it sending every keystroke back to the server and waiting for a response??

Not impossible -- I've certainly seen naively-designed systems that did that. (Usually built by programmers who have a 5ms latency to the server, and don't see any problem with it.)

(While it would be lovely to have The One True UI that works great in every circumstance, I'm betting that it's a pipe dream.)

You can have that if you can implement it on Netscape 4.7. :)

In reality, the other huge problem to be aware of is that ever growing number of people using the web from handhelds. Quite aside from the js (and CSS and HTML5) issue, there's the fact that UIs should work differently when you have different amounts of screen real estate to work with -- and different amounts of bandwidth and processor power. For instance, inline editing is lovely on my desktop machine. But don't make my not-so-smart phone reload and redraw the entire huge page just to present me with inline editing -- take me to a new, smaller, page with just the editing fields.

"Responsive design" is apparently only about layout, not about workflow. And thus has been a big disappointment to me.

Yep -- that's actually a front-and-center priority for me. Regardless of the ever growing number of people, *I* use Querki via my phone pretty frequently, so any shortcomings wind up in my face. I can't say that the current state is as good as I'd like it, but it's at least adequately functional (heaven knows, it's already better than the majority of websites), and I'm slowly moving towards usable.

That's going to be a constant battle, though, not something I fix and am done with -- if Querki winds up successful, I suspect I'm going to need people focused on mobile, regularly testing everything on both the phone and tablet form-factors, and arguing about how they should be different from desktop. Once again, I doubt that there's a *good* one-size-fits-all answer, and the alternate-UI mechanism will eventually come into play there as well.

The hardest problem is actually going to be in promulgating best practices via the tech, though. Since Querki is more a platform than an app, I can't entirely dictate that people build their Spaces in ways that are ideal for mobile. Instead, I have to look at it as a second-order problem, providing them with tools such that mobile compatibility flows naturally from the easiest choices. Some of the basics are fairly easy (using Bootstrap gets us the basic responsive-design stuff), but I suspect we'll find that we need to focus on having the user say what they want to accomplish, and choose the right UI for the circumstances...

P.S. A bit of wisdom I got from Uncle Bob at SDBP: The right object model for your code might be quite different from the object model in your users' heads. He used as a teaching koan to this point, "Should the square class derive from the rectangle class?" But the thing is, it's important to design UIs to the object model in your user's heads.

It seems to me a large amount of the problems I've seen in web UI have been rooted in this failure of perspective taking.

(Deleted comment)
Querki's in an odd position because it has a middle mental model, namely, users are allowed to push Objects around. This makes things extra tricky, because the user's mental model looks like an object model, but isn't quite.

Yaas. Indeed, I've long considered this to be Querki's hardest problem to overcome, and it's why I'm unabashedly focusing on techies as my initial early-adopters, since they are already somewhat comfortable with the idea of breaking down a problem. (It is also why Querki's preferred workflow is kind of evolutionary, and I'm going to be putting a lot of weight on making trial-and-error not *too* painful.)

I figure the hard part is going to be figuring out how to elicit an object model from non-technical users, that at least approximates what they want. I'm not sure how much existing literature there is on that front, but I anticipate a *lot* of learning over the next few years...

Not quite the way I usually think about it, but that sounds about right.

Relatedly, I've long since found that good UI *code* and good UX are often closely related, and that's not accidental. Poorly-factored code often suggests that you don't have a clear mental model of your representation, and that often surfaces as confusing UX. Improving either aspect often (although not always) improves the other -- getting the factoring of UI code right often forces you to understand *why* you are building what you are.

That's not a hard-and-fast rule -- sometimes good UX demands things that look weirdly fiddly from a pure code perspective -- but it seems to be a good 80/20, in my experience...

Poorly-factored code often suggests that you don't have a clear mental model of your representation, and that often surfaces as confusing UX.

Indeed. And not just confusing UX, but frustrating UX.

Remember, when the user can't figure out how to do something in your app, their first assumption is that they're stupid, and they feel shame; when the user can figure out how to do something in your app, but it involves a ridiculously elaborate, inconvenient, and frankly unnecessary set of steps ("AUGH WHY COULDN'T YOU AUTOPOPULATE THAT VALUE?! AND IF I HAVE TO LOOK IT UP AND ENTER IT MANUALLY, WHY TO I HAVE TO CLOSE THIS WINDOW TO DO SO?!"), their first assumption is that you're stupid, and they feel rage.


Edited at 2014-06-20 04:15 pm (UTC)

Yep. All of which is why the usual principle of, "Get your ego the hell out of your code" is even more important when it comes to UX than it usually is.

One of the most important (and challenging) disciplines for building Querki has been considering not just every user complaint but every user *question* as a potential bug report. Doesn't matter if it makes oodles of sense to me; if the folks using it don't intuit what's going on, I should be looking for ways to improve it...

  • 1