Final presentations timing Today Wrapup: • final presentations timing • finalize final presentation slot: Tue Dec 10 3-7pm –Original plan: 1-5 Tue (26) • presentations Research Papers and Process • ML final: 12-2?? 12:30-3:30?? • final papers and final presentations –Best availability: 3-7 Tue (28) –course paper vs research paper expectations –Worse: Mon (21), Wed (24), Thu (20) • writing infovis papers: pitfalls to avoid Final Papers & Presentations Tamara Munzner –Process and Pitfalls in Writing Information Visualization Research Papers. • reminder Department of Computer Science Tamara Munzner. In: Information Visualization: Human-Centered Issues and Perspectives. –we do have class next time (Tue Dec 3), since started a week late Andreas Kerren, John T. Stasko, Jean-Daniel Fekete, Chris North, eds. University of British Columbia Springer LNCS Volume 4950, p 134-153, 2008. –peer reviews 2 CPSC 547, Information Visualization • other research pitfalls and process • do remember to submit your peer review slides 26 November 2019 • for this one, also upload notes as comments –review reading, review writing, conference talks • reproducible and replicable research http://www.cs.ubc.ca/~tmm/courses/547-19 2 3 4 Final reports Course requirements vs research paper standards Report structure: General Sample outlines: Design study • PDF, use InfoVis templates http://junctionpublishing.org/vgtc/Tasks/camera_tvcg.html • research novelty not required • low level: necessary but not sufficient • www.cs.ubc.ca/~tmm/courses/547-17F/projectdesc.html#examp –your choice to use Latex/Word/whatever • mid-level discussion of implementation is required –correct grammar/spelling • abstract • no length cap: illustrate freely with screenshots! –sentence flow –part of my judgement is about how much work you did –concise summary of your project • medium level: order of explanations –design study / technique: aim for at least 6-8 pages –high level: what toolkits etc did you use –do not include citations –analysis / survey: aim for at least 15-20 pages –medium level: what pre-existing features did you use/adapt –build up ideas • introduction • ok to re-use text from proposal, interim writeup –low level not required: manual of how to use, data structure details • high through low level: why/what before how –give big picture, establish scope, some background material might be appropriate • design justification is required • encourage looking at my writing correctness and style guidelines –paper level • related work –(unless analysis/survey project) • motivation: why should I care –http://www.cs.ubc.ca/~tmm/writing.html –include both work aimed at similar problems and similar solutions • overview: what did you do –different in flavour between design study projects and technique projects • strongly encourage looking at previous examples –no requirement for research novelty, but still frame how your work relates to it • details: how did you do it –technique explanation alone is not enough –cover both academic and relevant non-academic work –www.cs.ubc.ca/~tmm/courses/547-19/projectdesc.html#examp –section level • publication-level validation not required –you might reorder to have this section later –Example Past Projects • overview then details –user studies, extensive computational benchmarks, utility to target audience –browse 2015, 2014,… reports –sometimes subsection or paragraph level 5 6 7 8 Sample outlines: Design study II Sample outlines: Design study III Sample outlines: Design study IV Sample outlines: Technique (diffs) • data and task abstractions • implementation • conclusions • Abstract, Introduction (same as above) • Related Work –analyze your domain problem according to book framework (what/why) –medium-level implementation description –summarize what you’ve done – big focus on similar solutions, some discussion of similar problems (same task/data combo) –include both domain-language descriptions and abstract versions • specifics of what you wrote vs what existing libraries/toolkits/components do –different than abstract since reader has seen all the details • Data and Task Abstractions –breakdown of who did what work –could split into data vs task, then domain vs abstract - or vice versa! • bibliography – much shorter than the corresponding one for design studies, framing context not core contrib • results –typically data first then task, so that can refer to data abstr within task abstr –make sure to use real references for work that’s been published academically • Solution • solution –include scenarios of use illustrated with multiple screenshots of your software • not just URL – describing proposed idiom exactly, not justifying its use for particular domain problem • walk reader through how your interface succeeds (or falls short) of solving intended problem • check arxiv papers, many have forward link to final publication venue - use that too! –describe your solution idiom (visual encoding and interaction) – as above, analyze in terms of design choices, justify why appropriate vs alternatives • report on evaluation you did (eg deployment to target users, computational benchmarks) –be consistent! most online sources require cleanup including IEEE/ACM DLs • Implementation (same as above) –analyze it according to book framework (how) • screenshots should be png (lossless compression) not jpg (lossy compression)! • do pay attention to my instructions for checking reference consistency • Results –justify your design choices with respect to alternatives • discussion and future work – http://www.cs.ubc.ca/~tmm/writing.html#refs – less emphasis on scenarios with particular target users –if significant algorithm work, discuss algorithm and data structures – more emphasis on characterizing the breadth of possible uses –reflect on your approach: strengths, weaknesses, limitations – still definitely include screenshots of the system in action –lessons learned: what do you know now that you didn’t when you started? • Discussion / Future Work, Conclusions, Bibliography (same as above) –future work: what would you do if you had more time? 9 10 11 12 Sample outlines: Survey (diffs) Sample outlines: Analysis (diffs) Sample outlines: Other types Report marking • Abstract (same as above) • Abstract, Intro (same as above) • see page for implementation project types • required: at least material I’ve listed • Domain Background • Introduction –implementation –you may include more material, you may choose alternate orderings – relevant vocabulary/ideas, your own background/connection www.cs.ubc.ca/~tmm/courses/547-19/projectdesc.html#outlines – discuss the scope of what you're covering, why it’s interesting/reasonable partition compared • probable marking scheme (may change!) to visualization as a whole • Data/Task Abstraction, Related Work (same as above) • interactive explanations • design study & technique: 12.5% each for • Related Work • Methods and Tools –meet with me in advance to discuss –intro, related work, abstractions, solution, implementation, results, discussion, style – only previous surveys – how has it previously/normally been analyzed –style: 10% main, 2.5% bibliography • focus on how your work is similar to or different from them, especially wrt coverage – explain what idioms you chose and justify those choices; same for tools • survey: intro (10%), relwork (10%), main (60%), style (20%) • Main • Analysis • analysis: intro/domain (8%), abstr (8%), relwork (8%), methods/tools (8%), analysis – break up into sections based on your own synthesis of themes of work covered – present results of your visual data analysis, including screenshots of tools in action (52%), discussion (8%), style (8%) – you might want a Background section at the start if domain-focused survey – specifics of what you learned in terms of the domain problem • reminder: project content is 60% of entire project mark • where there’s important vocabulary/ideas to establish before diving into main discussion – your reflection on how visualization choices helped you understand it – analyze visualizations proposed in these papers in terms of what/why/how framework – strengths/weaknesses of your approach (idioms and tools) –report is 25%, presentation is 15% • include images from papers • can be interleaved or in separate section at end • Discussion / Future Work, Conclusions, Bibliography (same as above) • Discussion / Future Work, Conclusions, Bibliography (same as above) 13 14 15 16
Recommend
More recommend
