V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  UIXX  ›  全部回复第 13 页 / 共 40 页
回复总数  788
1 ... 9  10  11  12  13  14  15  16  17  18 ... 40  
2022-06-28 09:52:37 +08:00
回复了 oyp 创建的主题 程序员 新人写的网站,望大佬提供意见
直说了吧,LZ 的方向走错了。

无论是你以学习的目的写一个 Demo 还是真正做一个可运营的站点。都应该以“抄”开始,而不是按自己想的先随性地做一个然后拿出来给大家改。

一个好的画师在磨练出自己独有的画技之前,他必须要有足够的对美的鉴赏力。有了对美丑的感觉,才有对画法好坏的定义,才有一个明确的努力方向。

我以前也曾用 JQ 手撸论坛系统,然后根据用户的体验一点点改,事后发现这完全是愚蠢的,或者说是很低效的。
像登录模块这种有“定式”的部分,我本可以借鉴外界的最佳实践,但却浪费了大量时间在改样式、文本上;
像帖子界面那样本该简洁的布局,应该把思考重心放在内容呈现上,控件的摆放细节却让我耗尽心神;
像权限分配一般重中之重的功能,我对其中的内涵一无所知,设计的时候各种“想当然”;

这一切都是因为我根本不知道这种内容系统该怎么做:
我接触的论坛类型少;
我从未在设计的角度思考我用过的这些网站;
我不知道这类站点会有哪些“潜规则”;
我只知道扣 Margin 、padding 的数值!

回到 LZ ,你的问题大体是类似的。
其实用过时的 JQ 做项目根本不是重点,重点是你现在连一些模块怎么做,一些最基本的“定式”“常识”都没有掌握。用几个 input ?用什么过渡效果?这些主观的东西不应该是 V2er 你一言我一语地教出来的。

你现在最好的学习方式就是抄,大量地抄。从方案到具体技术,一步步来,让自己形成一种知觉,在实现框架中形成自己擅长的模式。
2022-06-27 10:41:48 +08:00
回复了 sxxsxx 创建的主题 职场话题 计算机毕业,关于职业选择的困惑
自己的人生,自己做决定,自己负责。
其实这事没什么好辩论的。开源协议不是什么严丝合缝的法律条文,选择它时也没有什么特定的法律程序,双方都说得有理有据,要真拉扯双方都有拉扯的空间。天猪也说了本来就是很简单的事,说一声双方都知道就得了。

现在主要矛盾是天猪觉得 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 所说,怎么运营、怎么进行内容管理才是建设这类站点核心的地方。
2022-05-17 21:50:37 +08:00
回复了 UIXX 创建的主题 英雄联盟 抛砖引玉,有没有人关注此次 MSI 赛事
Append 2
2022-05-16 12:30:44 +08:00
回复了 Stendan 创建的主题 程序员 请教一个关于 Ping 的问题
0X 年的时候写过游戏逻辑,技术可能过时了,就简单说说吧。

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

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

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

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

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

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

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


甲方是不会有直接的感同身受的,乙方需要维护自己工程师的利益。如果乙方只会两头吸血,那么 run 就对了。
2022-05-11 18:44:51 +08:00
回复了 Aliberter 创建的主题 程序员 公正评价,这代码什么水平
对于已经语义化了的变量,我有一种评判代码逻辑组织是否合理的方式,即

用自然语言去试读代码是否会让人感到冗余。

从这个角度来看,我是同意 LZ 的说法,比如 if isOpened == true (假如 已打开 为真)就不如 if isOpened (假如已打开)。
2022-05-11 15:42:48 +08:00
回复了 lazydog 创建的主题 职场话题 人在体制,打算裸辞了。
之前好像回答过类似的问题。

一言蔽之,在体制内工作容易缺乏职业自信。原因懂的都懂,不赘述。

裸辞跟骑驴找马哪个好,这无法判断,很多事确实只能等到“盖棺”才能定论。但有一个事情是没错的,无论作了哪种选择,都要付诸相应的努力走下去,瞻前顾后、反复横跳是大忌。
2022-05-09 10:02:34 +08:00
回复了 CookCoder 创建的主题 求职 太多年没有写简历,诚恳各位审阅一下
既然是挂在网站上作个人展示,就不要拘泥于纯文字描述,可以发挥网络媒体的优势,增强一下读者的视听感官体验。

因为你也是 Web 工程师,前后端都做过。不妨:
- 做个个人经历的 timeline ,突出从学生时期到职人时期的里程碑节点。
- 对项目介绍作可视化处理,比如小程序的动图+动效展示。

个人网站一般是第二入口,即大部分点进去的人是“对你有点感兴趣”的对象,他们可能从别的地方(投递的简历 /论坛的贴子 /Github 的项目代码)知道了你,然后想进一步了解你。因此我觉得在里面感性的建设是必要。

最后是个个人看法:开源出来的东西尽量把 README 写好。
我注意到“喜欢编写健壮的代码,编写会以牺牲性能来提高可读性的代码,因为代码是给人看的”,从工程的角度看,纯叙述性的项目描述也是可以提高项目可读性的。
2022-04-20 11:34:40 +08:00
回复了 JamesRuan 创建的主题 职场话题 面试有感,不吐不快
...给后来的人总结一下:

LZ 面试了一个图形工程师,感到不快,原因如下:

对方背景似乎很牛,但对于 LZ 的核心问题没回答到点子上。
从对方的话语中得知他只想“找大牛抱大腿”(可能还有点不愿意做一线实施的意思,仅个人猜测)。
2022-04-19 11:15:35 +08:00
回复了 shawnwang340 创建的主题 程序员 真心请教: 29 了还在公司 CRUD,怎么突破自己?
我试下解读你的需求:
你希望搞钱,但在青岛当程序员工作内容平庸,工资也平庸,想要改变的时候发现自身资质也平庸。

这跟 CRUD 本身没什么关系,就是没有立身之本、缺乏职业自信造成的精神内核不稳固。

我的建议是先作自我剖析,认清自己,再决定接纳还是改变自己。
2022-04-13 14:51:45 +08:00
回复了 equationl 创建的主题 程序员 个人开发者处境是否越来越困难了
其实你说的不是什么新鲜事儿,就是一个渠道管理的问题。

在 app 运营的最初期,你的推广渠道够不够多、你在推广渠道话语权够不够大是很关键的。

菜市场的格局已经从堆数量的野蛮生长期过渡到了保质保口碑的成熟期,在这里面,个人小开发没有自主能力。
除了海外渠道,经营私域是最常规的玩法:业务 app 上小程序、云平台,甚至只是打个 apk 包挂到 XAMPP 上。用威推抖油等还有原创红利的新媒体导流。
2022-04-11 17:05:10 +08:00
回复了 interpretation 创建的主题 职场话题 offer 选择求教,大公司 vs 小公司
先去大公司,让前老板给你留个坑。
1 ... 9  10  11  12  13  14  15  16  17  18 ... 40  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5134 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 40ms · UTC 08:22 · PVG 16:22 · LAX 01:22 · JFK 04:22
Developed with CodeLauncher
♥ Do have faith in what you're doing.