[Web4lib] Android app for library catalog

Laura Krier laura.krier at gmail.com
Wed Apr 14 10:04:10 EDT 2010


As far as academic libraries go, I think it makes a lot more sense to
work with campus IT on any app they're developing, and to be sure the
library will be part of it, than it does to create our own, separate
apps. I don't think people are going to be doing any serious research
from their phones, so we generally want to offer account-related
things, like renewing books or checking the status of ILL items.
Having that included in a broader campus app would be key.

laura

On Tue, Apr 13, 2010 at 8:46 PM, Greg Carpenter <greg at boopsie.com> wrote:
> The one thing to keep in mind about your web traffic is that it is skewed
> towards iPhone from the beginning.  The reason that is is that iPhone users
> know they can have a reasonable experience on the iPhone on 'normal' web
> sites.  Any other handset user is used to a crappy experience.  Therefore,
> anyone that is gauging mobile interest by their web logs is making a
> mistake.  What you really need to do is ask the right question: poll your
> audience as to what mobile devices they actually have vs. what you see in
> your web logs.  Secondly, if you had a reasonable experience on your mobile
> phone, would you use it.  The 2nd question is easily answered because of the
> fact that you are indeed getting iPhone traffic.  Therefore, there is an
> interest in accessing the data from a mobile device.  If you have an app
> that runs on all platforms (or at least 90% of the platforms) that your
> audience is using, then you will see a much higher use rate across your
> library materials.  We've seen this in virtually every library we have
> mobilized (I am the CEO of Boopsie, FYI).
>
> The other thing you should keep in mind is that the majority of phones in
> the market are not Javascript enabled - so, a lot of the 'modern day' web
> sites are unusable on mobile devices.  If you stick to basic HTML then you
> may able to create a web presence that is accessible across all devices.
> The biggest problem with that, however, is that you typically scale your
> user interface to the least common denominator of devices.  So, you may look
> good on an iPhone, but you look terrible on a BlackBerry.  CSS and other
> tricks are usable here, but you then have to detect the phone model and
> browser version to offer a tailored experience.  I would challenge anyone to
> do that if your customers use Opera - as they hide the true underlying phone
> and features by design.
>
> So, it comes down to whether you want to take the insane number of man hours
> to figure out a cross platform (meaning phone OS platform) web based
> strategy, or you can isolate your use to a sub-set of devices, or you can
> use a 3rd party vendor like Boopsie that has spent nearly 4 years developing
> a platform that addresses the above issues and gives a clean and usable
> experience across all platforms with integration into your existing ILS.
>
> Given the nascent market, leveraging a 3rd party that 'does this for a
> living' isn't a bad way to go.  Our mobile publishing platform allows you to
> generate an application that leverages the fastest search in the industry as
> well as integration into your existing ILS *and* allows you to customize
> additional channels in minutes, not weeks or hours - at an incredibly low
> price and with minimal impact on your resources.  In addition, the resulting
> app runs as a native app (meaning much faster) on Android, BlackBerry, J2ME,
> Palm OS, Symbian S60, Windows Mobile, iPhone/iPod/IPad *and* generates a
> scaled web lite version for all feature phones - all in a single app.
>
> When it comes to web vs. app, there is clearly a better solution that
> leverages both - which is what the Boopsie platform is doing.
>
> Cheers,
>
> Greg
>
>
> On Tue, Apr 13, 2010 at 8:01 PM, Steven Pryor <pryorsw at slu.edu> wrote:
>
>> I generally agree with the sentiment about basing a mobile presence on
>> mobile-friendly websites first.  I would not, however, expect Android users
>> to stay anywhere near 5%.  The platform seems to be coming into its own all
>> of a sudden and there are a LOT of Android devices hitting the market with
>> some major publicity and vendor support now.  Coupled with Apple's recent
>> practices to alienate developers and others (the same sort of thing that
>> basically marginalized their platforms the first time around), I think
>> starting on an Android app -- if you really want or need native app
>> functionality -- would pay off in the future when the platform gains some
>> serious market share.
>>
>> Just my opinion,
>> Steven
>>
>>
>> On 4/13/2010 8:35 PM, William Denton wrote:
>>
>>> On 13 April 2010, Heather J Klish wrote:
>>>
>>>  Has anyone created, or is anyone working on, an Android app for searching
>>>> their library's catalog?
>>>>
>>>
>>> I have an Android phone (and like it a lot), but I'm curious about why
>>> you're asking.  Are you asking out of general interest, or are you actively
>>> thinking about working on this?  Is there enough Android usage at Tufts to
>>> warrant it?  At www.library.yorku.ca we're seeing 75% of mobile vists
>>> from iPhones and iPods, and about 5% from Androids (4% if you take away me,
>>> probably).
>>>
>>> We're going to start on a mobile-friendly version of our site.  I agree
>>> with MJ Suhonos about apps versus web pages.  Google Sky Maps and Layar are
>>> fascinating apps that have to be apps, but I want everything my library does
>>> to be on the web first, and if that leads to services that apps can reuse,
>>> great.
>>>
>>> Bill
>>>
>>
>>
>>
>> _______________________________________________
>> Web4lib mailing list
>> Web4lib at webjunction.org
>> http://lists.webjunction.org/web4lib/
>>
>>
>
>
> --
> Greg Carpenter
> Boopsie - Type Less, Find More
> tel: 650-241-3300 x203
> _______________________________________________
> Web4lib mailing list
> Web4lib at webjunction.org
> http://lists.webjunction.org/web4lib/
>
>



-- 
Laura Krier

http://www.lauraek.net
http://kitchenilliterate.wordpress.com




More information about the Web4lib mailing list