MS Access中的最终用户文档

Question

如何在Access中实现用户文档？我以前从未对正式的用户文档感到困扰;我倾向于依靠良好的界面设计来引导用户（或者我告诉自己）。但我真的很想知道比我更聪明的人......

以下是我认为我认为重要的事情（按顺序）：

1. 简单：它需要足够简单，以便在代码更改时可以轻松更新，否则文档将最终不同步
2. 屏幕截图：一张图片胜过千言万语;屏幕截图必须轻松集成到文档中
3. 集成：用户可以尽可能少地访问文档的相关部分;即，在表单上按F1会显示该表单的帮助，而不是打开帮助文件并且必须导航目录<​​/ li>
4. 可搜索：全文搜索功能很不错

其他考虑因素：

• 在线与本地：本地会更快/更可靠，但在线将始终可用，加上搜索引擎可索引（允许使用谷歌网站：搜索和提供一些SEO的好处也是如此）
• 用户可编辑：您允许用户对文档进行多少更改：完全访问权限（即wiki），无权访问权限，主持论坛等等。
• 版本控制：基于文本的格式更有利于版本控制，而不是在mdb中包含帮助文本的Access表
• 可导出为PDF ：看起来很不错

Answer 1

我没有为我的客户项目生成文档，除非客户支付给我很大的$$$，因为它非常困难。我经常指导用户制作记录程序和标准的内部材料，但总的来说，我设计的应用程序易于使用。

这与学习轻松相反。

易于使用和易于学习经常相互冲突，因为UI设计使得一旦用户习惯了工作原理，第一次执行任务变得非常容易。

但是，设计UI时需要考虑两件事：

1. 每天完成的事情不需要易于学习 - 对于已经知道如何使用应用程序的人来说，他们需要非常快速和友好。我有10 + 20规则 - 10分钟的训练和20分钟的使用，用户永远不会忘记如何使用它。

2. 完成的事情很少应该设计为透明且简单的UI，并且不需要用户记住任何内容。这些类型的任务是向导式界面的理想选择，可以引导用户完成整个过程，并在整个过程中提供文本提示和提示。

我还在应用程序中实现了许多UI设计约定。我想到的一个例子是，任何数据表或连续形式的子表单都有一个双击事件，激活后会打开一个弹出窗体，其中包含所选记录的完整详细信息。一旦用户掌握了这个约定，他们就会假设任何子表单都是双击的，以便导航到细节。

还有其他类似的约定，但这是基本的想法，即在类似的上下文中实现类似的行为，这样如果用户学会在一个上下文中做某事，当她发现自己在具有类似UI的不同地方时，在原始上下文中学到的东西在基本的UI行为方面是可转移的。

Answer 2

在Access中，我从未创建过最终用户文档。没等了，我大约12年前做过一次。我付钱给别人写手册和屏幕截图。我也有hlp文件等等。但我现在不记得细节了。

现在，对于Auto FE Updater，我有一个文本控件，它是underlned和blue，然后用户可以点击它。然后代码使用ShellExecute API将我们的Web浏览器打开到我网站上的相应页面对我来说比试图找出适用于离线和在线的某种帮助系统更简单。我还更新了ToolTip控件以输入确切的URL，以便他们可以看到如果他们点击文本控件他们将去哪里。这是一个VB 6程序，但足够接近你的要求。

Answer 3

您需要做两件事：

1. 使用所有主题的主题ID创建帮助文件
2. 将此帮助文件链接到您的访问数据库，并链接主题

http://www.helpandmanual.com/我们取得了非常好的成绩。从单一来源，您可以创建任何类型的帮助文件：pdf，online，chm，hlp，xml，...它集成了截图工具。

每个主题都可以拥有自己的ID，您只需将访问表单/控件链接到此ID即可。

Answer 4

我和Tony做了很相似的事情。它是一种用户生成的内容类型的东西让我解释一下。

• 数据库包含一个表格，其中包含表格名称列表，然后是与该表格对应的帮助文件（word doc）的路径。

• 某些用户可以访问表单，该表单允许他们说出每个表单对应的帮助文件

• 每个表单都有一个帮助按钮，因此当用户点击它时，它们会打开正确的帮助文件。

这种方式非常灵活，如果他们只想要一个大的帮助文件，那么所有的链接指向那个，但如果用户想要付出努力，那么他们就可以为每个文件创建一个文件。因为它们帮助文件与数据库存储分开不是问题，也可以帮助文件更改，而无需重新编译应用程序。

如果您愿意，可以将此想法与Tony's合并，并在线提供帮助文件。我发现这是一个很好的设计模式

Answer 5

您可能会发现HTML Help合适。

Answer 6

我最近偶然发现TiddlyWiki并且一直在考虑将其用作Kevin和Tony所描述的系统的后端。