UIXX

UIXX

V2EX 第 292801 号会员,加入于 2018-02-20 15:30:01 +08:00
根据 UIXX 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
UIXX 最近回复了
其实这事没什么好辩论的。开源协议不是什么严丝合缝的法律条文,选择它时也没有什么特定的法律程序,双方都说得有理有据,要真拉扯双方都有拉扯的空间。天猪也说了本来就是很简单的事,说一声双方都知道就得了。

现在主要矛盾是天猪觉得 LZ 把他挂到 V2 上来害他被骂了,他要采取措施。建议 LZ 私下与天猪协商,事后让坛主把帖子删了得了。
我看了 Mix Space ,也看了保罗的小窝,有一些结合了个人经验的看法。

我没做过完整的前端 UI 方案,但做过 Discuz 的插件跟局部 UI 修改,恰好 Mix Space 这种板块布局风格非常像以前的 Discuz 二次元主题,我想可以说些什么。

由于主题叫 Kami ,加上 demo 标题,这应当是一套偏日式风格的 UI ,但我感觉到一些违和:

1. Helvetica 极其平淡,使用日式风格字体更好,比如一些黑体、细长体与细圆体。

2. 白天模式下的背景白对比过于强烈,造成阅读不适,可以换成温和的大色块。夜晚模式要好一些,但背景的横线仍让我不禁想起 QQ 空间中的“信纸”,有一种廉价感。

3. 透明底的控件不好。博客要设计得有层次感,一是突出内容的类属,比如正文、回复框与评论,降低读者的“负担”,二是反衬出背景,不致于文字与图像无序杂糅。

4. 减少色彩的使用。这个就不多说了。

5. 论坛式的板块布局不适合直接用于文章陈列。弊端很多:
- 无法从有限的板块宽度中提取完整的文章标题;
- 文章配图局限大;
- 横向空间利用率低;
- 整体有效信息密度低

就信息密度低多展开一下。无论是博客系统还是论坛系统,重要的还是有效信息,风格再强烈,该传达给读者的还是要传达的。所以除了纯炫技的飞机稿,非主要的图片元素喧宾夺主是打造主题时很忌讳的一件事。

希望 LZ 的项目能越做越好。
看了 Pixcall 的官网,有些东西可以说一说。

我建议你先对 Pixcall 和 Eagle 的官网做一做各级标题的词云分析。
Pixcall:“云端同步”、“本地客户端”“图片优化”、“浏览器扩展”、“客户端插件生态”、“免费”。
Eagle:“素材整理”、“激发灵感”、“快速找到收集”、“轻松整理”、“流水般浏览”、“用户喜爱”、“媒体好评”。
Pixcall 的主流服务群体是谁?是设计师等一众呈现视觉效果的群体,TA 们感性度更高,更受用表达情感的抽象名词而非技术名词。
你希望它是一个“硬邦邦”的工具,还是“柔软灵活”的助手?

同样的角度,动效的表达大于静图,内聚的表达大于宽放。就不展开说了,个人觉得 Pixcall 官网的内容及排版需要更加专业、有倾向性的设计。

然后我想讲几点关于竞品的理解。
(这里只是针对策划已知市面上已经存在同类产品的情况)

“凭什么抛弃惯用的 B 来选择你的竞品 A”是在产品立项的时候就要作出的思考。未雨绸缪利于在关键点上对症下药,如:
用户觉得缺少平台支持--使用跨平台、移植性好的技术。
用户觉得软件不够灵活--模块化、增加插件机制,甚至(部分)开源。
用户有路径依赖--复制竞品的逻辑与流程,大到布局、小到快捷键。

在运营端,先争取大牛背书,讲得一手好故事,有了基本立足点后借助各路大众媒体广撒网。推广与技术配合好,在宣传期降低活动准入门槛(别一上来就搞手机邀请码注册),筛选种子用户,做好反馈收集。接下来就是赶紧迭代,实在没辙了就修正赛道,在小众需求上实现弯道超车。

对于竞品开发,小团体对抗大公司可能只有一个有利条件:关键的运营人员、技术人员离实际用户“更近”,在快速反馈上有人员组织架构的优势。
确实跟 Twitter 风格很像,不过并不重要,如同 @yazoox 所说,怎么运营、怎么进行内容管理才是建设这类站点核心的地方。
39 天前
回复了 UIXX 创建的主题 英雄联盟 抛砖引玉,有没有人关注此次 MSI 赛事
Append 2
40 天前
回复了 Stendan 创建的主题 程序员 请教一个关于 Ping 的问题
0X 年的时候写过游戏逻辑,技术可能过时了,就简单说说吧。

1. 不知道,这得问 LOL 的开发人员,不同游戏的 ping 代表的含义可能会不一样。
游戏内显示的 ping 值不一定是 TCP/UDP 的时延,也可能是专门为游戏设计的心跳机制中的网络参数。

2. 网络状况迥异的环境下,没有任何技术手段能确保双方都在某个 ping 范围内。
比起锁定延迟,我们更常的做法是在帧同步上下功夫,比如优先让网快的正常游戏,网慢的客户端对短时间内过来的更新指令作类似于快进的处理。

3. 不同架构、不同类别的游戏控制同步的方法不一样。
比如一款中心化的 RTS 游戏,采用的是服务器广播-客户端收发的方式交互,想要增加延迟可以设置广播队列的发送时间。对一款允许局域网内的 RPG ,纯粹的 P2P 通信,只需要交互前约定共同参数即可。
40 天前
回复了 UIXX 创建的主题 英雄联盟 抛砖引玉,有没有人关注此次 MSI 赛事
@littleylv 见 append
42 天前
回复了 zhuwd 创建的主题 程序员 定制化需求三天一变,累死技术部
频繁地改需求,不外乎是以下几个原因:

1. 甲方对自己的需求不明确 或 乙方对需求理解有偏差。
这种还是挺有说法的,对口定制化跟不对口定制化情况略有不同。
对口定制化中,乙方在开需求会议的时候有义务引导甲方把需求漏洞补全;
非对口定制化中,需要甲方有人全程跟进,双方频繁沟通保持意见统一;

如果已经进入了开发期,有必要重新开展需求研讨会。

2. 甲方追加额外需求
甲乙双方在协商开发周期以及开发成本的时候就要明确额外需求的处理方式--优先级、费用、后续维护事项等。
一旦写进合同,照章办事。甲方来新的需求,乙方负责人会议评估,一致通过的话可以进行排期。如果不通过,对甲方反馈再作协商。

这里面有一个非常重要的点:甲方的需求不能直接到具体的编码人员,中间必须要有项目经理跟技术经理作评估。乙方需要有立场的独立性。


甲方是不会有直接的感同身受的,乙方需要维护自己工程师的利益。如果乙方只会两头吸血,那么 run 就对了。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1011 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 18ms · UTC 20:55 · PVG 04:55 · LAX 13:55 · JFK 16:55
Developed with CodeLauncher
♥ Do have faith in what you're doing.