We’re making Tumblr more accessible!

If you’re an avid user of Tumblr on mobile web, then you might’ve noticed some improvements we made. Bigger font sizes and higher contrast text? Your screen reader actually reads what you hope it would? You’ve guessed it, we’re making Tumblr ✨accessible✨.

Why?

Since we’re rewriting the web, we wanted to make sure we did so with accessibility in mind. I could give you a long description why, but plenty of articles explain better than I can. Put simply: the web should be made useable for everyone.

We began with using the accessibility auditing tool in Google Lighthouse to check the improvements that could be made. Initially, our score wasn’t that great: 62. If you factored in areas that need to be manually checked then our score would have been abysmal. However, we’ve made great strides since then and are on our way to achieving that coveted 💯

We had inaccessible menus and poorly described elements, among other things. Using a tool like VoiceOver or TalkBalk you can see what experiencing Tumblr on mobile web with a screen reader was like. Here's a gif showing what the mobile web experience on Tumblr was like prior to the changes.

What we did

Some of the more noticeable improvements we made were introducing design changes to increase readability and making improvements following WAI-ARIA guidelines. We'll walk through a few other changes we made using React.

Visual order on the page follows DOM order

One of the larger changes we made was to revamp modals and popovers (e.g., the post activity screen). Originally we used React Portals but it isn't always the most friendly for accessibility. Ideally you want to have elements appear in logical DOM order and Portals provides a way to circumvent that. So, no more Portals!

The user's focus is directed to new content added to the page

Next step was to provide a way to manage focus. We want to a) direct focus to the modal when it's opened and b) return focus to the element that opened the fullscreen modal. Using React's lifecycle methods and refs, this is simple enough to implement. In your modal component:

This can make navigation a lot easier.

Tada!

Of course, we’re still fine-tuning different elements of the site since accessibility is more than just a number. A lot of these changes will be even more noticeable when the new Tumblr dashboard comes to your desktop. There’s still more to come, so keep your eyes open!

Think there’s a way to make Tumblr more accessible? Hit us up at tumblr.com/jobs and come work with us!

    - Nora Mohamed / @nomo

Making a progressive web app with webpack just got a little bit easier

Today we are releasing webpack-web-app-manifest-plugin, which generates an app manifest that shows up in your assets manifest.

I heard you like manifests

Turns out, there are a lot of web things called "manifests". When talking about web app manifests and assets manifests, sometimes it's hard to keep track. Buckle up, because we made a webpack plugin that deals with both of these types of manifests.

Web app manifests are JSON files that allow your application to specify the way it should be treated when installed as an application on a mobile device. You may want to specify what the application name and icon should be. Maybe you want to tell the browser to tint some of its UI elements to match the color scheme of your page, or even hide the browser chrome entirely. You can do all of that with a web app manifest.

Assets manifests are JSON files that contain paths to assets that are generated by webpack. They're generated by plugins such as assets-webpack-plugin. If you add hashes to the end of your filenames to allow cache busting, assets manifests can be very useful. For example, we use our assets manifest to add JavaScript and CSS files to our <script> and <link> tags.

So I put a manifest in your manifest

While we were building our web app manifest, we wanted to be able to add a hash to the file path and <link> to it. So we needed to add it to our assets manifest. Unfortunately, we were unable to find any existing open-source plugins that output the file in the correct way to add it to the app manifest. So, we built webpack-web-app-manifest-plugin.

By default, webpack-web-app-manifest-plugin assumes that you will name your icon files in the format manifest/icon_[square dimension].(png|jpeg|jpg). If you name them using that scheme, you can use this plugin just like this:

If you named your icons with some other naming scheme, you can still add them to the web app manifest, it's just a little more work. That process is detailed in the README.

Please use it

We're really proud of the work we've done to make web app manifests compatible with asset manifests, which is why we've decided to open source it and publish it on npm. Please use it.

If this plugin doesn't meet your needs, we welcome pull requests. And if you have a passion for progressive web applications, webpack, and open source, join our team!

- Paul Rehkugler (@blistering-pree)

A Breath of Life: Welcome the Brand New Mobile Web Dashboard

We rebuilt another piece of the site with React

Background

A few months ago my colleague Robbie wrote a post about how the Core Web team is introducing a new web stack built on Docker, Node, and React. It is a beautiful vision, but we had only launched one tiny page on that infrastructure. This spring, we used that new stack to rebuild the mobile web dashboard from the ground up. And then we launched it.

Why we did it

We decided on building the mobile dashboard next for a few reasons. First, the dashboard is one of the most important parts of Tumblr—for many people it is their primary window into the content here. Because of that, most things that we develop inevitably touch the dashboard. It was time to raise the stakes.

The desktop dashboard and the mobile apps have been moving forward at a blistering pace, but have you seen the mobile web dashboard? It was stuck in 2015. Nobody ever made features for it because it was a completely separate codebase. We avoided that issue with the rewrite. Since the new version we're building is responsive, our new mobile web dashboard will eventually also power the desktop web dashboard experience. This'll make it much easier to maintain feature parity between the desktop and mobile web experiences.

Finally, we wanted to make something a little bit more complex than the image page, and the mobile web dashboard seemed like a good next step. It allowed us to start making authenticated API calls and figuring out how to pass cookies through our new server to and from our API; to think about laying the groundwork for a totally responsive dashboard, so we can eventually launch this for the desktop; to make a testing ground for progressive web app features like web app manifests; to start rendering posts that are backed by the new post format; and to figure out how to slowly roll out the new stack to a consistent, small set of users. We also had a pretty bad performance bug and learned a whole lot about profiling Node. (We plan on writing more in-depth posts about some of these topics soon.)

It is good

And the rewrite turned out really well. Even with more features like pull-to-refresh, a new activity popover, and modern audio and video players, we sped up our DOM content loaded time by 35%! The new page has a lot of modern web standards in it too like srcsets, flexbox, asynchronous bundle loading, and a web app manifest. You can install the mobile web dashboard as a standalone app now. It was also way faster and simpler to write using React than it was on our old PHP/Backbone stack.

We're really proud of the new mobile web dashboard. We look forward to bringing even more new features to it in the near future, and launching even more pages on our new web infrastructure.

If you think this is cool too, come work with us!

– Paul Rehkugler (@blistering-pree)

Come join us!

If you’ve been following this Tumblr, you’ll likely know that we, the Core Web team, have recently started rewriting and modernizing the Tumblr web platform. This undertaking presents some incredibly exciting opportunities to innovate with lots of fun technologies. We’re working on improving every aspect of the web; the dashboard, the archive, the blog network, you name it.  

Are you a senior JavaScript engineer and wanna be a part of this adventure? Come join Core Web! You’ll help create the building blocks with which a brand new modern Tumblr will be built. Your work will directly impact and define the user experience for millions of users and the development tools for a large number of product engineers across several teams at Tumblr!

What you’ll do

We’re looking for an extraordinary senior JavaScript engineer who wants to take on the following challenges:

Who we’re looking for

An ideal team member is someone with:

Our current toolkit

If you’re interested, but your background does not include all of the above, please don’t let that hold you back. Let’s talk! To apply, follow the instructions at the bottom of our official job listings page! 

We can’t wait to hear from you!

A Big New Beautiful Future for the Web at Tumblr

In the ten years that Tumblr’s been around, a lot has changed in web technology. We’ve kept up, of course, but it’s always been a process of addition, layering one new technology on top of another. And what we were working with—a custom framework built on top of Backbone, messily entangled with a PHP backend and its associated templates—was becoming unmanageable. Our piecemeal conversions to new technologies meant we had thousands of ways posts were rendered (only a moderate exaggeration). And each of those had to be updated individually to support new features or design changes.

It was time to step back, survey the world of web technology, and clean house in a big way. That we could finally test some of the new tech we’ve been itching to use was just a little bonus.

We started by laying out our goals:

With those goals in mind, we spent the beginning of the year on research - figuring out what kinds of things people were building web apps with these days, tooling around with them ourselves, and trying to assess if they would be right for Tumblr. We landed, eventually, on React, with a Node server (running Express) to make isomorphism as easy as possible. On top of that, we’re using Cosmos for developing components, React Router for routing, and TypeScript to make our lives better in general. (My colleague Paul already wrote about what went into our decision to use TypeScript here.)

As if writing an entirely new stack wasn’t enough, we realized along the way that this was our perfect chance to start deploying containerized applications with Kubernetes, a first for Tumblr. We had never previously deployed a node application to production here, and didn’t have the infrastructure for it, so it was a perfect green field on which to build another new and exciting thing. There’ll be more to come later on Kubernetes.

So where are we now? Well, we’ve launched one page powered by this new app - image pages, like this - with more to come very soon. 

Though it may seem simple, there’s a whole new technological world between you clicking that link and seeing that page. There’s a ton more exciting stuff happening now and still to happen in the future, and we’re looking forward to sharing it here. Wanna get in on the action yourself? Come work with us: https://www.tumblr.com/jobs.

- Robbie Dawson / @idiot

Flux and React in Data Lasso

TL;DR

Flux helped bring the complexity of Data Lasso down, replacing messy event bus structure. React helped make the UI more manageable and reduce code duplication. More below on our experience.

tumblr.js update

We just published v1.1.0 of the tumblr.js API client. We didn't make too much of a fuss when we released a bigger update in May, but here's a quick run-down of the bigger updates you may have missed if you haven't looked at the JS client in a while:

Check it out on GitHub and/or npm and star it, if you feel so inclined.

tumblr.js REPL

When we were updating the API client, we were pleasantly suprised to discover a REPL in the codebase. If you don't know, that's basically a command-line console that you can use to make API requests and examine the responses. We dusted it off and decided to give it its own repository. It's also on npm.

If you're interested in exploring the Tumblr API, but don't have a particular project in mind yet, it's a great way to get your feet wet. Try it out!

Data Lasso 2

Data Lasso, Tumblr’s three-dimensional visualization tool, just got a serious upgrade. Along with a version bump to 2.x, Data Lasso now has some handy new features (as well as completely reworked internals). A GIF is worth a thousand words:

Quick refresher: Data Lasso is a visualization tool that Tumblr built that allows us to look at large multi-dimensional data sets quickly. If you haven’t tried it yet, check out the hosted version here.

New stuff

Reworked Internals

A lot was changed under the 3 dimensional hood of Data Lasso.

It won’t be a major version bump, of course, if it did not contain backwards incompatible changes. With a move to Flux, the event bus was deprecated. So if you are using Data Lasso inside your app and rely on events for interacting with it, you will have to switch to using Store and Dispatcher instead. It is good in the long term - as it provides so much more clarity into what’s going on inside Data Lasso.

That should be it! Overall, 2.0 is a solid release that adds new fundamental functionality, while allowing for future work to go smoother. As usual, if you encounter a problem - open an issue on the repository.

Here at Tumblr, we use a JS bundler to compile our client-side code. As time went by, we started to feel the very real effects of bit rot in the form increasingly slow build times and the realization that were were 9 major versions behind on Browserify with no straightforward way to upgrade.

Moving things out of critical rendering path

Tumblr’s web pages are heavy.

Naturally, the heaviest strain on the network comes from the content - filled with heavy gifs and other content. However, we also load embarrassingly large amounts of JavaScript. There is one particularly heavy JavaScript file that contains our vendor libraries (e.g., jQuery, Backbone, etc), which we call the vendor bundle.

It was loaded right on the top of the page, significantly adding to the critical rendering path. But we don’t need it there, being one of the first things user loads. Moving the vendor bundle down the page might result in performance gains and a more responsive page load time - all are great goals that Tumblr’s Core Web team is set on accomplishing.

After a few months of patching ancient, legacy inline scripts, and running performance tests, the script is finally moved to the bottom of the page! Even more, with this effort we decided to really dig into performance - we conducted A/B testing of that move (establishing performance split testing framework along the way) to see what exactly what effect the move would have on our site’s performance.

Results

Starry eyed and excited to see improvements across the board (that file exists on nearly every page of tumblr, after all) we jumped head on into the data to find ourselves amused and slightly disappointed.

Turns out, the performance gains that we expected to see from moving a heavy file out of a critical rendering path were not there. The 75th percentile of page load times across the board remained the same. We suspected that analyzing on a more granular would reveal performance gains on certain pages or even certain browsers - but results were pretty uniform. See for yourself - below are boxplots for performance on the dashboard:

Was our approach to taking measurements incorrect? We revisited numbers again and again. We looked into finer detail at various pages. We excluded IE9 after hypothesizing that it might skewing our results. We measured across several metrics that we had at our disposal (we sample actual navigation timings from actual users). Results remained the same.

Outcome

As much as we were disappointed, we were also glad that we ended up knowing precisely what effect we had on the performance. Oftentimes we take blind faith that best practices will lead to best results, and fail to realize that myriads of factors weigh in on actual outcomes.

If anything - we learned a lot from this experience. We gained better insight into our codebase and established an approach to measuring performance in future experiments!

Data Lasso

There I was. Stranded. Alone with my hive query export of many thousands of records, earned by a tireless series of painfully refined select statements, needing to identify what the outliers were in this madness of data.

"I have data. Now what…Crap." I mumbled to myself, realizing that I am limited to a few unpromising options.

Flexing my brain muscle, I tried to recollect bits and pieces I knew on mighty R. “What was the name of the library? ggdraw? ggchart? Dammit it’s ggplot.” Prospect of trying to remember cryptic R work was dooming, weighing heavily on a tired engineer who had enough of suffering for the day.

Then a shameful thought passed through my mind: “Just open it in MS Excel. No one has to know.” Countless minutes passed as I was still looking at a beach ball of death, spinning as the naive program tried to open my data set and obviously failing.

Desperation fell on a lonely engineer. There’s got to be a better way. A way to easily visualize the data set as a whole and not needing to write code for it. Just plug in the data set and specify what to show from it. A scalable solution. Firmly deciding that no one should have to be stranded in that situation, a determination came to write a tool that will solve that gap. So was born the Data Lasso.

Data Lasso

Data Lasso is a visualization tool that allows exploration of arbitrary set of data in 3D. It is built to be agnostic to the structure and formatting of data.

There is no setup. You don't need to prepare your data, .csv, .tsv or .json will do. It can easily visualize half a million entries. All of that in a three dimensional space, so you can have complete freedom of looking at your data.

Data Lasso can help answer such fundamental questions as:

Under the hood

Future

WebGL. The future is upon us, and 3D in a browser is a reality. Using three.js to help wrangle WebGL, Data Lasso benefits from that extra dimension a lot. Rotating, moving and zooming in 3D space gives additional freedom to look at your data closely.

Data Lasso can visualize around half a million entries - all thanks to shaders that allow to take rendering off the CPU and pass it on to the GPU. Shaders alone might have been the single most important breakthrough for Data Lasso, enabling those smooth 60fps even with large data sets.

Goes well with your stack

At it’s core, It is built to be extensible by means of modules, that can hook right into Data Lasso event bus. That allows you to set up data flow out of Data Lasso that is customized for your needs, or add a UI on top of the Data Lasso to be specific to your data.

Data Lasso can be used standalone, but it was not made into an npm module for no reason - add it to your stack and serve it up from your systems.

Data Lasso was used inside Tumblr for several months, and shown itself to be an extremely useful visualization tool, filling a big gap in a workflow of working with data.

Now it’s open sourced. Go check it out.