Skip to main content

Structuring the Front End: Building Wooster's User Interface

Frontend ArchitectureReact3D GlobeTypeScriptUI/UXComponent DesignResponsive DesignUser Experience (UX)3D VisualizationFolder StructureStatic and Interactive Components

Frontend Adventures: Making Wooster Look Presentable

After getting the backend sorted and teaching Wooster to generate coherent travel plans, it was time to give him a proper home on the web. But before diving into styling or state management, I needed to lay down a solid foundation. Past experience has taught me that rushing into implementation without proper architecture is like trying to teach Wooster tricks before he knows "sit" - it rarely ends well.

Component Architecture: Every Dog Needs a Good Structure

While it might have been tempting to throw everything into App.tsx and call it a day (we've all been there), I decided to start with a proper component structure that would scale with the application:

src/
├── components/          # Organized by feature
│   ├── activities/
│   ├── auth/
│   ├── destinations/
│   ├── explore/
│   ├── layout/
│   ├── shared/
│   ├── trip/
│   └── ui/
├── context/            # Application context
├── hooks/              # Custom hooks
├── lib/                # Utility functions
├── pages/              # Route components
├── services/           # API service layer
├── store/              # State management
├── types/              # TypeScript definitions
└── utils/              # Helper functions

This structure might look like overkill for an MVP, but I've learned the hard way that "I'll organize it later" joins "I'll document it later" in the graveyard of good intentions. By organizing components by feature rather than type, I could work on entire features without jumping between folders. The separation between components/ui and feature-specific components has already paid dividends - reusable UI components stay clean and focused, while feature components can evolve with their specific needs.

The layout implementation set the tone for the entire application:

function AppLayout() {
  return (
    <div className="min-h-screen bg-gradient-to-b from-green-100 via-white to-green-50/80">
      {/* Desktop Sidebar */}
      <div className="fixed left-0 top-0 z-50 hidden md:block">
        <Sidebar />
      </div>
 
      {/* Main Content */}
      <main className="flex min-h-screen flex-col">
        <div className="flex-1 px-4 pb-20 pt-4 md:ml-48 md:pb-4 lg:ml-64">
          <div className="mx-auto max-w-7xl space-y-8">
            <Routes>
              <Route path="home" element={<Dashboard />} />
              <Route path="trips" element={<Trips />} />
              <Route path="explore" element={<Explore />} />
              <Route path="trips/:tripId" element={<TripPage />}>
                <Route
                  path="summary/:destinationId"
                  element={<DestinationSummary />}
                />
              </Route>
              {/* Additional routes */}
            </Routes>
          </div>
        </div>
      </main>
    </div>
  );
}

This layout already accounts for both desktop and mobile views - although I'll admit I made the rookie mistake of not starting mobile-first. Future me will remember that responsive design is easier when you start small and scale up, rather than trying to squeeze a desktop layout into a mobile view later.

Starting Static: Teaching Wooster to Sit Before He Can Fetch

Before adding any interactivity or state management, I built out every component as a static version. This approach might seem like extra work, but it's actually saved me countless hours of debugging by separating concerns: if the layout is broken, I know it's not because of state management or data fetching - it's just the component itself.

Take the destination creation flow, for example. Here's how it started:

function CreateDestination() {
  return (
    <div className="w-full">
      <div className="mb-6 space-y-1">
        <h2 className="text-xl font-semibold">Add a Destination</h2>
        <p className="text-sm text-gray-600">Add a new destination to your list</p>
      </div>
 
      <form className="space-y-6">
        <div className="space-y-2">
          <label className="font-medium">Destination Name</label>
          <input
            placeholder="Enter destination name"
            className="w-full rounded-md border"
          />
          <p className="text-xs text-gray-600">
            Where would you like to go?
          </p>
        </div>
        <button type="submit" className="w-full">
          Add Destination
        </button>
      </form>
    </div>
  );
}

No state, no form handling, just pure structure. This made it easy to get the layout and user flow right before adding complexity. Later, it evolved into:

function CreateDestination({ onClose, className }: CreateDestinationProps) {
  const { state } = useAppContext();
  const { isLoading } = state;
  const { handleCreateDestination } = useCreateDestination(onClose);
 
  const form = useForm<DestinationFormData>({
    defaultValues: {
      destination: '',
    },
  });
 
  async function onSubmit(data: DestinationFormData) {
    toast.promise(
      handleCreateDestination({
        destinationName: data.destination,
      }),
      {
        loading: 'Fetching your destination...',
        success: () => {
          if (onClose) onClose();
          return '🎉 Destination created successfully! Time to explore!';
        },
        error: (err) => {
          console.error('Form submission failed:', err);
          return `Failed to find your destination: ${
            err instanceof Error ? err.message : 'please try again'
          }`;
        },
      },
    );
  }
 
  return (
    <FormProvider {...form}>
      <form onSubmit={form.handleSubmit(onSubmit)} className="space-y-6">
        {/* Form fields implementation */}
      </form>
    </FormProvider>
  );
}

The Wow Factor: Every Dog Needs Its Show-Stopping Trick

During my years in software sales, I learned something crucial: users make snap judgments about software in the first few seconds. You need that "wow" moment - what UX designers often call a hero feature or marquee component - to capture attention immediately.

For Wooster, this meant building something unexpected. Sure, I could have started with the essential trip planning features, but I wanted users to feel that sense of adventure the moment they landed on the explore page. The solution? A fully interactive 3D globe that brings your travel destinations to life:

const GlobeComponent: React.FC<GlobeComponentProps> = ({
  destinations = [],
  focusedDestination = null,
  className = '',
  initialAltitude = 1.5,
}) => {
  const globeEl = useRef<HTMLDivElement>(null);
  const globeInstanceRef = useRef<GlobeInstance | null>(null);
 
  // Initialize Globe
  useEffect(() => {
    const globe = Globe()
      .globeImageUrl('/earth-texture.png')
      .bumpImageUrl('//unpkg.com/three-globe/example/img/earth-topology.png')
      .backgroundColor(isDarkMode ? '#1c3027' : '#F0F7F4')
      .htmlElementsData(points)
      .htmlElement((d) => {
        const el = document.createElement('div');
        el.innerHTML = `
        <div class="flex flex-col items-center">
          <div class="relative">
            <div class="h-1.5 w-1.5 rounded-full bg-yellow-400 shadow-[0_0_8px_rgba(250,204,21,0.5)]"></div>
            <div class="absolute -inset-0.5 animate-[ping_2s_ease-in-out_infinite] opacity-40">
              <div class="h-full w-full rounded-full bg-yellow-400"></div>
            </div>
          </div>
          <div class="text-[0.65rem] text-white font-medium whitespace-nowrap px-1.5 py-0.5 mt-1 rounded-full">
            ${d.name}
          </div>
        </div>
      `;
        return el;
      });
 
    // Globe initialization and cleanup logic
  }, []);
 
  // Handle focused destination changes
  useEffect(() => {
    if (!globeInstanceRef.current) return;
 
    if (focusedDestination) {
      globeInstanceRef.current.pointOfView(
        {
          lat: focusedDestination.latitude,
          lng: focusedDestination.longitude,
          altitude: 0.1, // Zoom in closer when focused
        },
        1000,
      );
    }
  }, [focusedDestination]);
 
  return <div ref={globeEl} className={`h-full w-full ${className}`} />;
};

Each destination appears as point on the globe, with smooth animations as users explore different locations. When you select a destination, the globe gracefully rotates and zooms to give you a closer look. It's not just a visual gimmick - it makes the whole experience of planning travel feel more tangible and exciting.

The explore page brings this all together:

export function Explore() {
  const { state } = useAppContext();
  const { savedDestinations, isLoading } = state;
  const [focusedDestination, setFocusedDestination] = useState<Destination | null>(null);
 
  const handleDestinationClick = (destination: Destination) => {
    setFocusedDestination((prev) =>
      prev?.destinationId === destination.destinationId ? null : destination,
    );
  };
 
  return (
    <div className="hidden lg:grid lg:grid-cols-3 lg:gap-8">
      <div className="space-y-8 lg:col-span-2">
        <div className="overflow-hidden rounded-lg bg-white/70 shadow-md backdrop-blur-sm">
          <GlobeSection
            destinations={savedDestinations}
            focusedDestination={focusedDestination}
            isLoading={isLoading}
          />
        </div>
        {/* Destination exploration section */}
      </div>
      <div className="lg:sticky lg:top-8">
        <DestinationPanel focusedDestination={focusedDestination} />
      </div>
    </div>
  );
}

Was implementing a 3D globe essential for an MVP? Absolutely not. But it transformed the experience from "just another travel planner" into something that makes users want to explore. Sometimes the non-essential features are what give your app its personality - and in Wooster's case, that playful, adventurous spirit is exactly what I wanted to capture.

Core User Journey: Building the Happy Path

With the foundation in place, I focused on the essential user journey. Rather than getting lost in edge cases and nice-to-haves, I mapped out the core path: login → explore destinations → create trip → view itinerary.

The login screen started life almost comically simple:

function Homepage() {
  return (
    <div className="flex h-full flex-col items-center justify-center">
      <Logo height={'h-72'} image={'/wooster-homepage-no-bg.png'} />
      <h1 className="text-grey py-10 font-black">Wooster</h1>
      <Link to="/home" className="flex items-center justify-center">
        Log in
      </Link>
    </div>
  );
}

No authentication, no error handling, just a direct path into the application. This might seem too simple, but it let me focus on what mattered: the core user experience. Authentication could come later (and it did, thanks to Supabase making it relatively painless).

Each page followed the same pattern: build the static structure, ensure the layout works, then gradually add interactivity. The explore page was particularly interesting because it had to balance the wow factor of the globe with actual usability:

export function Explore() {
  return (
    <div className="container mx-auto px-4 py-6">
      <PageHeader
        title="Explore the World"
        description="Discover amazing destinations and plan your next adventure"
      />
 
      <div className="lg:grid lg:grid-cols-3 lg:gap-8">
        <div className="space-y-8 lg:col-span-2">
          <div className="overflow-hidden rounded-lg">
            <GlobeSection />
          </div>
          <div className="rounded-lg">
            <ExplorationSection />
          </div>
        </div>
        <div className="lg:sticky lg:top-8">
          <DestinationPanel />
        </div>
      </div>
    </div>
  );
}

What I Actually Learned

  1. Start with structure
  2. Build static before adding interactivity - it forces you to think about component composition
  3. A strong "wow factor" feature can be worth the early investment
  4. Organize by feature, not type - keeps related code together
  5. Separation of concerns from day one saves refactoring later
  6. Next time, I'll start with mobile-first design (lesson learned!)
  7. TypeScript and good folder structure are like training wheels - they might slow you down at first, but they prevent a lot of falls
  8. Don't be afraid to keep things simple initially - you can always add complexity later
  9. Document your component structure early - it helps maintain consistency as the app grows

Looking Back

Would I do some things differently? Absolutely. The mobile-first approach is the biggest one - retrofitting responsive design is never fun. But the core decisions - starting with good architecture, building static components first, and investing in that wow factor - have all paid off.

The foundation is solid, but now comes the interesting part: making it all work together seamlessly. That's where state management comes in...

Next up: "State Management: Teaching Wooster to Remember Things" (where we'll dive into the context vs reducer debate, why TypeScript saved my sanity, and how we kept our state as well-organized as our components)