txia

上个学期的时候，因为疫情的缘故，我所在的学校为了控制食堂的人流量，引入了一款预约饭点的第三方移动应用。简单地说，这款应用的功能就是在完成身份验证后，让用户选取取餐的地点和时间，软件在点单完成后发送确认邮件，然后用户凭确认邮件去食堂取餐。可以说，业务并不复杂，实现得好应该也不难，但是不知为何这个APP设计得就很烂，用户体验特别差，预约步骤特别麻烦，每次需要： 指纹解锁APP -> 等待APP跳转到下一个界面 -> 点击“Start an order” -> 等待APP跳转到下一个界面 -> 选择预约地点 -> 等待APP加载数据 -> 选择日期时间 -> 等待APP加载数据 -> 将早饭/中饭/晚饭加入购物车 -> 等待APP跳转到下一个界面 -> 结算购物车 -> 等待确认邮件 整个流程下来如果运气好那么要30-45秒，如果运气不好，刚好处在点餐高峰期，应用后端便会不堪重负，前端数据永远加载不出来，然后应用直接崩溃挂掉。这款应用还会经常莫名其妙地闪退，或者出现整个界面失去响应，导致用户只能强制关闭。而且到了食堂要掏出手机，翻出那封可能早已经被其他邮件所淹没的确认邮件，给食堂门口那几位生无可恋的工作人员肉眼检票。刚开始大家还比较遵守规矩，会按照下单的时间和地点去食堂取饭，但到了学期中大家都被搞疲了，于是出现了五花八门各式蒙混工作人员的手段，有修图改确认邮件时间的，也有使用过期的邮件截图欺负食堂大妈眼神不好的，更有直接闯卡的。总而言之，这款应用不光使用体验巨差，也根本达不到原来控制人流量的设计目标。 寒假的时候闲来无事，就和另外两位CS系的同学，用Flutter和Firebase替学校的Dining Service开发了一款更加简单易用的预约软件，准备在春天投放使用，改善一下大家的预约订餐体验。比起原有的APP，新开发的APP主要有以下一些方面的改进： 改用Google Account一次验证登录用户，省去了每次解锁APP的流程 日期、地点和时间选择全部放在同一界面上，前端数据实时刷新，方便用户一键预约 在就餐地点部署PROX读卡设备，用户点单后可以直接刷卡进入 新增历史订单查看和取消功能 这个项目前前后后，断断续续大概折腾了一个月，最近总算是弄完了。这几天刚好有空，就胡乱写点东西记录记录开发过程，假装一下博客还在更新。