Изменение парадигмы колонок

romka11 · Сообщение **romka11** » 06 апр 2020, 22:10

Суть:
Сделать поля(колонки) не фиксированными, а конфигурируемыми: наличие, смысл и тип определяется пользователем.
Это путь к гибкости и лаконичности.

Мой пример:
Было бы очень удобно иметь несколько колонок с типом "Select" (Единственное значение из пополняемого списка, как у колонки "Текстовый тег"), а так же колонку с типом "Text" исключительно для вставки кликабельной ссылки. В то же время, я абсолютно не пользуюсь половиной стандартных колонок.

Примеры других пользователей:
• Прилагал множественные попытки привить планировщик друзьям и коллегам. Все отказались из-за устрашающей сложности.
• У многих пользователей возникает недоумение, почему у задачи можно поставить две даты (Начало/Срок). Это нетривиальное явление для планировщиков общего назначения и не всем это нужно.
• У начинающих – ужас от перечня из 38 колонок и еще большего количества настроек на панели свойств, а у продвинутых – нужда в недостающих колонках, которая вынуждает постоянно выкручиваться.

Примеры реализации:
Мини-базы данных на листах сервиса Notion за 2 минуты превращаются в почти планировщик мечты – именно такой, какой нужен для любой конкретной ситуации:

Расшаренная страница Notion https://www.notion.so/127eb1e0b1bf47d09 ... d5ff6715cc

А "почти" – потому что все хранится на серверах у Безоса, десктоп-клиент на тормозном Electon-е, а также нельзя нормально работать с иерархией.

В Notion конкретное именование и назначение полей (=столбцов=колонок) определяется пользователем, при этом задается только их тип:

Код: Выделить всё

    Мета-типы            Типы
    ----------------------------------------------------------------------------------------------------------------
    Изменяемые           Text; Number; Select; Multi-Select; Date; Person; Files&Media; Checkbox; URL; Email; Phone
    Вычислимые           Formula; Relation; Rollup; CreatedTime; CreatedBy; LastEditedTime; LastEditedBy

Измышления по реализации в MLO:

Развернуть

• Мне не известно какой абстракцией сейчас представлена атомарная задача:
- или как запись в некоторой базе данных с фиксированным набором полей,
- или как объект некоторого класса ~<Task> с фиксированным набором свойств и собственным способом хранения,
- или с переводом из первого во второе при загрузке в RAM,
- или еще как-то.
Так или иначе, рациональным является хранение дескрипторов задач в виде базы данных, причем не обязательно реляционной, вполне достаточным представляется noSQL типа Key-Value.

• По сути сейчас, все свойства задач имеют следующие Мета-типы и Типы (даже если это явно не отражено в объектной модели приложения)

Код: Выделить всё

    Мета-типы            Примеры конкретных  свойств
    -----------------------------------------------------------------------------------------------
    Скрытые              GUID, иерархический дескриптор, массив флагов отображения значков и т.д. 
    Изменяемые           Заголовок, Даты, Флаги, Звезда и т.д. 
    Вычислимые           Процент выполнения, Счетчик зависимостей и т.д.
    Только для чтения    Дата создания, Дата изменения, Дата смены избранного и т.д.
    Действия             Кнопка "Обзор проведен"

Код: Выделить всё

    Типы                 Примеры конкретных  свойств
    -----------------------------------------------------------------------------------------------
    Bool                 Complete, IsProject, IsFolder, …
    Text                 Caption, Comment, …
    Num                  Importance, Urgency, BookmarkIndex, …
    DateTime             StartDateTime, DueDateTime, CreatedDateTime, …
    Select               ProjectStatus, Goal, TextTag
    MultiSelect          Contexts
    Pic                  Flag( Pic(Select[*]) ), Значки( Pic(Bool[n]) )
    Button               Кнопка "Обзор проведен"
    Struct               Recurrence, Обзор каждый
    LinkToObject         Используется для TopLevelFolderName, TopLevelProjectName, …

Эти типы и стоит предоставить на выбор пользователю при создании столбцов. Функционирование существующих профайлов с точки зрения пользователя не изменится.

• Поскольку текущий набор колонок сейчас у всех пользователей одинаковый, переход на новый формат будет беспроблемным. Для воссоздания текущего набора создается конфигурация MLO5standard.xml и включается в стандартный комплект поставки новой версии MLO. Далее пользователи изменяют набор на свое усмотрение

• Набор полей задается xml-конфигурацией, может быть экспортирован/импортирован в виде файла

• Компромиссным решением может быть просто возможность добавления пользовательских колонок и полное скрытие некоторых стандартных колонок в настройках профайла

• Если исключить избыточные типы Notion, то для воссоздания почти такой же гибкости, в MLO остается добавить только следующие типы: Формула(Вычислимое), КликабельнаяСсылка(Действия) и, может быть, Файл(новый мета-тип)

• Очень интересным представляется тип Аction(кнопка), при развитии которого можно автоматизировать рутинные задачи пользователя с помощью скриптового языка

.

Сообщение **WaRoX** » 07 апр 2020, 08:07

С одной стороны, тема пользовательских полей уже многократно обсуждалась на форуме, и навешивать функционал редактируемых баз данных на MLO будет очень тяжело...
С другой стороны, пользовательские поля - отличная фича для MLO 6, и первое время их можно вести независимо от мобильных версий.

А за ссылку на Notion спасибо! Выглядит как комбинация OneNote и кастомных баз данных (например, Memento Database)

justme · Сообщение **justme** » 09 апр 2020, 13:10

WaRoX писал(а):Источник цитаты С другой стороны, пользовательские поля - отличная фича для MLO 6

Было бы очень круто получить такой апгрейд МЛО

Сообщение **edw** » 15 апр 2020, 02:07

romka11 писал(а):Источник цитаты • Если исключить избыточные типы Notion, то для воссоздания почти такой же гибкости, в MLO остается добавить только следующие типы: Формула(Вычислимое), КликабельнаяСсылка(Действия) и, может быть, Файл(новый мета-тип)

+1
Отдельно плюсую кликабельную ссылку.В надежде увидеть её ещё в 5 версии. ))

romka11 писал(а):Источник цитаты• Поскольку текущий набор колонок сейчас у всех пользователей одинаковый, переход на новый формат будет беспроблемным. Для воссоздания текущего набора создается конфигурация MLO5standard.xml и включается в стандартный комплект поставки новой версии MLO. Далее пользователи изменяют набор на свое усмотрение

Правильгно ли я понимаю, что такая архитектура позволит мне отключить те поля задач, которые я не использую?
Отключить только в табличном виде или в принципе убрать их из интерфейса? Если последний вариант, то что тогда будет в окне Свойства задачи? Пустые места на том месте где сейчас те или иные параметры?

romka11 писал(а):Источник цитаты• Очень интересным представляется тип Аction(кнопка), при развитии которого можно автоматизировать рутинные задачи пользователя с помощью скриптового языка

Сегодня в десктоп-версии автоматизация предлагается через командную строку. Список операций (в файле помощи) достаточно беден.
Для iOS-версии предлагается использовать Быстрые команды. Тут возможностей больше. Но это фича Apple.
Действительно ли MLO нужен свой скриптовый язык? Есть ли какие-то технологии для Windows, которые позволяют настраивать MLO-скрипты во внешних приложениях? Что-то типа API для десктопа.

romka11 · Сообщение **romka11** » 15 апр 2020, 14:32

edw писал(а):Источник цитаты Правильгно ли я понимаю, что такая архитектура позволит мне отключить те поля задач, которые я не использую?Отключить только в табличном виде или в принципе убрать их из интерфейса?

Наличие какого-то свойства(поля) задачи влечет за собой множественное его проявление: отображение колонки, контрола в панели свойств, использование в фильтрах, группировках, сортировках, правилах автоформатирования, расчета оценки и т.д. Соответственно, если свойства нет, то и всего этого тоже нет, и интерфейс не захломляется.
На мой взгляд, интерфейс сейчас уже перегружен из-за стремления объять необъятное – добавить столько свойств описания задачи, чтобы хватило всем. А ведь все равно всем не хватит.

edw писал(а):Источник цитаты что тогда будет в окне Свойства задачи? Пустые места на том месте где сейчас те или иные параметры?

Формирование панели свойств уже сейчас реализовано динамически:
• Панель поделена на блоки "Срок", "Общие", "Проект" и т.д., которые можно скрывать(сворачивать) и передвигать
• Положение контролов в блоках тоже определяется динамически (можно заметить, если подвигать ширину панели свойств)
Соответственно, отображение/скрытие контролов так, чтобы не было пустот, не станет большой проблемой.

Набор и порядок контролов для отображения может формироваться динамически при загрузке ml-файла на основе набора используемых в нем свойств(полей) описания задач. Тип контролов определяется в зависимости от типа данных (стандартно CheckBox для Boolean, NumEdit для Numeric, TextEdit для String и т.д.)

Для формирования панели свойств возможны несколько путей, в зависимости от того, как именно изменится парадигма:
1. Полная свобода:
Контролы отображаются по порядку один за одним, в соответствии с дескриптором задачи (описания набора свойств(полей) задач для данного ml-файла). Можно отображать в две или более колонок, если ширина панели свойств позволят
2. Набор фиксированных свойств и возможность добавлять пользовательские:
Фиксированные свойства свойства отображаются фиксированно, как и сейчас, пользовательские свойства – в блоке "Пользовательские свойства"
В качестве развития можно и вовсе предоставить пользователю определять какие контролы отображаются и в каком порядке

edw писал(а):Источник цитаты Действительно ли MLO нужен свой скриптовый язык?

Это станет естественным шагом при создании API в рамках построения Web-версии. (Но как я понял, Web-версия пока не планируется)
В противном случае, это будет востребовано лишь среди гиков типа меня.

edw писал(а):Источник цитаты Есть ли какие-то технологии для Windows, которые позволяют настраивать MLO-скрипты во внешних приложениях? Что-то типа API для десктопа.

Сейчас для открытия задач по ссылкам и добавления задач в долгоживущие ветки(проекты) пользуюсь CLI(командная строка). Большего, к сожалению, функционал не позволяет.
Добавление же в CLI всего двух функций подняло бы его функциональность в десятки раз:
1. Поиск GUID задачи по значениям некоторых свойств
Представляю так:

Код: Выделить всё

MLO.exe myprofile.ml -GetGUID -caption="My task" -completed=false

2. Изменение некоторых свойств задач
Представляю так:

Код: Выделить всё

MLO.exe myprofile.ml -console -task={D1621AAC-DB59-4E20-9F3B-B229ACC7165D} -SetProperties -caption="New name"
MLO.exe myprofile.ml -console -task={D1621AAC-DB59-4E20-9F3B-B229ACC7165D} -SetProperties -completed=true

Ну и далее собираем в конвееры и автоматизируем.

Уверен, что такие функции уже реализованы, просто не выведены в CLI.

Сообщение **edw** » 17 апр 2020, 19:35

romka11 писал(а):На мой взгляд, интерфейс сейчас уже перегружен из-за стремления объять необъятное – добавить столько свойств описания задачи, чтобы хватило всем.

Согласен. Скажу жёстче. Для меня на сегодня это основной недостаток MLO-десктоп. Он перестаёт быть удобным не потому, что там чего-то нет. А потому что там слишком много всего, что я не использую. Я теряю миллисекунды в поисках нужного мне параметра задачи. Но, что хуже, меня это выводит из равновесия. :oops:

Что не допустимо для системы управления личным списком задач.

romka11 писал(а):Источник цитаты2. Набор фиксированных свойств и возможность добавлять пользовательские

Если вы утверждаете, что програмно это реализуемо, тогда мой минимум хотелок для 6:

новые типы полей Формула(Вычислимое) ~~и КликабельнаяСсылка(Действия)~~
есть какой-то обязательный минимум полей - заголовок, комментарий, тип (задача, папка, проект); все прочие поля пользователь может отключить
пользователь может добавить свои поля определённых типов (вроде Checkbox, Number, Text, Select, Date) - в логике приложения их обрабатывать не надо, но через Формулы с ними можно работать
для тех полей которые пользователь включил, он может выбрать нужно ли их отображать в Свойствах задачи
возможность группировать поля в блоки с привязкой блоков к областям

В результате:

радикальное упрощение интерфейса на уровне «область - блок - поле»
с редко используемыми полями можно работать в табличном виде
дополнительные поля под специфические задачи пользователя
новый уровень логики через формулы

Если всё это вместе с автоформатированием запаковать в отдельный файл конфигурации, появляется профессия “внедренец MLO”.

(Тему скриптов вывожу за скобки. Они необходимы, но как их реализовывать - отдельная тема.)

Сообщение **edw** » 18 апр 2020, 09:46

romka11 писал(а):Источник цитаты Если исключить избыточные типы Notion, то для воссоздания почти такой же гибкости, в MLO остается добавить только следующие типы: Формула(Вычислимое), КликабельнаяСсылка(Действия) и, может быть, Файл(новый мета-тип)

По типам полей.
Тип Файл добавлять рисковано. Потеряется совместимость между версиями на устройствах если идти через пути в файловой системе. Впрочем уже сегодня в текстовое поле Заметка можно добавить кликабельную ссылку на file://

КликабельнаяСсылка(Действия). По сути уже реализована в виде ссылок в текстовой Заметке. Если дать возможность пользователю создавать новые текстовые поля то он сможет сам их зарезервировать под КликабельнаяСсылка. Хотя мне кажется что более удобным решением будут кликабельные иконки.

Формула(Вычислимое). Идея интересная, но что бы стать её сторонником, нужны яркие кейсы. В каких случаях могут быть полезны расчёты между значениями отдельных полей задачи?

romka11 · Сообщение **romka11** » 19 апр 2020, 18:16

edw писал(а):Источник цитаты Тип Файл добавлять рисковано.

Да, согласен, потому и написал со пометкой "может быть". Внедрение полноценной функции вложенных файлов потребует помимо смены парадигмы колонок, полной смены инфраструктуры и расширения команды, потому что эти файлы придется хранить в специальном облаке, которое нужно обслуживать, балансировать и, естественно, оплачивать. Оставим это для MLO10.
На мой взгляд, единственный адекватный вариант, реализуемый в ближайшем будущем – это встраивание вложений в ml-файлы с обязательными ограничениями на размер отдельного файла и базы файлов в целом. Понятно, для полноценного хранения файлов проекта, такое не подойдет, но для встраивания изображений в заметки – вполне. Любители маркдауна вообще будут в восторге.

Технические моменты:

romka11 · Сообщение **romka11** » 19 апр 2020, 18:16

edw писал(а):Источник цитаты КликабельнаяСсылка(Действия). По сути уже реализована в виде ссылок в текстовой Заметке. Если дать возможность пользователю создавать новые текстовые поля то он сможет сам их зарезервировать под КликабельнаяСсылка. Хотя мне кажется что более удобным решением будут кликабельные иконки.

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

Технические моменты:

romka11 · Сообщение **romka11** » 19 апр 2020, 18:17

edw писал(а):Источник цитаты В каких случаях могут быть полезны расчёты между значениями отдельных полей задачи?

Уже сейчас множество свойств являются вычислимыми: "Процент выполнения", "Длительность", "Вычисленная оценка", "Счетчик зависимостей" и др. В принципе, все, для чего сейчас используется автоформатирование, может быть выражено не в виде ПараметраШрифта/Значка/Заливки, а в виде некоторого значения поля, по которому уже можно фильтровать, сортировать, группировать и разукрашивать.
Личный пример, как я бы использовал пользовательские формулы:
• собственная формула оценки задач
• категоризация по типам [Текущее, Накануне, Скоро, ОбозримоеБудущее, ДалекоеБудущее]
• категоризация по типам [Новая, Недавняя, Старая, Замшелая]
и множество другого...
Сейчас все реализовано через автоформатирование(56 активных правил без учета стандартных), а вид "Все задачи" похож на шабаш клоунов

. Но другие планировщики не позволяют и этого.

Технические моменты:

Сообщество MLO