Clojurians Log v2

@meow: I'v done a bit of a brain dump in there. Still need to do the pros and cons of each.

Also this is something I think everyone involved should have a read of. http://whoo.ps/2015/02/23/futures-of-text

If we are really wanting to make something that is extensible and hackable that is adopted at large we need to be thinking in terms of the motivations for the Chat era that is upon us. Plenty of talk about chat being the next big thing. This is the reason why Facebook has two chat applications and paid top dollar for Whatsapp. Also the reason why Slack has gotten so much funding. I wouldn't be surprised if an open source project pops up in the Elixir space.

@grounded_sage: great, I will read both of those, thanks

made some major changes to make it easier to get started locally (now, by default, we use datomic-free, don't use redis, don't require a chat profile) also new docs: https://github.com/braidchat/braid/blob/master/developing.md if you've had trouble getting it running before, it should be much easier now still planning on using mount or component to make things even simpler

@grounded_sage: thanks for sharing the links, good thoughts there. chat bots have great potential. I do wonder about discoverability though, and GUI's having been more accessible than CLI in the past (but CLIs can be much faster for power-users). with chat, bot commands are often done in public, so that may help with discoverability

once we get integrations going, I think lots of advantages of threading will pop-up (ex. bi-directional sync conversations on github issues... or even do email threads)

re: having 'full threading'... something like this could be worth a try: https://github.com/braidchat/meta/issues/148

The forking looks very similar to the trees that I drew last night

I'll jump on sketch when I am at the computer next. The key thing with the chat bots I see is the AI. The Futures of Text essay is talking about how it could potentially replace Siri as building AI over text is easier than speech due to there being less variables (voice/microphone/ambient noise). So that would mean you would be speaking to the bot in your natural language instead of using shortcuts/keys/macros.

The key things I am thinking about at the moment is the tone/context of a message and the discoverability. The way I see it is there is (Announcements /or Statements), (Questions), (Idea /or Suggestions), (Reactions /or Statements). When you are in a room full of people talking you generally focus/contribute to one thread of conversation. I'm wondering how do we emulate this. When someone freshly enters a room is they would probably see a mix of fresh messages and the tail end of conversations. Would the tail end of the conversations just say 'X' replied to 'Y' with the message. And they click on it to see who they replied to. Or would it show a short of the message X is replying to. Would that short be the parent 'thread' or should it be the root 'thread'.

* Room full of people. But can still hear other conversations and chime in at any time.

That Futures of Text article is awesome.

@grounded_sage: I would caution that the analogy to 'people in a room' breaks down when transferred to a digital space b/c digitally, you can handle multiple simultaneous conversations b/c they are less ephemeral, more async, and you can retrieve lost context without disrupting the group

I am excited to see what insights you come up with

@rafd: That's a good point. The in a room conversations require an interruption of conversation when 'switching' into a conversation which may be the requesting of information for context or confirming the context of the conversation. I was more referring to the overhearing of conversations surrounding conversations. Say the room may be business networking and you are talking about 'company structures' then overhear a nearby conversation about 'web development'. Then decide to chime in. So if a new conversation thread put a virtual wall in the room which reduces noise but makes it difficult to discover the current status of active conversations. It would make it difficult to enter a room and find something of interest to chime in on or to switch to.

we don't get much participation from newbies on Braid but I'm not sure why or what, if anything, that says about Braid at this point in its development

Still as someone who has partially studied industrial design and UX giving as much thought about this in the early stages can save a lot of wasted Dev time. TBH I think it's just because it is very early. If I saw this and hadn't already read about chat apps/ needed Discourse & Slack for my future business ventures/ believed in the tech stack I would have dropped it straight away.