Tell Others: Posters General Features Formatting Print Peer Review Video

Tell Others: Posters

This page is for outlining considerations for the "Tell Others" milestone. We'll get it started just by listing bullet points, then flesh in the text as we go along. We'll start with the more immediate stuff, and the crazy ideas for the future come later.

General

• One stop shopping means we host posters on our site, and make it as easy as possible to create a poster with the proper components and layout.

• Robustness means we also allow for posters (or maybe papers, video presentations, wiki articles) hosted elsewhere. Teachers could then use other tools they are comfortable with (eg. wikispaces) but we still get posters in the system.

• Hence consider a separation between the Catalog of posters and the Repository of same.

• But make it so that users don't really notice the distinction. To them it's all one thing (just with links to external posters as well as internally hosted posters).

• The e-Print archive at Cornell (http://arXiv.org -- formerly xxx at Los Alamos) is both a catalog and repository for physics papers (the Tell Others step for real research). SPIRES at SLAC (http://www.slac.stanford.edu/spires/) is a catalog, but not a repository (they don't keep papers there, they just index them).

Features

• Images: plots and other images need to appear in the poster, not just as links, but as images. They could be of reduced size, so as to fit on the page, but when you click on them (or a specific link) then a full sized version pops up (in a separate window?) Ideally, all plots should have metadata that allows the viewer to recreate the analysis that produced the plot. This is one of the important features of using workflows in SWIFT.

• Lockdown: at some point you consider the poster "published" and it is no longer possible to edit it. (Q: how should this be controlled? Who does the locking? Can someone unlock? Who? How?)

Formatting

• Posters always have the same elements (title, authors, abstract, background, methods and analysis, results, conclusion), so we can collect this information in an on-line form, save each section separately, and then assemble them for final display.

• Poster style is a matter of taste. Include custom CSS per e-Lab so that looks can be adjusted, even though they are similar.

• Allow for multiple Templates (like skins?) so that there can be a choice of layouts and formats. (Kinda like the "make your own greeting card" sites?) There need only be a few options.

• A wiki would be another way to create posters (See the Baseball e-Lab poster). We could set up a separate "Poster:" namespace in the public wiki for this. Or a separate posters wiki. But this would only be for "experienced" participants who had already used the form method successfully.

• An alternative to entering poster sections via a web form would be to edit wiki pages, then assemble them in a poster via "mash up", similar to how the LIGO resources page content is (or will be) stored in a wiki page, but is served from a JSP page.

• A lesson Eric learned from WLAP (see below) is that the process of storing and presenting content should actually be a 3 step process, not just two steps. One is inclined to just collect material in a database, and then present it on demand. Don't neglect the central step of "archiving" what was collected in a format that is open and easily converted into any of a variety of final presentation formats. For example, we might allow image upload in any of several formats, but we convert them to JPEG or PNG for storage, and then we don't have to worry if the original format is no longer supported down the line. (This is more important for video -- see below). It's important to make a distinction between a preparation or archive format (eg. MS .doc file) and a presentation format (eg. PDF file).

Print

• CSS allows for different style for printed form of the document. Optimize this so that printed posters can be hung up in the classroom.

• Printed posters are useful for in-class display, and can be hung in the hallways to show previous efforts and achievements. Taking something home can be good. (So can making it easy for parents to view student work on-line - if we can do so.)

• It might be possible to automate the generation of posters in PDF or PowerPoint format, not just as web pages.

• Posters are easier for a class to develop in parallel, and easier to read quickly to get a result, but advanced results might also produce papers in addition to (or instead of) posters. But we'll need feedback from teachers on what is age appropriate. The Catalog should allow for papers or other formats, but not require it, and the default is to assume a poster unless otherwise instructed.

Peer Review

• arXiv is not peer-reviewed. Phys Rev and Phys Rev Letters are peer-reviewed. SPIRES is a catalog (but not an archive) of peer reviewed papers. For ELabs the equivalent of peer review might be to have an on-line virtual science fair: students at each school compete for top poster of the semester/year. These get marked as such in the catalogue. The top posters from all the schools could then compete nationally (or first in each state, or each city, once there are enough) for further honors. But any poster that is rated highly in the school can be considered "peer reviewed" at some level.

• An alternative to a competition could be to have an Editorial Board at the school, city, or state level, and they decide that a poster meets some minimum criterion for "publication'.

• Even though posters are likely the appropriate medium for the secondary ed level, it might be nice to find a way to get across to students that papers are the primary medium for "Tell Others" in real research. Except that posters are used at conferences. It would be useful to have examples of posters from real research.

Video

• Students might also make in-class presentations and record them as "video posters", with the result uploaded to YouTube. While the Repository would be YouTube, we would still want metadata so that it could go in our Catalog. Video is "cool" and "cutting edge" today, so using it for a class project could help feed interest. (Q: what hurdles would there be to putting student content on YouTube?)

• The Catalog should therefore allow for "video posters" hosted somewhere else (not necessarily YouTube)

• There is software used by ATLAS and Fermilab to combine video and PowerPoint slides (or PDF) into a single presentation. Examples:
  • See the Web Lecture Archive Project (WLAP) hosted by the University of Michigan. (Eric worked on WLAP at Michigan before moving to Vassar and knows something about how the software for this works. See the paper from CERN: CERN-OPEN-2001-066 and Eric's Vassar Tech Forum Poster.)

  • See the video links in the Fermilab Colloquium Calendar. This could be a valuable resource for students, even though the technical level may be a little high for them. (Colloquia are more accessible than technical seminars, and it doesn't hurt to see stuff you don't understand. Titles in green are less technical. A 1-hour talk may be too long for some high-school students. It might be that these are useful more for teachers to get background, so they feel they know something before beginning the e-Lab.)

  • These kind of presentations would likely require a machine set up in our cluster to host the Repository. We would also need a machine to run the software to assemble the presentations from the video stream, slides, and slide timing info. These could likely be the same machine, at least in the beginning.

• Examples relevant to students are reports by students participating in UM-CERN REU. They recorded presentations they made at the end of their stay at CERN. See the WLAP collection UM-CERN Research Experience for Undergraduates. Although WLAP is an ATLAS project, students also worked on CMS. See for example Muon Identification at CMS by Andrew Wagner. High school level "video posters" would of course be shorter and less technical.

-- Main.EricMyers - 25-28 Jul 2008