Droove - Documenting 10 Days of Building a No-Code Tool
WHY I DECIDED TO BUILD DROOVE - 1/20/20
I wanted to build a tool like Droove because I felt there was an opportunity in the digital workspace market. There were plenty of work management tools out there that helped teams stay organized, and track their work, but I thought most of them were missing a key aspect...visual interaction.
Most humans are visual creatures. Unfortunately, most companies don't work that way. I wanted to build something that filled that gap. The need for something like this became clear to me in a few different times in my career.
The first was when I started consulting for a small remote team. I always wrote very clear emails and messages, and felt that I could communicate really well in written form. However, there were times when being able to draw and map things out on a whiteboard in person would have helped. The second was when I started working for very large company. I was on an analytics team and we had stakeholders all throughout the organization. I worked with product managers and engineers who were on different teams, had different messy reporting relationships to management, and had different goals for their teams. Not only that, but a giant re-structure happened while I was there, and it was never explained very well after it was finished. Although we used some of the popular tools to keep track of our work, I never felt like I had a clear idea of what teams were working on what, how things should be prioritized across teams, and what the true impact of my work was.
Even though I thought a tool like this could help a lot of people, I never thought I’d be able to build it. I knew a little bit of python, but definitely didn’t have the programming experience necessary, and I wasn’t going to look for outside help for something that may not come to fruition. It wasn’t until I started playing with no code tools that building something like this seemed more realistic.
I started exploring tools like Webflow, Zapier, and Airtable. I built my personal website with Webflow, and had used Zapier and Airtable for some small projects here and there. After getting comfortable with those, I knew I wanted to spend a few weeks pretty focused on Bubble. I quickly realized this tool had TONS of potential. I’d seen people build marketplace apps, websites, and a few other things with it. However, I hadn’t seen much with functionality in terms of dragging and moving (that's where the name came from, for anyone who was wondering) elements around on an interactive workspace that could help tell stories and keep teams organized. At one point, I came across a plugin for dragging and dropping elements. When I found that, I knew I had to see if I could build this tool....entirely without code. The rest of this story is my experience each day of trying to build Droove.
DAY 1 - 1/20/20
Since I had some understanding of Bubble prior to starting the Droove build, the first thing I wanted to check out was the drag and drop functionality. I knew if that wasn’t as good as I hoped, this whole project was going to be over very quickly. Even though Bubble had some reference documentation, I just started playing with it.
I put a drag/drop group into my page, and then put a text element inside that group. When I clicked preview. I was happy to see that it worked. My assumption was that a drag and drop group allowed any element inside of it to be moved around. I made my drag and drop group the width and height of my screen, and put another element in there to test. When I hit preview, I realized my assumption was wrong. When clicked in preview mode, any elements inside that drag and drop group, were picked up at the same time, and moved around together. This wasn’t what I wanted, since I wanted to be able to move drag and move each element around on its own.
My next thought was that maybe you need to put a drag and drop group around each individual element that you want to move on the screen. I tested that next. I had two drag and drop groups on my page, with a text element inside each one. When I clicked preview this time, I was able to move the text elements individually on the screen. This was exactly the start I wanted to see.
Now that I had that out of the way, the next part was building a workflow to get movable elements to appear on the screen at the click of a button. I wanted to do something cool for the homepage, while keeping the minimalist feel to it. I came up with this…
The idea was that someone could get a little preview of how Droove worked by pressing the plus icon. A little text element would appear on the screen, and they could move it around. This took a little more work than I thought.
To get this to work, I knew that I needed to set up some type of data structure, set up several workflows, and use repeating groups along with drag and drop groups.
For the data structure, I set up a new type called ‘homepage demo’ with one additional text field. Since this was only going to be used on the homepage, and by anyone, I wasn’t worried about tracking the data (Maybe I should have been? What if these additions slowly accumulated over time and I ran into storage issues in Bubble? Wasn’t sure, but figured I could cross that bridge later).
Once I had the data structure set up, I added my ‘+’ icon to the homepage, and created a workflow to create a new record of ‘homepage demo text’ each time the ‘+’ icon was clicked.
After that was set up, I went to the Droove homepage in preview mode, and clicked the ‘+’ icon 7 times. I went into the data page of bubble, and saw that the workflow was working, and that 7 records of ‘homepage demo text’ were created.
Great to see...everything was moving pretty smoothly so far. The next step would be to now get those ‘Hello’ text elements to actually appear on the homepage when ‘+’ was clicked.
My original idea was that I would allow people to create unlimited ‘hello’ text elements as they wanted, and they could play with them freely on the homepage. I knew that I’d need to use a repeating group to produce the text elements, as well as a workflow to make them hidden on page load, but visible on a ‘+’ click.
The setup for the repeating group was important. It took awhile to figure out. Here’s the setup I used.
After connecting these groups to the ‘homepage demo’ data structure, the idea was that each time the ‘+’ icon was clicked, a new inner group would be created within the repeating group, and then shown on the homepage. From there, someone would be able to click and move the text element around. Essentially, the red, green, and orange elements would stay in place on the page, but the blue and white elements would be clickable and draggable by the user. I was able to get this to work, but ran into 2 problems.
First, the text element could be moved around, but once it was moved into the inner group part of the layout, it visibly disappeared from the page. I thought this may have been from the order of the elements on the z-axis (front to back), but It was still happening after bringing the blue and white elements to the front over and over. My solution for this was to make the outer and repeating groups (red and green elements) the same size as the homepage itself, while keeping the inner group, drag drop group, and text element the original size and at the original X,Y coordinates on the page. Once I did that, the text element was able to be moved freely. Here’s a quick demo.
This caused a different problem that I didn’t expect. Remember when I said that these groups would originally have to be hidden on page load, and then shown when the ‘+’ icon was clicked? Well that was happening, and now that the outer and repeating group were taking up the whole page, when they were shown, they were shown in front of the ‘+’ icon on the z-axis. This would mean that a user would only be able to create and move around 1 text element on the homepage. I thought about fixing this, but decided it wasn’t worth it. I figured users would get the point whether they created 1 element, or 5. I had more important things to worry about. Making this decision also temporarily eliminated the 2nd problem I mentioned with the repeating groups, but it was one I knew I’d face when I got to the UI.
DAY 2 - 1/21/20
My 2nd day of building Droove was focused on the main UI which was the visual workspace users would see when they signed up / logged in. I reproduced the repeating group setup I used before, but I knew this would get more complicated since I needed to build in more functionality.
The first thing was setting up a more robust data structure. I wanted to simplify the terms for the elements users were adding to their workspace. Rather than call it a ‘thing’ or an ‘element’, I decided to call it a ‘droove’. I figured that would cement the idea that a ‘droove’ could be created, and could be turned into almost anything, ranging from a simple note, an image, a file, all the way to a task that tracked work, like a traditional work management tool. As a first version, I set up a droove data type with fields of ‘droove color’ and ‘droove type’.
I put in entries for 3 new records, giving the drooves colors of red, blue, and green, and types of note, note and note. This didn’t mean anything yet, so don’t worry about that too much. Just remember that I created 3 records. During day 1, I mentioned that I had a 2nd problem with the repeating group setup that I was going to need to fix. Well, now was the time to try and fix it.
In my head, I was picturing that each time a new droove was added to the workspace, it would appear on the screen at the same X,Y coordinates, and users could move it around from there. However, what actually happened is that each new droove that was created in my repeating group, would appear below the previous Droove. This had an effect of new drooves appearing to be hidden on the workplace, unless you scrolled down on the repeating group. I knew I needed to come up with a way to fix this.
Just an FYI, if you’re trying to compare the colors in screenshot from day 1 to the colors in this video, they don’t match up. I realized I probably should have kept them consistent, but I didn’t realize that until too late. Oops.
So this was the first big challenge I came across. How do I get new drooves to appear on the screen in the exact same spot each time?
My first thought was that maybe I needed another data structure for drooves. The first one that I already had would be for droove creation, and the second would be for droove activity. If there was a workflow trigger to move a droove from the droove creation data structure to the droove activity data structure, this may give me the visual effect I want on the repeating group elements. In programming, I believe this is called the fifo (first in, first out) approach.
After thinking about it, I realized this approach wouldn't work. Although it may create the effect I want as far as new drooves from the droove creation data structure showing up on the same X,Y coordinates on the screen, if the droove was moved to a droove activity data structure, I’d still need a way to display the droove that was now in the droove activity data structure. In simpler terms, If a new droove that was created was dragged somewhere on the screen, it would still have to appear at some other X,Y coordinates when it was moved to droove activity.
A second thought popped into my head. What if there was a workflow that could be built that would automatically scroll to new drooves that were created? Similar to an assembly line, new drooves would be created, but the action (droove appears on screen), always happens at the same spot. In the workflow, there’s an element action to scroll to a certain element, with a pixel offset. I didn’t know what that was, so I played around with it.
After experimenting for a bit, I realized this wasn't going to work. This scrolls the whole page to a certain element. You can’t choose to scroll within an element itself.
I wondered if there was a way to have a new record in a data structure show up dynamically somewhere on the screen. If so, maybe I could use the fifo approach I mentioned above?
Aha! I had an epiphany. I think I could use a workflow to hide the inner group element, and collapse its height, once a user clicked on the new droove that appeared on the screen. This should cause the next droove to be created to show up in the same spot.
This didn’t work either. I ran into weird workflow rules about which elements you could hide, based on which elements triggered the workflow. I just needed a way for the data in the repeating group in the groove creation data structure to be deleted, without deleting the new droove that I was creating.
DAY 3 - 1/22/20
I was still stuck on the new droove problem from day 2. Fortunately, I had another epiphany while brushing my teeth the night before. I realized I hadn’t put a sort on the repeating groups. If I put a descending sort order on the repeating group of drooves by their creation date, the newest drooves should always appear on the same spot. I tried it, and I was correct! Another problem fixed, but of course, this caused 2 more.
Since I only wanted 1 new droove to appear on the screen at a time, I set up my repeating group to show 1 row and 1 column. This setup, along with having the repeating group take up the whole screen, was a problem. Each time a new droove was created, the current one was moved down, so the whole UI that the user was seeing on their screen was being replaced each time, which would cause any previous drooves to disappear...not good. I wasn’t sure what to do so I took a break for a few hours, hoping I’d come back with fresh eyes.
When I came back, I realized the 1 row 1 column repeating group problem wasn’t a hard problem to solve. Initially I was thinking that I’d want the drooves to appear in the middle of the screen, but having them appear in the top left corner was fine. I changed the repeating group to be 5 rows and 5 columns. Since new drooves would now appear in the top left corner and could now move freely around the screen, this would work for me.
The other problem I had to fix now was that when I dragged a droove that was just created to the different part of the repeating group on the screen, the next droove created after it would appear at that same spot, and not the top left corner like I intended. In fact, this was happening with all the drooves. If I moved any drooves around, when a new droove was created, all the drooves would move to the last location of the droove created right before it.
I realize this is confusing, so here’s a video showing what I’m trying to explain. I’ve numbered the new drooves coming in, so you can see the order they are created.
You can see that each new droove that’s created is appearing on the screen in the same spot in the top left corner of the repeating group. That’s exactly what I wanted to solve on day 2, so that issue was now fixed. However, when I dragged a droove into a different spot, the new drooves created after it would appear at the dragged location of the one before it. That was a problem because it meant all the drooves on the screen would be starting at a different spot each time a new droove was added.
I wondered if I could set up a workflow that would move a droove to the location of the previous droove? I also wondered what would happen If I deleted drooves? How would this affect the movement? Did I need to set up a way to dynamically track x and y coordinates to know the location of drooves? Was that even possible? There were a lot of thoughts spinning in my head, and it was tough to keep track of all the details. I needed a little bit of a break. I took a few hours off.
After some google searching and checking out the bubble forum, I found a plugin that would track X and Y coordinates for an element. It took a little while to figure out, but it allows a bubble creator to link a tracker to 4 elements at a time. I wondered how I’d handle this if there were more than 4 drooves on the screen, but that was a question for later.
Through a lot of trial and error with a simple setup I made for testing, I figured out how to use the tracker and I was able to store an element’s X and Y coordinates in a sandbox data structure. I was happy about it, but I still needed to apply this logic to my repeating groups element that was showing all of the drooves, and that was connected to my actual droove data structure. This was a nightmare.
Because of how bubble lets you connect to a data structure in a workflow, I was only able to try and figure this out with the first or last item in my droove data structure. If I ended up having 10 drooves on the screen at once, I had no idea how I’d be able to use the tracker to appropriately track each individual droove. Maybe there was a way, but I felt like that was a limitation in Bubble I hadn’t figured out yet. I figured that was better than nothing for now. Unfortunately, that’s what I was able to figure out...nothing.
I ran into a lot of issues here with how the tracker interacted with the element hierarchy I had set up. I tried setting up the tracker outside of the outer group, within the outer group, within the repeating group, and at every other level of the hierarchy. Regardless of what I tried, I couldn’t get the X,Y coordinates to save in my droove data structure when I was using the tracker in this more complicated setup.
I spent a long time playing around with different ideas, whether that was continuing to change the position of the tracker, changing workflows, changing elements within workflows, but nothing seemed to work. I’d get errors from the plugin in preview mode. This was especially frustrating because it was a plugin from someone other than Bubble, so I had no documentation to help me fix this. After putting my mind into a pretzel, I decided it was enough for the day, and that I should step away. I was hoping a break would help me figure this one out.
DAY 4 - 1/23/20
Before I opened up Bubble, I wanted to take a step back. I knew I was too deep into the weeds at the moment. Up to this point, I’d been using the repeating groups approach because that was my understanding on what was required to attach data to a data structure, and also show it on the screen...but what if there was another way?
When I was playing on my sandbox page, it was much simpler and I had more of the functionality I wanted. I could drag my few elements around the screen freely, without having to worry about the repeating group complexity. I assumed that this approach wouldn’t scale, because there wasn’t a way to link these elements to an actual data structure. I started to question whether that was a correct assumption. I got out a pen and some paper.
I started sketching out the current approach I was taking (left), and an approach that I could maybe take (right). Since the benefit of the current approach was scale, and the benefit of the maybe approach was functionality, I decided I should try the maybe approach. If you don’t have a working product, being able to scale it doesn’t matter. I decided that I’d pre populate a droove data structure with 4 drooves, create 4 droove elements on my screen, and try to join (or link, for the non database folks) them with some type of ID.
On my screen I had a pink element, which was the tracker, add and delete buttons that I’d try to incorporate later, and 4 drooves that I could move around on the screen. For the data structure, I set up a table with 4 records for 101 to 104, with droove number, and X and Y positions as the fields. X and Y positions were unpopulated, so I had to set up workflows to populate them when the drooves were moved around.
The data was easy enough to set up, but the workflows were not. Even though I wanted to have a 1 to 1 relationship (sorry for another database term) between a droove and a record in the table, the workflow wouldn’t do what I wanted it to do.
Anytime a droove was clicked and dragged, the workflow was supposed to update the new X,Y coordinates. This was done by pulling the updated X,Y coordinates via the plugin, for step 1, and step 2 was to update the record in the table for the matching droove number (101, 102, 103, 104).
I think the workflow struggled with the ‘1 to 1’ and ‘1 to many’ relationship between the droove and the data. Although I was trying to link 1 droove to 1 record by filtering the list of drooves on droove number (1 to 1), the workflow was recognizing it as me trying to update a list of records(albeit filtered) based on 1 droove (1 to many). I played around with the workflow, but nothing was working. I realized my best bet was to create a table for each droove with 1 record each. Very annoying, but I’d see how it would run.
Although it was very time consuming to set this up manually, it did work as intended. I could move any of the droove around on the screen, and when I looked at the data, the X and Y coordinates were updating correctly.
In addition to knowing the X and Y coordinates of the drooves for the repeating group approach I worked on the first 3 days, I also expected it to be important for users who were logging out and logging back into the Droove platform. I wanted to make sure users could move drooves around in their workspace, and they would stay in place each time they logged into the product. I figured I’d test that next.
For this, I had to build sign up and login functionality. Thankfully I had done this before, so I set up a pop up on the homepage that collected email, passwords, and could determine if people were signing up or logging in to an account they created previously.
Once that was done, it was time to see if having the X and Y coordinates would do anything on its own. As the video shows, it did not. When I moved my drooves around, logged out, and logged back in, they were in their original places, not the places I moved them to.
This was going to be something else I’d have to solve. Was it possible to keep those elements in place? If so, how? Maybe I needed to use custom states? Something else? All I knew was that it was midnight, and I was done with another day of working on this.
DAY 5 - 1/24/20
Day 5 was a good day. I was getting pretty discouraged that this may not end up where I want it to. The new approach I was taking seemed way too clunky, and the original approach with the repeating groups seemed too ambitious.
I spent a lot of the morning and afternoon researching bubble X and Y coordinates on forums, slack groups, and google searches. At one point, I came across a post on the Bubble forum by Emmanuel, who is one of the founders of Bubble. It was the post announcing the new draggable elements plugin back in 2016. In the post, there was some conversation about storing X and Y coordinates, for people trying to do things similar to what I was trying to do now. At one point in the thread, he mentioned that Bubble added a way to save the X and Y coordinates.
This caught my attention because I thought the only way I was able to do it was with the plugin I installed. I went back to the workflow, and created a new one without the plugin, and was stunned when I got one to work. Not only did it work, but I got it to work in the repeating groups approach I initially used. This was a HUGE step forward, which I was super excited about. It was also one of those moments where taking a long break helped. It stunned me how quickly I figured this out...one of those moments everyone has where you think ‘How did I not get this before?’. Better late than never.
With my new workflow error free, I tested it out. I moved some drooves around in the repeating group while in preview mode, and went to look at my data. My X and Y position fields were now populated.
In addition to that, I also figured out how to get drooves to stay in the same position when a user left the page, and came back later. I went back to my sandbox for this for simplicity, but I set up a workflow for the page load that would move the draggable elements to their X and Y position that was now being saved in the droove data structure. It definitely wasn’t as smooth as I hoped, but it worked. I was willing to take it, for now. I was hoping I could figure this out in the repeating groups as well. If I could, then I’d be able to move on to more of the work management part of Droove.
DAY 6 - 1/25/20
I didn’t spend much time on Droove this day, but I did get a little bit done. I wanted an easy way to delete drooves, and I think I figured it out. Along with storing X and Y coordinates, the draggable element plugin also has something called a drop area. This is an element that can be put on a page, and when an element is dragged over it, it will trigger a workflow. The simplest way to think about this is probably inserting a key (the element) into a lock (the drop area), and having a door open (the workflow).
My intention was to have this drop area trigger the deletion of whatever droove was dropped into it. For simplicity's sake, I didn’t want this drop area to be on the screen the whole time. I only wanted it to show up if someone had clicked and was pressing on a droove. I was able to set up conditional logic for the drop area to only show it when that click and press happened.
The next step was setting up the workflow to trigger the actual deletion of the droove. This was pretty straightforward, thankfully. After I set this up, I made sure that my draggable droove was able to be dropped. I tested it out in preview mode, and it worked.
It seems to be a running theme as I’ve written this whole process so far, but 2 new issues came out of this. First, I could no longer drag drooves freely around the screen, unless I was dropping them in the drop area. If I tried dropping them somewhere else, they moved back to their original position. Second, the deletion of the droove seemed to be more related to the position of the repeating group vs. the droove itself. Here’s a video to explain what I mean.
In the video above, you can see that when I drag droove 15 around the screen, I move it towards the bottom left of the repeating group. When I let go of my mouse, it automatically moves back to where I initially clicked it from. It seems that having a drop area may override the functionality to drag elements freely. Eventually, I drop it in the drop area, and droove 15 is deleted.
Next you can see that droove 16 is the only droove in the repeating group. If I click the ‘add’ button, a new droove appears, but droove 16 disappears. If I add a few more, droove 16 eventually reappears. This would be a problem if my drop area causes drooves that still exist, to temporarily disappear.
DAY 7 1/27/20
I took a day off from working on Droove. At this point, there were 4 problems that I needed to solve.
- How to move drooves around and place them freely, even while using a drop area
- How to make sure drooves don’t temporarily disappear when new drooves are added (also related to drop area).
- If a droove is added/deleted, how to make sure the drooves are moved to the correct spot automatically
- Can I move the drooves to their last saved X and Y position whenever the page is loaded instantaneously (This was currently on a delay, and very visible to the user)
I probably had more in my mind, but these were the ones that I knew I had. I didn’t want to get burned out on building this, so I decided to shift my focus to more of the work management part of the tool. This would include a page for reporting on drooves, how to comment on a droove, how to change the appearance of a droove, and so much more.
I wanted to keep this part of the tool as simple as possible...at least to start. I wasn’t sure exactly where to start so I drew out some sketches. One sketch was for how an individual droove might work, and how to manipulate it based on what users want it to be. The idea is that a droove could be text box for notes, an image, a file, a task, or maybe something else.
The rough idea I had was that a droove would start as a drag/drop element, with text/image/file groups hidden or behind it. Based on the droove type that user selected, the appropriate group would then be shown, and users could interact with it accordingly.
The other thing I started sketching was the general layout of the UI. To start, I figured I needed a page for the team/account management, a page for reporting, a page with the drooves to show current tasks, and maybe a page for stakeholders to submit a droove.
I made a few visuals of what these could look like, just so I could have something to work towards. I decided I would work on the team page first.
The team page needed to have a few different features, including the ability to add team members, delete team members, and add an avatar for the team. Setting permissions was also an option that made sense, but I decided I’d leave that as a possible addition for the future. I kept this page really simple to start, and created the necessary workflows. To get the add/delete team mate functionality working, I created a few pop ups that would appear on the page if a user chose to add or delete team members.
Once I had the team page done, I moved on to the task page. For the most part, the task page was a clone of the team page. The only adjustments I needed to make were to have a task repeating group showing instead of a team member repeating group, as well as updates to the pop ups. The add task pop ups needed additional fields, including the stakeholder, the category, any files related to the task, and the team member that was assigned to it. This was pretty easy to do, so I was on to the next thing.
Before working on the data structure for the repeating groups in these pages, I wanted to build a navigation for when a user was logged in. I liked the very simple left navigation layout that youtube uses, so I decided to mimic that. I created a long gray bar running along the left side of the page, and made it a reusable element with different page options. Even after setting my ‘floats relative to’ in the appearance pop up, it wouldn’t stay in a fixed location when I scrolled in preview mode.
I played around with this, and figured out that once a floating element was converted to reusable, it no longer would float on the page. Maybe there was a way to fix this, but I wasn’t able to easily find it. I decided to start over on my nav bar.
My next attempt did work. I knew that a floating element that wasn’t reusable would stay in a fixed location on page scroll, so I built a blank nav bar on the left side of each of my pages. Once I had that done, I set it to float relative to the ‘Top’ and ‘Left’, and confirmed that it worked in preview mode.
For the reusable element, I created a smaller group with the different page options. Once that was done, I placed that element inside the floating nav bar I had on each page. Once again, I was able to confirm this stayed in place when I scrolled down the page, and also that the navigation actually worked between pages.
Now that the navigation was done, I had to think a little bit more about the data structure. I wanted Droove to be able to be used by multiple teams, so I needed to think more comprehensively than I was before when I was mainly building things for myself.
I knew I had the pre-built User table in Bubble, but I had to think about the logic a little bit. Should the User table be only for Users who sign up for their team? What about team members they add to their team? Should those additions go in a new table, or could they just be a list field in the User table? Depending on which choice I made, how would that affect functionality? What if users on different team names have the same user name? How do I make sure this gets distinguished when their data is shown? There were a lot of questions I hadn’t dealt with before. I decided to just start building, and adjust any issues I ran into along the way.
There was definitely a point of trial and error, but I eventually figured it out. I originally had a ‘teammates’ field in the pre-built User table that I set up as a list. I thought I’d be able to use a repeating group to show all the teammates for the current user on the team page. Unfortunately, I couldn’t get that to work. After doing some research, it seems like repeating groups can show different records in a table, but not different elements of a list within a record. This also created a problem because at scale, there wasn’t going to be an easy way to guarantee that all the teammates of the current user that had signed up for Droove would end up in that teammates field.
I ended up with the pre-built User table, and a new Team table. I needed to figure a way to join them, so I set a field in the User table called ‘User Team Name’. I set the field type as a ‘Team’, which would take the data from the Team table. This is known as a composite field type, which was new to me. I don’t feel like Bubble has the best documentation around it, because I had a hard time understanding how it worked at first. My original goal was to have a user create a team when they signed up, and a workflow would 1) create a new record in the Team table with that team name, and 2) Modify the user record in the User table to have the created team name as their User Team Name field. Step 1 worked, but step 2 did not. I tried a few different things via a workflow, but I get kept getting type inconsistency errors between the data types of ‘team’ and ‘text’. Eventually I was able to get a workflow working, but instead of putting the team name in the ‘User Team Name’ field in the User table, it put the unique ID for the team instead. I figured this was close enough, so I changed my ‘User’ table to have a field of ‘Team ID’.
I went back to my team page, made some adjustments to my repeating group, and was now accurately seeing the team members I expected to see.
DAY 8 1/28/20
I didn’t do much work in Bubble. I took a day to go back and try to find answers the questions I had at the start of day 7...
- How to move drooves around and place them freely, even while using a drop area
- How to make sure drooves don’t temporarily disappear when new drooves are added (also related to drop area).
- If a droove is added/deleted, how to make sure the drooves are moved to the correct spot automatically
- Can I move the drooves to their last saved X and Y position whenever the page is loaded instantaneously (This was currently on a delay, and very visible to the user)
The reason these were so important, is because they were directly related to what makes droove different...having the ability of visual interaction. After a few hours of research, I came to the unfortunate realization that I wouldn’t be able to build out Droove as much as I wanted. I was hoping that wouldn’t be the case, but I knew I may run into limitations with Bubble when I started this project.
I was at an interesting crossroad at this point, with a few options. I could stop working on Droove altogether, and move on to something else, which would give me more time back, but I’d have no user insights from building it. I could continue with a prototype where I could have a few draggable elements, but it would be more of a ‘duct tape and band aid’ approach which probably wouldn’t be the best experience for a user. I could also build Droove out as just a super simple work management tool without the visual elements, and see if there was maybe a niche market that would find it valuable. I had a decision to make.
DAY 9 1/29/20
I decided I’d go with the ‘duct tape and band aid’ approach. Even though I wasn’t going to be able to build the product I was hoping to, I figured doing this would at least allow me to show something for my efforts, and hopefully glean some insights. I also decided that I would put a deadline on this...14 days of work.
At this point, the repeating groups approach was officially done. It just wouldn’t scale how I wanted it to. I was back to my less scalable, very clunky, approach.
For this to work, I needed to build the drooves. From my sketch on day 7, I had an idea of putting a draggable group on the page. Within that draggable group would be a multiline input group that users could take notes on, a picture uploader, and a file uploader, and a button that would create a new task. These elements would be hidden when the page was loaded. When users initially clicked on a droove, a pop up would show asking them what type of droove they wanted, whether it was a note, a picture, or a file. Based on what they chose, a workflow would start that would transform the droove into what they wanted. From there, it could be moved around.
As you can see, this didn’t work how I wanted. I was able to create a note, but the drag functionality wasn’t as good as I hoped.
DAY 10 1/30/20
Even though I said I was going to stick with a duct tape and band aid approach to Droove, I decided to stop working on it. The more I thought about the issues I was trying to overcome, the less confident I felt that I’d be able to build a prototype worth sharing.
The visual workspace just wasn’t going to get to where I wanted it to be. Even though I could have continued with a super simplistic work management tool without the visual workspace, I felt like this was a saturated market already. I knew about tools like google sheets and trello, but I also found other tools like taco app. These were tools that were on the more simplistic side of work management, and had a freemium pricing model. The fact of the matter was that these tools could do what I wanted to build, if not more, for free.
It would have been nice to have a prototype to show for my work, but hopefully writing this experience is enough that either I, or someone else finds it useful in some way. I think this will be a good reference for me to go back to if I come across similar issues in the future.
As I wrap this up, I have a few parting thoughts…
- Even though Bubble has a lot of functionality, it still does have its limitations. I feel like I chose a pretty ambitious product idea for a no-code solution, but I'm happy about that. I feel like a learned a lot about the nuances of the tool, that I may not have learned, if I decided to build something more traditional that had already been done before.
- Should I only try to build things that I’ve validated in some way with other users? In the case of work management, I know there is a desire to have more visual tools. Tools like Mural, Notion, as well as Ideapaint, prove the fact visual is good. I've also seen plenty of evidence that supports it. However, I never explicitly asked anyone if they’d be interested in a tool like this before I started. I was OK with that in this case, because it was a way for me to learn Bubble, while trying to build something I was interested in. Now that I’m familiar with Bubble, that probably will be more of a requirement for projects I take on going forward.
- Is it worth building something in no-code if it’s not financially viable? Again, I could have built Droove out as work management tool, and that would probably be a pretty cool no-code accomplishment, but I don’t think it would have a chance of making money. There's got to be a balance between building something in no-code because you can, vs it actually making/saving money.
- Should I livestream videos instead of writing in the future? This is something I struggle with. One one hand, live streaming definitely seems better from a content perspective, as it’s easier to explain in real time what’s going on. However, I enjoy writing because I think it’s a better skill for me. Also, going back between writing and doing, helps me think through problems, and come up with new ideas. I don’t know how this would translate if I was live streaming my work.