Previous Entry Share Next Entry
System and Method for Presenting Complex Threaded Conversations on Small-Screen Devices
device
jducoeur wrote in querki_project
[Continuing from "Conversation Threading Models"]

Ooookay -- now that I've laid out the groundwork (most of which has been in the plans for some time now), let's get to the point of what woke me up at 9am this morning: how the heck do we make light-threaded conversations work well on a smartphone?

Keep in mind, Querki must work well on iPhone and Android -- that's essentially a business requirement. It is unambiguously clear that mobile technologies are taking over the world, so if you don't work well on mobile, you're toast. I don't love this particular trend, because *I* like doing many things with a serious screen and keyboard, but it's clear that many of my use cases require a good mobile element.

And conversations *especially* must work well on mobile. Conversations are interactive back-and-forths, all about notification and reply. If somebody comments on my Thing, I want to know about that promptly, and I want to be able to reply back quickly. That ranges from "nice to have" to "deathly critical" depending on the use case, but it's pretty much always a good idea.

The problem is, "mobile" mostly means "smartphone". Doing this well on a tablet isn't *too* hard, since you have a fair amount of screen real estate. But doing complex threaded conversations on a phone? That will take some creativity. Hence the oddly-worded title of this post. If I was a believer in software patents, *this* would bloody well be patented -- heaven knows, it would be a better patent than 3/4 the ones coming out of Apple. Since I hate software patents with a burning passion (and since I'm not working for a VC, I can decide it for myself), we'll instead anti-patent the design: publish it publicly online, so that nobody *else* can patent it easily.


Here is a starting set of requirements:
  • To begin with -- the underlying model is heavyweight-threaded, as described in the previous post. We have Threads, each of which is a linear conversation in response to something (often in response to a comment in a higher-level Thread).

  • It must be extremely simple to follow a single thread. The most common action is to simply read from top to bottom.

  • It must be easy to understand which comment a reply adheres to. That is, I need to be able to see my context.

  • It should be easy to see new comments within the conversation, wherever they are, while still being able to see context.
Context is the killer here. Threaded conversations can be just plain hard to follow if you aren't clear where they are springing from. So far, I've never even seen anybody *try* to deal with this problem, but I think we'll tackle it. I've started laying this out in the wiki, but let's talk about it here.


Soooo...

Strawman Design

When I am viewing a Conversation on a smartphone, I see a display with a bunch of elements. At some point I'll have to actually draw this, but for now try to envision it.

At the top is a one-liner showing Context. This is set apart and highlighted to illustrate that it's the context of the thread -- let's call that the Context Bubble. The content depends on what the thread is in reply to; my guess is that it's roughly:
  • Replying to a Thing -- the Display Name of the Thing.

  • Embedded in a Thing -- the text immediately before/commented by the Thread, at least the first line

  • Replying to a Comment -- the avatar and name of the commenter, and the beginnings of their comment
We'll need to experiment to get this right, but the high concept is straightforward: the top of the screen is a breadcrumb indicating what this Thread is about. In all likelihood this will be configurable to allow the user to decide how many lines to show by default (and maybe even to control the content of the Bubble), but that's an easy detail.

Under this is the Thread itself. This is a scrolling list of comments -- you just scroll down to read it, as everyone is used to on their phones by now. (That is, you swipe up to scroll down.) The Thread is *slightly* indented, to provide a visual cue of the master/slave nature of the Context and Thread, but we're not going to try to keep sub-indenting over and over.

If I am simply reading all Comments to a Thing (or the Threads under a Comment), as I scroll down, the context "pushes" and "pops". That is, when I get to a sub-Thread, the Comment being replied to slides into the Context bubble at the top, and now I'm scrolling through the Threads under that. When I get to the end, the higher-level Context reappears. The key is that I can always see the Context of the Thread currently being viewed. (Making this adequately smooth will take some experiments and a bunch of programming, but we'll figure out what works best.)

Since we have a touch screen, we'll take advantage of that. Swiping to the right means "out" -- it pops the Context into the main reading area, and shows *its* Context in the Context bubble. This will be stateful, so that swiping left means "in" -- back to where I was in the sub-Thread. This way, I can easily move back and forth up and down the stack, to remind me of what we're talking about here. (I don't know any existing systems that do anything like this, but it seems really useful to be able to move up and down the stack like this, to follow complex conversations.)

Heavy-threading basically means encouraging folks to comment *intentionally*, so there probably won't simply be a comment-input field at the bottom of the screen. Instead, there will be a comment-input box at the bottom of each Thread, a prompt to say, "This is an appropriate place to toss in your tuppence" -- clicking there brings up your keyboard. Each comment will also have a small icon that, when pressed, gives you a comment-input box to start a sub-Thread. This makes it *easiest* to comment within the conversation, but allows side-Threads, as we want.

There will be one or more Notification systems. There will certainly be a mechanism inside Querki to see which conversations have new content. (Just like CommYou and Wave had.) There may also be optional emailed notifications, although I want to avoid that getting spammy -- it'll likely just be a daily summary. In the smartphone case, there should be pushed Notifications -- a way to tell Querki to flash me when new comments come in, and to go to those quickly. (Normal for mobile-based communication systems.)

When I am looking at a previously-read Conversation that has new content, we should focus on that new content. In the desktop version, that will likely work the same way that both CommYou and Wave did it -- you hit spacebar to go to the next new comment. In the phone version, there will probably be a button in the corner or some such, which means "next". (Or maybe a diagonal swipe, or some other gesture-based input.) The display will look more or less normal, except that we will start out focused on the new comments. Earlier comments in the Thread will be available, but will be above the displayed area (so you swipe down if you want to see them), and will be subtly highlighted (eg, greyed out) to indicate that they are older. As soon as I have the *bottom* of a comment displayed, we mark that comment as read. (So we can keep track of what's "new".)


There's more to think about here -- all sorts of stuff like how we'll deal with adding and reading embedded Threads, if that happens. But this looks like a decent starting point.

Truth to tell, while this is designed for mobile, we may well use much of this design for the tablet and even desktop-browser versions of the product. While those aren't so badly space constrained, the problems of context are largely the same, so the same ideas mostly apply. We'll need some other mechanism to replace the swipe-right/left context switching, but we can come up with something.

So -- thoughts? I'm in brainstorming mode here, and obviously nothing is going to become hard and fast until we do a lot of user tests, but I would *love* to get critique and additional ideas now. It's likely to be a year or more before most of this gets properly implemented, but in the interests of anti-patenting, I'd like to get the ideas out on the table in public, to make it harder for someone to come undercut us later...

  • 1
First, thanks for making an anti-patent.

"Since we have a touch screen, we'll take advantage of that. Swiping to the right means "out" -- it pops the Context into the main reading area, and shows *its* Context in the Context bubble. This will be stateful, so that swiping left means "in" -- back to where I was in the sub-Thread."

This seems to leave the function of 'swipe left' undefined when you're already furthest "in". Which I didn't think worth mentioning until...

"When I am looking at a previously-read Conversation that has new content, we should focus on that new content. In the desktop version, that will likely work the same way that both CommYou and Wave did it -- you hit spacebar to go to the next new comment. In the phone version, there will probably be a button in the corner or some such, which means "next". (Or maybe a diagonal swipe, or some other gesture-based input.)"

Actually, I think this 'next' function would be well served by overloading "swipe left" with it. Then swipe left always means "get me more detail". If I've previously 'zoomed out', it gets me more detail by zooming back in. If I'm already *at* the lowest zoom level, it get me the next *new* detail.


Intriguing. We'll have to test that with users, and see if they find it intuitive (and check to see if there are any problematic edge cases), but it might well work nicely. Thanks!

  • 1
?

Log in

No account? Create an account