13.10.2017 07:57
curunir 51 10500 Источник

Некоторое время назад, я, как активный пользователь планировщиков личных задач, открыл для себя один значительный недостаток – несмотря на их несчётное количество, невозможно найти «тот самый», который удовлетворял бы тебя по всем пунктам.


Нет, само по себе это абсолютно нормально, так как программу разрабатывал один или несколько разработчиков, которые в итоге пришли к своему пониманию того, “как пользователю будет лучше”. Да и к тому же, невозможно в одной программе уместить всё, что теоретически может захотеть сферический пользователь в вакууме. Или возможно?





Почему 2 функции в 1 приложении лучше, чем 1 функция в 1 приложении


Давайте на секунду отбросим все ограничения и представим что идеальный планировщик существует: он полностью соответствует вашим ожиданиям в плане интерфейса, предоставляет все необходимые вам функции и работает на всех ваших устройствах. Что это нам даёт? Ключевой особенностью такого приложения будет возможность использовать одни и те же данные для обеспечения работы всех функций приложения.


Смоделируем ситуацию — есть два пользователя, которые жить не могут без составления списка задач и использования техники Pomdoro. У обоих одинаковые потребности — разница лишь в том, какие приложения они используют для их удовлетворения:

  • Пользователь#1 использует 2 популярных приложения: Todoist (список дел) и Productivity Challenge Timer (Pomodoro)
  • Пользователь#2 пользуется нашим гипотетическим «идеальным» приложением



Пару слов о том, как происходит взаимодействие пользователя с программой в обоих случаях:

  • Пользователь#1: заполняет список задач в Todoist, заполняет список проектов в Productivity Challenge Timer
  • Пользователь#2: заполняет список задач внутри своей программы



Исходя из приведённой иллюстрации можно определить некоторые неприятные моменты, с которыми придётся столкнуться пользователю#1, в отличие от пользователя#2:

  • Необходимость ручной синхронизации списка проектов в обоих приложениях
  • Невозможность запустить циклы Pomodoro для включённых в проект подзадач
  • Отсутствие объединённой статистики по выполнению задач — она хранится в разных приложениях

Если вас это не смущает, и вы считаете что можно обойтись и несколькими приложениями, то представьте что будет, если нужно обеспечить пользователя не двумя, а десятью функциями?

Решение проблемы


Хорошо, одно приложение в котором есть все нужные функции лучше, чем несколько приложений. Но нельзя же разрабатывать под все сочетания функций отдельную программу! Всё так и получается, если не использовать...и зачем я ломаю комедию, в заголовке же написано было… модульный подход!


Главный секрет «идеального» приложения в том, что не надо пытаться «предугадать» что же пользователь там захочет, а позволить ему самому собрать своё «личное» приложение, которое как раз и будет максимально полно отвечать его желаниям и потребностям. Процесс сборки такого приложения будет заключаться в отбирании желаемых функций приложения и аспектов пользовательского интерфейса, которые будут представлены соответствующими модулями.


К тому же, очевидно, что если грамотно организовать процесс разработки подобного приложения, то общая трудоёмкость существенно сократится, так как реализованные функции никуда не исчезают — они лишь «запаковываются» в удобные для использования другими разработчиками модули.


Это не только теория


Чтобы эта статья не выглядела как бред спятившего на своей теории разработчика, я хотел бы показать как это всё работает на примере своего проекта. Я не буду пока описывать его в рамках данной статьи — сейчас лишь опишу саму идею. В общем, есть некое приложение X — на данный момент в нём можно подключать новые модули в систему, где каждый модуль может существенно изменить интерфейс и расширить доступные функции приложения.

Вот ситуация как в примере выше, когда модуль списка дел расширяется модулем Pomodoro:




На данный момент приложение находится в стадии разработки, и не готово к предоставлению доступа пользователям. Ещё много чего предстоит реализовать, но кое-что уже есть — вот, например, список рабочих функций приложения:


  1. Список задач — у задач есть следующие свойства: название, дата, выполненные Pomodoro, зарисовка
  2. Техника Pomodoro — запуск циклов Pomodoro для задач из списка задач
  3. Пользовательские зарисовки — создание зарисовок для сохранения в отдельной галерее или привязки к задачам из списка задач

Каждая из описанных функций представлена группой модулей, каждый из которых можно удалить, не повлияв на работоспособность всей системы — удаление модуля лишь исключит из системы соответствующую функцию, за которую он отвечал.

Перспективы


Под конец статьи я бы хотел поделиться с вами своими концептами по дальнейшему развитию и использованию этого проекта.

Взаимодействие с умным домом
Дано: На смартфоне установлено приложение X, в нём пользователь хранит свои задачи, распорядок дня и прочее. В месте, где он проживает установлена система «умного дома».
Описание: Приложение на смартфоне имеет данные, используя которые можно улучшить функционирование «умного дома», а именно: зная расписание дня можно настраивать освещённость, включать и выключать музыку в определённое время, запускать бытовую технику (при пробуждении, вернулся домой). При этом пользователь не должен вручную настраивать поведение этой системы, так как она использует те же данные, что и он (как в примере с Pomodoro).
Уже реализованные модули: список задач, взаимодействие с СУБД
Необходимо реализовать модули: интернет взаимодействие или Bluetooth, модуль общения с системой умного дома, модуль с логикой анализа расписания дня для умного дома



Оптимальное планирование выполнения проектов с учётом стиля жизни пользователя
Дано: На смартфоне установлено приложение X, в нём пользователь хранит свои задачи, распорядок дня и прочее.
Описание: При длительном использовании приложения накапливается большой массив данных, которые можно использовать как входные для алгоритмов машинного обучения. Таким образом, можно будет с некоторой вероятностью предсказывать, когда пользователь будет выполнять задачи в зависимости от их срочности, важности или отношения к какой-либо сфере жизни. Используя предсказание, можно будет, например, в начале дня сгенерировать варианты того, как он мог бы провести сегодняшний день. При этом бы учитывались все сроки по текущим проектам и составлялось оптимальное расписание для сдачи их в срок.
Уже реализованные модули: список задач, взаимодействие с СУБД
Необходимо реализовать модули: модуль машинного обучения на последовательностях, модуль генерации «предсказаний»



Контроль выполнения физических упражнений
Дано: На смартфоне и ПК пользователя установлено приложение X, в нём он хранит свои задачи, распорядок дня и прочее. У пользователя есть фитнес-браслет, который он всегда носит.
Описание: Пользователь решает заняться спортом (бегать по утрам, делать зарядку). На смартфоне и ПК пользователь выбирает приложения и сайты, к которым ему будет урезан доступ. В случае невыполнения спортивных занятий, пользователь на некоторое время получает урезанный доступ к выбранным ресурсам. Контроль за выполнением спортивных занятий отслеживается по данным, полученным с браслета.
Уже реализованные модули: взаимодействие с СУБД
Необходимо реализовать модули: интернет взаимодействие или Bluetooth, модуль взаимодействия с фитнес-браслетом, модуль ограничения доступа к ресурсам, модуль контроля выполнения привычек



В данной статье я не рассматривал особенности реализации, дабы не перегружать текст деталями. Я обязательно освещу сам процесс разработки, но в рамках следующей статьи. Если кому-то интересно, то можно ознакомиться с уже реализованными модулями:

Реализованные на текущий момент модули
  1. MainMenuModel — хранит ссылки на подключенные в данный момент плагины
  2. MainMenuView — предоставляет UI главного меню
  3. TaskListModel — предоставляет доступ к пользовательским задачам
  4. TaskListView — отображает пользовательские задачи в виде древовидного списка
  5. PomodoroModel — предоставляет доступ к выполненным Pomodoro
  6. PomodoroView — предоставляет UI для запуска циклов Pomodoro и их просмотра
  7. TaskSketchModel — предоставляет доступ к пользовательским зарисовкам
  8. TaskSketchView — предоставляет UI для создания зарисовок
  9. AndroidNotificationsModel — предоставляет доступ к специфическим для платформы Android функциям
  10. ExtendableDataBaseManager — предоставляет доступ к абстрактным структурам данных, независимым от источника
  11. CipherDataBaseSource — предоставляет методы для взаимодействия с шифрующим плагином для СУБД SQLight


С исходным кодом можно ознакомиться по ссылке.

Спасибо за внимание.

Комментарии (51)


  1. Bonart
    13.10.2017 12:17
    #10470754

    Каким образом учитываются зависимости между модулями?
    Как решаются возможные конфликты (два модуля претендуют на модификацию одной части интерфейса)?
    Может ли один плохой модуль сломать все приложение?


    1. curunir Автор
      13.10.2017 13:22
      #10470940

      1. Зависимости и конфликты контролируются корневым модулем, который загружает и линкует все прочие модули.
      2. Да, если в систему встроить заведомо нерабочий модуль, то всё грохнется. Однако, прежде чем такой модуль будет подключен к программе, он должен пройти несколько этапов контроля, начиная от сборки под разные платформы и заканчивая интеграционным тестированием.
      Вообще говоря, будет некий централизованный список «доверенных» модулей, которые уже прошли все стадии контроля, и которые пользователь сможет подключить в приложение, скачав их с сервера через это же приложение или с сайта.


      1. Bonart
        13.10.2017 14:33
        #10471126

        Зависимости и конфликты контролируются корневым модулем, который загружает и линкует все прочие модули.

        А как корневой модуль узнает, что модуль A зависит от модуля B?


        1. curunir Автор
          13.10.2017 14:46
          #10471170

          В комплекте с каждым модулем идёт мета-файл в формате JSON, в котором хранится информация, на основании которой корневой модуль и производит линковку. Связываются модули по интерфейсам.
          Вот, например, мета-файл модуля с логикой для списка задач:

          {
    "Type": "PluginModel",
    "Interface": "ITaskTreeModel",
    "Name": "TaskListModel",
    "RelatedPluginInterfaces": [
        "IExtendableDataManager",
        "IMainMenuModel"
    ]
}


          1. Bonart
            13.10.2017 16:02
            #10471414

            Спасибо, видно, что вы серьезно подошли к задаче.


            1. Как корневой модуль обрабатывает наличие нескольких реализаций одного интерфейса?
            2. Может ли модуль стать корневым для своих подмодулей и использовать тот же механизм для разрешения зависимостей?
            3. Можно ли получить актуальный граф модулей в пригодном для понимания человеком виде?


            1. QDeathNick
              13.10.2017 16:14
              #10471458

              Такая модульная система хороша. Ещё бы отслеживать версионность и автоматически всё подтягивать, обновлять. В odoo тоже примерно так реализовано. И там тоже есть todo модули и, если поискать, то и с pomodoro.


              1. curunir Автор
                13.10.2017 16:41
                #10471554

                Класс, спасибо — обязательно рассмотрю поближе)
                А в неё модули добавляют только разработчики компании или любые?


                1. QDeathNick
                  13.10.2017 16:44
                  #10471560

                  Она opensource, я сам для себя писал специфический модуль. Всё довольно просто, особенно сейчас. В 6 версии было сложнее.


                  1. curunir Автор
                    13.10.2017 16:52
                    #10471584

                    Это средство же получается только для веба? Его можно использовать для разработки нативного приложения?


            1. curunir Автор
              13.10.2017 16:37
              #10471542

              1.Через пользовательский интерфейс предложит пользователю выбрать один из них. Но вообще, такая ситуация не должна возникнуть при правильном использовании приложения.
              2. Вообще говоря, я хотел раскрыть эту тему в следующей статье, но вкратце есть всего 4 типа модулей:

              • Model — бизнес логика и взаимодействие с другими модулями
              • View — пользовательский интерфейс
              • DataManager — предоставляет доступ к независимым от источника данным и общается с DataSource в контексте источника данных (запросы, протоколы и прочее). Это такой, буферный тип для отделения логики от источника
              • DataSource — взаимодействует напрямую с источником данных

              За исключением описанных ролей — я не закладывал абсолютно никаких ограничений на функциональность, только на назначение. Так что да, можно хитровывернуться как вы предложили)
              3. Можно, но сейчас это не реализовано. Однако, можно реализовать всё что угодно — нужно лишь знать интерфейс нужного модуля. Вот, например, интерфейс того самого корневого модуля:
              class IMainMenuModel : public IModelPlugin
{ 
public:
    struct MenuItem{
        MetaInfo* meta;
        QList<MetaInfo *> Items;
        QList<MenuItem*> SubItems;
    };
    virtual MenuItem* GetRootMenuItem() = 0;
    virtual void RunItem(MenuItem* item, MetaInfo *viewMeta) = 0;
};

              В принципе, можно хоть сейчас строить такой граф.


  1. wert_lex
    13.10.2017 13:01
    #10470888

    У меня ощущение, что вы только что придумали мобильную операционную систему. Приложения — и есть те самые модули.


    1. curunir Автор
      13.10.2017 13:27
      #10470958

      Да, согласен, но если писать приложения под какую-либо операционную систему, то они смогут выполняться только на ней.
      В моём же случае я использую фреймворк Qt для обеспечения переносимости логики и интерфейса на любую платформу. Что-то вроде кроссплатформенной операционной системы получается, простите мой французский.


      1. wholeman
        13.10.2017 13:52
        #10471028

        Тоже пробовал сделать подобное приложение, но тогда Qt под Android работал не лучшим образом, по крайней мере, виджеты. А как с этим сейчас, виджеты, наверно, совсем забросили, а QML-то доделали?


        1. curunir Автор
          13.10.2017 15:32
          #10471294

          Да, раньше с Qt было намного сложнее чем сейчас…
          QML ещё делают, но в целом он уже очень привлекательный. Призывают бросать в топку виджеты и переходить на QML. Я пока не отказываюсь от виджетов, так как с ними удобнее работать из плюсов, но если что-то красивое надо сделать, то объединяю виджеты с QML.


          1. wholeman
            13.10.2017 15:54
            #10471374

            В QML тоже есть кое-какие виджеты. По крайней мере, их делали, но я их не дождался и перешёл на Java+Android API, тем более, что актуальную задачу без этого просто не реализовать. Пока обдумываю выделение кроссплатформенного кода в отдельные модули на C++ без фреймворков с легковесными мордами на HTML и нативных API.


  1. Plesser
    13.10.2017 13:26
    #10470952

    Я над подобным проектом уже бьюсь давно :). Но понимания как сделать правильно до сих пор нет. Основная проблема, что в голове вырисовывается картинка как оно должно работать, делаю прототип и понимаю что пользоваться не удобно. Отдельная головная боль это хранение данных в облаке и шаринг данных между несколькими пользователями…


    1. curunir Автор
      13.10.2017 13:29
      #10470966

      Прекрасно, я рад что вы есть!: ь
      А вы какие инструменты используете и как обеспечиваете модульность архитектуры?


      1. Plesser
        13.10.2017 13:33
        #10470978

        Android Studio для написания ядра и основного интерфейса, модульность пока не трогал так как в голове нет понимания до конца как обеспечивать связку данных и опять таки как будет влиять ситуация когда у одного товарища есть какой либо модуль а у другого нет и при этом у них данные расшарены друг для друга.
        И по облаку смотрю упорно в сторону Django/Flask


      1. Plesser
        13.10.2017 13:35
        #10470980

        Ах да, еще в моей голове крутится такой факт — что не плохо было бы привязывать начало одних задач к завершению других задач


      1. QDeathNick
        13.10.2017 15:07
        #10471244

        Желающих иметь идеальный планировщик больше, чем вы можете представить. Но ваши помидоры, это мелочь по сравнению с тем, что действительно хочется.
        Вот тут народ пишет:

        не плохо было бы привязывать начало одних задач к завершению других задач

        А ещё хочется чтобы при отмене одной задачи отменялись её потомки и создавались другие. Хочется чтобы задачи создавались сами на основе внешних событий, звонков, писем, превышения скорости в мониторинге автомобиля… Вообще хочется чтобы всё само происходило по разным сценариям.

        Так вот всё это возможно в планфиксе. И если чего-то не возможно, то можно попросить добавить это и разработчики делают. Единственное чего у них пока нет, это удобного мобильного приложения, обещают уже год.


        1. curunir Автор
          13.10.2017 15:39
          #10471306

          Я согласен с вами, что наши помидоры это мелочь — я просто показал этот случай как пример.
          Спасибо, я не знал о таком инструменте. Обязательно ознакомлюсь.
          А как у них реализовывается создание задачи при превышении скорости автомобиля?


          1. QDeathNick
            13.10.2017 15:49
            #10471334

            Я сам его искал очень долго, но вот уже второй год отличного полёта. Рекомендую.
            Не изобретайте велосипед, прикрутите лучше свой мобильный интерфейс к их API, я буду первым тестером и возможно покупателем.

            А как у них реализовывается создание задачи при превышении скорости автомобиля?

            Система мониторинга умеет слать email, а планфикс умеет при поступлении письма разбирать его и при выполнерии условий создавать задачи по шаблонам. Потом планфикс вызывает через API телефонии диспетчера и водителя, водитель получает втык, запись разговора прикрепляется в задачу, задача завершается. Если же нет, то диспетчер оповещается планфиксом уже через телеграмм ботом, а если и так нет реакции, то через час создаётся задача старшему диспетчеру и он начинает нагибать первых двух исполнителей.
            Очень мощный инструмент автоматизации бизнес-процессов. И при этом там легко вести личные дела, использовать его как ежедневник и ещё куча других вариантов использования, судя по тому что пишут люди в успешных кейсах.


            1. curunir Автор
              13.10.2017 16:01
              #10471412

              Спасибо, я покопаю глубже по поводу этой панацеи)
              Нет, я имел ввиду как они определяют что скорость превышена — в машине установлена какая-то аппаратура или они с GPS телефона информацию берут?


              1. QDeathNick
                13.10.2017 16:05
                #10471424

                У нас аппаратура, но можно и с телефона. mobyfleet.ru/gps
                Они специально для нас добавили функционал геозон, в которых можно указывать максимальную скорость.
                Кстати по поводу определения текущей скорости ещё не всё решено. Есть подводные камни.


        1. wholeman
          13.10.2017 16:07
          #10471436

          Единственное чего у них пока нет, это удобного мобильного приложения, обещают уже год.
          Это перечёркивает все их достоинства. А ещё, как я понял, у них нет автономной работы. Я частенько бываю в местах, где даже голосовая связь отваливается, не то, что Интернет. Внезапно остаться без всех своих задач и планов — перспектива не из приятных.


          1. QDeathNick
            13.10.2017 16:20
            #10471486

            Согласен, перечёркивает, есть мобильная версия и боты в телеграме, пока как-то перебиваемся.
            В мобильном приложении обещают и автономную работу и именно это, я так понимаю и затягивает процесс. Потому как не совсем понятно, как обрабатывать автономность в случае групповой работы над задачами. В сингл режиме то проблем особых нет, хотя вдруг у вас есть и телефон и комп и ещё несколько устройств, и как это всё синхронизировать и решать конфликты при появлении связи?
            А в мультиплеере вообще сложно, вы что-то по задаче сделали в автономном, а её уже закрыли или изменили и ваши действия уже не повлияют на сценарии так, как вы хотели. Да и даже если ничего не изменили, это же надо и серверные сценарии тянуть на клиент, чтобы они там выполнялись.
            Надеюсь им удастся сделать что-то более интересное, чем простую автономную записную книжку


          1. QDeathNick
            13.10.2017 16:31
            #10471524

            Внезапно оказаться в местах, где даже голосовая связь отваливается да ещё без всех своих задач и планов — отличная перспектива.
            Хорошей всем пятницы, а я в отпуск, рыбу ловить.
            Пока ещё нет автономной работы и это ещё возможно.


  1. wholeman
    13.10.2017 14:15
    #10471084

    Пытался реализовать что-то подобное. Дошёл до задачника и переключился на учёт физкультуры. По ходу пришёл к выводу, что в Android поддержка модульности реализована не лучшим образом, потому что все приложения как бы независимы и какой-либо группировки в магазине нет. Как следствие, проще организовать взаимодействие между приложениями, хоть через сокеты или интенты. Но более тонкой настройки уже не получится.


    1. curunir Автор
      13.10.2017 14:42
      #10471164

      Спасибо что поделились своими проектами — представляю сколько сил было вложено. А в каком виде у вас был использован модульный подход?
      Да, я, к сожалению, тоже столкнулся с такой же проблемой. Вы не встречали существующих приложений, которые общаются через сокеты или интенты? Любопытно, насколько вообще такой подход распространён.


      1. wholeman
        13.10.2017 16:01
        #10471408

        А модульный подход у меня не использовался, но я его продумывал.:) Если под Linux это решается достаточно легко с помощью динамических библиотек (а в Qt вообще есть система плагинов) и зависимостей в пакетах, то в Android пока кроме выделения библиотек при компиляции и отдельных служб ничего не придумал.


        1. curunir Автор
          13.10.2017 16:55
          #10471598

          Ну, теперь в Android тоже можно использовать систему плагинов Qt — у меня на них вся система и держится. Чертовски удобная штука, не могу нарадоваться ею)


          1. wholeman
            13.10.2017 17:46
            #10471724

            А как она уживается с Гуглоплеем?


            1. curunir Автор
              13.10.2017 17:53
              #10471736

              Ой, вот до этого пока не добирался, честное слово. Вообще, с этим ожидаются проблемы, так как приложение может изменяться «на лету», а я не знаю насколько это созвучно с политикой Гуглоплея.


  1. Apokalepsis
    13.10.2017 17:57
    #10471748

    Спасибо за статью. Примерно такую же задачу сейчас решаю тольк с crm/erp


    1. curunir Автор
      13.10.2017 18:07
      #10471770

      Спасибо за отзыв. Насколько я понимаю, crm/erp это методология? А с помощью чего реализовываете?


      1. Apokalepsis
        14.10.2017 08:51
        #10472400

        Я бы сказал что это и методология и система, все взаимосвязано. Фактически все началось с того что ни одна не подошла, где то что то не хватало, где то было слишком много. А менять нельзя. Поэтому решили сделать модульную систему и выложить все на Github, может кому будет интересно присоединиться :). Пока делаем только веб приложение, поэтому — Vue.js -и LoopBack.


  1. rasmikun
    13.10.2017 19:43
    #10471900

    Как мне кажется, проблема «модульного» подхода в том что в итоге потом будет зоопарк, нужно будет как-то понимать как все эти комбинации модулей между собой взаимодействуют.
    То есть наверное можно поддерживать небольшой зоопарк, небольшой зоопарк это не сложно. Но тогда у пользователя не будет всех фишек которые он бы хотел. А если делать все фишки которые бы он хотел, то тогда будет сложно гарантировать что всё будет работать достаточно гладко во всех комбинациях.
    Автор, кстати, не пробовал org-mode? По-моему их идеалогия очень схожа. Правда поддержка мобильника всё ещё оставляет желать лучшего. Хотя вот активно пилится orgzly например, у них море планов.


    1. curunir Автор
      13.10.2017 20:01
      #10471932

      Несомненно, без зоопарка не получится, но я и не сказал что будет просто — нужно разработать методологию группировки и поиска всех этих модулей, а также варианты их доступного отображения для пользователя. Вообще говоря, эту часть системы тоже надо сделать модульной, чтобы множество разработчиков могло получить доступ к этим данным и попытаться сделать лучший вариант. Потом просто методом естественного отбора всплывут лучшие решения.
      По поводу гладкости работы — запланировано обеспечить несколько этапов контроля новых модулей: сборка под разные платформы, автоматическое тестирование (функциональное, интеграционное), код-ревью другими разработчиками, выпуск модуля в бета-группу, а только после этого уже разрешение доступа к модулю всем пользователям. Тут много идей, но работы предстоит ещё больше.
      Спасибо за информацию — не был знаком с ними. А какие у orgzly планы, ну из самых интересных?


  1. Cid
    13.10.2017 22:27
    #10472124

    А вы пробовали анализировать предметную область? Сколько, действительно, различающихся по назначению модулей там можно придумать? То, что приведено у вас в разделе «Перспективы», — это (помимо машинного обучения) интеграция со сторонними устройствами.


    1. curunir Автор
      13.10.2017 22:33
      #10472128

      Дело в том, что предметная область в данном случае не определена до того самого момента, как пользователь соберёт свой приложение. За исключением интеграции со сторонними устройствами, необходимо также учесть интеграцию со сторонними приложениями, все возможные функции персонального приложения и всевозможные вариации пользовательского интерфейса: начиная от цвета ярлыка — заканчивая отображением для очков виртуальной реальности.


  1. Cid
    14.10.2017 00:07
    #10472214

    Предметная область как раз определена хорошо. Это личная продуктивность и тайм-менеджмент. На эту тему написано много томов, но существенно различных стратегий управления делами может быть не так много. Если стратегий мало, то и интересных комбинаций много не получится. А значит, открытая платформа-конструктор не будет иметь преимущества перед каким-то специализированным планировщиком. На мой взгляд это ключевой вопрос, который нужно проанализировать, чтобы понять, есть ли потенциал у вашего конструктора.
    А интеграционных модулей можно придумать бесконечное количество. Экспорт-импорт данных, синхронизация, всякие гаджеты, оформление UI. Это все полезно, но не то, что создает продукт.


    1. curunir Автор
      14.10.2017 10:35
      #10472466

      Согласен с вами, что количество различных стратегий счётно и, если поискать, то можно найти готовую обзорную статью. Однако, если вы посмотрите на иллюстрацию в заголовке статьи, то сможете увидеть там множество серьёзных и успешных продуктов, которые, тем не менее, различаются только тем, что вы как раз перечислили. Дело в том, что аудиторию пользователей можно сравнить с ситуацией в басне «Лебедь, рак и щука» — все тянут в разные стороны: минималистичнее — функциональнее, в облако — на устройстве, десктоп — смартфон, ещё функций — слишком много функций. И в результате этого процесса, разработчик делает выбор в сторону требований большинства аудитории, ограничивая, тем самым, свой рост. В данном же случае, «Лебедь, рак и щука» могут тянуть хоть в разные измерения — система от этого станет только устойчивее.
      Я не говорю что этот продукт является панацеей от всех бед разработки — он с таким же успехом добавляет новых, но вот проблему, которую я озвучил, он должен решить однозначно.


  1. mSnus
    14.10.2017 02:52
    #10472316

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


    Идеальный инструмент — тот, которым легко и приятно пользоваться, а не тот, который покрывает 110% запросов пользователей.


    А это решается не модульностью, а хорошим дизайном и usability, от удобных шорткатов на компе до хорошего мобильного приложения. А то рождаются всякие убогие Trello, где интерфейсных ошибок больше, чем фич, зато его можно расширять модулями power ups!


    Или посмотрите для примера на сегмент текстовых редакторов или редакторов кода. Монстры редко выживают, а уж модульность вообще мало кому нужна, хотя тоже можно было бы собирать идеальный редактор по кусочкам.


    И, да, проще держать notepad, sublime text, word и phpstorm в придачу, потому что для разных целей удобно держать разные отвёртки.


    1. curunir Автор
      14.10.2017 10:54
      #10472490

      Несомненно, если некорректно организовать расширение системы модулями, то от этого она лучше не станет, а только усложнится и станет бесполезной грудой кода. Но я и не говорил, что хорошо сделать такой инструмент будет простой задачей — встаёт много проблем по организации удобного подключения модулей как для пользователей, так и для программистов.

      Я бы прямо сейчас бросил всё и начал радоваться жизни, если бы

      которым легко и приятно пользоваться
      значило для всех пользователей одно и то же. Рынок, к сожалению, переполнен продуктами, которые различаются лишь
      хорошим дизайном и usability
      , а функционально являются идентичными на 70-95%. Да, варьируются масштабы проектов, но по сути, здесь уже вступает в дело маркетинговая политика, а не способности программистов.


      1. mSnus
        14.10.2017 12:34
        #10472576

        К сожалению, большинство из них отличается плохим дизайном и юзабилити, набором дизайнерских и интерфейсных ошибок, устарелостей и недоработок… у Trello они одни, у MS Project другие, у ToDoList третьи.

        Скажем так, все старые — устарели, все новые — недозрели. Ждём :)


  1. xvilka
    14.10.2017 09:26
    #10472420

    Модульный интерфейс уже есть — TaskWarrior (+ TimeWarrior) и многочисленные дополнения и утилиты к нему. Да и Android приложение есть.


  1. curunir Автор
    14.10.2017 14:12
    #10472666

    Спасибо, не слышал о нём. Да, очень много сделано у них и сообщество прекрасное. Обязательно рассмотрю его получше.
    Однако, ознакомившись с документацией, хочу отметить следующие моменты:

    В разделе Philosophy:

    Taskwarrior carefully limits the features it supports, in order to focus on doing one thing well. It does not offer reminders and time tracking, because there are other projects dedicated to implementing those features well.

    If a feature improves the way we manage task lists, then it belongs in Taskwarrior, otherwise it belongs in some other software.
    Получается, что они заведомо ограничивают возможности расширения системы. Это не плохо — вполне вероятно, что у них прекрасно получается, но я в этой статье говорил о системе, в которой нет ограничений функциональности.

    В разделе Extension API:
    Several Timewarrior reports are written as extensions, which uses an API to provide filtered data and configuration to the external command. This is a one-way process, the extension has no way to communicate back to Timewarrior. Future rules will allow this.
    Здесь же вообще говорится, что расширения не могут влиять на работу основного приложения. Да, они говорят что в дальнейшем ситуация изменится, так что если это действительно будет так, то этот пункт критики можно не учитывать.


  1. AbstractGaze
    16.10.2017 06:44
    #10474594

    Вроде как и идея хорошая, но на самом деле это будет еще одно узко специализированное приложение, которое будет добавлять сложностей.
    Как выше написали телефон и есть агрегатор приложений, и еще одни выполняющий ту же самую функцию будет не актуален.
    Например на pc есть мессенджер, который на самом деле представляет из себя облегченный браузер с кучей web клиентов. По сути вы делаете аналог, но только для телефона.
    Зачем?
    Как только появится хоть одно приложение которое будет удовлетворять пользователей — а оно появится про ваше приложение забудут, так как ставить одно приложение всегда проще чем ставить агрегатор и пачку приложений.
    Или например одно из используемых приложений после обновления перестает работать совместно с вашим, что сделает пользователь? Правильно удалит ваш агрегатор чтобы подобных ситуаций избежать.

    Есть одно конечно одно но — ваше приложение будет качественным агрегатором со своей экосистемой, как например стим для игр, или nexusmod для модов к играм. Но ведь телефон и есть этот самый агрегатор с уже готовой экосистемой, зачем создавать еще одну прослойку?

    Лично мне кажется что вы подошли к решению проблемы не с той стороны. Если вы видите много недостатков в куче мелких приложений, при этом они легкие и уже есть, не проще ли написать свое приложение с модульным функционалом, который можно просто включать или выключать, но которые 100% совместимы потому что являются частью вашей программы?


    1. wholeman
      16.10.2017 08:03
      #10474626

      К сожалению, телефон, не справляется с задачей агрегации приложений: они в большинстве своём разрозненны и между собой взаимодействуют плохо. Например, простой поход в магазин: нужно определить список покупок, желательно заранее прикинуть стоимость, вписать в план, в магазине иметь возможность свериться с планом и отметить купленное, а потом записать расходы и хорошо бы учесть пополнение запасов. Это уже три модуля (финансы, время, запасы), которые нужны не всем. Я бы ещё добавил физкультуру и питание, а также управление «умным домом», которым тоже хорошо бы обмениваться информацией. Сделать это всё одним приложением можно, но блаутварь получится ещё та. А между отдельными приложениями потребуется обмен данными и переходы от одного к другому.


      1. AbstractGaze
        16.10.2017 08:36
        #10474660
        +1

        Так почему «блаутварь получиться еще та»? Почему если делать агрегатор пачки разных приложение то это будет удобно и легко, а если создавать тоже самое изначально самому то это будет ужасно?
        Чтобы сделать агрегатор все равно придется разбираться в огромном количестве приложений, и их совместимости, и делать в итоге это постоянно. А если вы эти приложения знаете и по функционалу, знаете что нужно, что не очень, почему не потратить это время на одно свое модульное приложение? К тому же не обязательно будет выпускать все модули сразу, их можно добавлять.

        Опять же, из за огромного количества существующих приложений может появится проблема с отзывами. Например автор учел не «все» приложения. Я вот поставил его, и хочу чтобы приложение задач было связано с приложением миндмап, т.е. чтобы я мог видеть задачи наглядно. А автор не учел такой тип приложение, и что будет дальше? я поставлю отрицательный отзыв так как приложение свой функционал выполнять «никак». В и тоге им и пользоваться никто не будет просто из за отзывов. Поэтому мне кажется что писать свое с указанным (или обещанным) функционалом проще, чем пытаться подружить все на свете.

        Но у каждого свой взгляд, в любом случае желаю автору закончить свой проект.


        1. curunir Автор
          16.10.2017 09:44
          #10474746

          Спасибо за ваш отзыв)
          Как вы упомянули:

          По сути вы делаете аналог, но только для телефона.
          Однако, я делаю эту систему переносимой на все платформы — то есть весь спектр реализованных функции будет в том же виде доступен на любом устройстве.

          Абсолютно согласен с вами, что одно приложение ставить намного проще чем этакую махину, но я и не утверждаю что оно поглотит весь рынок, мимикрируя под все существующие приложения. Может мимикрировать то оно и сможет, но чтобы заставить его это сделать будет нужно будет, само собой, приложить некоторые усилия — что является минусом относительно «готовых» приложений. Однако это не приговор — здесь уже встают задачи по сведению этих усилий к минимуму и сокрытии от пользователя (по крайней мере в начале) всех доступных возможностей — чтобы не пугать его раньше времени.

          И кстати, вы говорите об агрегации приложений — однако, в этой системе функции будут представляться отдельными библиотеками подключенными в одно приложение. То есть здесь агрегация идёт на уровне интерфейсов модулей. Чтобы это получше описать, воспользуюсь вашим примером:
          Я вот поставил его, и хочу чтобы приложение задач было связано с приложением миндмап, т.е. чтобы я мог видеть задачи наглядно.
          В архитектуре системы, список задач будет представлен модулем в котором хранятся только данные, а к нему уже будет подключаться модуль, который занимается только отображением — это что-то вроде подхода MVC. То есть один и тот же список задач можно, при подключении соответствующего модуля, отобразить как угодно.