Почему я решил создать Droove

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

Большинство людей - визуальные существа. К сожалению, большинство компаний так не работают. Я хотел построить что-то, что восполнило бы этот пробел. Потребность в чем-то подобном стала для меня очевидной в несколько раз в моей карьере.

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

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

Я начал изучать такие инструменты, как Webflow, Zapier и Airtable. Я создал свой личный веб-сайт с помощью Webflow и кое-где использовал Zapier и Airtable для некоторых небольших проектов. Освоившись с ними, я понял, что хочу провести несколько недель, полностью сосредоточившись на Bubble. Я быстро понял, что у этого инструмента ТОННЫ потенциала. Я видел, как люди создают с его помощью приложения для торговых площадок, веб-сайты и многое другое. Однако я мало что видел в функциональных возможностях с точки зрения перетаскивания (отсюда и название, для всех, кому интересно) элементов в интерактивном рабочем пространстве, которое могло бы помочь рассказывать истории и поддерживать организованность команд. В какой-то момент я наткнулся на плагин для перетаскивания элементов. Когда я это обнаружил, я понял, что должен посмотреть, смогу ли я создать этот инструмент ... полностью без кода. Остальная часть этой истории - это мой ежедневный опыт попыток создания Droove.

ДЕНЬ 1–1 / 20/20

Поскольку у меня было некоторое представление о Bubble до начала сборки Droove, первое, что я хотел проверить, - это функциональность перетаскивания. Я знал, что если все будет не так хорошо, как я надеялся, весь этот проект закончится очень быстро. Несмотря на то, что у Bubble была справочная документация, я только начал с ней играть.

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

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



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

Идея заключалась в том, чтобы кто-то мог получить небольшое предварительное представление о том, как работает Друв, нажав на значок плюса. На экране появится небольшой текстовый элемент, и его можно будет перемещать. Это заняло немного больше времени, чем я думал.

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

Для структуры данных я установил новый тип под названием «демонстрация домашней страницы» с одним дополнительным текстовым полем. Поскольку это собиралось использовать только на домашней странице и кем-либо, я не беспокоился об отслеживании данных (может быть, мне следовало? Что, если эти дополнения медленно накапливались с течением времени, и я столкнулся с проблемами хранения в пузыре? Разве не уверен, но подумал, что смогу перейти этот мост позже).

После настройки структуры данных я добавил значок «+» на главную страницу и создал рабочий процесс для создания новой записи «демонстрационного текста домашней страницы» при каждом нажатии значка «+».

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

Приятно видеть… пока все двигалось довольно гладко. Следующим шагом будет отображение текстовых элементов «Hello» на главной странице при нажатии «+».

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

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

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

Во-первых, текстовый элемент можно было перемещать, но как только он был перемещен во внутреннюю групповую часть макета, он заметно исчезал со страницы. Я подумал, что это могло быть связано с порядком элементов на оси Z (спереди назад), но это все еще происходило после того, как синие и белые элементы снова и снова перемещались на передний план. Мое решение для этого заключалось в том, чтобы сделать внешнюю и повторяющуюся группы (красные и зеленые элементы) того же размера, что и сама домашняя страница, сохраняя при этом внутреннюю группу, группу перетаскивания и текстовый элемент исходного размера и в исходных координатах X, Y на странице. Как только я это сделал, текстовый элемент можно было свободно перемещать. Вот небольшая демонстрация.



Это вызвало другую проблему, которой я не ожидал. Помните, я сказал, что эти группы изначально должны быть скрыты при загрузке страницы, а затем отображаться при нажатии значка «+»? Что ж, это происходило, и теперь, когда внешняя и повторяющаяся группа занимала всю страницу, когда они были показаны, они были показаны перед значком «+» на оси z. Это будет означать, что пользователь сможет создавать и перемещать только 1 текстовый элемент на домашней странице. Я подумывал исправить это, но решил, что оно того не стоит. Я полагал, что пользователи поймут, создали ли они 1 элемент или 5 . У меня были более важные дела, о которых нужно было беспокоиться. Принятие этого решения также временно устранило вторую проблему, о которой я упоминал, с повторяющимися группами, но я знал, что с ней я столкнусь, когда перейду к пользовательскому интерфейсу.

ДЕНЬ 2–1.01.20

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

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

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

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



К сведению: если вы пытаетесь сравнить цвета на скриншоте из первого дня с цветами в этом видео, они не совпадают. Я понял, что, вероятно, мне следовало сохранить их последовательность, но не осознавал этого слишком поздно. Ой.

Так что это была первая серьезная проблема, с которой я столкнулся. Как сделать так, чтобы на экране каждый раз появлялись новые смычки в одном и том же месте?

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

Поразмыслив, я понял, что такой подход не сработает. Хотя это может создать желаемый эффект, поскольку новые кривые из структуры данных создания канавки отображаются в тех же координатах X, Y на экране, если канавка была перемещена в структуру данных активности канавки, мне все равно понадобится способ отображения кривой, которая теперь находилась в структуре данных активности. Проще говоря, если новый созданный канал был перетащен куда-нибудь на экране, он все равно должен был бы появиться в некоторых других координатах X, Y, когда он был перемещен для выполнения действия.

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

Немного поэкспериментировав, я понял, что это не сработает. Это прокручивает всю страницу до определенного элемента. Вы не можете выбрать прокрутку внутри самого элемента.

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

Ага! У меня было прозрение. Я думаю, что мог бы использовать рабочий процесс, чтобы скрыть внутренний элемент группы и уменьшить его высоту, как только пользователь щелкнет новую выемку, появившуюся на экране. Это должно привести к тому, что следующая дуга появится в том же месте.

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

ДЕНЬ 3–1 / 22/20

Со дня 2 я все еще не мог решить новую проблему с вмятинами. К счастью, накануне вечером, когда я чистил зубы, у меня было еще одно прозрение. Я понял, что не сортировал повторяющиеся группы. Если я помещаю повторяющуюся группу группировок в порядке убывания по дате их создания, самые новые группировки всегда должны появляться в одном и том же месте. Я попробовал, и оказался прав! Исправлена ​​еще одна проблема, но, конечно, это вызвало еще 2.

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

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

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

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



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

Мне было интересно, могу ли я настроить рабочий процесс, который переместил бы канавку на место предыдущей канавки? Еще я задавался вопросом, что будет, если я удалю сбои? Как это повлияет на движение? Мне нужно было настроить способ динамического отслеживания координат x и y, чтобы узнать местоположение смывов? Было ли это вообще возможно? В голове крутилось множество мыслей, и уследить за всеми деталями было непросто. Мне нужен был небольшой перерыв. Я взял перерыв на несколько часов.

После некоторого поиска в Google и проверки пузырькового форума я нашел плагин, который отслеживал бы координаты X и Y для элемента. На то, чтобы разобраться, потребовалось немного времени, но это позволяет создателю пузыря связать трекер с 4 элементами за раз. Я задавался вопросом, как бы я справился с этим, если бы на экране было больше 4-х дроу, но это был вопрос позже.

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

Из-за того, как пузырь позволяет вам подключаться к структуре данных в рабочем процессе, я смог попытаться выяснить это только с первым или последним элементом в моей структуре данных droove. Если бы у меня на экране появлялось сразу 10 сгустков, я понятия не имел, как я смогу использовать трекер для надлежащего отслеживания каждого отдельного смычка. Может быть, способ есть, но я чувствовал, что это ограничение в Bubble, которое я еще не понял. Я решил, что сейчас это лучше, чем ничего. К сожалению, это то, что мне удалось выяснить… ничего.

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

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

ДЕНЬ 4–23.01.20

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

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

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

На моем экране у меня был розовый элемент, который представлял собой трекер, кнопки добавления и удаления, которые я попытался добавить позже, и 4 кнопки, которые я мог перемещать по экрану. Для структуры данных я создал таблицу с 4 записями от 101 до 104, с номерами канавок и позициями X и Y в качестве полей. Позиции X и Y не были заполнены, поэтому мне пришлось настроить рабочие процессы, чтобы заполнять их при перемещении слюни.

Данные было достаточно легко настроить, но рабочие процессы - нет. Несмотря на то, что я хотел иметь отношение 1 к 1 (извините за другой термин в базе данных) между каналом и записью в таблице, рабочий процесс не выполнял бы то, что я хотел.

Каждый раз, когда щелкали и перетаскивали канавку, рабочий процесс должен был обновить новые координаты X, Y. Это было сделано путем получения обновленных координат X, Y через плагин для шага 1, а шаг 2 заключался в обновлении записи в таблице для соответствующего номера канавки (101, 102, 103, 104).

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

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



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

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

Как только это было сделано, пришло время посмотреть, будут ли координаты X и Y делать что-нибудь само по себе. Как видно из видео, этого не произошло. Когда я перемещал свои группы, выходил из системы и снова входил в систему, они были на своих исходных местах, а не на тех местах, куда я их переместил.



Это должно было быть что-то еще, что мне нужно было решить. Можно ли было сохранить эти элементы на месте? Если да, то как? Может мне нужно было использовать кастомные состояния? Что-то другое? Все, что я знал, это то, что сейчас полночь, и у меня закончился еще один день работы над этим.

ДЕНЬ 5–1 / 24/20

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

Я потратил много утра и после обеда, исследуя координаты X и Y пузыря на форумах, в слабых группах и в поиске в Google. В какой-то момент я наткнулся на сообщение на форуме Bubble Эммануэля, одного из основателей Bubble. Это был пост, в котором объявлялось о новом плагине перетаскиваемых элементов еще в 2016 году. В нем был разговор о хранении координат X и Y для людей, пытающихся делать что-то похожее на то, что я пытался сделать сейчас. В какой-то момент он упомянул, что Bubble добавил способ сохранения координат X и Y.

Это привлекло мое внимание, потому что я думал, что единственный способ сделать это - установить плагин. Я вернулся к рабочему процессу и создал новый без плагина, и был ошеломлен, когда он заработал. Это не только сработало, но и заставило меня работать в подходе повторяющихся групп, который я изначально использовал. Это был ОГРОМНЫЙ шаг вперед, и я был очень взволнован. Также это был один из тех моментов, когда долгий перерыв помогал. Меня ошеломило то, как быстро я понял это… один из тех моментов, которые случаются у всех, когда вы думаете: «Как я не понял этого раньше?». Лучше поздно, чем никогда.

Я протестировал мой новый рабочий процесс без ошибок. В режиме предварительного просмотра я переместил несколько тупиков в повторяющейся группе и пошел посмотреть свои данные. Мои поля позиции X и Y были заполнены.

В дополнение к этому, я также выяснил, как заставить слюни оставаться в одном и том же положении, когда пользователь покидает страницу и возвращается позже. Для простоты я вернулся в свою песочницу, но я настроил рабочий процесс для загрузки страницы, который перемещал перетаскиваемые элементы в их позиции X и Y, которые теперь сохранялись в структуре данных слива. Это определенно было не так гладко, как я надеялся, но это сработало. Я был готов принять это, пока. Я надеялся, что смогу понять это и в повторяющихся группах. Если бы я мог, то смог бы перейти к большей части управления работой в Droove.

ДЕНЬ 6–1 / 25/20

В этот день я не тратил много времени на Друва, но немного поработал. Мне нужен был простой способ удалить слюны, и я думаю, что разобрался с этим. Помимо хранения координат X и Y, плагин перетаскиваемого элемента также имеет так называемую область перетаскивания. Это элемент, который можно разместить на странице, и когда элемент перетаскивается на него, он запускает рабочий процесс. Самый простой способ подумать об этом - это, вероятно, вставить ключ (элемент) в замок (область перетаскивания) и открыть дверь (рабочий процесс).

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

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

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



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

Далее вы можете видеть, что канавка 16 - единственная канавка в повторяющейся группе. Если я нажму кнопку «добавить», появится новая выемка, но канавка 16 исчезнет. Если я добавлю еще несколько, в конце концов снова появится канавка 16. Это было бы проблемой, если бы моя область падения заставляла временно исчезать слюнки, которые все еще существуют.

ДЕНЬ 7 27.01.20

Я взял выходной, поработав над Droove. На данный момент мне нужно было решить 4 проблемы.

  1. Как перемещать слюни и свободно размещать их, даже используя площадку для сброса
  2. Как сделать так, чтобы слюнки не исчезли временно при добавлении новых слюн (также относится к области сброса).
  3. Если канавка добавлена ​​/ удалена, как обеспечить автоматическое перемещение канавки в правильное место
  4. Могу ли я переместить сгустки в их последнее сохраненное положение X и Y всякий раз, когда страница загружается мгновенно (в настоящее время это было с задержкой и очень заметно для пользователя)

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

Я хотел, чтобы эта часть инструмента была как можно проще… по крайней мере, для начала. Я не был уверен, с чего начать, поэтому сделал несколько набросков. Один набросок был о том, как может работать отдельный желоб и как управлять им в зависимости от того, что пользователи хотят видеть. Идея состоит в том, что стрелкой может быть текстовое поле для заметок, изображения, файла, задачи или, может быть, чего-то еще.

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

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

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

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



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

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

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

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

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

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

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

Определенно был метод проб и ошибок, но в конце концов я понял это. Изначально у меня было поле «товарищи по команде» в предварительно созданной таблице User, которую я создал как список. Я подумал, что смогу использовать повторяющуюся группу, чтобы показать всех товарищей по команде текущего пользователя на странице команды. К сожалению, мне не удалось заставить это работать. После некоторого исследования кажется, что повторяющиеся группы могут отображать разные записи в таблице, но не разные элементы списка внутри записи. Это также создало проблему, потому что в масштабе не было простого способа гарантировать, что все товарищи по команде текущего пользователя, который подписался на Droove, окажутся в этом поле товарищей по команде.

В итоге я получил предварительно созданную таблицу User и новую таблицу Team. Мне нужно было придумать способ присоединиться к ним, поэтому я установил поле в таблице User под названием «User Team Name». Я установил тип поля как «Команда», который будет брать данные из таблицы «Команда». Это известно как составной тип поля, что было для меня в новинку. Я не думаю, что у Bubble есть лучшая документация по этому поводу, потому что мне сначала было трудно понять, как это работает. Моя первоначальная цель заключалась в том, чтобы пользователь создал команду при регистрации, и рабочий процесс должен был: 1) создать новую запись в таблице Team с этим именем команды и 2) изменить запись пользователя в таблице User, чтобы создать созданный название команды в качестве поля имени группы пользователей. Шаг 1 сработал, а шаг 2 - нет. Я пробовал несколько разных вещей с помощью рабочего процесса, но постоянно получаю ошибки несоответствия типов между типами данных «команда» и «текст». В конце концов мне удалось наладить рабочий процесс, но вместо того, чтобы указывать название команды в поле «User Team Name» в таблице User, вместо этого он поместил уникальный идентификатор для команды. Я решил, что это было достаточно близко, поэтому я изменил свою таблицу «Пользователь» на поле «Идентификатор команды».

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

ДЕНЬ 8.01.20.

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

  1. Как перемещать слюни и свободно размещать их, даже используя площадку для сброса
  2. Как сделать так, чтобы слюнки не исчезли временно при добавлении новых слюн (также относится к области сброса).
  3. Если канавка добавлена ​​/ удалена, как обеспечить автоматическое перемещение канавки в правильное место
  4. Могу ли я переместить сгустки в их последнее сохраненное положение X и Y всякий раз, когда страница загружается мгновенно (в настоящее время это было с задержкой и очень заметно для пользователя)

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

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

ДЕНЬ 9 29.01.20

Я решил, что буду использовать подход «клейкая лента и пластырь». Несмотря на то, что у меня не было возможности создать продукт, на который я надеялся, я подумал, что это, по крайней мере, позволит мне показать кое-что за свои усилия и, надеюсь, почерпнуть некоторые идеи. Я тоже решил, что поставлю крайний срок на это… 14 дней работы.

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

Чтобы это сработало, мне нужно было построить слюнки. Из моего наброска на 7-й день у меня появилась идея разместить на странице перетаскиваемую группу. Внутри этой перетаскиваемой группы будет группа многострочного ввода, в которой пользователи могут делать заметки, загрузчик изображений и загрузчик файлов, а также кнопка, которая будет создавать новую задачу. Эти элементы будут скрыты при загрузке страницы. Когда пользователи первоначально нажимали на желобок, появлялось всплывающее окно с вопросом, какой тип желоба им нужен, будь то заметка, изображение или файл. В зависимости от того, что они выбрали, запускался рабочий процесс, который превращал грохот в то, что они хотели. Оттуда его можно было перемещать.



Как видите, получилось не так, как я хотел. Мне удалось создать заметку, но функция перетаскивания оказалась не такой хорошей, как я надеялся.

ДЕНЬ 10.01.20.

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

Визуальное рабочее пространство просто не могло достичь того, чего я хотел. Несмотря на то, что я мог бы продолжить использование сверхпростого инструмента управления работой без визуального рабочего пространства, я чувствовал, что это уже насыщенный рынок. Я знал о таких инструментах, как таблицы Google и trello, но я также нашел другие инструменты, такие как приложение taco. Это были инструменты, которые были на более упрощенной стороне управления работой и имели модель ценообразования freemium. Дело в том, что эти инструменты могли делать то, что я хотел, если не больше, бесплатно.

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

Подводя итоги, у меня есть несколько мыслей на прощание ...

  1. Несмотря на то, что у Bubble много функциональных возможностей, у него все же есть свои ограничения. Мне кажется, что я выбрал довольно амбициозную идею продукта для решения без кода, но я рад этому. Я чувствую, что узнал много нового о нюансах этого инструмента, которых я, возможно, не узнал бы, если бы решил создать что-то более традиционное, что уже было сделано раньше.
  2. Стоит ли мне пытаться создавать только те вещи, которые я как-то проверял у других пользователей? Что касается управления работой, я знаю, что есть желание иметь больше визуальных инструментов. Такие инструменты, как Mural, Notion, а также Ideapaint, доказывают, что визуальный эффект хорош. Я также видел множество свидетельств, подтверждающих это. Однако до того, как я начал, я никогда прямо не спрашивал никого, будет ли им интересен такой инструмент. В данном случае меня это устраивало, потому что это был способ выучить Bubble, пытаясь создать что-то, что меня интересовало. Теперь, когда я знаком с Bubble, это, вероятно, будет больше требованием для проектов, которые я продолжать идти вперед.
  3. Стоит ли создавать что-то без кода, если это нерентабельно? Опять же, я мог бы создать Droove как инструмент управления работой, и это, вероятно, было бы довольно крутым достижением без кода, но я не думаю, что у него будет шанс заработать деньги. Должен быть баланс между созданием чего-либо без кода, потому что вы можете, и фактическим зарабатыванием / экономией денег.
  4. Стоит ли мне транслировать видео в прямом эфире вместо того, чтобы писать в будущем? Это то, с чем я борюсь. С одной стороны, прямая трансляция определенно кажется лучше с точки зрения контента, так как в режиме реального времени легче объяснить, что происходит. Однако мне нравится писать, потому что я считаю, что это лучший навык для меня. Кроме того, возвращение между написанием и делом помогает мне обдумывать проблемы и придумывать новые идеи. Не знаю, как бы это отразилось, если бы я транслировал свою работу в прямом эфире.

Первоначально опубликовано на https://www.mattpupa.com.