Tag: Audience

Doubling Down: My Specific Strategy

Doubling Down: My Specific Strategy - https://www.publicdomainpictures.net/en/view-image.php?image=130306

Doubling Down: The Quick Background

I recently wrote about how and why I’m looking to double down on my strength to improve a weakness, and I figured it would be a great follow up to try and explain the specifics in my strategy. It’s an interesting learning opportunity for me, so why not share it with those that are interested?

The format of this post is really just to call out the specifics of some strategies I’m looking at exploring when building the brand for my vehicle to help with sponsorship opportunities.

Reach Outside Core Audiences

This one shouldn’t be a shock to you if you’re familiar with this blog already. It’s primarily aimed at programming, leadership in a tech environment, and self reflecting as a means to improve. One of my goals is to explore attracting other audiences that might have a bit of overlap with my core audience in order to build up awareness of my brand. In this particular case, I’m writing about branding in the online world and attempting to relate it to setting personal goals and establishing a plan to reach them. So while this topic is outside my core domain here, I think there’s some interesting overlap, and working on this will help me build up the knowledge for how to apply this to my vehicle brand.

I’d like to practice on this blog by writing about some things that are slightly outside of the norm for the content here and gauge how readers react. This learning will be used to expand the brand awareness of my vehicle when I apply it in that domain. Or that’s the theory, at least.

Linking to Related Content

If you’ve been paying attention, I’ve been trying to link you, my fearless reader, to other content I’ve created. It’s a simple tactic to provide you with more opportunities for the information you’d like to read more about and simultaneously keep you engaged with more of my own content.

The specific goal here is exploring how readers consume related information. When it comes to my vehicle brand, perhaps those that are interested in the wheel brand I use will also be interested in the air suspension setup I run. Perhaps the shop that does my work can gain more business because someone clicked a link or followed the breadcrumb trail to their site. Something about content synergy <insert eyeroll>.

Content Planning

Between the last post on doubling down and this current post, I had to do a little bit of work beforehand to plan content. This is something I need to practice more of, and I think I can do a good job of it when it comes to writing programming articles. So for example, I’m picking up more Unity3D work and would love to write more about Unity3D.

This will have great carry over for social media platforms when trying to plan content around events that my vehicle will be at. I can engage audiences better if I have a better plan for content, but this will take practice, time, and effort. The practice part is something I can work at on this blog with little risk because it comes a bit more naturally.

Ads: Hosting Them and Creating Them

This is a big one for me because it’s very new to me, in general. This blog runs ads, and without much experience, they’ve been able to generate a little bit of income (and I mean, very little). It’s something I can work at tuning to get better results, especially because I at least have a starting point to work with.

On the flip side, I’ve never created ads for my blog to drive traffic to this site. This is something I need to explore in order to help with the vehicle brand, and is a great example of doubling down on a strength. This devleader brand has better online presence (at least in terms of a website) than my vehicle’s brand. I think it would be a significantly easier experiment to work on creating ads for this site to drive traffic here and perhaps use my small ad revenue to seed this initial experiment. Minimize the risk!

Once I learn how to use ads better, I can perhaps apply this to the vehicle brand to drive more traffic to the content I create for that.

Calls to Action

For social media engagement, it’s really important to have calls to action. In the last post on doubling down, I added a call to action right at the end of the post. Did you see it?

Maybe not, and that’s okay because I’m practicing it. For Instagram and Facebook, it’s extremely helpful for generating impressions when you have your audience interacting with you. The more practice with creating good calls to action, the better I can do with my vehicle brand.

Next Steps

My next steps for my doubling down strategy are to start with creating some Unity3D articles. As I mentioned above, I’m looking to work more with Unity3D so it’s another great doubling down opportunity where it’s minimal investment for me (I’m already doing the research, I just need to write about my experiences) and a low-risk area to experiment in. I can practice some of the individual pieces of my strategy (as outlined above) in creating a series of Unity3D articles, and measure my success along the way.

If you’re a Unity3D programmer, what sorts of Unity3D articles would you be interested in? I plan to start some on Autofac and some cool patterns I’ve been using, but I’d love to hear what you’re interested in!


API: Don’t Forget About The Non-Public API!

Image courtesy of FreeDigitalPhotos.net

Background

From an object oriented programming perspective, an application programming interface (API) is often referred to as the way other developers can interact with the public members of your class(es) and interface(s). Of course, API can be used to describe how one interacts with a web service (or other types of services), but for this discussion I’m limiting the scope to that of interfaces and classes. Limiting the definition of API to public members (or the equivalent of C#’s “public” in other languages) is omitting one huge part of what it encompasses. The purpose of this post is to clarify, in my opinion, why I think forgetting about the non-public API can lead to bad framework and API designs.

API And The Audience

I’ve written before about what I think makes a good API, and I had some comments on Code Project on the same posting that lead me to this topic: the audience. There’s a lot to consider when you’re writing what many people would consider good, clean code. It’s impossible to please everyone because everyone has some sort of best practice, guideline, or convention that they follow because they believe it’s the best. So, I’m not going to tell you that some way is the best… I just want you to be conscious of your audience so that you can make better decisions.

Okay, okay… So what do I mean by audience? I’m going to generalize your audience (the consumers of your API) into two distinct categories. The first category is the group of developers who will be using references to things that implement your interfaces and your concrete classes. They’ll use the instances of the things you define. For example, let’s consider a something built-in to the .NET framework: the List<T> class. Your first group of API consumers are just going to use instances of this class exactly as provided by the framework. They’ll make new instances of them and pass them around to be used in functions, or make properties that return instances of List<T>, or declare variables of type List<T>, etc… They use it as is, as provided.

The second general group of API consumers are the ones who are going to be extending your interfaces and classes. A great example of this is the EventArgs class. This class is super basic; It doesn’t do anything! Anyone who wants to use the EventArgs class essentially has to make their own class that inherits from EventArgs. Another example of this is the Exception class. Again, this class is built for people to extend it with their own implementations. I suppose both of these examples are pretty primitive because the base classes don’t offer much functionality, but what if your class wanted to let child classes override the default behaviour? I’ll have some more concrete examples of this later on.

Intentions Of The Audience

With these two general types of consumers defined, it’s a bit easier to consider how people may want to use your API differently. The first class of consumer wants to able to easily call your methods that you’ve defined and easily create the objects/interfaces that are core to your API. This means that the input they need to provide should be extremely basic, so using things like built in interfaces, or other classes that you’ve defined that are easy to create. These consumers also want information-rich return values and classes. Why? Because it makes their life easy! If they only need to provide a little bit of information and they get a lot back, they’re able to do a lot more with the data that they have access to. They don’t need to (and they certainly don’t want to) call 10 different things in intricate ways to get a little bit of data back.

The second class of consumer takes the exact opposite perspective. Here’s why. In the first case where the first group of consumers want to pass in only minimal information to methods, the second class of consumer wants lots of information passed in. This class of consumer is required to do some job or return some data, so the more information they are provided the easier it is for them to perform their job. Similarly, they want the return values of methods to be as simplistic as possible. Why? It makes their job easier! If they are responsible for returning some incredibly complex class from a method defined in your interface, and the input to that method is only minimal information, this makes the job of the second class of consumer quite difficult.

The best way to remember these similarities and differences is that the flow of data is opposite depending on what type of API consumer you’re talking about. The first type of consumer wants to provide a little and get a lot, and the second type of consumer wants to get a lot and provide a little. Makes sense right? Everyone wants to do the easy thing.

The take-away here is that depending on who you think your main audience is going to be for your API, it will affect how you structure it. And this is exactly why forgetting about the non-public API can be a huge mistake. Forgetting this part of the API makes the whole thing difficult to extend because your base classes cannot as easily be built on top of. You actually make the lives of the second class of API consumers very difficult if you ignore their needs.

Example: WinForms

If you’ve done desktop application development in C#, you’ve likely used (or at least heard of) WinForms. Some people new to desktop application development might have actually started with Windows Presentation Foundation (WPF), but the same concepts will apply here. In my opinion WinForms is a great example of an API that has both public and non-public components that were designed with both audience types in mind. Let’s start with the first class of API consumers.

If you’ve dabbled in WinForms, you’re likely familiar with the Windows Form Designer offered in Visual Studio. If you are… then congrats! You’re the first class of API consumer that I’ve described. By using the built in classes like Buttons, TextBoxes and Labels, you’re using the out-of-the-box components offered in the framework and consuming the public API offered by these controls. You’ll be using things like the Text property offered on these controls and interacting with them via their events (i.e. hooking onto click events or text changed events). You’ll be using the public API. Nothin’ wrong with that!

//
// MyButton
//
this.MyButton.Location = new System.Drawing.Point(146, 84);
this.MyButton.Name = "MyButton";
this.MyButton.Size = new System.Drawing.Size(75, 23);
this.MyButton.TabIndex = 0;
this.MyButton.Text = "Click Me!";
this.MyButton.UseVisualStyleBackColor = true;
this.MyButton.Click += new System.EventHandler(this.MyButton_Click);

private void MyButton_Click(object sender, EventArgs e)
{
    // do stuff!
}

Now, the creators of WinForms weren’t dummies. They knew that they weren’t going to be able to offer you every possible control you’d ever need. They made the API in WinForms have great support for the non-public members of their base classes! So, what do I mean by that?

Let’s pretend we want to have our own fancy button class. Because our button is fancy, we always want to tell the user just how fancy it is when they click it. Now if the framework you were using had a poorly designed API, you might be forced to code a button from scratch. That would be pretty lame considering the complexity of the built-in controls offered to you already. For this example, you could surely just create one button and hook an event handler onto the click event (using the public API), but what if you wanted to re-use this everywhere throughout your user interface? You’d want your own FancyButton class that has this behaviour built-in so you can easily reuse it. No problem.

private class FancyButton : Button
{
    protected override void OnClick(EventArgs e)
    {
        base.OnClick(e);
        this.Text = "The fancy button was clicked.";
    }
}

The non-public API in WinForms gives you access to built-in behaviour of the base classes. You don’t need to hook onto events to get the job done, you can actually override the OnClick method and prevent the click event from even firing! The focus on the non-public API allows developers to extend the built-in classes without having to design their own from the ground up.

Summary

It takes a lot of practice and experience to be able to write a good API. There’s also plenty of different opinions on what constitutes a well-designed API. In my opinion, you need to give a lot of thought as to how your API will be used. Consider the two general types of API consumers I’ve defined: The consumers that use your API with the public parts of the interfaces and classes you’ve defined, and the consumers that want to extend your defined classes to provide their own related implementations. These two types of consumers will want very different things, and in order to please the second class of consumer, you absolutely cannot forget about the non-public API.

Some food for thought:

  • How can I best guess how developers will use my API?
  • I’m providing base classes with my framework and API. Can people easily extend them through inheritance? Will people want to extend them?
  • What would make my public API easier for other developers to use?
  • What would make my non-public API easier for other developers to build on to my base classes?

  • Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.

  • Nick Cosentino

    Nick Cosentino

    I work as a team lead of software engineering at Magnet Forensics (http://www.magnetforensics.com). I'm into powerlifting, bodybuilding, and blogging about leadership/development topics over at http://www.devleader.ca.

    Verified Services

    View Full Profile →

  • Copyright © 1996-2010 Dev Leader. All rights reserved.
    Jarrah theme by Templates Next | Powered by WordPress