Last week I wrote about Micro.blog for iOS version 1.1, which adds several new features including support for multiple photos and longer posts. Today I want to demo how longer posts work on the web version of Micro.blog. Here’s another quick screencast with audio:
Federico Viticci has an overview and examples for the latest Workflow for iOS release, which adds more advanced features for calling into web APIs. It looks great:
For those who are only partially familiar with the terminology, this means that Workflow can communicate with the majority of modern services that come with a web API. If you’ve never worked with web APIs before, it’ll take you a few hours of reading and experiments with dictionaries, token authentications, form requests, and file uploads to get the gist of how it works. But, the Workflow team has managed to make what tends to be a visually unintuitive programming task – assembling dictionaries and structuring JSON – as simple and attractive as possible, abstracting many of the complexities that web developers have to deal with in desktop IDEs and command-line tools.
Here’s another nice example of automatically creating GitHub Gists, from Jordan Merrick:
This is a workflow I’ve always wanted to create, and the new API support makes it possible. Gists are great to share small pieces of text information, such as code snippets or scripts. This action extension workflow accepts files of any type (though they must be text-based) and creates a gist using the GitHub API.
Workflow can now take over many web tasks that previously required either writing scripts or depending on hosted solutions like IFTTT and Zapier. Like my workflow for posting photos to my blog, it’s a natural tool for web publishing and microblogging.
I’d also love to see a Mac version of Workflow one day. I do some limited automation on my Mac, but AppleScript and Automator aren’t as easy to use or as well-maintained as Workflow.
I subscribe to a lot of web applications for my indie business, from hosting to invoicing and reporting services. But I also pay for web content when it’s compelling enough. Here are some web sites with writing and art that I think are worth supporting directly:
New York Times. Still the best reporting on the 2016 presidential campaign. While I usually use RSS for news and blogs, I check the New York Times manually each morning to see what is happening in the world. $10/month.
ESPN Insider. Extra articles to supplement what I read during NBA season. Seemed easy to justify as an expense for my podcast Technical Foul with Ben Thompson. Also comes with the ESPN print magazine. $39/year.
Club MacStories. I’ve enjoyed reading MacStories for years, and the club subscription adds a bunch of great content in a weekly newsletter. You also get occasional book downloads such as for Federico Viticci’s new epic iOS 10 review. $5/month.
Six Colors. Jason Snell wasted no time after leaving Macworld. Seemingly overnight, Six Colors has become an important site for Apple fans. Jason and Dan Moren talk informally about current work, travel, writing, and tools on their secret podcast for subscribers. There’s also a monthly email magazine. $6/month.
Stratechery. Thoughtful analysis of current news and trends from Ben Thompson, delivered Monday through Thursday via email or RSS for subscribers. Great depth to stories about tech company business models and where the industry is going. Helps pay for his NBA League Pass subscription. $10/month.
Craft. An archive of sketches, rough animation, and preproduction artwork from animated films. It’s like an expanded version of behind-the-scenes DVD extras and art books. Initially subscribed for the rough animation for the beautiful film Song of the Sea. $6/month.
Before the web dominated all publishing, it was normal to pay for the newspaper and maybe a few print magazines. Then we entered a period where everything had to be free. Now, paying for content is useful again. The sites above have figured something out about building an audience and creating good content.
The decentralized web works by having a p2p distribution of the files that make up the website, and then the website runs in your browser. By being completely portable, the website has all the pieces it needs: text, programs, and data. It can all be versioned, archived, and examined.
He mentions IPFS in particular, which I’ve written about before. The bottom line is that static HTML sites are more portable. They more naturally evolve not just from host to host as necessary, but also to a possible distributed future web. That’s why that — even though I still use and recommend WordPress — I have a static mirror of my site too.
Facebook continues to roll out their Instant Articles format to more publishers. It’s now available to anyone, with this catch:
“You won’t be able to publish Instant Articles until your RSS feed has been approved.”
That’s just what we need: the worst part of the App Store approval process applied to the web. No thanks.
Google’s competing Accelerated Mobile Pages has problems too, as I mentioned in the last half of this post about the cost of links. Although unlike Facebook, which wants to trap content behind their own platform, AMP is at least more open and useful to the larger web.
I hate to say it but neither Instant Articles nor AMP are really good enough. I think we need a third standard for super-fast web pages. (Or do we? Maybe the web is okay as-is if we fight page bloat.)
Speaking of the health of the open web, Maciej Cegłowski gave a talk on web page bloat at the Web Directions conference, and he put the slides and notes online (via Daring Fireball). It’s fun to read and there are many great points, but I want to focus on Accelerated Mobile Pages:
“The AMP project is ostentatiously open source, and all kinds of publishers have signed on. Out of an abundance of love for the mobile web, Google has volunteered to run the infrastructure, especially the user tracking parts of it.”
Sarcasm aside, I think Google’s involvement is mostly transparent, and I was hopeful about it when I wrote about this in November. Google wants the web to be fast. A faster web includes more ad impressions and is more competitive with native mobile apps. I don’t think this disqualifies Google from proposing this project.
High Scalability has a long article exploring AMP:
“Google needs an open and rich ecosystem of knowledge. If that’s not there then Google search won’t be relevant. Which is Google’s direct self-interest, which is also the same objective of the publisher. Publishers need access to an open ecosystem of distribution. Otherwise they’ll have a harder time building audiences if they have to appeal to closed platforms. Yes, Google is a private company that has business interests, but that philosophy and that core similar objective is something very important when considering Google’s role in AMP.”
I’m willing to give Google the benefit of the doubt on AMP. The alternatives are too focused on specific platforms and so even less available to the rest of the web.
On this week’s Core Intuition, Daniel and I spend the whole show talking about the Apple TV. The first half is about the Apple TV dev kit lottery, and the second half is about whether we need the web on our TVs.
There’s also a good discussion on the Accidental Tech Podcast about this. Here’s an Overcast link about halfway into the episode.
Dave Winer on the continued disappearance of old web sites:
“I’ve tried to sound the alarms. Every day we lose more of the history of the web. Every day is an opportunity to act to make sure we don’t lose more of it. And we should be putting systems into place to be more sure we don’t lose future history.”
Earlier this week, Steven Frank pointed to a new format and protocol called IPFS, which Neocities is embracing. Copies of your content would live in multiple nodes across the web instead of in a single, centralized location. From their blog post:
“Distributing the web would make it less malleable by a small handful of powerful organizations, and that improves both our freedom and our independence. It also reduces the risk of the ‘one giant shutdown’ that takes a massive amount of data with it.”
I took some time to read through what it can do, and I’d like to support it for the publishing platform that’s in my new microblogging project. I don’t know if it’s technically feasible yet, but I love that someone is trying to solve this. We just have to start somewhere.
“The old web where I feel like more people saw the web as what I was talking about: as a unique and amazing invention in human history, a thing that can bring the 6 billion voices out into the open, to tell their stories and say what they’re going to say. That this thing is really something special, and it shouldn’t just be treated as a way for monetizing eyeballs and figuring out great new advances in interstitial ads. […] We can’t lose sight of the opportunity this is. And if the story really is that the web exploded in the mid 90s and became a wonderful thing, and then stopped being that wonderful thing a little more than 20 years later… Then I couldn’t even bear that heartbreak.”
Hope you all enjoy the episode. It was great to have Brent on the show.
Adam Keys has several tips for programmers, to make our web sites look better by keeping things simple. I often just use grayscale, too:
“Most important: design in greyscale. Color is hard and can lead to tinkering. My goal is to get in and out of the front-end bits quickly, so tinkering is the enemy. Greyscale is one dimensional, greatly simplifying matters. Give important information higher contrast and less important information or ‘chrome’ less contrast. Now you’re done thinking about color.”
These days I also start everything with Bootstrap, which adds great defaults for layout, buttons, and text. It makes everything looks better, right away. It’s not a replacement for a designer, but it does save hours (or days) of getting the basics up and running.
When I launched Tweet Marker Plus, I documented that it would store “about a month” of tweets. I didn’t want to promise too much before I fully understood the storage requirements. After a few weeks, I officially bumped it up to “at least 2 months”. I also added a full archive of your own tweets, which are never deleted.
The truth is I’ve yet to write the code that actually deletes any tweets from the database and search index. Eventually I’ll have to, but not yet. So I’ll continue to evolve the service in a way that makes it more useful and sustainable.
Recently I increased the $2/month price to $5/month, with the search index expanded to 3 months of tweets. Today I’m officially bumping the storage again, to 6 months of tweets. I’ve also changed to monthly billing instead of once every 3 months. Everyone who already has the $2/month plan will get to keep it. No price increase for you, and you still get the new 6-month storage and new features, as a thank-you for being an early subscriber.
And I’ve added a major new feature. You can now create custom collections of tweets and publish them to share with others. This is a feature from my iOS app Tweet Library, and in fact any published collection from Tweet Library will also show up in Tweet Marker Plus. New in Tweet Marker, you have the option of keeping a collection private or making it linkable, without it showing up when someone browses the list of collections.
The screenshots linked on the account page include an example of how collections work.
As a bonus for Mac users, there’s also a new menubar search app. This little Mac app hides in the menubar and gives quick access to searching your Tweet Marker Plus timeline and archive. Here’s a screenshot of what version 1.0 looks like.
“This MacStories article”:http://www.macstories.net/stories/iclouds-first-six-months-the-developers-weigh-in/ covers the progress that developers have made adopting iCloud over the last 6 months. Over the next 6 months, we should have an even better appreciation for what iCloud is and isn’t good for.
For iOS backups and iTunes Match, iCloud is fantastic. For private, app-specific data that doesn’t make any sense away from a single developer’s native Mac and iOS apps, it’s also excellent. There’s no question that using Macs, iPhones, and iPads today is a significantly better experience thanks to iCloud.
But there are two fundamental limitations in iCloud that make it inappropriate for a bunch of syncing uses:
- No way to access it from other platforms or web apps.
No way to share data between apps from different developers.
I don’t expect Apple to change this. Again, for what iCloud was made for, these limitations are fine. It simply means that iCloud cannot replace web APIs that do solve these two problems.
“Here’s what I wrote”:http://www.manton.org/2011/06/faq_for_tweet_marker.html not long after announcing the Tweet Marker API:
“The primary goal with Tweet Marker is to enable different Twitter apps to work together. iCloud is designed for storage and syncing only between apps from the same developer, so it’s not appropriate as a replacement architecture for Tweet Marker.”
Think back to the so-called Web 2.0, which gave us web services to access previously closed-off data. This eventually led to truly dominant syncing APIs like Dropbox, Simplenote, and Instapaper. At the same time, we all have more devices than ever before. Syncing exploded on iOS in text editors and note taking apps. Without a proper shared file system between apps, or even an event or scripting system, these iOS apps looked to web APIs as the only way to communicate.
That has turned out wonderfully. With web APIs as the only solution, we see more compatibility between apps and more web services popping up all the time. If you create a new web app, it’s dead without an API. Every success of the modern web, from Flickr to Twitter, has an API that is available from any platform.
So then what about iCloud? If Web 2.0 made data more accessible, iCloud takes that same data and… keeps it closed. It’s a step forward on user convenience and a step back on interoperability.
If you’re a developer considering iCloud support, just make sure your data fits there. Ask yourself if your data is all about your app, or if it’s bigger than your app. Developers who are willing to take a risk on building an open API instead of iCloud could see new opportunities: web-based views of their data, compatibility with other apps, and syncing on the Mac outside of the App Store.
A couple years ago, “Shawn Blanc said about cloud syncing”:http://shawnblanc.net/2010/08/sans-cloud/:
“And my next wish? A cloud-based service like Instapaper, but for to-do items. I want it to be available in apps like Tweetie, Reeder, and more, so when I click on ‘Do Later’ it sends the link or item of note into a running to-do list (that syncs with Things, of course).”
Imagine if Things or OmniFocus or another tasks app opened up a slice of their private syncing API to make the Instapaper of to-do inboxes. Now take other APIs for all of the useful apps we use. Not just to-do apps as Shawn mentions, but RSS, photos, blog drafts, sketches, and more.
What I wrote above about Tweet Marker is still very much true. Since then, Tweet Marker has become the standard for last-read syncing between Twitter apps, with support for 15 apps and many more in development. I want to see more syncing platforms like this. Let’s think big and make apps work together.
Two new bundles were announced this week: “The Indie Mac Gift Pack”:https://indiemacgiftpack.com/ (6 great Mac apps for $60) and the “Fusion Ads Holiday Bundle”:https://fusionads.net/bundle/ (an assortment of web design-related apps, icons, and more for $79). I love apps in both of these bundles and recommend you check them out, buy what you need, or gift them to a friend. There’s a fear among many developers that a bundle can cheapen the healthy Mac software market, but both these bundles avoid that with a higher price and the feel of being put together carefully.
As a comparison, here’s a “Macworld article on holiday bundles from 2009”:http://www.macworld.com/article/145005/2009/12/holiday_bundles.html. That collection seems kind of random despite several good apps in the list.
And sales for the Indie Mac Gift Pack are split evenly to the developers, so we know it’ll be a nice revenue boost for them during the holidays. From the FAQ:
“Hey… you’re ripping these developers off, aren’t you?” … “No… we ARE these developers. Our six small companies decided to band together and do a promotion, to see if it works for us. We’re splitting all the proceeds evenly. There’s no middleman here.”
I’ve never participated in a bundle, but after some of the “MacHeist controversy”:http://homepage.mac.com/simx/technonova/reports/from_the_mouths_of_developers.html I developed a set of rules that I run Riverfold promotions on. These are the easy things that I can always say “yes” to without much thought:
Coupons are great. My coupons rarely expire and I don’t care if sites like “retailmenot.com”:http://www.retailmenot.com/ keep a list of them. Saving a few bucks might be the difference between someone buying my software and not.
Giving out software to bloggers is great. Inspired by “Wil Shipley’s C4 talk”:http://www.viddler.com/explore/rentzsch/videos/4/, I’ve “blogged about this”:http://www.manton.org/2008/04/wii_transfer_serial.html. Apple employees get free licenses too.
Small promotions are great. I freely give out copies to small sites that want to give away licenses of my software to encourage people to post comments. I think readers interpret these (correctly) as software developers doing something generous for a small site, instead of the gut reaction when you see software listed on MacZot or MacUpdate Promo (“are sales so bad they had to sell their software for half price?”).
Charity is great. I loved being a part of “Indie+Relief”:http://www.indierelief.com/, the Pan-Mass Challenge auctions, and other bundles that go directly to a cause. Just like smaller promotions, these are good for users (deals on software), good for developers (helps with marketing), good for charity (donated money), and good for the software market (these aren’t developers who are making a sacrifice because their sales aren’t doing well — it’s charity).
Now that I’ve seen a bundle like the “Indie Mac Gift Pack”:https://indiemacgiftpack.com/, I think I can more clearly judge a unique bundle opportunity when it comes along. Does it minimize the middleman? Does it respect the individual apps as peers? Does it use the total bundle price to underscore the value of software rather than cheapen it? Then it’s probably a good deal for everyone.
Paul Graham thinks “Microsoft and desktop apps are dead”:http://www.paulgraham.com/microsoft.html:
“Gmail also showed how much you could do with web-based software, if you took advantage of what later came to be called ‘Ajax.’ And that was the second cause of Microsoft’s death: everyone can see the desktop is over. It now seems inevitable that applications will live on the web — not just email, but everything, right up to Photoshop. Even Microsoft sees that now.”
He’s definitely off the mark with that statement. Luckily “Martin Pilkington has a counter-rant”:http://pilky.mcubedsw.com/index.php?/site/the_desktop_is_here_to_stay/:
“There seems to be a slightly delusional section of web developers who seem to believe that in a few years time all of our applications and data will be online, while our computers run little more than a browser. Of course this is complete bull.”
As someone who builds both desktop software and web apps, I’m very much interested in what happens in the middle. Next generation Mac software in particular can mix local HTML interfaces, web services, and syncing with a traditional rich UI to build something that is the best of both offline and online worlds.
I had an interesting conversation with “Willie Abrams”:http://willie.tumblr.com/ the other day about why the Flickr UI is better than iPhoto, even if you take away all the social parts of Flickr. The reason is that Flickr introduces extra layouts specific to certain types of activities, such as the excellent calendar view for archives. Another example of a web app UI innovation is the Backpack reminder UI that “John Gruber recently wrote about”:http://daringfireball.net/2007/03/deal_with_it.
Web apps are usually able to iterate on features and interfaces much quicker than desktop software, but that doesn’t make web apps inherently better. Put another way, iCal sucks because it hasn’t been seriously updated in 5 years.
I have other thoughts on this topic, but already I’ve extended this blog post 3 paragraphs more than intended.
When we use Google everyday and mostly work with technology and related topics that are well indexed, it’s easy to forget the truth: the web is horribly incomplete. I’ve been doing some research for an upcoming podcast and it’s very frustrating to encounter huge gaping voids in the internet where history, audio recordings, and photographs should be. Somewhere out there is an audio cassette tape recording that I’d like to hear, but it will probably gather dust in an attic for the next decade instead. It needs to be even easier for anyone to put everything they have online so that it can be preserved and shared. Already I think the current generation raised on instant messaging and the web may not realize that there’s a whole world out there that is outside the reach of our keyboards. At least I know I sometimes forget.
The other part of the problem is linkrot. And not just 404s, but old links to obsolete file formats that can no longer be accessed. I can’t even count how many links to .ram files I’ve clicked that result in an error. When your content requires a special server (RealAudio streaming server software, in this case), it’s only a matter of time before that content itself will die.
Now, the good news is that a simple MP3 file and static HTML file with JPEG images will be around forever. It requires no special server software, no dynamic processing of any kind, and client software is so widespread and open that it’s a guarantee you can access it 10 years later. The only missing piece of the puzzle is reliable non-expiring domain registration and hosting.
The bad news is the rise of centralized web applications and data stores. What happens when YouTube shuts down? Remember they burn through huge amounts of cash for bandwidth each month and seem to have few options for becoming profitable. I feel better about Flickr, because they get it, but “Yahoo! has been known”:http://www.manton.org/2002/07/yahoo_mail.html to not treat data longevity seriously.