针对应用开发者的几点建议

近日，Dzone网站上发布了一篇文章《Suggestions for App Developers》，针对应用开发者分享了一些开发经验，下面是该文的译文。 针对某一平台，进行了多年的应用开发，你一定积累了不少经验。这些经验对于刚涉足该领域的开发者将十分有用。本文将列举一些我在Windows Phone平台上的开发经验，希望对你有些帮助。 评审很重要 经过认真评审的应用往往优秀于那些虽有较好内在，但未经过较多评审的应用。 请用户参与评审 最初，我很犹豫是否应该邀请用户评审我的应用。毕竟，在使用应用的过程，他们需要花费时间来评审应用。一次，当我发布某个应用后，发现出现了大量的评审意见——或在网络媒体上或在Windows Phone应用商站上。评审数目稳步增加到20~30个。当发布新的更新后，其他评审意见又纷纷出现，但速度远远不如应用发布之初。为了对其有更好的掌握，我决定增加一个提示，每第5次更新时，邀请用户评审该应用。如果用户说“Yes”，应用将引导用户进入评审页面；如果用户选择“No”，应用就会继续执行。当下一个第5次更新发布后，同样的提示又会出现。 这时，你可能觉得该方法太“侵略性”了。如果你不想参与评审，可以不参与，但它仍旧工作着。评审的数据呈现指数级增长，几周之内，从100长到200，又到400。以前，收集100个评审则需要一年之久——由此可以看出一个简单的提示可以给你带来多大的价值。 注意特征蔓延（Feature-Creep） 伴随着产品的成长，你可能会收到一些反馈，用户希望增加更多的功能。首先要衡量该功能的权重，看是否有必要增加到应用中。比如，气象指示器确实有必要增加到你的播客播放器中吗？更危险的是，解决那些看起来似乎有助于应用要处理的问题，但又会导致程序膨胀的功能。你确实需要将每个云存储服务增加到你的文档编辑器中吗？可能不会。可能有的用户希望将Box、Dropbox、Amazon EC2、Google Drive整合其中，但因为你的应用针对Widows Phone平台，所有的Windows Phone用户都有一个微软帐号，所以他们本身需要获得的是SkyDrive——这可能才是你的目标。 简化、简化，再简化 如果用户需要依靠教程来使用你的应用，那你的产品就失败了。在桌面上，你可以假设用户有时间来熟悉你的产品，但在移动设备上这是不可能的。从你自己的角度来想——你愿意花费多少时间来学习一个应用？可能不会超过1分钟。如果一个游戏、应用过于复杂，那它被关闭、不再被访问的概率将会很高。为了防止这种情况，需要注意以下几点： 遵循平台设计法则，用户不必特意去适应你的应用。 不要使用小号字体。移动设备的屏幕大小有限，不要让用户在使用你的产品时显得很费力。 每个页面应该包含和应用相关的有限功能集，不要试图每个页面都包含应用的所有内容。 保持与用户间的联系 无论信与否，当你对那些提供反馈、评论的用户致谢时，他们会很兴奋。通过Email、Twitter，或其他社交网络与用户保持联系，你将获得一群忠实的用户，他们愿意测试你的产品，会更加开诚布公地公开应用中存在的错误及潜在的多余功能。很显然，这就需要你有一个经过大力宣传的交流渠道（如“关于页”）。所有的反馈未必都是好的，虽然你收到的一些Email、评论可能是用户对产品如何糟糕的吐嘈等，但你仍会获得大量让你印象深刻的好主意和测试案例。与用户保持联系，很有必要。 迅速迭代 没有任何一款产品在发布时就能做到十全十美。保证对反馈迅速做出反映，并尽可能快地修改、增加功能。拥有一款维护良好的产品可以让用户更加信任你，同时也提高了用户体验。 星巴克咖啡谬论 我经常注意到开发者抱怨，为什么用户宁愿每天发5美元买一杯咖啡，也不愿意在应用上花0.99美元呢。核心问题是，当买了一杯星巴克卡布奇诺后，你肯定还会在其他星巴克咖啡馆购买卡布奇诺，但对于一个应用，却不太一样。作为开发者，你可能会说：“我们应用很不错，你会喜欢它的”，但如果用户不喜欢又会怎样呢？应用购买后就会永远属于用户，即便价格并不高。一旦被某事物牵绊住，下次再购买此类产品或项目时，用户就会再三考虑。这正是需要评审的地方，以吸引更多的新客户为你的努力进行投资。