问题标签 [innovation]

我在一个同时具有 GUI（图形）和 API（脚本）界面的应用程序上工作。我们的产品拥有非常庞大的安装基础。许多客户投入了大量时间和精力来编写使用我们产品的脚本。

在我们所有的设计和实现中，我们（可以理解）对保持 100%向后兼容性有非常严格的要求。当我们引入新的软件版本时，之前运行的脚本必须继续以完全相同的方式运行，无需任何修改。

不幸的是，这个要求有时会束缚我们的双手，因为它确实限制了我们创新和想出新的更好的做事方式的能力。

例如，我们可能会想出一种更好（并且更有用）的方法来完成已经可能完成的任务。最好将这种更好的方式设为默认方式，但我们不能这样做，因为它可能具有向后兼容性的含义。所以我们坚持将新的（更好的）方式作为一种模式，用户必须“打开”才能使用它。除非他们阅读文档或在线帮助（许多客户不这样做），否则此新功能将永远隐藏。

我知道 Windows Vista 刚问世时惹恼了很多人，因为所有的软件和外围设备都无法在它上面运行，即使它们在 XP 上运行也是如此。因此，它收到了非常糟糕的接待。但你可以看到，微软也成功地在 Vista 中进行了一些伟大的创新，但代价是为许多用户提供了向后兼容性。他们冒险了。它得到回报了吗？他们做出了正确的决定吗？我想只有时间会证明一切。

您是否发现自己在创新和向后兼容性的冲突需求之间取得平衡？你如何处理杂耍表演？

关系数据库的 SQL 实现以目前的形式已经存在了大约 25 年（自 System R 和 Ingres 以来）。甚至主要（松散地遵守）标准是 ANSI-92（尽管后来有更新）也有 15 年的历史。

在过去十年左右的时间里，您能想到基于 SQL 的数据库有哪些创新。我特别排除了 OLAP、列式和其他非关系（或至少非 SQL）创新。我还想排除“应用程序服务器”类型的功能和捆绑（如报告工具）

尽管基本方法仍然相当静态，但我可以想到：

• 可用性
• 能够处理更大的数据集
• 易于维护和配置
• 支持更高级的数据类型（blob、xml、unicode 等）

还有其他你能想到的吗？

几年前曾引用艾伦·凯的话说，在过去的 20 年里，软件中只有三个新事物（实际上是 PC 的生命周期）。其中之一是电子表格。

有人记得另外两个吗？

艾伦·凯是谁？（有些人可能会问。）他在 Xerox Parc 的工作可以说比其他任何影响都更能塑造我们当前的软件范式。

这个问题源于对过去 50 年左右计算领域不同类型进步的评论。

其他一些参与者要求我向整个论坛提出这个问题。

这里的基本思想不是抨击事物的当前状态，而是试图了解提出基本新思想和原则的进展情况。

我声称我们在大多数计算领域都需要真正的新想法，我想知道最近已经完成的任何重要且强大的想法。如果我们真的找不到它们，那么我们应该问“为什么？” 和“我们应该做什么？”

在我看来，在某些方面，Java 是 C 很久以前的地方。两者在当时都是相当简约的语言，具有相对干净、简单的核心构建。（我指的是这里的核心语言，而不是库。）两者都非常流行。两者都是/曾经是通用语，具有大量遗留代码。两者都缺乏其他语言的程序员经常错过的几个现代生产力功能。两者似乎都非常惯性主导，并且适应不断变化的世界的速度很慢。

在我看来，创建一个大致是 Java 超集的 Java++ 是合理的，就像 C++ 之于 C 一样。这种语言会试图让 Java 摆脱它所经历的相对停滞，只在少数情况下破坏向后兼容性仅在绝对必要的情况下使用次要方法，添加许多普通旧 Java 所缺少的现代特性，并担心以后的标准化。可能是个好主意的功能包括：

1. 一流的功能，代表。
2. 关闭。
3. 静态类型推断，类似于varC# 或autoD 中的类型。
4. 运算符重载。
5. 结构体作为不同于类的值类型，如 C# 和 D。
6. 特性。
7. 忽略检查异常的选项。
8. 在一个文件中声明多个顶级公共类的能力。
9. 更强大的内置数组，允许追加之类的东西。
10. 更好的泛型/真实模板。
11. 类似于 C# 4.0 的动态关键字，它允许在必要时以一般静态语言进行鸭式输入。
12. 由于 Java 主要是一种 VM 语言，因此可能有一些核心元编程功能，例如为某些事情动态生成代码。

你认为这种语言会有需求吗？你认为这样的事情会成功吗？

编辑：我不是在谈论运行时/字节码级别的兼容性，而是在源代码级别谈论与 Java 的兼容性。此外，是的，Java 7 可以添加其中的一些，但似乎为 Java 添加功能的“官方”过程非常保守。真正的重点是将Java分叉成一个分支的想法，重点是创新而不是稳定性/标准化。

.NET 3.5、.NET 4.0、WPF、Silverlight、ASP.NET MVC - 这些天真的有很多新的微软技术发布/即将试用。（我给出的例子都是微软的技术，但这可以适用于任何语言或平台）。我很好奇你工作的公司是如何处理这个问题的。几个例子：

• 您是否有决定公司使用什么技术的 CTO？
• 开发团队可以自由选择他们使用的技术吗？例如：框架版本，经典的 ASP.NET vs ASP.NET MVC，ADO.NET Entity Framework vs Linq2Sql 还是 NHibernate？还是这些的混合？
• 您所在的公司尝试了哪些新技术，为什么？
• 您的公司是否有专门的资源（时间）来尝试 WPF 或任何技术，只是为了研究，或者您是否在业余时间尝试并尝试将它们介绍给您的公司？

这些只是让我的问题更清楚的例子。总而言之，我想知道这个过程是什么样的，谁负责，谁做决定。贵公司是跟风，还是不愿意尝试新技术？您对这种情况感到满意吗？

在我工作的公司，我们仍然使用 .NET 2.0（尽管我们现在正在慢慢切换到 .NET 3.5），还没有认真研究过 ASP.NET MVC，根本没有尝试过 WPF，等等。而且，有些人发现很难说服人们这样做。否则是否公平？

如今，创新似乎是一个流行词。每个组织都非常重视它，同时它也成为最辱骂的词。每一个新事物都不是创新。在我的组织中，也开始推动创新文化以及我如何参与其中。

我想知道您如何促进创新文化。是否有一些经过验证的方式促使人们以这种方式思考。我正在寻找一个答案，告诉我如何激励人们并给他们一些方向，以便他们扩展他们的想象力并提出新的想法。

通常，约定是用户界面最重要的设计考虑因素之一。通常建议会像微软那样去做。

这是出于三个原因：

1. 如果它没有坏，就不要修理它。
2. 如果您的用户希望单击软盘图标进行保存，请不要更改图标（即使他们中的一些人可能从未见过真正的软盘）。
3. 用户不想用他们使用的每个不同的应用程序重新学习界面（和热键等）。

同时，Emmerson 说：“*愚蠢的一致性是小脑袋里的妖精。*”那么，什么时候保持一致的用户界面会从一个好主意跨越到停滞的创新呢？

微软通过引入工具栏来改变旧的WIMP GUI，然后再次使用功能区控件（这是工具栏的自然演变，不管喜欢与否。）现在我们到处都可以看到功能区。

所以我的问题是，有哪些用户界面范式在多个应用程序中被接受并保持一致，但已经过了鼎盛时期并开始发臭？是否有一些重要的变化会受益于开发人员推动的基层推动，以创新和改善我们用户的用户界面体验？

我想到的一个想法是模态弹出对话框。你知道那些说：“你确定你想要...... - [是] [否] [取消] [也许]”和它的邪恶双胞胎“成功完成了你想做的事情！[OK]。” 我们看到浏览器中的“信息面板”正在远离这些。我认为它们也需要在 Windows 应用程序开发中采用。

如果可能，请为每个陈旧的 UI 项目列出一个解决方案。

并且请不要列出剪辑。我们都知道他是个坏主意。

注意：这是专门的 Windows 客户端用户界面范例，但我当然愿意从 Web、Mac 等中汲取灵感。

各位，

我刚刚阅读了这篇关于执行 XSS 的非常讨厌（同时也很酷）的方法的帖子。但是，我仍然有一些不清楚的地方。

我了解攻击的完整概念，但是，我不知道如何潜在地利用它。表单中的“action”属性必须指向一个 ftp 服务器（或任何其他反映输入的服务器），但事实并非如此。

因此，除非您有另一个 XSS 漏洞来注入这种形式，否则无法利用此漏洞。我的问题是，如果我认为它不能被利用的结论是真的，还是我错过了什么？

传统的版本控制系统通过将 Projects->Folders->Files 分组来显示版本信息，左侧是 Tree 视图，右侧是 details 视图，然后您将单击每个项目以查看该配置历史的修订历史。

假设我从面向对象模型的角度（例如类 -> 方法 -> 参数等）拥有项目可用的所有历史版本信息，您认为在 UI 中呈现此类信息的最有效方式是什么？您可以轻松导航和访问项目的快照视图以及历史版本信息？将自己置于您每天在工作中使用此类工具的位置，就像您当前使用 SVN、SS、Perforce 或任何 VCS 系统一样，这将有助于该工具的可用性、生产力和有效性。

我个人发现像上面这样显示文件夹和文件的经典方式对显示深度嵌套的逻辑模型非常有限制，而且效率较低。假设这是一个新建项目并且不受特定技术的限制，您认为我应该如何最好地解决这个问题？

我在这里寻找想法和意见，为我的研究项目增加价值。随意提出任何您认为有价值的建议。再次感谢任何分享他们想法的人。

编辑：为了提供更多信息，一个平均配置项，采取一个方法将嵌套在大约 6 个级别（项目->程序集->模块->命名空间->类型->方法，以及更多级别以导航到其中的子项) 并且情况始终如此，不像在文件夹文件结构中偶尔在某些项目中具有深层嵌套结构。当您有那么多级别时，树窗格将无法导航。恕我直言，树窗格在这种情况下也不太有效地呈现系统的整体结构。