为什么称“启用情形”为交互的最后防线？因为某些奇奇怪怪的需求往往没有现成的逻辑可以使用，这时候往往需要使用启用情形来做判定和交互,如果启用情形配合变量函数交互还是满足不了，那可能这个需求Axure目前无法实现。个人看法，启用情形可以说是Axure交互系统中最为“复杂”的一块，倒不是因为其具体操作步骤复杂，而是因为“何时用？”“该不该用？”“用到什么地步？”这三连灵魂拷问。有时一种需求可以通过多种方式实现，而使用启用情形进行判定的交互往往是其中最为麻烦的一种（每种情形下都要重复写一遍类似逻辑啊！）因而我在使用“启用情形”这一功能时往往本着“巧用”，“慎用”，“不得不用在用”作为使用原则。
（⬇️图文无关）
令人窒息的启用情形
在原型制作中，出现像上图这种令人窒息的交互逻辑一般是因为功能的耦合度过高，即在进行一个元件的操作同时，还要分别实现另一个或者另几个元件的不同动作。或者，我在进行这个操作的同时会影响到全局变量，亦或是这个启用情形需要根据全局变量来判断是否启用。
通常来说，使用启用情形这种并非我主动选择，而是需求让我不得不使用相对麻烦的启用情形。再举个简单的例子：比如我做了一个类似微信的即时聊天软件的原型，其中有一个需求就是我们点击聊天列表时，弹出新的聊天窗口并且出现对应的好友头像、名字和列表中的聊天内容。下面借着这个需求稍稍偏题地讲多一点：
实现方法1（分别建立页面）
首先我们来分析一下这个需求，实现的方法有很多种。最简单的实现逻辑就是每个用户新建一个有该用户的头像、名字、聊天内容的聊天窗口页面，并在每个用户的聊天列表单元中写入交互逻辑，点击时打开其对应的聊天窗口页面。那么问题来了，当仅仅两三个用户作为展示时尚且可以如此制作，如果列表中有十几个用户呢？难道要对应在做十几个页面吗？如果这个聊天列表能够动态增加，那么我们又无法动态增加其对应的聊天窗口了。
实现方法2（默认隐藏点击根据启用情形再不同显示）
第二种方式就是我不愿意使用的启用情形方式了。这种方式可以只建立一个聊天窗口页面即可，然后分别填写所有用户的头像、名字、聊天内容并设置为隐藏。当用户点击聊天列表时我们设置一个全局变量并将该用户名赋给全局变量。之后根据这个变量我们在聊天窗口页面中设置启用场景，分别填写逻辑：页面载入时——启用情形 if 全局变量=“A用户”，设置“A用户的头像”为显示，设置“A用户的用户名”为显示，设置“A用户的聊天记录”为显示；B、C、D……用户同理。这样我们就只需要新建一个聊天窗口页面并根据启用情形显示对应内容即可。
刚才这种方法也有其相对的弊端，我们虽然只做了一个聊天窗口页面，但是我们还是将所有的信息，包括头像、名字、聊天内容像做千层饼一样的叠在了一起。而且最难受的是有多少个好友我们就需要填写多少遍启用情形。有没有更为简单的方法呢？
当然，这就是第三种方法——使用中继器。我们新建一个聊天窗口页面，然后使用一个中继器，排布好头像、名字、聊天内容的位置，并将用户的头像、名字、聊天内容分别填写到中继器表格的三列中，填写完内容之后我们设置交互，设置中继器载入时在头像、名字、聊天内容中加载对应的列名。最重要的一步来了，我们要在内容加载后设置一个中继器的筛选功能，筛选条件以一个我们设置的全局变量为准，之后我们在聊天列表页面中点击聊天单元时将用户名赋值给这个全局变量。通过这一系列的操作，我们既能借助中继器快速地将内容填写到聊天窗口页面中，同时也可以利用一个全局变量和筛选功能实现在点击聊天列表时，新建的聊天窗口页面中显示对应的内容。（这个案例我暂时先不附图片了，后面有时间可能会出详细的实战版教程）。
通过这一个需求的三种实现方式，我们可以看出启用情形在使用时并不会使交互的编写变得简单快捷。而是当且仅当用其他方案显得有点“走投无路”时，启用情形作为最后的防线能够让我们至少可以先以不怎么优雅的方式实现需求。我这里只表述了启用情形在某些时刻的弊端，当然不能否认启用情形还是有很多相对基础且实用的使用方式，在很多教程中有非常详细的说明，有需要朋友可以搜索、查阅。
至此，前两章的内容终于完结了，顺便把目录贴在下面吧，第三章教程可能会出的比较慢，还请理解。
——————————————————文章目录——————————————————
Chapter 1
开始前的准备
Chapter 2
开始做吧,初学时懵逼的问题：
Chapter3
实战教程，未完待续...
网友评论