將 Scapple 嵌入 Scrivener

這個想法乍聽起來非常诱人，但其背後存在兩個根本性的難題：

1. 將一個程式嵌入另一個程式會極大增加復雜性。更不用說 Scrivener 本身已經是一個功能非常豐富的程式。想想 Scapple 中所有的選單命令和鍵盤快捷鍵——它們在 Scrivener 的使用者介面中該放在哪裡？要么會大大膨胀選單项的數量，要么 Scapple 組件本身必須被精簡到幾乎去掉所有高级功能，那它就會失去幾乎所有使其獨特的特質，變成某種類似於 Scrivener 中已有功能的東西——即自由形式的索引卡模式。
2. 更重要的是，這兩個程式使用的資訊模型存在根本性的差異。Scrivener 基於嚴格的大纲模型，活頁夾中的每個專案都必須有且僅有一個父级專案，並且這些專案按線性順序排列。而 Scapple 則完全沒有線性順序或嵌套層级的概念。將一個筆記向左上方拖動，在 Scrivener 的大纲中應該對應到什么位置？這正是 Scapple 與更常見的"思维導图"軟體的區別所在——思维導图確實使用了可以表達為大纲的層级結構，而 Scapple 不要求筆記之間必須有連接關係，還允許創建不產生邏輯序列的連接，比如一圈首尾相連的筆記，偶尔還有從環外切入的連結。這種結構在 Scapple 中創建轻而易舉，但對於基於大纲的程式來說，它是一種完全無法理解的"形狀"。

簡而言之，將 Scapple 嵌入 Scrivener 要么需要一方或双方程式在其設計目標上做出妥协，要么只能提供一種非常松散的"整合"诠釋，以至於它們不如繼续保持獨立——這樣每個程式都能擁有完整的選單和快捷鍵服務。因此，這個請求幾乎可以確定不會實現。