What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
Static and dynamic content editing
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
How to customize formatting for each rich text
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
Bug-bashing and Android with OSOM's Head of QA, Prabhakar Thirumoorthy
Building something means more than just tossing pieces together and calling the first result “done.” It’s an iterative process with emergent properties and systems interactions that require fine-tuning and feedback to adjust to perfection. This is the domain of quality assurance, and Prabhakar Thirumoorthy is OSOM’s expert on the subject, with over a decade of experience working with Android from his time at Google.
I recently had the pleasure to sit down with Prabhakar and talk about both his work on Android at Google, his take on the platform’s biggest strengths (and greatest weaknesses), the hardest bugs to track down, and his favorite details about Saga.
It’s tough sometimes to know what someone does just based on their title at a startup, so many of us do so many different things. But you’re OSOM’s Head of QA. Previously, you’ve worked at Google on the Android and Cloud teams, doing test engineering work there. I think a lot of people reading this might not know how software development works, so can you tell us what QA is?
It’s interesting, it comes up when you work with a new team, actually. Most of the time, people think quality assurance engineering is the least important section in the org. But that’s not the case, it’s very important stuff. Having good test engineering skills on a product is very, very important before releasing anything out into the world. We have a lot of insight, and a lot of responsibility. We (as a test engineer) are involved in the whole life cycle of the product from scratch to development, release and support. We play many roles — QA is not just QA.
We have to train ourselves to think from new perspectives. When you release a product, it has to go through a very good testing cycle to ensure good quality. I’m very proud of that.
I work in a demanding mode, not a commanding mode. I request things, I don’t command things — “Can you please do this?” That’s my style, and people like that, which helped my career. I had a very good manager back at Google who taught me a lot. How to write a bug summary, how to file a bug report, how to ping people for follow-up.
Because some of it is pretty cool, can you talk about some of the things you worked on at Google? Among whatever things you can talk about.
There’s nothing to hide, actually. I was part of all the Android launches from Cupcake to Pie [Editors note: this covers Android 1.5 in 2009 through Android 9 in 2018!]. I was responsible for more than 20 major releases, including security patches and maintenance releases. I know the ins and outs of what is happening with Google software and Android, including wearables, TV, VR headsets. I have extensive experience on all of Google’s products. Working there was a very very great experience, actually.
The last couple of years, I moved to Google Cloud, where I got the chance to work on more internal products — very small channel customers where we extended our internal products to external customers. I did that for the last four years before I moved to OSOM. But I was at Google from 2008 to 2020.
Like all the developers here, you know Android backwards and forwards.
I still have my Droid! Remember sliding phones? I still have all those old phones, actually.
After so long, you can’t help but be an expert on the subject. I am curious: what do you think is Android’s biggest weakness and biggest strength?
What I am hearing most now from friends that switch from iPhones is that it is more user-friendly. My wife, too — she used an iPhone, and I gave her an Android, and she finds it easy to use. Even kids, they can operate it very easily. That’s what I feel is its greatest strength.
For weakness, I would say the display: as in the icons, animations, everything there. That’s really great on iPhones. Before, I would say — Android has made big improvements in battery life, for sure. Until Jelly Bean, we couldn’t fix battery performance, but they’ve done a lot of work then. Most phones last at least two days now.
What if you could change one thing about Android to make it better?
Those things — battery life, performance, and UI. Android feels like a very native UI, but it’s not a fancy UI. And there is a long-term ask: Having small phones come back would be nice.
A lot of QA involves dealing with, tracking down, and fixing bugs. Across all of the work you’ve ever done, what are the most difficult bugs you ever saw?
Random reboots and kernel panics. It’s just very hard to diagnose those kinds of bugs — when they happen, there is no record to look at. Also some bugs with GMS [Google’s apps on Android]. Without a proper GMS update, you can have some issues. But from a stability perspective, I would just say random reboots.
Even with a dashboard and automatic reporting at Google, there was a rebooting issue Android had that we couldn’t fix until maybe after — I think Ice Cream Sandwich? We had no clue what was happening; there were no logs. Slowly the system team was able to capture kernel panic logs with a new tool to see what happened before the reboot. That’s a beautiful thing.
There is one other ugly thing. Android shows the crash dialogue, but iPhone doesn’t do that. They do a silent crash in the background, so no one knows what is happening. I don’t like that.
What was your favorite thing to work on for Saga?
It runs Android, and I’ve worked on similar things before. So I feel like I’m back on my own ground, at home. I had that break for 2-3 years working in the cloud, and I am so happy to be back to my mobile world.
I was able to file so many bugs into the system since joining. The number of bugs filed in a year before, I did in one document, because I know the system, I know the domain, I understand everything in and out. I was able to make a lot of changes here. I love to work on mobile, it’s my area of interest, and I’ve worked on it for almost 15 years, so coming back to that same interesting field makes me so happy.
What is your favorite feature on Saga? Which thing about the phone do you like the most when you use it?
I can see a big difference with our camera compared to other phones. Everything is functional — I mean, Gmail, Chat, the system is the same. Not that every phone is the same. But the biggest difference in Saga for how I use it is the camera. Seed Vault also, but I don’t use those features as much. Our camera makes a big difference.
I feel like I already know the answer to this one, but one last question that I like to ask department heads here: If you could work on any project, any product, anything at all, what would it be?
Anything related to phones, tablets, I am happy to work on it, because I really want to work on the things that I know about. But I am open to trying new things outside of that. It depends on the cycle — how fast you want to deliver the product. I know the whole QA cycle and software development cycle to support testing from the start, and I am open to anything.
You’re an influential and critical part of the team here, Prabhakar. We’re lucky to have you here, making sure the work we do is good quality. Great talking to you!