Tag Archives: urls

Fixing AMP

When I first wrote about Accelerated Mobile Pages, there wasn’t a true implementation. Now we see how Google is rolling this out, and it has problems. John Gruber uses Ars Technica as an example:

On desktop browsers, these URLs do get redirected to Ars’s website. But on mobile they don’t. Share from one mobile device to another and nobody ever leaves google.com. Why would any website turn their entire mobile audience — a majority share of their total audience, for many sites today — over to Google?

Maybe this is inherent in how AMP works, and we should have predicted it. If Google’s AMP implementation must run in browsers, will there always be a layer of JavaScript and custom URLs that hide the original web site?

I’d prefer if Google added AMP support directly to Chrome. While it would be a much more limited rollout, it would feel more natural, with fewer drawbacks for publishers.

Competing news platform Apple News isn’t problem-free either. The apple.news:// shared links also add a redirect, with inconsistent behavior since not all platforms and countries even support Apple News. Apple News is an RSS reader that’s designed like a closed platform.

I want the web to be faster. Breaking links should not be part of the solution.

Microblog links

Brent Simmons points to my post on microblogs and asks:

“Is the web we lost gone forever? Was it a brief golden age before the rise of Facebook and Twitter and The Algorithms of Engagement?”

But he quickly follows with an alternate view: that it’s a blip and we’ll get back on track. And that’s what I believe.

Instead of accepting a common opinion that Twitter is slowly replacing RSS readers, we should flip that around. What kind of changes could be made to RSS readers to embrace microblogging and make Twitter itself less important? Because once we do that, we get back control of our own short-form content and at the same time encourage open tools that will survive independent of whatever happens with Twitter and Facebook in the future.

I received some other great feedback about defining what it means to be a microblog post. One question that I didn’t address is links. Noah Read writes:

“It has consistently annoyed me that Twitter and App.net’s links count against my character count. It seems to run counter to what I love about microblogging, carefully chosen words communicating a succinct idea. I often have a pretty good tweet composed and then I paste in the link to a site or image and have to rework the whole thing.”

And David Ely says that a microblog post…

“Contains a single thought, a link with short commentary, or a photo with a caption.”

Whereas a full blog post would often contain multiple links. Certainly a lot of what is posted to Twitter and Facebook is just a single link with short commentary.

I also noticed recently that Dave Winer’s Radio3 includes links in the text when tweeting, but in the RSS feed the text and the link are split out. The URL goes in the RSS item’s link tag. While this is easy enough to support in tools, it’s surprising if you consider the link part of the content, not metadata. (I also expect inline HTML links to become even more common.)

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.

Launch Center Pro and Sunlit

I’ve long been a fan of Launch Center Pro, an iPhone app from my local Texas friends David Barnard and Justin Youens. It’s handy even for fairly simple tasks — firing off web searches or other shortcuts into apps — but it’s especially powerful when wiring up multiple apps together. For Sunlit it was nice to provide some full actions that Launch Center Pro users could use to automate bringing content into Sunlit.

Jonathan has the full rundown on the URL schemes that Sunlit supports and why we think they’re important. You can also use the Action Composer inside Launch Center Pro to access these actions without having to type them in.

And just today, Launch Center Pro for iPad shipped. Check it out and explore some of the many apps like Sunlit that are supported.

Ugly reminders

In my “last post about family pricing”:http://www.manton.org/2008/10/family_packs.html, I mentioned that I modified my PayPal scripts for backend order processing to support family packs, but I left out that the whole system is a hack. A hack that processes a nice chunk of money, but a hack nonetheless. Hard-coded PayPal buttons and coupons, PHP that would make even newbie web developers cringe, too few lines of code to really be taken seriously.

I refactored it a few months ago, but kept some ugliness in there to remind myself that I should move to a “mature store solution”:http://www.potionfactory.com/potionstore. Sometimes we build systems that are flawed from the start, and it’s wasted effort to invest time into something that will be replaced. Instead, let the thing stand out like a sore thumb.

It’s a complement to doing things simply and taking shortcuts even when it’s tempting to overengineer and build the perfect system.

This ugliness trick works for other things too. For example, the Wii Transfer product page is /software/wiitransfer/ instead of just /wiitransfer. I gave this URL more thought and second-guessing than it deserved, and every time I type /software/ or see the link I cringe a little. But I did it for a purpose: one day I hope to sell or promote things other than software. For example, when I registered riverfold.com I was working on an independent animated film which I planned to sell on DVD direct to customers. (I’ve had that shelved for years now, though, as I’ve recently discovered there are only 24 hours in a day.)

Others will say that you shouldn’t mix such different projects under the same brand, and that makes a lot of sense. But I also know it to be true that if you want to build a strong blog following, you should stick to one subject and become a respected voice in that field, and I didn’t do that either. I made a conscious decision with my personal blog to keep it loose and cover several different things that I am passionate about, and because of that I’ll likely never have tens of thousands of readers as other popular Mac development blogs have.

So maybe one day Riverfold will sell something other than Mac software. When that time comes, it won’t matter what the URLs are, but until then, the /software/ URL won’t let me ever forget that I have other things in mind.

Learning from Rails design

Since version 2.0, “Wii Transfer”:http://www.riverfold.com/software/wiitransfer/ has had a built-in web server for serving music and photos to the Nintendo Wii. The server was written in Cocoa and the code became very unwieldy as I continued to add features. Dozens of methods for processing different parts of the URL, and many if statements for conditionally branching based on the URL, splitting the URL parameters, and more.

The code looked something like this (only worse):



if (path startsWithSubstring:@"/albums") {

[self processAlbumsRequest:path];

}

else if (path startsWithSubstring:@"/artists") {

[self processArtistsRequest:path];

}

else {

// ...

}

(void) processAlbumsRequest:(NSString *)inPath

{

// split out the parameters and request extensions from the URL path

// ...

if ([e isEqualToString:"xml"]) {

// ...

}

else if ([e isEqualToString:"html"]) {

// ...

}

}

Multiply that times 10 for all the different URLs that Wii Transfer knows how to process, and you can see how it worked fine for a couple simple things, but quickly became a mess as I added features.

For the upcoming version 2.3, I redesigned most of the URLs to follow a common structure, patterned after the default URL syntax that Rails uses: /controller/action/id. Now, instead of if statements, I dynamically route the URL requests using NSSelectorFromString() and performSelector:withObject:.

Consider this code (as above, simplified from the real thing):



// extract the values from /controller/action/id URLs

NSArray* pieces = [[path stringByDeletingPathExtension] pathComponents];

NSString* controller = [pieces objectAtIndex:1];

NSString* action = [pieces objectAtIndex:2];

NSString* param_id = [pieces objectAtIndex:3];

// call a method named controller_action, passing it the id

NSString* sel_name = [NSString stringWithFormat:@"%@_%@:", controller, action];

SEL method = NSSelectorFromString (sel_name);

[self performSelector:method withObject:param_id];

Now if I need to invent a new URL, say “/tracks/play/1234.mp3”, all I have to do is write the implementation for that method:



- (void) tracks_play:(NSString *)inParamID

{

// ...

}

The web request calls through to this new method without any additional glue code, in this case passing “1234” in the single parameter.

(The underscored method signatures aren’t very Cocoa-ish, but this is actually a plus because I can quickly spot the chunk of the controller that processes a set of requests, and I like that they read just like the URLs. I’m also currently using a single controller instead of having separate controller objects for the different types of requests, but I may expand that later.)

This convention has also allowed me to simplify all the URLs that Wii Transfer uses. Other examples include “/covers/search/U2” or “/artists/show/5”. I’ve eliminated a bunch of code, and it fits nicely with how I serve application resources and the start of a HTML template system.

Could it be taken further? Sure. I remember in the Mac OS 9 days building a web interface for a product using only compiled AppleScript scripts stored in the resource fork. Lately, folks like “Gus Mueller”:http://gusmueller.com/blog/ and Adobe’s Lightroom team have been doing interesting things with “embedding Lua”:http://www.sqlabs.net/blog/2006/01/adobe-lightroom-and-lua.html. I don’t want that level of extensibility yet, but it seems like a logical next generation when I outgrow even this new web architecture in Wii Transfer.