论文：Process and pitfalls in writing information visualization research papers
出处：Information visualization: human-centered issues and perspectives
作者：Tamara Munzner
这篇论文依然是我女神的论文，当时读到这篇论文的时候真有相见恨晚的感觉。文章罗列了信息可视化论文几大类型中常见错误，虽然不是什么新内容，但是很少有人这么系统地把这些错误按项目进展的顺序列出来。在科研尤其是写作过程中作为checklist一般的存在，让我们避免掉入很多陷阱。受限于篇幅，这篇博文只关注最最重要的论文类型的陷阱，其他内容还是强烈推荐同学们自己去好好读原文。
信息可视化/可视分析的论文有5大类：technique, design study, system, evaluation, model，以及类型的混合。当你开始一个信息可视化项目的时候，就需要知道你最终要写什么类型的论文，因为每个类型对应的工作和重点都不同，对工作的评 估方法也不同。虽然大家心里可能很确定自己的项目是针对某一个类型（比如technique），但是项目进行过程中可能会不自觉地偏到其它类型去（比如 system或design）。
论文类型分类
首先区别一下这5种论文类型：
technique 算法/方法类，例如边绑定算法。technique类工作的评估方式分量化评估和非量化评估两种，量化就是从时间、内存、墨水比 (ink ratio)、空间占有率等可量化角度评估算法效率；而非量化则是从可视效果上评估，与原方法比较用户能够从可视化结果中得到什么新的信息，或是可视化结 果的细节是否有提高等等。
design study 设计类，设计一个新布局、新交互或是针对某一类数据设计一个整体的可视化方案，例如themeriver。设计类工作一般首先需要明确是为解决什么问题而 设计。设计类工作的评估方式就是case study和user study：用case验证设计的可用性（应用于数据是否展现需要展现的信息），user study评估用户对新设计或新交互的接受程度、上手难易程度和各方面的评价。
system 系统类，但是把一些方法和一些设计实现成一个系统并不是system类的工作。system类的工作更多是对系统架构或是代码库(library)的思 考，对于大数据、异构数据、流数据等有挑战的数据类型或是对于大屏、协同等复杂环境的系统架构设计上的思考。需要讨论系统在性能、可扩展性、灵活性、安全 性等系统架构上的问题，以及对系统的优化和平衡。
evaluation 评估类，专门对比/评价一个或多个方法的优劣，并不涉及新算法或是新设计。一般用user study的形式从量化、非量化两个角度去评估方法的好坏，对结果进行严谨的统计分析。也可以把方法在真实生产环境中实施收集效果(field study)，但这种一般时间较长。量化评估方法包括但不限于答题正确率、答题时间、眼球跟踪、鼠标操作跟踪等手段，非量化就是问卷、录音、访谈等手段。
model 模型类，就是可视化中的方法论类，包括taxonomy（分类法）, formalism（model类、定义术语等）, commentary（评论类）。这类论文往往需要对可视化有深入的理解和体会，一般都是大牛写的，我就省略了。
类型陷阱
确定5种论文类型之后首先就要提出类型陷阱，也是这篇博文的重点。
Design in Technique’s Clothing – “Don’t validate a new design by providing only performance measurements.” 这是分不清设计类和方法类。并不是说设计类就不能用量化的性能去评价，而是不能用写technique论文（国人最擅长）的那套去写设计论文，不能只用一 大堆性能指标评价一个设计，而不管用户对设计的体验。因此设计类工作要明确你要解决什么问题，针对问题设计user study收集并分析用户体验，性能指标可以作为辅助评价手段。
Application Bingo versus Design Study – “Don’t apply some random technique to a new problem without thoroughly thinking about what the problem is, whether the technique is suitable, and to what extent it solves the problem.” 这是用锤子找钉子，找到就开始敲的情况。有好方法确实可以到处试试看看方法的普适性，但是什么都不管乱套用就会带来很多问题，到后期当你发现锤子和钉子不 十分匹配就会各种不舒服。这种情况在论文中的表现就是在表述方法的时候非常详尽，而在案例分析或是用户分析的时候磕磕绊绊不能自圆其说。避免这种情况的方 法有两个，首先还是那句老话，明确要解决什么问题，针对问题量身打造方法；其次，在实现之前先对比你所选的方法为什么比已有的方法好，在道理上说服自己才 能说服读论文的人。
All That Coding Means I Deserve A System Paper – 不说这是一篇系统类论文对不起我写的那些代码（泪~）. 明白上面所说的什么是系统类论文就知道这是个苦肉计陷阱，不多说。
Neither Fish Nor Fowl – 鱼与熊掌想要兼得. 很多论文的contribution部分都会写我们提出了一个什么方法，设计了什么可视化表达或交互，实现了什么样的系统，一下子写了3个类型的贡献。而 为了评估工作是不是要把三种评估方法和讨论都写出来洋洋洒洒一篇博士论文呢？Tamara认为可以有一个主贡献一个副贡献，比如设计类的跟一个 evaluation类贡献，以主贡献为论文类型，兼顾副贡献，这样不会摊子太大收不回来。
此外文章还提出了可视编码上的陷阱，论文结构、组织、行文的陷阱，评估方法的陷阱，写作的陷阱，甚至投稿的陷阱等等。感兴趣的同学自己去看吧，一篇博文字太多也是挺烦的……
这是可视分析的补充分割线
文章出版于2008年，当时可视分析还不是一个非常成熟，但是时至现在已经是一个独立的子方向了。包括本人在内的很多人可能都在纠结于可视分析的论文应该怎么写，评估方法是什么。因为很多时候可视分析专注于提出一个完整的解决方案，针对的是一个特定应用，很难界定这是属于算法、设计还是系统，可能都有一些。就目前而言可视分析的一般思路是提出应用的典型task（往往领域相关），为满足task制定或算法或设计或都有的一套方法，并整合到一个比较完整的系统中去，评估方法也是以领域专家的反馈为宜。
✉️ zjuvis@cad.zju.edu.cn