Getting Started

First, run the development server:

npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev

Open http://localhost:3000 with your browser to see the result.

On Engineering, Design,' and Other things

I've been tasked to build an auction website or DEX (Decentralized Exchange) for sfcomupte. The task was intentionally vague, with a focus for design engineering.

From my understanding, there's subtle functional differences between auctions and DEXs. An auction is more like a marketplace, where users buy the stuff they want. DEXs serve purposes beyond marketplace — they establish pricing based on buy and sell orders. Assuming sfcompute believed in commoditizing compute, I went for the DEX route.

Thus,

1. There had to be an order book to keep track of buy and sell orders
2. Users could fill out those orders
3. keep things aggresively simple (no auth, no ssr)

Creating these components weren't creatively difficult — Binance and Pheonix had very good UI/UX for DEXs.

The hard part was creating an aesthetic. Modern website design feels so monotonous — your typical B2B SaaS was flatly styled and had no flavor.

I did some reserach, and gathered design inspirations and best practicies:

• https://mmm.page/
• sfcompute.com (the slider bar and the overall contrast aesthetic)
• noah solomon
• https://web.dev/articles/cls

I want to also share this article on Design Advice for Programmers written by Evan Conrad. I found it particularly useful in how I approached this project. The word "contrast" was a perfect analogy I used to piece together each design decision, and this contrast is also demonstrated nicely on the sfcompute page.

I set out to build my first component. There was no Figma involved, but a rough sketch in my notebook sufficed. I was taking the tweak-as-you-build strategy, and grueling over forgetten CSS knowledge

I liked the slider on sfcompute.com, so I made my own slider very similar to that one. I used nextUI and tailwind components for everything, but had spend a lot of time customizing everything.

And so I finished an unrefined order form on the first day. Before this I actually spent 2 hours on friday building the backend. That didn't work and I scrapped that. A frontend-first approach was better suited for this take-home.

Here are some improvements that I made:

it’s hard to build componenets without a designer or having someone to consult on with ideas.

3 days have passed and I realized that I might have built the wrong thing.

An orderbook optimizes for trading and not for actual use of the commodity. the reason why someone would want to purchase compute is because they need it for training, and aren’t trying to immediately trade away their compute away. Although I planned for “compute” actually becoming a commodity, people aren't trading “compute”, at least not yet.

One way we can accelerate into this future would be to employ decentralization. The easiest way to do that is to distribute compute tokens that become tradeable immediately, and be tender for "compute" (Disclaimer: I have no crypto bg). Regardless of how we envision this future, I don’t think sfcompute is trying to go down the trading/crypto/regulatory route. Their priority is to deliver real value to researchers who cannot afford cheap and quality compute. I might have fucked up here.

nice I added a marketprice

Thoughts on reducing friction. If a user looks at a table they have to look down the middle, then look at the left align for the range component, but they shouldln’t have so many friction steps in their head. It's the designer's job to eliminate that.

user looks -> user must look down range -> user must then look left -> user then must laign the ranges -> user depicts 07 to July -> user discovers meaning

Let's try cutting the mental friction:

This is much better but for many ppl mentally translating 07 to “July” also poses another friction. Information needs to travel fast, and design helps convey that information efficiently. The orderbook table looks very cluttered in my opinion, but i’ll settle for this now. Not sure if users want to stay on this platform and learn the UX, which would make a more informative table better. Otherwise I should aggresively cut features.

When deciding which features to cut, we should decide the purpose of this application. Are users going to find more value in trading the unit costs of “compute” or would they be more interested in the actual renting? If it's unit costs, then we can remove the range, otherwise, if renting was a priority then the unit cost isn’t as important and we’d put that in the additional tooltip section. These need to be discovered — and I'm willing to do that.

My buddy @fiveoutofnine also talks about how for programmers can use certain colors for certain functionality. I found this very helpful, and maybe you would too.

nice looking good so far. Putting it all together ->

Friday morning: Okay I deployed it on vercel, did some cleanup. Holy shit I didn't know vercel persists the app running in some background. My database of orders is just a const orders[] variable stored in memory. That's so awesome. And I tried it on another computer and the data is persistent. Guess you don't need a db after all.