Category Archives: Web

The Mac Open Web

These days, as the giant social networks behave more and more reprehensibly, many people are looking back to the “good old days” of the web, when self-published blogs were the primary means of sharing one’s thoughts.

Brian Warren has taken this enthusiasm, and combined it with his nostalgia for another classic resource: the links page. He’s created a new one called Mac Open Web:

A collection of open and indie Mac, iOS, and web apps that help promote the open web.

The solitary page is jam-packed with links to resources for creating and perusing content on “the open web,” that is to say “the web.” If you’re sick of Facebook and Twitter owning your experience of what is still a hugely diverse and free global network, then spend some time investing in writing and reading on the web “the way we used to do it.”

Social Networks are a Feature

Apple’s pre-announcement of Clips reminds me of Steve Jobs’s infamous quip to Dropbox CEO Drew Houston. From a 2011 Forbes feature:

Jobs smiled warmly as he told them he was going after their market. “He said we were a feature, not a product,” says Houston.

I’ve heard many dismiss Clips as too little, too late. A blatant attempt by Apple to weasel into the crowded market for quirky photo and video sharing apps. As a 41-year-old, I’m not sure I completely understand this field, but it appears to be dominated by Snapchat, while Facebook seems desperate to catch up and surpass them.

Where does that leave Apple? In punditry circles, the company is almost as well-known for their repeated failure to spark a fire in social networking as they are known for their successes in building highly desirable hardware and software products. Yes, products. Apple loves products, and is good at building them.

Despite constant criticism, Apple controls a pretty huge, relatively smooth-operating social network. The Apple ID single-sign-on infrastructure powers a host of social services including photo sharing, friend finding, document collaboration, shared calendars and reminders, and peripheral services such as Apple Pay that seem poised to make the leap to social when the company sees fit.

But “Apple ID” is not a catchy name for a social network, and despite its popularity among the Mac and iOS faithful, Apple makes little attempt to meaningfully bridge the gap with people who are tied into Facebook, Twitter, Snapchat, Weibo, whatever. These networks are enormously popular not only because users enjoy their features but because they are accessible from all popular hardware platforms. They facilitate interplatform friendship.

For a variety of reasons, the features afforded to Apple ID account-holders do not seem likely to attract non-Apple customers away from other social networks. So if Apple can’t beat ’em? Join ’em. Or rather, make it easy for Apple’s customers to participate at once in Apple-ID-powered services, and with outside social networks.

It started to appear that Apple had ceded “the social network” to other companies when they added standard share functionality to iOS and Mac. Virtually any text, image, or video on these platforms can be efficiently shared to Twitter, Facebook, Flickr, Tumblr, or any of an unlimited number of apps installed on the device that implement support for working with the media in question. If Apple had ambitions of becoming the dominant social network for sharing any of these types of content, they would probably not be so generous in facilitating this integration with their competitors.

I think Apple wisely considers their role, as the maker of personal computers and mobile devices, as empowering users to achieve specific goals in life. Apple empowers its users to write school papers, organize photos, record a jam session, check email, surf the web, work with a spreadsheet, play games, and yes, to connect with friends and family through a variety of social networks.

To this end, any time Apple might have spent building out their own social network is better spent investing in tools that maximize users’ enjoyment of the social networks they already belong to. Rather than obsessing over the venue in which social interactions occur, Apple can profit by equipping its users to be more expressive, wherever they may roam.

If I may stretch the venue metaphor for social networks, imagine you are invited to a huge gala event. Thousands of attendees are anticipated to meet up for an epic night of dining, drinking, and social revelry. Facebook, Snapchat, and Twitter are dying to rent the venue, cater the snacks, and serve the drinks. All things that set the tone for where, and how, people will interact. Apple is content to sell the suit, dress, or whatever, that empowers 30% of attendees to look and feel their best.

Clips falls naturally into Apple’s long history of software that is designed to enhance the creative productivity of its customers. GarageBand empowers users to share their musicality with anybody, on any platform, who can play an audio file. Photos and iMovie do the same for visual creative works. And now Clips, recognizing the unique appeal of combining film, photography, visual effects, text, and emoji overlays, seeks to do the very same thing with a twist on the format.

Few of us wake up every morning “excited to social network.” Yet we turn to services like Twitter, Facebook, and Snapchat to connect with friends and strangers. We’re excited to use the chat, image sharing, file transfer, and collaboration tools that add value to the stark, cold network. Many of these tools are built and shipped by the makers of the network, while others are supplied by third parties.

Apple’s Clips appears to be a canonical example of adding value to social networks from the outside. Regardless of whether you meet your friends on Facebook, Twitter, or a network that I have never heard of, Apple is glad to have you use and app like Clips to make your experience more fulfilling and fun. Clips is the latest of many products, from Apple and from others, that empowers you to express yourself uniquely. The social network you choose to do that on is merely a feature that connects you with friends and family.

Everything But The Web

Since Apple announced the new Apple TV on Wednesday, we developers have been poring over the details of what the SDK will, and what it won’t allow us to achieve on the platform.

One of the most surprising, and most impactful limitations to the SDK is that it provides no facility for presenting web content in an app. Not only is there no built-in “browser” on the Apple TV, third party apps are unlikely to be able to offer any web browsing functionality.

This is a big deal, but many people see it as a wise choice on Apple’s part: by forbidding the use of web technologies, they will encourage app developers to design natively for Apple TV. On iOS, by comparison, a large number of “native apps” that are downloaded from the App Store are in fact only thin wrappers around web content. These offer the same interactive experience that a user would have if they navigated to the company’s site in a browser. Forbidding web views on Apple TV all but guarantees that developers will provide a more tailored experience, designed in the spirit of Apple’s guidelines.

But forbidding web content outright will also be an unnecessary impediment to many developers whose apps are either tastefully implemented with the help of web technologies, or whose core functionality is to deliver content — not web sites, mind you — that happens to be formatted with HTML. Daniel Pasco of Black Pixel points out that his company’s NetNewsWire, an RSS news reader, falls squarely into this category. On that point, although I have a hard time imagining the utility of a blog editor on Apple TV, my own MarsEdit would also be “unfairly” restricted by this policy.

As Pasco acknowledges, we don’t know Apple’s real motivation for omitting web views from Apple TV. There may be technical challenges or performance shortcomings that contributed to the decision. But let’s assume for the sake of reasoning that it is purely political, that they want to discourage “web wrappers” and to promote a more native look and feel in TV apps. I propose that Apple could strike a compromise that would serve those ambitions while also supporting the tasteful handling of web content in apps. How? By forbidding network access to web content. Apps themselves could still access the network, but not from within their web views.

Blocking network access from web content would immediately knock out the “web wrapper” type of native app. Any such app that connects to a site meant to also serve regular web browsers will be rendered useless if the referenced resources from the site are not allowed to load. Images would be blank, stylesheets omitted, etc. A clever developer might try to overcome these limitations by taking all network loading into their own hands, but I expect this would be a complicated mess and quickly encourage such a developer to seek a less cumbersome solution.

On the other hand, all apps that use web content tastefully would be liberated to continue doing so. Whether an app simply uses a small web view here or there to support the native UI with styled text and images, or if it is a full-fledged news reader like NetNewsWire, the ability to capitalize on WebKit’s core functionality to convert web content into a visual format should be no more controversial or politically limited than the ability to process TIFFs, JPEGs, and PNGs and turn them into attractive, or not so attractive, visuals in an app’s interface.

I’m not sure where JavaScript support should stand in this “compromise.” It would be somewhat ironic to omit it, seeing as the Apple TV supports a whole framework for creating apps that is based in JavaScript, but I can also see an argument that supporting JavaScript in web views is too much of a lure away from using native iOS technologies. Personally, I think they should include it and let developers decide whether there are suitable use cases for it, but I imagine the vast majority of current iOS developers would be extremely satisfied to be granted the mere ability to render static HTML content in their Apple TV apps.

I’m excited about the Apple TV even if, like many developers, I haven’t quite wrapped my head around what I could or should develop for the platform. These major announcements from Apple always come with a healthy mix of tantalizing allure for the possible, and sobering reminders that Apple defines the constraints in which we must operate. The lack of web views on Apple TV was not a constraint I imagine most developers were anticipating. I hope that it does achieve the laudable goal of encouraging more developers to embrace native designs, but I also hope that Apple loosens up and finds a way to allow responsible developers to use a powerful set of technologies that we’ve grown accustomed to relying upon.

Apple News And The Open Web

People love to poke fun at Apple for its purported failure to achieve anything of lasting value in the realms of the cloud or social media. Essentially: anything that connects people to a centralized system for storing and sharing information with each other? Apple’s not good at that. Or at least that’s what people say.

Apple has fallen short or outright failed with many projects, including Mobile Me and Ping, which serve as poster children for people who claim they will remain forever helpless with this whole class of technologies. Personally when I hear this criticism, I’m inclined to remind people that for example the massive number of iOS and Mac users who communicate daily over iMessage are technically part of a massive social network that connects them through Apple’s centralized servers and permits the storage of, and sharing of, information between people. If you were to concede that iMessage is a social network, then it’s a pretty impressive one.

But I grant that in key ways, Apple falls short when compared to social giants such as Facebook or Twitter. These companies see value less in the types of private communications that take place via iMessage, and more in the public, or at least loosely bounded communications that take place between individuals and groups of followers. Subscribers, if you will. This massive quantity of communication, and the tendency towards sharing it publicly to potentially millions of viewers, seems well-suited to companies whose viability is rooted in advertising on a massive scale.

I’m a huge fan of Twitter, but one of the things that continues to bug me is that I don’t feel as though I own any of my content there. Sure, I can now request and download a complete archive of my Twitter posts, and a variety of solutions make it easy to automatically accumulate a copy, or even post live replicas of my posts to other services. But the canonical home for my posts to Twitter is … Twitter. When you multiply this fact out over the hundreds of millions of Twitter users, you have a situation that is very good for Twitter, but in my humble opinion, not so great for each and every one of us users.

As the developer of a popular blogging Application for the Mac, it should be obvious that I value blogging. I think there is something special about the ability we have gained as a global community to sit down at a computer, tablet, or phone, and peck out the words that attempt to express our thoughts, sharing them with the world through this gift (coincidence?) of history sometimes referred to as The Open Web. In a nutshell: the Open Web enables free distribution of content in a manner that can’t be completely curtailed by centralized authorities such as governments, militaries, or multi-national companies who happen to run social networks.

Twitter for example is as a company that controls the storage and distribution of each and every one of the messages we post to it. If they decided tomorrow that my use of the service does not meet their standards, my content could be eliminated from the system with the metaphorical flip of a switch. They also maintain tight control over access to the information they do distribute. Years ago, they famously clamped down on 3rd party developers, severely limiting the ways in which existing apps could connect end-users to the company’s services, all but eliminating the possibility that new “full service” Twitter clients would be developed.

What does all of this have to do with Apple and its famous inability to run a viable social network? At WWDC 2015, held last week in San Francisco, Apple announced the Apple News app for iOS 9: essentially an app that will make it easy for 3rd party content providers to serve rich “magazine style” content to all iOS users. Already they have a host of big publishing names on board including Condé Nast, the New York Times, and Bloomberg.

This all sounds great for big publishing, but how does this serve “the rest of us,” and what does it have to do with the “Open Web”? It will all come down to how stringently Apple limits access to small publishers who wish to get their content into the app. Judging from initial overtures, I’m inclined to think that most publishers will be welcome to participate. Currently, if you log in with your iCloud account and click through the sign-up process, it indicates that you can enroll as either a company or individual. I am tentatively optimistic that this blog, your blog, and the vast majority of blogs you read and enjoy will be welcome to publish content through Apple’s News app.

Great, another closed system over which a huge company lords absolute control, and can cut off access to unwanted content at the drop of a hat? No. Because the content doesn’t live on Apple’s servers. This is a key distinction in my mind. Apple’s News App serves primarily not as a source of information, but as an amplifier of it. Podcasting makes a great comparison, and is especially apt considering the extent to which Apple deserves credit for popularizing and faciliating the early growth of podcasting as a platform for free expression.

Approximately 0% of the podcasts available to the massive installed base of Apple’s customers are actually hosted on Apple’s servers. Yet a huge number of podcast content providers thrive because of the distribution mechanism, the amplifier, that Apple provides by way of the Podcasts section of its iTunes store, and the Podcasts app on its iOS devices. If Apple decides on a whim to rank a particular podcast lower in the charts, or even to outright remove it from the iTunes directory? It’s definitely bad news for the show, but it’s not a death knell. The content lives on, access to it remains unfettered for those who seek it, and alternative clients for accessing the content are not “permitted,” because they don’t need to be. They are allowed to exist by default, because of the very nature of the web.

I already said I’m moderately bummed out by my relationship to Twitter because of the sense of lost ownership of my content. That feeling is exacerbated by my knowledge that eschewing Twitter, publishing my shorter, quippy, conversational thoughts to a private server of my own devising, would result in connecting to fewer people. To me, that’s the point of tweeting, the point of blogging, and the point of podcasting: to connect with people.

People who used to write prolifically on long-form blogs are facing a similar conundrum with the rise of services such as Medium, which aim for and seem to deliver on the goal of connecting writers with larger audiences of people. Why keep writing for your own, completely owned and controlled site, if contributing your content to a centralized authority such as Medium will yield more feedback, gratitude, and criticism than publishing on your own site?

I’m optimistic that Apple’s News app will be a strike against centralized services such as Medium, Twitter, and Facebook. A strike against signing over content to a 3rd party mediator for the sake of a greater chance at connecting to an audience. Apple may not be the world’s best technology company when it comes to either storing data or building a social network around it, but they are damned good at building a captive audience of delighted users who trust the company to provide access to a variety of 3rd party content.

Whether it’s music, apps, podcasts, or, coming very soon, syndicated blog content, you’d have to be a fool not to try to get your work into their customer-facing channels. In the case of podcasts, and as it seems with “News,” doing so means providing a feed that points to content you own and which you store on your server. If Apple turns out to be a jerk about it? We can count on other apps and services rising to consume the content in a comparable or improved manner. That’s the way the web works.

Manton’s Twitter Apps

My long-time friend and podcasting partner, Manton Reece, is finally saying a painful goodbye to all of his apps that use Twitter’s API. Reacting to Twitter’s recent announcements about full-history search:

I was thrilled by this upgrade to the Twitter service. That the search was so limited for so long was the primary reason I built Tweet Library and Watermark to begin with. Unfortunately, this functionality is only for the official Twitter apps. It will not be made available to third-party developers.

Manton is probably the most earnest developer I know. He is eager and ambitious in his indie pursuits, but always slightly more interested in serving the greater good than in serving his own interests. To me this is a charming, admirable quality, even if it has lead to some inevitable frustrations and disappointment.

It’s easy to imagine how a developer like Manton Reece would have been so eager to participate in the Twitter developer platform of 2007, and how devastating it must have been for him to watch as his ambitions for the platform became less and less viable over time.

How Many Blogs Do You Have?

One of the things that has kept me from blogging more over the years has been the problem of worrying that, or at least wondering if, the specific thing that is on my mind right now is particularly useful or interesting for my readers.

I find it sort of charming when people write “whole person” blogs that may contain material spanning from their personal emotions, to the culture they appreciate, to the work that they do, and the politics they believe in. But I also find it kind of irritating when I don’t happen to value or share in common one or more of those many disparate interests. Slogging through myriad posts about renaissance faires or meat rendering techniques, just to get the rare morsel about, say, optimizing Objective-C code, is not my idea of enjoying the written word as a reader of blogs.

And so I am very sensitive to try to keep things pertinent to the blog at hand. This has led to my having had for a long time now at least two, and often far more active blogs at a time. I started with just a single LiveJournal blog more than a decade ago, but when I started building Red Sweater it made sense to add a company blog as well. I pushed the limits of what is appropriate for a company blog, frequently using it as soapbox for my own personal beliefs, usually about tech issues, but occasionally straying into discussions about the environment, or endorsing a political candidate. I even eulogized my dad when he passed away four years ago.

I enjoyed a significant audience on the Red Sweater Blog, but I became increasingly uncomfortable with the fact that it was a personal blog more than a professional one. Sure, I announced all my product news, but also wrote about, well, almost anything I felt like. That didn’t seem right.

There was also a ton of stuff I didn’t write about at all. Stuff that wasn’t related to my business and furthermore wasn’t related to technology. For this, I kept an old “personal blog” at Blogspot, which was basically the evolution of my original LiveJournal blog. Here, for example, I wrote a long post on buying a car, sharing the tips I’d picked up in my own process of doing so.

But that personal blog wasn’t really suitable, or I didn’t think so anyway, for technical rants or programming advice. If I wanted to make broad observations about a tech company, or wanted to share advice about code signing, these didn’t really belong on either Red Sweater or my personal site.

So I’ve basically added blogs until I no longer hem and haw about whether or not to post something. There’s still a challenge sometimes in deciding which of my blogs to post to, but never a limitation of there not being a suitable outlet if I want it.

The only problem is that now whenever I post a new blog entry and share it on Twitter, somebody will have inevitably seen the blog for the first time and ask “how many blogs do you, anyway”

Let’s see if I can enumerate them all, as well as my rough idea of the audience they serve and the correlated limitations on content.

  • Red Sweater Blog. My official company blog serves to inform existing users about updates to my software in a casual way that includes more verbose explanation about the changes than a mere bullet list of changes. The blog also, at its best, will share tips and tricks about using not only my software but software that is highly pertinent to Mac and iOS users as a whole.
  • Bitsplitting. This is my technical soapbox. If something feels technical in nature but is not clearly tied to my work at Red Sweater in such a way that it’s meaningful to Red Sweater customers, then it goes here. I find this particularly liberating because it gives me a chance to share opinions about tech companies and people that might be less appropriate coming from an official company blog.
  • Indie Stack. Some of my best posts on the Red Sweater Blog were long excursions into the process of debugging or programming for the Mac and iOS. Granted, some normal people found these posts interesting, but for the most part they fly right over the heads of those who are tuning in to learn about either my products or my philosophies about technology. Indie Stack is the nerd haven where anything goes so long as it’s suitable to other developers or people who happen to be interested in developer technologies.
  • Punk It Up. Often neglected for long periods of time, this is where my non-technical writing belongs. Observations about social situations, jokes, advice about buying cars, etc. If it’s suitable for a general audience, it goes here. Wait, that’s not right, because this is also my blog for crude, relatively unedited quips on whatever subject. In short, these are my liberal arts writings, but they have also sometimes been uncensored. Perhaps that’s an opportunity for further bifurcation.

And unless I’m missing something, that’s how many blogs I have. Oh, but I forgot the podcasts and audio:

  • Core Intuition. My weekly podcast with Manton Reece. We talk about anything related to being a Mac and iOS “indie” developer. Geared towards both developers and people who enjoy a peek inside the minds of two guys actively pursuing our indie ambitions.
  • Bitsplitting Podcast. Spun off from the Bitsplitting blog, the idea with the podcast was to fill a void I perceived in other tech podcasts: a failure to dive deeper into the backstory of individuals being interviewed. The format for this show is a long-form interview that doesn’t hesitate to get philosophical about the life ambition of a guest, and how their stories have fulfilled that ambition thus far.
  • TwitPOP. Born from my idea one day that (nearly) literal renditions of poetic tweets in musical form would be a good way to start doing something musical again, and to explore my fascination with the elegance of Twitter’s 140-character expressions.

You might wonder how a crazy person like myself manages to keep this many blogs going. I’m far from perfect, so of course there is some amount of neglect. I just posted to Punk It Up for the first time in four years, but it was nice to have it there when I finally got around to it.

But the other thing is this is only possible because MarsEdit makes editing a large number of distinct blogs somewhat sane. All of my blog posts and podcast episodes start in a familiar, Mac-based editor interface where all my favorite keyboard shortcuts, scripts, saved images, macros, etc., all live. Whether I’m writing to my company’s users or to the few people who take joy in my musical tweets, the interface for doing so is the same.

To be fair, there is certainly a cost to splitting everything up like this. Whatever notoriety I may gain with one blog is unlikely to transfer directly to the others. So if I wanted as many people as possible to see a specific post, it would have to go to the most visited blog, whether it was suitable content or not.

The compromise I’ve taken to address this problem is to treat Twitter as the over-arching, meta-topicked super-blog that acts as the umbrella to all the others. Regardless of the blog I post to, I’m likely to link to it from my @danielpunkass Twitter account. Sure, folks who follow me on Twitter may get tired of seeing links to various subjects that don’t interest them, but that is far less tedious to dig through than whole articles placed where they clearly don’t belong.

Now you know about all my blogs, and why they exist in such numbers. Just don’t ask how many Twitter accounts I have …

The 2014 Retina Web

When Apple announced the first “Retina” HiDPI device, the iPhone 4, it set into motion a slow (slower than I expected, anyway!) migration away from a web on which it was safe to assume every client had roughly the same screen resolution, towards one in which the resolutions of some clients would be so much higher as to warrant distinct image resources.

From a HiDPI device, it’s obvious to most people when a site has taken care to ensure that all the images are suitably high resolution to look sharp on screen. Sites that are not updated look blurry if not downright pixelated, and really take the shine off these fancy displays.

So it seems obvious to me, and should seem obvious to you, that if it’s at all feasible, every web publisher should ensure that her or his site renders beautifully on a HiDPI device. But how feasible is it, really?

Solutions in 2010

The problem in 2010 was that HiDPI seemed to take the web by such surprise that there was no drop-dead stupid way of updating a web site so that it served higher resolution files to the new devices while continuing to serve smaller images, which were also by definition a better fit, for lower-resolution screens. An undoubtedly non-exhaustive list of solutions advised at the time were:

  • Serve @2x images. Where you used to have a 100×100 pixel JPG, serve a 200×200 JPG but keep the width and height at 100. It works as expected for older devices, but newer devices with reasonable browsers will take advantage of the extra information density to draw the image with greater precision. The main downside to this approach was that even older devices would be forced to download the larger, higher-resolution image files.
  • Use CSS background images. This approach took advantage of the ability for CSS to specify that specific CSS rules should be applied only on devices where the ratio of pixels to screen points was e.g. 2 instead of 1. Because the CSS would be evaluated before any resources are loaded, using this technique would allow a browser to download only the image suitable for display on the current device. The main downside I saw to this was that it encouraged moving away from semantic “img” tags and towards using e.g. div tags that just happen to behave just like images. Things tend to go to hell when printing a page that uses this trick, and I have to imagine it isn’t super friendly to screen-reading technologies.
  • Use JavaScript hacks. I say “hacks” with a careful tongue, meant to express both disdain and admiration. Actually, I don’t know how many bona fide solutions there were in the early days, but I seem to recall people talking of dynamic scripts that would rewrite the “src” attributes of image URLs depending on whether they were being loaded on a HiDPI screen or not. The downsides here are that is feels super fiddly, and there were questions, borne out as justified I think, as to whether the tricks would work universally or not.

I jumped to update most of the Red Sweater pages. Why? Mainly for the reasons I listed in Target The Forward Fringe:

HiDPI customers may be a fringe group, but they are a forward-facing fringe. They represent the users of the future, and the more we cater to them now, the more deeply embedded our products and designs will be in their culture. The future culture.

Great thinking, Daniel. Only, in spite of more-or-less supporting Retina very early on, I never really got good at it. I embraced a combination of “just serve @2x images” and “use CSS background images.” But both solutions have bugged me, and made it less fun to change anything about the graphical make-up of my sites. Thus, I have mostly adopted the “if it ain’t broke” approach for the past 4 years, and that has been fine.

Except no, it hasn’t been fine. Because it is broke. Only after finally getting my first Retina MacBook Pro earlier this year have I finally found myself in front of a HiDPI browser frequently enough to become truly judgmental of the LoDPI web. And wouldn’t you know it, one of the offenders is none other than the Red Sweater site. The main page and product pages all sport fancy HiDPI graphics of the application icons, but incidental badges and, worst of all, screenshots of my apps are fuzzy when viewed on a HiDPI Mac. The very “forward fringe” I’m supposed to be catering to will not be so confident of that fact if they rely solely upon my screenshots. So this morning I took to the long-postponed task of correcting my Retina ways.

Solutions in 2014

Surely in 2014, having had four years to bake, the methods for supporting HiDPI on the web will have gelled into a few no-brainer, 100% effective techniques? I had heard a few things over the years about image sets, picture tags, etc., but nothing really jumped out as being the obvious way to support Retina. That’s annoying. I even took to Google and tried searching for definitive rundowns of the 2014 state of the art. Admittedly, my Google-fu is weak (does adding “site:alistapart.com” to any query count as deep-diving in the web realm?), but I wasn’t turning up anything very promising. I took to Twitter:

My reference to “srcset” alluded to my barely understood impression that a smart-enough browser would interpret the presence of a “srcset” attribute on img tags, and use the content of that attribute to deduce the most suitable image resource for the HTML view being served.

Unfortunately I didn’t get a definitive response along the lines of “you should go read this ‘The 2014 Retina Web’ article.” I’m assuming that’s because it’s really hard to pin down a definitive approach when so many different people have differing priorities: how much effort do you put into supporting older browsers, how important is it to minimize bandwidth costs, are you willing to take on 3rd party JavaScript libraries, yadda, yadda, yadda.

In the absence of such an article, I guess that’s what I’m trying to approximate here. This is for myself and for all my peers who have not paid a ton of attention to the state-of-the-art since 2010, and who would at least set themselves down the path towards making an informed decision. My take thus far about the rough approach to the choices we have today is probably all wrong because I just learned most of it 5 minutes ago, but because I think I would have nonetheless benefited from such a rundown, here it is:

  • Keep doing things the 2010 way. That is, if it actually ain’t broke, or you actually don’t care.
  • Use srcset and associated technologies. These are specified in the W3C’s HTML draft standard as the new “picture” tag and extension to the “img” tag with attributes such as srcset. To answer my own question “can I just use srcset?” I think the answer is more or less “yes,” as long as you don’t mind degrading to a lower-resolution experience for any browser that doesn’t support the new evolving standard. And I’m not 100% sure yet, but I think I don’t mind.
  • Use a polyfill. I just learned that a polyfill is a fancy word for a JavaScript library specifically geared towards providing a compatibility layer such that older browsers behave even when you use newer web technologies. I think the gist of this approach is to more or less use the W3C draft standard features including picture tags and srcset attributes, but to load a JavaScript library such as Picturefill to ensure that the best possible experience is had even by folks with clunky old browsers.
  • Use 2014 JavaScript hacks. You could argue the polyfill approach is also a hack, but distinct from that is a popular approach in which a robust library such as Retina.js is used, not to facilitate the use of any kind of semi-standard W3C-approved approach, but to simply get the job done using runtime JavaScript substitution in a manner that does not require extensive changes to your existing HTML source code. The gist of Retina.js in particular is that in its simplest deployment, it will look for any img tags and replace the src attribute with URL that points to the @2x version of the asset, if appropriate for the screen you’re being loaded on.

Further Reading

My searching and the responses of folks on Twitter turned up some valuable resources that may help to paint a clearer picture of what’s been going on. In no particular order:

</pseudofacts>

I want to emphasize that this post is an exposition of a few inklings of truth that I gleaned from surveying the web and some friendly, responsive folks on Twitter. There’s no need to roast me for being wrong about anything here, because I don’t claim to know anything about the topic. Well, maybe 5 minutes worth of research more than you…

Many thanks to @edwardloveall, @tomdiggle, @samuelfine, @josephschmitt, @adamklevy, @octothorpe, @seiz, @nico_h and others I no doubt missed or who chimed in after I published this piece, for responding to my Twitter query and helping me to start painting a picture of the current state of the art.

15 Lessons From Anil

I’ve been trying to get back into the groove of more regular blogging. Like most habits, blogging is hard to keep up when you let the inertia of inaction take hold. Lately I’ve been trying to remind myself when I have a lively conversation with a friend, or when I start overloading Twitter with multiple tweets on the same subject, that I may as well use it as an opportunity to blog.

This ambition to blog more makes me especially receptive to rallying cries restating the value of blogging, especially when they come with advice for how to blog well. Anil Dash’s 15 Lessons from 15 Years of Blogging is full of observations and advice that ring true to me from my shorter yet still-significant blogging career. There are many gems here but I particularly like his emphasis on the difficulty of gauging the impact of a given post. Sometimes it feels like you’re sharing your thoughts with a black hole, but I’ve also experienced the phenomenon Anil describes:

The most meaningful feedback happens on a very slow timeframe. It’s easy to get distracted in the immediacy of people tweeting replies in realtime, but the reason I write is for those rare times, years later, when I get an email from someone I might only barely know, saying that something I wrote meant something to them.

The only thing Anil says that doesn’t ring completely true to me is his observation about blogging tools:

The tools for blogging have been extraordinarily stagnant. One of the reasons the art form of blogging isn’t particularly respected lately is because the tools essentially stopped evolving a decade ago.

At the very least I think this point needs elaboration: which tools in particular is he alluding to? I think the only reasonable interpretation is that he’s alluding to the hosted blogging services that facilitate “easy” blogging for the vast majority of people. 10 years ago, WordPress was still in its infancy, and my impression was that most people used (original) Blogger, Movable Type, LiveJournal, or Blosxom (a rudimentary text-based system) to share their thoughts.

The web interfaces to these early blog systems were laughably bad, so much that desktop apps like MarsEdit were celebrated essentially for simply providing a reliable text field in which to compose and send text to a blog. There was no Tumblr, whose interface was a revelation for many when it came on the scene and suggested that blogging could be something breezier than the pseudo-journalistic style that had been taken as the standard. Inclusion of photos or videos in blog posts was an insane exercise that only the most intrepid web-worker would dare to tackle. These days? Blog authors can easily share photos and videos from the palms of their hands, while riding a roller-coaster at Disneyland, before the ride stops.

Which is not to say that I think blogging tools are perfect. Far from it. As the developer of MarsEdit, my challenge is to observe the ways in which web-based tools fall short, and strive to fill those gaps with the native Mac-based app. Believe, me there are lots of shortcomings, but it’s also literally awesome how much the tools have improved over the years.

Because I work on a blogging tool, and because I’m friends with a lot of people who I will lovingly refer to as “internet hipsters,” I often get asked by these folks for whom blogging is old news, whether I think blogging is “on the way out.” Far from it, thanks in no small part to those massive improvements in blogging tools. In my experience from selling blogging software and from socializing in and out of tech circles, more people than ever are writing in blogs.

I regularly visit non-technical family in the rural midwest of the United States. Five years ago when I explained to them what I did for a living, the usual response I got was “what’s a blog?” or at best “how is a blog different from a newspaper?” They didn’t get the idea at all that a blog was something they could participate in personally. This year, one of those relatives finally started a blog of her own. And it’s good! Her dipping her toes into this “new” self-publishing platform will undoubtedly serve as a template for the rest of her friends and family. I’m sure we’ll continue to see a lot of new blogs and a lot of improvement to the current tools.