Library Hat Rotating Header Image

September, 2012:

A bad business model or a savvy market strategy? Thinking like a vendor

I want to talk about an e-book platform called Inkling whose web version is not cross-browser compatible. But what I am really interested to talk about is neither an ebook platform nor its cross-browser support. I am interested in thinking about the way we assess and evaluate resource products from vendors and their market strategies as librarians. I am using Inkling just as an example to touch on this topic.

Inkling is a company that makes an interactive textbook. It works with publishers to get a contract for certain titles of theirs, so that those titles can be made to e-books that run on and are sold at the Inkling platform. Inkling originally started as an e-book platform app on the iOS device such as an iPad and iPhone. The Inkling platform is quite nice. Adding annotation is easy and the page numbers of a print book is clearly marked on the side of its e-book version. Inkling e-textbooks in medicine offer interactive quizzes integrated into a human anatomy diagram and include related audio and video files that can be played right there inside the app, thereby broadening the utility of a textbook to students. The Inkling e-book platform also provides various sharing features that can be handy for students and teachers.

Recently, Inkling released a Web version. My library, which tested its app version earlier, was interested in purchasing some of the titles that were available at the Inkling Store for library patrons. Not only did we like the Inkling platform as a reading platform but we also found out that those titles were not available as e-books from any other vendors. My library wanted to provide more medical titles as e-books so that our students and faculty can access them with convenience. But while testing their Web version, we found a few problematic things for library patrons. (1) First, the Web version of Inkling doesn’t allow library patrons to use their iPad/iPhone version unlike products such as Naxos Music Library. So the convenience of getting the resource on a personal device was taken away in the Web version. (2) Second, Inkling requires each library patron to create a separate Inkling account in order to access the Web version of Inkling through the institutional subscription. The double authorization required – one for the university log-in and the other for the inkling log-in – was cumbersome and annoying. The majority of library users do not want to create an additional account for each database or resource that they use through the library subscription.

But the most problematic was (3) the fact that Inkling’s Web version only runs on Safari and Chrome.  No Firefox, no IE. This was a deal-breaker for us because the number one browser that is used to access our library’s website is IE and the second is Firefox according to the Google Analytics statistics. Furthermore, the most important patron group that my library serves, the medical students and faculty at our school, mostly work on the student laptops and office PCs that the school IT department configures and issues, and those student laptops and computers only come with IE and Firefox. Students and faculty have to request IT if they want to install any new software on these standard laptops and PCs. For this reason, when the limited browser support of the Inkling Web was known, librarians at my library unanimously agreed to wait for Inkling to add the support for other web browsers. We also did a demo of the Web version to a group of faculty with a few students included but the responses were lukewarm. So waiting was agreed to be the best option at this point.

At the same time, it was puzzling why Inkling released a Web product that only supports Safari and Chrome. We were told that Inkling e-books use HTML5 and CSS3 extensively and that not all the HTML5 and CSS3 features that Inkling uses are supported in IE and Firefox.  Okay, but if the Web version is to target institutional subscriptions rather than individual consumers – whom their iPhone/iPad version targets, then why the limited cross-browser functionality? In my opinion, no libraries were going to purchase ebooks that are going to run on web-browsers that half of their library patrons or more do not already have on their computers. Perhaps did Inkling release its Web version in haste and are planning to add cross-browser support as soon as possible? However, when my library inquired about Inkling’s future plan of cross-browser support, we were told that they were planning to add that feature in the future but without any timeline for it. Then, the cross-browser support didn’t seem like a high-priority for them. So if this is the case, what is going on?

Source: http://www.flickr.com/photos/angeliathatsme/6182582677/

As long as I was thinking as a librarian, I could only think that this was simply a bad business model. But let’s think about from Inkling’s perspective.  Is there a possibility that this is not a bad business model but an actually savvy business strategy? I do not doubt that Inkling’s development team can make their platform work with Firefox and IE. From the product they built, Inkling seems to have a capable dev team. I wonder if the company is debating internally whether adding the cross-browser support to their e-book platform would be a worthwhile investment at this point.

(A) First of all, HTML5 is being fast accepted as the new web standard and the W3C has a working group to finalize the specification. So whatever feature Inkling needs and FireFox lacks may well be soon added. And hopefully IE will follow the suit. If the browser support for these features are coming, Inkling may well do better by simply waiting a bit.

(B) The company may be uncertain about how much revenue will be generated from the institutional subscriptions. If the main attraction of their product lies in its availability on iPhone and iPad, then since this feature is not allowed for the users of Inkling’s Web version through the institutional subscription, individual consumers may well remain as their main target customer group. And for that matter, the release of the Web version itself doesn’t necessarily mean that the company is targeting institutional subscriptions as the main customers. The Web version might be a nice companion for the individual users who nevertheless purchase Inkling books mostly to use them on the iOS platform.

(c) But most importantly, Inkling’s real target could be mobile devices, not desktops. Now think about mobile devices – many different kinds of smartphones and tablets. If they are iOS devices, they will have Safari web browser. If not, they are likely to be Android devices. What browser do Android devices have? Chrome. So perhaps what the real market strategy of Inkling is going for the mobile market, not the desktop market. Maybe this is what they are really after.  Now the choice of Sarafi and Chrome seems to make much more sense, doesn’t it? And I have to say that focusing on the mobile is only smart considering that the Mobile Internet is about to surpass the Desktop Internet.  Of course, I have no way of knowing if any of these guesses are true. I am simply testing hypotheses.

So what was the lesson I learned? It was something obvious but nevertheless I have been overlooking for a while. As librarians, we are used to evaluate a resource product based upon how user-friendly it is for library patrons to use and how easy it is to implement in the common library setting (such as IP authentication by EZproxy and institutional log-in). However, these two factors are not necessarily the greatest concern for the vendors. That doesn’t mean that their business model is bad. They just happen to have a different business model that is not quite library-friendly. But vendors don’t exist to be library-friendly as much as libraries exist to purchase vendor products.  And sometimes, thinking about their concerns rather than ours can give us librarians a clue of where the vendors are going with their products and what their responses to our requests are likely to be, which we need to be aware of and to understand as much as we can. It is a good mental exercise for librarians.

 

 

The simplest AJAX: writing your own code (1)

*** This blog post has been originally published in ACRL TechConnect 0n September 12, 2012. ***

It has been 8 months since the Code Year project started. Back in January, I have provided some tips. Now I want to check in to see if how well you have been following along. Falling behind? You are not alone. Luckily there are still 3-4 months left.

Teaching oneself how to code is not easy. One of the many challenges is keeping at it on a regular basis. Both at home and at work, there seems to be always a dozen things higher in priority than code lessons. Another problem is that often we start a learning project by reading a book with some chosen examples. The Code Year project is somewhat better since it provides interactive tutorials. But at the end of many tutorials, you may have experienced the nagging feeling of doubt about whether you can now go out to the real world and make something that works. Have you done any real-time project yet?

If you are like me, the biggest obstacle in starting your own first small coding project is not so much the lack of knowledge as the fantasy that you still have yet more to learn before trying any such real-life-ish project. I call this ‘fantasy’ because there is never such a time when you are in full possession of knowledge before jumping into a project. In most cases, you discover what you need to learn only after you start a project and run into a problem that you need to solve.

So for this blog post, I tried building something very small. During the process, I had to fight constantly with the feeling that I should go back to the Code Year Project and take those comforting lessons in Javascript and JQeury that I didn’t have time to work through yet. But I also knew that I would be so much more motivated to keep learning if I can just see myself making something on my own. I decided to try some very simple AJAX stuff and started by looking at two examples on the Web. Here I will share those examples and my review process that enabled me to write my own bit of code. After looking at these, I was able to use different APIs to get the same result. My explanation below is intentionally detailed for beginners. But if you can understand the examples without my line-by-line explanation, feel free to skip and go directly to the last section where the challenge is. For what would your AJAX skill be useful? There are a lot of useful data in the cloud. Using AJAX, you can dynamically display your library’s photos stored in Flickr in your library’s website or generate a custom bibliography on the fly using the tags in Pinboard or MESH (Medical Subject Heading) and other filters in PubMed. You can mash up data feeds from multiple providers and create something completely new and interesting such as HealthMap, iSpiecies, and Housing Maps.

Warm-up 1: Jason’s Flickr API example

I found this example, “Flickr API – Display Photos (JSON)” quite useful. This example is at Jason Clark’s website. Jason has many cool code examples and working programs under the Code & Files page. You can see the source of the whole HTML page here . But let’s see the JS part below.

<script type="text/javascript">
//run function to parse json response, grab title, link, and media values - place in html tags
function jsonFlickrFeed(fr) {
    var container = document.getElementById("feed");
    var markup = '<h1>' + '<a href="' + fr.link+ '">' + fr.title + '</a>'+ '</h1>';
    for (var i = 0; i < fr.items.length; i++) {
    markup += '<a title="' + fr.items[i].title + '" href="' + fr.items[i].link + '"><img src="' + fr.items[i].media.m + '" alt="' + fr.items[i].title + '"></a>';
}
container.innerHTML = markup;
}
</script>
<script type="text/javascript" src="http://api.flickr.com/services/feeds/photos_public.gne?tags=cil2009&format=json">
</script>

After spending a few minutes looking at the source of the page, you can figure out the following:

  • Line 12 imports data formatted in JSON from Flickr, and the JSON data is wrapped in a JS function called jsonFlickrFeed. You can find these data source urls in API documentation usually. But many API documentations are often hard to decipher. In this case, this MashupGuide page by Raymond Yee was quite helpful.
  • Line 3-8 are defining the jsonFlickrFeed function that processes the JSON data.

You can think of JSON as a JS object or an associative array of them. Can you also figure out what is going on inside the jsonFlickrFeed function? Let’s go through it line by line.

  • Line 4 creates a variable, container, and sets it to the empty div given the id of the “feed.”
  • Line 5 creates another variable, markup, which will include a link and a title of “fr,” which is an arbitrary name that refers to the JSON data thrown inside the jsonFlickrFeed fucntion.
  • Line 6-8 are a for-loop that goes through every object in the items array and extracts its title and link as well as the image source link and title. The loop also adds the resulting HTML string to the markup variable.
  • Line 9 assigns the content of the markup variable as the value of the HTML content of the variable, container. Since the empty div with the “feed” id was assigned to the variable container, now the feed div has the content of var markup as its HTML content.

So these two JS snippets take an empty div like this:

<div id="feed"></div>

Then they dynamically generate the content inside with the source data from Flickr following some minimal presentation specified in the JS itself. Below is the dynamically generated content for the feed div. The result like this.

<div id="feed">
<h1>
<a href="http://www.flickr.com/photos/tags/cil2009/">Recent Uploads tagged cil2009</a>
</h1>
<a href="http://www.flickr.com/photos/matthew_francis/3458100856/" title="Waiting at Vienna metro (cropped)">
<img alt="Waiting at Vienna metro (cropped)" src="http://farm4.staticflickr.com/3608/3458100856_d01b26cf1b_m.jpg">
</a>
<a href="http://www.flickr.com/photos/libraryman/3448484629/" title="Laptop right before CIL2009 session">
<img alt="Laptop right before CIL2009 session" src="http://farm4.staticflickr.com/3389/3448484629_9874f4ab92_m.jpg">
</a>
<a href="http://www.flickr.com/photos/christajoy42/4814625142/" title="Computers in Libraries 2009">
<img alt="Computers in Libraries 2009" src="http://farm5.staticflickr.com/4082/4814625142_f9d9f90118_m.jpg">
</a>
<a href="http://www.flickr.com/photos/librarianinblack/3613111168/" title="David Lee King">
<img alt="David Lee King" src="http://farm4.staticflickr.com/3354/3613111168_02299f2b53_m.jpg">
</a>
<a href="http://www.flickr.com/photos/librarianinblack/3613111084/" title="Aaron Schmidt">
<img alt="Aaron Schmidt" src="http://farm4.staticflickr.com/3331/3613111084_b5ba9e70bd_m.jpg">
</a>
<a href="http://www.flickr.com/photos/librarianinblack/3612296027/" block"="" libraries"="" in="" computers="" title="The Kids on the ">
<img block"="" libraries"="" in="" computers="" alt="The Kids on the " src="http://farm3.staticflickr.com/2426/3612296027_6f4043077d_m.jpg">
</a>
<a href="http://www.flickr.com/photos/pegasuslibrarian/3460426841/" title="Dave and Greg look down at CarpetCon">
<img alt="Dave and Greg look down at CarpetCon" src="http://farm4.staticflickr.com/3576/3460426841_ef2e57ab49_m.jpg">
</a>
<a href="http://www.flickr.com/photos/pegasuslibrarian/3460425549/" title="Jason and Krista at CarpetCon">
<img alt="Jason and Krista at CarpetCon" src="http://farm4.staticflickr.com/3600/3460425549_55443c5ddb_m.jpg">
</a>
<a href="http://www.flickr.com/photos/pegasuslibrarian/3460422979/" title="Lunch with Dave, Laura, and Matt">
<img alt="Lunch with Dave, Laura, and Matt" src="http://farm4.staticflickr.com/3530/3460422979_96c020a440_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3436564507/" title="IMG_0532">
<img alt="IMG_0532" src="http://farm4.staticflickr.com/3556/3436564507_551c7c5c0d_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3436566975/" title="IMG_0529">
<img alt="IMG_0529" src="http://farm4.staticflickr.com/3328/3436566975_c8bfe9b081_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3436556645/" title="IMG_0518">
<img alt="IMG_0518" src="http://farm4.staticflickr.com/3579/3436556645_9b01df7f93_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3436569429/" title="IMG_0530">
<img alt="IMG_0530" src="http://farm4.staticflickr.com/3371/3436569429_92d0797719_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3436558817/" title="IMG_0524">
<img alt="IMG_0524" src="http://farm4.staticflickr.com/3331/3436558817_3ff88a60be_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3437361826/" title="IMG_0521">
<img alt="IMG_0521" src="http://farm4.staticflickr.com/3371/3437361826_29a38e0609_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3437356988/" title="IMG_0516">
<img alt="IMG_0516" src="http://farm4.staticflickr.com/3298/3437356988_5aaa94452c_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3437369906/" title="IMG_0528">
<img alt="IMG_0528" src="http://farm4.staticflickr.com/3315/3437369906_01015ce018_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3436560613/" title="IMG_0526">
<img alt="IMG_0526" src="http://farm4.staticflickr.com/3579/3436560613_98775afc79_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3437359398/" title="IMG_0517">
<img alt="IMG_0517" src="http://farm4.staticflickr.com/3131/3437359398_7e339cf161_m.jpg">
</a>
<a href="http://www.flickr.com/photos/jezmynne/3436535739/" title="IMG_0506">
<img alt="IMG_0506" src="http://farm4.staticflickr.com/3646/3436535739_c164062d6b_m.jpg">
</a>
</div>

Strictly speaking, Flickr is returning data in JSONP rather than JSON here. You will see what JSONP means in a little bit. But for now, don’t worry about that distinction. What is cool is that you can grab the data from a third party like Flickr and then you can remix and represent them in your own page.

Warm-up 2: Doing the same with JQuery using $.getJSON()

Since I had figured out how to display data from Flickr using Javascript (thanks to Jason’s code example), the next I wanted to try was to do the same with JQuery. After some googling, I discovered that there is a convenient JQeury method called $.getJSON(). The official JQuery page on this $.getJSON() method includes not only the explanation about JSONP (which allows you to load the data from the domain other than yours in your browser and manipulate it unlike JSON which will be restricted by the same origin policy) but also the JQuery example of processing the same Flickr JSONP data. This is the example from the JQuery website.

$.getJSON("http://api.flickr.com/services/feeds/photos_public.gne?jsoncallback=?",
  {
    tags: "mount rainier",
    tagmode: "any",
    format: "json"
  },
  function(data) {
    $.each(data.items, function(i,item){
      $("<img/>").attr("src", item.media.m).appendTo("#images");
      if ( i == 3 ) return false;
    });
  });

As you can see in the first line, the data feed urls for JSONP response have a part similar to &jasoncallback=? at the end. The function name can vary and the API documentation of a data provider provides that bit of information. Let’s go through the codes line by line:

  • Line 1-6 requests and takes in the data feed from the speicified URL in JSONP format.
  • Once the data is received and ready, the script invokes the anonymous function from line 7-11. This function makes use of the JQuery method $.each().
  • For each of data.items, the anonymous function applies another anonymous function from line 9-10.
  • Line 9 creates an image tag – $(“<img/>”), attaches each item’s media.m element as the source attribute to the image tag – .attr(“src”, item.media.m), and lastly appends the resulting string to the empty div with the id of “images” – .appendTo(“#images”).
  • Line 10 makes sure that no more than 4 items in data.items is processed.

You can see the entire HTML page codes in the JQuery website’s $.getJSON() page.

Your Turn: Try out an API other than Flickr

So far we have looked through two examples. Not too bad, right? To keep the post at a reasonable length, I will get to the little bit of code that I wrote in the next post. This means that you can try the same and we can compare the result next time. Now here is the challenge. Both examples we saw used the Flickr API. Could you write code for a different API provider that does the same thing? Remember that you have to pick a data provider that offers feeds in JSONP if you want to avoid dealing with the same origin policy.

Here are a few providers you might want to check out. They all offer their data feeds in JSONP.

First, find out what data URLs you can use to get JSONP responses. Then write several lines of codes in JS and JQuery to process and display the data in the way you like in your own webpage. You may end up with some googling and research while you are at it.

Here are a few tips that will help you along the way:

  • Verify the data feed URL to see if you are getting the right JSONP responses. Just type the source url into the browser window and see if you get something like this.
  • Get the Firebug for debugging if you don’t already have it.
  • Use the Firebug’s NET panel to see if you are receiving the data OK.
  • Use the Console panel for debugging. The part of data that you want to pick up may be in several levels deep. So it is useful to know if you are getting the right item first before trying to manipulate it.

Happy Coding! See the following screenshots for the Firebug NET panel and Console panel. (Click the images to see the bigger and clearer version.) Don’t forget to share your completed project in the comments section as well as any questions, comments, advice, suggestions!

Net panel in Firebug

 

 

Console panel in Firebug