技术控

    今日:57| 主题:49101
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] To Designers With Love (A Letter From a Front-end Developer)

[复制链接]
涨姿势 发表于 3 天前
38 3

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
Dear Designers,
  This letter has been brewing for years. Parts of it have been delivered in speech and in writing to various designers over a long period of time.
  However I’ve always dreaded publishing it out of fear that it would implicate the current designer or client I’m working with. So before I proceed I’d like to emphasize that this is not a specific grievance but rather an itemized list of 18 years of disagreements.
  We have worked together for almost two decades, and each PSD file you’ve sent me has had (more or less) the same issues. Forgive me then for the indecency of trying to teach you your job.
  I do not presume to teach you about graphics or aesthetics. I will not delve into typography, legibility, or use of white-space.
  Instead, I’d like to explain how the fruits of your labor inform mine.
  I’d like to remind you what is required to reproduce designs as pixel-perfect web pages. I’d like to tell you how your design files will be used for documentation and how the images you create determine the technologies used – down to the very base levels of scalability and performance.
  Also, I’d like to demonstrate what can be done quickly and easily and what will generate overhead that will drag the entire production to a crawl.
   And most of all, I’d like to remind you that the picture you’re creating right now will be made into a living thing that interacts and responds, that communicates with thousands of different individuals, that needs to teach them, and learn from them in the most effortless way possible. Both for it and for them.
  Designing for Documentation

   First of all, I’d like to remind you that the PSD files you’re producing are not only the source of the images for the client to approve, they’re also technical documentation and source materials for developers. Therefore, please keep your layers and groups tidy, organized and named .
   
To Designers With Love (A Letter From a Front-end Developer)-1 (publishing,designers,together,required,specific)

  Dear Designers, for two decades you've been sending me PSDs with the same issues.
  Annotate your design. Either create a separate file with the conventions you’ve used, or note them in a separate hidden layer.
   Tell me which fonts you’ve used for what. Let me know which colors, spacings, and contexts to use. I need to know.
  I also need to know what to extrapolate if no design has been made for a specific feature.
   I guess what I’m trying to say is: If at all possible create a brief style guide for the product you’re designing.
  For both our sakes, when adding standard text blocks – such as titles – add a rectangle behind them to indicate the spacing around them. That should enable you to consistently place them every time. If this is too much work, at least indicate which example in the document is canon.
  I cannot tell you how often I find that titles are placed by eye so they visually fit the single instance in which they’re being placed, but when measured, reveal that each has its own individual spacing.
  The same goes for content blocks. If you have a list of different content blocks, please space them out consistently.
   I’ll tell you more in the Designing for Content section, but please don’t assume that your titles will always be in one line, and use that information in the file.
  I keep running into these titles that have font size 22px and a line height of 92px (obviously copy and pasted from main page title). The settings you choose are relevant even if they don’t visually change the exported file.
  Designing for Technology

   There are two sides to this: What can be done and what is appropriate for the medium.
   While we are fast reaching the point where everything will be technically possible for website development (if nothing else, I can still draw it out pixel-by-pixel using canvas) a lot of those solutions are not production-ready.
  The fact that you found an example where someone successfully combined WebGL 3D with CSS blur plus filter masks for a demo page does not mean that you can use that as a full-window parallax panel in a single page application.
   And if you really want to walk the bleeding edge, please consult with your developer before submitting the design for approval. Otherwise, it will be hard to get the client to settle for less.

To Designers With Love (A Letter From a Front-end Developer)-2 (publishing,designers,together,required,specific)

   If you really want to test the edges, though, and if you want to try it out for fun, contact me privately. I love creating things like that as much as you do. Just don’t put that stuff into a budgeted production project.
   Beyond those things – beyond testing the limits of what can be done, try to be sensitive and sensible with regard to what should be done .
  You’re not a graphics artist; You’re more than that, you’re a designer.
   You’re not only designing it to look a certain way, you also have to design it to run a certain way, communicate and behave in a certain way.
   To go for the cliché familiar to designers everywhere: What good is a gorgeous looking chair if no one can sit on it ?
   You must incorporate speed of loading, and speed of execution and ease of use in your design for it to be a design instead a picture.
  Try to achieve as much as possible with only HTML and CSS.
  Try to achieve as much as possible with only HTML and CSS. Avoid using nice-looking features that are available in Photoshop. Don’t use blending! Don’t use faux bold and faux italic.
  Unless you intend the element to be an image, don’t use filters at all – other than the simplest shadows.
  Don’t make me calculate or pick the colors because you’ve used blended color fills. Please don’t fake transparent images by using overlay blending; I actually need a transparent image on site.
   If we’re using a front-end framework, such asBootstrap, many of these issues will already be solved, so learn how it’s done and how it can be modified. Don’t just go willy-nilly designing something unrelated.
  If your design is not in line with what the framework does, than implementing it is not implementing the design. Instead we end up selectively overriding the framework, so it doesn’t mess with our design and then implementing it from scratch. The workload doubles instead of halving.
  And finally, don’t use more than three fonts – or font variants – on the site. If you need six different weights, each with its own regular and italic variants, you’re no longer designing for the web.
  Designing for Interactivity

  This is a huge one. And this letter was originally written exclusively for this topic. You really have to know and understand all the ways users and functionality can interact.
  Let’s start with the simplest things: links.
  Links do not have solely two states.
   In the navigation I receive, you always provide designs for links and an active link (current page).
   In other cases you usually provide base and hover states.
   If you want to be the least bit user friendly, you should have distinct designs for base, hover and focus states ( visited and active are also nice-to-have for UX). And for navigation, a link and an active link each have all of the above states .
  Oh, and don’t you dare change a link layout between states (varying border width, padding, and the like).
  Similarly, if it doesn’t look like a button, it doesn’t have a background. Period. Padding an inline text element is a mess, and unpadded text backgrounds will never do.
  Since we are going to use this on mobile, make sure that there is enough whitespace between separate interactive elements, and that each hitbox is sufficiently large. I think that a minimum of 42px on each axis is the norm.
  Draw an invisible rectangle, or a hidden layer showing hitboxes; make sure they don’t overlap and that user interactions are unambiguous.
  Form elements are even worse.
  The most common case I see is with the radio buttons and checkboxes. The standard ones are ugly! So, you design your own, and give me a checked and an unchecked state, and consider yourself done.
  However, there is an entire multidimensional table of states for a checkbox, and each should be visually indicated to the user.
  We have the following states:
  
       
  • Checked or unchecked   
  • Hover or not   
  • Focus or not   
  • Enabled or disabled   
  • Error or not  
  Each of those can combine with the others.
  Disabled prevents some combinations (hover and focus are usually irrelevant when disabled) but not all (checked-disabled-error is a perfectly valid and informative state for a checkbox). So we end up with 16 enabled and four disabled states, giving a total of at least 20 distinct states. For example, the states you usually give me are checked-not-not-enabled-not and unchecked-not-not-enabled-not in that setup.
123下一页
友荐云推荐




上一篇:Quiz: Choose the Right Front-End JavaScript Framework for Your Project
下一篇:wordpress博客搬家到阿里云遇到的十大问题
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

vicni888 发表于 3 天前
鄙视楼下的顶帖没我快,哈哈
回复 支持 反对

使用道具 举报

lyh51119768 发表于 3 天前
楼主这么可爱,你造么?
回复 支持 反对

使用道具 举报

uonpzf591 发表于 前天 00:38
火前留名,前排占座,此楼出租,欢迎议价。
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表