Mike Isaac, reporting on Twitter's new stance on third-party apps and “consistency” in the ecosystem:
The problem is, there are far more clients than the official ones: Tweetbot, Echofon, Osfoora, all are popular alternatives among many others. And right now, the tweets that use Twitter’s shiny new Card technology don’t show up in their rich new form inside of these third-party clients.
For Twitter, this is awful: The company needs its new, media-rich tweets to appear the same to everyone, not just to those using the official Twitter apps.
This could mean death for those third-party clients.
According to multiple sources, when Twitter decides to finally drop the hammer and introduce the new set of API guidelines, the days of these apps are likely numbered.
What I don't understand from the article is: will Twitter let developers use Cards? Because I'm fairly certain several developers would prefer to have Cards and stay in the Twitter business, rather than being kicked out for a design choice.
Reporting on rumors on speculation is hard, but someone's gotta do it. And when it comes to Apple rumors and speculation, there's so much new material to choose from every day that following new rumors and quick retractions has become a job by itself.
One does not simply “follow” Apple rumors.
I want to give back to the community of Apple reporters, industry analysts, Digitimes editors and content scrapers by releasing a handy Keyboard Maestro macro that makes it extremely easy to build headlines for the next unreleased Apple product with a few keystrokes. In my opinion, this macro is a work of beauty – several beta testers chimed in saying it looked better than the teardrop iPhone 5. So that's something.
The macro in itself is fairly simple. Sharing the same underlying foundation of the Keyboard Maestro Markdown Library, it takes into account four variables: Product Name, Release Date, Post Kind, and Comment. The first beta of the macro didn't include a “Comment” field, but since it was leaked to a rumor blog which posted a screenshot gallery of it, I received many unsolicited suggestions to implement it, so I did.
You can modify the macro to your own needs – you can remove the Comment variable if you fancy simpler, easily Techmeme-able headlines more – but keep in mind that, out of the box, it can be triggered by typing the “rumorz” string in any app. This will open a popup panel to insert your title values; hit Okay, and then BAM! – instant headline generation.
It's faster than an average iOS beta roundup article.
But I tap that heart icon within the app fairly often on content I believe is worth sharing, and I don't know if I'm doing that for essentially no reason. If I knew who were following me, or how many people were following me, I could have a better sense of whether it's even worth it for me to recommend articles, or if I'm just whistling in the wind. I feel like Instapaper empowers me and my friends to become mini curators in our own right, and I like that.
Personally, I wouldn't want to manage (or at least look at) yet another following count on the Internet, but I believe that Instapaper could leverage some of the data at its disposal (people names and relationships, most saved URLs, related items based on people, likes, or other patterns) to make its Friends feature just a little deeper.
I, for one, think it'd be great to have something like a “Picks of the Week” section that highlights articles your friends read the most in the past seven days. Or, perhaps, like Lex says, an Amazon-like “people who read this also read” list of articles I might be interested in.
Marco explained last year how he made Instapaper “anti-social” by leaving the social features to social networks, and trying to make Instapaper a better product. I think some of Lex's suggestions could make for a better Instapaper without preventing it from being a “quiet escape from the social networks”.
I’m fickle. I’m not committed to a single application if it’s not the best. It’s easy to configure a new editor to use the same shortcuts and color schemes. I enjoy learning about new ways to do old things better. Better is better.
I'm at a point in my life where I actually enjoy trying out new things, and I love the sense of discovery that I get out of it every day.
Being committed to an app doesn't mean you can't be curious.
Why did we do this? Firstly, many people over the past year asked us if there was any way to directly support MacStories. We have never asked for donations – fortunately, our ad-based business model has been working fine so far – as I don't feel completely comfortable in taking money without giving something extra in return; but I do understand that some (awesome) readers would like to show their appreciation for the site even without that extra.
Second, I have always wanted to experiment with eBooks. I believe that longform writing is a great fit for portable, digital books, and with PDF, not only do you get to read the document with the app you prefer, you can also enjoy the perks of a DRM-free, portable file format that allows for neat stuff like notes and annotations. Great features for those who'd like to keep this document around for future reference.
We have therefore collected all our Mountain Lion coverage, and reformatted it completely for PDF. We designed a cover and unified the Table of Contents, and in the process we got our friend Shawn Blanc to write a foreword for us. There are three exclusive chapters you won't find on the website, too: Preparing for Mountain Lion, Installing Mountain Lion, and Tips & Tricks. And I have to say – I usually don't like pagination on the web, but my review of Mountain Lion is much more accessible and easier to read in the PDF. Gabe, Chris, Graham, and the rest of the MacStories team did a fantastic job, too. Thanks guys.
But more importantly, since I was diagnosed with cancer last year, I have always wanted to do something for my fellow cancer fighters. To this day, I haven't made a single donation to any charitable organization out there, nor have I sent any money to other research funds or families that struggle with cancer every day.
Late last week, I felt that it was time for me to do something – to find a way to leverage what I do to help others. It was one of those ideas that immediately felt risky, bold, and ultimately just right at the same time. And even better, the team backed me up on it.
If you buy the PDF, we'll give away 30% of proceeds to American Cancer Society. No deadlines: this week, next month, next year – if you buy the eBook, we will always take 30% off the sales, and send it to American Cancer Society. For every purchase, roughly $2.10 will go out to ACS. As long as the eBook is available, this will never change.
I put a lot of thought into this. I wanted to address the requests of the readers who kept asking us for a way to support MacStories, but how? The idea of turning the Mountain Lion coverage into an optional purchase popped in our heads right away, but how should we do it? Have excerpts on the site? Make a lot of articles exclusive to the eBook? Delay the release of articles on MacStories, perhaps?
Instead, we went the simple way. You don't have to buy the eBook, but if you do, you will directly support us. Sure, you can add all our articles to Instapaper or Pocket, but I believe you'll enjoy the portability and convenience of the PDF file we've assembled (again, DRM-free). In the PDF, you'll also find three exclusive chapters, and a foreword by Shawn Blanc.
But more importantly, by purchasing our eBook you'll make a direct, concrete contribution to the American Cancer Society. Because cancer sucks, and I know how desperately research needs funds to move forward, and how people affected by cancer need money and assistance.
You develop an instant global consciousness, a people orientation, an intense dissatisfaction with the state of the world, and a compulsion to do something about it. From out there on the moon, international politics look so petty. You want to grab a politician by the scruff of the neck and drag him a quarter of a million miles out and say, “Look at that, you son of a bitch.”
I am no programmer, but I like to fiddle around with HTML and AppleScript every once in a while. In writing my Mountain Lion coverage in the past weeks, I have relied on a number of tools to speed up my writing and be more efficient.
The most tedious part of writing in Markdown, for me, is inserting links. More specifically, I use inline links, and I like to have both a webpage's URL and title when I am linking to it, so that the converted HTML will have proper location and title attributes. For this reason, I have modified a number of existing Keyboard Maestro macros and bookmarklets to suit the process of inserting inline links to my tastes.
The Keyboard Maestro macro I use is a modification of the “Link New” one found in the Keyboard Maestro Markdown Library. With the addition of two simple AppleScripts, it automatically grabs the URL and title from the frontmost Safari window (and active tab) and it places them in the URL and title field of the macro's dialog box, so I only have to hit okay.
I use this macro all the time when I write in Scrivener, Evernote, or TextEdit, but I also keep the “regular” version around for when I'm writing in the browser, making the process of inserting the URL a manual one (though I use this macro to grab a webpage's title).
If you don't want to use Keyboard Maestro, I have put together a modified Walter Higgins' bookmarklets for inserting links in Markdown to work better with the inline and reference link formats. The first one places URL and title in brackets, with the title wrapped in straight quotes. The second one works the same way, but there are no brackets, so you can easily paste its contents after the [id] of a reference link at the bottom of your document. Personally, I use these bookmarklets all the time when I'm writing on iOS. You can install them by copying their text from the links below.
I was shown how fragile life was on Saturday. I saw the terror on bystanders’ faces. I saw the victims of a senseless crime. I saw lives change. I was reminded that we don’t know when or where our time on Earth will end. When or where we will breathe our last breath. For one man, it was in the middle of a busy food court on a Saturday evening.
Jessica was killed at the midnight screening in Aurora.
Too often we take what we have for granted. Our house. Our car. Our cellphones. Our friends. Our loved ones. The sushi Jessica wanted to eat.
To me, it's not about politics, religion, or a combination of both. If there's one thing battling cancer has taught me, it's that what I have can be taken away in a second. That I should fight for it. Cherish it. Try to make it better.
Every damn minute I'm given on this little planet of ours.
Life is fragile. But it's a fragility worth holding onto.
That’s why we’re adding the ability for Google Play developers to respond to reviews from the Google Play Android Developer Console. Developers can gather additional information, provide guidance, and — perhaps most importantly — let users know when their feature requests have been implemented.
We’ll also notify the user who wrote the review via email that the developer has responded. Users can then contact the developer directly if additional followup is needed or update their review.
In my look at four years of App Store, I left out the part about developer replies to user reviews, as it's a feature request that has come up several times over the years, and I wanted to focus on different issues. But almost every developer I contacted included the possibility of getting in touch with App Store customers in the “wish list” of improvements Apple should consider.
Good move by Google, even if “inspired” by the things Apple isn't doing on the App Store. I hope Apple follows soon.
