One-Time Fetch

The "One-Time Fetch" (since I am not quite sure what to call it) is the biggest problem I have with Inoreader and my students' blogs, so I'll explain the problem here, and then I'll list some of the ways I've found to accommodate and work around the problem.

When Inoreader fetches a feed, it goes and gets any new items in the feed, retrieving the content of the item. If the content of that item changes, you will never see those changes in Inoreader; you will only see the content that Inoreader fetched when it added the new item to the feed. This is not really a problem for feeds in general, but it can be a problem for my students' blogs. Here is what I have learned about that:

1. Explain Save button and blog drafts. I need to emphasize very strongly to students at the beginning of the semester that the "Save" button in Blogger is their friend! If they have a post that is not finished, they should save it, rather than publishing it and then editing it later. Luckily, that is a blog courtesy in general; if you know something is not finished and not ready for others to read, you shouldn't publish it, and that is true for for schoolwork and any other kind of blogging. Some of my students would hit publish as soon as they typed the first sentence of their post, and if Inoreader fetched that, yikes, not good. I wrote to these students individually about the situation, but I did not anticipate this problem in my instructions; I will be revising my instructions to put a big emphasis on the "Save" button and the idea of a blog "draft."

2. Use the Inoreader web-view option. Inoreader does have a very handy web-view option which lets you see the actual web version of any post. This is handy for all kinds of reasons (my students choose their own blog designs which often adds to the personality of their posts), and it is also a good way to quickly check on a student's post if it was published prematurely. 

3. Use tags to track possible problems. So, for example, if I saw that a student's post did not look like it was complete, I could click the web-view option and see. If it was complete, I added a tag to the post "seeweb" to help me remember that to see the full post I had to look at the web. If it was not complete even on the web version, I would tag the post as a "problem" and check back later with the web-view, contacting the student if there really was a problem.

4. Use tags to remove problem items from syndication. Since this was not a big problem, I did not worry about incomplete posts showing up in syndicated feeds (like when I share examples of student posts in the assignment instructions), but if I did notice a big mismatch between the Inoreader version of a post and the actual published version, I would remove the tag that was syndicating the post. 

5. Don't Assign Multi-Stage Blog Posts. This was the single biggest mistake I made in my first semester of using Inoreader. I had designed all my assignments not even knowing about Inoreader, and then when I realized the one-time-fetch problem, it was really too late to change them. For more about that, see My Rookie Mistakes page.

6. Be Aware. For the way I use blogs in my classes (I consider blog posts informal writing assignments, not formal writing), this is not a major problem, but it's something I needed to be aware of at all times. I found it absolutely convenient to use Inoreader to read and review all incoming posts, but whenever I commented on a student's post or contacted a student directly about a post problem, I would do that while looking at the current version of the public blog post, rather than expecting the Inoreader version to be 100% up-to-date.

Last updated: 11/23/2014.