Что ж, я не сдержал своего обещания в своей прошлой статье четко, но если вы всегда смотрите на прошлые ошибки, вы не сможете исправить их в будущем. В своей прошлой статье я рассказал о том, как мне захотелось изменить это издание, а точнее начать писать для него (если вы еще не заценили, то можете посмотреть прямо здесь). Однако я забыл упомянуть одну вещь. Как дизайнеры, мы должны смотреть на мир и видеть дизайн во всем, но мы также должны ценить хороший дизайн, как форму, так и функцию. Поэтому для этого я время от времени буду писать статьи о каком-то продукте или дизайне, который действительно хорошо разработан. Для нашей первой демонстрации мы начинаем с хакатона StarterHacks. Мои друзья (включая меня) создали приложение, чтобы помочь другим решить простую проблему: ожидание в очереди. Теперь без лишних слов, давайте посмотрим, что это такое.

Встретить команду

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

Шивам Пандей — студент факультета математики Университета Ватерлоо.

Шивам хорошо разбирается в Python, что было необходимо для разработки этого приложения. Что еще более важно, он знал, как визуализировать проблему и логически связать все действия, которые нам нужно было предпринять, и действия, которые предпримет пользователь. Он отвечал за соединение всех систем воедино.

Али Зохейр — студентка факультета математики Университета Ватерлоо.

Али быстро учится, а это значит, что он может адаптироваться к любой ситуации, с которой мы сталкиваемся. В случае с нашим приложением нам нужно было хранить номера телефонов в базе данных. Именно здесь Али проявил себя, изучив и внедрив простую базу данных для хранения информации.

Хоссейн Мохебби — студент компьютерных наук, Университет Ватерлоо

Хоссейн знал, что это приложение должно использовать какой-то сторонний API, и изучил основы API Twilio, чтобы мы могли управлять взаимодействием с пользователем через MMS. Он также занимался бизнесом, помогая разрабатывать презентацию и ключевую графику.

Так что же такое контроль толпы?

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

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

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

Как это работает

Приложение использует 4 компонента. Мы создали дашборд в React для фронтенда. Это было достаточно просто для использования любым органайзером и масштабируемо. Что еще более важно, информационная панель только отправляет информацию в API. Это означает большую безопасность, поскольку данные взаимодействуют только между сервером и API, что означает меньший доступ. Это подводит нас к основной части приложения: Flask API. API Flask действует как станция переключения поездов. Он получает вызовы от панели управления, которая либо получает данные из базы данных SQLite, либо передает информацию в Twilio API. Мы использовали Axios и Flask для связи между интерфейсом для создания шаблонов вызовов, что было проще, чем использование Fetch, потому что нам нужны были только команды POST. Мы создали базу данных SQLite, потому что она может использовать локальное хранилище и легковесна, что является ключевым фактором в нашем дизайне. Наконец, мы создали отдельный обработчик API Twilio, который взаимодействует с приложением для обмена сообщениями на телефоне. Это также помогло с масштабируемостью, поскольку нам нужно было изменить только определенные переменные. Относительно просто в теории, гораздо сложнее на практике.

Итак, что случилось?

Во время разработки вся наша команда как на палубе работала над отдельным компонентом. Интерфейс React был сделан максимально простым для поля. Основными аспектами были серверные компоненты. Использование Twilio позволило нам не только отправлять сообщения на все типы телефонов, но и позволило масштабироваться до Facebook Messenger, Whatsapp и электронной почты. В нашем выборе базы данных использовалась одна таблица с тремя столбцами: номер телефона, статус (логическое значение) и очередь. Статус сообщает нам, звонили ли человеку уже. Чтобы запрос вызывал пользователя, мы должны передать ему номер очереди, а затем количество людей, которых мы хотим. Затем мы выберем людей, у которых статус ложный, а номер очереди — тот, который нам нужен, и мы вернем список этих номеров в API Flask и вызовем API Twilio, чтобы отправить сообщение этим пользователям. Затем мы удаляем эти строки из таблицы. Преимущество этой системы в том, что внешний интерфейс не видит чисел и, следовательно, более безопасен.

Что мы узнали

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

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