Comments 27
Получается, в вашей реализации пользователь не может сделать Undo действиям другого пользователя?
А если Николай весь день писал документацию к проекту, а вечером Геннадий зашёл в этот документ и удалил весь текст, то Николай не может сделать Undo этой операции?
Мне кажется более естественным, если действия всех пользователей складываются в один стек и Undo отменяет последнее по времени действие независимо от того, кто это действие совершил.
А если Николай весь день писал документацию к проекту, а вечером Геннадий зашёл в этот документ и удалил весь текст, то Николай не может сделать Undo этой операции?
Мне кажется более естественным, если действия всех пользователей складываются в один стек и Undo отменяет последнее по времени действие независимо от того, кто это действие совершил.
Заминка в редактировании разных абзацев или страниц. Вы хотите отменить свой абзац, но вы хотите сначала грохнуть абзац коллеги.
Так делать точно нельзя, иначе, ошибившись в слове на 10ой странице, я отменю действия другого на первой, даже не зная об этом. Если Вы дали Геннадию доступ на редактирование документа, то должны понимать, что он может все удалить
Я вот одного не понимаю, почему бы в универе не учить git, почему бы не засунуть поддержку гита, маны, зачем все эти костыли? Имхо не стоить строить велосипед, если нет действительно важной причины его строить.
То есть read uncommitted и read committed…
А что Redo?
А что Redo?
/me думает… 37% complete
Возможно ли представить док как цепочку токенов (предложений и фигур), внутри которых undo/redo stream будет общим? То есть владельцем потока действий будет фраза, а не люди?
В таком случае, конечно, надо придумать как сделать ctrl-z до разборки компа, ведь неочевидно какой токен имеет «хронологически предыдущий» токен, что делать при уничтожении или перемещении токена.
Но Ctrl-Z для «деинсталляции Винды и разборки компа» редко используется, поэтому на таком уровне логики может прокатить. И может оказаться интуитивным — будет предельно ясно как работать с конфликтом внутри одного предложения.
Возможно ли представить док как цепочку токенов (предложений и фигур), внутри которых undo/redo stream будет общим? То есть владельцем потока действий будет фраза, а не люди?
В таком случае, конечно, надо придумать как сделать ctrl-z до разборки компа, ведь неочевидно какой токен имеет «хронологически предыдущий» токен, что делать при уничтожении или перемещении токена.
Но Ctrl-Z для «деинсталляции Винды и разборки компа» редко используется, поэтому на таком уровне логики может прокатить. И может оказаться интуитивным — будет предельно ясно как работать с конфликтом внутри одного предложения.
Redo пока нет.
На самом деле у вас всё сделано примерно как было сделано в Google Docs — много лет назад. До того, как они получили гордую приставку Google.
А потом, после нескольких лет возни, всё это было выкинуто и заменено тем, что есть сейчас. Потому что рассказы про «Это не недостатки нашей реализации undo. Оно работает правильно.» пользователями не воспринимаются. Если я не могу открыть документ и нажав несколько раз Undo получить то, что в нём было вчера — то что это за «Undo» такое?
Посмотрим как ваши пользователи к этому отнесутся…
А потом, после нескольких лет возни, всё это было выкинуто и заменено тем, что есть сейчас. Потому что рассказы про «Это не недостатки нашей реализации undo. Оно работает правильно.» пользователями не воспринимаются. Если я не могу открыть документ и нажав несколько раз Undo получить то, что в нём было вчера — то что это за «Undo» такое?
Посмотрим как ваши пользователи к этому отнесутся…
На самом деле у всех слишком большое доверие названию Google. Поредактируйте совместно (двумя пользователями) документ в Гугл и поотменяйте одновременно. И посмотрите, как документ вернется в первоначальное состояние). И тогда наши разговоры может воспримутся чуть лучше.
Хотелось бы добавить по поводу Google. Все выше приведенные примеры на тему «недостатки нашей реализации», повторяются и сейчас в Google документах. Вы можете сами проверить это прямо сейчас. Т.е. в этом плане между нами и Google никакой разницы нет. Поэтому странно слышать про старую реализацию в Google Docs, поскольку у них в этом плане ничего не поменялось. Все эти проблемы, которые есть у нас, есть и у них.
Онлиофис — большие молодцы. Первое, чем молодцы — это качеством отображения и возможностью работы с гигантскими документами. Второе — совместным редактированием и остальными фичами порталов. Третье — тем, что постоянно продакшен делают и не боятся обкатывать продукт на клиентах, в отличие от распиаренного российского офиса, который в глаза-то толком мало кто видел из простых смертных. Развивайтесь, парни!
Прошу прощения, возможно уже есть такая реализация, но (прочитав комментарии, пришла мысль — делюсь)
Если есть история изменений документа (в виде визуального стека) у пользователей, то человек может попробовать сделать undo. Если при этом в стеке есть действия других пользователей, то отправляется запрос пользователям на разрешение этого undo. Все это верно, если затрагивается блок с общей информацией. Если блок создал и изменял один пользователю, то отмена будет без подтверждений.
Также по поводу:
А потом, после нескольких лет возни, всё это было выкинуто и заменено тем, что есть сейчас. Потому что рассказы про «Это не недостатки нашей реализации undo. Оно работает правильно.» пользователями не воспринимаются. Если я не могу открыть документ и нажав несколько раз Undo получить то, что в нём было вчера — то что это за «Undo» такое? ( пользователя khim)
Согласен, можно было бы добавить историю документа read-only. То есть можно откатить вид документа по истории внесения изменений (того же стека). При этом добавить возможность печати документа и, например копирования его, чтобы его можно было редактировать уже как отдельный документ.
И все это действительно отчасти начинает напоминать git...
Если есть история изменений документа (в виде визуального стека) у пользователей, то человек может попробовать сделать undo. Если при этом в стеке есть действия других пользователей, то отправляется запрос пользователям на разрешение этого undo. Все это верно, если затрагивается блок с общей информацией. Если блок создал и изменял один пользователю, то отмена будет без подтверждений.
С точки зрения интерфейса и взаимодействия пользователей так делать нежелательно. Почти все пользователи всегда уверены в изменениях, которые вносят сами, и если им придет предложение «Разрешить внести изменения в свои правки ради Undo у другого пользователя», то мы почти уверены, что в 99% случаев все будут запрещать это делать и Undo как такового не будет вообще. Кроме этого, такое поведение сильно усложняет совместный набор документа.
Согласен, можно было бы добавить историю документа read-only. То есть можно откатить вид документа по истории внесения изменений (того же стека). При этом добавить возможность печати документа и, например копирования его, чтобы его можно было редактировать уже как отдельный документ.
История версий у нас есть.
UFO just landed and posted this here
В некотором смысле да. Отдельные части документа, представленные в виде массивов, у нас смоделированы по схеме CmRDT, т.е. по коммутативному варианту, когда другим пользователям мы не пересылаем целиком состояние всего массива, а только изменения связанные с ним, и этим изменения мы коммутируем между собой, чтобы у всех пользователей состояния этих массивов были идентичны.
В примере с неоткатываемыми действиями, Николай первой отменой сделал что?
Отменил вставку символа, которого уже нет. То есть никак не модифицировал документ.
Получилась отмена Шрёдингера.
Её можно было бы оставить в стеке, а после отмены действия Геннадия, сделать доступной.
Отменил вставку символа, которого уже нет. То есть никак не модифицировал документ.
Получилась отмена Шрёдингера.
Её можно было бы оставить в стеке, а после отмены действия Геннадия, сделать доступной.
Во-первых, здесь приведен сильно упрощенный случай из возможных. Хорошо, когда все изменения между собой не связаны, а если бы это изменение, связанное с другим, то так как вы предлагаете сделать уже нельзя. Другими словами, из блока своих действий вырывать какие-то действия и не делать к ним Undo — неправильно, и может привести к еще более худшим последствиям.
Во-вторых, как это будет выглядеть для первого пользователя? Вот он откатил все свои действия до конца (кнопка Undo неактивна), и тут неожиданно после действий другого пользователя его кнопка Undo станет снова активной. Так неправильно, он же ничего не делал, значит и кнопка Undo не должна становится активной для него.
Во-вторых, как это будет выглядеть для первого пользователя? Вот он откатил все свои действия до конца (кнопка Undo неактивна), и тут неожиданно после действий другого пользователя его кнопка Undo станет снова активной. Так неправильно, он же ничего не делал, значит и кнопка Undo не должна становится активной для него.
Во-вторых, как это будет выглядеть для первого пользователя?
Он сделал два действия, но отменил только одно. Это произошло из-за конфликта с действиями другого пользователя. Если конфликт разрешился, то действия снова могут быть отменены.
Так неправильно, он же ничего не делал
В совместном редактировании документа. Значит он должен был учитывать, что на состояние влияют другие люди. Рассчитывать на другое, все равно что рассчитывать, что содержимое Интернета не изменится за ночь.
Он сделал два действия, но отменил только одно. Это произошло из-за конфликта с действиями другого пользователя. Если конфликт разрешился, то действия снова могут быть отменены.
Никакого конфликта нет. Он вводил текст и отменил свой ввод. Второй пользователь удалил текст и отменил удаление. При неправильном порядке Undo появляется удаленный текст. Это нормально, тут нет конфликтов, поэтому и нет смысла не давать пользователю не делать Undo. На самом деле ввод двух символов, хоть это и 2 разных действия, но можно их трактовать как одно (например, так делает Google Docs), и на ввод двух символов у вас будет ровно одно Undo, а не 2. В такой ситуации Undo запрещать нельзя, т.к. один из символов все еще есть в тексте.
В совместном редактировании документа. Значит он должен был учитывать, что на состояние влияют другие люди. Рассчитывать на другое, все равно что рассчитывать, что содержимое Интернета не изменится за ночь.
С такой логикой пенять на «неправильную» работу Undo вообще нет смысла. Т.к. пользователь жмет Undo и надеется увидеть предыдущее состояние, но в это время кто-то правит этот же кусок текста (возможно правки вносятся с помощью опять-таки Undo второго пользователя, но первому-то какая разница как) и предыдущего состояния первый пользователь не увидит уже никогда.
Sign up to leave a comment.
Всё не так просто с Ctrl+Z: об undo в быстром совместном редактировании ONLYOFFICE