Live data from Hacker News

Non-obvious remote work techniques

queue.acm.org

71–80 of 87 posts

Re: Non-obvious remote work techniques

#71

> makes the mute button easier to find It's odd this is still an issue. I'm not sure why the mute button is not featured more prominently on videochat apps. It's almost the primary feature during a call that makes things go smoothly. Also, there's always one guy who has to say every bloody time, "are you there, have you forgot to unmute?" if you fail to unmute and start talking <100ms after your name has been mention…

I appreciate apps that provide a universal keyboard shortcut like Zoom that works even if I’m focused on another app. Next best is Google Meet but it only works when you’re focused on the same tab. Worst is Teams, WebEx etc that don’t provide any keyboard shortcut

My mute preference in videoconference tools:

Universal keyboard shortcut > app focused keyboard shortcut > no keyboard shortcut

Re: Non-obvious remote work techniques

#72

> makes the mute button easier to find It's odd this is still an issue. I'm not sure why the mute button is not featured more prominently on videochat apps. It's almost the primary feature during a call that makes things go smoothly. Also, there's always one guy who has to say every bloody time, "are you there, have you forgot to unmute?" if you fail to unmute and start talking <100ms after your name has been mention…

I set up a mute pedal going to my microphone so there's no dependency on software or even clicking with my hands. I just toggle it with my foot. But then, it's a full audio setup with a shure sm7b, preprocessor and audio interface, instead of your typical conference call headset.

Re: Non-obvious remote work techniques

#73
post #55
post #41

Earlier quoted context omitted.

This is cool, thanks for the tip! How is performance compared to meet.jit.si?

I used meet.jit.si once but my own server mostly and I couldn't tell you the difference in user experience. Seemed exactly the same. Video: The default install sets up for 720p. It seems to start notably worse and then scale up to 720p within a minute, often much less. Some congestion control thing I expect. You can set 1080p or other (lower too) resolution limits if you like. I tried 1080p but at ~6-7Mbit per connec…

Thanks for the detailed rundown, definitely gonna give it a go now!

Re: Non-obvious remote work techniques

#74

Earlier quoted context omitted.

This is only a problem with headsets that have poor drivers. Better devices like Jabra headsets integrate directly with Teams and will actually synchronize mute status between the headset and Teams!

Cool! YMMV but 0 of my WFH colleagues own business-grade headsets though. Some have Airpods, and most use Gaming headsets (like I do) or Bose QuietComfort (which IIRC don't have dedicated mute buttons). Until we find a unified API around all those devices, a prescribed unified usage pattern IMO doesn't make sense yet.

Eventually companies will realize they should spend or reimburse to upgrade "home office" equipment to "business-grade".

Re: Non-obvious remote work techniques

#75
post #60

Earlier quoted context omitted.

Teamspeak guild, assemble!

Yea, gaming is miles ahead of everything in this area. It obviously doesn't focus on video too much, but audio and text are on point.

I've heard of a few companies preferring Discord over Slack or Teams right now exactly because gaming figured out so much of this decades ago and Discord prioritizing it works well for those companies.

Re: Non-obvious remote work techniques

#76
post #37

I feel like "Accurate Chat Status" only works if it's automatic (as in, a calendar integration that switches your status to "in a meeting" or "it's after 6pm, probably afk.) Otherwise you get: 4pm: "Ah, bob's status says he's in a meeting. I could message him, but I'd like this to be a quick, synchronous, chat discussion." 5pm: "Guess bob's still in a meeting..." 7pm: "Let me check - yep, still 'in a meeting'" 10pm:…

For me automatic idle+meeting detection is not good enough. There are lots of times when I can't chat immediately, but I'm using my computer and not in a scheduled meeting. Pair programming, someone else at my desk (pre covid), programming in the zone, watching a presentation, currently chatting with someone else, etc. etc. I want the expectation that my Slack icon is green to mean that I'm at work and I'll reply som…

Several of those situations you could use existing "meeting detection": full screen apps signal to most of these detection systems that you are busy. If you are watching a presentation or even programming in the zone, if you have it full screen you should get automatic signalling that you are busy.

(VS and VS Code have nice fullscreen views that are great because they also cut down on other distractions even inside of themselves. VS Code also has Zen Mode which pairs really nicely with fullscreen and cuts down on distractions about as much as possible.)

Re: Non-obvious remote work techniques

#77
post #37

Earlier quoted context omitted.

For me automatic idle+meeting detection is not good enough. There are lots of times when I can't chat immediately, but I'm using my computer and not in a scheduled meeting. Pair programming, someone else at my desk (pre covid), programming in the zone, watching a presentation, currently chatting with someone else, etc. etc. I want the expectation that my Slack icon is green to mean that I'm at work and I'll reply som…

Several of those situations you could use existing "meeting detection": full screen apps signal to most of these detection systems that you are busy. If you are watching a presentation or even programming in the zone, if you have it full screen you should get automatic signalling that you are busy. (VS and VS Code have nice fullscreen views that are great because they also cut down on other distractions even inside o…

Hey that's a good tip, I didn't know about fullscreen status being a signal for busy detection. This is a useful tip for me personally that I'll start using, thanks!

That doesn't quite resolve what I'm talking about. Keeping apps full screen isn't realistic for me, since I'm app switching all the time and often need multiple apps side-by-side, especially when coding. And again, my main goal commenting was just to challenge the very idea that chat status should be minute-to-minute accurate. I don't want that idea to spread, I want people to expect to wait for a response, I want chat to be default asynchronous, and for people to just be happy when they occasionally don't have to wait.

By and large this just isn't a big problem for me, it's a totally minor issue, but would be nice if we collectively have the same expectations. At my work, people mostly do use chat asyncronously and don't start chats with just "hi" waiting for a response. I'm personally relatively happy with my work interactions, but I'd prefer if attitudes didn't shift in the direction the article is advocating.

Re: Non-obvious remote work techniques

#78
post #55
post #41

Earlier quoted context omitted.

This is cool, thanks for the tip! How is performance compared to meet.jit.si?

I used meet.jit.si once but my own server mostly and I couldn't tell you the difference in user experience. Seemed exactly the same. Video: The default install sets up for 720p. It seems to start notably worse and then scale up to 720p within a minute, often much less. Some congestion control thing I expect. You can set 1080p or other (lower too) resolution limits if you like. I tried 1080p but at ~6-7Mbit per connec…

Missed the edit window of my other post. Just got it setup and it was a breeze, only took ~30 minutes! It's running with Docker (nginx w/ Let's Encrypt, Jitsi on http, port 8000) and it was a bit unclear what specifically needed to be configured in the `.env` file[0] but managed to get it up and running on the first try.

So far I've only tried it with 2 people but the CPU barely flinched (a 2 core basic VPS) - most of the heavy lifting seems to be happening client-side. Uses ~500 MB of RAM.

Initial impression: 5/5

[0] https://jitsi.github.io/handbook/docs/devops-guide/devops-gu...

Re: Non-obvious remote work techniques

#79
post #8
post #5

Is there a good reason why ACM can't make their site readable for the largest group of computers in the world - mobile devices?

Works fine for me on Firefox, and I can even use Reader mode.

For me, with Firefox on Android, it delivered what appeared to be a desktop site (tiny text, clearly non-mobile layout). I almost never encounter that on websites, so the problem is not with me nor my phone. My phone is a Note 8 (still reasonably high performance and with a very large screen).

It's nice that it works for you, and sure I could try reader mode, but I should not have to switch to reader mode to view a website.

Re: Non-obvious remote work techniques

#80

> makes the mute button easier to find It's odd this is still an issue. I'm not sure why the mute button is not featured more prominently on videochat apps. It's almost the primary feature during a call that makes things go smoothly. Also, there's always one guy who has to say every bloody time, "are you there, have you forgot to unmute?" if you fail to unmute and start talking <100ms after your name has been mention…

Some videoconference solutions that are pushed on businesses aren't mature at all: in that Cisco thing when you mute someone it mutes them for everybody (not just for you), so it's hard to have a mixed conference because you either hear people in your physical room twice or remotes obviously don't hear them at all if you use the 'mute participant' button.

I can’t think of a situation where someone would need to be muted and it shouldn’t mute them for everyone. That is not a scenario that I think anyone would expect to work that way.
Post reply on HN