Expand my Community achievements bar.

Dive into Adobe Summit 2024! Explore curated list of AEM sessions & labs, register, connect with experts, ask questions, engage, and share insights. Don't miss the excitement.
SOLVED

Muse PreRelease to DPS 2015

Avatar

Level 4

Muse PreRelease to DPS 2015

I'm producing a muse page that is responsive so that it can be used in DPS 2015.

When I have an HTML article from muse placed in DPS it loads on iPad and phone great. But when I tap on the article the top menu does not show-up.

Is this a known issue?

I should add that other Muse 2015 html articles I have place in DPS 215 that are not responsive don't have this problem.

1 Accepted Solution

Avatar

Correct answer by
Employee

When this happens it is because your page is trapping the touch events so the viewer can't get them and react. You'll need to change your HTML so the javascript isn't capturing all the touch events. If you need to use touch events in your page you should integrate the DPS touch APIs.

Neil

View solution in original post

16 Replies

Avatar

Correct answer by
Employee

When this happens it is because your page is trapping the touch events so the viewer can't get them and react. You'll need to change your HTML so the javascript isn't capturing all the touch events. If you need to use touch events in your page you should integrate the DPS touch APIs.

Neil

Avatar

Level 4

"If you need to use touch events in your page you should integrate the DPS touch APIs"


Does this mean that these DPS API's need to be re-added in a program like Dreamweaver? This is not something I can do in muse?

Avatar

Employee

It means you have to write your Javascript code in a way that uses the APIs if you are attempting to use touch in your HTML. If you’re in Dreamweaver or Muse you’d need to include the APIs and then use them.

Neil

Avatar

Level 4

Ok. I will have to find out how a non-coder like myself can do this in muse. I have asked on the Muse Forum also.

Avatar

Level 2

I'm having this same problem. So how do non-coders solve this? I've looked at the DPSGesture API material as well, but being a non-coder, I really don't understand what goes where.

Avatar

Level 2

As I said in this other thread: same problem here.

I'm guiding a former DPS client into the realms of publishing with AEM and Muse for HTML content, but they have absolutely no experience or ambitions in coding. Let's wait for Adobe's official stance on their earlier "non-coding" approach and promise...

Avatar

Level 6

My $0.02 is that there is no such thing as an HTML solution with no coding required. Yeah, you might get away with something highly templated but to not have any HTML skills today is to put yourself at a very big disadvantage.

Avatar

Level 4

It would then be nice if adobe would put together an explicit (in the sense even dummies can follow along) tutorial on how to add AEM UI to a Muse Published page.

Since this would be a repetitive workflow for every artical created in muse.

Possible?

Avatar

Level 2

I guess having a session at Max titled "No Code Required: Using Designer-Focused HTML Tools with Adobe DPS" would be a little misleading then.

Avatar

Level 4

"BINGO" that's where some of the distress is coming from. Its marketed as one thing, and then once you have its another.

Avatar

Level 6

Yup. But they’re not alone. Everyone does it and I hate it.

Avatar

Level 4

So next best thing is to have a fantastic Tut on how to inject AEM API in to Muse page!

Avatar

Level 2

@BobLevine: That kind of generalization is not helping.

For every "skilled coder" there are probably hundreds - if not thousands - of other human beings who don't, won't, and can't get a grip on coding. And they have very legitimate needs for digital publishing tools. You're right: many of them will happily use some kind of template or framework solution. But a fair amount of designers will never touch a tag.

But let's go back to the problem at hand: AEM not playing nice with Muse.

A friendly Adobe staff member discovered that older Muse output (before the responsive hoopla) worked fine, so something must have crept in with a recent Muse and/or AEM update.

Would a straight-forward "dummy" tutorial on how to apply that Gesture API solution help ?

If copying/pasting/editing some necessary code into an HTML file is the solution, then why not let Muse, AEM, or even the Packager handle it ? As a temporary work-around, we consider developing a script and a hot folder to process the code into the files.