Add doc turms-chat-demo to introduce roadmap of turms-chat-demo #1330

turms-docs/src/.vitepress/config.ts

@@ -195,6 +195,10 @@ export default defineConfig({
                             {
                                 text: 'turms-client-js Shared Context',
                                 link: '/client/turms-client-js.md'
+                            },
+                            {
+                                text: 'Turms Chat Demo',
+                                link: '/client/turms-chat-demo.md'
                             }
                         ]
                     },
@@ -409,6 +413,10 @@ export default defineConfig({
                             {
                                 text: 'turms-client-js共享上下文',
                                 link: '/zh-CN/client/turms-client-js.md'
+                            },
+                            {
+                                text: 'Turms Chat Demo',
+                                link: '/zh-CN/client/turms-chat-demo.md'
                             }
                         ]
                     },

turms-docs/src/client/turms-chat-demo.md

@@ -0,0 +1,37 @@
+# Turms Chat Demo
+
+## Background
+
+Initially, our plan was to let users to reuse existing XMPP clients by making turms-gateway support the XMPP protocol. However, both paid and free XMPP clients have generally low quality, mainly due to the following reasons:
+
+1. Most XMPP client projects have poor code quality, especially early client engineers who lack coding skills. They often mix complex UI logic with business logic (e.g., the famous open-source project JMeter), making it difficult for redevelopment. It is better to rewrite them from scratch.
+2. Both commercial and open-source XMPP clients have UI designs that are at an amateur level. If a client project lacks a professional UI, we doubt the capabilities of their frontend engineers and UI designers (a competent intermediate frontend engineer should be capable of designing a single product UI independently). We do not recommend users to adopt their solutions.
+3. There is hardly any open-source XMPP client that supports a complete cross-platform solution.
+4. Many low-quality XMPP clients even require payment.
+
+Considering that developing a cross-platform IM application is not difficult and mainly involves manual work, and that IM application UI and functionalities are highly generic (researching 10 commercial IM applications in the market would reveal that at least 9 of them have similar UI and functionalities), we decided to first provide the IM client demo `turms-chat-demo-flutter` for Turms users to use or redevelopment. We will support the XMPP protocol later.
+
+## Roadmap
+
+- November-December 2023: Complete desktop UI design; set up Flutter project framework; develop and test basic desktop components; complete Windows UI development and testing.
+- December 2023-January 2024: Adapt the UI for MacOS; develop and test basic mobile components; complete Android UI development and testing.
+- January-February 2024: Adapt the UI for iOS.
+- February-March 2024: Develop the UI for the web.
+- March-April 2024: Integrate turms-client-dart and implement IM business logic (the above tasks only involve UI development and testing, excluding business logic).
+
+Note:
+
+- Considering other tasks, holidays, and work situations at Turms, the above timeline may be subject to slight changes.
+- There is no plan to support mini programs.
+
+## Introduction
+
+We want to emphasize the term `demo` in the project name. This term mainly has the following meanings:
+
+1. Whether from a product perspective or a technical perspective, this client "demo" is just one of the "possible" solutions. Users should not limit their ability to design their own IM products because of this "demo." Especially, do not assume that Turms' server is customized for this "demo." As repeatedly mentioned in the Turms documentation, Turms is a generic IM solution dedicated to solving various IM scenarios.
+2. Prepare for users' further development. This mainly involves three aspects:
+   1. Separation of UI and business logic. This allows teams that require redevelopment to reuse the UI and implement their own business logic.
+   2. We continue to use the permissive Apache 2.0 license instead of the more restrictive GPL license commonly used in client open-source projects.
+   3. Since the UI design of IM applications worldwide is very similar, this `demo` will also implement most of the generic UI and logic for IM. It generally does not provide more customized logic to facilitate redevelopment by other teams.
+
+Note: `demo` does not imply "low quality." Readers will understand this by examining the code quality and UI design later.

turms-docs/src/zh-CN/client/turms-chat-demo.md

@@ -0,0 +1,37 @@
+# Turms Chat Demo
+
+## 背景
+
+最初，我们是计划先通过让turms-gateway支持XMPP协议来让用户能够自行复用世界上已有的XMPP客户端。但是不管是收费，还是免费的XMPP客户端质量基本都不高，主要体现在：
+
+1. 大多XMPP客户端项目代码质量差，尤其是很多早期客户端工程师的代码功底很差，甚至会把复杂的UI逻辑与业务逻辑杂糅在一起写（比如著名开源项目JMeter），二次开发不如自己重写。
+2. 不管是商业还是开源的UI设计水平基本都停留在业余爱好者水平。如果一个客户端项目没有专业的UI，我们会对其团队的前端工程师与UI设计师的能力表示怀疑（团队中只要有一位靠谱的、中级水平的前端工程师，就应该有独立设计单一产品UI的能力），也不会推荐用户去用他们的方案。
+3. 几乎没有一个开源的XMPP客户端支持完整的跨平台方案。
+4. 很多质量不高的XMPP客户端甚至需要收费。
+
+考虑到提供一套跨桌面端与移动端IM应用的开发难度不高，主要是体力活，并且IM应用的UI与功能通用性强（在市面上找10款IM商业应用调研，会发现至少有9款IM的UI与功能是基本类似的），因此决定先提供IM客户端Demo`turms-chat-demo-flutter`，让Turms的用户能够自己使用或二次开发，之后再支持XMPP协议。
+
+## RoadMap
+
+* 2023年11月~12月：完成桌面端UI设计；搭建Flutter项目框架；完成桌面端基础组件开发与测试；完整Windows桌面端UI开发与测试。
+* 2023年12月~2024年1月：完成MacOS桌面端的UI适配工作；完成移动端基础组件开发与测试；完成Android手机端的UI开发与测试。
+* 2024年1月~2024年2月：完成iOS手机端的UI适配工作。
+* 2024年2月~3月：完成Web端的UI开发。
+* 2024年3月~4月：集成turms-client-dart与实现IM业务逻辑（上述任务只有UI开发与测试，不包括业务逻辑）。
+
+另外：
+
+* 考虑到Turms的其他任务、节假日与工作情况，上述时间可能会略有变动。
+* 无计划支持小程序。
+
+## 简介
+
+我们想着重提醒项目名中的一词——`demo`。该词主要有以下几种含义：
+
+1. 不管是从产品角度，还是技术角度，该客户端`demo`也只不过是其中`可能的`的方案之一，用户不应该因为该`demo`而限制设计自身IM产品的能力，尤其不要认为Turms的服务端是为该`demo`定制的，正如Turms文档中反复提及Turms是一个通用IM解决方案，致力于解决各种IM场景。
+2. 为用户的二次开发做准备。这主要分为三个方面：
+   1. UI与业务逻辑分离。方便需要二次开发的团队复用UI来实现自己的业务逻辑。
+   2. 依旧采用宽松的Apache 2.0，而不是客户端开源项目常见的、更加严格的GPL协议。
+   3. 由于全球范围的IM应用的UI设计都非常类似，因此该`demo`也会实现大部分IM的通用UI与逻辑，一般不提供更为定制化的逻辑，以方面其他团队二次开发。
+
+注意：`demo`没有`质量低`的含义，这点读者之后看代码质量与UI设计就可明白。