In an effort to bring some personality to my apps, website and blog and make them easily recognizable by “connecting” them visually I rolled out a minor re-”design” of my website and blog yesterday.

The Color Scheme

The entire color scheme is based off the Eternal Storms Software logo.
Up until now, neither the website nor this blog reflected those colors. As a matter of fact, the only place that had some of this personality was the iOS part of Transloader. In its “About” screen, you’d see this:

IMG 9025Screenshot of Transloader on iOS

It’s immediately recognizable – and not only by the logo.

The Website and Blog

It was about time I brought that over to the website, because it looked like this (please excuse the missing text and bezels, I took this from the Wayback Machine as I stupidly don’t keep old websites around):

Old eternalstorms.at websiteeternalstorms.at before the re-“design”

At the time, I had a good reason for it. I wanted the user to be able to see all my apps at once, without any distraction. But it lacks a certain “je-ne-sais-quoi”. It has no identity. You don’t know who it’s from. Heck, there’s not even a logo anywhere to be seen.

Lo and behold, the new website looks like this:

Untitledeternalstorms.at after the re-“design”

It’s probably not the best website you’ve ever seen, but it’s certainly an improvement over the old one.

The Apps

Now I can’t go in and make all my apps purple. That would look ludicrous (or would it?). But I still want to carry over some of this into my apps, and I believe the best place to do this is in the apps’ About windows. Currently, they look like this:

Briefly's old About WindowBriefly’s About window before the re-design

It has all the necessary information in there, but it could be more personal, more fun, if you will. Here’s what the new one will look like:

Briefly's new about windowBriefly’s About window after the re-design

It will roll out in all apps with future updates. The nice thing is that it’s very much a drop-in replacement for the standard about panel Apple’s providing in Cocoa. It takes all its information from the app’s Info.plist file and additional information (like twitter, Facebook, Acknowledgements, Credits) can be provided in a strings file which will then be used in the about panel. So I just drop it in, change some strings in the strings file and I’m done, I don’t need to touch the xib in Interface Builder. Perhaps I’ll do a blog post about it some other time.

App Store Screenshots

All this kind of raises the question – should I brand my App Store screenshots as well? I’m leaning toward “no”. Definitely no logo or slogan, though. That would just distract from the product. Perhaps I could color explanation text accordingly, or put them in colored overlays. Or create an Eternal Storms Software Desktop Background Image that will be present in all App Store screenshots, that would definitely be a more subtle way of doing it. I might try it out on an app and see how it does.

But in general, I am against branding of App Store Screenshots. They should present the app. A description of the company could always be put into the last paragraph of the App Store App description. That’s a nice place for it.

Read more

ESSSquareProgressIndicator animating

What Is ESSSquareProgressIndicator?

It’s an indeterminate progress indicator originally developed for the iOS game ZEN.

It uses Core Animation (specifically, CAShapeLayers) to do its job and it’s pretty straight forward.

CGPathRefs, CAShapeLayer

CAShapeLayer has two animatable properties – -strokeStart and -strokeEnd (with a minimum value of 0.0 – start of path – and 1.0 – end of path). Going beyond 1.0 or below 0.0 doesn’t work.

So when trying to animate those values along a rectangular path – which was the first thing I tried when creating this – you do get a nice animation, but it ends at the 0.0/1.0 (which is, basically, the same) mark. So you end up with something like this:

glitchy progress indicator animation

The goal, then, was to animate beyond 1.0. The solution I came to – I’m sure there are other ways – was to use a second CAShapeLayer that animated alongside the first for the last/first part of the animation.

For a square, the values of the CAShapeLayer’s -strokeStart and -strokeEnd are as follows (starting at the top left corner):

CAShapeLayer strokeStart strokeEnd values

The CGPath begins and ends in the top left corner because I drew the path that way (you could make it start in the lower left corner or in the middle of a side, it all depends on where you start the CGPath with CGPathMoveToPoint).

The progress indicator starts at the middle of the left line and reaches to the middle of the top line. These are the two CAShapeLayers at work. The left part is one shape layer, the top line is another. I’ll do this in pictures I drew in code so it’s simpler to understand (the lines represent where the layer animated to, the dots are the invisible rest of the square).

Animating

Animation Part 1We start at this position. The line to the left is layer2(strokeStart:0.875, strokeEnd:1.0), the line at the top is layer1(strokeStart:0.0, strokeEnd:0.125).

Animation Part 2The transition to this is the reason we need two layers as we can not animate one layer beyond the 1.0 value.
So we animate layer2 to (1.0, 1.0) and at the same time animate layer1 to (0.0, 0.25) which makes it look like one line moving.

Animation Part 3This next part is easy. We animate layer1 to (0.75, 1.0).

Animation Part 4Lastly, we animate with two layers again to get to the initial position so we can repeat the whole thing from there on.
We animate layer2 from (0.75, 1.0) to (0.875, 1.0) and layer1 from (0.0, 0.0) to (0.0, 0.125) at the same time, again making it look like one line moving.

The Source Code

The repository (a sample iOS app, but the class works the same on OS X) is available on Github.

It was developed for iOS 7.1 but should work on earlier systems, and has been tested on OS X Yosemite, but should work on earlier systems as well.

You just drop in an ordinary UIView or NSView and set its class to ESSSquareProgressIndicator. Done. You can then set the color and stroke width right within Interface Builder thanks to the fairly new Xcode macros IB_Designable and IBInspectable.

Open Source

I have some more source code available here (or directly on my github profile page) if you’re interested. If you have any questions or feedback regarding this progress indicator, please be sure to mail or tweet me 😉

Enjoy!

—-
My name is Matt, I’m the developer of Eternal Storms Software. If you’d like to comment, you can catch me on twitter here: [twitter-follow screen_name=’eternalstorms’ show_count=’yes’] or by eMail.

Read more

A little over a week ago, I started a Teespring campaign. 

Eternal Storms Software Cloud Logo on T-Shirt

What is Teespring

Teespring lets you “create & sell custom apparel” (more info).
You upload your design, set a goal for the campaign and once that goal is reached the T-Shirts will be printed and shipped. If you sell enough shirts, you can gather a little profit with it.

Because I’m interested only in the shirts, not the profit the campaign makes, I thought I’d do something useful with the money and decided to donate it directly to charity:water.

What is charity:water

charity:water makes it their “mission to bring clean and safe drinking water to every person in the world.”
I first heard about that charity from Steve Scott (@macdevnet on twitter). He launched the “Developers against Poverty” campaign in 2011 on charity:water and raised over $60,000 with it, bringing clean water to a community in Ethiopia and 12 others.

I thought that was a very nice thing, so that’s why I decided to donate the resulting money from the teespring campaign to that charity.

The Apparel

There are four kinds of items you can purchase:

Unisex Shirt

Unisex Shirt; back has small cloud logo with text www.eternalstorms.at ($16.99)
Female ShirtFemale Shirt; back has small cloud logo with text www.eternalstorms.at ($16.99)
Long Sleeve ShirtLong Sleeve Shirt; back has small cloud logo with text www.eternalstorms.at ($17.99)
Hoodie
Hoodie; back has small cloud logo with text www.eternalstorms.at ($25.99)

Contributing

If you like the shirts, please consider taking a look at the teespring campaign. All profit created from that campaign will be donated to charity:water.

If the shirts don’t tickle your fancy, perhaps you’d like to donate directly to charity:water – here’s a link to their donate page 😉

Thank you for your time – I hope you enjoy the shirts. They should start shipping early to mid April 2015, depending on where you live!

—-
My name is Matt, I’m the developer of Eternal Storms Software. If you’d like to comment, you can catch me on twitter here: [twitter-follow screen_name=’eternalstorms’ show_count=’yes’] or by eMail.

Read more

That’s a question I’ve been asking myself ever since I started releasing software to the public.

Googling “When to send a press release”, I get articles talking about on what specific weekday to send it or at what time of day.
Or “send a press release when you have something newsworthy”.

Although that is good advice – never send anything not newsworthy, you’ll just alienate people – that’s not the subject of this blog post.

What I mean by ‘When’ is: should I send a press release a couple of days before I release an app or on the same day?
And yes, it is an “either – or” kind of situation. I’ve been told by journalists I asked if it’s cool to follow up a week after (or send the press release again) – definitely don’t do that.

Non-Embargoed Press Releases

To issue press releases the same day I release the app itself always felt natural to me. I’ve been doing it for as long as I’ve released software.
No advance notice, no follow up – just “send it and forget it”. I want to get the news out when it’s fresh and hot and when it’s available for everyone to download.

Control Is An Illusion

Front and foremost, it gives me this feeling of ‘control’. When sending out a press release the day of, I feel like I’m on the mind of the journalist and like they’re more inclined to write about my app since it is “fresh off the press” and just happened. And there might be some truth to that as I’ve seen good results with that approach. But you never have any control to speak of. That’s an illusion.

Secondly, there’s the App Store Review process. It takes time. So once the review is done and the app has been approved, I’m usually very eager to get the app out the door as soon as possible and not have to wait around a couple of days more to be able to send out press releases ahead of time.
I also don’t want to send out a press release while the app is still in review – that’s got ‘catastrophe’ written all over it.
If you send out a press release with an embargo only to have your app rejected some time later, you’ll have to issue a redaction and that’s just hideously tedious. It’s a one-way-ticket onto the journalist’s blacklist.
Even though there are apps for checking the average review times for the iOS and Mac App Stores, it’s just too uncertain in my opinion.

Forget me not

It’s not fun to spend hours writing a decent press release, send it out early to members of the media just to find out they forgot about it come the actual date of the app release. This is probably not much of an issue with bigger news sites and blogs that have systems in place for embargoed press releases, but smaller blogs run by independent reviewers might do all this by hand, so things might slip their minds.

Sending press releases with an embargo also has the risk of of the news leaking.
You send out your news with an embargo of one week, but that doesn’t mean that every member of the media is going to respect that – they might publish early to break the news first (a problem I assume only bigger companies face who’s news appeals to a broader audience than mine, a small indie developer’s press release; but nonetheless, it’s still something to be wary of).
I hear that embargoes aren’t legally binding, so be wary of that as well. 

Embargoed Press Releases

With everything you’ve read by now, you might think sending a press release beforehand might not be a good idea. And you’re right, a lot of it speaks against it (although it depends heavily on each individual case).

But there is one thing about it that appeals to me more and more the longer I ponder it – with a press release you send early, you give your potential reviewers time.

Time for Preparation

Imagine being a journalist, getting a couple dozen press releases each day (or more) and some of them are to be released on the same day. There’s simply no way you could check out all those apps and publish on the same day. Pressed for time, a journalist might be inclined to just post the entire or edited press release, publish late or not post about it at all. But a full review is out of the question, that’s for sure.

If you issue that press release a week early, though, you’re helping out not only the journalists you’re addressing, but also yourself.
You give the greatest gift there is: time.

Time to check out your app in detail, less in a hurry to get to the next press release, because they do pile up, I’m sure.
Time to use the app for a few days, should they decide to cover it and get a deeper look at how the app works and feels.
Time to experience details about the app that make it stand out over its competitors.
Time to get more details about the app, e.g. check out the app’s Press Kit; ask you for more details if something isn’t clear or if they have any questions in general.

I believe that is invaluable for all parties involved.

Testing Embargoed Press Releases

To put this to a test, for the release of Transloader 2.1, I sent out the press release one week ahead of the release and the result has been way better than I thought. As I wrote before, I sent out PR with the bad aftertaste of thinking it would be forgotten on the actual day of the release.

But that was not the case. Quite the contrary, actually.

After sending out an embargoed PR, I pretty soon received requests for promo codes to an extent I have not experienced before. That might be attributed to the extended time frame they had for reviews, given the embargo. I imagine journalists don’t bother asking for promo codes if they don’t have the time to really look at the app anyway.

The embargo itself worked very well, not one site posted early. I used the following wording (in bold print) right before the press release body

Embargo: Please do not publish before March 10th, 2015

I think I will take out the “Embargo:” part, though, it sounds kind of demanding.

Among others, MacNN, c|net and the german site MacGadget posted favorable reviews of Transloader and @MacTrast called it their iOS App of the Day.

All in all, it went very well and I’m very satisfied with how it turned out.

Conclusion

I will be moving to embargoed press releases from now on. The benefits of giving journalists some time to check out your app by far outweighs the disadvantages listed above and I think it engaged journalists more.

And that’s what press releases are all about.

—-

My name is Matt, I’m the developer of Eternal Storms Software. If you’d like to comment, you can catch me on twitter here: [twitter-follow screen_name=’eternalstorms’ show_count=’yes’] or by eMail.

Read more