如何向普通用户解释“实例”的概念

时间:2011-08-01 06:06:50

标签: usability instance user-experience

我正在创建一个用户可以创建卡片和卡片组的应用程序。

他们可以做的一件事是创建一张卡片并在套牌中共享它的一个实例。因此,如果他们修改此卡,所有套牌中的所有实例也将被更改。这在我的应用程序中非常有用,但它可能会让用户感到惊讶,所以我想以一种简单的方式解释这一点。

你会如何解释这个?作为程序员,我们都知道什么是实例,但是熟悉这个概念的普通用户呢?我应该使用“实例”这个词还是有一个用户更熟悉的等效词?

6 个答案:

答案 0 :(得分:3)

我不认为“实例”是一个完全可怕的术语,但也许是另一种解释它的方式:

  

您创建的每张卡都是唯一的。无论您添加多少套牌   卡到,只存在一个实际副本。在任何一个修改卡   deck将导致相同的更新自动出现在每个   其他牌组包括同一张牌。

......或者一些不那么冗长的变化。

答案 1 :(得分:1)

你可以为这些卡创造一些词。简而言之,“MAdeCards”的变化属性随处可见。并避免使用“实例”这个词。

答案 2 :(得分:0)

我会以另一种方式看待它,并将实例称为“卡片”。然后可以将“模板”或“类”称为“卡片类型”。

答案 3 :(得分:0)

告诉他们关于OOP的等级部分怎么样?一张牌有一个父亲和一个母亲,因为它的左右指针。一张牌可以有孩子(再次是它的左右指针)。最有可能的是,主卡的每个孩子都有他的共同属性。主卡的一个突出属性是唯一属性。如果主卡被修改,所有的孩子都会以同样的方式被修改而没有任何延迟吗?

答案 4 :(得分:0)

我打算买一部新手机(手机)。还是一辆车。

那是一堂课:

  • 目前假设
  • 还没有使用
  • 无状态(例如,没有电池充电或不知道水箱中会有什么燃料)

我买了一辆新的Samsumg或奥迪。那是一个实例。

  • 我可以玩它(“实例化”)
  • 我可以衡量一些事情,例如电池充电等(“状态”)

非技术人员不关心我们的日常概念,所以甚至不要使用“Instance”或许

在现实世界中,一张卡不会在几个套牌中,更不用说所有套牌了。乍一看,你的模型对我来说没有意义......

答案 5 :(得分:0)

可以使用“编辑主卡”替换实例,也可以在链接/按钮旁边提供文本帮助“注意:修改将反映在所有现有的卡片中”。希望您能够将内容改写为“目标用户”想要的方式。您需要通过按钮和帮助文本向目标用户查看这些信息是否被他们很好地接收,或者询问他们建议他们以何种方式更容易地对其进行重新定义,然后合并响应并得出结论。