Що сталося з Уніфікованою файловою моделлю Алана Купера?

13

Протягом тривалого часу Алан Купер (у 3-х версіях книги "Про обличчя") просував "єдину модель файлів", щоб, крім усього іншого, не обійтися тим, що він називає найбільш ідіотичним полем повідомлень, коли-небудь винайденим - тим, що з'являється при натисканні кнопки закриття програми або форми, що говорить "Хочете відмінити свої зміни?" Мені подобається ідея та його аргументи, але також маю різку реакцію проти неї, яку мають більшість досвідчених програмістів та користувачів.

Хоча книга Купера здається досить популярною і шанованою, в Інтернеті є надзвичайно мало обговорення цього конкретного питання, яке я можу знайти. Петр Гессельберг, автор програми "Вікна програмування міцності" згадує про це, але це здається на це.

У мене є можливість реалізувати це в (настільному) проекті, над яким я працюю, але зіткнувся з опором клієнтів та колег, які, звичайно, знайомі з способом виконання MS Word та Excel. Я маю змогу перекрити їхні заперечення, але не впевнений, чи варто.

Мої запитання:

Чи є якісь хороші дискусії з цього питання, які я не зміг знайти? Хтось робить це у своїх додатках? Це гарна ідея, яку, на жаль, практично не втілити в життя, поки, скажімо, Microsoft це не зробить?

design programming-practices

— ПАУЛ Мансур
джерело

2

Google Docs використовує "уніфіковану модель файлу". Ще існує кнопка збереження, але насправді це плацебо: кожен раз, коли ви вносите зміни, файл "зберігається". Звичайно, Google Docs також має дуже надійну модель "історії", де ви можете повернутися до будь-якої попередньої версії, яка вам подобається.

— Дін Хардінг

Дякую всім за відповіді. Особливо ElGringoGrande та Berin Loritsch. Я вибрав Беріна лише тому, що він здався трохи повнішим. Я все ще замислююся про напрямок, який потрібно взяти.

— ПАУЛ Мансур

5

Придатність Єдиної файлової системи дійсно залежить від програми. Такі речі, як веб-програми, Microsoft OneNote та програми iOS, піддаються цій моделі. Коли програма керується базою даних, вона також піддається цій моделі. Однак я також можу подумати про сфери, де це не найкращий варіант. Зокрема, коли програма може споживати дані, які не надходили з цієї програми, вам потрібна концепція файлової системи, щоб знайти інформацію.

Що стосується збереження пам’яті та диска синхронізовано, я хочу цього, але я не для свого текстового процесора. Якщо я знайшов час для збереження свого файлу, я, можливо, захочу переконатися, що я не втрачаю жодної інформації. Про це потрібно подбати за допомогою функції автоматичного збереження, яку ми мали вже кілька років. Якщо хтось відключиться від шнура живлення, я можу принаймні трохи повернути його. Однак я створюю декілька викинутих документів, я не хочу засмічувати свою файлову систему. Знак, який буде використовуватися лише протягом одного дня, розігруючись із зразками шрифту тощо.

Відповідь "це залежить". UFS Cooper корисний в одних випадках, а в інших - менше. Технічна кмітливість ваших користувачів також може враховувати ваше рішення щодо цього. Більшість із нас виросли із статусом-кво, а іноді переваги змін не перевищують вартість змін. Я оцінюю відповідність такого підходу у вашій програмі.

— Берін Лорич
джерело

7

Microsoft робить це в OneNote.

Я б не перекривав бажання користувачів. Ми думали про те, щоб реалізувати це, але дізнаємось, що багато користувачів роблять речі, не замислюючись, і скористаються кнопкою закриття форми (або ctrl-alt-del, якщо такої немає), щоб запобігти їх врятуванню.

Якщо ви могли б реалізувати це таким чином, що дозволяє їм повернутися до попереднього сеансу (велика кількість скасування), то це може бути прийнятним. Але люди створені для того, щоб скористатися оточенням навколо них. Змініть навколишнє середовище, і ви ризикуєте знищити перевагу, яку вони виявили.

— ElGringoGrande
джерело

1

І надання скасування того, що пересічені лінії сеансу можуть викликати власні проблеми. Скільки людей починають листи, кажучи, що вони думають, а потім закінчують, роблячи це дипломатичним? Вам знадобиться окрема функція експорту.

— Девід Торнлі

+1, особливо для останнього абзацу. Не перезаписуйте попередній вміст під час збереження, але додайте нову "версію", зберігаючи старі версії недоторканими. Щоб заощадити місце, ви можете мати декілька версій спільного (незмінного) даних.

— Joey Adams

1

@David: це хороший приклад того, що дійсно потрібно команду "опублікувати", а не команду "зберегти нову версію в потоці версій".

— Алекс Фейнман

1

@Alex: Саме так - за винятком того, що більшість людей не піде шукати команди "опублікувати" чи "експортувати". Зрештою, різниці не відразу видно, і вони звикли просто надсилати остаточну версію файлу.

— Девід Торнлі

Я погоджуюсь, що вам потрібно мати варіант "повернення до попередньої версії", якщо ви збираєтесь використовувати єдину модель - це фундаментально для цього. Насправді в моєму випадку всі дані (це специфічні для програми елементи, а не файли, але це все одно) знаходяться в СУБД, яка не дозволяє руйнувати оновлення, тому в мене зберігається будь-яка версія. Це одна з причин, що я навіть розглядаю уніфіковану модель, оскільки це вільна згадка про старі версії предмета.

— ПАУЛ Мансур

6

Єдина файлова система вже виграла!

Усі програми iOS * працюють таким чином. Немає "файлів", немає файлової системи, немає збереження, лише програми, які містять дані, до яких завжди можна повернутися, якщо не видалити їх. З огляду на те, що MacOS може потрапити до iOS якось, я б сказав, що модель напевно причепилася.

Веб-сайти також працюють таким чином - рідко ви зберігаєте документ, рідко переглядаєте набір документів, і дуже рідко ділитесь документами між веб-сайтами. Документи вбудовуються в сайт, як вбудовуються ці питання та відповіді в StackExchange.

Історично було кілька незручних спроб перенести це в Windows та Macs, і це відключило людей від ідеї. Але зміна на нову платформу, де ніхто не очікує існування файлового браузера, позбавило компаній повністю переходити.

(* Я не знаю з Android чи інших ОС телефону; можливо, і там.)

— Алекс Фейнман
джерело

2

Однак файлові системи існують (у значній частині) для відокремлення даних та інтерфейсів від програм та додатків. Є аргументи з обох сторін.

— Черга Jé

2

@ Алекс, за винятком того, що ви не можете обмінюватися інформацією між програмами. Файл збереження гри не може відкрити текстовий редактор на iOS, оскільки інша програма не має доступу до пісочної скриньки.

— Стівен Фурлані

@Stephen, це правда, і важливий аспект усунення файлової ментальної моделі. Якщо ви хочете переміщувати дані між додатками, вам слід вдатися до прямого обміну між додатками ("поділіться цим у Facebook!"), Або посередник може обидва говорити (як буфер обміну). Мене бентежить ваше "крім".

— Алекс Фейнман

Ви можете обмінюватися інформацією між програмами - iOS підтримує обробники файлів, а також передавати інформацію через обробники URL-адрес. Це робиться лише на рівні, коли користувачі з'єднують дані між додатками, не є посередником у процесі передачі.

— Kendall Helmstetter Gelner

1

@ Алекс, зачекайте, тому використання буфера обміну (тимчасового) посередника є прийнятним, але використання загальної файлової системи (постійної) - ні?

— Стівен Фурлані

1

Ви збираєтесь зберігати їхні дані у файлах чи в якійсь базі даних?

Якщо ви очікуєте, що вони матимуть фізичний доступ до файлів, тоді вам доведеться навчити їх, що ваші файли "особливі". У своїй сучасній ментальній моделі вони можуть копіювати, вставляти, перейменовувати та видаляти. Я впевнений, що деякі з них уже використовують перейменування як спосіб "версії" своїх даних (наприклад, resume2010.doc, SalesDataFromBob2.xls).

Якщо це база даних, я впевнений, що вони захочуть експортувати / імпортувати файли в якийсь момент.

— rperetti
джерело

0

Чи є чітко відображена для користувача опція «зберігати завжди», яку важко реалізувати?

— JeffO
джерело

1

Ні, це зовсім не важко здійснити. Але чи справді гарна ідея створити варіант та підтримати дві моделі тут? Я не думаю, що так. Я думаю, що краще вибрати один і дотримуватися його.

— ПАУЛ Мансур