Perhaps you are multitasking as you read this. Many of us work in fast-paced environments where multiple things need to be happening at the same time. For close to 2 decades—ever since I bought a PlayStation that could play both video games and music CDs—I have expected multiple capabilities of my technological devices. It seems that the number of new technological devices increases exponentially each year, and rarely do they serve a single purpose. Would you buy a single-use tool if you could acquire the digital equivalent of a Swiss Army knife?
Smartphones, and now tablets, have made the term app, short for application, common. Opening an app is generally easier than choosing the correct option from a shiny red and silver multi-use tool. So what are scholarly publications doing with apps, and, perhaps more importantly, have publications found them to be worth providing?
You may have been in a meeting in which someone excitedly suggested that your publication create an app. The most important reason to create an app is to provide something that consumers want. Creating an app with no purpose or one that is “buggy” might mean that people download it and never use it. Even worse, it could reflect poorly on the publication brand that you have worked so hard to build.
One of the first things to consider when creating an app is on which platform(s) it will be available. According to data from comScore MobiLens1 , released 3 January 2013 for the 3 months ending November 2012, of all smartphone platforms in use, Google’s Android was used by a majority, 53.7%, of smartphone subscribers. Apple’s iOS came in second with 35.0%, followed by RIM (BlackBerry) with 7.3%, Microsoft with 3.0%, and Symbian with 0.5%. If you are contemplating creating an app for a tablet, you may wish to assess first how your current Web site performs in browsers for common tablets (and whether what is already available to users via the browsers on tablets negates the need for an additional app). Platforms for tablets include multiple versions of Android, iOS, Windows, and Kindle. Before you decide to create a single app or multiple apps to accommodate specific smartphone and tablet platforms, you need to know which platforms the majority of your customers are using. If there is no clear majority or you aren’t willing to alienate users of any platform, you may find that optimization of your Web site for mobile devices is preferable to creating platform-specific apps.
I invited three experts to share their knowledge and experience regarding scholarly apps with Science Editor. I hope you enjoy this food for thought.
HTML5 for Scholarly Publishing, Paul Gee
Journals exist to vet ideas and disseminate them to their constituents (subscribers, members, researchers, and other users) as quickly as possible.
Technologies may assist in the mission of speedy dissemination of scholarly information, but technologies are not the mission. Technology is never the product.
When the JAMA Network began looking at the mobile landscape, we tried to keep those thoughts in mind as we attempted to make heads or tails of the app world. JAMA has been publishing continuously since 1883; there was little momentum behind jumping directly into an app, so we waited and observed. After a bit of time, other publishers released apps, noted a round of immediate downloads, touted them, and then went silent. We noticed a couple of trends. First, there appears to be no end to the number of devices being pushed into the market. (Apple products currently attract nearly all the physicians, but can that trend continue?) Second, achieving app downloads does not mean that the app will be used. Blogs like one published recently by the Wall Street Journal (Walker, 20122) report on the fickle nature of mobile-app use.
The JAMA Network team deliberated on those trends and considered our mission and strategy. The network was formed to answer the complaint heard from many of our members and subscribers, readers, and authors: “I don’t need journals. I don’t need issues. I just need content that supports my specialty and my profession.” We began to think about how mobile products or apps could drive personalized experiences with everything we publish, rather than single journal experiences. We asked ourselves, “Why work so hard to bring together so much content into one experience but build for the users of only one or two devices?”
The JAMA Network began to look outside the walls of traditional app development. We investigated the option of building an HTML5 mobile reading experience for our journals that would work on any device. The decision to go to HTML5 seemed to be an easy, black-and-white call, but there were and are many factors to consider before developing an HTML5 application.
First, the HTML5 standard is still under development (http://www.w3.org/html/wg/drafts/html/master/single-page.html). The coding standard itself tends to change rapidly, both supporting more functionality and refining flaws in the code.
Second, there are no “out-of-the-box” solutions for HTML5 journal delivery systems. Traditional app development has matured to the point where a publisher can contact a mobile vendor (Mobile IQ, Adobe DPS, and others) to launch a fast, sleek app version of its journal quickly. When we investigated HTML5 options, we were shown wireframes of the HTML5 journal experience—not live examples and definitely not a standard licensing agreement. You cannot buy an HTML5 journal app. You have to build one.
Third, performance of HTML5 apps depends heavily on users’ browsers to run the application and on users’ devices to store app content and data. Both dependencies create mild to moderate differences among end users that vary with their devices and browser configurations.
Publishers considering HTML5 should weigh and consider those three basic risks against such factors as mission, budget, and timeline.
The JAMA Network did decide to go with HTML5. In March 2013, we released The JAMA Network Reader (www.JNReader.com). The Reader works across all mobile platforms, both Android and Apple, for both tablet and phone models. Additionally, the Reader can be accessed from both laptop and desktop machines running Google Chrome and Safari browsers. Since the initial launch in March, additional browser support has been added for Firefox and Dolphin, and very soon Internet Explorer 10 will be added to the list. What this means is that the Reader can leverage one code base to deliver an app experience beyond just one device (iPad or iPhone), and on each device there are more and more browser choices for our users.
Development challenges all revolved around the difficulty of building an enjoyable, cohesive reading product that works well on any device. The marketing challenges continue to revolve around the difficulty inherent in explaining to users why they can’t find the reader in the app store; providing a simple URL to an app actually proved to be quite confusing to our users.
We are excited about the future. We will soon release a feature that allows us to generate URLs directly to individual articles within the app, a move that will take us away from “app marketing” and back to the basics of marketing our content. Additionally, we have already begun to test the Reader on the new touch-screen laptops cropping up in the computer aisle. We are pleased to see that there is no barrier to using it on any of these devices. The Reader launches on the huge touch-screen canvases and delivers a true “app experience” whether the user is “mobile” or not.
In the end, we are not sure that we made the right decision in “skipping” the app store. It would nice to be able to say, “Get it in the app store!” But we are happy that we already see a future in which we can provide a responsive screen-to-screen offline or online experience with our content for any of our users worldwide, regardless of the new devices that will continue to appear year after year.
Advantages of Web Apps, Joanna Gillette
When most publishers start to think about the possibility of providing an app for their publications, the focus is on native apps, that is, built specifically for Android, Apple, or other devices and sold through their stores. There is, however, an alternative to native apps that my experience has shown is very well suited to publications. That alternative is the Web app. You may also have heard the term mobile-optimized Web site, but the fact is that as HTML5 technology improves, there is an ever-smaller functional difference between what one can create with a native app and what one can create with a Web app. Furthermore, a Web app can have a number of advantages for publications.
The technological distinction between native and Web apps is relatively simple. A native app runs on a device’s operating system, and a Web app runs on a device’s browser. In the latter case, rather than downloading an application, users access a Web app by searching on the Web or inputting the URL directly. The Web site recognizes the user’s device and displays the appropriate view (desktop, tablet, or smartphone) accordingly.
From the publisher’s perspective, a mobile-optimized Web site can be much easier to manage than a native application. Device operating systems are updated often, and it is difficult to keep up with new developments. Not to mention the fact that you’ll have to develop native apps for multiple platforms if you don’t want to alienate readers. Web apps, in contrast, are designed to work on multiple devices, and browser technology seems to be moving at a much more reasonable development rate. As an additional publisher convenience, rather than needing to load content into both a Web site and a third-party application and perform quality control in both environments, a Web-optimized site allows for a single repository for your content. Similarly, use statistics are all tied to a single Web site, and this eliminates the need to reconcile use statistics for both your journal hosting site and a native app.
From the end user’s viewpoint, a Web app can provide the convenience of a native app without requiring precious device storage. Users who access your journal often find it simple to bookmark the site on their device desktop for easy access. But let’s face it, many of the people who read your articles aren’t browsing your journal’s Web site or app to find content. A recent study of reader behavior indicated that the most popular starting points for researchers looking for articles on a given topic are specialist bibliographic databases and academic Web sites.3 You may have had the experience of conducting a Google search and clicking on an interesting link only to be directed to a page that invites you to download a journal app . . . and you may also have shared my experience of going straight to the next article on the list of search results rather than going through the exercise of downloading the native app. By contrast, a Web app can provide a seamless transition from browsing to reading, directing the user straight to the article in a mobile-accessible format without making a pit stop at the app store. Another benefit for users is that because a Web app is really just a different skin for the full Web site, any user preferences or favorites that are stored in a user profile will be available in both the mobile version and the desktop version. Many Web apps also allow users to download content to their devices for offline reading.
For scholarly publications, a major benefit of the Web app is the ability of individual users to pair their devices to an institutional subscription. Depending on the library security, device pairing may be automatic (if the device is using the library’s wireless and is therefore within the library’s IP range). In other cases, users simply download a pairing code to input into their devices. A device is paired for a defined access period, after which a new pairing code must be used. While a device is paired with an institution, any access from that device is included in the library’s COUNTER reports.
Allen Press offers two distinct online platforms: Pinnacle is a journal-hosting platform geared to peer-reviewed scholarly publications, and BrightCopy is a digital magazine platform that is intended for more design-intensive, advertising-heavy publications. Both platforms can be optimized for mobile devices with the use of an HTML5 Web app. The technology offers a low-cost alternative to native apps that leverages the existing content platform. Cost is a substantial factor when one is considering applications for journal or magazine content. Although users are willing to pay for an application that delivers some unique functionality or content, our experience has been that subscribers expect to be able to view journal or magazine content on multiple devices for no additional cost. As the other contributors to this article have pointed out, there are a lot of great uses for native apps, but for journal and magazine content, my preference is for Web apps.
User-Centered Design for Mobile, SiNae Pitts
As a former researcher and published author in the sciences, and now as head of a mobileapp development company, I’ve experienced firsthand the rapid evolution of technologies, devices, and apps for scientific scholars. However, the end users evolve much less quickly, and when we design for them, we build lasting value that can withstand even the most sweeping of technological trends.
User-centered design optimizes how people can, want, or need to use your product rather than forcing them to change their behavior to accommodate your product or the technology you’ve chosen. The physical and logistical limitations of printed matter (bound issues and volumes) should not be perpetuated online and on mobile devices if they don’t match how readers interact with the content. It’s important to break content free of arbitrary containers and to make it granular and interlinked if it is to be useful to consumers rather than easier for producers. Reach for better user experience and better design first, better technology second, and maintenance of traditional modes of reading content only as absolutely necessary.
Scientific scholars are inundated by content, and more sources emerge daily. They need apps that go beyond presenting content, even premium content, and that help them to make good use of the content. Good design begins with people’s needs and leverages technologies to help them to accomplish their goals. For scholars, those goals are generally content discovery, content consumption, and content production. If you consider how your app or potential app can make content most usable for your users, worries about return on investment will be fewer than if your projects are driven by organizational mandates.
It may seem to be an uphill battle to keep up with different device platforms, screen sizes, operating systems, format standards, and technology acronyms. However, it is never a waste of effort to learn more about your target audience, the contexts in which they interact with your content, and their goals. There are many reasons for going mobile, many ways to go about developing a mobile offering, and many groups that can build a mobile platform. Publishers need to make sure that their reasons are good reasons—the decision to go mobile should be supported by user data, and the publishers and developers should begin with a good understanding of their target audience.
Good design is driven and refined by usercentered evaluation, which helps builders to iterate and improve. There is no more honest evaluation than observation of what constituents are actually doing with your apps. Mobile apps allow an unprecedented level of usage analytics. Whereas the use of the Web is measured in hits and page views, the use metrics for apps are based on appspecific actions and engagements, such as creating favorites, sharing, and annotating. Mobile devices constitute the most personal technology that a person touches each day; they present a better opportunity for, and even need for, content personalization and user profiling than the Web.
At the end of the day, trusted content sources will be set apart not by superficial trappings, arbitrary styling, or being first to market but by how well they help their particular audiences to get their work done. There will always be room for organizations that know and serve their consumers. We start with the principle of building empathy for the user and understanding the content and context; these inform our designs, which ultimately inform our technology. With all the new devices and astounding adaptation rates, it’s easy to focus on the gadgets and the technology. However, our audience is the actor who should be on center stage and not left waiting in the wings. Otherwise, people will find different venues for discovering, consuming, and producing content— for entertainment, community, and, in the case of scholars, their livelihoods.
References
- comScore Reports November 2012 U.S. Mobile Subscriber Market Share. http://www.comscore.com/Insights/Press_Releases/2013/1/comScore_Reports_November_2012_U.S._Mobile_Subscriber_Market_Share.
- Walker, Joseph. A Look at How People use Mobile Apps. Wall Street Journal Blog. June 26, 2012. Last accessed May 13, 2013. http://blogs.wsj.com/digits/2012/06/26/a-look-at-how-peopleuse-mobile-apps.
- How Readers Discover Content in Journals: Comparing the Changing User Behaviour Between 2005 and 2012 and its Impact on Publisher Web Design and Function. Summary Edition. Tracy Gardner and Simon Inger. pp 12–13.
ANNA JESTER is director of sales and marketing, eJournalPress, Washington, DC.
PAUL GEE is senior product development manager, the JAMA Network, Chicago, Illinois.
JOANNA GILLETTE is product marketing manager, Allen Press, Inc, Lawrence, Kansas.
SINAE PITTS is chief executive officer, Amphetamobile, Philadelphia, Pennsylvania.