git ssb

Although I approve of the simplicity, how do you feel about tabs? https://github.com/dominictarr/hypertabs/

I also see that you have removed infinite scrolling, but it still works on the private feed?

@dominic I do think that tabs are pretty useful, particularly as patch* starts getting used for more and more tasks. Will probably implement it in the style where you right click + open in new tab, and then some new UI appears. That way power users get the benefit, but they aren't just there from the start.

RE the infinite scrolling removal: that's just temporary. My new feed is super hacky right now. Just a prototype. Want to rewrite it to use streams better.

But I'm already using it as my main ssb client :D so I think that's great progress!

tabs is especially an issue on a discussion tool, because you often open lots of threads up, and might be writing responses more or less in parallel. tabs are todos (for better or worse)

With patchwork, people prefer running it in a browser, because then they get tabs

The compacted follows and digs are great! I was thinking about doing that.

Okay, and other problem is that back button takes you to the top of the feed, not to where you where at.

Oh, and if you post a message, then hit "back" it still shows the "show update" button, should probably just add them, and only use the update button when realtime changes come in while you are on the same screen (though I think i prefer infinite scrolling)

the compacted digs make my heart sing !

@dominic yep, not remembering the scroll position is super annoying. Were you handling that in patchbay? Or did tabs get around it?

I'm sure I can get it to work, just need to figure out why caching the view isn't good enough.

As far as supporting infinite scrolling, I think it would make sense if the compactor worked over a "window" of msgs, maybe 100 - 300. Once you scroll to the bottom of that zone, it would load the next compacted "window".

@matt Do you think it'd be possible to convert the patchwork-thread view to a patchbay module? I think it'd be cool to switch between the different thread views.

@ev possibly, but I think the big problem is that patchkit stuff requires having the full index, whereas in patchbay, everything is streamed on demand.

With patchwork, people prefer running it in a browser, because then they get tabs

data-point : I never use patch(work|bay) in a browser for todos. I always used 'read' and 'unread', and while it existed 'bookmark' and read that way. Not to say tabs aren't good - I like them in patchbay for sure (it's the only way you can see a thread). Maybe you have data on numbers of people, but blankety claims can tend to sound more like biases <3

more data-points: I use tabs like todos or more like i need to collace information from these 5 threads but which info is nebolus as I write the post and copy together ids to reference.

I actually asked before if we can leverage native tabs somehow instead of hypertabs in the liteclient or if electron comes with more native tabs on the gtk level to split patchbay into multiple windows, which comes in handy as the amount of tabs raises above the clutter threshold.. but I think the tabs on the left/sidebar approach might cover this as well.

@matt hypertabs just sets display:none on all but the visible tab, which means they maintain their position, then you just display them again, and it's correct.

The infinite scrolling in pull-scroll loads more items from a pull-stream as you scroll down, you could easily have a thing that reads ahead and reduces those into miniaggregations like threads or dig-sets etc, then passes them to the renderer.

The other thing you gotta have, to be really good, is remove things from the top when you scroll down really far, because having too much in the dom definitely slows things down.

@mixmix sorry, user interfaces are very subjective I just mean that tabs kind of represent something I intend to do with them, which could be read and reply to a thread, or it could be docs I have open because I was doing something. sometimes I come to a tab, what was this tab open for? oh yeah! and I do the thing. I don't think this is an efficient way to schedule tasks, but that is what I catch my self doing. Anyway, without tabs at all, I'd just forget lots of things! read/unread is also a todo system, and also not a great one IMO

another data point: i use Patchwork in the browser, but don't ever use multiple tabs. i treat Patchwork more like i do Slack, where it's a stream that's impossible to keep up on everything with, it's inevitable that bits will flow past. i use my human brain to store my todos (which means i often forget them) and use the search to find things from my fuzzy memory.

I reckon there's an interesting nugget in here / root cause about what it is we're exactly people are trying to do with interfaces.

I'm hearing :

• keeping track of things
• weaving together / synthesising

could be fun to collect those threads and imagineer some interface solutions

this is the thing! use vectors point in different directions! people use the same software different ways, and are trying to get different things out of it. That is why a one size fits all solution probably doesn't fit anyone very well

i'm excited by how i heard @mmckegg outline his plan for patchwork-next: use patchbay as the un-opinionated modular extensible engine, add opinions and styles in patchwork-next that cater to the masses.

I use tabs as todos for stuff I want to respond to later, or to bookmark. A browser tab is the only way to get an URL to bookmark, as far as I know.

I have the usual collection of bookmarks (for people who do that kind of thing): now and then I use one of them. Mostly of them just lay there dormant.