Complete Conversations

Earlier today I asked a question on App.Net that sparked a conversation that I think was misinterpreted as me bypassing even more of the system1 to allow people to view and interact with posts from people that have blocked them, or they themselves have blocked. While it would be a trivial matter to simply show all posts from all accounts regardless of whether blocks are in place to prevent such a thing or not, this is really not my intention. My question has more to do with completeness than anything else. The next few updates to Nice.Social will be attacking some of the more complex issues that people have been asking for, one of which is a different conversation view that will allow for a TreeView-style layout. Doing so will not be ridiculously difficult so long as conversations are complete entities. It’s when they are incomplete that the code needs to get tricky and begin making assumptions.

Allow me to illustrate.

conversation_a

In the image above, we can see a very basic type of conversation. @person_a starts it off, and @person_b replies. Eventually we see others join in the conversation and it begins to split and evolve into three distinct conversations. This is par for the course on a social network like App.Net, but there’s a problem. @person_d has blocked @person_c from seeing their posts, and @person_c wants to see the conversation view in order to better understand the flow of the conversation. What does @person_c see?

conversation_b

If @person_d blocked @person_c, the first and third conversations will be completely disconnected despite what happened in the second conversation. These two conversations may come from the same conversation thread but, for all intents and purposes, they’re completely different conversations … even if they’re the same subject with the same ultimate root.

What I posited was whether it would be a good idea to show @person_c that the second conversation did indeed happen, as they’d see it in their home timelines, anyway, and link it accordingly.

conversation_c

The difference here is that, rather than seeing every message, we would see that the second conversation includes blocked content. Again, this could be the result of @person_d blocking @person_c or vice versa. It really doesn’t matter. The conversation between @person_a and @person_b that stemmed from @person_d’s comment will appear just as they should in a second tier, and everything would be good to go. This allows for a complete view of a conversation as best as possible. As someone who has worked with databases for over 15 years, data completeness is incredibly important to me. Broken data — especially obscured, broken data — infuriates me to no end as my mind wonders if something is wrong with systems if the human interactions are "out of alignment".

Of course there are a few ways to handle the comment from @person_d. The post can be completely eliminated from the view and a disconnected conversation can be shown, leaving the reader to wonder how a branch replying to @person_d with no discernible parent record came to exist.

Another way to resolve this issue would be to eliminate anything that came after @person_d’s post. The posts from @person_a and @person_b will continue to appear in @person_c’s timeline, but they will not be able to see it in the conversation view as an entire entity.

The third, my preferred way, would be to show that a post (or string of posts) does indeed exist, but collapsed in such a way that it’s understood the material is best ignored. Of course, if a person *really* wanted to know what those messages said, a client could be configured to collect the information without an API key and display it. This, too, would be trivial for someone to add to a personal branch of Nice.Social. Heck, this could be extended to show that posts have been deleted from the conversation, too!

As I said above, when I think about doing a proper conversation view, I think about data completeness. Hiding missing chunks of data is the default answer by many, but strikes me as overly simplistic for the types of complex discussion that can arise on the App.Net platform.

Of course there is the problem of having our posts — posts that we own according to the contract of App.Net — shown to people whom we have revoked the privilege, and this is not something that I will blatantly disregard. There will be no stupid “opt out” function necessary to ensure our posts are not easily read by people we’ve blocked from view. The goal of the exercise was really more about answering the question of completeness and information display.

I’ve said this before and I’ll say it again here. No code has been written to allow a person to access or read posts that have been denied to them. This question was raised as a thought experiment with the hopes of collecting ideas from the people who actually use the network. You are free to examine the source code for Nice to confirm what I’ve said.

Back to Basics

How many site designs can a person make and subsequently throw away before they find a layout that they like? When it comes to the upcoming Nice.Social layout, the answer is apparently up around 15. What you see in the image here is version sixteen which, believe it or not, involves some collaboration with a Canadian designer. This is probably something that I should have done a long, long time ago.

Nice Progress

One of the many things that I have tried to stay away from is the “standard design” that seems to be used with just about everything deemed social. While Nice will undoubtedly be used as a place for people to chat, it’s also supposed to be a place for people to easily publish the things they wish to share. Podcasts, blog posts, pictures, and random thoughts … no item is too big or small to warrant design restrictions. The problem with trying to do everything, though, is that one can end up getting nothing done. For this reason, Design v16 goes back to basics with a slight twist. The text-entry area supports dragon drop, basic WYSIWYG functions through keyboard shortcuts, Markdown, and HTML. But it’s also able to expand from an overly-simplistic bland box of blocky letters to something much more powerful.

So, with roughly 50 days to go until the big launch, Nice might just have an ugly two-column design (single-column on narrower screens) with an entry form that really focuses on giving people the power to publish things in a simple, intuitive way. Hopefully with the help of another pair of eyes and some different perspectives, we’ll even seen design decisions that make sense! Well … that’s the hope, anyway.

There’s still a lot of work to be done, and I will be too embarrassed to show my face online if this is the design that Nice officially launches with, but I’m glad to see that an interface is finally making good use of the API that has, until now, been exclusively accessed through RESTful API testing tools.