Действительно актуальной работой занимаетесь. У нас в команде система управления знаниями играет ключевую роль а все остальное уже вокруг нее вертиться. Кстати было бы очень интересно получить фидбэек о нашем сервисе: живой вики в стиле фанак: rizzoma.com
Ну я не могу придумать немодального решения без собачки. Хотя может оно и есть.
По поводу других использований собачки. Если нужно набрать что-то потипу @ some place то просто ставиш пробел после собачки.
По поводу нажатий не знаю у меня в раскладке нормально наживается:) просто двойка с шифтом.
По поводу поругать согласен. То решение которое у нас работает сейчас мы тщательно оттестили на нашей альфа-версии odessa.projectvolna.com, вроде достаточно удобно получается. Вообще если есть идеи по тому как сделать этот интерфейс лучше то было бы очень интересно обсудить. Мы впринципе можем и все чертежи и макеты которые еще только в дальних планах показать.
То есть если после ввода имени возникает прерывание ввода и появлется форма с предложением подставить вместо имени конкретного адресата. Верно?
Для меня такой кейс кажется сомнительным, во-первых потому что что такое сообщение моет оказатся неожиданным, а во-вторых что если я например маркетолог/журналист и как обычно пишу в презентации/статье какуюнить чуш про стива джобса то программа будет постоянно предлагать заменить имя или фамилию стива на твоих друзей стивов. Что не хорошо. То же самое когда вводиш просто список людей.
Хотя может это и надуманные проблемы которые легко решаются какой-нить еще интерфейсной фичей и если я попробую то быстро привыкну к новому. Что-то подобное я даже на фэйсбуке видел, сервис предложил поставить вместо имени и фамиллии человека конкертного пользователя. Щас попробывал повторить эксперимент не получилось:)
> По-хорошему, компьютер должен самостоятельно определять по тексту и контексту, кому адресовано обращение в тексте, где заголовок, а где теги. Вот это действительно было бы круто.
Что касается выбора адресата то мне например проще ввести собачку и два символа имени. Нежели вводить имя и фамилию а еще хуже почту адресата целиком. Упаси боже вводить почту, это совсем лениво к тому же ее никогда не помню.
А что касается заголовка тут я согаласен. Мне нравится идея делать первую строку текста/сообщения заголовком. На практике она вроде хорошо тоже прижилась.
Тут еще очень важна разница между коллаборацией и заполнением форм в электронном магазине.
Если при покупке чего-то или заказе билета есть четкая последовтельность шагов которая достаточно постоянная.
При совместной работе с документом последовательность действий может быть самой разной. Документ проматывается то вверх то вниз. Комментарии по пять раз исправляются, и вообще коллаборция со стороны похожа на наус. Я помню свое первое ТЗ много лет назад. После каждой итерации я его распечатывал и скреплял с предыдущими версиями. В результате в докумкнтов стало два там был совмем другой текс и даже утверждади его не те же люди которые планировались вначале:)
Про таб мы помним конечно, но решили убрать этот момент из статьи так как подумали что он только усложняет. Видимо нужно вернуть, не подумали про контингент читателей.
С быстрым переходом между полями есть интересный момент связанный с тем что порядок заполнения полей бывает разным. Я например использую заметки в evernote для записей своих занятий по английскому. Обычно я начинают записывать в новой заметке когда преподаватель говорит что-то. При создании заметки эвернот всегда кидает на поле название, при первом нажатии таб китадет на заполнение тега и только пото на текст заметки. А мне как раз удобнее сначала писать текст заметки а потом только назвать ее и поставить теги.
Понял.
Сделать адресацию через @ в системе документооборота не так уж сложно на мой взгляд. Просто перехват события ввода символа в форме ввода делать. Делать это внутри рабочего документа (типо ms word) на порядок сложнее. Думаю можно попробывать ихней техподдержке написать. Интересно что они по этому поводу думают.
Понятно. Мне кажется можно будет о чем-то таком подумать, как для нашей системы, googledocs-ов или же zoho docs и прочих. Интересно понять ключевой сценарий.
Важна ли для вас такая функция как запрет доступа не в свою очередь? То есть когде человек получает доступ к документу только тогда когда натсупает его очередность. И теряет доступ когда его очередь прошла? Для нас такая функциональность представляет опеределненный вызов. Насколько я понимаю в директуме это в два щелчка реализуется.
Еще интересно часто ли бывают возвраты на предудущего участника процесса? И вообще изменение маршрута после его изначального планирования. Для случаев когда таких изменений много, быть может каждому участнику проще перебрасывать мячик ровно на один ход вперед и сами по себе маршруты являются излишним системным усложнением.
А с точки зрения типовых маршрутов я думаю можно будет стыковать систему подобную нашей с одной из BPMN систем, например BizAgy и тогда особой разницы не будет что согласеуеш. Просто ссылку передавать на тот же гуглодокс или на документ.
Да идея прикольная. Только насколько я знаю в этих СЭД дофига всяких хитроумных специализированных типов маршрутов, типо таких: Сначала директор департамента, потом один из экономистов, потом главбух и финик в любом порядке. — в общем всякие премудрости из последовательных, паралельных и альтернативных типов маршрутов.
Или же всякие такие заумные маршруты редко используются?
Еще интересно если вы сразу описываете кто, что и как должен сделать то значит видимо вы и есть тот самый руководитель, который описывает путь документа в начале пути. Действительно такое бывает?
У меня просто есть опыт внедрения систем документооборота (DocscVision) и стало очень интересно так как ничего подобного на практике не встречал.
Похоже на google wave, но сильно отличается.
Похоже на google wave, но сильно отличается.
Похоже на google wave, но сильно отличается.
Похоже на google wave, но сильно отличается.
Подробнее можно посмотреть в roadmap.
По поводу других использований собачки. Если нужно набрать что-то потипу @ some place то просто ставиш пробел после собачки.
По поводу нажатий не знаю у меня в раскладке нормально наживается:) просто двойка с шифтом.
По поводу поругать согласен. То решение которое у нас работает сейчас мы тщательно оттестили на нашей альфа-версии odessa.projectvolna.com, вроде достаточно удобно получается. Вообще если есть идеи по тому как сделать этот интерфейс лучше то было бы очень интересно обсудить. Мы впринципе можем и все чертежи и макеты которые еще только в дальних планах показать.
Для меня такой кейс кажется сомнительным, во-первых потому что что такое сообщение моет оказатся неожиданным, а во-вторых что если я например маркетолог/журналист и как обычно пишу в презентации/статье какуюнить чуш про стива джобса то программа будет постоянно предлагать заменить имя или фамилию стива на твоих друзей стивов. Что не хорошо. То же самое когда вводиш просто список людей.
Хотя может это и надуманные проблемы которые легко решаются какой-нить еще интерфейсной фичей и если я попробую то быстро привыкну к новому. Что-то подобное я даже на фэйсбуке видел, сервис предложил поставить вместо имени и фамиллии человека конкертного пользователя. Щас попробывал повторить эксперимент не получилось:)
Что касается выбора адресата то мне например проще ввести собачку и два символа имени. Нежели вводить имя и фамилию а еще хуже почту адресата целиком. Упаси боже вводить почту, это совсем лениво к тому же ее никогда не помню.
А что касается заголовка тут я согаласен. Мне нравится идея делать первую строку текста/сообщения заголовком. На практике она вроде хорошо тоже прижилась.
Если при покупке чего-то или заказе билета есть четкая последовтельность шагов которая достаточно постоянная.
При совместной работе с документом последовательность действий может быть самой разной. Документ проматывается то вверх то вниз. Комментарии по пять раз исправляются, и вообще коллаборция со стороны похожа на наус. Я помню свое первое ТЗ много лет назад. После каждой итерации я его распечатывал и скреплял с предыдущими версиями. В результате в докумкнтов стало два там был совмем другой текс и даже утверждади его не те же люди которые планировались вначале:)
С быстрым переходом между полями есть интересный момент связанный с тем что порядок заполнения полей бывает разным. Я например использую заметки в evernote для записей своих занятий по английскому. Обычно я начинают записывать в новой заметке когда преподаватель говорит что-то. При создании заметки эвернот всегда кидает на поле название, при первом нажатии таб китадет на заполнение тега и только пото на текст заметки. А мне как раз удобнее сначала писать текст заметки а потом только назвать ее и поставить теги.
Сделать адресацию через @ в системе документооборота не так уж сложно на мой взгляд. Просто перехват события ввода символа в форме ввода делать. Делать это внутри рабочего документа (типо ms word) на порядок сложнее. Думаю можно попробывать ихней техподдержке написать. Интересно что они по этому поводу думают.
Важна ли для вас такая функция как запрет доступа не в свою очередь? То есть когде человек получает доступ к документу только тогда когда натсупает его очередность. И теряет доступ когда его очередь прошла? Для нас такая функциональность представляет опеределненный вызов. Насколько я понимаю в директуме это в два щелчка реализуется.
Еще интересно часто ли бывают возвраты на предудущего участника процесса? И вообще изменение маршрута после его изначального планирования. Для случаев когда таких изменений много, быть может каждому участнику проще перебрасывать мячик ровно на один ход вперед и сами по себе маршруты являются излишним системным усложнением.
А с точки зрения типовых маршрутов я думаю можно будет стыковать систему подобную нашей с одной из BPMN систем, например BizAgy и тогда особой разницы не будет что согласеуеш. Просто ссылку передавать на тот же гуглодокс или на документ.
Или же всякие такие заумные маршруты редко используются?
Еще интересно если вы сразу описываете кто, что и как должен сделать то значит видимо вы и есть тот самый руководитель, который описывает путь документа в начале пути. Действительно такое бывает?
У меня просто есть опыт внедрения систем документооборота (DocscVision) и стало очень интересно так как ничего подобного на практике не встречал.