在这篇文章中，将探讨屏幕的初始原型设计。基于最初的需求，这是对它们可能的外观的最佳猜测，但正如所有事物一样，一旦深入了解，变化就会发生。
提醒一下，这是关于正在进行的一系列文章的一部分，在讨论过，将逐步构建一个使用许多不同技术的完整应用程序，例如：
非常喜欢balsamiq原型工具。这可以作为一个独立的安装版本，或者作为JIRA的插件。balsamiq提供了以下功能（只列出了使用的功能，还有更多）：
这是Windows安装的balsamiq桌面版本的样子，看看有多少类别的项目可以选择。
这就是所说的巧妙的设计时支持。这是一个双击过的数据网格，在设计模式下描述了控件的渲染结果。这真的是一个非常好的工具。无论如何，让继续最初的屏幕设计：
这将是一个简单的基于react-router/react-bootstrap的导航栏。关于这一点没有什么可说的。
这将是一个登录表单，将被验证，并提交给Play框架控制器进行进一步验证。Play控制器会从MySQL数据库中查找用户详细信息，如果找到条目，用户就被认为是登录的。在这里保持简单，没有OAuth，没有JWT，只是简单的查找。
如果用户是乘客，他们需要输入的注册信息将与可能需要注册的司机不同，因此有一个特定的乘客注册表单，将被验证并发送到Play控制器端点以存储在MySQL中。
如果用户是司机，需要更多关于车辆的信息，因此有一个特定的司机注册表单，将被验证并发送到Play控制器端点以存储在MySQL中。
只有乘客才能创建新工作。由于所有的工作都是在一台始终位于同一位置的笔记本电脑上完成的，不得不通过接受当前用户输入的当前位置来模拟工作的地理坐标。乘客/司机用户将通过点击谷歌地图提供这些地理信息。地理坐标更新将通过Kafka流，-> Akka -> Comet，或者可能只是使用Akka -> Comet。这部分还没有完全决定。
可能永远只有一个活跃的工作，所以如果一个登录的乘客尝试创建第二个工作，这应该会导致一个错误。
乘客/司机都可以查看活跃的工作。如果工作还没有与司机配对，司机可以通过点击地图上的标记来“竞标工作”。司机的符号将是一辆车，就像以前一样，司机将通过点击地图来更新他们的地理坐标。就像以前一样，地理坐标更新将通过Kafka流，-> Akka -> Comet，或者可能只是使用Akka -> Comet。
乘客可以检查司机的详细信息，并选择接受司机，此时乘客的工作将被分配给选定的司机。
没有分配给工作司机将从地图上移除，只有配对的乘客/司机的地理更新将反映在地图上。
一旦工作完成（通过点击“完成”按钮），乘客将能够对司机进行排名。这将存储司机的排名。这可以直接存储在MySQL中，但想更多地玩Kafka Streams，所以使用Kafka发布者-> Kafka Streams -> KTable的安排来存储状态。然后使用Kafka活跃查询再次获取数据。
司机也可以从他们那一端完成工作（使用“完成”按钮），并且能够对乘客进行排名。这将像上面描述的那样工作。