为应用做

　　过去两年，移动互联网一直是我关注的领域之一，为什么？因为我的那些英国教授人手一只iPhone，弄得我每天挂眼科。时常白日梦，自己左手iPhone，右手Nexus，胸前再挂一个iPad（或许腰间再绑一串iPod，屁股下再垫上Mac，大腿再护上Kindle）…黄粱一梦，时至今日，还是Nokia陪伴在身边。
　　前面提到我们以iPhone为目标所做的课程设计，也提到其中使用paper prototype对应用进行快速原型。没有提到的是这个过程中产生的问题：
　　1，用诸如VB这样的程序将原型展示在PC屏幕上，让用户以鼠标方式交互显然已经大大偏离了iPhone所提供的触摸交互方式；
　　2，用paper prototype遇到的问题则是使用场景的不真实：你可能拿着移动设备坐在公交车上，走在大街上，也可能蹲在厕所里，你可能单手拿着，双手并用，横着看，竖着瞧。
　　总之，习惯用paper prototype来应对PC等等这种＂不动＂设备的人来说，这些听上去简直是像场灾难。
　　面对这些，UX Booth在5号（3天前，好吧，我落伍了）有一篇文章谈到这个问题，designing with prototype，，谈到Indiana大学的信息学院是如何应对这个难题的：
　　制作paper prototype；
　　将每一屏数字化，无论是通过数码相机还是扫描；
　　将图片导入（PC，Mac），根据移动设备调整尺度；
　　将调整好的图片保存为移动设备支持的格式；
　　根据设置的Scenario调整好图片顺序；
　　将图片上传到移动设备；
　　指导用户如何导航，例如根据场景一张张Swipe（扫过？）这些图片。
　　这个方法被称作：Paper in Screen。我的问题来了，这种情况下，场景必须是固定的，用户必须一直随着安排好的唯一交互顺序继续下去，否则这些图片顺序就毫无用处了。而测试人员也难以很快完成制作新视图，拍照、上传、调整顺序一系列任务，这样用户的思路也中断了，似乎又失去了paper prototype的一大优势。
　　UX Booth的作者进行了调整，将视图制作成页面，加入链接，这样就可以加入更多的交互可能，然而我的问题还在，制作成本提升，用户觉得不合理，制作者依然无法快速现场修改。由于链接的引入，所有交互都只以点击（click）的形式完成。