I've been listening to podcasts recently via Overcast's web player. It's good, but not great. An excellent MVP, but, unsurprisingly, not as good as the iPhone client.

No "Smart Speed", and as far as I can tell, 99.44% sure there's no Voice Boost either. It also syncs with my phone poorly. Poorly might be a little too strong, but not by much. I need something like Apple's Handoff, where I can listen to a podcast in the browser, grab my phone to jump in the car, and have Bluetooth pick right up where I left off. That's not working.

So the web client, though good, isn't great. But is it worth improving?

I've got lots of reactions there, including the comment Gruber gave me that, "a fair number of listeners listen right from the web page." The web is more popular for podcast listening than I'd expected.

But the main thing I think about is Marco & David Smith's comments about figuring out what the user is using before you bother coding new features.

Here's a quote from _David:

Being able to make my decisions based on numbers... makes me more honest with myself, because it's so easy to trick yourself into thinking something's more important than it actually is. As an example of this... [Pedometer++], my most sort of popular app, has an Apple Watch component, which is great, and as part of the Apple Watch component, it has a complication, that you can install...

In my analytics, it tells me how many people have installed the complication, and I started getting the numbers back, and the reality is that a very small percentage of my users use the complication, which was different in my mind than what I had originally expected. I use it. I love it. It's the part of the Watch app that is most useful to me. But it turns out a lot of my customers don't use it. There are some. But it's very very helpful for me to kind of guide how much time and energy I should put into making that awesome, because I had a number to base on it. You know, if it's a few percent of people are using it, maybe it's not as important as I thought it was, and so [keeping track of usage analytics] helps me to be honest. [emphasis mine - mfn]

Let's do what all the cool sites are doing, and emphasize one of those quotes by repeating it, but making it LARGER!!

[T]he reality is that a very small percentage of my users use the complication, which was different in my mind than what I had originally expected. I use it. I love it. It's the part of the Watch app that is most useful to me. But it turns out a lot of my customers don't use it.

Sans a business case, it's a vanity project

But can we really determine what's useful by what's being used now? In David's case, I bet so. If we use Spolsky's rule of thumb that each barrier to entry loses you half your customers, well...

• All app users
  • App users than own an Apple Watch. -- 50%
    • All Watch owners that install the app on the watch -- 25%
      • All that installed the app that install the complication -- 12.5%

And, of course, the second bullet is much much less than 50%. No, no a Watch complication is probably not the best place to spend your time, unless Watch users are really your target audience. Then tell me your business plan. It's probably not ads, which make are Pedometer++'s main source of income, as I understand it.

That is, _David doesn't have, as far as I know, a way to monetize Watch users specifically. So why is he spending time there? Because he's building something useful. That's not a business case. Time to move on, unless you're doing a vanity project, which, honestly, it sounds like he was.

(And that's okay -- One, pretty much every project an indie picks has a little vanity in it. Otherwise, why do it and not something just as useful but a little more boring? Second, building something you'll use is an important part of most any service. If you can't dogfood it, nobody else is going to eat it either. You just need to make sure it's not dogfood for one.)

Overcast online: Is there a business case?

Which brings us back to Overcast online. If the web interface isn't getting much use, why not? Is it because people don't use web interfaces to listen to podcasts? Gruber and Snell say that's not the case. Would people listen in another web page, one away from those two guys' sites? Urmmmm... probably not many, but more than I would've thought at first. That is, what we've learned is that podcasting away from your phone isn't uncommon.

Could you do Smart Speed on the web? Probably not, practically speaking. Probably not without playing a file you're modifying on the fly on your own server, or, worse, forcing some wacky browser install. The first is an unwarranted expense, and the second is a horrible interface. Nobody's installing that.

That is, I'm pretty sure Overcast.fm is just a player, streaming the audio file from wherever the file lives. The web page is just a middleperson. It's a very thin client.

But you know what the web client doesn't have that it could add much more easily than Smart Speed and Voice Boost?

• Playlists (I just get a big dump of podcast subs in an alphabetical list on Overcast.fm)
• Persistent settings (like what speed multiplier I use on each podcast -- the iOS app keeps track podcast by podcast)
• Recommendations
• Great syncing

If you gave me a full[er] client, would I listen on the web more? Yes. Yes, I would. And do you what else? The web client is more visual than the app on my phone. I'm not using my car's Bluetooth radio's buttons or my headphone clicker to pause. I'm looking at the screen I pictured, above, as I mouse over to it to click.

And do you know what you could put there? That's right. If not ads, then at least a donate button.

That sounds like a business case. It might be worth a couple of weeks of development.

Labels: analytics, business, coding, features, indie

When you're writing a Markdown editor, you have to be worried about Markdown formatting in two distinct, and not always especially related, ways.

The first is that you have to format the Markdown into html markup correctly. That's a no-brainer requirement, and there are plenty of libraries to help you convert raw Markdown to html. That said, there are extensions to Markdown that sometimes require quite a bit more discussion than you'd expect. If your favorite Markdown parsing library doesn't include these extensions, do you write them yourself? Change parsers? Etc, etc. Typical library evaluation stuff.

The second consideration, however, is how you make your users' Markdown input more graceful.

Take the following example. Say I've got this text...

I was reading the following snippet on Mozillazine.org about the history of replying about and below quoted emails:|

... and I have the cursor exactly at the "pipe" character -- | -- what should happen if I pasted in my clipboard's contents as a quotation (Ctrl-Shift-V in my editor)?

There are a number of choices. The pasted quotation could read...

I was reading the following snippet on [Mozillazine.org](http://kb.mozillazine.org/Reply_above_quoted_message) 
about the history of replying about and below quoted emails:
> Traditional netiquette (especially on Usenet and mailing lists) is to reply contextually beneath quoted material, trimming down the quotes to the minimum needed to establish context. Also known as inline, interspersed and interleaved posting, this does not always put your entire reply beneath all of the quoted material, because if you are replying to multiple paragraphs, each section of the reply would be beneath the quote of the paragraph to which it is responding. Some people prefer to start their cursor at the top of the message in order to facilitate moving down through the message and trimming the quotes before typing replies contextually.|

Or they might prefer another newline before the quote so that you had the quoted material nicely set off...

I was reading the following snippet on [Mozillazine.org](http://kb.mozillazine.org/Reply_above_quoted_message) 
about the history of replying about and below quoted emails:

> Traditional netiquette (especially on Usenet and mailing lists) is to reply contextually beneath quoted material, trimming down the quotes to the minimum needed to establish context. Also known as inline, interspersed and interleaved posting, this does not always put your entire reply beneath all of the quoted material, because if you are replying to multiple paragraphs, each section of the reply would be beneath the quote of the paragraph to which it is responding. Some people prefer to start their cursor at the top of the message in order to facilitate moving down through the message and trimming the quotes before typing replies contextually.|

Or they might like to have that quote wrapped so that it's not one giant ugly line with a single greater than (>) in front of it ^[1]...

I was reading the following snippet on 
[Mozillazine.org](http://kb.mozillazine.org/Reply_above_quoted_message) 
about the history of replying about and below quoted emails:  

> Traditional netiquette (especially on Usenet and mailing lists) is to 
> reply contextually beneath quoted material, trimming down the quotes to 
> the minimum needed to establish context. Also known as inline, 
> interspersed and interleaved posting, this does not always put your 
> entire reply beneath all of the quoted material, because if you are 
> replying to multiple paragraphs, each section of the reply would be 
> beneath the quote of the paragraph to which it is responding. Some 
> people prefer to start their cursor at the top of the message in order 
> to facilitate moving down through the message and trimming the quotes 
> before typing replies contextually.|

(Or they might like wrapping but only one newline (so no full empty lines) between the quote setup and the quote itself...)

Curiously, those all render to the same html (which I'm setting off with an extra blockquote, below)...

I was reading the following snippet on Mozillazine.org about the history of replying about and below quoted emails:

Traditional netiquette (especially on Usenet and mailing lists) is to reply contextually beneath quoted material, trimming down the quotes to the minimum needed to establish context. Also known as inline, interspersed and interleaved posting, this does not always put your entire reply beneath all of the quoted material, because if you are replying to multiple paragraphs, each section of the reply would be beneath the quote of the paragraph to which it is responding. Some people prefer to start their cursor at the top of the message in order to facilitate moving down through the message and trimming the quotes before typing replies contextually.|

When you're trying to minimize application preferences, you really really want one of these options to be the a priori best.^[2] Because otherwise you're selecting one for all of your users and knowing everyone who prefers another option enough to notice is going to, if you're lucky, let you know about it.

^[1] To the point someone might've written an insanely ugly app to do just that for text-unfriendly Outlook.
^[2] And if you're paying attention, yes, once you embed your Markdown editor into an email client, you have to worry about where you put the quoted material too. Argh. Fun times. Remember -- Just Fn Ship, see how much purchase you get, and then head back to add preferences where users actually have a strong enough reaction to your choice that adding a preferences item is The Right Thing to do. Just too bad that I'm wired to spend so much time sweating which selection is correct for the mvp.

Labels: coding, features, indie, markdown, markupdown, style

I'm a little late to the party, but I had a quick reaction when rereading "Apple's Elephant in the Room":

We now know from Craig Federighi and Eddy Cue on John Gruber’s podcast that many of these features were essentially unused by anyone who wasn't a developer.

Look, unhappy early adopters is a big deal. Remember when we started noticing more and more people were bringing Mac laptops to dev conferences? There was a cache, a buzz that started catching on.

Remember who started all this mess anyway? Marco Arment, a developer. Remember where his post got reported? Everywhere. Mac news sites, Mac podcasts (The Talk Show, anyone?), everywhere.

Developers are canaries. Developers told Apple that we like Bluetooth keyboards on our Apple TVs. We like Bluetooth keyboards with our iPads. And guess what Apple built? The "Smart Keyboard".

Don't sleep on developers' favorite features.

Labels: apple, apps, developers, features

Labels: features, Google, search