Некоторое время назад, я, как активный пользователь планировщиков личных задач, открыл для себя один значительный недостаток – несмотря на их несчётное количество, невозможно найти «тот самый», который удовлетворял бы тебя по всем пунктам.
Нет, само по себе это абсолютно нормально, так как программу разрабатывал один или несколько разработчиков, которые в итоге пришли к своему пониманию того, “как пользователю будет лучше”. Да и к тому же, невозможно в одной программе уместить всё, что теоретически может захотеть сферический пользователь в вакууме. Или возможно?
Почему 2 функции в 1 приложении лучше, чем 1 функция в 1 приложении
Давайте на секунду отбросим все ограничения и представим что идеальный планировщик существует: он полностью соответствует вашим ожиданиям в плане интерфейса, предоставляет все необходимые вам функции и работает на всех ваших устройствах. Что это нам даёт? Ключевой особенностью такого приложения будет возможность использовать одни и те же данные для обеспечения работы всех функций приложения.
Смоделируем ситуацию — есть два пользователя, которые жить не могут без составления списка задач и использования техники Pomdoro. У обоих одинаковые потребности — разница лишь в том, какие приложения они используют для их удовлетворения:
- Пользователь#1 использует 2 популярных приложения: Todoist (список дел) и Productivity Challenge Timer (Pomodoro)
- Пользователь#2 пользуется нашим гипотетическим «идеальным» приложением
Пару слов о том, как происходит взаимодействие пользователя с программой в обоих случаях:
- Пользователь#1: заполняет список задач в Todoist, заполняет список проектов в Productivity Challenge Timer
- Пользователь#2: заполняет список задач внутри своей программы
Исходя из приведённой иллюстрации можно определить некоторые неприятные моменты, с которыми придётся столкнуться пользователю#1, в отличие от пользователя#2:
- Необходимость ручной синхронизации списка проектов в обоих приложениях
- Невозможность запустить циклы Pomodoro для включённых в проект подзадач
- Отсутствие объединённой статистики по выполнению задач — она хранится в разных приложениях
Если вас это не смущает, и вы считаете что можно обойтись и несколькими приложениями, то представьте что будет, если нужно обеспечить пользователя не двумя, а десятью функциями?
Решение проблемы
Хорошо, одно приложение в котором есть все нужные функции лучше, чем несколько приложений. Но нельзя же разрабатывать под все сочетания функций отдельную программу! Всё так и получается, если не использовать...и зачем его я ломаю комедию, в заголовке же написано было… модульный подход!
Главный секрет «идеального» приложения в том, что не надо пытаться «предугадать» что же пользователь там захочет, а позволить ему самому собрать своё «личное» приложение, которое как раз и будет максимально полно отвечать его желаниям и потребностям. Процесс сборки такого приложения будет заключаться в отбирании желаемых функций приложения и аспектов пользовательского интерфейса, которые будут представлены соответствующими модулями.
К тому же, очевидно, что если грамотно организовать процесс разработки подобного приложения, то общая трудоёмкость существенно сократится, так как реализованные функции никуда не исчезают — они лишь «запаковываются» в удобные для использования другими разработчиками модули.
Это не только теория
Чтобы эта статья не выглядела как бред спятившего на своей теории разработчика, я хотел бы показать как это всё работает на примере своего проекта. Я не буду пока описывать его в рамках данной статьи — сейчас лишь опишу саму идею. В общем, есть некое приложение X — на данный момент в нём можно подключать новые модули в систему, где каждый модуль может существенно изменить интерфейс и расширить доступные функции приложения.
Вот ситуация как в примере выше, когда модуль списка дел расширяется модулем Pomodoro:
На данный момент приложение находится в стадии разработки, и не готово к предоставлению доступа пользователям. Ещё много чего предстоит реализовать, но кое-что уже есть — вот, например, список рабочих функций приложения:
- Список задач — у задач есть следующие свойства: название, дата, выполненные Pomodoro, зарисовка
- Техника Pomodoro — запуск циклов Pomodoro для задач из списка задач
- Пользовательские зарисовки — создание зарисовок для сохранения в отдельной галерее или привязки к задачам из списка задач
Каждая из описанных функций представлена группой модулей, каждый из которых можно удалить, не повлияв на работоспособность всей системы — удаление модуля лишь исключит из системы соответствующую функцию, за которую он отвечал.
Перспективы
Под конец статьи я бы хотел поделиться с вами своими концептами по дальнейшему развитию и использованию этого проекта.
Описание: Приложение на смартфоне имеет данные, используя которые можно улучшить функционирование «умного дома», а именно: зная расписание дня можно настраивать освещённость, включать и выключать музыку в определённое время, запускать бытовую технику (при пробуждении, вернулся домой). При этом пользователь не должен вручную настраивать поведение этой системы, так как она использует те же данные, что и он (как в примере с Pomodoro).
Уже реализовать модули: список задач, взаимодействие с СУБД
Необходимо реализовать модули: интернет взаимодействие или Bluetooth, модуль общения с системой умного дома, модуль с логикой анализа расписания дня для умного дома
Описание: При длительном использовании приложения накапливается большой массив данных, которые можно использовать как входные для алгоритмов машинного обучения. Таким образом, можно будет с некоторой вероятностью предсказывать, когда пользователь будет выполнять задачи в зависимости от их срочности, важности или отношения к какой-либо сфере жизни. Используя предсказание, можно будет, например, в начале дня сгенерировать варианты того, как он мог бы провести сегодняшний день. При этом бы учитывались все сроки по текущим проектам и составлялось оптимальное расписание для сдачи их в срок.
Уже реализованные модули: список задач, взаимодействие с СУБД
Необходимо реализовать модули: модуль машинного обучения на последовательностях, модуль генерации «предсказаний»
Описание: Пользователь решает заняться спортом (бегать по утрам, делать зарядку). На смартфоне и ПК пользователь выбирает приложения и сайты, к которым ему будет урезан доступ. В случае невыполнения спортивных занятий, пользователь на некоторое время получает урезанный доступ к выбранным ресурсам. Контроль за выполнением спортивных занятий отслеживается по данным, полученным с браслета.
Уже реализованные модули: взаимодействие с СУБД
Необходимо реализовать модули: интернет взаимодействие или Bluetooth, модуль взаимодействия с фитнес-браслетом, модуль ограничения доступа к ресурсам, модуль контроля выполнения привычек
В данной статье я не рассматривал особенности реализации, дабы не перегружать текст деталями. Я обязательно освещу сам процесс разработки, но в рамках следующей статьи. Если кому-то интересно, то можно ознакомиться с уже реализованными модулями:
- MainMenuModel — хранит ссылки на подключенные в данный момент плагины
- MainMenuView — предоставляет UI главного меню
- TaskListModel — предоставляет доступ к пользовательским задачам
- TaskListView — отображает пользовательские задачи в виде древовидного списка
- PomodoroModel — предоставляет доступ к выполненным Pomodoro
- PomodoroView — предоставляет UI для запуска циклов Pomodoro и их просмотра
- TaskSketchModel — предоставляет доступ к пользовательским зарисовкам
- TaskSketchView — предоставляет UI для создания зарисовок
- AndroidNotificationsModel — предоставляет доступ к специфическим для платформы Android функциям
- ExtendableDataBaseManager — предоставляет доступ к абстрактным структурам данных, независимым от источника
- CipherDataBaseSource — предоставляет методы для взаимодействия с шифрующим плагином для СУБД SQLight
С исходным кодом можно ознакомиться по ссылке.
Спасибо за внимание.
Автор: Кирилл Крылов
