Realization
The realization for this experiment is quite limited, as I’m honestly right in the middle of building out our search module. Things are semi-functional, but the interface is sparse and quite honestly a mess right now - so above is just a quick snap from a prototype I’m mid-build on.
Feature Overview
Navigate with Keyboard
You can use your keyboard to parse up, down, and enter your search. This was quite essential for us as we love using this navigational pattern for command palettes in other products and wanted to embody that same feel here. We can re-use this functionality across Dub.
Auto-complete
When the search query changes, the top results for that query are displayed and selectable. You can set your search engine of choice for auto-complete and searching.
There’s also a subtle debouncing period that waits until you’ve stopped editing for a tiny (~100-200ms - still feeling out the best number here) amount of time before refreshing the results. This smoothens the experience quite a bit.
Process
Primary Challenges
Concurrency is Challenging
I actually found a wonderful demo project that was functionally quite similar to what I wanted to build. However, this project searched across static data whereas I needed to make asynchronous data pulls to live data. This created wayyyyy more problems than expected. Thank you to Anupam for helping me debug and reach a viable solution to my problems.
Learnings
Small wins daily make big wins weekly
As we’ve been experimenting these past months, we’ve generally focused on hitting a technical checklist to prove that certain things are both possible and positive. Now that our checklist is quite extensive, we’ve begun to focus more closely on the details of how certain interface components should look, feel, and behave. In doing this, we generally assume that any interaction is possible to build and if we feel it’s worth it, we’ll invest whatever it takes to build it.
This has led to a few days in the past week where I felt I was banging my head against the wall as I tried (and failed) to achieve seemingly simple things. For instance, reading a specific key press (in this case up / down). I falsely assumed this would be a simple task, and ended up spending an entire day troubleshooting and getting to a point where it kinda sorta worked with duct tape. On these days, I learned the value of celebrating small (ok, tiny) wins. These small wins were small, very small - but they propelled me through the week and helped me keep my sanity.
Whule I don’t feel particularly enthused with my experiment post this week (I bounced across ~10 different deep dives in the past week), I think my week as a whole was a success and I can feel this fully in noting and celebrating all the little things.
Next Steps
Search (again) (part 2)
When search is fully implemented, it should feature the following:
- autocomplete
- blockchain data
- popular sites
- history
- open sites
- commands
- navigation
I don’t know if part 2 will hit all of those marks, but I’ll be fully focused on taking search to 100%.
Brand, Design, Community
This is in motion right now and there will be many experiments here in the coming weeks.
One of the primary challenges we are facing as we define the details like language and aesthetic is that our product and it’s purpose evolves as the river flows. Each new marker we hit leads to a fork with many branches, and those many branches are the source of exponentially more paths, some straightforward and others winding backward.
Riding with the flow of the river is thrilling, a ceaseless adventure - and I’d argue that our current state of exploration is the right approach for us right now. But damn, a moving, changing target can be hard to hit.
As we define our brand, our design system, and our community strategy, I plan to focus on ephemereal elements that drive our passion and purpose in building dubdubdub. Why are we here, doing this?
If you’re excited the answer, you better buckle-up for all of the fun that’s soon ahead.