It’s been a number of years since I had to think – I mean really think – about electronic communication and HEP. On BaBar, I became accustomed to a specific model of communication. E-mail for personal correspondence, for which no record inside the collaboration is necessary (e.g. arranging a meeting time); Hypernews for conversations whose archival value is, at least, non-zero (e.g. the time of the meeting); phone for connecting people together in a meeting (via MeetingPlace); the web for locating presentations either in a central database or a site (PDF preferred, please!).
ATLAS has adopted EVO [1], which was developed jointly by Caltech and the DOE and leverages technology built by the VRVS collaboration. Years ago, a colleague of mine introduced me to VRVS. It barely worked on my linux machine, and I quickly abandoned it. That was sad, because it was built on JAVA and it really should have worked well. I wanted it to work.
VRVS has come a very long way, if EVO is any indication. That said, EVO seems to be the butt-end of many jokes inside ATLAS and certainly it seems to inadvertently induce delays in meetings, due to troubleshooting. The very first day I attended the LBL ATLAS jamboree, I decided to fire up EVO and see what the meeting looked like to people on the other end of the connection. I quickly realized that the tools in EVO allow a participant to exercise a great deal of flexibility in participating in a meeting.
EVO adds extra dimensions to my old collaboration model. Video and audio are totally integrated into the client (Koala), so I can choose to send video or not. Chat is also built into the client, distributed to all the participants in the meeting or directable at only a single participant. Today, for instance, during the Hadronic final states workshop at SLAC there were some problem moments in the meeting when firing off a short chat to the speaker, letting them know there were audio problems, was EXTREMELY valuable. That, and when audio would drop out a few chats fired around to participants in the meeting could help isolate the problem.
I’ve decided that EVO augments my old model in a very positive way, even though it brings inevitable technological challenges. The challenges I’ve experienced so far stem mainly from the marriage of the phone system (literally, a phone handset that someone uses to dial into the meeting) and the EVO internet-based system. The “phone bridge”, as it’s called, seems to introduce the most problems. Feedback, dropped connections, etc. seem to stem largely from the phone bridge.
Based on the last 5 days of ATLAS-related meetings, I’ve come up with a set of personal “best-practices” that I intend to implement when running, or even participating in, ATLAS meetings.
- It’s important that the moderator (me, let’s say) focus on maintaining the connection at all times, and sending a “pause” signal out to people via chat when things go badly. It’s therefore also incumbent on the speaker to keep an eye on the chat window for emergency messages.
- Having a “shadow” in the audience, someone who is physically at the meeting site but dialed into EVO via video and audio (in fact, even listening to the audio while in the same room as the meeting is a good idea). This person is like the audio engineer, listening to the performance and alerting the moderator of problems. I did this today as an experiment, and I found that if I brought the volume on my headset up to a high enough level (not too high) I could mentally ignore the audio in the room and focus on the audio coming across EVO, even though I was in the same room. It was then immediately clear when the speaker dropped out from the connection, important if they were physically in the room and thus oblivious to the fact that no one on EVO could hear them.
- Try to avoid the phone bridge, but if you must use it watch it like a hawk. The Shadow will be of great value in monitoring such a thing.
- Wireless internet seems to work fine, but I’m a big fan of hard-lines since the TCP/IP protocols are more standardized and well defined there (there is also no encryption overhead at the network device level). I’ve heard rumors that hard-line connections to EVO are more reliable than wifi connections, and a priori I can see why this might be, but my own experience says it’s fine. That said, I fundamentally trust hard-lines more than wifi.
I plan to keep these in mind while moving forward. I’m particularly keen on the moderator/shadow model. Communication in such a large body as ATLAS is hyper-critical to the mission of the experiment. Minimizing delays is also key to maximizing meeting time, and thus getting out of meetings and getting to work. My collaborators seems to succeed in spite of the frustration they seem to feel about EVO. Me? I like it, even if it does have idiosyncrasies. I like that chat, video, audio, and identity in the meeting are all tied into one service.
With that in mind, I intend to keep EVO up during the day as a means to facilitate cooperation between my colleagues and myself. If you’re on EVO, let me know and I’ll add you to my buddy list on chat. I like that I can keep G-chat and AIM for personal use, and keep EVO for the physics side of my life.
