Our favorite _DavidSmith has declared app support bankruptcy. With the success of WidgetSmith, I get it. He's got MUCH bigger fish to fry.

But I emailed a decently written bug request on September 24th, well before WidgetSmith blew up, and I just received this reply (to be clear, it's the first reply. Not even an autoresponse before, afaict), a short month and a half later.

No offense, and I think he'd admit it: That's email support bankruptcy.

Why good indie apps often have incredible support... initially

Again, as a developer with a small app store side business, I get it. It's tough to find the time to reply to every request, and the time it takes to reply is never a good trade off on its face. If I answer an email carefully once with a $15 app, I've probably lost money, and if I get into an email chain, it's, on some level, a time and resource sink I'll never climb out of.

But note: It makes sense to go overboard on support when you start, as you're looking for word of mouth at that point. If you can get your first 500 customers, then maybe you have a snowball big enough to lead to a sustainable business. And so lots of indie devs give amazing support (I'm looking at you, Daniel Jalkut) in ways that are simply unsustainable at scale.

The danger of success

I'm not sure when David made it to "sustainable snowball" stage, but I'm confident he's well past it and into avalanche stage with WidgetSmith now.

And I think this is a weakness of indie development. As much as David wasn't "in it to hit big", he's not against it. He's been writing apps for a decade (plus?) and taking a shotgun approach with good individual success. Now he's extremely successful*. What happened to that awesome support? (Disclaimer: I've never gotten awesome support from his apps, but at least with the hired help, I've gotten a reply or two.) 

As a sort of app experience comp, I'll also admit Marco's complete lack of support for Overcast, the podcast player, leaves a bad taste in my mouth. Always has. I've emailed and posted a few bugs to Twitter, and nothing. Not even a "like". 

That's fine, and it's not a dumb decision (see above on time), but it's not a decision I really appreciate as a customer. 

Hire a contractor to go through and reply, "That's interesting. Does anyone else have the same issue?" to every Twitter post. If the contractor finds enough of the same thing, have them tell Marco and get an update from him to post on the issue. What does that cost? $50 once every week or two? Overcast gets 150+ new subscribers a week on a bad week. That's $1000 a week new income. With 50% churn each year, that's still... carry the one... enough to hire someone.

And that's really the issue. Marco already had a single app whose business was bigger than the snowball but smaller than the avalanche on some level. He hasn't had to keep pushing out apps to find success. He's easily making $200k a year on Overcast, which I'd call success. He doesn't have to find another app (though, given his history, I'm sort of surprised he hasn't). 

This is the danger for users of indie apps: Indie apps with enough success find that word of mouth for good support is no longer particularly important. 

Leaving the toy store

I'm reminded of this post from Brent Simmons:

People in the village love toys, but they also like to get to know the village toy-maker.

Brent was talking about having a blog, but I'd extend that to all communication from the dev to the user. When the toymaker discovers their Rubik Cube and goes to the big city, you don't get to really know the village toymaker any more. What's more, you'll find they've stopped making your favorite toys.

So though it makes sense in David's case to declare support bankruptcy and to put his limited resources on the cash cow, it's an off-putting move. I don't want to check out "his apps here". Which of those are being supported now? Why not just point me to WidgetSmith? Isn't that effectively the message behind the message? "For at least the near-term, until the fire burns itself out, we're a WidgetSmith-only shop." Nothing inherently wrong with that. At least it's honest.

Here's the important point for David: Realize, at least for the time being, that you're no longer the village toymaker.

Suggestions

Here are some more suggestions to improve the email. As someone whose even taught business writing a few times, I don't feel it's out of turn to offer them.

• It's been over a month at this point. Again, on some level, why engage at all? You've already sent the "I don't quite have time" message loud and clear.
• But if you do communicate -- 
• Is there a FAQ of common errors/issues? Can you identify if my issue is on that?
• Is there a forum where the community might help? (Could you [hire someone to] stand one up?)
• Maybe try this: Ask me if I've found a solution in the last 45 days.
• (Spoiler: I have.)
• Give users a realistic timeframe before they can expect "real" help.

Labels: business, communication, indie, ios, support

There's something in "massively multiplayer online games" called theorycrafting. It's when you take a game and play it with an eye to figure out the numbers beneath it. You've probably seen Dungeons & Dragons played in a movie or television show, where dice are rolled to see if a player, say, escapes from a monster's grasp.

When you're playing with dice, you can see the numbers. "To escape, you need to roll greater than a fifteen on a twenty-sided die," your referee might tell you. When you play a game online, like World of Warcraft, the "dice" are hidden, the server is the referee, and some software is coming up with all of the percentages and values.

But "theorycrafters" want to see the dice. They'll play in ways where they can take known situations and outcomes, change a single variable, and then see how the known values change. They'll record things in spreadsheets, or even use programs written specifically to watch and record values as they play.

What theorycrafters are trying to do is, in effect, exactly like counting cards in blackjack. If you know what the system is doing... that there are, say, six decks in a shoe, and 13 kings have been played... your odds of winning, and what the odds are for winning what you want, go waaaaay up.

With online games, it's sort of like playing blackjack without knowing which cards were removed from the deck. The servers could be running whatever numbers they want.

Now, if you ask me, theorycrafting isn't fun. When I play, I want Blizzard (Warcraft's developers) to take my dice, please, and let me forget what I'm doing isn't much different from playing blackjack or slots.

Unfortunately, this attitude keeps me from participating fully in the game. In "raids", where 30-40 people cooperatively¹ fight the most powerful creatures in the game, everyone is supposed to be familiar with all sorts of theorcrafted knowledge...

• The best gear (armor, weapons, wraps, etc)
• Enhancements for that gear (armor kits, spells to make weapons stronger, etc)
• Character talents
• "Rotation" (which spells to cast in a fight and in what order)
• (No, believe me, we're just getting started, but that's enough for now... )

If you're not well-versed, and your character is wearing or doing the wrong things, especially in the toughest parts of the game, you're liable to get kicked out of the raid.² And those links I've included, above, were for just one "specialization" of the thirty-six in the game! Phew.

You get the picture. It's insane the amount of studying that needs to go on to simply know the results of theorycrafting, much less to do the theorycrafting yourself. And it kills some of the fun. Ultimately, there are other games I could be playing.

Which brings us to the lesson I'm trying to push here: Theorycrafters might be playing the same game as me, but being a theorycrafter is work, hard work.

Targeted advertisements are like theorycrafting. Discuss.

How does this connect with being an indie app developer? Well, MarkUpDown, my Markdown editor for Windows 10, is getting reasonably mature, and over the last year or so, I've had my ears open to other indie developers that talk about advertising. There's a decent amount of advice about how to market, but I noticed that I bristled when I heard about one kind of marketing in particular. It took me a while to figure out why: It's because there's a particular type of marketing that reminds me of theorycrafting, and I'm not convinced the juice is worth the squeeze.

I'm going to lump the advertising methods I've heard discussed into two categories: Broadcast and microcast.

(Dare you to figure out which one I like more.)

Broadcast advertisements

You're used to broadcast advertisements. Television, radio, and newspapers are the conventional examples. In a figurative since, there's always a lot of "bycatch" in broadcast. You're casting the net out broadly, knowing a good percentage of the people who are exposed to your ad aren't in your market.

You certainly want to cast the nets where you think you'll maximize the market you're after, but you're not being that careful. Fill it up!

Here's one example of a "new media" broadcast from John Saddington's blog, where he's talking about spending $9000 to advertise his Desk app on Daring Fireball:

So I began the paper-napkin math and figured that if I spent $9,000 on DF it would ultimately have to convert approximately 300 copies of my app to at least break-even. So I asked myself this simple question:

Do I really believe that Daring Fireball can create explicit value in converting 300 new customers?

News flash: It did.

The sponsorship went live on November 17th and I held my breath…

The short answer is this: Yes, DaringFireball worked for me.

Over the course of that first week’s campaign and sponsorship I had net (profit) proceeds of nearly $16,000, which means that my investment of the $9,000 was made back within the first week of sponsorship!

For those interested, the previous 7 days of sales were just north of $2,100, so assuming that I was on pace to do that again I was clearly in the black based on Gruber’s sponsorship.

But there were three more significant things that happened as a result of the sponsorship, the first is that I began to rank at the very top of the Mac App Store in not only the Productivity category but globally...

This means, at least in the dominant US-market, Desk App was the #11th most-grossing app in the entire Mac App Store marketplace. 

That's expensive, and risky, but fun.

An aside on advertising dollars

I can hear folks saying to themselves, "Nine grand?!! Are you OUT OF YOUR MIND?!!!"

One thing I feel I should point out: If you've written a detailed app, you've already invested lots more than nine grand in your endeavor. I don't want to think about it too much, but I probably have $30-40k of time in MarkUpDown. That's insane. It's a great Markdown editor -- the best on Windows, I don't mind believing -- and that's probably about what it'd cost to get someone with my experience to write it.

But that's a ton of cash -- or, to be kinder, a huge investment. If you won't drop $10k to get the word out on something that ran you $35k to write, well, your don't value your time enough.

I know, I know. As an indie, getting to write what you want is a huge part of the gig, and by "part", I mean "reward". And I know the feeling of wishing you could give some cash back to your employer to work on what you wanted to, even if it was constrainted to something in their app! I often feel that way about tech debt. Gosh, I'd work for half-price now to make my future work so much easier.

Regardless, the advice here is don't be penny wise with advertising and pound foolish with your time. $5-10k is not a lot to spend on effective advertising.

The question I keep asking myself is, "What advertising is going to be effective?" And with that, we're back to our consideration of...

"Microcast" advertisements

Facebook and Twitter, even Google AdWords to a degree, offer a different sort of advertisement than traditional broadcast. Targeted advertisements allow you to cast your net more precisely, reducing the bycatch significantly.

Now, instead of broadcasting to everyone at a website (can you imagine if Google search had static banner ads?), you get to wait until the user has performed some action that hugely improves the chances they're interested in what you're selling.

• Someone searches for "Windows Markdown editor" on Google.
• Someone on Twitter follows John Gruber and Paul Thurrott.
• Someone on Facebook is a software engineer and hosts projects on GitHub.
  • (You're not writing your READMEs with a Markdown editor? Ouch! There's an easier way! ;^D)

These are increasingly specific demographics. You're no longer broadcasting to a group that you hope largely overlaps with your market. You're lasering in on people you already know are your market, and hoping your net works.

Of course, this service is going to cost you more per impression too.

Theorycraft and Microcasts

The thing that bugs me is how theorycrafty app developers sound when they're working on their targeted microcasts. Like theorycrafting a game, finding the right target for your advertisements is hard work. I understand the appeal that if you get everything dialed in perfectly, you could theoretically take your hands off of that perfect combination, step away, ramp up your advertising budget, and hit Phase 3. Profit.

But it always sounds like there are too many dials.

Here's a quick introduction to how it feels to use Facebook ads from Charles Perry and Joe Ciplinski on the Release Notes podcast, episode Sorta Cool, Sorta Creepy, from back in December 2015 (link is cued up to 8:33 - transcriptions and any errors therein are mine!):

Charles: You know… I wasn’t really familiar with Facebook ads before I started looking into this, and looking for options. And in fact I didn’t even have a Facebook account. But they know an incredible amount about the people who are using Facebook. It is just mind-boggling. They give a lot of that information… I was going to say that they give a lot of the information to their advertisers, but they don’t. But they do allow advertisers to target based on that information.

You can target based off of geography or travel inclinations or whether they have a friend who just gave birth. It’s all kinds of crazy things that you can do -- you really can [target people with friends who just gave birth]. It’s really odd to have that much insight into… the people that you’re advertising to. It’s great, but it’s sorta unique in that you don’t get that much insight into who is viewing your ads in any other platform that I’m aware of, at least.

And from the same episode a few minutes later on...

Joe: So you can target pretty much anything you want, and I know it’s pretty crazy. We did a very brief experiment with Setlists a while back, which I want to repeat, because I don’t think we did it right. We were able to say just give us people who have iPads… Just give me musicians. We could even just say give me singers versus guitar players versus… It’s pretty wild how specific you can get in that detail, and that’s why Facebook’s always asking you all those questions like where you went to high school or where you live… but they also glean quite a bit from your timeline and from what people post about you and what you post in return.

Man, that's a lot of dials. And each one could be the barrier to hitting your target market. Who is more likely to use Bombing Brain's Setlists app? What if it's, strangely, drummers, even though there's a huge emphasis on chords in the app? You might never think to add them to a targeted ad, though a broadcast ad on The Garage Band podcast (made up name) would've hit them all. That is to say, microcasts seem to operate as opt-in operations.

Or here's Curtis Herbert's blog post, That Dirty M[arketing] Word:

One of the (many) things I tried was Facebook app install ads...

Over a one-month period I tried all kinds of permutations, re-visiting my ads every day or two to turn off the clear losers to save money, and try new ones. Looking back at the ad manager for that time period my worst permutation was going to cost me $20 a user, and I had a lot in the $2 - $5 range, but by Jan 2016 I knew how to dial some of the knobs get users for < $1.

That sounds like theorycrafting.

Or on the Under the Radar podcast, episode #49, App Store Search Ads:

Marco: Another thing to think about is what percentage of your new users come through clicking ads? If you're thinking that you make 25 cents per user, but 10% of you users come from clicking ads and the rest come from other ways, then you actually might be able to bid a lot more than what that is to get those users...

... I think [cost per acquisition] will make people think about their business models a little bit more and maybe charge more money and charge higher prices for apps that really, that can earn it, that deserve the higher prices. I think this actually might help raise App Store prices as people figure out, "You know, it'd be really a lot better if I could bid on these keywords and be a little more competitive on the ad side, but in order to do that I have to charge a real price for my app or I have to have some kind of recurring revenue scheme or something like that. Ultimately I think this might actually help ad pricing substantially.

Theorycraft or carpet bomb?

Look at the emphasis on cost per acquisition in the last two microcast quotes. That's the right metric, but I'd suggest "per user" is the wrong unit.

Maybe it's just mentality, but I think it's also largely medium. There are places your potential users live. If you can blanket one of those places that overlaps with your potential users closely enough, it seems worth it to me to broadcast there.

Now I figure part of the lure of microcast is microspending. You can spend $20 (or less) a month on these media if you want. If you target too broadly, your cash will be spent quickly, and you'll hit folks who weren't in your market. But if you start with the pico instead of the micro, you can work your way up, minimizing the cash you've wasted on bycatch.

But I also worry the time it takes to "pico-theorycraft"³ an advertisement... oh, the time. What features did you not add because of the time you spent theorycrafting advertisements? I think Curtis is happy with his results, but every time I have a process that complicated (including writing blog posts), I look up at the clock and say, "Where did today's time go?!"

And if the ads don't scale, even if our theorycrafted dials were working great, what time we've wasted! If I had to tune all those knobs over days or weeks, then cranked my spending from $20 to $2000, and didn't get 100x results, well, man. What a waste.

If you have a broad enough market, and the market congregates in a few specific places that are marketable, I think the lesson is that you go advertise on those media first. The broadest exposure is the best exposure, and has the best follow-on benefits. I also wonder how much of, say, Daring Fireball readers also would be the ones hit by a well-theorycrafted advertisement.

If I had a marketing department with people who really knew how to do this, I would expect them to make these experiments. When it's just me, well, easier is better. Time is money and all that.

But for a niche app like MarkUpDown, even though there was, a few years ago, at least one decent Markdown editor on Windows making enough money it got rewritten, I have to consider just how big my total potential market is. If I could reach everyone who would spend $23 on not just a Markdown editor, but my Markdown editor, how many would that be? If I could find Desk App's Daring Fireball equivalent, could I pull down 550 purchases? Or should I just consider this app a labor of love? If the market is thousands, and I can find the right source, broadcast makes sense. If I want to maximize the return on a labor of love, then I should keep up the hobbyist mentality and microcast.

(And then I think there's probably a middle-ground, where big companies carpet bomb with "targeted ads", but the ads really aren't all that targeted at all, since the markets are so large. "People who watch the NFL," doesn't really require theorycraft-level consideration, and if you're already advertising on TV during games, why not Twitter and Facebook too? Honestly, that's probably the best answer. If Saddington didn't market on Daring Fireball and then to Daring Fireball readers on Facebook and Twitter, he missed a great opportunity. If you buy into the whole saturation thing.)

In any event, there are my current thoughts on advertising, as I try to determine where to sink my hard-earned dollars so that they'll best make friends and bring more dollars home.

¹ No joke! From [wikia.com](http://wowwiki.wikia.com/wiki/Raid):

Raid groups are a way to have parties of more than 5 and up to 30 (40 for some old raids) people, divided into up to 8 groups of up to 5 players.

² Interestingly, as I've argued before, this means the game developers expect and effectively require you to play outside of the game to fully experience it. I'd argue that, additionally, Blizzard's level of financial success demands and depends on theorycrafters as well.

³ I realize I'm misusing "theorycraft" here. There are no hard numbers behind the scenes when you're talking about people. Oh sure, we can play amateur economist, or pretend our experiments in Facebook targeted ads are representative, or apply sampling statistics until we're blue, but we could be wrong too. See the major new networks from our last presidential election. That said, the methods between targeted ads and theorycrafters are similar, and the results could be too. Let's pretend the comparison works.

Labels: advertising, app dev, business, indie, markupdown

Sometimes, it's easy to tell yourself that you shouldn't need to advertise, and that if you wait long enough, discovery will happen, and your work will produce results simply by being obviously better than existing alternatives [in some unique way, at least].

(The worst part is that this dream of "if you build it, they will come" is even true for the lucky, whether that "lucky involves hard work" means knowing people who appreciate your work and can kickstart it (a blogger, a podcaster, etc) or that you have a mailing list from another, or some other means of celebrity or visibility.)

On his Release Notes podcast, Joe Cieplinski tries to twist your conception of advertising backwards. From about 8:40 into episode #195...

And B, in some cases, you're kind of doing them a disservice. People have needs... and if you have a product that actually addresses that need, you're not doing them any harm by letting them know that you exist.

He's talking about cold-emailing someone to tell them about your product or service, in this case, Joe's specifically talking about drumming up contract work. There, cold-contacting someone is essentially a requirement.

But don't let that talk you out of it applying to your situation as an indie developer, if that's what you do. Cold contact reviewers, podcasts where you could sponsor, visible people who could benefit from your app and who essentially serve to represent a market... those visible people that the lucky already know. Get to know them, and bother them. Because, done right, you're probably not bothering them.

It's okay to advertise. It doesn't [inherently] cheapen your work.

Just because you primed the pump doesn't mean the water's bad.

Labels: advertising, business, indie

So here's a tough question: When you're creating your marketing, what do you do about competition?

I'll admit, I'm not in a position where it really matters yet. Other than dabbling in AdWords, I haven't really marketed. I'm probably going to start contacting review sites and folks that have written Markdown editor comparisons soon, but telling people why my widget is better than all the other widgets of the world isn't what's holding me back from internet fame. Though part of me does wonder if that isn't part of your press kit.

But at some point, isn't it a good thing to tell folks why you're better than your competition? We see that on TV all the freakin' time.

(The irony of the above image? Both Gain and Tide are Procter and Gamble products. /sigh Still, it's a clever project someone performed in their dorm -- "If you leave two free containers of detergent, which do folks pick?" This is what happens when you search for "product comparison" images "with reuse", I suppose.)

Finding vs. exposing market fit

One of the things you need to do before you start making an application is to gauge product-market fit. I'll admit my fit measurement was a little spotty. I use Windows quite a bit, and was upset that the Markdown editor that I'd traditionally used hadn't been updated in months to maybe over a year when I started, and its live preview window was broken (as in no display at all) in Windows 10. But that same app had apparently sold enough units that its developer had rewritten the whole schmear at one point, hoping for even better future sales.

If I could get somewhere close to what that app interpreted as "enough cash that I should rewrite what I'm already doing to make real cash", I'd be pretty happy, even if that second level cash they'd hoped for wasn't there. That is, if I could create an asset that's good enough to bring in several thousand dollars a year -- plus is easily reusable for any number of apps and extensions -- that'd worth a few months' of time, right?

I did survey the state of Markdown editors before starting. It's actually, as far as I can tell, a much more crowded field on macOS. I'm not really sure why. I could guess it's because Markdown's inventor, John Gruber, runs an insanely popular Mac new blog, and there's spill-over. Or maybe having an elegant shorthand for HTML appeals to the same aesthetic as macOS. But at the same time, GitHub and StackOverflow's web interfaces both support Markdown entry, and there's nothing especially Mac-specific about either of those, even if you pretend that a disproportion number of programmers still use Macs (do they?). And every time I turned around, people publishing to the web, from readmes to blogs, were praising Markdown, releasing tutorials, and writing "Intro to Markdown" posts.

If you could get anything close to a Mac-sized following for Markdown on Windows (so even a much lower percentage of total users, just with a similar total number of users) and sell to the folks that actually depend on a decent editor to get their work done, I figured you'd be doing fairly well.

The state of Markdown editors on Windows is pretty sad. The one I used, as I mentioned, seems abandoned. The Windows Store is full of Markdown editors, but they're usually freeware and, honestly, bad. I've found a few crossplatform apps that are okay-ish, but don't feel like something I'd use if my publishing life depended on them.

Then I found an editor that has a pretty neat website and boasts a ton of features, from tables to fully customized themes to automatic outlining. And I tried its demo. Ugly, difficult to use, poor UI, and so buggy that I felt it was unusable.

Cheeky comparisons

But how do you get the fact that your competition stinks (in many ways) across to people looking for an app? Simply be good and let people find you? That's classy, but also almost certainly doesn't maximize profit.

Yet isn't it too cheeky to make a flowchart detailing what's broken?

With names, that seems like it'd be in really bad taste. But part of my selling point is that you're wasting your time just trying out these other apps. If it takes 15-30 minutes to read through a marketing site, download, install, and test out an app just to find out it's crud, that's offensive. Our most valuable asset is usually time. I'd like to think MarkUpDown is worth the money already just in the time it'll save you from searching up a competent editor.

Setting a classy example

At the same time, look how friendly Daniel Jalkut was to John Saddington when Desk came out for macOS.

From On the Shoulders of Giants – John Saddington:

I saw this tweet this morning via Daniel Jalkut and my heart skipped a beat:

MarsEdit has a new competitor in @deskpm. Lots of 5-star reviews, looks like they got some important things right! https://t.co/oETpOJE5Jk

— Daniel Jalkut (@danielpunkass) November 12, 2014

For those that are unaware, Daniel is behind the most-famous MarsEdit app (he acquired in back in 2007) and has made it the “king” of desktop publishing apps. It is a robust and more than capable offering and if Desk isn’t the right fit for you then you should definitely check it out!

The thing that was so amazing, though, was that he didn’t come out “guns blazing” and tear me and my small indie app a new one. He could have, if he had wanted to, and totally laid me out but he choose to really tweet a very encouraging set of tweets:

@DeskPM @adamspelbring I sincerely miss the days when there were more competitors, so I am always inspired to see newcomers on the scene.

— Daniel Jalkut (@danielpunkass) November 12, 2014

I can also say that when I met John Saddington at the Release Notes conference, it became clear that post wasn't simply posturing. I asked him about the bugs I was seeing in Desk MD when posting to blogger, as I was looking to a write a similar app myself. That is, I was looking for anything -- why did he decide to ship with those bugs, what sort of reaction did he expect from users (and what was the "right" thing for me to do as a user in that situation), etc.

Saddington not only took the time to explain why he had some bugs, what he felt was fair for customers like me to say ("When you're hitting that much trouble, and I know you are, ask for a refund!"), what his priority list was then in general and for Desk, but also told me, "Hey, if you do write your own, let me know. I'll totally recommend it for Blogger. Supporting Blogger drives me crazy," or something similarly as impressively helpful (I'm pretty sure John's a Wordpress user). If I'd written MarkUpDown for Mac with Blogger extensions and had started by, as he says,

So I'm a little loathe to lambast anyone, if only because of the example these folks have set before me. Argh.

Perhaps I should just reasonably fairly review what's out there. (I say "reasonably" just because I know I'll be a little biased towards MarkUpDown. If there's something I don't like about it, I change it. And I grossly undervalue things that don't matter to me [like most reviewers, I'd assume], like, eg, dark themes.) Then at least I can honestly say what's not working and at least rationally argue for why MarkUpDown is better. /shrug

Anyhow, marketing is fun.

In other news, here's an interesting list of dev podcasts in the running for some sort of award.

There are a number of JavaScript 'casts. Guess I should check out more of them.

Best JavaScript and Web Podcast

• Adventures in Angular
• Angular Air
• JavaScript Jabber
• Modern Web
• NodeUp
• Relative Paths
• A Responsive Web Design Podcast
• Shop Talk
• Start Here FM
• The Web Ahead
• The Web Platform Podcast
• The Back to Front Show
• The Big Web Show
• Boagworld Show
• CTRL+CLICK CAST
• Design vs Dev
• FiveJS
• Front End Happy Hour
• JavaScript Air

Worth looking around at the others too.

Labels: indie, market, marketing, markupdown

That text about Russia VAT changes I talked about yesterday is from an email I viewed in Win10 Mail. I cut and paste the content, and figured it was HTML format. It was, and MarkUpDown handled it... interestingly.

Here's the raw HTML:

<span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;
mso-fareast-font-family:"Times New Roman"; mso-ansi-language:EN-US;
mso-fareast-language:EN-US;mso-bidi-language:AR-SA'>Russia will become a
Microsoft remittance country where Microsoft (or its billing service provider)
will collect and remit the VAT on behalf of developers. <strong><span
style='font-family:"Segoe UI",sans-serif'>Effective January 1, 2017, Microsoft
will determine the VAT due, withhold such VAT from your App Proceeds, and remit
directly to the Russia tax authorities</span></strong>. The current VAT rate in
Russia is 18%. </span>

The problem comes when we put that into Markdown block format.

> <span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;
> mso-fareast-font-family:"Times New Roman"; mso-ansi-language:EN-US;
> mso-fareast-language:EN-US;mso-bidi-language:AR-SA'>Russia will become a
> Microsoft remittance country where Microsoft (or its billing service provider)
> will collect and remit the VAT on behalf of developers. <strong><span
> style='font-family:"Segoe UI",sans-serif'>Effective January 1, 2017, Microsoft
> will determine the VAT due, withhold such VAT from your App Proceeds, and remit
> directly to the Russia tax authorities</span></strong>. The current VAT rate in
> Russia is 18%. </span>

Bonus for anyone who can figure out the issue.

See how that leaves us with an HTML tag that's split over multiple lines?

> <span style='font-size:10.5pt;font-family:"Segoe UI",sans-serif;
> mso-fareast-font-family:"Times New Roman"; mso-ansi-language:EN-US;
> mso-fareast-language:EN-US;mso-bidi-language:AR-SA'>Russia will become a

The Markdown parser handles that quite well, but the > symbols threw off the code I use to align the live preview with the cursor's location as you edit, as it looks like bogus html with all the >'s in the middle. Not great.

So four hours later, I have a fix checked in that seems to be working integrated with MarkUpDown's code (please don't get me started about indie devs' attitudes about (against?) Test Driven Development -- I get that Marco would argue he understands what TDD is, but my guess is he's never actually tried it. That said, I'm not doing it here).

Sure, I also ate and interviewed a programmer in that time, but still... that's a rabbit hole of almost certainly over two hours for a problem only I was likely experiencing.

That's the benefit and danger of being an independent developer. Nobody's going to tell you not to scratch your itch. You're less itchy personally, but that's not always the "best win" for your users.

Labels: app dev, indie, priorities

From a Windows Developer email:

Russia will become a Microsoft remittance country where Microsoft (or its billing service provider) will collect and remit the VAT on behalf of developers. Effective January 1, 2017, Microsoft will determine the VAT due, withhold such VAT from your App Proceeds, and remit directly to the Russia tax authorities. The current VAT rate in Russia is 18%.

You know, when you give an app store (iOS, macOS, Windows) 30% of your take, you actually tend to get a lot.

• Free licensing
• Free update mechanisms
• Free downloads
• A pretty reliable landing page
• Free payment processing
• Limited marketing

That's not bad.

The question's not even, "Is that worth 30% of my revenue?" for many (most?) developers. The question is, "Is 30% too much to give up to release my app before I could have all of this other stuff ready?"

If you could release at Day 0 instead of Day 250, and 70% of the lost sales from 0-250 would make up more than 30% of all sales, then you're an idiot not to release with in an app store as quickly as you can.

What the store buys you is a reduction in time to market. Use that.

What it also buys you is more markets. There's no way I could keep track of VATs and taxes for every country, especially when these countries don't make up much of my user base. Microsoft is big enough that it's worth it to them, as part of the 30% they take from us, to make changes like this VAT charge.

Course it stinks. I'm now getting 70% * 82% = 57.4% of my list price in Russia. Ouch. I could make the price higher to cover the VAT, but for the sales I have there, I probably won't bother.

As Joel says, it's all about barriers to entry. Such a protective tariff should make foreign software more expensive in Russia. I wonder to what extent it does.

Labels: app dev, app store, app store econ, indie, taxes, windows store

At some point I'm going to write up all the crap I've done to host node.js on Linode easily. It's really kind of a pain if you're coming into it fairly cold. I mean, I've been using *NIX since the 90s, but when you really are the only schmoe responsible for everything, it's a new experience.

There are three main things I needed to learn to code and release node:

1. How to set up firewalls -- ufw and iptables.
2. How to execute node in an extended test mode that didn't shut down when I logged out.
   • Both for testing and for production
3. How to fix case sensitivity
   • Okay, I'm a dope. As you may remember, this one got me, though I have better fix now.

I'm going to hit number two right now, just for fun.

Use forever

Here's a good resource, but let's hit the high points:

$ [sudo] npm install forever
$ forever start simple-server.js
$ forever list
    [0] simple-server.js [ 24611, 24596 ]
$ forever stop 0

See how the forever stop 0 matches the [0] from forever list? Then you've got it.

... and one not on the list...

$ forever stopall

Success.

Why is that useful? Two reasons. First, I have a testing service set up that mirrors the "real" site so that I can stage changes both to my website and to the express server. That's at another port, and it's good to be able to start that code from the command line with something better than node app.js (or nodejs app.js as the case may be. If things act funky, try a which node and start sniffing).

But I might want that staging server to be up indefinitely. I probably don't really need it to stay up if the VM blows up, but I want it to stay even when I move from tower to laptop and back. Forever does this nicely.

Secondly, to "really" keep things running, you want to create something for systemd, which apparently replaced upstart in Ubuntu to some controversy a while back, that also ends up calling forever.

Fastest intro to systemd EVAH

$ cd /etc/systemd/system/
$ [sudo?] vim myservice.service

Now put something in the service file like this:

[Service]
ExecStart=/usr/local/bin/forever /home/yourLogin/path/to/your/app.js
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=node-sample
#User=srv-node-sample
#Group=srv-node-sample
Environment=NODE_ENV=production

[Install]
WantedBy=multi-user.target

Now [esc]:wq (for you vi[m] users).

That seems to be alls you need. Notice that the ExecStart part has forever (and the full path to forever in it).

Here's the rest of the magic:

$ sudo systemctl start myservice.service
$ sudo systemctl status myservice.service
● myservice.service
   Loaded: loaded (/etc/systemd/system/myservice.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2016-11-30 12:16:47 EST; 1 weeks 5 days ago
   Main PID: 30575 (node)
      CGroup: /system.slice/exweb.service
              ├─12345 node /usr/local/bin/forever /home/yourLogin/path/to/your/app.js
              └─12346 /usr/bin/nodejs /home/yourLogin/path/to/your/app.js

$ sudo systemctl stop myservice.service

And now you're booting up your node server indefinitely or as a service in case of reboot.

I'll try to remember to follow-up on the other two. The case sensitivity one is the more interesting problem; it's borderline fun. ;^)

Labels: indie, linode, node, noteToSelf

From allenpike.com:

[Consistency works] Except when it doesn’t

As far as consistency will get you, if you work with startups or other rapidly growing businesses, sometimes they’ll struggle with cashflow. To manage these problems, you need to apply fair but undesirable consequences when a client consistently doesn’t pay on time. While individual tastes vary, popular selections include:

• With[h]olding IP rights to the work in question
• Charging interest
• Ramping down or halting development after a warning period
• Telling a client “[Forget] you, pay me” (advanced users only, offer not valid in Hawaii or Canada)

[highlighting and PG censoring performed by me -mfn]

Had a "duh" moment reading this one. I've been lucky that most of my clients pay on time. I'm probably also lucky that I don't act like I'm only around to pluck every living dollar out of what one might act like is their tightly clenched hand. I bet it helps you to get paid in some-to-many situations if you don't act like getting paid is the only reason you're interested in them. Clients are not ATMs; they're [usually, ultimately] people. If you're interested in helping them succeed -- and can competently help them do it -- they'll be happy to bring you along.

But the "duh" moment -- to be clear, a moment when I'm slapping myself in the head -- is to withhold IP. You might do yourself one better and include in your contact that you will also assume rights to any design elements and other IP that you've been made privy to while working. I realize you could get into a mess if the client has licensed stuff that they shouldn't or can't officially allow you to use, and some folks would balk at their current clients or test data, but you get my point.

Clients don't always respond to "time out"

The problem with "ramping down... development" and "charging interest" is that they don't guarantee you'll get anything. Those are really only useful if the companies want to work with you again, or if you're owed so much it's really worth suing. That is, those two remedies usually require the client to participate in their punishment for them to be effective. (If you're currently still working for a client that agreed to and is not now paying, we need to have a talk.)

It's like being a parent -- if your only punishment requires the punished's cooperation, you're often left with a battle of wills. This includes stuff as simple as, "That's your third strike. Go to time-out." If they don't go to time out, what do you do? Pick 'em up and put them there? Stand over them and forcibly keep them in time-out? (Um, I don't recommend that, btw.) These aren't great situations, are they? [... is a rhetorical question most any parent has likely already confronted.]

But tell someone you now own their ideas and legally become their competitor? Now that's punitive and enforceable.

Litmus testing

I really can't see anyone pitching too big of a fit for that being in your contract either, if it's well written and sounds fair and even, not like you're dying to stick it to your client. Anybody who tells you they're not willing for you to own their stuff if they don't pay might not be who you want as a client, right?

If they're worried about slow times or unexpected issues, I'd feel okay negotiating the, "Pay or I can play" clause as far as they want, until they're comfortable. I'd also probably need to add some soothing language that you wouldn't use their brand itself, and would perform what you felt were minimal distinctive changes to address possible user confusion...

But at some point, a reasonable entity would have to recognize that, if they're not paying their own contractor what they contracted, that's unfair.

I should probably also add now that I don't typically fix-price something past the first contract. I don't mind taking a little bath to try and show someone I'm worth keeping around, but later, I try to make it clear that you're paying for hours of work, whatever they produce. This tends to keep clients on track if they're exceptionally cost-conscious, and also from them asking for the moon -- and from moving the moon biweekly because of some incredible insight!!1!121! they had over breakfast.

Two lessons here:

1. Well-written contracts work well as a litmus test for your clients.
2. Clients paying for time tend to be more responsible clients.

Google fails in search for blog

Headline, headline; read all about it!

One quick aside: When I was searching for Allen Pike's post, above, using a very specific string of words from the post, "to manage these problems, you need to apply fair but undesirable", Google gave me nothing, at least nothing tempting on the first page of results. That's crazy-insane.

Bing found it, no problems (though its third hit was, um, strange).

Go figure. As I've said before, Programming is Hard, (c) 1842.

Labels: bing, business, contracting, Google, google fail, hats of money, indie

Whew boy, too many irons in the fire today.

1. Figuring out how to server http ranges from a node server.
2. Using CamStudio to create a demo video for MarkUpDown.
3. Putting my new podcast feed management app on the Windows store.
4. Making a website for the podcast app.
5. Figuring out how to post to Blogger & Wordpress from C#.
   • Mostly just OAuth fun.
6. Figuring out ufw and complete my Linux box install at Linode.
7. Move over my company webpages from the current host I've used for a little too long (webhost4life).
8. Applying for a few more contracts to fill back up the proverbial work pipeline.

That's all for now, I think. /sigh

Ever overcommitted? This time, I've got nobody to blame but myself. The problem, of course, is that I've got all of these well started, which means I probably could've finished the top two or three in the same amount of time as the nothing-finished state they're in now. And that's the real lesson: You have to finish what you start before starting something new if you want to get things done as efficiently as possible.

Why is finishing something now more efficient than working in parallel and finishing it all at the same future time Y? Well, take the CamStudio work: I wanted to finish the MarkUpDown video before I really started advertising. Let's face it -- a Window 10 app, even though it seems fairly cutting edge-ish now, has a limited shelf life. Assuming there's much money to make, I'm losing money by not advertising now. Sales today should compound sales tomorrow. I'm wasting my asset.

Finishing Task A at time X rather than end time Y means you get from X to Y as extra time to benefit from Task A's work. Clear?

So enough blogging. Back to the fire I go. ;^)

Labels: indie, management, time

I've spoken before that whatever it is that you chose to work on, you're going to be married to it in a way you can't possibly fully understand until you're knee-deep in some edge case a week or more past whatever internal deadline you've set for yourself.

For instance, I thought I'd write a quick app to manage creating podcast feeds. And owning your feed really is one of the most important things to do when you start a podcast. Writing a quick utility like that shouldn't take long, right? It's just XML with some madlib spots, essentially a long string.Format call, with one one-to-many relationship. I've done really quick and dirty apps like this before.

From rufwork.com (for heaven's sake, don't download these ancient VB6 apps):

FAQ Maker
A quick VB 6.0 app made to make making FAQs easier.  Add, edit, delete, change order of FAQ questions.  Links, anchors, links back to the question list, etc, all done for you.  CRAZY FAST.  Get source to FAQ html into clipboard with Ctrl-G.  It doesn't get any better. There's no installer.  If you have Win2k, XP, or have ever installed another VB 6 app it should "just work".  Use at your own risk.  FAQ Maker exe download
Stupid Pet Tricks This is an idiotic group of text manipulation functions that I use fairly often in lieu of learning regular expressions as well as I should. Does do some interesting stuff, like insert wildcards from seperate files into repeated chunks of code, format tab separated rows (say from a database) into easy to read columns, etc. Again, at your own risk, yo. This one's just a zipped exe to download.   Stupid Pet Tricks, aka "The Lazy Man's Regular Expressionless RegExp Tool"

Child's play, right?

Sheesh, no. Once you start programming for others (which even the wack apps really aren't), you've got loads of overhead you'd never expected.

Here's an example. For podcasts, you need to add a duration. Instead of asking users to slap in durations in a specific format, I split hour, minute, and second into separate textboxes.

Simple, right? Well, sorta. What's wrong with this code?

this.CurrentEpisode.Duration = this.txtEpDurationHours.Text
    + ":" + this.txtEpDurationMins.Text
    + ":" + this.txtEpDurationSecs.Text;

Well, duh. What happens when any of the textboxes aren't filled in? How about if one is? What if they aren't numbers?

And I thought I was saving myself validation work...

This is a very simple thing to fix (first cut is below), but the point is that small decisions like this add up.

// This is in a static class of extension methods.
public static string ToDurationString(this string str, bool maxOf60)
{
    string ret = "00";
    int intRun;
    if (int.TryParse(str, out intRun))
    {
        ret = maxOf60
            ? Math.Min(intRun, 60).ToString()
            : intRun.ToString();

        if (maxOf60 && ret.Length < 2)
        {
            ret = "0" + ret;
        }
    }

    return ret;     // though note that I now probably have to check 
                    // for all zeroes when serializing to RSS.
}

I mean, how about this one, where I insert a subtitle for your new episodes based on the date, just as a default:

Great if you keep the current time, not so great if you edit that time to something different. Then my attempt at giving you a "shortcut" doesn't work at all. In the above screenshot, we have a publication date of the 30th, but the subtitle still says the 27th.

So what to do? Do you look for dates in that format and automatically update them if the pub date is changed? Yes, you do, but what a pain... I don't want to have settings in an application this simplistic, but that also means you have to make sure all the "features" aren't ever annoyingly in the way.

See? You can't just skip stuff and expect users to figure out what actions bring down the app and what don't, like some unpatched, extremely rushed Playstation game. You have to mind the p's and q's and actually finish your work.

And that means you'll be doing whatever app work you decide to do for a heck of a lot longer than you ever expected. It also means, luckily, that you'll be a lot prouder of what you've made once it's finally out of the door...

This is the life of an indie.

Labels: app, business, indie, overhead, planning, podcasters' feed generator

Note to self: Never create images for documentation until you're done with your release. No, no no. ALL the way done with your release. I thought I could "get started" on my docs a little early, so I did. Not the worst idea ever, but I recently added a new toolbar button or two. I got lucky, I think, and can use my old images, like this one:

... since it's so tiny you can barely see what's in the toolbars. But if it'd shown one extra in the bottom or all of the top, I'd be remaking them now.

See that header button way over on the right? That's new.

And then for some strange reason I put the "Find" button on the bottom. Argh. That was close.

I won't say anything about that tab close "X" in the first image next to the "New 0" file tab. Except that if you'd been reading, you'd know I just added that. That may or may have been retroactively added to the original image. Ms. Paint, indeed.

Labels: fail, images, indie, markupdown, paint

Ah, the power of MSPaint.exe. (Just realized there's a Ms. Paint pun in there somewhere. How many years have I been using this?)

I'm writing a Markdown editor. Its super-original name is MarkUpDown. (I'd originally thought I'd name it MarkUpMarkDown, but emailed John Gruber to see if that was kosher, since that really is too close to Markdown, and he objected to CommonMark's original name, "Standard Markdown". No response, though I could see how "Standard" seems presumptuous in a way I trust a bad pun like MarkUpDown is not.) I used Fiverr to get some icon artwork made, and it was pretty good. Just one problem that didn't occur to me until a few weeks later.

It's not MarkDownUp, it's MarkUpDown. /sigh

I have the psd, so I, in theory, could make my own lossless changes (I spent a little more than Fiverr's $5 to get that, but not much more), but when I tried, the export from the Gimp was super pixelated.

I really like the Gimp, I do. I used it to create the animated gifs on my MarkUpDown home page. But sometimes it takes a lot longer to figure out than it's worth to get something simple done.

^{(I'm suspicious I should pay $1500 for a good Gimp training course and watch that pay back insane dividends over the rest of my career, but I also don't want to get to be known as "the image hack guy" either.)}

Anyhow, I put together a request for my Fiverr guy, and included an image I'd hacked in Ms. Paint (and then Skitch) to show what I needed changed. Took me a little longer than I would've thought, but showed what needed to get done.

And then it hit me: That image on the right didn't look half bad. If I didn't hear back (and I didn't. He at least temporarily closed shop shortly after I left the request), I figured I had another option. If I took a little more care to line the arrows up where they were initially, I'd have something.

Not too shabby for a few hours' work (I actually did this and three other images, two of which were wider than tall and required some more serious editing), right?

Looking at it again, it looks like the down arrow needs to go a little further towards the edge to match the original, but I think I'm okay with it.

I'll blog about figuring out badges and icons and naming conventions for Visual Studio later, perhaps. Right now, I'm going to relax in my reasonable success with crazy mspaint.exe.

(You might wonder if the Fiverr design copied the "Markdown icon" too closely. I don't think that's a problem -- it was designed, and copylefted (actually put into the public domain), by Dustin Curtis.)

Labels: fiverr, gimp, images, indie, markupdown, paint

From Vesper's own release notes:

We three at Q Branch — Dave, John, and Brent — are greatly appreciative of everyone who has used and said good things about Vesper. We love this app. But the time has come to say goodbye. We thank you, sincerely, for your support and enthusiasm.

From Brent Simmon's blog here:

I loved working on Vesper. It was one of the great software-making experiences of my life. We’d get on a roll and it was wonderful.

And now it hurts to turn it off, but it’s time.

... and here...

The code is all Objective-C. It’s an iOS 6 app with just enough changes to keep it working on iOS 7 and beyond. It knows nothing about size classes, presentation controllers, and so on. Doesn’t even use auto layout. It’s not an example of how you’d write an app these days.

Belief inside Q Branch: if we had started with a Mac app rather than an iOS app, Vesper would have been much more successful. That wasn’t clear at the time we started, though (Dec. 2012).

... and from the same post as above, describing what comes next for Simmons...

This is the last app on the App Store where I wrote all (or almost all) of the code. Odds are excellent that there will never be another app written largely by me on any app store.
...
I’m working on new stuff from Ranchero Software. I had planned two apps, but I think it’s going to be just one, just because two takes too much time. So I picked the one I’m more passionate about.

It’s a Mac app...

And then that will be my app. The thing I work on for the next 10 or so years, until I retire. That’s the plan. (To be clear, though, I don’t plan to leave my day job, which I love.)

What happened?

• "time to say goodbye"
• "but it's time [to turn it off]"

These quotes aren't helpful.

• "if we had started with a Mac app... Vesper would have been much more successful."

This might be useful. Sounds like the app wasn't making much money.

If it's a client-side only app, that's no big deal. It costs you very little (your Apple developer account cost) to keep something on the app store.

There are two problems with Vesper, however.

1. They're syncing everything into their own cloud service.
   • This costs money every hour it's open.
   • Syncing images (size) can be a bear.
2. The code isn't particularly easy to maintain.
   • See "It's an iOS 6 app... It knows nothing about size classes [etc]..."

The first means it's costing them money today (EDIT: Gruber adds that they were also paying licensing fees for the font. He's removed that portion from his post, but it was originally there). The second means it's going to cost them a disproportionate amount of time to improve the app tomorrow.

If today and tomorrow are overly expensive, it might be foldin' time.

Post Mortem Results?

Here's my guess at what happened.

• They're stuck with a crappy codebase (we all write some)
• Vesper has high server fees relative to new income
• It's a poorly chosen app category where there's too much competition
  • Don't forget that they were given a good Sherlocking when Apple updated Notes on iOS.
• Related to the previous: Nobody's buying
• Most importantly: The app's not stellar. Great design, decent start, not yet stellar.

It's amazing to think that folks with the name recognition, at least in Apple circles, of Wiskus, Simmons, and Gruber could fail, but they did. To Gruber's credit, he didn't pimp Vesper much at all on The Talk Show or, iirc, Daring Fireball a few months after release. But he didn't do the app any favors with that restraint either. Wear your own shirt.

I heard that Gruber was using Vesper on his Mac in the iOS emulator. I think that tells you something pretty important right there.

I think you can also piece together from Simmons' final statements that he wasn't interested in writing a notes app for the Mac, and I'd guess that this provides the three a good escape narrative. "If we'd only made a Mac app..." I'd counter with, "If that's a good market, why not do it now?" And if the syncing code works well, it's done, man. You're 50% of the way to a notes app already (sync and much of your design is done)!

Again, I don't think Simmons is interested in writing a notes app for the Mac. But I think the real answer is that a great Mac notes app wouldn't have saved them, even if the coding time was zero.

Good, but not great

Vesper was good, but not great. It was, unfortunately, buggy. There were a number of times that I couldn't see and/or add images in one screen orientation. Sometimes cursors would jump around. Sometimes I couldn't enter text. It's a notes app. That's bad.

The idea -- the design -- of Vesper was great. It wasn't a great app. Mediocre apps, regardless of design, tend to fail if they're not maintained and improved. Vesper's had how many updates since 2013?

Revisiting The Marco Effect

I think the most important take home here is that The Marco Effect is greatly overestimated.

That is, if Marco's apps were no good, he probably wouldn't stay in business. Heck, if Marco's stuff was decent, even solid, it might not be worth making.

If Marco had the same reach as The Talk Show and Daring Fireball, picked the wrong app, and that app was only "okay", they wouldn't be worth his time.

Vesper shows me we don't give Marco enough credit. It also tells me app dev is a very tough gig.

A cynic might say that Wiskus-Gruber-Simmons simply didn't want to "stick it out" (certainly they could cover even server-side losses for a while), or that 33% of the cash from decent is much less than 100%, or that Overcast is a labor of love & doesn't make tons of cash either (actually, Overcast does quite well), but I still see Marco being undervalued here. His apps do better because of both (business speak alert!) product-market fit and quality.

Nice of them to let us dump our stuff before it disappears, natch. ;^)

Edit: Tell me what you really think

Ouch. The reviews have turned pretty nasty.

Customer Reviews

Oh well.

     

by .Dan79.

A good example of why subscription services are bad and why extremely expensive apps are bad. And this seems to be both. A $10 app for a service that is now closing and will be completely unusable. And if you haven't logged in for a while, you may have missed the closing notification and you'll be too late to recover important or invaluable data. I discovered this via Apps Gone Free. That's how I heard of it today and checked it out. Sad to see all of this.

About time you pulled the plug

     

by Robert White 74

Nice waste of money this app was. I bought it years ago based on the promises of one of the most opinionated, self promoting guys on the Internet. Turns out John Gruber & pals were a lot of talk & very little action. This app was abandoned almost immediately after it was released. Let this be a warning to others not to bother with promises of snake oil like this in the future.

I agree with those who are unhappy. Thank Gawd I didn't have to pay.

     

by Four2x4

There are several other note apps that are much better and have mush better functionality.
No way to add to an existing note. No way to unarchive a note, and the list goes on of deficiencies.
Sync is discontinued.
Pull the plug, call it a day.

Edit #2: Gruber weighs in, a little

Must've missed it yesterday, or it came in later than I catch up on RSS, but Gruber says he's going to do his own postmortem in a bit:

I’m working on a postmortem — or maybe more of a eulogy — but for now, I can’t express my feelings any better than those two short paragraphs from Brent.

Will be interesting to see how candid he is. I'd like Jared Sinclair, Marco Arment-level candidness, but I'll guess we'll take what we get.

Labels: app dev, app store econ, business, indie, ios, vesper

Tell you what, being an independent shop has its drawbacks. One is that it's hard to be good at design and zeroes and ones. There are certainly people great at both, but it's much fewer than those who are really good at just one or the other. That's nearly a truism.

That means it's taken me days to get my website looking presentable over and above my cheaping out and using a template for the site.

One of the biggest issues for me was trying to get a grid of application features to look good in both desktop and mobile modes. I've got a pretty common set of three features and an image for each. On the desktop, the bootstrap grid arrangement is simple enough:

But when I go to mobile, I want the order to change fairly drastically.

...

Probably makes more sense with numbers...

Changes into...

...

That's kind of an extreme change.

First attempted solution

I wasted a lot of time trying bootstrap push and pull. Look at this answer, for instance.

So basically in a 3 column layout of any web page the "Main Body" appears at the "Center" and in "Mobile" view the "Main Body" appears at the "Top" of the page. This is mostly desired by everyone with 3 column layout.

<div class="container">
    <div class="row">
        <div id="content" class="col-lg-4 col-lg-push-4 col-sm-12">
        <h2>This is Content</h2>
        <p>orem Ipsum ...</p>
        </div>

        <div id="sidebar-left" class="col-lg-4  col-sm-6 col-lg-pull-4">
        <h2>This is Left Sidebar</h2>
        <p>orem Ipsum...</p>
        </div>


        <div id="sidebar-right" class="col-lg-4 col-sm-6">
        <h2>This is Right Sidebar</h2>
        <p>orem Ipsum.... </p>
        </div>
    </div>
</div>

Look at the first col-sm-12 class. That means the next two divs end up on new rows, right? So I can count on pulling my images back a row or two, and pushing my descriptions to fit, right?

Wrong. After fiddling around a while, pushes seem to simply push off to the right of the viewable row. And this question pretty much confirms it.

Second solution

Since that question suggests that we can't push and pull, I figured I'd take one of these more complicated options. They boil down to...

1. Hide at different view "grid tiers"
2. Use JavaScript event handlers to catch resizing

The first makes more sense I think, though you end up having to duplicate code.

I ended up with code like what's below. What's important to note is that the first row is hidden-sm-down, so it's not visible in small or smaller tiers. Then I've got extra lines -- the description text -- repeated in the next row in divs that are hidden-md-up.

It does get the effect I want, even if it's not DRY.

<div class="row hidden-sm-down">
    <div class="feature-desc col-md-4 ">
        Tools to help you learn Markdown. <!--- <<< This'll be repeated -->
    </div>
    <div class="feature-desc col-md-4">
        Keyboard shortcuts once you're a pro. <!-- and this. -->
    </div>
    <div class="feature-desc col-md-4">
        Easy Actions make editing effortless. <!-- and this too. -->
    </div>
</div>

<div class="row">
    <div class="col-md-4">
        <img class="col-image" src="./resources/toolbar350x55.png" alt="toolbar showing a few of MarkUpDown's commands" />
        <div class="hidden-md-up"> <!-- \/\/\/ =====REPEATED!!!===== -->
            <ul><li>Tools to help you learn Markdown.</li></ul>
        </div>
    </div>
    <div class="col-md-4">
        <img class="col-image" src="./resources/keystrokes.gif" alt="Just a few of MarkUpDown's keystroke commands" />
        <div class="hidden-md-up"> <!-- \/\/\/ =====REPEATED!!!===== -->
            <ul><li>Keyboard shortcuts once you're a pro.</li></ul>
        </div>
    </div>
    <div class="col-md-4">
        <img class="col-image" src="./resources/clipboardUrlInsert.gif" alt="Animation of smart clipboard insertion with urls" />
        <div class="hidden-md-up"> <!-- \/\/\/ =====REPEATED!!!===== -->
            <ul><li>Easy Actions make editing effortless.</li></ul>
        </div>
    </div>
</div>

<div style="height:15px" class="row hidden-sm-down">
    &nbsp;
</div>

I don't like it, though I don't even know that it isn't what a bootstrap master would do to get the same effect. I do know that any idealistic setup seems to go completely out of the window once your use case gets complicated enough, whether with conventional code or with CSS.

Chartige

Here's a chart of the different "down" and "up" classes to hide your stuff, though it's from the version 4 alpha...

	Extra small devices Portrait phones (<544px)	Small devices Landscape phones (≥544px - <768px)	Medium devices Tablets (≥768px - <992px)	Large devices Desktops (≥992px - <1200px)	Extra large devices Desktops (≥1200px)
.hidden-xs-down	Hidden	Visible	Visible	Visible	Visible
.hidden-sm-down	Hidden	Hidden	Visible	Visible	Visible
.hidden-md-down	Hidden	Hidden	Hidden	Visible	Visible
.hidden-lg-down	Hidden	Hidden	Hidden	Hidden	Visible
.hidden-xl-down	Hidden	Hidden	Hidden	Hidden	Hidden
.hidden-xs-up	Hidden	Hidden	Hidden	Hidden	Hidden
.hidden-sm-up	Visible	Hidden	Hidden	Hidden	Hidden
.hidden-md-up	Visible	Visible	Hidden	Hidden	Hidden
.hidden-lg-up	Visible	Visible	Visible	Hidden	Hidden
.hidden-xl-up	Visible	Visible	Visible	Visible	Hidden

Labels: coding, css, indie