第一次结对作业-原型设计

222100133蓝有润 2024-03-10 20:12:02

这个作业属于哪个课程	软件工程实践
这个作业要求在哪里	作业要求
结对学号	222100132（以下简称32） 222100133（以下简称33）
这个作业的目标	1.阅读《构建之法》第3章和第8章的内容 2.结对合作，阅读作业中客户描述的现实困扰，以共同发布一份博客随笔的形式，设计一套方案，向客户推销。描述大致方案，正确理解客户的需求、提供给客户可行的优化的使用建议，给出原型模型，并提供大概的解决方案预期规划。
其他参考文献	《构建之法》

一、原型链接
二、软件分析
1、需求分析
2、NABCD模型
3、四象限
三、原型设计过程
1、学习原型的过程
2、网站总体设计
3、首页设计
4、示例结果页面
5、其他界面
四、遇到的困难及解决方法
1、墨刀的软件特性无法复刻官网的下拉内容
2、如何简化数据的导入
3、墨刀内置功能存在交互缺陷
五、PSP表格与效能分析
1、PSP表格
2、效能分析
六、结对过程
1、分工与贡献度
2、结对截图
3、评价

一、原型链接

原型链接

二、软件分析

1、需求分析

用户需要简洁的界面能够实现对比赛记录和选手信息的查询，这是基础功能
用户呈现出的需求可以被交叉分类成几个标签：
第一类用户对世界游泳比赛本身了解不多，只是出于好奇或者偶然点进网页，那么我们希望能够激发用户对游泳比赛的兴趣，将这类用户发展为长期用户。所以网站首页采用美观的界面和吸引人的介绍，给用户一个完美的第一印象。
第二类用户对世界游泳比赛比较关注，同时有自己喜欢的选手或比赛，为了满足这类人的需要，我们设计了选手关注功能和比赛推送功能。选手关注功能是指在选手信息页面增加一个关注按钮，点击关注按钮后所有该选手出现的地方都将高亮显示，同时，一旦关注的选手出了成绩后，将会发送到用户的电子邮件里。如果该比赛结果未出，用户可以预约比赛，当比赛开始前一天，用电子邮件提醒用户。
第三类用户想要在网站上支持自己心仪的选手，或是能够在专业的赛事结果网站上进行讨论，对于这类用户，我们开设了留言板，用户可以在留言板上写下对选手的祝福和祝贺，同时也可以对比赛发表自己的看法。社群讨论充分拓展了用户的社交需求，能增强用户对软件的黏性。

2、NABCD模型

N（Need，需求）
将用户分为新用户与体育赛事关注者两类
共同的需求是：简洁的界面，能够实现选手查询和赛事查询等基础功能
新用户的需求：了解世界游泳锦标赛的历史，知道世界游泳锦标赛有哪些项目和其中的精彩瞬间，激发对游泳比赛的兴趣。
体育赛事关注者的需求：时刻关注自己喜欢的体育选手和比赛项目，有一个能够讨论比赛的环境。
A（Approach，做法）
对于新用户的需求，做法是在首页增加不同项目精彩图片的轮播，还有不同年份比赛的时间轴，通过时间轴可以了解到比赛举办的地点和其他基本情况。
对于体育关注者的需求，做法是提供关注功能，对已关注的选手有高亮显示。在每场比赛下方提供评论区，可以发表对比赛的评论。
B（Benefit，好处）
我们的选手关注和留言板功能是我们能带给用户的好处，有了关注功能，人们可以了解到自己喜欢选手的最新动态，而无需在大量的赛事中大海捞针，而留言板能满足人们的互动需求，也增强用户的依赖程度。
C（Competitors，竞争）
考虑到体育赛事的数据记录网站功能比较有限，而大部分用户也不会过于在意UI等外围功能（当然，设计好交互性强的UI是至关重要的，这涉及用户对软件的第一印象），因此，竞争的方向可能会是数据的详细程度、正确性和网站的易读性，关于数据的详细程度，可能会在后续web端实现时，加入每一次跳水的分数；关于正确性，可以考虑用户上传报错，报错的用户可以获取一定的奖励；关于数据的易读性，需要仔细考虑数据的排版，字体的设计。
在思考竞争对手的过程中，我们翻找了其他突出的体育赛事网站——例如sofascore，真正使网站脱颖而出的是附加功能——赔率预测和直播渠道。其他的竞争对手很可能发现了软件的拓展方向，所以我们在原型中考虑加入具有社交团体性的功能——留言板，在后续的设计中，会考虑将简单的留言板发展成评论区，实现回复的功能。
在了解了竞争方向和竞争对手之后，我们总结出了我们网站的优势和劣势。
我方优势
1.照顾用户的体验，有更精美的界面设计；
2.满足用户社交需求，帮助用户追踪选手的比赛动态。
我方劣势
1.没有集成newsletter功能，对体育新闻有需求的用户可能不会满意，同时缺少和新闻报社合作的机会；
2.网站专注于跳水，面向的用户群体是有上限的，相比于其他软件，该上限不高。
D（Delivery，推广）
考虑到成本，预计请自媒体博主进行推广，这是现在成本比较低的一种方法，至少对于我个人来说，现在生活中接触最多的广告基本都来源于自媒体博主的视频宣传。

3、四象限

杀手功能：关注功能和评论区就是我们的杀手功能，这是其他软件所缺少的功能，是我们产品的关键
外围功能：在墨刀上我们尽可能使用更美观的字体和优化界面，满足用户审美需求
必要需求：对游泳锦标赛信息的全覆盖是必要需求，运动员信息和所有的比赛信息及检索功能
辅助需求：照顾新用户的体验，提供精彩图片轮播和时间轴帮助了解比赛基本内容

三、原型设计过程

1、学习原型的过程

由于墨刀的免费版本不支持团队协作，唯一能够进行组件导入导出的只有素材广场，鉴于素材上传审核的延迟性，33本人单独学习并使用墨刀，32在33进行设计时，提供一定的建议。
同时，考虑到时间有限，加上原型设计和ppt制作具备一定的共性，所以我们最终决定直接上手，边制作边学习。
学习了动态组件的概念，同时在制作中自行摸索出了一定的设计方法：
1.状态——事件分离的设计模式。如果状态内部有一直存在的事件，那么可以将这些事件替换成一个透明矩形的组件。
2.项目越是复杂，就要尽可能使用母版，将常用的组件放入素材库。
3.在复杂的界面中，组件的组合和层次对于界面完整度和有序度的实现至关重要，如果组件组合不明确，组件块的重定位会浪费许多时间；如果组件次序颠倒，会出现许多意想不到的bug，例如文本框中的框会遮挡住文本，这一点在浮动组件的排布上十分明显，如果内容组件在导航栏上层，那么在下滑时，导航栏会被内容遮挡。

2、网站总体设计

以下是网站的总体结构：

这里给出网页的总体结构：网站在上下方浮动着导航栏和页脚，能保证跳转到——赛事和运动员的数据，同时也能跳转到官网其他分网站的内容。

以蓝色为主要配色，查阅了常见的网页配色，最终采用以下三色来进行配色（考虑到原网站配色的极简思想，后续将灰色换成了背景色白色，以减少颜色的使用）：

同时，字体和官网的字体类似，避开草书等可读性差的字体，同时要保证字体宽高比越大越好（越扁的字体越和1920:1080的网站宽高比对应），因此采用大幅度采用墨刀内置的courier new和montserrat。

3、首页设计

首页主要考虑网站介绍+新闻。为了提高空间的利用率，采用了轮播图来展示新闻。同时用了三栏来宣传：第一栏是简短的宣传语，第二栏采用交互的方式让用户了解基础的项目，第三栏聚焦于本网站的主题——跳水。

4、示例结果页面

官网采用上方tabsview的设计，符合上下浏览的自然顺序，因此，本网站仿照官网设计了五个tab，对应各自的界面。

五个tab分别对应以下状态：

1.总览+评论区

2.查看比赛安排，作为事件的示例，点击第一项能跳转到对应比赛的阶段（woman 1m springboard-preliminaries）。

3.查看奖牌榜。

4.查看结果，侧边栏为比赛类型，结果上方为比赛阶段。

5.查看参赛的运动员，作为演示示例，点击第一个运动员能到达对应的个人界面。

5、其他界面

所有赛事的页面，作为示例，保存了两项跳水赛事，上方提供搜索功能（国家、年份、月份），点击赛事进入对应的界面。

对于尚未举办的赛事页面，提供预约功能。

下图是所有参赛运动员的界面，因为本原型中只有第一场赛事，因此这里的内容和rockstock的athelte-tab中是一样的，作为演示，点击第一项能进入对应的运动员界面。

选手个人界面，内置关注选手的功能。

四、遇到的困难及解决方法

1、墨刀的软件特性无法复刻官网的下拉内容

由于墨刀在组件状态变化之后，不像axure一样会对组件进行重新排布，因此在展开之后会其他比赛结果发生重叠（如下图所示）。此外，墨刀无法在事件中设置组件移动，因此，无法在墨刀上“动态”实现官网的下拉菜单显示结果的功能，这里的动态指的是在点击比赛按钮时，结果和其他的比赛会随之往下移动。

若要在动态效果上让步，只需要设计对应的下拉——展开界面，需要设计11个页面（1个：无结果被展开，10个：10个结果各被展开），本质上是每一个页面展示一个结果，与一个比赛结果对应一个页面没有区别，因此，放弃原有的下拉展示结果模式，采用一个页面展示。修改成以下方案：
左边为选择比赛的侧边栏，右方为比赛的结果。
同时，侧边栏的最大优势是，用户在查看不同结果时，不再需要大量的上下滑动，例如，当比赛结果占据的高较大时，用户需要不断上滑来查看上方的结果，而在侧边栏设计中，用户只需要点击侧边栏中的对应项目即可。

2、如何简化数据的导入

在分析工作量的过程中，我们着重分析了人工导入比赛数据的工作量：
首先，通过第二次作业的程序，若要导入较为完整的数据时，可能会不可避免地手动在官网下载大量的图片数据，赋值大量的文字，因此，为了提高输入数据的效率和准确性，33设计了以下导入方案：
1.将国家的内容也加进素材库。

2.将所有运动员的表格内容封装成了组件，然后按照国家进行了分类（如下图，左图为分类后的包含运动员的组件库，右图为内部的直接用的组件）。

在无代码的方法中，对于每一个运动员，在网页中下载对应的图片，加入墨刀，设计对应的姓名文本框，然后通过生日计算出比赛时（18th~24th Jan）的年龄。由于这种方法造成大量的重复劳动，33复用了之前已经写过的java爬虫程序：稍稍修改之后，爬出了所有运动员的图片，然后命名为对应的名称（运动员和图片名的对应关系在网页GET到的示例JSON文件中）。最后得到以下文件夹：
>

此外，在第二次左右的athletes数据中，运动员只有date of birth的数据，而不是年龄。因此，33再次复用其已有的java项目，计算出所有运动员在比赛时的年龄，结果如下图：

最后，在下图的工作环境下，实现一个运动员的内容只需要20秒左右，相比于原来的设计，大大提高了效率。

最后摸索出了流水线的设计过程：对于运动员的模板，复制最右的名称——粘贴到文本框，修改年龄，点击替换图片，粘贴名称到文件搜索栏并选择，在命名组件时粘贴名称并上传。一次复制，三次粘贴，大大提升了检索图片、命名组件的效率。

解决这个问题的收获是：函数的设计的一个目的就是减少重复的代码，在上机手动操作时，这种思想也十分重要，我们要尽可能想到所有可能的方法来减少大量重复的劳动，同时，一些工作也能通过超出常规的方式自动化实现，除了用爬虫软件自动爬取数据并整理之外，鼠标可以用鼠标精灵等软件（甚至可以用python自己设计鼠标行为），PS也支持用javascript和python进行流水作业。因此，我们要做的是，不断踏出舒适圈，去思考生产力提高的可能。

3、墨刀内置功能存在交互缺陷

原计划导航栏在墨刀的模板上进行修改，发现在墨刀模板的导航栏占据了页面上方大于他本身体积的空间，只要在导航栏占据空间范围内的组件都会因遮挡失去交互功能，无法点击触发事件。所以手动重写了导航栏中的每一个下拉菜单，保证下拉菜单不会遮挡其他组件，就在准备将修改后的下拉菜单和导航栏结合为一个整体时，发现又产生了遮挡，详情可看图：

RESULTS一栏被上方的SECTIONS的区域（上图的蓝框，也就是展开的部分）挡住了，点击无反应。

在这里插入图片描述

尝试了将大的母版分离成几个子母版（解决了一部分问题，但上面的示例问题还是未能解决），墨刀软件本身是新手友好的原型软件，和axure相比，类似于美图秀秀和Photoshop的区别，前者在高级的设计功能上少于后者。因此墨刀在交互上的设计缺陷是不可避免的（就是不知道axure是否也会出现该问题），目前的解法只能尽可能将具有交互事件的组件和会展开的部分尽量分开。当发现这个问题时，木已成舟，所以不再彻底修改导航栏或者是界面排布，因为在web实现时这种问题也不会发生。

五、PSP表格与效能分析

1、PSP表格

PSP	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	20	25
• Estimate	• 估计这个任务需要多少时间	20	25
Development	开发	620	1240
• Analysis	• 需求理解	30	40
• Learning	• 学习原型设计工具	10	30
• Discussion	• 结对讨论	40	50
• Design	• 界面原型设计	480	1060
• Test and Improvement	• 测试与改进	60	60
Reporting	报告	90	110
Size Measurement	•计算工作量	50	65
• Postmortem & Process Improvement Plan	•事后总结, 并提出过程改进计划	50	50
合计		660	1460

2、效能分析

经过后期分析，找出了以下耗时较多的环节——原型设计
界面原型设计效率较低的原因是计划中的设计方案在墨刀中无法实现（描述困难一栏只是冰山一角）。包括但不限于：由于组件不能在演示中移动位置导致下拉框无法复刻，不存在持续运行的计时器导致轮播图无法自动滚动，尚未显示的组件遮挡了交互的空间，在目录里选择组件合并时会使合并后的组件占据无用的空间，表格、按钮、图形内部的文字无法自定义字体导致基本上所有文本和组件都是分开的（为了美观）。
在平台上作业一定会收到平台的制约，就像eclipse的maven一样，使用时可能会因为网速的制约，大大限制了依赖的下载速度（这时候最好用idea）。一定要根据自身的需求选择好工作的软件，如果在原型设计时就要体现比较复杂的结构，或者使用是更高级的事件，那么axure会是更好的选择，如果只是想要简单地设计草稿，或是想要直接引用庞大的中文素材库，墨刀会更加友好。如果这次作业可以重来的话，我们组一定会选择axure，而不是在简单地看到历年的一部分优秀作业选择墨刀的情况下，忽视自身的需求，盲目使用墨刀。

六、结对过程

1、分工与贡献度

因为我们是舍友，所以所有的分工都是在口头交流中确定的，没有聊天截图等记录。

	222100132	222100133
分工	1.阅读《构建之法》，撰写博客，主要负责PSP表格的时间估计、软件分析的部分	1. 原型设计 2.阅读《构建之法》，撰写博客，主要负责原型设计、效能分析、遇到的困难及解决方法的部分
贡献度	30%	70%