Tabula

My student newspaper uses a suite of software that is very popular among K-12/college publications. Yet when I joined as a freshman, it felt a lot like a Swiss Army Knife if you forgot that knives are supposed to cut—a sentiment shared by most of my classmates.

As I became involved in maintaining and designing our website, I also became very interested in multimedia: pushing the medium of our content to its fullest potential. However, our previous CMS limited us to text-only editing, which meant that any design work had to be done outside our main editorial workflow, by people familiar with HTML/CSS and Figma. This made the design process inefficient and much less accessible to the broader team.

Inspired by the New York Times' Oak and Scoop, Tabula addresses these challenges while also reimagining what an all-in-one software suite for journalism should look like. By studying how reporting happens outside of a CMS (and writing stories myself!), I learned what tools can be built to support it.

Features

• Configurable review workflows that route stories through editorial stages, with real-time submissions, approvals, and revisions. Includes a robust notification system, deadline tracking, and Canvas integration so story due dates appear alongside other assignments.

• Integrated pitch tracker for managing story ideas from conception to assignment, with visual prioritization, inline commenting, and note-taking spaces. Allows writers to request to claim pitches and managers to approve those requests, converting pitches to assigned stories automatically.

• Built-in WYSIWYG editor that lets you write and design in one place with full Google Docs-like collaboration, version history, and commenting/suggesting capabilities. With drag and drop simplicity, anyone can dream of and lay out interactive, media-heavy stories.

• Drag and drop editor for homepage, sidebar, and section layouts that automatically updates your WordPress theme, letting managing editors easily prioritize different stories based on newsworthiness or shifting journalistic priorities.

• One-click upload from Tabula to WordPress, with automatic JSON configuration of layout widgets and HTML/CSS/JS generation for embedded multimedia so breaking news doesn't have to wait on a Web Editor.

• Real-time planning tools, including an infinite whiteboard for structuring investigations, a simple outliner for organizing angles and sources, and an interview question tracker for engaging with others.

• End-to-end interview management from scheduling to transcription: sync availability with Google Calendar, send interviewees scheduling links with pooled availability, draft questions in the same place, and upload recordings to generate searchable transcripts with speaker attribution.

• AI-powered chatbot and inline editing assistant that aligns your story with a custom-defined style guide and AP standards live, mitigates inaccuracy and bias in writing, and talks through story and sourcing ideas with you.

• Seamless integration with school identity systems for role-based access control that avoids overwhelming new writers with features unnecessary to their role and streamlines onboarding.

• Simplified analytics dashboard, parsing Google Analytics data for non-technical writers to understand and interpret traffic, engagement, retention, and other key metrics.

• Companion iOS app for taking and uploading pictures with recommended settings, paired with an AI assistant that gives advice on composition, lighting, and other photography best practices.

• Outreach manager for scheduling social media posts and designing email newsletters with drag-and-drop creative tools, Canva integration, and Gmail delivery. Feeds engagement metrics to analytics dashboard.

Engineering

Small technical teams with varying expertise, unpredictable traffic spikes, and low technology budgets are all realities of student journalism. To meet these challenges effectively, I made the deliberate choice to build Tabula serverless. Forgoing traditional backend servers, I gained autoscaling and usage-based pricing. This had the added benefit of making it significantly easier to teach future successors how to maintain and extend the platform, since the core paradigms of serverless architecture are relatively simple to grasp.

However, when it came to certain especially stateful features like the collaborative editor, this choice introduced some very interesting engineering challenges. Rather than setting up a simple Socket.io server with y-websocket and Hocuspocus, straying from serverless, I built a custom real-time sync system using Firestore's transaction system as an "authority server." When a user makes an edit, it generates a "step" (ProseMirror's term for atomic document changes). I send these to Firebase, which quite elegantly acts like a bouncer: if no conflicting steps exist, it accepts them; otherwise, it tells the client to fetch newer steps, rebase, and retry. The result: reporters, editors, designers, and managers can effectively work simultaneously without stepping on each other's toes during breaking news.

I also had to work with this structure when building custom extensions that bring the editor beyond text. Each extension had to be collaboration-aware, tracking presence and version history, exposing APIs for non-human input, and supporting special marks and real-time diffing for comments and suggestions. To accommodate this, I created generalized primitives for collaboration which could be applied to any kind of document node. Those extensions ranged from custom autocorrection to a Notion-like layout editor that lets you drag and drop any kind of content block to the side of another, its own line, or a spot in a grid. While basic multimedia is not novel for Tiptap, going around the core principle of sequentially placed blocks is: it required a lot of custom logic of trying to encode visual dynamics in a structured hierarchy of rows, columns, and nested blocks.

I also had to build APIs for easily converting extensions' widgets to JSON in a way that allowed HTML/CSS/JS generation later on. Preview widgets use the same CSS classes as the real website, enabling WYSIWYG despite this translation layer.

The editor was certainly the most difficult part of Tabula to create, but it was also the most rewarding because of how much value it provided my publication and I. For the CMS, other interesting engineering decisions included using Firestore as a backend because of its native pub/sub capabilities and real-time syncing. While some of the more complicated role-based access control settings were hard to encode in their row-level permissions model, I gained live presence features deeply spread across the app.

Certain automations, like publishing to WordPress, were also implemented using Cloud Functions. When certain technical limitations prevented using a REST API to integrate with parts of our managed WordPress setup, I used Puppeteer to scrape website content in the same format a real user would see it. I tried both Browserbase and Cloudflare's Browser Rendering services, but chose Browserbase for their more stable API and broader website support.

The entire stack is built with Next.js in TypeScript, although if I had to remake Tabula, I'd probably use Vite instead. Next.js's server-side rendering features, while great for some websites, became unnecessary once we committed to a fully client-side architecture for real-time collaboration. Vite might have also offered better performance and more granular control over the site.

Reflection

I presented Tabula to an engineering executive at New York Times who lead the development of their current storytelling tools. It was great getting to talk about product design that balances power and simplicity for a nontechnical userbase, rolling out new tools to large organizations, and choosing infrastructure for large-scale collaboration where reliability/uptime is incredibly important. The conversation definitely reaffirmed some of my design decisions while also giving me ideas for new ways to improve Tabula.

Both NYT and leading student-run newspapers like the Harvard Crimson developing their own CMSes shows that there is a real need for tools that are tailored to the unique needs of journalism. Tabula is not a replacement for traditional CMSes like WordPress, but rather a complement that allows for more flexibility and creativity in storytelling, and I'm really glad that I spent the time to design a platform custom to The Forum.

Looking forward, I hope to get involved in student journalism in college, and I'm excited to see how Tabula can help other publications or be turned into a scalable product.

Screenshots