Sometimes, you *are* Google (maybe)
In yesterday’s Tinned Fruit Missives, I linked to Antin Harasymiv’s excellent write-up of how the Google Photos photo grid was developed for the web. If you haven’t already, check it out.
We’re often told by persons of wisdom that “You are not Google / Facebook / Amazon / Microsoft,” and therefore, you should not copy what they do with regards to business strategy / marketing / design / product development / scaling / infrastructure.
This is normally very good advice. Although it can be interesting to read about how the big tech companies go about things, it’s not necessarily relevant or appropriate for your own needs. A great example of this is how Facebook scaled their release pipeline. These are just not problems that most of us will ever encounter.
UI development is a great leveler, though. We don’t quite have the same gulfs in scale to think about. After all, front-end code that runs in a browser is always run by just that one device for one user. Performance and usability gains (usually) apply equally, no matter the size of the user base or how many servers you have. (Yes, I know this is simplifying some things. I’m leaving things like CDNs, caching and real-time collaboration out of this for now.)
The Google Photos UI is a good example of scale in a user interface that has very little to do with the size of the company, development team or user base, and everything to do with the amount of data created and accessed by individuals. Small companies often have to deal with this too.
Indeed, the ability to gracefully handle large volumes of data, interactions or actions can be used as a unique selling point for a product, positioning it in the marketplace. The Google Photos team certainly see the importance of supporting users with a lot of photos.
The tactics, algorithms and tricks demonstrated by Antin in that article took a long time to develop. But they are extremely valuable in the context of the product.
The web platform and modern browsers have an improved capability to deal with complex UI challenges like this, but the capabilities are low-level. It still takes developers to pull them together to satisfy the specific goals they have for their product. What’s more, most popular component and view libraries don’t really help that much here. Many of us wouldn’t even try, because we lack the time, experience and support to get to the level of polish required to achieve a difficult outcome like this.
But small product teams have to take risks sometimes too. If you have a big core user need in your product, but it takes a big effort to get right, with no guarantee of success, do you take on that risk? Or do you take a simpler, cheaper approach, with a lower return on investment?
Hit reply and tell me about a time when you took on a big risky engineering like this and it paid off, or failed dramatically.
All the best,
– Jim
