Over the past decade, I have submitted abstracts to countless conferences, and been accepted at hundreds of events around a good portion of the planet. I do not say that out of ego, and in fact, I never even thought about the sheer number until I was recently asked "Where do you get abstract ideas?" Where do ideas come from? A good question indeed.
I spend a lot of time thinking about the software market. Probably too much. In that thought though, I often think less about the product, and more about the problems that the product is trying to solve, and how people will use it. A recent example is AR (augmented reality).
I first saw AR done with Flash years ago. It was a cool gimmick. A few years later, I saw my daughter with an AR coloring book. She would color the picture, point her phone's camera at the picture, and the scene would pop off the page and come to life. It was there that AR stopped being a gimmick to me, and started being a feature.
AR on the client side is still nascent. It requires a heavy mix of 3D modeling, computer vision, hardware, and much more. There is fertile ground for ideas.
An abstract on using a specific 3D framework such as Three.js is a great topic. Further then would be a comparison of the 3D frameworks on a single platform. Or potentially, across various platforms. These types of topics help developers understand what is best for their application, and that, to me, is exactly what advocacy is about - making developers heroes for the task that they are trying to accomplish.
Meetups are an awesome source of inspiration for ideas. You get to see what people are working on, talk with others about their thoughts on the topic, and hear questions. The questions help understand the things developers are attempting to accomplish with the technology.
One of the terms you might hear in a traditional IT environment is 10% time. That is the time that developers get to work with technologies that they find significant in some fashion or other. As an advocate, you get 90% time (not quite, but you get the idea). You get to spend 90% of your time working with technologies that are significant to you. The technologies that are significant to you as an advocate, are the ones that will make heroes of the developers that spend the other 90% of their time implementing product for their employers.
Booth duty is often dreaded by advocates. Long days, in an often unforgiving booth configuration, knowing full well that you have a pile of work to do when you get back to the hotel. For me though, booth duty means more questions - more clarity on what it is that developers are trying to accomplish with your technology, or technologies related to it.
At a booth you will likely start to hear a trend in the questions. As example might be how your product works with other products that were announced at the event. Or how an attendee was in a session where the presenter was talking about a specific technology, and thinks that your product might help implement what they heard.
As an advocate, these are diamonds in the rough. Do not dismiss the question, or simply point to some obscure documentation, rather, think about the questions. Explore the things attendees mentioned. See if you can integrate them with your product(s). When you find a synergy, you have the foundation of an abstract relevant to a broad audience that you can submit to conferences.
Another conference-related area often neglected by advocates is the rest of the exhibit floor. Get your badge scanned and take in some demonstrations from other vendors. Getting your badge scanned means more email spam to deal with if you are a corporate developer, but as an advocate it is the beginning of a professional network - one that is a window into how other vendors are thinking about a similar space.
Much as making developers heroes by spending your 90% time on their problems, spending 90% time on how to integrate with other vendors makes the vendor (the developers who work for that vendor) heroes. In some situations, these explorations can lead to fruitful partnerships. This will make you a hero at your place of business.
So long as we are talking about events, going to the sessions, listening to them, and taking thoughtful notes will help you start to formulate ideas for your own sessions. Further, as a reflection of the meetup scenario, the questions that other attendees ask reveals the problems they are trying to solve. If you can help them solve them, then you are making them heroes.
It never fails that at the end of your presentation, despite a lengthy question and answer portion, there will always be somebody that approaches you after your session ends. They will have questions. Genuinely listen to those questions. Think about where those questions come from. Did you leave something out in your presentation? Did you open an unexpected door to an area you had not previously envisioned?
A common approach by advocates is to refer to a blog post, or some documentation somewhere. This is fine, but you can go further. If the question is something you think you might be able to solve directly, get their contact information. Try a naive implementation to answer their questions. Share the code with them. These types of work often create the foundation for future conference abstracts.
Nobody understands an event, whether it be a conference or a meetup, better than the people that organize it. As an advocate, events are your bread and butter, so it behooves you, if only from a networking perspective, to know who they are, and build a relationship with them. Event organizers often have their own ideas of what they want(ed) to have presented. Often, conversing with the organizers will reveal topics that are submitted too frequently. This helps you refine your ideas, and submit better abstracts to their events, and others.
This then brings the source of inspiration back to you. You can be your own source of inspiration. I personally keep an [Evernote] notebook dedicated to inspiration. Sometimes I put silly pictures in the notebook. Transcripts from TED talks. Efforts by cities to solve municipal problems. User interfaces or interactions I find compelling will go in there as well. When I need an idea, I look back through that notebook.
==The other aspect of inspiration is in solving problems that you have personally. ==
I once gave an IoT talk on storing and analyzing data. The backdrop of my demonstration was a device I built to track how often my cats used the litter box. Gross? Sure! But I was curious, and IoT seemed like it could help me answer that question. While ML (machine learning) was not prevalent at the time, I now wonder if I could use it to identify which cat used which litter box. Moar ideas!
This exploration of litter box usage lead to all fashion of interesting problems to solve such as designing an enclosure - cat urine and electronics do not mix, but a metal enclosure would create a Faraday cage. I did not even know what a Faraday cage was until I had to start solving the problem on my own. Conference abstracts in their own right.
The key takeaway is to be your own hero, and do not be afraid to incorporate your own problems and personality into the solution. It has been said many times that the best products are ones created to solve an individual problem. Flickr as an example, was not the company's original goal - it was a side project to solve a specific pain point.
How about you? How do you come up with ideas for conference abstracts? Did I miss something? With some practice, I think you will find that you will have more ideas than you can possibly complete, and that you will have to start prioritizing, and sharing, them to continue to help developers be heroes.