I wonder if 'dang' followed the same process I did: click the submitted link; read the interesting abstract; scroll to the bottom only to be scared by the embedded video; recover for a second from the panic of being without plain text; scroll back up scrutinizing the small print for a link to actual paper; then click with an awkward urgency, feeling relief at having found my way back to safe ground.
Then I asked myself, "Why did the submitter link to the container page rather than to the real content? Maybe 'dang' should change the link?" But then I wondered, "What if there are people who actually prefer the video? It's hard for me to picture, but presumably such people exist. How will they be able to watch the video if the link goes straight to the PDF?"
So as a survey for my sanity, I have to ask: How many people watched the video without looking at the paper first? How many looked at the paper without giving any consideration to the video? Second, does this correlate with the first 'sin' in the paper? Do those who prefer linear text also frequently wonder if unnecessary distributed parallelism tends to hamper performance?
On previous USENIX submissions I've put some variation of "[pdf/slides/video]" in the title to indicate multiple things are available, but this just created unnecessary work for poor `dang` who had to edit the title to remove it. I really do try to avoid causing work for the moderators, so this time, I did not put the extra info in the title. I was proud of myself for learning from my mistake... until I saw `dang` adding a comment with a direct link to the paper pdf. (sigh, I'll probably never learn ;)
If there is a "right" answer, then I still haven't figured it out yet.
As for my access pattern, I actually found the USENIX page from another site listing various papers, so that's what I was looking for when I loaded the page. I made sure the USENIX actually did provide a download link to the full paper PDF (sometimes they don't/can't), and then started downloading the video with wget in the background while I read the paper... I still haven't watched the video yet, but I will.
I think the FAQ is out of date with regard to adding an explicit [PDF], as the system now adds this automatically for links where the type is apparent. But I'm always impressed at how efficient the new 'dang' API is for adding publication dates to submitted papers!
Though it's not really "cloudy" per se, I think there's an eighth deadly sin, "Ignoring Architecture and Infrastructure." If you want to get repeatable and comparable results, the system and network architecture, as well as the supporting infrastructure, can make a huge difference.
LNCS uses instead a smaller paper (not A4/letter) with one column, I prefer two columns on standard paper to that approach.
> For similar reasons, long lines (wide paragraphs) are slower and harder to read than narrower ones. Lines of around 100 characters present neat bite-size chunks of text that can easily be decoded, and also make it really easy to scan round to the start of the next line. That’s why newspapers and magazines use several columns on a page, and why books use the same common format.
There are some controversies, however; e.g.
http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng...
> This study examined the effects of line length on reading performance. Reading rates were found to be fastest at 95 cpl. Readers reported either liking or disliking the extreme line lengths (35 cpl, 95 cpl). Those that liked the 35 cpl indicated that the short line length facilitated "faster" reading and was easier because it required less eye movement. Those that liked the 95 cpl stated that they liked having more information on a page at one time. Although some participants reported that they felt like they were reading faster at 35 cpl, this condition actually resulted in the slowest reading speed.
Atwood talks about this study here: http://blog.codinghorror.com/text-columns-how-long-is-too-lo...
I'm not sure, however, if you would consider 95 cpl to be long. 10 pt. font across a letter-sized page with reasonable margins...that seems quite painful and one reason I dislike reading dissertations. However, if you are reading straight and not skimming, it might be better as flow is broken less frequently (I rarely read papers straight, they have to be very good for that).
But wait, there's more! Narrow multi-column formatting only works well with decent typesetting systems...aka not Microsoft Word! Fortunately, a MSR Turing award winner using the work of another non-MSR Turing Award winner have solved that problem for us (i.e. TeX and LaTeX). There are many fields where MS Word is the standard, and therefore...it would be nuts to try anything complicated.