We have migrated some collections to DPS 2015. One of the things we notice is how slow the new viewer opens every article.
In the current viewer, you can browse trough the whole edition (30-50 articles) really fast just a short time after the initial download has started.
In the new viewer, every article takes time downloading, giving the reader the feeling he is in a really slow app. And the limitation of only downloading the next four articles isn't really helping.
An ordinary edition of 30-50 articles is usually between 20 and 40 megabytes, so download time itself should not be the problem.
Hi Espen, thanks for the feedback. Note that the new DPS 2015 viewers take user into the article view right after tapping to view it, even if it hasn't been downloaded from the service, compared to the existing DPS product, which blocks access until some subset of articles have been fully downloaded to the device.
We have been making some performance and usability improvements to more effectively communicate progress to end users so it doesn't feel slower, and are also evaluating the explicit download feature (which is covered in other forum posts).
Yes the performance works fine in safari (as well as expected), as does it in DPS classic. The last two editions of WIRED UK for both tablet and phone are HTML, https://itunes.apple.com/gb/app/wired-magazine-uk/id400701660?mt=8I can share them with you if you want.
I have an idea that the custom Nav (that currently does not work in the publish environment) is causing an issue leading to excess render time (not loading time). I am planning to make a new version of the app that does not have this feature to see what impact that has on the speed. I cannot do that until Monday however when I am back in the office with my developers.
Because these are migrated folios and not folios created with the new set of API's for Publish then I know they may not be optimised as well as they can be. However for various reasons (namely cost and time) we are unable to integrate our CMS with new workflow for at least six months. The publishing plan for now is to continue to Publish via DPS classic and then migrate those folios into the new environment (does that make sense?).
Have you tried loading your HTML in Safari? How does it perform there?
Is it not possible to re-route some developer support through another office, Bucharest perhaps, I know they are mainly focused on the UI/UX but maybe they have limited dev support?
Considering we only have a few weeks left now until launch, waiting a week before a response (and expecting my team may have lots of work to do to fix any potential problems with migrated HTML) it is really eating into our timeframe.
Thanks. Everyone is out on vacation next week for the 4th of July so hang tight. We'll get back to you in a little over a week.
Can you please share your HTML content with Scott so we can take a look at it? Thanks.
We are using HTML articles rather than INDD based articles. These are created in a CMS (Umbraco) and then published via the DPS classic API. We then migrate this content into the new DPS Enviroment.
The pages are quite slow to load but worryingly the render time is even longer. Once the page has loaded the screen appears to be grey while the HTML renders. However its typical to wait between 7-20 seconds per article. For a 200+ article edition this is a huge problem.
I know you are constantly upgrading performance but we are still unable to test. Adobe have recommended we start to submit viewers soon to Apple for review but this will be impossible without prior testing. Do you have a definitive timeline for upgraded prior to launch?