search

mindpin / TouchIdea

0 stars 1 forks source link

场景6：产品意见收集 需求迭代 #18

Open ben7th opened 9 years ago

ben7th commented 9 years ago

来源： https://github.com/mindpin/TouchIdea/issues/13

根据场景 6 绘制了泳道图： https://www.processon.com/view/link/55093ce6e4b01eb448378817

根据泳道图，需要进行下列工作：

  1. 吴笛根据泳道图，比较目前的 pin-idea 版本和场景 6 需求的差异。指出功能方面匹配和不匹配的地方；提交文字描述
  2. 夏实根据泳道图，以设计手机应用为目标，根据泳道图反应的需求和操作过程，绘制界面草图。提交设计稿。过程中可参考之前进行的投票类应用调研。

对于投票类应用调研的讨论在 3月24 号午饭后进行。

ben7th commented 9 years ago

3月24日：

吴笛计划提交差异比较说明； 差异说明提交后，使用 http://designboard.cc/ 这个软件 绘制当前 pin-idea 版本的页面流，便于在此基础上迭代

午饭后会针对投票类应用调研进行讨论

夏实正在继续编写场景 6 需求实现的草图。

pimgeek commented 9 years ago

下面是新需求和现有原型之间的 feature 差异比较说明。

议题创建和发布

有
  标题字段和日期字段
没有
  正文字段
  商品元信息
    例如：外观，规格，定价，地理位置等
    基于 3-24 日关于投票产品调研的讨论
    https://github.com/mindpin/TouchIdea/issues/16#issuecomment-85395760 
    中宋亮关于数据库内置领域信息的建议，商品元信息可以在商品中内置。

贡献初始意见

注：原图此处有误。初始意见对于信息收集场景而言，应该是相当于投票的预置选项，由主题的发起人创建，而不是由其他参与者创建。换言之，其他参与者继续补充的意见，不属于初始意见。所以原图上，贡献初始意见的动作，应该归到话题发起者的泳道下。

后续所有其他参与者补充的意见都不算初始意见，而算补充意见。所以原图上有一些方块的位置和描述错误（主要是第二大行和第三大行错误。）

有
  贡献初始意见的输入手段（在目前版本中，初始意见是通过预设投票选项的形式体现的）
没有
  图片、超链接等输入手段
    例如：使用软件过程中的截图，买家秀照片，菜品实物图等

添加补充意见 x N

与初始意见形式相同

针对某意见点赞 x N

有
  表达赞同。
    但是，目前版本中，“点赞”这一动作是通过“一次勾选所有想赞同的选项，并完成提交”来体现的。可能从使用形式上，并不容易让人体会到这是一种“点赞”动作。
    所以，目前这个动作在当前版本能够体现，但是给人的感觉有误。设计场景6的实现时，需要把点赞动作的操作做的更加简化，至少不应像现在这样需要多步操作完成。

生成互动统计报告

有
  原始投票记录呈现
没有
  关于投票者在全社区活动状态的一些信息（不限于本议题）
    可参考 3-24 日调研结果讨论：
    https://github.com/mindpin/TouchIdea/issues/16#issuecomment-85447319
    关于 Thumb 的星星图标的分析。
  参与者可能感兴趣的数字统计（考虑以视觉化形式呈现）
    例如：参与互动的总人数，贡献出来的意见总数，获得赞同数最多的若干条意见，点赞的饼图，参与者按不同时段进入互动的折线图等。
chilliza commented 9 years ago

mockup文件下载地址：http://pan.baidu.com/s/1eQpgCyY

ben7th commented 9 years ago

3月26日：

需要针对/参考以下四分提交物进行讨论：

  1. 场景 6 的角色泳道图： https://www.processon.com/view/link/55093ce6e4b01eb448378817 如果不能看就看这个： http://img.teamkn.com/i/oMK49Zk2.png
  2. 目前版本和场景 6 的迭代差异比较： https://github.com/mindpin/TouchIdea/issues/18#issuecomment-85330368
  3. pin-idea 目前线上版本的页面流整理（在线查看）： https://www.processon.com/view/link/551381a3e4b0a5a222805fb8 如果不能看就看这个： http://img.teamkn.com/i/i5evHVTN.png
  4. 针对场景 6 的 mockup （我已传到网络便于直接观看）： http://www.mindpin.com/mockups/pin-idea/2015-03-26-scene-6

需要就以下话题进行讨论：

  1. 按照顺序浏览新的 mockup，对于中间所有要素进行 UI 实现/程序开发 方面的评估； 1.1 一些在 UI 实现时，由于内容变化而需要注意的地方 1.2 一些程序实现时，逻辑上需要注意的地方
  2. 厘清今后的【角色事件泳道图】【迭代差异比较记录】【页面流图】【mockup】几类提交物之间的关系，各自的意义，以及提交顺序；
  3. 后续的工作安排，以及程序开发何时展开。
  4. 如果 mockup 不能定稿，则修改并反复进行以上三项；
  5. （当以上工作完成，并且 mockup 能基本定稿之后）制定【如何以当前版本为基础，通过修改来实现新版本】的计划草案；主要需要参考【迭代差异比较记录】 https://github.com/mindpin/TouchIdea/issues/18#issuecomment-85330368 草案要包含的内容主要是开发方面先做什么，后做什么（讨论这部分时可能需要DD参与）
  6. 宋亮开始提交美术稿（以可在线访问的 html 形式提供），并且需求组的夏实，吴笛根据会议讨论结果进行后续工作。
ben7th commented 9 years ago

结果记录：

mockup 点评

HOME

  1. home-2 界面上，每个投票议题列出目前的选项。如果选项文字较长，则截取。如果选项较多，只列前三个（关于何谓“前”三个看后面的描述）。 不管在列表页还是在详情页上，列出选项时，采用以下策略：
    • 不同用户看到的选项顺序是不一样的。并不是按照时间或者得票顺序来排；
    • 同一用户无论何时打开，看到的选项顺序是一样的。（可以根据用户ID所谓随机数种子生成排序）
    • 这样做的目的是为了让所有投票选项在参与者足够多时被投的几率一致；
  2. 新建选项时应该限制字数，限制字数的原则是，使得界面上显示选项时文字不超过两行；
  3. 选项可能需要添加图片。但是具体如何操作可能不易考虑。这次迭代先不做。
  4. 如果补充选项，自动的赞代表参与者自己对自己的赞。同时，允许一个人赞多个选项，甚至全赞。
  5. 补充选项默认只允许补充一个。如果还想再补充，第一个后面的选项都需要申请添加。题主通过后才能显示出来。不过这一版先不做。
  6. 列表上不显示创建日期，选项也不显示添加日期。这样做的目的是减少日期信息对用户心理的干预。知乎目前的问题不显示创建日期也是同样的道理。
  7. 3月31号补充： 按目前这样设计，如果用户处理完一个议题后有机会回到这个议题，则可以取消对某个选项的点赞。
  8. 3月31号补充： 按照目前的设计，允许多选模式的情况下不容易自动切换到下一个议题，导致用户玩得不顺。宋亮和夏实讨论后，初步打算将方案改为：
    • 默认情况下，他赞一次，或者补充一个选项后，就自动去下个议题
    • 如果他想同时赞多次，这时允许他通过界面上某个地方来操作
    • 把多出来的操作加给“想多选”的人
    • 当“想多选”时，本来就是要点多下，也不在乎再多点一下
    • 如果有人说，我就是习惯多选，那么以后在用户设置里加选项
    • 因为需要优先照顾大多数“玩得顺”的人的心流
  9. 3月31号补充： 没有好友系统时，议题列表的议题发布人信息（头像）并不重要。而且即使有好友系统之后，议题发布人头像也不适宜作为议题上需要强调的信息。综合修改建议是：
    • pinidea 0.2 中，列表内不显示发布人头像和名字
    • 将来有好友系统后，大厅列表内，陌生人是小圆点，好友是另一种形状的点
    • “好友议题”列表内，才显示头像
    • 对于我们的系统而言，选项是谁发的可能更重要
    • 而议题的创建者肯定会发至少2个选项的

SEARCH

  1. 搜索是从主页面下方的放大镜导航进来的。
  2. 搜索出来的结果是议题列表，索引范围是议题和选项（会显示的，被禁止显示的或者申请中的不索引，当后续加上这个功能时考虑这一点）。显示方式和 home-2 一致。

ADD POLL

  1. 发表投票是通过主页面的底部导航进来的。
  2. 针对场景 6 而言，应该去掉一切诸如截止日期，报告生成日期等约束。因为在场景 6 而言，没有需要用到日期限制的心理因素。报告应该允许随时查看。
  3. 需要给议题发起者增加一种操作的手段：关闭/打开一个自己创建的投票议题。
  4. 议题中允许多图。（由于目前选项中是没有图的，所以无论从UI呈现上还是心理因素上，都暂时不用考虑多图可能造成的某些混乱；如果后续迭代中在选项中允许图片后，则结合选项如何添加图片，为何要添加图片等因素，考量议题中是否仍然允许多图。包括考虑将来又不允许多图的可能性。）
  5. 还是把链接作为可选项。同时通过链接获取 info-card 的操作流程和界面要素参考豆瓣东西的手机应用。_（安排到会后对于 mockup 的修改中） _

Notification

  1. 由于所有日期因素导致的 feature 应该去掉。所以通知里不再包括报告生成通知。

  2. 目前有四种触发通知的时机：

    2.1 我参加的议题增加了选项 2.2 我创建的选项被人投票了 2.3 我创建的议题增加了选项 2.4 我创建的议题中有任意选项被人投票了

    至于通知里写什么，宋亮考虑。

ME
  1. “我创建的”列表内，由于已经没有日期导致的报告生成因素。改为随时可查看报告。
  2. 由于做的是 HTML 应用。所以关于页面的给个好评，改成分享产品到微博。
  3. 通知设置里面，去掉 夜间免打扰，去掉统计报告。
  4. 通知可能会用到 http://www.oschina.net/question/89964_76571

其他

  1. 需要举报功能，用来举报不良议题和不良选项。举报功能需要特定的提交界面。这一版先不考虑。
ben7th commented 9 years ago

结果记录：

提交物流程

根据时间顺序

  1. 场景描述（文字）
  2. 分角色的泳道图（processon 图片）： http://img.teamkn.com/i/oMK49Zk2.png

  3. 场景迭代差异比较（文字）：https://github.com/mindpin/TouchIdea/issues/18#issuecomment-85330368

    （重要参考，一般来说上一轮会有这个提交物。这一次由于上一轮没有，所以花了时间去补）旧版页面流图（processon 图片）：http://img.teamkn.com/i/i5evHVTN.png

  4. mockup（网页压缩包）
  5. 改动草案（文字）
  6. UI 实现（网压缩包）
  7. 新版页面流图（processon 图片）（会作为下轮迭代的旧版页面流图）
ben7th commented 9 years ago

结果记录：

后续安排

infocard 案例收集：

收集的内容：针对每个商品网站，简单研究其商品页面，并按以下格式逐一记录：

网站名称：
网站首页地址：
示例商品页地址：
能够采集的商品关键元信息，以及如何采集的示意图，包括：
   - 图片
   - 商品名称
   - 商品描述
   - 定价
   - 地理位置

   以上五个属性基本上领域性不太强，无论是实体商品，餐饮服务，软件产品，基本上都可能具备这五个属性。如果页面上能找到这些属性，通过示意图给出位置。如果不能找到就忽略。

案例范例：http://markdown.4ye.me/a70Rlgho

抛砖引玉：

像豆瓣东西里列出的这些网站，都可以作为案例。 一些书籍信息网站也可以作为案例。 一些软件产品推荐网站或者开源项目推荐网站都可以作为案例。 点评类网站也可以作为案例。

ben7th commented 9 years ago

改动草案

目前线上的版本，下文称为【pinidea 0.1】 接下来要做的版本，下文称为【pinidea 0.2】

从 pinidea 0.1 中，需要增加删除或修改以下大致内容（这里只是一个大体描述，具体如何修改，等UI实现稿出来之后，由陈啸峰详细规划），方能实现 pinidea 0.2

  1. pinidea 0.2 优先考虑支持手机。所以设计和实现方面都是基于手机屏幕考虑。PC WEB 浏览器能够访问，但并不特别优化。
  2. pinidea 0.1 中，主题对象层级分为：主题 -> 要点 -> 选项 三个层级。而 pinidea 0.2 中，会变为 主题 -> 选项 两个层级；
  3. pinidea 0.2 中，暂时用不到新浪微博邀请好友的功能。可以在程序中保留而在UI上隐藏。
  4. 通知模块在pinidea 0.2 中不再和新浪微博 API 挂钩，并且逻辑有些改变。
  5. pinidea 0.2 中多出了个人信息页面，且内容不少。个人信息页面会用到从新浪微博获取个人信息的 API。
  6. pinidea 0.2 中多出了搜索，需要实现索引策略和搜索相关界面；
  7. pinidea 0.2 的主题中增加了多张图片支持；并且增加了一个通过网址获取 infocard 的逻辑。关于 infocard 的实现，可以参考后续会提供的商品网站案例收集清单；
  8. pinidea 0.2 的 result 页和目前版本会有所不同；
  9. pinidea 0.1 的数据不保留。

涉及的技术点：

新浪微博登录验证，和新浪微博API 全文搜索技术：elasticSearch（李飞比较熟悉） 通知：HTML5 的通知 API（由宋亮调研 http://www.oschina.net/question/89964_76571 ），faye 选项排序算法：具体描述由宋亮随 UI 实现稿给出，由陈啸峰实现

ben7th commented 9 years ago

4月13日 pinidea 0.2 页面流图绘制

一些要求：