Non Tech / Writing

Blogging: Ideation

On 28th March 2011 I published the first ever blog post to Styling Android. Almost 9 years later there are now, as this is published, some 458 published articles. When I first started out, I did not have a clue what I was doing, and some might say I still don’t! After writing so many posts I have found a process and rhythm for writing blog posts which seems to work for me, and it occurred to me that it might help others to find their own blogging voice to share how I go about it.

The first thing worth mentioning is that everyone is different and just because something works for me does not mean that it will work for everyone. The important thing is to find what works for you personally. My hope is that this post will help some folks to either start out writing posts, or find their own way of working.

The starting point for any blog post is the initial idea of what to write about. For me the inspiration for this can come from many different sources. The one that happens quite often is where I encounter something in my day job which I immediately think: “There’s a blog post here”. This can be encountering an Android framework or AndroidX API which I wasn’t previously aware of, or, more commonly, it can be a gotcha that caused me a lot of head scratching and attempts to Google a solution were unsuccessful. An example of this is the recent post I did on Kotlin Serializable Objects – I encountered this in my day job and a colleague, Matt Dolan, pointed me in the right direction. But a blog post resulted, nonetheless.

There’s an interesting addition though: Matt had already written a blog post about this very issue and I considered whether I should write my own post, or simply share Matt’s post. I felt that I could frame the problem in a different way to Matt’s post. Please feel free to compare the two and I’m sure that most people will agree that the two posts approach the same issue from very different viewpoints. That raises another important point: Never feel afraid to blog about a subject that someone else has covered previously. If you can offer a different viewpoint, insight, or detail.

Another great source of inspiration is events like Google IO and the Android Dev Summit where lots of shiny, new APIs and tools get announced. Also keeping an eye out for new releases of AndroidX libraries & features is a good source of inspiration. There is an easy trap to fall in to here, though: Simply re-writing the official documentation for these is pointless because it adds no value. Most devs will read the official docs first and look to third-party blogs for the information not covered there. If your post is simply a rehash of that then you’ll frustrate the very people that you want to attract to your blog.

Back in the early days of blogging, I felt that there was value to be had in being the first to publish something on a particular API or technology. My viewpoint on this has changed subtly but, I feel, quite importantly. Being the first to publish something uniquely insightful on a particular API or technology is actually what’s important. If you cannot add any value to what is already available on a particular subject, then why bother? An example of this, for me, was when View Binding was first announced / released. I saw a few blog posts which were simple rehashes of the official documentation (I won’t name & shame, so please don’t ask), and I personally see no value in that. My approach was to consider aspects that I hadn’t seen covered elsewhere, and focused on the impact in terms of both APK size and build speed to add value. The official docs perfectly covered the aspect of how to use it, so I focused on other areas.

Another source of inspiration is to just browse the official reference documentation. Sometimes you will come across something that you weren’t aware of in either the framework itself, or AndroidX. An example of this, for me, was the support of HEIF images in Android. As before, I felt it was important to add value to what was covered in the official documentation.

Another thing worth considering is things which actually interest you and how to apply that to the area in which you’re blogging. I am, I think quite obviously, interested in things visual and looking at how to do things like image processing, and rendering the Mandelbrot set have provided me with some initial inspiration which then followed on to some Android-specific insights.

A recent occasional series that I have been writing is the AnimatedIcons series. This was inspired by the website which contains some really nice Lottie animations, and I thought that it would be interesting to try to implement some of them using AnimatedVectorDrawable instead of Lottie. The series has, I think, enabled me to explain some details of both SVG path data and AVD in small, easy to digest segments.

Other times, there will just be blind ideas. One evening I was having a beer and the thought of doing parallax scrolling popped in to my mind. The blog post duly followed.

Inspiration comes in many forms, and the key thing is to learn to recognise them. I now have a firm mindset when I have an “I could blog about this” recognition in my day job, and I have a number of other sources that I use for inspiration.

An idea is only a good one if I feel that I can add value to what is already publicly available. There have been many ideas that have fallen by the wayside because I could not see where I could add anything.

Let’s take a moment to consider what I mean by “add value”. While I stated earlier that I feel it is fine to cover material that is previously covered elsewhere, there seems to me little point in doing so if there is nothing new to be gained from my article. For example, with the View Binding articles that I mentioned earlier simply rehashing the official docs would not have provided the reader with any thing more than the official docs. However I felt that there was an area worth exploring which wasn’t covered anywhere else that I could find – what effect using View Binding would have on APK sizes and build speeds. Another example is the Kotlin Serializable Objects post – although I was aware that Matt had already written his own post, his post was quite academic in nature (there’s absolutely nothing wrong with that, by the way) but I felt I could offer a very different perspective on it by framing it from a much more practical view point in terms of how I actually encountered it in a real world scenario.

I do not, however, do exhaustive searches for articles on any subject that I’m considering. The reasons for this are twofold: firstly, it would be very time consuming; and secondly I would not wish my article to be majorly influenced by what others have written, which may happen at a subconscious level. That said, I’ll always check out any official documentation (which should be a trusted authority) to ensure that what I am planning is not already covered there, and anything that I may have come across either through researching the subject myself. Also there are other incidental sources such as: if I see an article in Android Weekly or Kotlin Weekly which is covering a subject that I’m planning, then I’ll take the time to read it to ensure that I’m offering something different, or in addition.

The entire writing process is actually a funnel – at every stage there will be losses. Here we have covered the first two stages of that funnel – the initial idea, and then deciding whether there’s something viable from that idea. But we don’t have a blog post yet. In the final article of this short series we’ll cover the final two stages of my personal blogging process.

Many thanks to both Claudia Luque Fernandez and Filipe Mendes for proof-reading this article and providing some valuable feedback which helped to improve it.

© 2020, Mark Allison. All rights reserved.

Copyright © 2020 Styling Android. All Rights Reserved.
Information about how to reuse or republish this work may be available at

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.