Monthly Archives: April 2014

Write locally, mirror globally

The Atlantic has an interesting essay on whether Twitter is on a slow decline, less useful and meaningful than it once was:

“Twitter is the platform that led us into the mobile Internet age. It broke our habit of visiting individual news homepages first thing in the morning, and established behaviors built around real-time news consumption and production. It normalized mobile publishing power. It changed our expectations about how we congregate around shared events. Twitter has done for social publishing what AOL did for email. But nobody has AOL accounts anymore.”

It reminds me of something I brought up on Core Intuition a few months back, wondering if Twitter is a core part of the web, something that would be with us forever, or if it is “just another web site”. When we get into the groove of using a new service for a few years, it’s easy to forget that web sites don’t have a very good track record. Giant sites like Facebook and Tumblr seem to have been with us forever, but my personal blog is older than both.

Think about this: if it’s even possible for Twitter to fail — not likely, just possible — then why are we putting so much of our content there first, where there are rules for how tweet text can be used? Storage for all tweets is so massive that there’s no guarantee that other companies will be able to take over the archive if the service has to fold. It’s why I built Tweet Library and Watermark to archive and publish tweets.

Decentralization is the internet’s greatest strength and weakness. There shouldn’t be one service to hold all of blogging; each writer should have his or her own domain and web site. But web sites also die all the time from neglect. We need centralized services to index and syndicate content so that it’s preserved and accessible to more people.

Longevity is the next great challenge for the web. All of my work on Riverfold apps is leading this way, from archiving tweets, to curating and publishing your best photos, to indexing a copy of the text and HTML from your blog. But I’m just one guy with a limited server budget.

It’s time for a new web standard — a metadata format and API that describes how to mirror published content. Maybe it’s part of IndieWebCamp? When I write on my blog, I want the content to flow to GitHub Pages, to the Internet Archive, to Medium. When I post photos, I want the content to flow to Dropbox, to S3, to Flickr. It’s not enough to backup or copy data blindly; the source must point to each mirror, and each mirror service must understand who the creator is and how to find the original data if it still exists.

Unlike a distributed platform that works at the level of raw data, like BitTorrent, this new system should work natively with well-understood common files: text, photos, video, and the glue (usually HTML, Markdown, or JSON) that makes a collection meaningful. Instead of yet another generic sync system, it’s a platform that understands publishing, with adapters to flow content into each mirror’s native storage.

If you accept that this is something worth doing, then every place we put our content must be classified as either an original source or a mirror. And this brings us back to Twitter. Because while I think the next 5 years for Twitter will be strong, I’m not convinced that it will last 50 years. Therefore, Twitter cannot be an original source of data; it must be just one of several mirrors for micro-blogging.

Firesid.es chat with Bill Kunz

Yesterday Bill Kunz was interviewed on Firesides, talking about his app Felix, and life as an indie developer vs. at a startup. Bill was especially open about how he used his own savings to build Felix, and some of the planning problems he ran into:

“One thing I would do differently – and this is probably going to come out wrong – but I would have stuck to my guns on my own plans better. I added quite a few niche features that ultimately ended up not being used, when I could have spent that time on the core of the app, or other projects. I burned a lot, lot, lot of time on things I ultimately didn’t need to.”

Firesides is a very nice use of App.net. You can browse chat transcripts from previous guests without signing in, or sign in with App.net to ask questions when there’s a chat taking place. It’s a little like Reddit’s Ask Me Anything, but more readable and visually appealing, and built on the App.net messaging platform.

iOS 7 and UI debt

Jared Sinclair writes about iOS 7 as a squandered year for third-party developers:

“Fast-forwarding a year, the effect that iOS 7 has had on third party development is disheartening — which sounds like a fatuous thing to say, since there have been so many well-liked redesigns over the past year. But that’s the rub: the vast majority of third-party developers’ time has been spent redesigning and reimplementing apps to dress the part for iOS 7.”

I agree with Jared that it was a sort of lost year for app features, but Brent also has a point:

“Jared argues that iOS 7 wasn’t urgent, that evolution rather than revolution would have been fine, since customer satisfaction was extremely high with iOS 6. In retrospect I agree, but were I at Apple I would have argued that the situation is like tech debt — UI debt — and it’s best to deal with it quickly, completely, and early.”

They had to deal with it all at once because UIKit’s look and feel didn’t really evolve the same way Mac OS X usually does, a little each year. Even Aqua, the most dramatic change ever to the Mac’s UI, was fairly straightforward for developers to adopt; if you stuck with consistent Mac controls, you got a lot for free. There was very little of that kind of consistency on iOS because developers frequently built their own custom UIs which had to be thrown out when iOS 7 happened.

17 services for hosting and business

While doing our taxes this month, I was a little surprised just how much I spend for various web apps and services to help run Riverfold. While I could trim some of them, most are essential and save a lot of time. I thought it would be interesting to write up some of the most important ones.

Linode: I’ve moved nearly everything to Linode. I like their style: just basic, solid hosting, with good features but not an overwhelming number of services or fancy stuff. They’ve recently increased their RAM and added SSD. I have servers there for Nginx/Unicorn, MySQL, Redis, and Elasticsearch. I also use their load balancer and Longview stats app. This link uses my referral code.

Amazon Web Services: I no longer use EC2, but I have some DNS hosted in Amazon’s Route 53. I also use S3 for backups and a new feature that’s coming to Sunlit soon.

Heroku: Before moving to Linode, most of my stuff was on Heroku. Now I only have one small app and database there, and I’ll be completely moved off by the end of the year. I’m including it here for completeness only. It’s a great option to get started if you don’t want to be a part-time system administrator, but I think Marco sums up nicely why you want to use Linux servers instead.

Stripe: Can’t say enough good things about Stripe. Watermark, Searchpath, Tweet Marker, and Core Intuition Jobs all use it for credit card processing. It’s the best.

Gauges: As much as I always loved Mint, as my business grew to several web apps and web sites, I looked for a new stats package that could support any number of sites, and which would work better across hosts, since I don’t need to run the database. I’ve been very happy with this.

AppFigures: I’ve used this for years to track Tweet Library sales. It’s great. I also like that I can enter other people’s popular apps and get an idea of how they’re trending if they make it to the top lists.

Blinksale: Kind of an ancient invoicing app that hasn’t changed at all in years, but it works so I keep using it. Originally started by the folks who would go on to do Gowalla.

Beanstalk: I moved the source for all my Riverfold projects here because it can do Subversion and Git well. I sometimes wonder if I should move to GitHub instead, since I do use GitHub and have a couple tiny public repositories there, but I like that Beanstalk is focused only on private hosting. No social; just a well-designed web app.

Postmark: Run by the same team as Beanstalk. I switched to this after Sendgrid had some PR problems you may remember. Email receipts and whatnot go through Postmark now.

Dreamhost: Still using this for email and a few static or PHP sites. It’s cheap and works well. Not much benefit in moving away from it, though I prefer my more important web apps to be hosted on Linode.

DNSimple: I have a few domains here and hope to have all of them moved over eventually. I want to have a single place for DNS. Right now I have registration and DNS hosting spread across Dreamhost, Amazon, and Network Solutions. Makes it difficult to remember where everything is and to keep track of expirations.

Buffer: This company has been on my radar since someone asked me to support it in Tweet Library. They also have a really interesting blog where they share revenue, salaries, subscribers, web traffic, and other usually private details from a company. I admire that a lot. Daniel and I use it to automate sending Core Intuition Jobs links to Twitter, App.net, and Facebook.

Mapbox: We use Mapbox throughout Sunlit. I wrote more about why here.

FogBugz: In the past I’ve build my own bug tracker, used Jira, Redmine, GitHub issues, and others I’m forgetting. They all have problems so for Riverfold I keep it simple with hosted FogBugz. To complement this I use OmniFocus for non-bug tasks.

Zendesk: For too long I was just using Apple’s Mail.app to handle support email. Now support email goes to Zendesk, where I can better track and reply to it. The downside is I’ve had a couple cases of people not seeing the replies, possibly because the HTML email is more often flagged as spam. Need to investigate whether I can switch it to plaintext, but otherwise I’m happy.

Keen.io: I was inspired to try this after reading Justin’s post on analytics. I’m experimenting with it to get better insight into how people are using my apps. So far so good.

Tapstream: Just started using this to help track Twitter ads and other links, to see what marketing actually converts to App Store sales. The web app is good, they responded to a support question the same day, and I love that the SDK is just a handful of .m files that can be dropped into an iOS project.

And that’s it. I may have left a few things out (like consumer-focused apps Dropbox, App.net, and Twitter), but these certainly cover the major services I use now. In the old days it was common to just have one server that did everything. Now there are so many specialized services. While it seems like a lot to manage, each one does a much better job than I could do with a home-grown solution.

Update 9/16/2016: I still like all of these services, but since originally written I’ve consolidated Beanstalk and FogBugz to GitHub; Postmark to Mailchimp; and stopped using Gauges, Keen, and Tapstream.

Twitter ads

I was talking to friends this week about app advertising, and it inspired me to try Twitter ads. Otherwise known as “promoted tweets”, these ads are actual tweets that show up in search results and timelines, even if the user isn’t following your account. Tweet Library 2.5 seemed like the perfect time to try this.

I set a max of $5 a day and included several related Twitter accounts to help the ads find a more narrow audience of people who might want to buy Tweet Library. Here are the results after 24 hours:

Promoted tweets dashboard

Unfortunately I don’t have an easy way to track this all the way to actual App Store sales. Assuming a 5% conversion on App Store visits, I likely lost a little money. The extra 1800 impressions is nice though, to raise awareness about the app. I’m going to let it run for a week.

Tweet Library 2.5 and consolidation

There’s a new update to Tweet Library out today. Major additions include CSV file export to Dropbox and new URL schemes for starting a search, export, or publish. The URL schemes look like this:

twtlib://username/search?q=hello&collection=Favorites

twtlib://username/export?collection=Testing

twtlib://username/publish?collection=Testing

twtlib://username/storify?collection=Testing

There are a few other important bug fixes too, especially to importing the Tweets.zip archive from Twitter.

When I gave up on Twitter as a user, many people asked if I would abandon Tweet Library. I wasn’t sure at first, but the answer now is a clear “no”. In fact, since my last personal tweet in 2012, I’ve released new features and even redesigned the app for iOS 7.

But I do need to start consolidating my work on Tweet Library and Watermark, because the apps share so many concepts around archiving and search. To that end, this week I’m retiring tweetlibrary.com as a way to browse and publish collections. The site will now redirect to a special landing page on Watermark. Published collections from Tweet Library also go to a public page on Watermark.

It was a tough decision to change the tweetlibrary.com URLs, but maintaining separate web apps that are so similar made everything more complicated, holding back what I could build. Having a single web codebase (Watermark) will ultimately let me improve both Tweet Library and Watermark more quickly.

Photos+ and focus

You may have heard by now that Photos+ has a new home at SilverPine software. My friend Jonathan Hays — now co-founder of SilverPine — is of course also half of Sunlit, so it was a great fit for him to take on another photo app as well. He writes:

“In addition to consulting, we intend to slowly grow a portfolio of software. To that end, we are announcing today that we have purchased Photos+ from Second Gear Software. We have quite a bit of expertise with photo Apps (see Sunlit, among others) and when Justin Williams approached me about purchasing it from him, it felt like a great fit. We have big plans for Photos+ and have already put into motion the first phase of those plans: native Dropbox integration!”

I tested the Dropbox support during the 1.1 beta and think it’s a great direction to take the app. Dropbox the company is going all in on photos: just in the last week shipping Carousel and now acquiring Loom. The more people start using Dropbox to store all their photos, the more useful companion photo apps like Photos+ and Sunlit will be.

And now Justin Williams is free to focus all his time on Glassboard. While I’ve been building web services and subscription apps for a while now, the truth is I’m still figuring out how to do this as a business too. I’ve learned a lot from Justin’s recent blog posts on the subject.

Tint color misuse

It has been nearly a year since the first iOS 7 beta, and something about tint color still bugs me. In fact it bothered me enough at the time of the early betas that a filed a bug on it with Apple, something I very rarely do. The problem isn’t so much in the concept of tint color, which I like; having a consistent color for buttons and links, especially now that buttons are so understated, makes a lot of sense. The problem is the implementation in apps that use tint color anytime they want to highlight something, whether it is tappable or not.

Here’s an example in Apple’s calendar app. It uses a red tint color for buttons, but it also highlights the current day with a round circle using the tint color. It looks tappable, but it’s not.

Calendar

And here’s an even worse example, from the App Store app. “Categories” in this screenshot is a button, but “Paid” directly underneath it — same blue, same font and style — is just highlighted to show that you are viewing paid apps. It’s actually “Top Grossing” that is the button.

App Store

These kind of usability mistakes turn the great potential of tint color into a disadvantage. It’s like underlined text on the web that can’t be clicked. Apps should use tint color to improve usability, not to become even more difficult to use than if everyone rolled their own button styles.

Here’s what Apple’s iOS 7 UI Transition Guide says:

“In iOS 7, tint color is a property of UIView. iOS 7 apps often use a tint to define a key color that indicates interactivity and selection state for UI elements throughout the app.”

But that’s not specific enough. The app screenshots above are following this rule, and it still looks wrong. Bold text or a gray background for highlights are much more effective to show selection state than tint color. I would completely avoid tint color for selection state except for controls that have 3 or more segments, such as a tab bar, and even then sparingly. Highlighting a 1- or 2-segment control with tint color is always going to be confusing, because the selected segment looks like it can be tapped.

With this in mind, fixing the App Store app is a simple change:

App Store

(You could make the “Top Grossing” button blue or not. I don’t think it’s necessary in this case.)

The best iOS 7 apps I’ve seen follow the spirit of Apple’s guidelines, but they know when to push beyond Apple’s built-in apps and when to pull back and do less. Tint color seems like an obvious case of where we should be more consistent and strict than Apple intended.