Getting .js Files Out of the Scaffold Script in the Super Helpful ‘backbone-in-rails’ Gem

Posted by on . No comments.

I’m working on stitching together the rails backend/api with a backbone.js web app I prototyped in isolation. Along the way, I started tinkering with – and quickly relying on – the ‘backbone-in-rails’ gem, which gives you a generator for a skeletal set of files for a backbone.js app within your rails app, and handles the asset pipeline.

I wasn’t sure what the benefit would be at first – I’ve already got a lot of js written, and I’m just integrating it all together. However, after about my second use of it, it really just became clear that it’s a nice time saver, an intuitive part of the rails workflow, and a good tool for keeping your namespacing and file system consistent.

There was a brief moment of hair-pulling, though, so I’m throwing this note out into the hive mind.

The documentation helpfully tells you that the whole thing defaults to coffeescript, but you can give the ‘– javascript’ directive to the installation script and it will support plain old javascript. What it doesn’t make explicit (at least, not explicit enough for dullards like me ;) is that you’ll also want to give that directive each time you fire off the scaffold script, or you’ll be left with a bunch of .coffee files where you expected plain old .js files.

It’s not the worst thing that can happen – there is a rollback script, and it’s not a huge mess – but since the whole purpose of the gem is to save you from having to go touch half a dozen files to add a new model to your backbone.js app, it’s worth noting.

I know I should make the coffeescript plunge – and I will, someday, probably – but it’s really nice that this little time saver supports the old fashioned way for us old fashioned js hacks.

Cheers!

 

Great Discussion of Content Driven Product Design on Build and Analyze

Posted by on . No comments.

The latest episode of Build and Analyze, Marco Arment and Dan Benjamin‘s podcast about the world of mobile web and app development (on the 5by5 network) featured a talk between the two hosts about an upcoming app Benjamin is having built for his podcast network. I recommend that everyone involved in designing and building digital content products give it  a listen.

It starts at the 54:40 mark in the episode, though the entire episode is great and I recommend you just subscribe to the podcast.

What I loved about the conversation was that Dan did not just focus on building an app that delivers his content to his audience – he recognized that there are already a number of ways for that to happen, and that he wasn’t really going to do it better, and that, in fact, asking users to get that content in a dedicated app that divided it off from the rest of the content they consume (could be a podcast catcher, could be a browser) was starting out by making things worse.

Instead, he identified what made consuming his content different and better: the experience of listening live, made unique by the specific hosts, formats and audience participation, and built an app that facilitates that specific thing. He even thought about what features he could include that would cater specifically to his most ardent fans, and thought about ways to monetize those features while enhancing the experience for everyone.

It’s a very good case study playing out in real time as Arment (the creator of Instapaper, and so a pretty good person to be providing feedback and insight) talks through the features, design, business model and functionality of the app, which is in final testing pending a release to the iOS App Store – at which time I’ll be paying for it for sure.

Bloggers Choose Who To Link To

Posted by on . No comments.

Editorial note: I first posted this referencing ReadWriteWeb instead of TheNextWeb. My bad. I’ve noted the change below using a strikethrough and replace. MP 20111130

Bloggers are a key audience for digital content creators whose needs and priorities usually go unconsidered by product teams. Bloggers on a beat covered by a media organizations – whether its national politics or local high school football – are certain to be among your most savvy, committed and loyal readers, and their blogs can provide valuable new unique users to your content if they find it link worthy.

To build audience, bloggers excerpt, link and comment on content from a broad range of sources on the topics of interest to their readers. Their incentive is to link to the best content they can every time, and the content experiences they link to are extensions of their site’s ux. When choosing which sources to reference, their first priority is to the quality of the content, but it isn’t the only thing they consider.

John Gruber today posted a follow up to a post he made wherein he linked to ReadWriteWebTheNextWeb. Gruber’s excellent blog, Daring Fireball, has a huge, committed following and a reputation for sending a lot of traffic to the sites he links to quickly. His follow up was prompted by a tweet from a reader about the page weight of the ReadWriteWebTheNextWeb article (3+ MB!) he had posted to, and explained that he considered not posting the link despite the quality of the article he was posting to because he doesn’t like the site. With this page weight information brought to his attention, he seems even less likely to do so in the future, though he doesn’t say as much in his post.

In the new media landscape, content creators cannot ignore the basic principles of good web design, which include limiting page weights and load times (even today in the era of broadband). This seems like an obvious statement, even though, in this case, a web only publication about digital products doesn’t seem to be aware of it, but what should be really interesting about this incident to content creators is that the experiences and perceptions of the specific bloggers who blog about the issues your organization covers should be inputs to the design process.