When working with Liquid, the Hot Ink templating system, each type of object (like an article, a mediafile, an issue or even your newspaper itself) has data associated with it that’s available for use in your templates. Which piece of data is available depends on which template your working in, but perhaps the simplest case is a Hot Ink article page template. On each article template there’s a variable called “article” representing the article requested by the user.
Archive for the ‘Development’ Category
Template Data – Part 1: The Article Drop
Thursday, October 29th, 2009Introduction to Website Design with Hot Ink
Thursday, October 29th, 2009**This post is a basic introduction to using the Hot Ink templating system. You may recognize it as the introduction to the Hot Ink Publisher google doc some users have had access to. Others have contributed to this document (thank to all of you), I’m posting it here to give it a wider audience and to help answer some questions forusers new to Hot Ink.**
Publishing with Hot Ink is different from publishing with any other content management system. Hot Ink strives to make it possible for you to exercise the same kind of careful control over the structure, appearance and composition of your website as you do over the print edition of your publication. Because it’s so flexible, the templating system can be a little overwhelming at first. To help make it a little easier to understand by defining some key terms.
In order to be visible to the public, your website must have a design and it must be set to be your website’s current design.
A design is a collection of layouts, templates, stylesheets, javascript files and images that together define the complete visual
presentation of your website. You can have as many designs as you like, but only one of them may be current at any one time. The design
designated as current is the one shown to readers when they visit your website.
Designs control the appearance of your site using templates. Templates are dynamic HTML files written using a templating language called Liquid. Liquid is a simple, easy-to-learn addition to standard HTML that makes it possible to build complex templates that accommodate a variety of individual types and forms of content gracefully. For example, a well written Liquid template for your article page will display the article differently depending on whether the content is
horizontal or vertical, an image or an audiofile, has a subhead or no subhead. (more…)
Just sign on the dotted line…
Thursday, August 13th, 2009At Hot Ink meetings, we often discuss the opportunities afforded to us – but that’s putting it eloquently. Having worked at a paper with a website that barely functions, I’ve seen the barrage of “web-guys,” “sys-admins,” and “tech gods” who’ve promised to turn our homepage around or set us up with something we didn’t even know we needed. We either ended up with a sub-par product, no product or someone trying to use our content and brand to further themselves.
This is a fairly tired set of circumstances when it comes to student publications. Canadian student newspapers have been making a great product for years, and continually someone tries to piggy back on this success – lest we forget College Publisher, and Klegg Newspaper stands.
But what about locally? I would guess the problems now are similar to when I was editor-in-chief of my paper: I had no idea what to look for. Looking back, however, I find that pretty funny, as I had no idea what to look for in any of the other positions at the paper either. Nonetheless, I think I made some good hiring decisions based on criteria I never held up to any of the web-applicants.
That criteria was having an active interest in the well being of the paper. When it came to webmasters, I was desperate and under pressure to hire someone who could quickly get a dilapidated website up-and-running as fast as possible. I tried to decipher resumes listing qualifications I didn’t understand and had no right trying to understand at the time. My desperation to find anyone made me ignore what would usually be a make-or-break attribute of any other newspaper position.
We usually decide not to pursue these opportunities when it comes to Hot Ink for similar reasons. Those looking to make quick cash are not usually interested in the greater well being of your or anyone’s site.
Why were we so engaged in this particular topic? Well, I believe it goes back to the very fundamentals of Hot Ink and why the project was started. Months ago, Chris blogged about how Hot Ink is a vault for your valuables. Your content is coveted by everyone, and this large cache of quality media is the currency of the future. The traditional news advertising model is changing, and being part of that change requires you controlling what is yours.
I have no doubt the next few years will see an influx of tenacious pitchmen, holding the key to the next great innovation… All you have to do is sign over your work.
Hot Ink was conceived with the hope to thwart these efforts. Not only so you can store your valuables, but so that you can show them off and charge admission on your terms.
Feeling like you’re in the same sistuation when it comes to hiring? Don’t make any hasty decisions. Send a few quick questions to anyone on the Hot Ink team or if you’re a CUP member, use the listserv to garner some advice.
What’s in a date? You’d be surprised
Wednesday, May 6th, 2009Developing a publishing system like Hot Ink is an interesting job. For one, you spend a lot of time thinking about seemingly small things that turn out to be a big deal. One such example: an article’s date.
Seems pretty straight forward, right? Articles are published on a particular date and that date is important for the context of the article. Articles without a date are missing a very important piece of information. So, of course, we add one.
But which date?
What do we have to choose from? Off the top of my head: the date an article was first saved, the date it was approved by an editor, the date it became available online, the date it was published in a print edition, the date it was last saved, or simply an arbitrary date not related to any of these.
There are a few things we have to keep in mind. First of all, it’s a plain fact that an article in your paper’s archive is either available to the public or it isn’t. We don’t want the article appearing online the moment it’s first saved, so we need to decide when an article becomes available to the public. Since this is a switch that will happen instantaneously, it needs to have a time-of-day, not just a date, even if that time-of-day is midnight on the article’s day-of-publication.
Second, we know that users will sometimes want to upload articles that are dated in the future or the past. You could be uploading old archived articles, or a story that’s under embargo. You may just be uploading tomorrow’s edition tonight and holding the online versions until the print edition drops.
Third, we want the system to work “right” without the user having to think very hard. That means our default behaviour should be simple and predictable, but flexible for even the special cases we can’t anticipate in advance.
So how do we do it?
Since the internet doesn’t publish on a weekly schedule, all our articles will have not only a date, but a time-of-day. That means articles that would once have been dated simply “May 6, 2009″ will now have to become “May 6, 2009 at 2:13PM”. Luckily, for the most part, you won’t have to worry about the date. It’ll be set automatically the moment you (or your editor) hits “Publish”. After all, that’s literally the date and time-of-day you published the article.
But what if you want to upload an archived article? One from last week, last year, or even 15 years ago. You certainly don’t want those articles appearing as though they were just published.
Or, what if you wanted to upload an article today but have it appear online sometime later? Maybe you’ve written an in-depth feature series to publish in pieces over the summer. Maybe you’ve got a movie review embargoed until just before release. Hopefully you’re not uploading articles now and waiting for the print edition to make them available.
For past or future publishing, we’re making a “custom date” option available. If, for any reason, the auto-date doesn’t meet your needs, you can feel free to attach your own “custom” date. If that date is in the past, the “publish” button will make your article available in the archive for anyone looking. If it’s in the future, your article will be scheduled to “publish” on that future date, provided it has the necessary editorial approval.
But, it’s your system, not ours. What do you think of our solution? If it were up to you what would you do differently?
P.S. I didn’t even get a chance to talk about time-zones, but they’re a whole other layer on top of the “date” system. Luckily, you’ll never have to worry about time-zones, Hot Ink takes care of that for you.
The open source approach
Friday, April 24th, 2009
Hot Ink's project page at github.com, a social open source development site
The first decision we made when starting Hot Ink was to keep the project “open source.” We mention it everywhere, so that’s probably no surprise. Maybe you’ve even heard of it before. So, you’re entitled to ask: what specifically does “open source” mean, and why should I care?
If you’re anything like me, the first place you’ll look is the wikipedia page. That’s interesting, sure, but it’s also a little bit long and both too general and technical for our purposes. Instead, let’s keep it simple. To us “open source” will mean software development where the both final code and ongoing development are transparent (i.e. viewable and trackable online.) This is the opposite of traditional “closed-source” development, where only the final product is available and the code running it is completely hidden.
Open-source reporting?
A good way to understand the differences, from a software developer’s point of view, is to consider what it would be like to write a news article in an open-source environment. Currently, most campus newspaper articles are “closed source.” Reporters gather some primary and secondary sources, write up an article, then pass it off to their editor as a more-or-less complete package. That editor may have access to the primary sources but readers generally don’t. Readers get the final product, read it and live with it.
In an open-source reporting environment, the early stages would be very similar. A reporter would collect information from sources, write up an article, and then submit it to an editor for publication. However, readers would be given access to the reporter’s copy, notes and source materials. If a reader was confused by a clause in the article they could refer to the sources (or the notes) and determine the author’s true intent. Then, if the reader is motivated enough, he or she can update the story to read a little clearer. Expand this on a massive scale and what do you get? Wikipedia, more or less.