?

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
[continued]

I want the character limit on comments to be raised, and the size of the comment textarea to be twice as tall.

I want an alternative view for friends/filter pages with an apparent in-page control for toggling between the regular view and it, where in the alternate view, the posts are reverse chronological order of most recent comment, not entry date.

I want a first-class interface on LJ to see and work with comments, both in my journal and wherever I comment. The Inbox is not that. I want a Friends-type feed of entries on which I have commented, which show not only how many comments there are total, but how many replies (recursive) my comments there have gotten. And with an Ajaxy little triangle I can click on to unfold the (compact) list of my comments and their replies' subjects.

I want an opt-in setting, "Automatically subscribe me to comment notifications for discussions in other journals and communities I comment in."

I want four times the number of filters. Or more. I have various features I want to make reading filters better.

I want LJ to actually pay attention to suggestions.livejournal.com. I'm under the impression there's some great stuff in there.

I want to be able to "invite in" specific other users, who are not on a filter, by name, to be able to view locked posts without my having to add them to the filter, or even friend them, and I want it to be temporary with setting an expiration date a mandatory part of the interface, and the expy being no more than a month into the future.

I want to be able to set the filter of a post to "filter minus this one person" (without having to create a new filter just for this purpose). I call this the Surprise Party Planning Feature.

I want the option of having on each public post in others' journals and comms, pie-chart icons which show you how much overlap there is between the friends list of the person who posted it and your friends list: make it obvious whether the other people on your friends list saw it, to inform the reader whether it is worth reposting it oneself. Heck, make links in posts mouseoverable (opt-in feature) that shows in a little ajax pop-up an aggregate number/percent of people on your flist who have seen a post with that link in it (i.e. sum across different friends posting the same link). Answer "have all my friends on LJ seen this already?"

I want when someone goes to change the privacy settings on a post to be more restrictive, or to delete it, or to substantially edit it (length reduction), I want the user notified if that post is in any other user's Memories. "Hey, before you take that down, did you know that 20 people save at link to that in their memories?"/"Hey, user X, who won't have access under your new setting for this entry, had put it in their Memories. Are you sure you want to kick them out? y/n" I want there to be a mechanism that encourages users to schedule such changes in advance and alert subscribers to those pages to save a copy now while they can -- but not mandatory. I want putting something in Memories to mean you're subscribed to notifications (opt-in account setting) of changes to that post.

I want LJ not to rely on Ajax. Asynchrony in interfaces turns out to suck in that things can fail to happen, or get temporarily hung up in media res, and you have no idea. Also, I want to be able to use LJ on antique browsers and hardware.

I want a lot of things. But they're not things other platforms are doing.

I want the character limit on comments to be raised, and the size of the comment textarea to be twice as tall.

Better -- I'd like it to autogrow as you type. This isn't rocket science any more: Querki's had that feature for a long time, based on an open-source component.

I want to be able to set the filter of a post to "filter minus this one person" (without having to create a new filter just for this purpose). I call this the Surprise Party Planning Feature.

Heh -- yeah, that's an awfully common use case. Sadly, I suspect that the data structures in their current form don't support it.

Answer "have all my friends on LJ seen this already?"

Intriguing. This one would actually be useful on any social network, but I can't recall ever seeing anything like it.

I want a lot of things. But they're not things other platforms are doing.

Fair enough, and this is quite a good list of suggestions: I agree with pretty much all of it. Thanks...

Better -- I'd like it to autogrow as you type.

I hate autogrow. Never works well in my browsers.

Intriguing. This one would actually be useful on any social network, but I can't recall ever seeing anything like it.

It's astronomically processor intensive. I toyed with the idea of setting up a third-party service, like LJToys, to implement it via greasemonkey script and paid subscription service to do the set crunching. It couldn't handle friends filters, though; public posts only. And it would have to monitor your list of friends (people friended you) and the list of all your friends (people-you-friended's people-who-friended-them), and cache all that. Which is... interesting, both socially and technologically.

I hate autogrow. Never works well in my browsers.

Interesting. What are you using? (I've seen a minor bug or two so far, but need to know if there are bigger problems than that.)

It's astronomically processor intensive.

Well, it's a pretty classic Big Data sort of problem -- I'd certainly tackle it using Hadoop or its equivalent to play map-reduce on it. Still expensive, but I suspect it's not crazy by modern standards.

Which is... interesting, both socially and technologically.

Yaas. It wouldn't be very hard for the walled-garden services (which already have all that data, and aren't shy about using it), but doing it ethically in an open environment is, as you say, interesting.

What are you using?

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

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.

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

Sadly, I suspect that the data structures in their current form don't support it.

*shrug* By now you'll have read the comment I made on moderation, which blows this out of the water for sheer ACL complexity implementation ramifications.

This just requires that authorization checking be two-pass: first whether you're in a group that is permitted, and if so, second, whether you're (not) on the list that is forbidden. It's an "and" in the interface layer, and a new db table or two (hell, this might be an occasion to denormalize, and just store the list of forbidden users on each post as an array of max dim something small, right on the entries table.)

Edited at 2014-06-19 05:29 pm (UTC)

  • 1