comsenz 要求用家，日后安装旗下各产品前需要先安装Ucenter，用以整合各产品的用户资料，加强社区的互动性。
对于会员数目众多的论坛用家来说，这无疑是一个天大的喜讯：Ucenter的出现，能够整合SupeSite 、X-Space、SupeV、Discuz等等的社区软件，若果网站有什么大型决策，使用Ucenter便能够将所有会员资料统一处理。
现时的安装概念如下图：


Comsenz在要求用户必需安装Ucenter的同时，有一群用户似乎正在被遗忘：中小型的论坛用户。没有错，Ucenter对于拥有大量会员的论坛来说是一个可以发挥得很好的整合软件，担当的角色正正是资讯交换的枢纽。但对于没有需要使用SupeSite 、X-Space等等软件的用户来说，这种捆绑式的安装会令用户对Ucenter的存在价值起了莫大的疑问：好端端的Discuz管理中心不是很好吗？为何要在Discuz以外开立另一个程序去管理会员？Ucenter虽然只占用若19个资料库，但这些功能对于这类用户来说其实是可以在Discuz中找到的，又或者说，用户要在没有Ucenter的情况下得到Ucenter功能，未必需要19个资料库，反而只需数个会查询资料库的插件就可以。

或者会有人说，UCenter的存在是Comsenz想增加Discuz以外的产品的使用量，这猜测并不合理，因为Ucenter的存在并不会令到用户因此而额外安装一个新程序，Ucenter的存在极其量只是方便用户整合，而非促成用户安装其他新产品，例如香港地区用户永远用不上的SupeV、SupeSite等等。Comsenz若果以为把Discuz的会员资料功能移到其他Comsenz产品就能够加强新产品使用量的话，这个馊主意绝不可行的。因为功能不切合用户需求就是不切合，Comsenz要做的不是硬销，而是反思。

若果Ucenter是纯粹为整合会员资料这个好处而出现，Comsenz要求捆绑式安装的决定是否有错呢？若果Ucenter真的以整合资料、加强互动的原则出发，安装程序理应是先有一个Comsenz产品，用户若果要安装第二个Comsenz产品，为了“整合会员资料”，才安装Ucenter的。如下图：

有时，真的会想，Comsenz有时会不会想多了，觉得所有产品非常受欢迎，所有用户对整合的需求都极度殷切？真的有很多用户同时使用三个、四个的产品吗？还是我目光太浅窄，只知道Discuz、Xspace一兩个程序？最后，面对功能日益增强和增多的Discuz，容许我再促请相关人士，认真考虑将Discuz Lite 纳入正规Discuz的发展计划当中，或许Comsenz看到的正在增长的财政收入是因为功能强大的产品带来的收益所致，但在这个庞大的数字背后，正是由比这数字更大的用户群所支撑，请为这群占大多数的小众设想，谢谢。

[ 本帖最后由 笨水水 于 2008-6-24 19:29 编辑 ]

文章很好。

但考虑一个情况。假如开发插件，第一种安装方式还是第二种方式方便？
第二种的话，有可能会出现很多种意外因素.......
我也不喜欢uc，这也是为什么我在测试了近3个月后投到dz6.1f的原因；但是从插件修改者的角度出发，uc存在的价值立即体现了。

comsenz现在的问题，是太过于跟者潮流，而没有静下心来考虑自己的优势在哪里。
远的不说，uch的1.5版本让人再一次感觉comsenz的不冷静和不成熟。
不要把所有鸡蛋放在一个篮子没错，但是，把鸡蛋分散在n个篮子同样也不可取。再这么下去，太阳神似的没落，我觉得不可避免。

现在在别人家上网，回来再详细阐述。

[ 本帖最后由 horseluke 于 2008-6-24 22:14 编辑 ]

引用:

原帖由 horseluke 于 2008-6-24 22:12 发表
文章很好。

但考虑一个情况。假如开发插件，第一种安装方式还是第二种方式方便？
第二种的话，有可能会出现很多种意外因素.......
我也不喜欢uc，这也是为什么我在测试了近3个月后投到dz6.1f的原因；但是从插件 ...

但要切想另一點，有插件會適合所有產品的嗎？即使有，但只是安插在uc上，而非單一插件上

举两个例子吧。
一个是短消息的处理插件。这类插件其实并不少——随着dz6.1针对管理员的短消息管理功能的弱化，这类插件肯定将会多起来。
现在的情况是，所有短消息给uc接管了。那么插件开发者应该就针对uc作处理就ok了。
但是如果使用你的方法，那么就麻烦了——首先至少要做两个插件，插件作者烦；其次用户在安装第二个产品、多了个uc后的又要转换插件，用户觉得麻烦。
第二个更加严重，如果插件涉及头像调用，维护起来更加困难。至少到现在我还没看见用类来调用头像的插件。

说到底，就是用户资料的转移，会影响到这类插件的功能发挥，甚至可能因此出现漏洞。

至于你说“UCenter的存在是Comsenz想增加Discuz以外的产品的使用量”，要不得不说一下，comsenz理解的uc，和站长理解的uc不完全一致。
comsenz理解的uc，就是一个万能插头，用户基本信息的集合地。所有程序只需要调用最基本的东西，剩余部分或者要扩展的用户资料由各个产品自己的用户中心解决——或者基本上来说，comsenz已经提供了一个用户中心，就是uch；用户如果要管理自己在这个站点的所有信息，就用uch搞定（否则uch 1.5版也不会出现什么“开始”菜单）。
而相当一部分站长，希望uc就是一个用户中心，用户所有信息都在那里，成为一个完整的通行证。用户可以登录uc更改自己的信息；而且只需要一个id即可登录到各个中心，所有产品都使用同一张通行证。

现在的情况是，uch在大肆宣传sns功能之后不仅仅忽悠了站长，而且把自己也给忽悠了——该继续宣传和加强uch的sns功能，还是加强uch作为comsenz六大产品的用户中心功能？在1.5版本，就感觉到迷惘了
因为，要同时做到sns功能和comsenz六大产品的用户中心，嘿嘿，我看不太行。

最后，“将Discuz Lite 纳入正规Discuz的发展计划当中”，我觉得，就现在的形势来说，这应该是fd论坛长期寒冬过后的春天来临了

引用:

原帖由 horseluke 于 2008-6-26 20:00 发表
至于你说“UCenter的存在是Comsenz想增加Discuz以外的产品的使用量”，要不得不说一下，comsenz理解的uc，和站长理解的uc不完全一致。
comsenz理解的uc，就是一个万能插头，用户基本信息的集合地。所有程序只需要调 ...

我不是說過「这猜测并不合理」嗎？

引用:

原帖由 horseluke 于 2008-6-26 19:42 发表
举两个例子吧。
一个是短消息的处理插件。这类插件其实并不少——随着dz6.1针对管理员的短消息管理功能的弱化，这类插件肯定将会多起来。
现在的情况是，所有短消息给uc接管了。那么插件开发者应该就针对uc作处理就 ...

我想有一點要攪清楚的：
你說會有例如短消息之類的問題
但還原最基本的一點： 程序員的開發方便重要還是用戶使用流暢度重要？ 先不要設想用戶會加插第2個產品，先來1個產品如何？ 若果實在有管理短消息的需要，發展兩次亦是必要，而非「浪費」、「麻煩」
況且現時UC的設計分明就是便宜了開發進程，害了用戶。用戶若果要由第2種可行方法加插第2個產品，要對系統作修改亦是必然的，世上並沒有免費午餐，但現行方法就是要利用用戶的資源將免費午餐雙手奉送予開發人員。

引用:

原帖由 笨水水 于 2008-6-28 00:06 发表

我不是說過「这猜测并不合理」嗎？

看来我的表述有点问题，不能让你明白我的意思
这个猜测我觉得其实有它存在的原因的。
因为前面说过了，在康盛公司看来，用户要管理自己的所有信息，同时又要展示自己在那个站点的动态状况，最好使用uch，而非uc——即使只有一个应用存在，如论坛程序（用uch来展示自己在论坛的动态）。
为什么会这么说呢？以前的mini-space，其实本意就是要用来展示用户在论坛的动态信息的[1]；现在这个东西交给uch了，没有uch来了解用户动态？难啊，除非自己开发一个类似的东西吧 。
但是uch又要用到uc，如此一来，猜测就成立了。

备注：
[1]虽然robots.txt有一句“Disallow: /space.php”来限制搜索引擎对mini-space页面的抓取，但是很不幸很多站长不懂得robots.txt是要依据自己的站点特性修改一下、然后放在合适的目录下才能起作用。结果就导致了大量的mini-space页面在搜索引擎上出现。这不知道算是好事还是坏事。

引用:

原帖由 笨水水 于 2008-6-28 00:10 发表

我想有一點要攪清楚的：
你說會有例如短消息之類的問題
但還原最基本的一點： 程序員的開發方便重要還是用戶使用流暢度重要？ 先不要設想用戶會加插第2個產品，先來1個產品如何？ 若果實在有管理短消息的需要，發 ...

程序员（或者扩大一点范围，技术员）想的都是两个点之间如何通过技术走得最近、最省时间.......等等等等，不会把人的因素包含在内的
不过对于你最后一句还是很赞同的。现行的uc的确就是为开发而准备的，对于最终用户，并没多大益处——反而导致了最终用户的困惑和不满。

[ 本帖最后由 horseluke 于 2008-6-28 15:00 编辑 ]

分析得很透彻啊