How to create an interactive multichannel presentation (from that PDF file you have) Posted on July 17, 2018February 4, 2025 by Andrii Nikulin So you want a full-function interactive presentation – one that is clickable, tablet-tappable, swipeable, and ideal for reps to use – but what you’ve got at the moment is a static PDF file? Maybe the file came from the agency, or was sent from the global office as a guideline – and now your department is facing the perspective of hiring a whole digital content team to create a multichannel wonder based on this. Maybe it is also upsetting that the project is nearly a from-scratch one, what with the whole HTML+CSS things to think of – so how challenging will it be for the budget? Have you wondered whether there is a shortcut from PDF to interactive format? In that case, you’re not alone – and yes, that’s an excellent idea! HTML presentations, eDetailing, interactive visual aids (IVAs) – whatever they are called in your organization, they are THE content in many cases, especially when it comes to rep interactions. Besides, once you have the presentation, it can (after just a little tinkering perhaps) be used in a variety of channels, including remote conferencing. At the same time, just having everything delivered by IT team is, well, not as cost-efficient as using the file the designers have carefully styled through. That is why Viseven team has created a PDF-to-HTML converter as part of the eWizard platform – a response to the many requests that (mainly) life sciences brand managers and marketers had. In this brief guide, you’ll see how this works and what can be achieved with the possibility. [in case you are curious] When best to use the PDF converter There are these moments is pharma communications where the responsible executive just needs more content. Preferably with minimum investment, of course. Since the “digital transformation” gained its full speed several years ago, the marketing budgets have grown slowly but steadily – a sign that the global offices started taking digital content very seriously but are reluctant to “overfinance” it. Out of the marketing directions considered in statistics, it is precisely the HCP audience that gains the steadiest attention, with about 50% pharma endorsing the effort to that end. A lion share of that content is presentations, of course. Yet, it’s not secret budgeting is also careful – about 1.5-2 years ago, only 30% of enterprises could track digital spending fully, mostly the more digitally savvy ones, according to McKinsey. As more pharma has been digitalized, the question has become more pressing, and regional affiliates are often left with a product/campaign launch in a new (emerging) market – and with restraints to comply with. At the same time, no one wants to sacrifice time-to-market (in fact, the #1 area of opportunity, as attested by 67% of companies). This is where the possibility to convert comes in handy. In general, it’s up to the organization to decide when to use a PDF converter to get an interactive aid – and when to go old-school and develop from scratch. Here are the three situations in which conversion becomes indispensable: Launching a new multichannel campaign that needs to be filled out with content really fast – and there are preexisting static assets. Budget restraints and focus on content reuse – but that content needs to get a “new life”. More and more content is required for field force efficiency – and a general strategy to foster in-house talent. Now, the converter itself. In fact, the procedure of creating an IVA is very simple, and only spans 3 steps. Ready? Step #1. Open the PDF converter in eWizard In your eWizard account, go to your eDetailers gallery – the place where you can see all the presentations you are (or have been) working on. In the corner, there is the +ADD NEW button, which presents you with several options. The last of these is Convert. Once you select it, you will see the popup that asks to upload the original file. The default method is simply to drag&drop the PDF from a folder on your PC. If your company is using Veeva Vault PromoMats, the left sidebar of the popup presents an option to load a file from Vault. Step #2. Find the PDF file you want to convert Rather self-explanatory, in fact. You can either drag&drop the file or click anywhere inside the popup to open the file manager. Your PDF file will most likely contain text on top of the background (so that it’s selectable with the mouse). Such text will be recognized by the system during the conversion so that you will later be able to edit it in the resulting HTML (the background will be, of course, preserved). All pages in the PDF will become separate slides. As soon as you select the file, a conversion starts, taking a few seconds before the magic begins… Step #3. Edit and add interactive components (events, actions) As soon as the conversion finishes, you will see the new presentation right there in the gallery. If already have some experience working with eWizard, you know what to do next: click the Edit icon (“pen”) and voilà – you can tinker with your new presentation, changing whatever needs to be changed. The selectable texts from the original PDF are up to you to change: You can even add new elements and whole new slides, expanding the presentation. Quite simple, isn’t it? If you have followed along, you can already consider yourself to be at quite an advanced level in content management. And, of course, if you are completely new to eWizard and have not yet got an account, don’t hesitate to request a demo to try out what you have read. Get creative with your digital initiatives – because multichannel excellence relies on your freedom of action. Now is a perfect time to start!
Sharing code across teams: current practices in agency race and how to prevent stumbling Posted on May 12, 2018November 22, 2024 by Andrii Nikulin Ctrl+C, Ctrl+V, more than 70% code currently shared on GitHub is duplicated. Did you just breathe that (no more guilty) sigh of relief and think “So it’s not only us”? Now, granted, most of the code out there is repetitive. Reinventing the wheel (a.k.a. retyping primitive bits of code that display/hide something, etc.) is definitely worse than plastering a dozen lines here and there all over several projects. Have you ever known people who actually sent JSON files via email? Okay, we all know there are multiple ways of sharing code and avoiding monkey jobs. The problem is, sometimes these code sharing tactics fail miserably. Especially when the code is being shared between teams who work remotely. The next thing that happens after a digital agency has bruised their toes against an unsuitable module system or code sharing practice, they tend to regress to the safe haven of “you do what you do”. In this article, let’s focus on what makes agencies stumble when creating and sharing/adopting code for pharma-related content. By the end, you’ll have identified what stumbling blocks there may be (and if your toes as a manager still hurt, they’ll probably be healing, as well). Frenetic deliveries, frail ecosystems With the “normal” rhythm of deliveries and deadlines, it’s hardly possible to blame any agency for poor codesharing practices. This is especially true for the pharma-oriented content: while traditionally the bulk of eDetailers, apps, emails, what-have-you was quite moderate, the situation has changed for many. On the one hand, pharma is noticeably laying more emphasis on digital production. As many as 84% managers reportedly believe that whenever there’s some true customer experience to deliver, content is the answer. On the other, HCPs are not as easy to impress; to appeal to today’s doctors, pharma has to provide not just ‘content’, but highly personalized experiences. In EU, 75% medical specialists explicitly state they want content that’s related to their specialty. The bulk of content is growing, even when marketers realize that it’s not the quantity but quality that matters – because of personalization. Accordingly, the entire cycle is shrinking, with deliveries coming at a fairly frenetic pace. Under these conditions, there comes the paradox. Setting up an adequate system that allows sharing encapsulated code entities, modules, blocks is becoming more necessary than ever – and yet, there’s simply no time to approach the question scientifically, so to say. Those who have worked with JS for a while remember the improvised, function-wrapped modules from before NPM and require; but even with ES6, there’s still room for improvement. It’s not just about refactoring and interdependencies, but also things like discoverability and sizing. There are stories about teams who went through painstakingly trying out very different approaches to sharing code, and the more dedicated ones end up inventing their own systems. Those, however, who don’t have the luxury of looking around and contemplating options, find themselves stumbling over several common problems with different codesharing practices. Here are the painful spots – and the lessons to infer. #1 Small bits of unspecific functionalities – all too many of them In one of these stories where they look for ideal not-reinventing-the-wheel solution, a team’s initial practice was publishing their code as modules on NPM. Now guess the problem. Right. First of all, the split repos by themselves were something to consider. Next, the code was split into small modules meant to be bundled together at some point in the perspective. Normally, of course, this is a good thing – after all, smaller code entities are more readily made self-contained, resembling those ideal “building-blocks” that we strive for. However, in some cases this multiplicity becomes a problem – you can have too much of a good thing, it turns out. The issues of refactoring and ownership of these packages, of course, exacerbated the issue. As an obvious remedy, there seems to be the idea of a single multi-package repository – but this, again, has its drawbacks: multiple package JSONs, multiple test/build environments – and an uncontrollably complex dependency tree. The truth is, each team should decide what the optimal package size should be for their specific purposes, and define the ways to store those packages, accordingly. Ready-made solutions are mostly lower-level in terms of both size and abstraction, but to reach ultimate efficiency (and not to regress to “tolerable” practices) an agency deserves to share larger entities on the same self-containing, comfortably encapsulated terms. #2 How maintainable is it all? Another issue that many encounter is keeping the shared code accessible and up-to-date. It’s not just the question of ownership, e.g. on NPM mentioned above, but the general discoverability and versioning concerns. While no one would want to install a whole library to use a component, when it’s the other way round – i.e. everything floating free, things become messy. Not only is it harder to find the modules needed, but also the versioning gets complicated quite fast. Now, the higher the change rate/frequency of updates – the more teams are working remotely – and the more testing needs to be done, specifically on the integration level, the more frustrating it gets. One doesn’t have to go far to hear people complaining about linking, submodules only working on one branch, nesting issues, etc. Again, the optimal approach is to consider how maintainable you want the whole shared code to be – and in what particular ways. For some projects, the focus is on testability; in some, it’s mostly about the plain possibility to find updated versions and ensure backward compatibility. Either way, the system has to be arranged for clarity. #3 Industry-specific requirements Who you write code for determines many things, including (crucially) functionality and how it gets constructed from separate elements and modules. If you are an agency working on pharma eDetailing presentations, for example, there most certainly are recurrent elements that customers request most often. Take a carousel with expanding elements that contain, say, patient profiles. Think of all the probable variants to implement this, a bunch of carousels, each of them relying on some shared functionality and building upon it. Now, the “core” functionality will very likely be assembled from more basic modules – and if these tend to be too small, there will appear all the problems with refactoring, testability, and linking. Of course, there’s also the reverse scenario, in which the packages used provide go-along bits you don’t really need, creating unnecessary interdependencies and devouring resources. Again, with pharma there are even more specific functionalities, especially related to the (extraordinarily well-developed) CRM and medical/legal review systems used, like IQVIA or Veeva. This is why, ultimately, code should be encapsulated, packaged, shared and updated based on industry-specific functionalities. The industry is, of course, whatever the customer intends to do with the deliverables once they leave your agency to see the daylight. Trial and error is not the only way it is Have you recognized any of the issues mentioned above? If so, you’re not alone, especially if your agency is specialized in medical content. There seem to be no ideal ready-made solutions around, as if everybody were to design code-sharing practice of their own. But do you really have to go through all that evolution on your own? Of course not. The reason why widely accepted module/package systems are easy to misuse is that they are for everyone – from website developers to mobile app designers. To adjust them to one’s needs will mean a lot of workarounds and duct tape hacks. Working with frameworks, storages, and platforms that were initially built around the needs of your own “segment” is more comfortable. For pharma content development, you can consider the possibilities of eWizard platform, where the available modular components are designed specifically with pharma content functionalities in mind – and with the purpose of saving time on repeated combining. Eliminate the anxiety of incorrectly split code packages – and you’ll see how surprisingly fast the different teams can really collaborate once they get to focus on the real tasks.
