Browserboard Blog

When you're teaching a class and want to prevent students from drawing, or you're finishing up a job interview and want to prevent the candidate from editing their work after the interview, you can use Browserboard's new Lock feature.

gif

When you lock the board, anyone with a Contribute link will only be able to view the board, not make changes.

Screenshot of contributor's read-only screen

Life's coming at us fast here at Browserboard HQ, so that's all for the week!

This week, I invested time in supporting the workflows of people who coordinate remote interviews. These people need to make a lot of whiteboards, but don't need to actually visit them; they just need to copy share links into emails and calendar invitations. So I created the Interview Dashboard:

Good whiteboards are sorely needed in the tech interviewing world. The need is so sore that many companies charge many dollars for so-so products. This new feature of Browserboard is free (for now) and I hope it will make some people's lives easier.

API enhancements

I'm focusing more on the API as people contact me about using it. This weekend, I added the ability to export an image out of an iframe-embedded board, and laid the groundwork to let API users customize the colors. I also stopped showing the “enter your name” modal for iframe-embedded boards.

Other improvements

I improved the behavior of the Text and Sticky tools. The Text tool will no longer keep spawning more text boxes as you click; instead, it'll switch you to the Select tool so you can edit. The width handle on text boxes is easier to grab, and sticky note colors can be changed using the Select tool.

Over the past two weeks, I've put down feature development to focus on stability and programmer-oriented features. To users, this means fewer bugs and better site performance in the future.

(In case you missed the last one, which didn't go out via email: Browserboard Update: Sharing Options and Heaps of Bug Fixes)

API

Someone contacted me about embedding Browserboard in a web app that lets children draw on storybooks. It sounded neat, so I built a simple API to enable them to do that. The API isn't public yet, but if you send me an email or use the contact form, I'll give you access and send you some documentation.

Error tracking

It's important for a web developer to know when things are going wrong. To that end, I finally integrated Sentry into the frontend JavaScript. This revealed a handful of bugs I quickly fixed.

This integration increases the amount of information tracked about users, but none of it is tied to anyone's information; all I know is what tool an anonymous person was using when they experienced an error.

Page load times

When I introduced image thumbnails for logged-in users, I used very simple, sub-optimal code on the backend. If multiple users were uploading thumbnails at once, and my image host decided to take a long time, it could cause the whole site to hang.

I ended up switching image hosting providers from Backblaze B2 to Digital Ocean Spaces, and thumbnail uploading no longer goes through my server, so the whole site should be more consistently responsive.

The most important result here is I can continue to spend very little on servers, which is good because I'm paying out of pocket to run this site for free. Another important result is I can build an image upload feature and be confident it won't bring down the site when I release it.

Continuous Integration

When you make changes to software, there's always a risk you introduce a bug. You can test everything by hand before every site update, but that takes a long time and there's a chance you miss something and break a feature for users.

People usually solve this problem by writing automated tests and running them as often as possible. I avoided this for a long time because I've been making big changes quickly, but this weekend I finally got test suites running for all the important parts of the app using GitHub Actions.

New sharing options

It's now possible to give different people different permissions on your boards, even on anonymous whiteboards created without user accounts. Simply click the “Copy” button under View, Contribute, or Owner.

The old board sharing options are gone. Not that anyone will notice—they weren't very useful.

Image export affordances

This week, a user discovered that when a board is really big, the browser freezes when trying to export it. So I ran some tests and found that most browsers have a threshold at 16,384 (2^14) pixels where they become really slow.

Rather than add a hard limit, I decided to just show the user the dimensions of the output image, and add a warning when it's too big. I also added a progress bar so you can see how long it's going to take.

Image export dialog including image size

Image export dialog with size warning

Heaps of bug fixes

There have been some minor and major issues around sticky notes and text boxes. I went into the guts of the app with a flashlight and a pair of pliers and rewired all the text stuff so it's more reliable, both in terms of user experience and data correctness. Critically, if someone starts editing a sticky note or text box you have selected, Browserboard will deselect the shape and save your text so nothing gets lost. It's not as good as having full realtime collaborative text editing, but I hope it will do for now.

“Beta”

To communicate the ever-changing nature of Browserboard, I added a little “beta” label next to the logo in the top navigation bar.

That's all for this week. Thanks for reading!

I went into this weekend telling myself I would take it easy. And I think it's fair to say I did—I spent the best parts of Saturday biking around the city. But then I came home and wrote some code for Browserboard. I wanted a break from adding features to the whiteboard itself, so instead I worked mostly on performance and the landing page.

Summary: pages load faster, panning is faster, your boards are paginated, and when you click the “new board” button, the name field is auto-focused so you don't need to click it.

Performance

tl;dr computer go brrrrr

Every line you draw and shape you place in Browserboard ends up as a unique HTML element. If you draw 5,000 lines, there are 5,000 Canvas elements on the page. Modern web browsers handle this surprisingly well; there's at least one board that has over 5,000 events. Those people managed to draw 5,000 lines (and text boxes, and shapes, etc).

Faster page loads

That huge board took 5+ minutes to load. That's because Browserboard has been replaying the entire event log on every page load. So if you drew a line, erased part of the line, undid the erase, and erased again, Browserboard would retrace all those steps, instead of just drawing the line in its final state. If you do a lot of undoing and erasing, Browserboard could be doing ten times more work than is necessary.

That's fixed now. The board that took 5+ minutes to load now takes less than 30 seconds, and most of that is waiting for network requests. Browserboard only draws the final state of each shape.

Panning

Panning around that 5,000-object board was pretty choppy.

When you pan and zoom in Browserboard, it simply updates the CSS transform of the parent element of all the shapes. This approach keeps things simple in the code, but it makes the browser do more work; my understanding is the browser keeps re-rendering all these elements to a parent texture on each update, which is very expensive.

To improve the situation, I added a very basic optimization that video game developers have been using since the invention of video games: I started marking offscreen objects as hidden, simply setting style.display = "none". Visibility is recomputed only after the mouse lifts or the zoom level changes, so when you're panning, the browser doesn't need to redraw anything. You'll see some pop-in, but it's much better than panning at 1.5 frames per second.

There's a lot more I can do here. I should probably try removing offscreen objects from the DOM tree completely, and also transform each element individually instead of transforming a parent element. This approach made a huge difference back when I worked on Buildy. But panning performance is “fine” now, so I don't think I'll look into that for a while.

Thumbnail size limit

When I started making boards save thumbnail images for easier browsing on your dashboard, I had them simply render the entire board contents to an image and then scale that down to a small size. This took multiple seconds on the 5,000-shape board, which is a real problem because JavaScript in a web browser can't run outside the UI thread and still have access to the DOM. Long thumbnail render times will affect user experience. So I simply clipped the thumbnail size to something reasonable, which should keep thumbnail render times under 50 milliseconds.

These are good problems

New products often hit this awkward stage where people like using them just enough to feed them more data than they can really handle. I was waiting for this moment before investing deeply in performance; after all, if nobody uses the app, great performance benefits no one. From now on, I'll keep an eye on it.

A few minor features for logged-in users

  1. When you're logged in, your list of whiteboards shows 16 per page, instead of all your boards at once. Please email webmaster@browserboard.com if you need more features on this screen.
  2. The “+ new” button will focus the whiteboard name field immediately, so you don't need to click it to set a name. You can just start typing and press Enter.
  3. You'll see a list of recent site updates below your boards. I thought it was impolite of me to only show the changelog to logged-out users. You can also sign up for the newsletter and get updates like the one you're reading right now! But I suppose you know that if you're reading this update.

New landing page

The old landing page was meant to be endearingly rough, to reflect the minimalistic and personal nature of the app. I'll share some old images here for posterity:

some very ugly screenshots

I've added and improved Browserboard a lot since I made that page. I also bought a cheap Wacom tablet, and while it doesn't improve my drawing skills, it does make it more fun to draw on a computer. So I spent today reinvisioning https://browserboard.com/, writing the HTML, and drawing some new boards to show in screenshots.

screenshot of the top of the new landing page

more nice images

The new landing page does a much better job of explaining what Browserboard can do and how it benefits different kinds of people. It's still pretty rough, but at least there's much more meaningful content that I hope will improve Browserboard's search engine ranking and help people decide whether it's worth a try.

What's next, other notes

There's one tiny new feature that nobody but me cares about: I wrote tools that let me export boards as JSON files and import them into my local development environment. I only do this with permission, to help diagnose problems with specific boards. It means I can mess around with a buggy whiteboard without trampling someone's live data.

Next, I'm thinking about how to make sharing more granular. A few people have requested the power to limit guests' ability to clear the whole board, which is very important when drawing with kids. Rather than bolt it on thoughtlessly like I've done with so many things, I want to reimagine how Browserboard thinks about user permissions, and see if I can give the owner more settings in the actual whiteboard view, rather than hiding settings on a completely separate page. It's probably more than one weekend of work, unfortunately, so I'll try to find something else to do next weekend as well.

Screenshot of a board showing off all the new features

Sticky notes

I do my best to make Browserboard's existing features work well before adding new ones. I spent lots of time working on the pen tool before the selection tool, and then lots of time working on the selection tool before moving on to text. I address bugs before adding new features.

That's why it's taken me so long to add my next-most-requested feature, sticky notes.

Screenshot of a sticky note

Conceptually, sticky notes are simple. They're colored rectangles with text on them. But under the hood, supporting sticky notes forced me to modify the fundamental way things are displayed, to support a shape rendered behind a text box. In web browsers, there's a hard split between traditional graphics rendering and text; this split is why Browserboard's PNG export feature only supports one font per text box.

Now, I can combine any graphical shape with text. Today I shipped sticky notes, but in the future, I'll be able to replicate some of the features of sophisticated “node”-based editors like draw.io.

Top toolbar tweaks

As I add tools to Browserboard, I add more controls to the top toolbar to support each new tool's features. As a result, the top toolbar has become crowded and cramped.

To free up space for future improvements, I added a navigation bar above the whiteboard toolbar, and started hiding controls that don't apply to the selected tool. Here's what it looks like while editing a sticky note:

Screenshot of sticky note tools

And here it is when you're using the marker tool. Check out the opacity slider!

Screenshot of marker tools

Selection tool bug fixes

Selection behavior is really difficult to get right because there are so many possible interactions. I made a few small but important improvements this week: 1. When you mouse/touch down on a shape, you can start moving it immediately, instead of needing to drag a second time after selecting it. 2. When multiple shapes overlap, Browserboard will use pixel-perfect selection to choose exactly the shape you indicate. If you click multiple times, it will cycle through all shapes under your cursor, from front to back. 3. Getting in and out of text selection states is less finicky. 4. Resizing shapes while zoomed in or out should work correctly, rather than incorrectly.

Bonus: eraser size

A few people asked me to make the eraser a bit bigger than the pen by default, so I did.

This weekend, I talked to some users who requested a couple small features. One was new image export options.

Transparent background and scale factor

The other was a pen tool with some transparency. For now I'm calling it “watercolor,” but I might change the name.

Watercolor tool

As a way of making tabletop RPG games easier to set up, I added a “duplicate” button to the top row of buttons, with a hotkey of Cmd/Ctrl+D. This will let people quickly make copies of colored tokens. I also adjusted the look of the stroke width picker because some people had trouble figuring out what it was for.

Bug fixes

Undo now works on the eraser.

Browserboard is a free multiuser whiteboard web app.

I like making drawing apps. I’ve been doing it for a long time. I started on Mac OS 8 using BASIC!

Daphctarcs screenshot

In college, I tried one in Python.

Splatterboard screenshot

In 2012, at my second job out of school, I wrote one in JavaScript: Literally Canvas. It became the most popular open source library for embedding drawing widgets in web sites.

Literally Canvas screenshot

While maintaining Literally Canvas, I learned a lot about how people integrate drawing with their products, because they would show up in the issue tracker describing their problems. On a few occasions, I made beer money implementing their feature requests on contract. Among my users' projects were e-learning platforms, football coaching tools, and to my surprise and alarm, electronic medical records systems.

One thing people asked for regularly was a way to use Literally Canvas as a “collaborative whiteboard.” It was never going to work—the data model was very poorly suited to it—but the requests kept coming. Over time, bit rot set in, contributors failed to appear, and I stopped maintaining the project.

My interest in drawing apps was rekindled in 2020 as my employer moved to online interviewing. We cycled through a few multiuser whiteboard tools, and when using each one, I would notice at least one or two papercuts I had taken care to solve in Literally Canvas years ago. It really bugged me that after all these years, people were still making drawing tools that don't do any line smoothing while drawing, or have odd behavior when moving shapes that have been affected by an eraser, or have unintuitive interfaces for basic operations. These things really aren't difficult to fix with a little thought, but the “minimum viable product” approach of most web companies these days doesn't seem to result in great experiences.

The more I used these frustrating tools, the more motivated I became to try to do better. My memories of working on Buildy gave me a few ideas about how to approach the data model for a realtime multiuser app, and the global pandemic was giving me plenty of time indoors with no responsibilities.

On April 8, I made my first commit. I worked on it 16 days in April and 17 more days in May. I deployed the site to browserboard.com on May 11 with the help of my friend Thomas. After that, I slowed down a bit. Between myself and Thomas, we worked about 4-5 days each in June, July, and August, getting the features of the site roughly where they are today, and then 4 days in November to switch from Redis to Postgres for event storage when the Redis instance hit its memory limit. After that, I ran out of motivation and took a long break, mostly to replay the Mass Effect trilogy.

Browserboard screenshot

On March 22, I noticed a sudden traffic spike. Apparently Bing decided that Browserboard should be the #2 result for “online whiteboard,” right after Microsoft Whiteboard! The traffic spike reinvigorated me, and I've spent the last couple weekends fixing bugs and adding new features again.

Now that users can save PNGs and boards have proper image thumbnails, I'm not sure what big feature to focus on next. The trouble with an open-ended prompt like “let people draw together online” is there are a lot of different kinds of people! Please do write in if there's something I can add that would help you, or just to let me know what you're using Browserboard for.

-Steve

Enter your email to subscribe to updates.